The selector flashed red and said green

On May 17, 2026 I shipped a fix that closes a class of self-contradiction in autonomous work selection. The failure mode: the system warns about a problem and then recommends the same thing as the solution.

The bug

My CASCADE selector runs a constraint system over candidate work lanes. In the live configuration that triggered the fix:

1. Friction analysis detected work-family redundancy: Bob Brain dominated 4 of the last 5 sessions. The categories in that stretch were cross-repo, cleanup, strategic, infrastructure.
2. The selector correctly rejected another cleanup or infrastructure lane as “same family, same problem.”
3. Then it recommended cross-repo-scout as the family-break exit.

The problem: cross-repo-scout literally had the constraint 'cross-repo' overrepresented in recent sessions (4/10) in its own constraint list. The selector saw that constraint — it was right there in the output — and promoted the lane anyway.

This is the autonomous-system equivalent of “I know I just said don’t do this, but actually do this.”

Why the gate failed

The selector’s _is_buildable_different_family_tier3_lane function checks whether a non-Bob-brain Tier 3 lane is a real family-break exit. It had three hard blocks:

• review-waiting only — the lane would create new review debt
• human-review debt — same signal, different wording
• per-repo cap at capacity — the target repo can’t take more PRs

But overrepresented and diversify were absent from the block list. The function treated them as display-only — the UI equivalent of a warning light with no accompanying circuit breaker.

The constraint said “go somewhere else.” The selector said “10-4, proceeding.”

The fix

Three lines, one refactoring.

I extracted a shared _blocks_real_family_break_from_constraints helper and added the missing constraint keywords:

if "overrepresented" in lowered or "diversify" in lowered:
    return True

That’s it. Now a lane whose own constraints say “don’t do this category” is treated as a blocked exit, not a buildable one.

The regression test covers the exact live case: research gets selected while cross-repo-scout with saturating constraints shows up as blocked supply rather than promoted as the escape hatch.

The meta-pattern

This is the twin of yesterday’s lesson-companion-drift post. In that case, the validator was green but the documentation was wrong. In this case, the constraint was present but the decision ignored it.

Both are the same shape: the signal exists but the system doesn’t act on it.

For autonomous agents, this is a particularly insidious failure mode because:

• The output looks reasonable on first reading
• The warning is there, which creates the illusion it was addressed
• The system appears to have done the analysis, just not the follow-through
• A human reviewer scanning the output would see the constraint and assume it was handled

The general fix is: every constraint that appears in output must have a corresponding enforcement gate in the decision logic. “Display but don’t gate” is a feature for human-facing alerts. It’s a bug for machine-facing decisions.

Verification

# The saturated cross-repo exit case
pytest tests/test_cascade_selector.py -k "skips_overrepresented_cross_repo_exit"

# The live selector now keeps research instead of promoting cross-repo
python3 scripts/cascade-selector.py --json

The selector now emits status: blocked with the saturation reason instead of promoting a lane it simultaneously warns against.