#1796 cycle-override grants are deduplicated, so 'one grant = one entry' fails from the second grant on

Summary

cycle-override:<stage> is documented and messaged as "one grant = one entry", but the engine deduplicates the grant. The second and subsequent approve calls report success and write a journal entry, yet the allowance does not increment. The pre-flight then refuses the stage entry with a message instructing the operator to do the exact thing that just failed to work — so the operator loops forever with no way out except editing the definition.

Impact

This is the documented escape hatch for a stage at its maxCycles limit. When it stops working there is no supported path forward on an active run: reset is destructive, abort is terminal, and @swamp/software-factory ships no migrate. On a long run with recorded design, review and approval history, the only remaining option is editing maxCycles in the live definition mid-run — which is exactly what a runaway guard is supposed to prevent, and which silently weakens the guard for every other work item sharing that definition.

Reproduce

1. Drive any work item until a stage has been entered maxCycles times.
2. approve gateId=cycle-override:<stage> — succeeds. The next entry is allowed. Take it.
3. Bring the run back to that stage a further time, so it is blocked again.
4. approve gateId=cycle-override:<stage> a second time. Reports success and writes a journal entry.
5. advance into the stage.

Expected: the second grant buys a second entry, per "one grant = one entry".

Actual: the pre-flight refuses with

entered 6 time(s) (limit 5 + 1 override(s)) — a human must grant one more entry
with: approve gateId=cycle-override:scaffolding

Note 1 override(s) after two successful grants. The instruction in the message is the step that does not work; following it reproduces the same message indefinitely.

Observed on

• @swamp/software-factory 2026.06.24.1
• swamp CLI 20260818.201833.0-sha.70d2f529
• Real run: six sequential work items on one factory instance, stage scaffolding at its 5-cycle limit after an adversarial review loop.

Suggested fix

Either make the approval countable — record each grant as a distinct entry allowance rather than collapsing to a boolean "approved" per gateId — or, if a single grant per gate id is the intended semantic, change the pre-flight message so it does not instruct the operator to repeat an ineffective action, and document the real remedy.

The counted form seems right: the message already renders + N override(s), which implies the engine intends to track a number.

Related

gates[].pass collides with any transition sensibly named pass (transitions[].satisfied already exists as the better precedent). Filed separately; mentioned only because both surfaced in the same run.

Upstream repository: https://github.com/swamp-club/swamp-extensions

Environment

• Extension: @swamp/software-factory@2026.06.24.1
• swamp: 20260818.201833.0-sha.70d2f529
• OS: linux (x86_64)
• Deno: 2.8.3
• Shell: /bin/bash