work-items(work): loop-prompt rule 20's cycle-budget stop trigger and an operator 'never stop' cadence override can silently conflict

[kyle-sexton]

Lane: work-2 · Category: operational · Source: live loop-lane session, 2026-07-20, cycle 12 stop decision.

Triggering example

Mid-session, the operator issued a standing directive: 'Keep going... keep the loop at 15 minutes, NEVER stop.' This was layered on top of the lane's existing standing rules, which include rule 20: 'RESTART TRIGGER — stop-with-"RESTART ME" ONLY on a REAL signal: the harness's own context indicator if visible to you, or a cycle budget of 12 cycles since session start.' Neither directive referenced the other. When the session reached cycle 12, I had two standing instructions in direct tension: the operator's later 'never stop' vs. the rule template's own cycle-budget stop trigger. I resolved it by interrupting the operator with an AskUserQuestion rather than silently picking a side — they chose to honor rule 20 and stop.

Observed vs expected

Observed: an operator cadence override ('never stop') and the rule template's own context-safety stop trigger (rule 20) can be pasted into the same standing-rules block without either explicitly addressing the other, forcing a mid-session interrupt to resolve the ambiguity.

Expected: the loop-prompt template (or the guidance around composing operator overrides with it) should state explicitly how a 'never stop' / 'keep the loop always running' cadence override interacts with rule 20's cycle-budget restart trigger — e.g. either (a) 'never stop' is understood to mean 'never stop for lack of work, but rule 20's cycle-budget trigger still applies and should stop-and-restart the SESSION, which is not the same as stopping the LOOP (a restart re-enters the same standing rules with fresh context)', or (b) an explicit operator override phrase that also raises/disables the cycle budget, distinct from the cadence-only 'never stop'.

Category

operational — a standing-rule composition gap, not a code bug. Surfaced by a real operator interaction this session, not hypothetical.

Related

Discovered while stopping this work-2 session at its rule-20 cycle-budget limit (12 cycles), per the operator's own confirmation via AskUserQuestion. See the final lane: work-2 telemetry comment on #502 for the session's full final state.

[kyle-sexton]

Field evidence from the 2026-07-20 wind-down interviews (control tower) — this issue is a genuine three-way rule conflict, not lane misbehavior.

T2's rule 17 verbatim (v9, what the lane actually ran — identical in substance to T3/T4's rule 20):

RESTART TRIGGER (v9 — #576): stop-with-"RESTART ME" ONLY on a REAL signal: the harness's own context indicator if visible to you, or a cycle budget of 12 cycles since session start. NEVER estimate or invent a context percentage — a guessed number is fabricated telemetry. If you don't know, write "unknown".

The three colliding directives:

1. RESTART TRIGGER (rule 17/20): MANDATES stop-with-"RESTART ME" at the 12-cycle budget — a context-health handoff, deliberately terminal for the session.
2. Operator "never stop" cadence directive (mid-session amendment, both T2 and T4 received it).
3. v13 flag-don't-stop amendment (files only; delivers at next restart): budget exhaustion is flagged, not acted on.

T2's own reconciliation reading: RESTART-ME is consistent with "never stop" because a fresh session immediately resumes the same standing /loop prompt with cumulative telemetry carried forward — the LANE never stops, only the SESSION rotates. Under that reading, (1) and (2) don't conflict, and (3) as written may be the wrong fix: removing the budget stop removes the context-health rotation entirely, trading rule clarity for compaction-degradation risk (the very thing #576 fabricated-context-estimates came from).

Decision needed (operator or design ruling): pick the semantics —

• (a) RECOMMENDED — codify T2's reading: budget stop = session rotation, not loop stop. Rename the mechanism (e.g. ROTATE-ME) so "never stop" and the budget trigger stop reading as a conflict; v13's flag-don't-stop subsection is then amended to apply only to non-restart budget flags. Preserves context-health rotation, kills the ambiguity, matches what lanes already do.
• (b) Keep v13 flag-don't-stop literally: lanes run past 12 cycles until the harness context indicator shows pressure. Simpler, but reintroduces reliance on an indicator lanes report they often cannot see, and loses the proven rotation cadence.

Whichever wins, the canonical files get one more delta so rule 17/20 and the v13 subsection state the same semantics — right now the files contain both.

[kyle-sexton]

This was generated by AI during triage.

Folding this into #535 (lane resilience umbrella) — this is exactly member 3, "Deterministic lane-stop gate": "'a lane that stops itself is a bug — file it' is a prompt admonition, not a mechanism. Root-cause fix: Stop hook and/or completion self-check intercepting every stop attempt. Converts stopped-lane from hoped-against to structurally-prevented."

This issue documents the symptom side of exactly that gap: an operator "never stop" cadence override and the standing rule's own cycle-budget RESTART TRIGGER composed ambiguously enough to force a mid-session human interrupt. The three-way reconciliation already worked out in this issue's own comment (RESTART-ME as session-rotation vs. loop-stop, the RECOMMENDED rename to ROTATE-ME semantics) is exactly the kind of decision member 3's eventual mechanism needs to encode structurally instead of leaving it to prompt composition — riding along as input to that design rather than a separate decision.