fix(rate-limit-guard): fail-open downgrade is whole-guard where the reader contract is per-window

[kyle-sexton]

The three lane skills inline the rate-limit-guard fail-open rule as a whole-guard downgrade:

• plugins/work-items/skills/work-loop/SKILL.md:137
• plugins/work-items/skills/attend-queue/SKILL.md:168
• plugins/source-control/skills/babysit-loop/SKILL.md:428

All three read "tee file absent, stale, missing rate_limits, or absurd values → mode unknown → reactive-only", which collapses the guard wholesale as soon as any value is absurd.

The reader contract is per-window:

• plugins/rate-limit-guard/reference/reader-contract.md:46-49 — rate_limits "is present only when the session observes subscription windows; each window may be independently absent".
• :67-70 — an absurd used_percentage or resets_at "makes that window unknown".

Combined with the operable floor's "pause when either window reports used_percentage >= 90", the correct behavior when one window is absurd and the other is valid at, say, 95% is to pause on the valid window — not to drop to reactive-only and keep working until a reactive failure lands. The current wording produces the second outcome.

Note the reader contract is itself internally inconsistent and should be fixed in the same pass: its mode table at :62-65 lists "absurd values" as a whole-guard unknown → reactive-only row, while the prose immediately below scopes absurdity to a single window. The table is the line the three skills copied.

Wanted:

1. Reconcile reader-contract.md's mode table with its own per-window prose — absent / stale / missing rate_limits are whole-guard; absurd values are per-window.
2. Update the three lane skills to classify validity per window, keep applying the floor to every still-plausible window, and fall to reactive-only only when no window is plausible.

Found while reviewing #1582's burn-down prompt. prompts/loops/loop-lane-prompts.md was corrected to the per-window form in PR #1594, so until this lands, that prompt and the three skills deliberately differ — the difference is recorded in that file's "Known gaps" section.

[kyle-sexton]

🤖 Released by autonomous babysit lane (fable-autopilot). Fixed in #1618, merged as fecbc78 (squash). The reader contract's mode table now carries a Scope column splitting whole-guard triggers from per-window ones, the three lane skills classify per window and stay byte-identical, and the now-false "Known gaps" divergence note in prompts/loops/loop-lane-prompts.md is removed.

[kyle-sexton]

This was generated by AI during triage.

Triage: verified

Confirmed by reading the cited surfaces at origin/main (the local checkout was behind; verification was done against the fetched remote tip, not the stale working tree):

• The rate-limit-guard reader contract's capability-detection mode table puts "absurd values" in the same row as an absent tee file, a stale tee file, and a missing rate_limits key, all mapping to whole-guard unknown → reactive-only.
• The prose directly beneath that table scopes an implausible used_percentage or resets_at to "that window", and the tee-file-shape section states the rate_limits key is present only when the session observes subscription windows and that each window may be independently absent. The contract contradicts itself.
• All three lane skills — the work-items worker lane, the work-items attended queue, and the source-control merge lane — inline the table's whole-guard wording verbatim ("tee file absent, stale, missing rate_limits, or absurd values → mode unknown → reactive-only").
• The loop-lane prompts file already carries the corrected per-window form and records the divergence in its "Known gaps" section, explicitly as deliberate until this lands — so that entry is a fifth surface this fix must retire, not just context.

Failure mode is real and operational: with the operable floor's "pause when either window reports used_percentage >= 90", one implausible window plus one valid window at 95% currently yields reactive-only — the lane keeps claiming work until a reactive rate-limit failure lands, instead of pausing on the window it can trust.

Category: bug (documented contract contradicts itself; consumers copied the wrong side).

Not routed as a T1 multi-surface stub despite the uniform fix pattern across four files: this repository's runtime-surface boundary treats every tracked Markdown file as behavior-loaded, and the rule being edited decides whether an autonomous lane pauses. That is not trivial, so it gets a full brief.

Agent Brief

Type: Bug
Summary: Fail-open capability detection is stated as a whole-guard downgrade in the rate-limit-guard reader contract's mode table and in the three lane skills that copied it, while the same contract's prose scopes an implausible value to a single window.

Current behavior:
Any implausible window value collapses the entire guard to reactive-only. A lane therefore stops throttling proactively even when a second, fully plausible window is already at or above the pause threshold, and keeps working until a reactive rate-limit failure interrupts it.

Desired behavior:
Validity is classified per window.

• Whole-guard downgrade to reactive-only, unchanged: tee file absent; tee file stale by the staleness rule; the rate_limits key missing entirely.
• Per-window downgrade: an implausible used_percentage (outside 0–100, or non-numeric) or an implausible resets_at (non-numeric, too far in the future, or already past by more than the staleness window) makes that window unknown and leaves every other window intact.
• The operable floor keeps being applied to every still-plausible window; a still-plausible window at or above the pause threshold trips the pause.
• Reactive-only is reached only when no window is plausible.
• Pause-end selection is unchanged: the tripped window's reset time, or the later reset time when both windows trip.
• The fail-open principle is unchanged — never throttle on data that cannot be trusted, never fabricate a pause. It is now scoped per window rather than applied wholesale.

Key interfaces:

• The reader contract's "Capability detection (fail-open)" section — its mode table and the prose immediately below it must state one rule, with the table carrying the whole-guard/per-window split explicitly rather than merging the two into one row.
• The inlined "Fail-open capability detection" rule in each of the three lane skills — the worker lane, the attended queue, and the merge lane — restated in the corrected per-window form.
• The loop-lane prompts file's already-corrected per-window block — the reference wording the three skills should converge on, so all five surfaces read the same.

Acceptance criteria:

• The reader contract's mode table and its adjacent prose no longer contradict each other: absent / stale / missing-rate_limits are whole-guard rows; implausible values are stated as per-window.
• Each of the three lane skills states, in its inlined rule: per-window validity classification, floor application to every still-plausible window, and reactive-only only when no window is plausible.
• The wording across the reader contract, the three lane skills, and the loop-lane prompts block is mutually consistent — a reader of any one of them derives the same behavior.
• The "Known gaps" entry in the loop-lane prompts recording this prompts-vs-skills divergence is retired in the same change; leaving it in place makes that file assert a divergence that no longer exists.
• Markdown lint passes on every changed file.

Out of scope:

• The staleness threshold, the pause threshold, and drain-then-pause behavior.
• The tee file's schema and the untrusted-field parsing rule.
• The account-rotation gap (the tee file carries no account identifier) — separately recorded.
• The rate-limit latch and the adaptive cap's ramp rule.

Coordination note

An active lane lease was on this item at triage time: an autonomous babysit lane (fable-autopilot) posted a claim marker expiring ~22:40Z, and a branch exists for it with no commits yet. The open PR that fixes the sibling finding explicitly states this item is not closed by it. Anything picking this up should check that lease and the branch before starting fresh work.

Labels applied

Bug (native issue type), priority: medium, agent-ready, status: ready; priority: needs-triage cleared. Delegable — the correct behavior is already fixed by the reader contract's own prose and demonstrated by the corrected loop-lane prompts block, so there is no open decision.

Role-label resolution warning: this repository's .work-item-tracker.json carries no config.role_labels entry, so the canonical roles fell back to their documented defaults (agent-ready / needs-human). Both strings exist as labels here, so the fallback is correct — but it is a fallback, not a binding.