process-gap(orchestrator): convergence counter lives in narrative prose — two independent counter slips in one session, one enabling premature ship declaration

## Summary

The consecutive-CLEAN counter for per-story adversarial convergence (BC-5.39.001 / D-006) is tracked as prose in orchestrator briefs and dispatch summaries, not as a machine-readable value governed by explicit rules. This produced two independent counter slips in one session:

1. **Orchestrator slip:** called a pass "2/3" when the cycle's Pass-1 was NOT_CLEAN — making the real count 1/3. The false premise propagated into the next reviewer's brief.
2. **Adversary slip:** a reviewer declared "CONVERGE + SHIP" at what was actually 2/3 CLEAN. Both caught before merge. The correction pass that followed found a real CRITICAL — validating that the reset was necessary.

## Evidence (single session, private pilot; identifiers scrubbed)

### Slip 1 — Orchestrator counter propagation

- Convergence cycle state: Pass-1 was NOT_CLEAN. Pass-2 was CLEAN.
- Orchestrator dispatch brief to Pass-3 reviewer: "two CLEANs precede you — this is your 3rd."
- Actual state: 1 CLEAN preceded (NOT_CLEAN, CLEAN). Pass-3 was only the 2nd pass in the clean run.
- Root cause: orchestrator tracked the counter narratively ("passes 1, 2, 3 run") without a rule that a NOT_CLEAN verdict resets the count.

### Slip 2 — Reviewer premature CONVERGE declaration

- Reviewer was dispatched with the brief from Slip 1 (false "2 CLEANs").
- Reviewer returned: CLEAN + "CONVERGE + SHIP" verdict.
- Actual CLEAN count: 2 (one of which was the reviewer's own verdict, one prior CLEAN).
- Action taken: orchestrator recognized the slip, reset, dispatched a correction pass.
- Correction pass result: real CRITICAL found — confirming the reset was not a false alarm.

## Why prose tracking fails here

The consecutive-CLEAN count has an update rule with two branches:
- Reviewer verdict is CLEAN at the frozen tuple (same commit, same spec version) → count + 1
- Reviewer verdict is NOT_CLEAN → count resets to 0

This is a deterministic state machine with a specific reset condition. Prose tracking (\"pass 1, pass 2, pass 3\") conflates ordinal position with cumulative CLEAN count. Any NOT_CLEAN pass resets the count, but does not reset the ordinal — making narrative conflation structurally error-prone.

## Proposed remedy

**Machine state field:** the consecutive-clean counter should live in a machine-readable field (e.g., `sprint-state.yaml:consecutive_clean_count`) updated by an explicit rule, not by narrative inference:
- On a CLEAN verdict at the frozen tuple: increment counter.
- On any NOT_CLEAN verdict: reset counter to 0.
- On a frozen-tuple change (new commit or spec version): reset counter to 0.

**Brief protocol:** reviewer dispatch briefs should carry only the current counter value (e.g., \"consecutive_clean_count: 1\"), never narrative like \"two CLEANs precede you\" or \"this is your 3rd pass.\" The ordinal position is not what the protocol needs; the current clean-run count is.

**Pre-dispatch check:** before any CONVERGE or SHIP declaration, the orchestrator verifies the machine-state counter value, not a prose summary.

## Relationship to existing issues

- **#344 (convergence fails to terminate on cosmetic residue):** #344 addresses the case where the counter increments correctly but the loop doesn't terminate because cosmetic fixes keep resetting it. This issue addresses the orthogonal case: the counter itself is wrong before the terminal decision. Both are convergence-integrity issues; the failure mode and remedy differ.
- **#470 (remediation scope miss / sibling sweep):** #470 addresses state-manager failing to propagate correct values to sibling sites. A counter field in machine state (per this proposal) would make it one canonical site to propagate, not a prose value scattered across dispatch briefs.

*(From a private pilot repo; framework-pattern detail only.)*