FACTUAL ACTIVITY RECORD · 実際の作業をもとにした活動記録
（非適用）次の作業開始を厳格な完了証明で制御する
状態照合とreceiptを組み合わせた候補を検証し、当初意図より制約が強いため採用を見送る
目的
複数のStoryを順に進める際、前の作業が完了していない状態から次の作業を派生させず、一つのStoryが確定したあとに基準状態へ戻って次へ進める仕組みが求められた。未完了の作業線が増え続けないことが出発点だった。
候補実装では、作業開始と完了の両端をrepository-local helperで検査し、前の作業が本当に完了したことをreceiptとして次の開始判定へ渡す、fail-closedな流れを試した。
実装
開始helperは、対象がopenなTaskであること、作業場所と基準状態が一致すること、作業領域がcleanであること、進行中または未完了の別作業が残っていないことを確認する設計にした。外部状態を取得できない場合や履歴を最後まで確認できない場合は、推測せず停止する。
- 作業単位名、Task、成果物記録、manifestの番号と参照先を構造的に抽出してexact matchする。
- localだけ、外部だけ、対応記録なし、open、終了したが未反映、head不一致の作業線を区別して停止する。
- 長い履歴が検査上限へ達した場合、履歴がないとは判断せずbootstrapを拒否する。
完了helperは、Taskの終了、成果の反映、作業単位のhead、manifest、基準状態への到達を照合し、次回の開始判定に使うcompletion receiptを生成する設計だった。receiptには対象、作業単位、成果、head、manifest、生成時刻を含め、直前の完了記録と一致する場合だけ受理する。
同じGit repositoryの複数worktreeから同時に開始・完了処理が走らないよう、Git common directoryに共有lockを置いた。片方だけがlockを得て、失敗した側は作業状態を変えないことをlinked-worktree testで確認する構成にした。
- staleまたは無関係なreceiptを受理しないexact identityと到達確認を追加した。
- 番号のprefix collision、表示番号と参照先の不一致、別repositoryの参照をnegative testへ加えた。
- 既存の無関係な作業線を削除せず、認証・API・状態取得の失敗では処理を止める境界を維持した。
isolated fixtureを使って正常系とfailureを検査し、shell syntax、helper isolation、linked-worktree lock、TOML parse、rule example、旧い呼び出し形式の残存、whitespaceを確認した。検査で見つかったreceipt provenance、fresh-copy判定、identity境界、履歴上限、manifest参照先の欠陥は候補内で順に修正した。
- receipt欠落、active downstream、dirty/non-main、local/remote/PR head mismatch、conflict、未解決review、required check失敗、承認不足、auth/fetch/API/FF-only pull失敗はfail-closedであり、次StoryのbranchやPRを作らない
- branch、PR、Issue、head、manifestの対応を保持し、無関係なbranch、PR、working-tree変更を自動削除・close・reset・discardしない。repositoryをまたぐ時は前repositoryのreceiptを確認してから、次repository自身のpreflightを開始する図を描画しています…
確認したこと
確認結果
最終候補はshell syntax、helper isolation、linked-worktree lock、TOML parse、rule example、旧形式の残存検索、whitespace検査を通過した。
検証過程では、stale receipt、fresh copy、worktree間排他、未完了作業線、番号prefix、履歴上限、manifest参照先のfailureが実際に見つかり、候補へnegative testと停止条件が追加された。
一方で、完成した候補は無関係な進行中作業、前提作業による保留、Not Plannedの終了、緊急対応、並行する小規模作業、receipt移行まで広く停止する、厳格な一本道の運用になっていた。
CEOは、求めていたのは基準状態から始めて未完了作業から別作業を派生させない軽量な制約であり、候補は意図より強すぎるとして承認せず、変更前の運用を維持すると判断した。
cutoff時点で候補は対象へ反映されず、作業はNot Plannedとして終了した。blocked、cancelled、not_planned、supersededを扱う軽量な代替は検討案に留まり、未実装だった。
完了とした根拠
候補の検証結果と具体的な運用ケースを照合し、CEOが当初意図とのずれを理由に不採用を決定し、対象が変更前の状態を保ったことを確認して、この非適用Activityを完了とした。