One Issue through PCE

このページで分かること

この Issue を実装して がなぜ粗い指示なのか
PCE では Issue をどう Transition Contract に変えるか
AI、人間、CI、ポリシー、PR がそれぞれ何を形成するか
merge してよい状態を Warrant としてどう作り、誰の依拠に何を残すか

普通の依頼

よくある AI への依頼はこうです。

ログイン失敗時のエラーメッセージを改善して。

この依頼は短くて便利です。しかし、中には多くの判断が混ざっています。

何が悪い状態なのか。
どの表示が改善された状態なのか。
UI 文言だけを変えるのか。
Domain 層や API エラー分類も変えてよいのか。
フォールバックを追加してよいのか。
どのテストが必要なのか。
不明点が出たら止まるのか、推測して進めるのか。
何を、後続が依拠してよい記録として残すのか。

人間なら途中で確認するところを、AI は自然に補完して進めることがあります。補完された仕様に、次の作業者が気づかず依拠する。これが典型的な汚染経路です。

PCE では、この依頼を作業名ではなく状態遷移として扱います。目的は AI を縛ることではありません。依頼側が依拠できる境界を作り、その中で AI に候補を恐れなく出させることです。

PCE で書き直す

同じ Issue を、Transition Contract（状態遷移契約）として書くとこうなります。

transition_contract:
  current_state:
    - ログイン失敗時の表示が、ユーザーの次の行動を示していない。
    - AuthError の分類仕様は既存仕様として固定されている。
  desired_state:
    - Presentation 層の表示文言だけが更新されている。
    - 各失敗ケースで、ユーザーが次に取る行動を判断できる。
    - Widget test が表示分岐を観測している。
    - 採用した文言方針と、採用しなかった候補の理由が残っている。
  allowed_operations:
    - 表示方針の候補を複数出して比較する
    - Presentation 層の文言変更
    - 表示分岐に関する Widget test の追加
  forbidden_operations:
    - Domain 層の変更
    - Repository 層の変更
    - API 仕様の変更
    - AuthError 型の変更
    - 新しいフォールバックの追加
  invariants:
    - 既存の AuthError 分類を保存する
    - Domain 層に UI 文言を入れない
  warrant_required:
    - 複数候補を比較し、採用理由が説明されていること
    - 変更範囲が Presentation 層に閉じていること
    - テストが失敗ケースごとの表示を観測していること
    - 契約外の変更がないこと
  projection_required:
    - 採用した表示方針
    - 採用しなかった候補と理由
    - 変更ファイル
    - テスト結果
    - 契約との対応
    - 残った不明点
  stop_conditions:
    - 新しい AuthError 分類が必要になった
    - Domain 層の変更が必要になった
    - 不明点が実装判断に影響した

ここで重要なのは、AI に「よい感じに直す」ことを丸投げしていない点です。

契約があるから、依頼側は「Domain 層と API 仕様は変わらない」と依拠したまま、AI に候補生成、候補比較、採用済み候補の実行、証拠生成を任せられます。境界が信頼できるからこそ、AI の生成を解き放てます。

それぞれのアクターが作るもの

この一つの Issue でも、複数のアクターが違うものを形成します。

アクター / 面	形成するもの
AI	表示方針の候補、差分候補、テスト候補、残った不明点
CI	テスト結果、lint、build の証拠
人間	意図、ユーザー体験の判断、範囲の承認、リスク受容
ポリシー	変更してはいけない層、承認条件
PR	差分、レビュー、CI 結果、議論を保持する状態面
Memory（記憶）	将来に残すべき表示方針や判断理由の投影候補

PCE 3.0 では、これらを同じ成果物に押し込みません。

AI の差分は候補です。CI の成功は証拠です。人間の承認は権限とリスク受容です。PR はそれらを保持する状態面です。性質の違うものを分けて合流させることで、merge してよい根拠を組み立てられます。

Join して Warrant を作る

merge してよい状態は、AI の出力だけでは決まりません。候補、比較、証拠、意図、投影が揃う必要があります。

AI branch
  -> message candidates / diff candidate

CI branch
  -> test evidence

Human branch
  -> UX intent / scope acceptance / risk acceptance

Policy branch
  -> permission / prohibition

PR surface
  -> reviewable projection / rejected candidates

join
  -> Warrant
  -> merge-ready state

ここで注意すべき区別があります。CI のテスト結果は 証拠条件 です。何度でも再実行して再導出できます。一方、人間の「この範囲でよい」という承認と「残るリスクを引き受ける」という受容は 規範条件 です。あとからどんな AI にも再導出できません。だから記録すべき重心は規範条件にあります。「誰が、いつ、何を引き受けたか」は、記録だけが根拠です。

この merge に誰が依拠するのか

merge は終わりではありません。merge された文言方針には、後続が依拠します。

次に文言を触る開発者は、採用された方針を前提にする。
翻訳作業は、文言の構造に依拠する。
将来の AI は、投影された「採用理由」を記憶として参照するかもしれない。

だから投影には、依拠してよい範囲を明示します。「文言方針は正規。ただし、エラー分類の妥当性自体は今回検証していない」のように、依拠してよい部分と、依拠してはいけない部分を分けて残します。

また、この Warrant には無効化条件を付けられます。たとえば「AuthError の分類仕様が変わったら、文言方針は再判断が必要」。無効化条件が発火したとき、依拠していた後続作業に伝わることが、依拠の統治の完成形です。

Before / After

普通の AI 依頼	PCE での扱い
この Issue を実装して	候補を出し、比較し、採用した遷移を契約内で実行する
AI が仕様を補完する	不明点は Obstruction または Completion Candidate にする
テストが通ったら完了	テストは証拠条件にすぎず、規範条件と採用理由も見る
人間が見たら責任を負ったことになる	確認とリスク受容を分ける
AI の説明をそのまま記録する	依拠してよい範囲を明示した Projection だけを残す

完了条件

PCE では、完了は「AI が作業を終えた」ことではありません。

完了とは、次の状態です。

契約に含まれる遷移が適用された。
候補が比較され、採用理由が残っている。
禁止操作が発生していない。
必要な証拠が揃っている。
残った不明点が明示されている。
依拠してよい範囲が明示された投影が残っている。
正規状態へ昇格させてよい Warrant（進行根拠）が、失効条件つきで形成されている。