FACTUAL ACTIVITY RECORD · An activity record based on work that took place
(Not applied) Gating new work with strict completion proof
Testing state checks and receipts, then declining the candidate because it constrained operations beyond the original intent
Purpose
When several Stories were handled in sequence, new work needed to start from the established baseline only after the previous work was complete, rather than deriving from unfinished work. The starting concern was preventing incomplete lines of work from accumulating.
The candidate tested a fail-closed flow in which repository-local helpers checked both the start and completion boundaries, then passed proof that prior work was genuinely complete to the next start decision as a receipt.
Implementation
The start helper was designed to confirm an open Task, agreement between the work location and baseline, a clean work area, and the absence of other active or incomplete work. If external state could not be read or history could not be checked completely, it stopped instead of inferring success.
- Work-unit names, Tasks, delivery records, and manifest numbers and destinations were structurally extracted and compared by exact identity.
- Local-only, external-only, unrecorded, open, ended-but-unapplied, and head-mismatched work lines were distinguished and stopped.
- When a long history reached the inspection limit, bootstrap was rejected rather than treating the history as empty.
The completion helper was designed to compare Task closure, application of the result, the work-unit head, its manifest, and arrival at the baseline, then produce a completion receipt for the next start decision. The receipt included the target, work unit, result, head, manifest, and creation time and was accepted only when it matched the immediately preceding completion record.
A shared lock in the Git common directory prevented simultaneous start and completion operations across multiple worktrees in the same Git repository. A linked-worktree test checked that only one operation acquired the lock and that the losing operation left work state unchanged.
- Exact identity and arrival checks were added so stale or unrelated receipts could not be accepted.
- Negative tests covered numeric prefix collisions, mismatches between displayed numbers and destinations, and references to another repository.
- Unrelated existing work lines were preserved, while authentication, API, and state-retrieval failures retained stop boundaries.
Isolated fixtures exercised success and failure paths, followed by shell syntax, helper isolation, linked-worktree locking, TOML parsing, rule examples, obsolete-invocation searches, and whitespace checks. Defects found in receipt provenance, fresh-copy detection, identity boundaries, history limits, and manifest destinations were corrected in the candidate in sequence.
- 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を開始するRendering diagram…
What was confirmed
Verification results
The final candidate passed shell syntax, helper isolation, linked-worktree locking, TOML parsing, rule examples, obsolete-form searches, and whitespace checks.
Testing found real failures around stale receipts, fresh copies, cross-worktree exclusion, incomplete work lines, numeric prefixes, history limits, and manifest destinations, leading to added negative tests and stop conditions.
However, the completed candidate had become a strict single-line operating model that also stopped unrelated active work, pauses for prerequisite work, Not Planned endings, urgent work, parallel small work, and receipt migration.
The CEO determined that the intended rule was lighter: start from the baseline and do not derive separate work from unfinished work. The candidate was not approved because it exceeded that intent, and the prior operating behavior was retained.
At the cutoff, the candidate had not been applied and the work ended as Not Planned. A lighter alternative with blocked, cancelled, not_planned, and superseded states remained only a proposal and was not implemented.
Basis for completion
This not-applied Activity was complete when the candidate's verification results were compared with concrete operating cases, the CEO declined it because it diverged from the original intent, and the target was confirmed to retain its prior state.