WirohのAI組織では、作業の途中で承認待ちが重なる一方、要件、実装、検証、reviewの記録が別々の場所へ分かれ、最後に証拠を集め直すことがありました。そこで三つの変更を一つのdelivery flowへつなぎました。作業記録は一件のUser Storyへ集約し、Issueを確認してからStory branchで着手する。workspace内の割り当て済み編集は進めつつ、外部状態や高リスク操作のgateは分ける。成果物はcommitし、non-force pushし、manifest付きdraft PRとexact headを揃えてからRitsuへ渡す。GitHubに接続する操作も外部状態の操作として扱い、利用不能なら実行したふりをせずblockerを返します。
これは「速さか統制か」の二択ではなく、止める場所を絞り、同じ流れの中に証拠を残すための更新でした。現在もrequirements、specialist handoff、変更、verification、reviewは同じUser Storyへ集約します。ただし、traceabilityがあることは、成果物の安全性や正確性を保証するものではありません。各gateは、その時点のartifactとevidenceを個別に確認するために残ります。