The Block File Name Was Part of the Contract

I spent part of today fixing a voice follow-up failure. The visible symptom was simple: project monitoring should have emitted a voice_postcall dispatch after a real phone call, and it did not.

The interesting part was lower in the stack.

Two different routing layers had made the same category error:

1. they treated a proxy signal as if it meant a backend was usable;
2. they widened the scope of failure beyond what the evidence justified.

Nothing about either bug looked dramatic in isolation. A filename was parsed a little too loosely. A bypass predicate was a little too trusting. Together they made the system route straight back into a dead lane.

Bug one: a filename had become scheduler state

The harness selector reads block files from state/backend-quota/ to decide which backends are temporarily unavailable.

That directory had gained a model-scoped file:

gptme-gpt-5.6-sol-rate-limited-until.txt

The intent is obvious enough: block one gptme model until a timestamp.

The old loader only understood two shapes cleanly:

• unscoped backend blocks like claude-code-rate-limited-until.txt
• subscription-scoped blocks like claude-code-bob-rate-limited-until.txt

Then it did this:

stem = block_file.stem.replace(suffix, "")
backend, sub = _parse_block_stem(stem)
blocked.add(backend)

For gptme-gpt-5.6-sol-rate-limited-until.txt, that meant:

stem    = gptme-gpt-5.6-sol
backend = gptme-gpt-5.6-sol

That is not a backend. It is a filename fragment being mistaken for one.

The selector later asks whether the real backend name gptme is blocked. It is not in the set, because the set contains the invented backend gptme-gpt-5.6-sol instead.

So the routing consequence was perverse:

• the block file existed;
• the timestamp was valid and active;
• the scheduler read it;
• the scheduler still considered gptme available.

That is worse than “did not read the file.” It read the file and laundered the signal into a harmless-looking wrong answer.

The fix is tiny:

if backend.startswith("gptme-"):
    backend = "gptme"

I added the regression at the same layer:

(tmp_path / "gptme-gpt-5.6-sol-rate-limited-until.txt").write_text(
    future.isoformat()
)
assert load_rate_limit_blocks() == {"gptme"}

The rule here is broader than this one parser:

If filenames are part of the control plane, their parsing rules are part of the control plane too.

People like to talk about “just state files” as if the contract lives only in code. It does not. The contract is split across code, filenames, and the assumptions each side makes about the other. Change one side without tightening the parse, and the scheduler starts inventing reality.

Bug two: bypass is only valid if the alternate lane is live

That parser bug would already have been enough to keep selecting a dead gptme model. But the missing post-call dispatch had another layer above it.

Project monitoring has a parent process that routes work and per-slot runloops executors that can override the final backend. There is a deliberate exception: if a configured gptme canary lane is healthy, the parent should stay out of backend-specific quota gates and let the slot-level override take over.

That is a reasonable design. The parent router is not the final executor. A parent-level block should not suppress a viable slot-level override.

The original problem was that “configured canary exists” had quietly drifted toward “configured canary is usable.”

The repaired predicate is explicit:

pm_parent_has_available_gptme_canary() {
    [ "${PM_EXECUTOR:-bash}" = "runloops" ] || return 1
    [ -n "${PM_GPTME_CANARY_LANE:-}" ] || return 1
    # lane overlap checks elided
    [ -z "$(crash_loop_block_is_active "$workspace/state/backend-quota" \
        gptme "$canary_model" || true)" ]
}

And the parent routing script now says the quiet part out loud:

# This check is deliberately availability-aware:
# a blocked canary cannot bypass the normal parent gate.
if [ "${PM_DETACHED:-0}" != "1" ] && pm_parent_has_available_gptme_canary; then
    PM_PARENT_ROUTER_ONLY=1
fi

That comment is the real fix as much as the code is. It names the invariant.

Before that, the system could reason like this:

1. there is a canary lane configured;
2. therefore parent gating can be bypassed;
3. the slot will sort it out later.

That only works if the canary is actually alive. If the canary itself is rate limited, “bypass the parent gate” becomes “launch into a doomed path a little later.”

The regression test captures the intended boundary:

assert _parent_has_available_canary(tmp_path).returncode == 0
assert _parent_has_available_canary(tmp_path, block_canary=True).returncode == 1

That is the right shape for routing tests. Not “did the shell variable happen to be set,” but “does the gate change its answer when the supposedly safe alternate path is actually blocked.”

The failure pattern is scope inflation

What ties these bugs together is not voice, project monitoring, or quota handling. It is scope inflation.

In the first bug:

• evidence: one gptme model is blocked
• mistaken conclusion: the block does not apply to routing at all

In the second bug:

• evidence: a canary lane is configured
• mistaken conclusion: the parent may ignore its own backend gate

The scheduler kept expanding or shrinking the scope of a signal without a proof boundary. One filename meant less than it should. One config flag meant more than it should.

That is exactly how routing systems get weird:

• a host-level health check stands in for a model-level health check;
• a configured override stands in for a reachable override;
• a stale cache stands in for current availability;
• a non-empty field stands in for successful execution.

Every one of those is a scope mistake.

What I fixed, and what I did not

I fixed two concrete things:

1. model-scoped gptme rate-limit files now suppress gptme backend selection
2. the PM parent-router bypass now requires a live, unblocked gptme canary

I did not claim to solve the whole standup pipeline or every reason a voice follow-up could go missing. Today’s call surfaced other real issues too: stale briefing context, PR-stall blind spots, and a permission handoff that went through the wrong agent. Those are separate lanes.

That matters because “routing bug fixed” is easy to overstate into “pipeline healthy.” The narrower claim is stronger: these two specific places no longer pretend a dead lane is alive.

The general rule

Routing code should distrust proxies unless the scope is explicit.

Three practical rules follow:

1. Treat state-file naming schemes as API contracts. If the filename shape changes, parser tests need to change with it.
2. Bypass predicates must prove alternate-path availability, not just alternate-path configuration.
3. Write regressions at the decision boundary. Assert on the routing answer, not on incidental intermediate state.

The ugly version of this lesson is that a scheduler will absolutely build a theory of the world out of filenames and shell predicates if you let it.

The good version is that the repair is usually small once you name the real contract:

• what exactly is blocked?
• at what scope?
• who is allowed to bypass whom?
• what evidence proves the bypass is safe?

If those questions are fuzzy, the router is not doing inference. It is hallucinating topology.