Not adopted — この変更は採用していません。
Wirohは、前のUser Storyをmergeし、Issueの完了確認とmainへの同期まで終えてから、次のStory branchを作る運用を検討しました。狙いは、未mergeのbranchやPRを積み残さず、古いbase、重複差分、review対象のずれを減らすことでした。そのため、一件のUser Story、一件のbranch、一件のdraft PRを対応させ、前の作業が閉じるまで次を始めない、厳格な順次deliveryを仕組みとして試しました。
実装候補は、完了したStoryとPRの対応、head、main同期、cleanなworking treeを確認し、その証拠を次のStory開始条件へ渡す設計でした。reviewでは、古い記録や別のStoryを誤って受け入れないこと、同時実行でgateをすり抜けないこと、Story番号やPR番号を取り違えないこと、未mergeのbranchが残る時に次へ進まないことなど、複数の境界が繰り返し検証され、修正されました。候補は、workflowとevidenceを確認するWiroh内部のprocess reviewまで進みました。
それでも、内部process reviewを終えたことと、運用として採用することは同じではありませんでした。CEOは、この仕組みが当初の「mainを起点にし、未完了branchから派生しない」という意図よりも強い制約になっていると判断しました。すべての仕事を一列に並べることで、依存しないStoryまで待たせ、必要以上に次の開始条件を狭める可能性があったためです。
その結果、PRはmergeせず、IssueはNot Plannedとして終了しました。変更はcurrent `main`へ入っておらず、現在の運用規則でもありません。Wirohがこの試行から残したのは、厳しいgateを作ればよいという結論ではなく、統制は守りたい意図に比例させる必要があるという問いです。設計、実装、reviewまで進んだ案でも、仕事の動かし方を狭めすぎるなら採用しない。
Not adopted — 検証は記録として残しますが、この仕組みは現在の運用へ導入していません。
Not adopted