Make lifecycle review status transitions atomic and self-validating

[tkstang]

Summary

Lifecycle review status is duplicated across review ledgers, implementation and state prose, routing fields, and secondary counters. In a downstream run, product fixes were already complete but several additional review cycles were consumed because statuses remained stale or were reintroduced during later bookkeeping.

Examples included a completed fix event left in an intermediate state, stale pending prose, broken links after backlog archival, and a phase status reverting to review pending after correction.

Desired behavior

Establish one structured authority for review-event, phase, and routing status. Lifecycle commands should update dependent artifacts atomically or derive human-readable views from that authority. Before dispatching another review, run a consistency check that catches stale or contradictory status without consuming a reviewer invocation.

Historical review provenance must remain append-only; atomic current-state updates must not rewrite prior event identities, artifacts, or reviewed heads.

Acceptance criteria

• One transition helper or structured authority owns current review and phase status.
• Plan, implementation, and state views cannot silently diverge after a transition.
• A pre-review invariant rejects stale or contradictory current status before dispatch.
• Append-ordered review provenance remains immutable.
• Secondary fields and counters are either synchronized with the authority or documented as intentionally different semantics.
• Regression tests cover stale-state retention and reintroduction after an otherwise valid correction.

Related

• Classify review findings as content vs bookkeeping; bookkeeping findings must never block a gate or trigger a re-review #233 addresses classifying bookkeeping findings so they do not block like content findings.
• Gate review-provide appends a received row that shadows the root's terminal review disposition #194 addresses stale received rows in the review ledger.

This issue is distinct: it targets the cross-artifact transition mechanism that permits current lifecycle state to diverge.

[tkstang]

Additional evidence from a downstream quick-mode project (OAT CLI 0.3.7). It shows two writers for the same review event.

• oat gate review appended its own received row to plan.md ## Reviews for each gate artifact, with - in Invocation and Gate Target. The lifecycle skill also records a row for the same artifact (for example fixes_completed | gate | <target>). The result was duplicate rows for one event, and one had to be removed by hand.
• The quick-mode scaffold keeps an inapplicable design | artifact | pending row that never resolves.
• One review artifact's frontmatter said oat_review_invocation: manual while its table row said auto.

Suggested direction, within this issue's single-authority goal: the gate command upserts one row keyed by (scope, type, artifact), fills Invocation and Gate Target, and preserves Reviewed Head across status transitions. Skills update that row rather than appending another. Quick-mode scaffolds omit scopes they never use.

[tkstang]

Triaged in #330 (record).

Tracked as BL-260927-derive-current-lifecycle-state (Derive current lifecycle state from one authority for review, phase, and publication status) (shared with #310). The duplicate-row evidence in the comment above is folded into BL-260820-bind-each-gate-review (Bind each gate review disposition to its exact received ledger event): one row upserted per (scope, type, artifact), a plan placeholder row, Gate Target filled for artifact gates, and quick-mode scaffolds omitting unused scopes. Note: the ## Reviews rows are written by the lifecycle skills, not the oat gate review CLI itself, which is why two writers produce two rows.