変更の編集と反復

変更内のすべての成果物は、いつでも編集できるMarkdownファイルに過ぎません。 ロックされた「計画フェーズ」も、承認ゲートも、入る必要のある特別な編集モードも存在しません。構築を開始した後に提案を変更したいですか？proposal.mdを開いて変更してください。実装の途中で設計が間違っていることに気づきましたか？design.mdを修正して続けてください。それが答えの全てであり、それが設計の意図するところです。

このページは、「待て、あれを戻って変更できるのか？」と思った瞬間のためのものです。はい、できます。以下に、各一般的なケースでの方法を示します。

あらゆるものを編集する2つの方法

常に両方が利用可能です：

1. ファイルを直接編集する。 成果物はopenspec/changes/<name>/内のプレーンなMarkdownです。エディタでproposal.md、design.md、tasks.md、またはspecs/下のデルタ仕様を開いて変更してください。他に必要なものはありません。

2. AIに修正を依頼する。 チャットで、希望する内容を伝えるだけです：「提案を更新して、キャッシュのアイデアを削除し、レート制限セクションを追加してください」または「設計はポーリングではなくキューを使用すべきです」。AIは変更の残りの部分をコンテキストとして使用し、成果物を編集します。

その場に合った方法を使用してください。小さな文言の調整？ファイルを編集してください。実質的な再考？AIに完全なコンテキストで修正させてください。

「構築を開始した後に提案（または仕様）をどのように更新すればよいですか？」

単に更新してください。同じ変更を洗練させるだけです。

拡張コマンドを使用している場合、自然な流れは以下の通りです：成果物を編集し、次に/opsx:continueを実行して新しい状態から再開するか、/opsx:applyを実行して更新された計画に基づいて実装を続けます。デフォルトのcoreコマンドを使用している場合、成果物を編集して/opsx:applyを実行してください。現在のファイルを読み込むので、成果物が現在示している内容に基づいて構築されます。

メンタルモデル：成果物は署名された契約ではなく、生きた計画です。AIは常に現在の内容から作業するので、それらを編集することで作業を誘導できます。

You: I want to change the approach in this change.

You: [edit design.md, or tell the AI:]
     Update design.md to use a background job instead of a synchronous call.

AI:  Updated design.md. The task list still fits; want me to continue applying?

You: /opsx:apply

これは非常に一般的な質問に答えます：「提案を更新」コマンドが別途存在しない理由は、それが不要だからです。ファイルが信頼の源であり、それを（手動でまたはAI経由で）編集することが更新です。

「実装後にレビューに戻るにはどうすればよいですか？」

「戻る」必要はありません。なぜなら、あなたは決して離れていないからです。ワークフローは流動的です：レビュー、編集、実装は、あなたが閉じ込められるような順次フェーズではありません。

具体的には、/opsx:applyによる作業の後：

• 計画を再確認したいですか？成果物を開いて読むか、ターミナルでopenspec show <change>を実行して統合ビューを取得してください。
• 変更すべきものを見つけましたか？成果物を編集するか（またはAIに依頼するか）、その後続けてください。
• コードが計画と一致するか構造的に確認したいですか？/opsx:verify（拡張コマンド）を実行してください。完全性、正確性、整合性を報告し、何もブロックしません。Workflows: Verifyを参照してください。

戻るための「レビューフェーズ」は存在しません。なぜなら、レビューは実装後を含む任意の時点で実行できるものだからです。

「コードを手動で編集しました。OpenSpecとどのように調整すればよいですか？」

これは常に発生することであり、問題ありません。エディタで何かを調整し、今コードと成果物が一致していません。どちら側が正しいかに応じて、それらを再び同期させてください：

• コードは現在正しく、仕様が古くなっています。 実際に出荷した動作を説明するために、デルタ仕様（および関連する場合はタスク）を更新してください。アーカイブする前に仕様が現実と一致する必要があります。なぜなら、アーカイブ時に仕様が信頼の源にマージされるからです。
• 仕様は正しく、コードが逸脱しています。 コードが仕様と一致するまで、構築または修正を続けてください。

不一致を明らかにする迅速な方法は/opsx:verifyです：成果物とコードを読み取り、それらが異なる箇所を通知します。その出力を調整のためのToDoリストとして扱い、一致したらアーカイブしてください。

原則：アーカイブ時、仕様が記録上の真実になります。したがって、アーカイブする前に、仕様がコードの動作を正直に反映するようにしてください。手動編集は歓迎されます。ただし、それらが仕様を静かに非同期にさせないようにしてください。

気に入らない提案の洗練

生成された提案が的を外れている場合、3つの良い選択肢があります：

• その場で反復する。 AIに何が間違っているか伝え（「スコープが広すぎる、管理機能を削除してください」）、修正させてください。最も安価で、通常正しいです。
• まず探索し、その後再提案する。 問題がアイデア自体が不明確な場合は、/opsx:exploreに戻って考えを整理し、そこからより明確な提案を出させてください。Explore Firstを参照してください。
• 新しく始める。 意図が根本的に変わった場合、新しい変更は古いものを修正するよりも明確になることがあります。

その最後の選択肢については、次に独自の意思決定ガイドがあります。

更新するか新しい変更を始めるかの判断基準

短いバージョン：同じ作業を洗練させる場合は更新し、意図が根本的に変わった場合やスコープが異なる作業に爆発的に広がった場合は新しく始めてください。

• 同じ目標、より良いアプローチ？更新してください。
• スコープの縮小（今すぐMVPを出荷し、後でさらに追加）？更新してアーカイブし、フェーズ2のために新しい変更を作成してください。
• 問題自体が変わった（「ダークモードを追加」が「完全なテーマシステムを構築」になった）？新しい変更です。

Workflows: When to Update vs Start Freshに完全なフローチャートと実例があり、OPSX: When to Update vs. Start Freshに詳細な解説があります。

タスクについての注意

tasks.mdは凍結された計画ではなく、生きたチェックリストです。実装中に、発見したタスクを追加したり、不要だと判明したタスクを削除したり、並べ替えたりできます。AIは/opsx:apply中に完了した項目にチェックを入れ、後で戻ってきた場合は最初の未チェックタスクから再開します。途中でのリスト編集は想定内です。

次のステップ

• Workflows - パターンと、更新vs新規作成の意思決定ガイド
• Reviewing a Change - 構築前のプランに対する2分間の確認
• Explore First - アイデアを再考する必要がある場合に戻る場所
• Commands - /opsx:continue、/opsx:apply、/opsx:verifyの詳細
• Concepts: Artifacts - 各成果物の用途