変更の編集と反復
変更におけるすべてのアーティファクトは、いつでも編集できるMarkdownファイルです。 「計画段階」というロックされたフェーズも、「承認ゲート」、特別な編集モードも存在しません。構築を始めてから提案を変更したいですか？ proposal.md を開き、変更してください。実装途中でデザインが間違っていることに気づきましたか？ design.md を修正し、続行してください。それが全てであり、設計思想です。
このページは、「待てよ、戻ってこれを変更できるだろうか？」と思う瞬間のためのものです。答えは「はい」です。ここでは、一般的なケースごとの対応方法を示します。
すべてを編集する2つの方法
常に両方の手段があります。
ファイルを直接編集する。 アーティファクトは
openspec/changes/<name>/内のプレーンなMarkdownファイルです。エディタでproposal.md、design.md、tasks.md、またはspecs/下のデルタ仕様を開き、変更してください。それ以上のことは必要ありません。AIに改訂を依頼する。 チャットで、「キャッシングのアイデアを削除し、レート制限セクションを追加するように提案を更新して」や「設計はポーリングではなくキューを使用すべきだ」といった内容を話すだけで構いません。AIが変更の文脈を利用してアーティファクトを編集します。
状況に合った方をご利用ください。ちょっとした表現の調整ですか？ファイルを編集してください。本質的な再考が必要ですか？AIに完全なコンテキストで改訂を依頼してください。
「開始した後で提案（または仕様）を更新するにはどうすればよいか？」
単に更新します。同じ変更を洗練させるのです。
拡張コマンドを使用している場合、自然な流れは以下の通りです：アーティファクトを編集し、その後 /opsx:continue を実行して新しい状態から作業を再開するか、/opsx:apply を実行して更新された計画に基づいて実装を継続します。デフォルトの core コマンドを使用している場合は、アーティファクトを編集し、/opsx:apply を実行してください。これは現在のファイルを読み込むため、アーティファクトが現在何を言っているかに基づいて構築されます。
メンタルモデル：アーティファクトは署名された契約書ではなく、ライブの計画です。AIは常にそれらの現在の内容に基づいて動作するため、編集することで作業を誘導します。
text
You: この変更におけるアプローチを変更したい。
You: [design.md を編集するか、AIに指示する:]
同期コールではなくバックグラウンドジョブを使用するように design.md を更新する。
AI: design.md を更新しました。タスクリストはまだ適合しています。適用を継続しますか？
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 新規の決定ガイド
- Explore First - アイデアを再考する必要があるときに立ち戻るべき場所
- Commands -
/opsx:continue、/opsx:apply、/opsx:verifyの詳細 - Concepts: Artifacts - 各アーティファクトの用途