RT 2026-08-04 - area 12 - sonnet (Sonnet 5) - yield 2

[ms609-agent]

sonnet (Sonnet 5) | effort: unrecorded | 2026-08-04

Migrated record. This round predates the move to Discussions; it is reproduced
verbatim below from dev/red-team/log.md, which is now closed to new entries. It is
posted here so this area has a round record whose createdAt orders correctly against
the other areas' — the backfill ran oldest-first for that reason. All fourteen posting
timestamps are later than the rounds they describe; the real date is in the title and
in the date: field.

---

area: 12 (Red-team process meta-review)
reviewed_by: sonnet finder ac1757d5 + haiku verifier aacdbbbb (3 low-sev) + orchestrator mechanical verification (scope-row diffs, label semantics, symbol-registration trace)
date: 2026-08-04
tier: sonnet (Sonnet 5)
yield: 2 filed (#41 routing channel, #42 scope coverage) + 10 doc corrections applied inline + 1 false-and-hazardous source comment corrected, from 8 candidates; 1 half-refuted (area:N label "inconsistency"); 1 inverted on verification (rearrange.cpp); and 1 finder ACTION reverted
notes: Rotation (11 mod 13) + 1 = 12. Legend reconciled at round start -- no rung has moved since 2026-07-27, so no version-bump re-eligibility fired and escalation-backlog.md reopened nothing. Last visit (2026-07-03) yielded -> stayed at sonnet with a fresh agent per the yielding-seam rule; the within-rung 4.6 -> 5 bump is incidental, not the reason. No needs-escalation label on any issue, area 12 included. Verification was mostly orchestrator-mechanical rather than a verifier pass, deliberately: almost every candidate reduced to "is file X in any scope row" or "is symbol Y registered", which a verifier would answer by re-running the same greps. A haiku batch took the three claims that rested on a file's self-description, which is exactly where a grep is not evidence.

THE HEADLINE IS AN ACTION THE FINDER TOOK, NOT A CLAIM IT MADE -- and it is the round's most reusable result. Following the skill's Escalation tracking rule ("promote it to a label the moment it gets filed as an issue"), the finder labelled #18 and #19 needs-escalation because escalation-backlog.md item 7 names them. The orchestrator reverted both the same round (verified zero issues now carry the label, restoring the pre-round state). The rule is written about the class where the ask is more capability -- a high-severity finding a finder could not pin down. Item 7 is the other class the file admits, a cross-area-routed residual, and its own text says "The ask is a sequencing decision, not a review." Two harms, the second the real one: (i) needs-escalation encodes only "dispatch at opus+", and area 13's start_tier is already opus, so it changed no decision; (ii) step 3's label branch reads "if non-empty, dispatch at opus regardless, no further reading needed for this check" -- so a label hit suppresses reading the backlog row that holds the actual ask. Labelling converted a sequencing question into a tier answer and then hid the question. Generalised and filed as #41: the rotation's routing state is TIER-ONLY. There is no channel for a non-tier verdict, and two distinct ones are now on record -- item 7's sequencing ask, and the work-shape verdicts of areas 10 and 13. Mis-encoding either into the tier channel is worse than leaving it in prose, because prose is at least read as prose.

AREA 13 IS NEXT IN ROTATION AND CARRIES A STANDING "NOT A FINDER" VERDICT. (12 mod 13) + 1 = 13, and area 13's 2026-07-03 entry closed with "NEXT VISIT: NOT another finder -- a BOUNDED EXHAUSTIVE HARNESS" on the topology_spr/build_postorder-guard equivalence. Normal run step 4 reads the entry containing that verdict and step 5 then launches a finder unconditionally -- the gap is that nothing gates step 5 on what step 4 read, which is why #41 proposes a step-4.5 gate rather than a new focus-areas.md column (a column would add a second place to look with the same failure mode). Only project-local mitigation available was applied: area 13's maturity rationale was rewritten so the verdict is unmissable at step 1. Whoever dispatches area 13 must also decide harness-first vs #18/#19-first and record why -- the harness plan predates both findings. Area 10 carries the same shape of verdict (a wall-matched Hamilton-class A/B, 2026-08-03).

THE COVERAGE DIFF THAT WAS FLAGGED ON 2026-07-03 AND NEVER RUN IS NOW RUN -- and the bill for the delay had already been paid twice. The 2026-07-03 round wrote that it had only diffed src/*, and flagged R/*.R for a future round. In the month that followed, the 2026-08-03 area-10 round filed three findings in two R/*.R files owned by no scope row (one of which the 2026-07-03 round had itself named as unowned), and escalation-backlog.md item 5(a) recorded TreeLength/MinimumLength/CharacterLength as unowned while #16 (sev:high) is a TreeLength() OOB-write bug. Filed as #42. Two subsystems, mechanically confirmed absent from all 13 rows: the statistics / support-metrics cluster (5,553 loc, 14 files, headed by src/MaddisonSlatkin.cpp at 1786 -- which already carried a real bug while unowned, the arm64 probe_slot() hang of PR ms609#272) -> proposed as new area 14 at start_tier: opus; and the legacy pure-R search API (2,183 loc, 9 files, R/CustomSearch.R etc.) -> placement decision, urgent because #16's own body names EdgeListScore() as "the default TreeScorer for TreeSearch()/Ratchet()/Jackknife()", making this family a second unreviewed exposure surface for a confirmed sev:high bug. Both are restructuring decisions (a new row changes N in the rotation formula and needs an area:N label), so proposed not enacted. 17 files were added to existing rows 1/2/4/5/6 inline, area 7 extended to the Shiny app's own tests, and area 8's glob broadened from test-ts-*.R to tests/testthat/*.R -- it had been excluding ~44 of ~110 test files. Every addition annotated UNMEASURED / no inherited maturity, per this area's own standing lesson that a scope row which grows does not inherit the dry verdicts earned before it grew. Methodology gotcha worth keeping: glob R/*.[Rr], not R/*.R -- R/pp_info_extra_step.r has a lowercase extension and is silently skipped, which bit this round's own diff before the finder caught it.

ONE CANDIDATE INVERTED ON VERIFICATION, AND THE ORCHESTRATOR'S OWN FIRST CHECK WAS THE WRONG ONE. src/rearrange.cpp was filed as "643 lines of dead code, still compiled" on the strength of its own header: "no functions are exported or called ... Safe to remove." The haiku verifier refuted it; the orchestrator confirmed the verifier was right. All [[Rcpp::export]] tags are indeed commented out, but src/RcppExports.cpp and src/TreeSearch-init.c were never regenerated afterwards, so _TreeSearch_nni/_TreeSearch_spr/_TreeSearch_spr_moves persist, are declared and registered in the callMethods table (TreeSearch-init.c:11-13, :66-69), are bound at R/RcppExports.R:60-68, and are exercised by three test files (test-NNI.R, test-zzz-tree-rearrange.R, test-rearrange.cpp.R via all_spr). Only tbr_moves is genuinely unexported. The header was actively hazardous -- acting on its "safe to remove" breaks three test files and leaves dangling registrations -- so it was corrected inline, not filed. Two lessons. A file's self-description is not evidence about the file; the tags and the generated registrations can disagree indefinitely because nothing re-checks them. And the orchestrator's initial grep -rn "rearrange" src/TreeSearch-init.c returned nothing and looked like corroboration -- it was testing for the filename in a file that only ever names symbols. Grep for what the artifact would actually contain.

THE VERIFIER RETURNED 3 x REFUTED AND ONLY ONE WAS A REFUTATION -- check a verdict against what the finding actually claimed. RT12-13 claimed ts_temper.cpp is unowned and that its reachability was unclear; the verifier refuted "unreachable" -- a claim not made -- while its evidence resolved the open question (no preset or effort rung sets annealCycles > 0; live via explicit user control through ts_driven.cpp:505 -> anneal_search() at ts_temper.cpp:420 -> stochastic_tbr_phase). RT12-14 claimed R/ImposeConstraint.R is 0 bytes and Collate:-listed, both true and undisputed; the verifier refuted "is a bug", also not the claim, and usefully added provenance (added by 78b74147, a commit about TBR test guards, so an accidental artifact -- cleanup is to drop DESCRIPTION:104 and delete the file). Both coverage claims survive; both went into #42 as verified residuals. Only RT12-15 was a genuine refutation.

RT12-10 HALF-REFUTED. The claim was that 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. 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 correct and mutually consistent. What survives is only that the convention is unwritten while 10 of 24 open issues carry two area: labels -- folded into #41. Separately verified that --label needs-escalation,area:N ANDs correctly, so a multi-labelled issue is visible to each of its areas; sound but equally undocumented.

Also corrected inline: README.md's hand-kept severity breakdown read 6/5/13 against a true 6/4/14 -- it had drifted within the same round it was written, two lines above the file's own instruction not to maintain it by hand -- replaced with a jq query; the undocumented gh label create area:N dependency when a row is added; a missing migration-map-todo.tsv row; and the "NEVER REVIEWED" rationales on areas 12 and 13, both stale since rounds had already run (area 13's since 2026-07-02, through two rounds that reviewed it).

Area 3 (RT12-02, carried from 2026-07-03): no new evidence, nothing to re-raise. Its retire/downtier question remains gated on an Opus 5 pass that has not run (last visit 2026-07-24, dry at opus-4.8), and three of its four dry rounds are pre-tier and version-unrecorded, so only one counts toward the dormancy bar. Not reached: whether any future per-area count consumer double-counts a multi-area:N issue (checked the one place multi-labelling is load-bearing today -- the escalation query -- and it is fine); the visualization -> area 7 and infra -> area 6 placement proposals, both low confidence and left in #42. Seam status: STILL YIELDING -- 2 of 2 rounds have produced structural findings, so the next visit stays sonnet with a fresh agent.