YasuakiOmokawa Workflow
- 依頼から、承認済みのPoC結果ファイル（
poc.md）のパスまたは同等の根拠、選定方式、実証済みの振る舞い、未解決事項、入出力契約、対象範囲、期待する振る舞い、対象コード、利用できる確認手段を特定する。PoC結果ファイルが渡されたら読み、## 問い、## 星取表、## 結論、## 申し送りを承認済みの根拠として扱い、そのファイルを結果の追記先、親ディレクトリ名を案件slugとして扱う。パスが無ければ依頼中の同等根拠で続行し、追記先が無い事実を報告に含め、案件slugは編集を許可された対象コードのパスと機能名から導出して導出根拠を報告する。同等根拠に方式の選定理由が含まれない場合は、選定理由を未検証事項として明示し、適合判断を条件付きとする。結論を覆し得る技術的実現可能性が未解決なら対象コードへ組み込まず、必要なPoCの問いと証拠を返す。 - 対象リポジトリの実ファイルから、今回に関係する配置、責務境界、命名、依存方向、データとエラーの扱い、テスト方法を確認する。従う慣習と根拠、検証する適合性の問いを対応付ける。境界案は実ファイルの類似例または依頼で承認された案に限定し、配置、責務を持つ層、依存方向、入出力またはエラー契約の組で同定する。既存の実ファイルが持つ契約を変えない案を既定候補とし、契約を変える案は、変えない案が実証済みの振る舞いまたは方式の選定根拠を成立させられない場合だけ候補化する。
- PoCで実証済みの振る舞いと未解決の振る舞いを分け、対象コードに対して、実証済みの部分だけを既存構成へ実際に書き込む。作業方針や想定差分の提示だけでは移植済みとしない。
- 編集を許可された対象コードと対応する検証コードに限定する。範囲外の変更が必要になった時点で着手せず、依存先と必要性を報告する。公開や外部状態の変更は、具体的な変更先と内容が承認されている場合だけ行う。
- 既存の確認手段と必要な追加確認を実行し、承認済みの各入出力と境界ケースに加え、関連する責務境界と契約への適合性を観測する。PoCの観測は実現可能性の根拠として再利用し、PoCが組み込み条件付きの結果と明示した項目、またはプロトタイプでPoCの観測経路・条件との差を実際に確認した項目だけを再測定する。対象コードへ組み込んだという事実だけでは差とみなさない。変更していない既存境界は実ファイルから不変であることを確認し、その対象は編集許可範囲と、変更箇所と同じ責務層の境界に限定する。適合性の判断には、境界案の根拠となる実ファイル、実際の変更箇所、振る舞いの観測結果、責務または依存方向が一致するか、逸脱時の具体的影響を揃える。承認済み契約の外で観測した差は観測結果として記録する。実証済み振る舞いの前提または既存の呼び出し側に触れる差はテストで固定し、それ以外は観測記録に留める。固定した差は残る設計判断として、PoC結果ファイルのPrototype節（追記先が無い場合は回答本文）に必ず併記する。
- プロトタイプは、期待する振る舞いとコードベース適合性の問いを観測し、適合または不適合を判断できた時点で完了する。適合の判断には、必須条件の充足に加え、その方式が選ばれた理由が組み込み後も成立していることを含める。振る舞いが通るだけではDesign Docへ進めない。技術は成立するが配置や責務境界が不適合なら、手順2で同定した境界案のうち、失敗した案から配置、責務層、依存方向、契約のいずれかを変える案だけを一候補一回試す。全候補を観測するか、実ファイルの根拠で棄却した時点で適合案は尽きたと判断し、範囲外の候補を発明しない。各候補の棄却は実行観測または実ファイルの根拠のどちらによるかを記録する。定量的な選定根拠は同一環境内の候補間比較で検証し、PoC環境の絶対値の再現を求めない。不適合が選定方式を覆すならPoCへ戻し、適合する複数案、または逸脱を選ぶ規範的判断だけが残るならDesign Docへ渡す。
- Design Docへ進めるのは、選定方式が既存コードベースに適合し、設計を覆し得る適合性の未検証事項がない場合に限る。意図的な逸脱を判断対象として渡す場合は、適合する範囲内の代替案を試したかリポジトリ上の根拠で棄却し、逸脱の具体的影響と判断主体を示す。これは逸脱の承認、本番品質、展開、運用準備の完了を意味しない。
- 検証終了時点で、適合、不適合、中断のいずれでもプロトタイプの変更を保全する。現在のブランチ名を記録し、案件slugを含むプロトタイプ用ブランチ（例:
prototype/<案件slug>）を現在のブランチから作成し、プロトタイプで変更した対象コードと検証コードだけをcommitする。無関係な変更はcommitに含めない。依頼が外部状態の変更を禁じる場合を除き、pushと元のブランチをbaseとするdraft PR作成をそれぞれ独立の操作として一度だけ試行し、成否を操作ごとに記録して、draft PRを作成できた場合はURLを記録する。成功を確認できなかった操作は状態変化の根拠なく繰り返さず、ローカルブランチ名と失敗内容を記録する。読み取り専用の事前確認は試行に数えず、事前確認で操作先が存在しないと判明した操作は試行せず対象なしとして記録する。その後元のブランチへ切り替え、現在のブランチが記録した元のブランチと一致し、プロトタイプの変更が元のブランチのworktreeに残っていないことを確認する。 - 追記先のPoC結果ファイルに
## Prototype節を追記する。変更箇所、振る舞いと適合性ごとの確認結果、プロトタイプの完了可否、Design Docへ進める可否、残る設計判断、制約、失敗、未検証事項を含め、### PRにdraft PRのURLまたは失敗時のローカルブランチ名と失敗内容を記録する。追記内容は、新しいセッションのDesign Doc作成がこのファイルだけで前提を再構成できる自己完結した内容とする。追記前に既存内容のスナップショットを取得し、追記後に再読取して、追記内容の保存と既存節の不変をスナップショットとの機械的比較で確認する。追記先が無い場合は同じ内容を回答で返し、保存できない事実を報告する。 - 書き込み操作を送信した事実、返却値が明示する結果、再取得で確認した保存状態を区別し、失敗や結果未確認から成功を作らない。PoC結果ファイルのパス、変更箇所、振る舞いと適合性ごとの確認結果、完了可否、Design Docへ進める可否、残る設計判断、制約、失敗、未検証事項、次に担うべき責務を返す。Design Docへ進めると判断した場合、後続作業への入力が追記済みPoC結果ファイルのパス、追記先が無かった場合は回答本文のPrototype節であることを明記する。別skillを暗黙に起動しない。