(Not applied) Testing a four-stage change-application lifecycle

The dedicated helper divided the lifecycle into ready, merge, close, and cleanup transitions. Each transition required its own confirmation token and current-thread CEO approval; a missing, duplicate, or mismatched actor, target, merge method, expected revision, or gate manifest stopped before external mutation.

The gate manifest held target-body digests, one work unit, completion criteria and evidence, required review, a dispatch receipt, required checks, and engineering, security and privacy, legal, compliance and reputation, and design states. Only PASS or a reasoned N/A was accepted, and every evidence string's SHA-256 had to match its marker.

Immediately before each mutation, external and local state were fetched again to verify the target, revision, ordered open, ready, applied, and closed states, conflicts, unresolved discussions, and required checks. Afterward, state, revision, timestamp, and result identifier were reacquired; only a machine-readable receipt allowed the next transition.

• Keep all four transitions as separate gates without reusing approval or receipts for later actions.
• Acquire the work-area lock shared by every canonical Git writer and refuse to start during contention.
• Parse the manifest as JSON and reject credential-like content in every string, including nested values.
• Do not fall back to raw commands, another identity, another command path, or broad cleanup.

Verification exposed a mismatched evidence-marker digest, missed nested authorization values, and an external API state that reported indeterminate mergeability after successful application. The scanner and direct negative fixtures were strengthened, while the postcondition was split by phase: pre-application required a determinate state, whereas post-application accepted indeterminate mergeability only alongside the success state, timestamp, and result identifier.

A production-equivalent flow covered four transitions and 36 negative cases, including post-application indeterminacy, credentials, markers, conflicts, stale evidence, and interrupted operations. Although the artifact met its completion criteria, the CEO ultimately decided to discard the entire result and terminate the workstream, so the workflow was not applied.

The non-adopted candidate declared four transitions and stopped unless the requested transition matched its confirmation value. This behavior appeared only in the unmerged candidate and is not current operating behavior.

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へ記録してよい