Workflow

1. 依頼から、承認済みのPoCまたは同等の根拠、選定方式、実証済みの振る舞い、未解決事項、入出力契約、対象範囲、期待する振る舞い、対象コード、利用できる確認手段を特定する。結論を覆し得る技術的実現可能性が未解決なら対象コードへ組み込まず、必要なPoCの問いと証拠を返す。
2. 対象リポジトリの実ファイルから、今回に関係する配置、責務境界、命名、依存方向、データとエラーの扱い、テスト方法を確認する。従う慣習と根拠、検証する適合性の問いを対応付ける。境界案は実ファイルの類似例または依頼で承認された案に限定し、配置、責務を持つ層、依存方向、入出力またはエラー契約の組で同定する。
3. PoCで実証済みの振る舞いと未解決の振る舞いを分け、明示されたローカル対象またはモック編集インターフェースに対して、実証済みの部分だけを既存構成へ実際に書き込む。作業方針や想定差分の提示だけでは移植済みとしない。
4. 編集を許可された対象コードと対応する検証コードに限定する。範囲外の変更が必要になった時点で着手せず、依存先と必要性を報告する。公開や外部状態の変更は、具体的な変更先と内容が承認されている場合だけ行う。
5. 既存の確認手段と必要な追加確認を実行し、承認済みの各入出力と境界ケースに加え、関連する責務境界と契約への適合性を観測する。PoCの観測は実現可能性の根拠として再利用し、PoCが組み込み条件付きの結果と明示した項目、またはプロトタイプでPoCの観測経路・条件との差を実際に確認した項目だけを再測定する。対象コードへ組み込んだという事実だけでは差とみなさない。変更していない既存境界は実ファイルから不変であることを確認する。適合性の判断には、境界案の根拠となる実ファイル、実際の変更箇所、振る舞いの観測結果、責務または依存方向が一致するか、逸脱時の具体的影響を揃える。
6. プロトタイプは、期待する振る舞いとコードベース適合性の問いを観測し、適合または不適合を判断できた時点で完了する。振る舞いが通るだけではDesign Docへ進めない。技術は成立するが配置や責務境界が不適合なら、手順2で同定した境界案のうち、失敗した案から配置、責務層、依存方向、契約のいずれかを変える案だけを一候補一回試す。全候補を観測するか、実ファイルの根拠で棄却した時点で適合案は尽きたと判断し、範囲外の候補を発明しない。不適合が選定方式を覆すならPoCへ戻し、適合する複数案、または逸脱を選ぶ規範的判断だけが残るならDesign Docへ渡す。
7. Design Docへ進めるのは、選定方式が既存コードベースに適合し、設計を覆し得る適合性の未検証事項がない場合に限る。意図的な逸脱を判断対象として渡す場合は、適合する範囲内の代替案を試したかリポジトリ上の根拠で棄却し、逸脱の具体的影響と判断主体を示す。これは逸脱の承認、本番品質、展開、運用準備の完了を意味しない。
8. 書き込み操作を送信した事実、固定応答または返却値が明示する結果、再取得で確認した保存状態を区別し、失敗や結果未確認から成功を作らない。変更箇所、振る舞いと適合性ごとの確認結果、完了可否、Design Docへ進める可否、残る設計判断、制約、失敗、未検証事項、次に担うべき責務を返し、別skillを暗黙に起動しない。