RT 2026-07-24 - area 6 - opus (Opus 4.8) + fable - yield 6

[ms609-agent]

opus (Opus 4.8) + fable | effort: unrecorded | 2026-07-24

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.

⚠ Scoped round. This was one of the 2026-07-24 directed passes over what was new in
MaximizeParsimony since the previous inspection — not the area's full file list. The
seam verdict it records is about that surface. Read the verdict in the notes rather
than inferring one from the yield in the title: a low number here can mean the new
code was clean, which says nothing about the parts of the area it never opened.

---

area: 6 (R ↔ C++ interface — DIRECTED round: dual-tier calibration, opus + fable in parallel on IDENTICAL fresh scope)
reviewed_by: opus finder (a35ac522) + fable finder (a955bb7f), launched in parallel with the identical brief and NEITHER told about the comparison (avoids priming); opus peer verifier (a48c7383, med-sev cluster) + haiku verifier (a8c021b8, low-sev batch)
date: 2026-07-24
tier: opus (Opus 4.8) + fable (version unconfirmed — not captured at dispatch) (USER-DIRECTED OVERRIDE — doctrine start_tier for area 6 is sonnet; this was NOT an organic escalation, so area 6's true sonnet-tier maturity is still unmeasured and the next organic visit should still start there unless explicitly overridden again)
yield: 6 filed — T-339 P2 (nThreads=0 dispatch), T-340 P2 (concavity string/case), T-341 P3, T-342 P3, T-343 P3, T-344 P3; 1 confirmed-benign not filed (A6-05, 4 enum params — REFUTED as a bug by both the finder's own trace and haiku); 1 trivial fix applied inline (timings roxygen doc, independently flagged by BOTH finders — added nni_ms/nni_perturb_ms/anneal_ms/prune_reinsert_ms)
notes: Orchestrated per explicit user request to (a) run finders as backgrounded Agent calls so the sonnet orchestrator's own context stays thin, and (b) empirically check whether fable regresses toward opus-like guardrail caution on adversarial-framed bug-hunting. Ran opus and fable on the SAME area-6 scope/brief in parallel (a deliberate one-off deviation from the "one finder" default — licensed by an explicit calibration ask, not a doctrine change). Calibration verdict: NO guardrail regression observed. Fable's report was exactly as technical, direct, and un-hedged as opus's — no disclaimers, no reframing away from "attack"-flavored framing (e.g. it happily traced the concavity-string bug as a silent-wrong-score exploit path). It found a genuinely DIFFERENT headline bug than opus (zero overlap on the two "med" rows — see below), and its own trace closed a cross-check opus's report had left open (confirmed parallel_driven_search's worker_thread still has its T-336-era per-worker ConstraintData copy at ts_parallel.cpp:558-562/651-655 — reaffirms, doesn't newly discover, since this was already cited as the area-4 fix's model). Cost note for future tier decisions (CORRECTED — orchestrator initially mis-stated this): doctrine assumes fable ≈2× opus cost per token; observed this round: opus 184,068 tokens/29 tool-uses/812s vs fable 185,852 tokens/18 tool-uses/1,005s — near-identical TOKEN COUNTS (fable +1%), but at fable's ~2× per-token rate that means this round's fable run cost roughly 2× opus in actual $, consistent with the doctrine's assumption, not contrary to it (token-count parity ≠ cost parity — conflating the two was the orchestrator's error, corrected same-session after user pushback). fable also took ~24% longer wall-clock on fewer tool calls. Post-round model-identity check: both finder agents were resumed and asked to self-report their exact model ID + awareness of any mid-task routing/fallback. opus → claude-opus-5[1m], fable → claude-fable-5 (both distinct, both matching what was requested; neither reported any awareness of a switch). This is real corroborating evidence against a guardrail-triggered reroute (rules out a trivial "harness always reports the same identity" failure mode) but is NOT dispositive — a self-report only reflects the client-side harness's system-prompt template, not a cryptographic attestation from Anthropic's serving stack; a lower-level API-side reroute would be invisible to it. The authoritative check (not available from within this session) is the Console usage/billing breakdown, which bills at the rate of whichever model actually served each call. Findings — two clusters, no overlap between opus and fable: opus's headline T-339 (P2): nThreads=0 is documented as "auto-detect cores" on both MaximizeParsimony() and Resample(), but the parallel dispatch gate at both Rcpp entry points (ts_rcpp.cpp:1843,2317) is if (nThreads > 1 ...), so 0 never reaches the auto-detect code one layer deeper (ts_parallel.cpp:283-288,618-622) — silently runs serial, no error; PLUS a second, currently-dead layer: the auto-detect impl itself doesn't implement the documented "cores minus one" even if it ran. Fails safe (correct trees, no parallelism) — functional/perf regression on a documented knob, relevant to Hamilton-style HPC invocations. Fable's headline T-340 (P2): MaximizeParsimony() never normalizes a character-valued concavity — concavity="10" (numeric string) silently produces uncorrected-homoplasy IW scores (is.finite("10")==FALSE skips min_steps population AND the EW-guard, but as.double("10") cleanly coerces with no warning, so C++ enters IW with all-zero min_steps); concavity="Profile"/"prof" (case-variant) silently falls back to EW instead (the search entry uses strict identical() while the scoring entry uses the lenient .UseProfile() — the two disagree). One root-cause fix (a single normalization step) closes both symptoms. Both T-339 and T-340 verified by an opus peer verifier that traced every cited line independently and, unprompted, confirmed both were two-symptom/one-fix clusters. Low-severity batch (haiku-verified): T-341 (maxReplicates<1 unchecked → silent fallback to the random starting tree, score=-1 self-flagging sentinel), T-342 (fractional-weight datasets get a ~1260×-inflated "recommended replicates" warning — cosmetic-only, no behavior change, left filed rather than fixed pending a design decision on pre- vs post-scaling nChars), T-343 (four documented SearchControl() ranges — enumTimeFraction/nniPerturbFraction/ratchetPerturbProb/sectorMinSize≤sectorMaxSize — unvalidated in R despite sibling params right above them already guarding; silently degenerate, not crashing), T-344 (unpack_xform missing tip_states length guard — same internal-boundary-only class as T-323/T-328/T-332, no public-API path found). A6-05 (four enum-valued SearchControl params also unvalidated) confirmed BENIGN by both the finder's own code trace and independent haiku spot-check — all four consumed via equality/switch, no fixed-array indexing, so out-of-range falls back to a default/no-op; not filed. Seam status: still yielding at BOTH tiers — this was a fresh-surface pass (area 6 hadn't had a dedicated interface audit since 2026-05-26, predating collapse/HSJ-XFORM/packing/T-336) and both opus and fable found real, non-overlapping, non-trivial bugs on identical scope. Given the override, the doctrine-correct next step is: organic rotation resumes at area 6's true start_tier (sonnet) only if/when this area comes up again WITHOUT another explicit override; a same-tier fresh-agent re-visit (opus or fable) would also be defensible given "still yielding," but that's an orchestrator/user call next time, not an automatic doctrine consequence of this round. NEXT ROTATION AREA = 7 (Shiny module wiring).