RT 2026-07-27 - area 7 - sonnet (Sonnet 5) - yield 7

[ms609-agent]

sonnet (Sonnet 5) | effort: unrecorded | 2026-07-27

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: 7 (Shiny module wiring — EasyTrees, inst/Parsimony/)
reviewed_by: sonnet finder (a2ad2c91, 229k tokens / 53 tool-uses / 1463s) + opus peer verifier (af2fad95, 2 medium+ rows) + haiku verifier (a7c2f411, 7-row low-sev batch) + orchestrator (fix-status reconciliation, scope-row repair)
date: 2026-07-27
tier: sonnet (Sonnet 5)
yield: 7 open (T-354 P2; T-355/T-356/T-357/T-358/T-359/T-360 P3) + 1 filed-and-closed (T-361, verified inert, kept as anti-dup) out of 9 candidates; 1 REFUTED in verification (S7-F), 3 hypotheses self-refuted by the finder with evidence
notes: ROUTING. last_focus: 6 → (6 mod 13)+1 = 7, the organic next area (the 2026-07-27 directed diff round below deliberately left the pointer at 6). Legend reconciled at round start per the Model versions rule: aliases now resolve to Sonnet 5 / Opus 5 / Fable 5 / Haiku 4.5, all already in the legend from the same-day bump, so no new rung movement and nothing new reopened into escalation-backlog.md. Area 7's last visit (2026-06-16, sonnet (Sonnet 4.6)) YIELDED 5 → re-visit at the same rung with a fresh agent; the 4.6→5 bump agrees with that routing rather than competing with it.

THE ROUND'S SHAPE WAS DECIDED BY ONE DATE-FILTERED COMMAND (git log --since=2026-06-16 -- inst/Parsimony/) — worth repeating before any future area-7 round. Since the last visit the ONLY non-test source changes in inst/Parsimony/ are the MorphyLib removal's footprint: 4 lines deleted from global.R, 4 deleted / 1 added in mod_references.R (cf9f19b3), plus a stop-note string in global.R (93adda76). Everything else is tests/snapshots. So server.R and mod_search.R are byte-identical to what the 2026-06-16 round already mined, and the never-opened modules were the entire new surface. The finder was briefed accordingly and told to treat the two mined files as read-only context. (The suspicion that a 4-line deletion is a light footprint for deleting an entire scoring library was checked and came back clean — no removed/renamed/deprecated TreeSearch function is still called from the app.)

⚠ FINDINGS.MD WAS STALE — T-309…T-313 WERE ALL LISTED OPEN AND ARE ALL FIXED. The finder flagged the discrepancy; the orchestrator confirmed every one by source inspection at tip: T-309 got both halves of the recommended fix (profilePrepHash snapshot-at-invoke stamped at mod_search.R:449, plus clearing profileDataset/profileDataHash/profilePrepHash on dataset change at :1176-1182), T-310 the if (isTRUE(r$searchInProgress)) return(invisible()) guard at :663, T-311 the session$onSessionEnded cancel-file write at :594-602, T-312 the ^ts_(cancel|progress|profile_prog|profile_cancel)_ unlink at server.R:195-200, T-313 the strip-branch-lengths dedup key at :1095-1104. All landed in 78b74147 (2026-06-19), three days after the round that filed them; nothing ever flipped their status. Rows annotated FIXED (78b74147) — awaiting tidy archive rather than moved, since archiving is tidy's job. This drift cost real tokens: the finder brief asserted they were open, so the finder spent effort rediscovering otherwise. A tidy pass is overdue (last one 2026-07-13; the skill's cadence is ~10 rounds). Open-count for that pass, so it is not read off a stale number: findings.md now carries 41 T- rows, of which 5 are annotated fixed (T-309…T-313, awaiting archive) and 1 is filed-closed (T-361, verified inert) ⇒ 35 genuinely open. That is well under the skill's ~150-open backlog threshold, so the trigger for tidy here is status drift and the missing findings-archive.md, not volume.

SCOPE ROW WAS ALSO STALE — REPAIRED THIS ROUND. focus-areas.md row 7 named a phantom inst/Parsimony/server/events.R (no such file exists) while its server/mod_*.R glob omitted global.R (430), ui.R (110), app_state.R (78) and logging.R (233) — ~850 real lines no area owned. Combined with the 2026-06-16 round having read only server.R + mod_search.R, roughly 4000 lines of this area had never been opened at any tier. Row corrected + a note added to the tier rationale. Three of this round's eight findings (T-357 in ui.R, T-360/T-361 reaching global.R/logging.R) sit in files the old row did not name — i.e. the phantom-file scope row was actively suppressing yield.

THE HEADLINE — T-354 (P2), confirmed by a COMMITTED ARTIFACT rather than by tracing. EasyTrees writes two logs of the same tree-thinning step and they disagree: mod_data.R:202-206 correctly records WideSample(allTrees[a:b], n) into the "Save log" download, while BeginLogP() (logging.R:155-161, feeding the "R script" / savePlotZip download) emits naive stride sampling trees[unique(as.integer(seq.int(a, b, length.out = n)))]. The opus verifier found the proof already committed to the repo: inst/Parsimony/tests/testthat/_snaps/Distribution/Distribution-001-ClusterCons.zip:50 — a currently-passing snapshot of the real download (test mode writes the script as plain text under a .zip extension) — literally contains trees <- trees[unique(as.integer(seq.int(1, 125, length.out = 48)))] for a run where the app executed WideSample(allTrees[1:125], 48). Measured divergence on Sun2018: overlap 19 of 48, and min pairwise ClusteringInfoDistance 0 for stride vs 8.9149 for WideSample — the stride subset contains duplicate topologies, exactly what the MMDP solver exists to prevent. Not display-only, which is what carried it to P2: the snapshot's own downstream lines run ClusteringInfoDistance → KMeansPP/pam/protoclust with silhouette-based k selection → ConsensusWithout(), so the wrong 48 trees change reported numbers and reported topologies. Fires on the default path for any tree set >48 (aFewTrees <- 48L, global.R:96). Fix must also regenerate that snapshot — it is the only one carrying the line, because test-Distribution.R:20 sets nTree = 125 and moves every later snapshot onto the identity branch.

T-355 downgraded medium → P3 by the verifier, and the downgrade is the useful part. mod_treespace.R:76 really is the one r$trees <- site with no paired r$treeHash <- (writer list confirmed complete by grep: hash writes only at mod_data.R:186,210,637), and the write really lands — plain [ on a multiPhylo drops the firstHit attribute, so shiny 1.13.0's identical()-based .dedupe in ReactiveValues$set does not suppress it. But no consumer can serve a wrong cached value (WhenFirstHit() adds only an attribute; the "space" cache key includes TreeCols()/ts_spaceCol() so switching colour mode re-keys anyway), and reachability is narrow — the mutation needs tree names matching (seed|start|ratch\d+|final)_\d+, and no in-package producer of those names or of the firstHit attribute exists in R/ or src/, so it fires only for externally-named legacy tree files. Latent invariant break, not a live bug.

RULED OUT WITH EVIDENCE — do not re-litigate. (i) output$pcQuality stale-promise race: the finder suspected future_promise() %...>% QualityPlot could let a slower, staler promise overwrite a fresher one, then built a shiny::testServer reproduction with two overlapping renders and distinguishable content — Shiny correctly discarded the stale render under both renderPlot and renderCachedPlot with the app's real sizePolicy. This class of bug does not occur here. (ii) sizePolicy = function(dims) dims (mod_treespace.R:752) looked like a wrong-arity signature against ?renderCachedPlot's prose, but shiny::sizeGrowthRatio really takes one 2-element vector — the doc prose is imprecise, both app usages are correct. (iii) EnC(a, b) multi-argument crash: EnC does error on 2+ positional arguments, but every call site in the app is single-argument — unreachable. (iv) S7-F, numericInput(min = 3L, max = 2L) at mod_consensus.R:93-94: REFUTED — the control is hidden inside consConfig until trees load, and UpdateKeepNTipsRange() (:1236-1253) overwrites min/max/value via updateNumericInput before it can ever be seen. (v) A cross-finding note from the opus verifier, recorded so it is not filed as a ninth finding: T-355's mutation also flips the !identical(r$trees, r$allTrees) gate at logging.R:155 on the otherwise-identity branch, but the line then emitted is seq.int(1, N, length.out = N) = 1:N, a harmless no-op.

COVERAGE — read this before the next area-7 round. Read in full: mod_consensus.R (1449), mod_treespace.R (776), mod_data.R (660), global.R (430), mod_clustering.R (294), logging.R (233), server.R (206), mod_downloads.R (182), ui.R (110), mod_references.R (93), app_state.R (78). Sampled only, NOT covered: mod_search.R (1214) — targeted reads around r$-write sites only (:375-390, 460-530, 580-620, 660-760, 880, 1030-1065). That file is now the single largest unreviewed block in the area: its own async/ExtendedTask logic, its ~10 distinct temp-file paths, and the r$searchDataHash/r$dataHash staleness guards at :673/:1061 have never had a full pass by any rotation round. The 2026-06-16 round read it, but only found the five bugs now fixed — it was not exhaustive.

METHOD NOTE. The five prior findings were handed to the finder as bug CLASSES to re-ask of every unreviewed file, not merely as a do-not-repeat list (stamped-at-completion vs snapshotted-at-invoke; missing re-entrancy guard where shinyjs::disable is an async round-trip; cleanup that doesn't signal the worker; cleanup patterns not matching the filenames actually created; identity keys that serialise more than the identity intended). Four of the eight findings are direct answers to those questions in new files — T-356 is the T-312 cleanup/naming class, T-359 the T-311 lifecycle class, T-354/T-360 the T-313 "key/record says something other than what happened" class. The pre-tier "clean" verdicts on cb_ref wiring and "cross-module updateXxxInput dead imports harmless" were also pasted in as claims to break; the latter covers mod_data.R, now read in full for the first time.

Seam status: STILL YIELDING (a P2 with committed-artifact proof plus 6×P3, in files never opened) → next area-7 visit stays at sonnet, and should target mod_search.R in full, which is the one genuinely uncovered block left. NEXT ROTATION AREA = 8 (Test suite health), last_focus: 7.

---