変更の編集 & 反復
変更内のすべての成果物はあなたがいつでも編集できるプレーン マークダウン ファイルです。 ロックされた「計画フェーズ」、承認ゲート、入力する特別な編集モードはありません。構築を開始した後に提案を変更したいですか？proposal.md を開いて変更します。実装の途中で設計が間違っていることに気付きましたか？design.md を修正して、進め続けます。それが答え全体です。設計によります。
このページは「待機、その戻ってそれを変更できますか？」と思ったときのためです。はい。ここで各一般的なケースの方法。
何を編集する 2 つの方法
あなたは常に両方を持っています：
ファイルを直接編集。 成果物はプレーン マークダウン
rasen/changes/<name>/。proposal.md,design.md,tasks.md, またはspecs/下のデルタ仕様をエディターで開いて変更します。他には何も必要ありません。AI に改訂するよう頼んでください。 チャットで、あなたが望むことを言うだけです：「キャッシングアイデアを削除し、レート制限セクションを追加するために提案を更新、」または「設計はポーリングではなくキューを使用する必要があります。」AI は変更の残りをコンテキストとして使用して、成果物を編集します。
moment が適切な場合を使用します。小さな言葉遣い調整？ファイルを編集。実質的な再考？AI に完全なコンテキストで改訂させます。
「開始後に提案（または仕様）を更新するにはどうすればよいですか？」
更新してください。同じ変更、洗練。
拡張コマンドを使用している場合、自然なフローは：成果物を編集し、次に /rasen:continue を実行して新しい状態から選択、または /rasen:apply を実行して更新された計画に対して実装を続けます。デフォルト core コマンドを使用している場合、成果物を編集して /rasen: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: /rasen:apply
これは非常に一般的な質問に答えます：個別の「更新提案」コマンドはありません。ファイルが真実のソースであるため、編集することが（手動またはAIを通じて）更新です。
「実装後にレビューに戻るにはどうすればよいですか？」
「戻る」必要はありません。流動的なワークフローであるため、戻ることはありません：レビュー、編集、実装は、立ち往生したシーケンシャルフェーズではありません。
具体的に、いくつかの /rasen:apply 仕事の後：
- 計画を再検討したいですか？成果物を開いて読むか、ターミナルで
rasen show <change>を実行して統合ビューを取得します。 - 変更するものを見つけましたか？成果物を編集（または AI に依頼）してから、続けます。
- コードが計画と一致していることの構造化チェックをしたいですか？
/rasen:verifyを実行（拡張コマンド）。完全性、正確性、一貫性をレポートします。何もブロックせずに。ワークフロー：検証 を参照してください。
レビューに戻すための「レビューフェーズ」はありません。レビューは実装を含む任意の時点で行うことができます。
「手でコードを編集しました。rasen とそれを調和させるにはどうすればよいですか？」
これは常に起こり、それは大丈夫です。エディターで何かをツイークしました。コードと成果物は意見が異なります。どちらの方向が正しいかで、それらを同期に戻します：
- コードは正しい、仕様は古い。 デルタ仕様（および関連する場合はタスク）を更新して、実装した動作を説明します。仕様は、真実のレコード源にマージするため、アーカイブ前に現実と一致する必要があります。
- 仕様は正しく、コードドリフト。 コードが仕様と一致するまで構築または修正を続けます。
不一致を浮上させる速い方法は /rasen:verify：成果物とコードを読み込み、どこが異なるかを伝えます。出力を調整リストとして扱ってから、同意したらアーカイブします。
原則：アーカイブ時に、仕様は記録の真実になります。したがって、アーカイブする前に、仕様をコードが行うことについて正直にします。手動編集は歓迎です。静かに仕様を同期させないでください。
あなたが満足していない提案を洗練
生成された提案が的を外れた場合、3 つの良い動きがあります：
- 場所で反復。 AI に何がオフか（「スコープが広すぎるため、管理機能を削除」）を伝え、それを改訂させます。最も安く、通常は正しい。
- まず探索してから、提案を再提案。 問題がアイデア自体が不明な場合、
/rasen:exploreに戻ってステップバック、それを考える、そしてシャープな提案が出てくることができます。探索を最初に を参照してください。 - 最初からやり直します。 意図が根本的に変更された場合、新しい変更は古い変更をパッチするより明確にすることができます。
その最後の動きには独自の決定ガイドがあります。
更新対新規変更を開始する場合
短いバージョン：同じ作業が洗練されている場合に更新、意図が根本的に変更されたか、スコープが異なる作業に爆発した場合は新規開始。
- 同じゴール、より良いアプローチ？更新。
- スコープ缩小（MVP を今出荷、後で残り）？更新してからアーカイブ、その後フェーズ 2 の新しい変更。
- 問題自体が変更（「ダークモード追加」は「完全なテーミングシステムを構築」になった）？新規変更。
完全なフローチャートと作成された例は ワークフロー：更新対新規開始 と OPSX：更新対新規開始 のより深い扱いにあります。
タスクに関する注記
tasks.md は冷凍計画ではなく、生きたチェックリストです。実装するときに、発見するタスクを追加、不要であることが判明したものを削除、またはそれらを並び替えることができます。AI は /rasen:apply 中に完成したときにアイテムをチェックオフし、後で戻る場合、最初のチェックしないタスクから再開します。飛行中のリスト編集が予想されます。