（非適用）変更適用の4段階lifecycleを試す

専用helperをready、merge、close、cleanupの4 transitionに分けた。各transitionは専用の確認語とCEOのcurrent-thread approvalを要求し、actor、対象、merge method、期待revision、gate manifestが欠落・重複・不一致なら外部状態を変えず停止する。

gate manifestには、対象の本文digest、単一の作業単位、完了条件とevidence、required review、dispatch receipt、required checks、engineering、security・privacy、legal・compliance・reputation、designの状態を保持する。PASSまたは根拠付きN/A以外は通さず、evidence文字列のSHA-256もmarkerと一致させる。

各mutationの直前に外部状態とlocal状態を取得し直し、対象、revision、open・ready・applied・closedの順序、conflict、未解決discussion、required checksを照合する。操作後もstate、revision、timestamp、result identifierを再取得し、machine-readable receiptを記録できた場合だけ次のtransitionへ進む。

• 4 transitionを別gateとして保ち、一つの承認やreceiptを後続操作へ流用しない。
• 全canonical Git writerと共通の対象領域内lockを取得し、競合中は開始しない。
• manifestをJSONとしてparseした後、nested stringを含むcredential-like contentを拒否する。
• raw command、別identity、別command path、広範なcleanupへfallbackしない。

検証中、evidence markerのdigest不一致、nested authorization値の見落とし、適用成功後に外部APIが不確定なmergeabilityを返す状態が見つかった。scannerとdirect negative fixturesを追加し、適用前は確定状態だけを許可する一方、適用後は成功state、timestamp、result identifierが揃えば不確定なmergeabilityを許容するphase別postconditionへ修正した。

4 transitionと36件のnegative case、適用後の不確定状態、credential、marker、conflict、stale evidence、途中操作をproduction-equivalent flowで検証し、成果物自体は完了条件を満たした。しかし最終的にCEOが今回の成果をすべて破棄して作業系統を打ち切ると決定したため、このworkflowは適用しなかった。

非適用となった候補は、4つの遷移を明示し、要求した遷移名と確認値が一致しなければ停止する設計だった。以下はマージされなかった候補diffからの説明であり、現在の運用コードではない。

12. 正常系では、authoring / implementation role agentはPR作成・検証・Ritsu explicit PASS後に、統合要約、PR情報、検証証拠、残存blockerをdomain leadまたはMakoへ通常handoffする。Ritsuはreviewと対象User Storyへのreview結果記録を担当し、通常の成果物作成、commit、push、PR作成を担当しない。CEO承認証跡や拒否理由を正常系handoffの必須項目にしない。CEO本人がtrusted transcript上の現スレッドで対象repository / PRとmerge methodを明示承認した後、Makoだけがdedicated lifecycle helperの`ready`、`merge`、`close`、`cleanup`の各直前に全gateを再照合する。pre-mergeの進捗とRitsu review activity / 結果は各担当roleがUser Storyへ記録してよい