Premise-check — 実装前の前提・影響範囲の独立確認

入力: $ARGUMENTS

親は修正方針を実装担当へ渡す前に、実装しない確認担当へ前提と影響範囲を確かめさせます。親が見ている目標の外にある利用者と、方針が暗黙に置いた前提を、親の見立てに引きずられずに洗い出すための手順です。確認担当は読み取り専用で、結果は親の判断材料です。合否のゲートや必須schemaは持ちません。

1. 確認担当へ渡す入力

渡すのは次の二つだけです。

• 修正方針: 変更内容と目的
• 変更するファイル・関数のpath

親による背景の要約、「影響はない」「この利用者だけが読む」といった見立て、期待する結論は渡しません。確認担当が自分でコードと履歴から調べるためです。渡すと独立性が失われます。

2. 確認担当の起動

• 実装しない独立した担当を、現在のruntimeの標準の汎用担当（read-onlyで足りるならその定義）として起動します。実装担当や、同じ作業を続けている担当を使い回しません。
• プロンプトには、入力（上記二つ）、共有 premise-check/references/checker.md の実在を確認した絶対path、「先にそのファイルをReadし、その範囲だけ行う」、「対象コード・設定・git・記憶を変更しない。他の担当を起動しない。結果はチャットで返す」を含めます。
• 親は checker.md の内容を読んで要約して渡しません。確認担当自身にReadさせます。
• 担当が起動できない、手順ファイルを読めない、入力が不足している場合は、別の担当や親の直接確認へ黙って置き換えず、原因を示して返します。

3. 返却の扱い

確認担当は、固定の五つの問いごとの結論、根拠（path:line、gitのcommit hash）、方針を見直すべきかを返します。

• 親は根拠を実際のコード・履歴と照合してから採否を決めます。確認担当の結論を鵜呑みにしません。
• 方針の見直しが示された場合、親は方針を更新してから実装担当へ渡します。担当の返却を転送しただけで方針の代わりにしません。
• 確認担当が挙げた利用者への影響は、実装条件と受入確認に反映します。
• 追加の確認が必要な論点は、新しい観測や具体的な未解決riskがある場合だけ再度確認担当へ渡します。