Red-team routing state is tier-only: a recorded "next visit is not a finder" verdict cannot gate dispatch, and area 13 is next in rotation

[ms609]

Found by the 2026-08-04 area-12 round (red-team process meta-review, sonnet). Three related
gaps in the /red-team orchestration, all in the user-level shared skill
~/.claude/skills/red-team/SKILL.md — so the fix is the maintainer's call, not a fixer's, and
it affects every project that inherits the skill. Filed rather than logged because the next
area-12 round is ~13 rotations away.

1. The routing state is tier-only, and a recorded work-shape verdict cannot gate dispatch

Normal run step 3 decides exactly one thing: the tier. Step 5 then says "Launch one
finder via the Agent tool", unconditionally. There is no branch for "the last round on this
area concluded that the next visit should not be a finder at all."

Two areas now carry precisely that verdict:

• Area 13, log.md 2026-07-03: "NEXT VISIT: NOT another finder — a BOUNDED EXHAUSTIVE
  HARNESS" (the topology_spr / build_postorder-guard equivalence). Mirrored in
  escalation-backlog.md under "Not in this backlog (deliberately)".
• Area 10, log.md 2026-08-03: "The next visit should NOT be a finder" — what is owed is
  a wall-matched A/B of the fix shapes on a ≥25-tip hierarchy-heavy matrix, Hamilton-class.

This is live, not hypothetical: rotation reaches area 13 next round (last_focus: 12 after
the current round, (12 mod 13) + 1 = 13). Absent intervention the next /red-team invocation
dispatches a finder against a standing verdict not to.

The verdict is not missing from the data — step 4 reads the log.md entries that contain it.
The gap is that nothing gates step 5 on what step 4 read. So a new focus-areas.md column
would not fix it; it would add a second place to look with the same failure mode. This round
applied the only project-local mitigation available — rewriting area 13's maturity rationale so
the verdict is unmissable at step 1 — but that relies on the orchestrator choosing to honour
prose.

Proposed fix (shared file): one gate between steps 4 and 5 — if the most recent log.md
entry for this area records an explicit non-finder work-shape verdict, stop and report it to the
user instead of auto-dispatching.

2. needs-escalation is a tier flag, and mis-encoding a non-tier ask into it is harmful

escalation-backlog.md admits two classes of residual: version-bump reopenings (ask = more
capability) and cross-area-routed residuals (ask = someone else should look). The skill's
Escalation tracking rule — "promote it to a label the moment it gets filed as an issue" — is
written about the first class but reads unconditionally.

This round's finder applied it to the second class, labelling #18 and #19 needs-escalation
because backlog item 7 names them. The orchestrator reverted both the same round. Item 7's
own text says "The ask is a sequencing decision, not a review" — harness first, or #18/#19
first. Two reasons the label was worse than nothing:

1. It encodes only "dispatch at opus+". Area 13's start_tier is already opus, so it
   changed no decision.
2. Step 3's label branch reads: "if non-empty, dispatch this round at opus (or higher)
   regardless of start_tier/last yield, no further reading needed for this check." A label
   hit therefore suppresses reading the backlog row that holds the actual ask. Labelling
   converts a sequencing question into a tier answer and then hides the question.

Note the shape: gaps 1 and 2 are the same defect seen twice. Every non-tier verdict the rotation
produces — work-shape, sequencing — has no channel that routing reads, so it is either ignored
or laundered through the tier channel.

Proposed fix (shared file): scope the promote-to-label rule to escalation-class residuals
explicitly, and say that a cross-area-routed residual stays prose.

3. The finder brief template never includes the area's own open issues

The Briefs template has exactly three sections — Files in scope, Key questions,
Prior rounds on this area (1–3 log.md entries). There is no
gh issue list --label area:N --state open anywhere in it.

So a fresh finder can spend its whole budget re-investigating a mechanism an open issue already
describes in full. The only current safety net is the anti-duplication keyword search at
filing time, which prevents a duplicate filing, not duplicate investigation. That has
already happened once: log.md's duplication-catch note for the 2026-08-04 round records a
verifier independently rediscovering T-400 (now #16) and requesting a fresh id.

Proposed fix (shared file): add the area's open-issue titles to the brief template.

Residue from a refuted candidate — area:N label semantics are undocumented

The finder claimed the area:N labels are applied inconsistently, citing #18 (area:9,
area:13) as found by the area-11 round yet not labelled area:11, against #19 (area:11,
area:13) from the same round.

Refuted. The labels encode which area owns the code, not which round found it. #18's
mechanism is the tree = / startEdge boundary plus Wagner retry and constraint handling →
areas 9 and 13. #19's is collapse versus constraint → areas 11 and 13. Both are correct and
mutually consistent under "owned by".

What survives is narrow: nothing states that convention, and it matters, because rotation
and anti-duplication are both per-area — 10 of 24 open issues carry two area: labels. Verified
separately this round that the compound query --label needs-escalation,area:N ANDs correctly,
so a multi-labelled issue is visible to each of its areas; that mechanism is sound but equally
undocumented. One line in the label table settles both.