pog-mcp 0.9.15 → 0.9.16

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pog-mcp",
-  "version": "0.9.15",
+  "version": "0.9.16",
   "type": "module",
   "description": "MCP server that lets an AI agent play Proof of Goal — wallet, sign-in, squad building, and matches as typed tools.",
   "license": "MIT",

package/skill/reference/measurements.md

@@ -1703,6 +1703,374 @@ N=2000 npx tsx …   # ~50s; the bar is fixed, the detectable EFFECT moves
 
 ---
 
+## Does the best BUILD depend on who you play? (`opp-conditional.mts`)
+
+Recorded 2026-09-09 — docs/tactics/01 track 0.2 ②, #729. Track 2.4 shipped a
+kickoff lock and a scouting surface that shows the opponent's last fielded
+eleven (#726). The plan's own condition for that surface having a DECISION
+value rather than only an information value is written in 01 §5: across a grid
+of opponent builds, take my best response to each — *if the distinct argmax is
+1, scouting's decision value is 0 and 2.4's reason to exist is gone.* Until this
+run that measurement had not been made; every reversal in this file is
+conditional on the mode or on my own attack strength, not on the opponent.
+
+The section above asked the same question of a different axis — which SHEET is
+best against each opponent, with my 212 points fixed — and found one sheet in
+every cell's band. This one asks it of the axis a manager actually controls
+today, the 212-point build.
+
+### The statistic, the three tests, and the controls
+
+The eleven published archetypes from `strategy-probe.mts`, built by the shared
+`squad-lib.mts` so they are the round-robin's squads by construction, play each
+other in both modes at 10,000 matches per fixture (5,000 seeds, home and away,
+SHA-256 keyed on both labels and the side). Each unordered pair is simulated
+once and read from both sides, so the matrix is antisymmetric by construction.
+The diagonal is played too: a manager who knows the opponent's archetype can
+field the same one, so that fixture is a real response with a real answer (50
+by symmetry). Its 22 cells have a known truth, but they are REPORTED data — the
+same-build response in their own column, feeding the tests — so nothing aborts on
+them. The controls are separate fixtures on their own seed keys (below).
+
+For every opponent and mode, my candidates are all eleven builds. The LEADER is
+the candidate with the highest win-equivalent share (draws half); the BAND is
+every candidate the sample cannot separate from the leader under the corrected
+bar; a cell is RESOLVED when its band has one member. Two candidates against the
+same opponent play different seed columns, so every comparison is UNPAIRED.
+
+Bonferroni is priced before the run over the search a band performs: one
+comparison per unordered pair per (opponent, mode) cell, 11·10/2 = 55 pairs over
+22 cells — **m = 1,210, two-sided, |z| ≥ 4.10**. Enumerating every pair already
+covers whichever pair the data selects as leader and runner-up, so that selection
+costs nothing extra, and the two-sided tail already covers both directions; an
+earlier version charged 2 × 55 AND halved α, pricing direction twice for a bar of
+4.26. A too-wide bar is not the safe side here — it widens every band and every
+equivalence bound, and this grid has boundary-sensitive readings. Worst standard
+error anywhere in the run 0.71 points of share, so the significance threshold is
+**2.90 points of share (5.8pp of win rate)** and the 80%-power effect
+**3.49 (7.0pp)**.
+
+Three tests are reported, and their provenance is not the same. **T1 was
+declared before the run.** **T2 and T3 were not**: T2 was added after the first
+run had been read, because "in every band" is a non-rejection and a
+non-rejection is not an equivalence; T3 was added after T2's result had been
+read, because "T1 fires and T2 fails" is not a magnitude claim either — T2
+failing only says no build was SHOWN within the gate everywhere, and every true
+effect could still be under it. On the run the tables below come from, T2 and
+T3 are therefore **post-hoc readings of intervals that were already priced**
+(the Bonferroni family covers every pairwise contrast they use), and the honest
+name for that is exploratory. So all three were then re-evaluated on a
+**confirmatory run** — the same fixtures under a fresh seed namespace
+(`SEED_NAMESPACE=confirm-1`, disjoint seeds, same N), with T2 and T3 fixed in
+the code before it was started. Its verdicts are reported in their own table
+below; the numbers in the sections in between are the first run's. The tests
+are reported **independently**; a difference can be statistically resolved and
+still smaller than the practical margin, so T1 and T2 can hold at once:
+
+- **T1 — conditionality DETECTED**: no build is in every opponent's band; each
+  is significantly beaten as a best response by some build against some
+  opponent. A rejection-based positive claim.
+- **T2 — equivalence ESTABLISHED**: some build is non-inferior to the TRUE best
+  response against every opponent — for that build, the corrected upper bound
+  of (candidate − it) over *every other candidate*, not only the sample leader
+  (the two differ: a bound against the leader alone is trivially satisfied by
+  the leader itself, while one noisy non-leader can deny the simultaneous
+  bound — Knockout's `role-433` and `def-433` columns qualify nobody for that
+  reason),
+  is under the margin in all eleven columns. A positive equivalence claim.
+- **T3 — conditionality BEYOND THE MARGIN**: every build is beaten, against some
+  opponent, by more than the margin with the corrected LOWER bound of (leader −
+  it). The positive magnitude claim, read from the same priced contrasts at the
+  other end.
+- The readings: T1 with T3 → **conditional beyond the margin**; T1 with T2 →
+  conditional but within it; T1 alone → conditional, magnitude
+  unresolved; T2 without T1 → **equivalent**; neither T1 nor T2 →
+  **UNDECIDED** at this sample.
+
+**The margin is 5pp of win rate WITHIN a mode, and that is NOT the repository's
+gate.** It is deliberately the same number — below it, re-solving stops being
+worth an agent's trouble — but the gate proper (`01-engine-expansion.md` §5,
+implemented by `constant-sweep.mts`) is specified on the **exposure-weighted
+mode mix**, and the modes are nowhere near equally exposed. A qualifier's day is
+about 1.33 knockout matches against 12 ladder plus the cup's own 3 group matches,
+which are played in regulation: **8.1% knockout**, and 0% outside the season's
+top 48. `constant-sweep.mts` says in as many words that issuing a verdict per
+mode would call cleared what the mix has not.
+
+**Which way that cuts is not decided here, and the arithmetic must not pretend
+otherwise.** T3 is EXISTENTIAL: each build meets SOME opponent that beats it by
+more than the margin. Multiplying that by the 8.1% mode exposure would assume the
+adverse opponent is met in every knockout fixture — a bracket may hold it rarely
+or not at all — so the product is not a lower bound on the mix, and the weighted
+regret can be anywhere from zero upward. This grid also never plays one locked
+build across the weighted opponent-and-mode mix, which is what the gate actually
+asks. So clearing the repository gate is **not established**
+here, and **not ruled out** either. What is established is that the best response
+is opponent-dependent *within a mode* by more than a within-mode 5pp — the
+prerequisite for scouting to be worth anything.
+
+Controls, every one of which aborts the run: each of the eleven builds must
+reproduce a pinned signature over every field the engine reads from a player —
+`name`, position, the four attributes, `total`, `cond`, `fair` and both kicker
+flags — for all eleven players (slot totals alone would let ratios or a scarcity repair
+drift under the same labels); no two builds byte-identical; **132 true-zero cells**
+within a family-adjusted |z| < 3.55 of 50 (worst 2.3, `stars-433` on the
+`stars-433|bal-442` League control key) —
+correcting matters here: at an uncorrected two-sided 3σ each true null exceeds
+with probability ≈0.27%, so across 132 streams a valid rerun would fail about
+three times in ten (1 − 0.9973^132 ≈ 30%). All 132 are CONTROL FIXTURES of their own,
+never cells read back out of the grid: 22 on a same-label key `a|a` and 110 on a
+two-distinct-label key, the shape every published cell uses. Both halves matter.
+A seeding defect keyed on the pair of labels — which the retired FNV one was —
+passes a same-label-only control while biasing every cell that control exists to
+validate. And every one carries a `zero-ctl:` prefix, so no control shares a
+stream with a reported cell: the controls abort at their α, and a rerun under a
+fresh namespace selected on a control that shared those streams would be picked
+partly on the estimates themselves. And a
+published fact held — `cycle-probe.mts` reports `role-433` beating each of
+its seven other candidates in Knockout, and here the same eight squads say so
+under the same statistic, smallest decided z 3.8 — played on a `drift-ctl:` seed
+family disjoint from every reported cell, because a guard that aborts on the
+reported cells' own estimates would accept only runs reproducing them. That last control is a
+**compatibility** test, not a demand for renewed significance: at
+`cycle-probe`'s N=4000 the weakest of the seven pairs would replicate |z| ≥ 3.32
+with roughly even odds even if nothing had changed, so a rerun that required it
+would be aborting on its own sampling noise. Instead `role-433`'s decided win
+rate against each of the seven from the default-namespace run is pinned in the
+probe, and a run fails only when its own rate is incompatible with the pin at
+the Bonferroni-7 bound |z| ≤ 2.69 — what "the squads changed or the engine
+moved" looks like at any N. Worst |z| against the pins: 0.0 in the default
+namespace (the pins are that family's own default values) and 0.8 in
+`confirm-1`.
+The Knockout column also reproduces the cheap keeper's published collapse
+(`gkmin-433` at 27.8% against `def-532`, inside the 27–42% this file already
+states), and the League column reproduces the two pairings `cycle-probe.mts`
+could not separate (`gkmin-433` 50.6% vs `def-433` and 49.2% vs `def-532`,
+neither significant here either).
+
+### League — UNDECIDED: T1 does not fire, T2 does not pass
+
+| Opponent | Leader | Share | Runner-up | Gap (z) | Band | Within 5pp of the true best |
+| --- | --- | --- | --- | --- | --- | --- |
+| `flat-433` | **`gkmin-433`** | 72.0 | `def-433` | +2.5 (5.7) | `gkmin-433` | `gkmin-433` |
+| `role-433` | `gkmin-433` | 54.0 | `def-532` | +1.0 (2.2) | `def-433` / `gkmin-433` / `def-532` | `gkmin-433` |
+| `def-433` | `gkmin-433` | 50.6 | `def-433` | +0.2 (0.5) | `def-433` / `gkmin-433` / `def-532` | `def-433` / `gkmin-433` / `def-532` |
+| `stars-433` | **`gkmin-433`** | 68.1 | `def-532` | +4.0 (7.3) | `gkmin-433` | `gkmin-433` |
+| `gkheavy-433` | `gkmin-433` | 60.8 | `def-433` | +1.9 (4.1) | `def-433` / `gkmin-433` | `gkmin-433` |
+| `gkmin-433` | `def-532` | 50.8 | `gkmin-433` | +0.8 (1.8) | `def-433` / `gkmin-433` / `def-532` | `def-532` |
+| `shootonly-433` | **`gkmin-433`** | 64.3 | `def-433` | +3.7 (7.2) | `gkmin-433` | `gkmin-433` |
+| `passonly-433` | `def-433` | 64.7 | `gkmin-433` | +1.8 (3.9) | `def-433` / `gkmin-433` | `def-433` |
+| `def-532` | `def-532` | 50.1 | `def-433` | +0.1 (0.3) | `def-433` / `gkmin-433` / `def-532` | `def-433` / `gkmin-433` / `def-532` |
+| `bal-442` | `gkmin-433` | 58.8 | `def-433` | +1.2 (2.6) | `def-433` / `gkmin-433` | `gkmin-433` |
+| `atk-352` | `gkmin-433` | 63.0 | `def-433` | +1.4 (3.0) | `def-433` / `gkmin-433` | `gkmin-433` |
+
+> **Measured on** — every one of the eleven published archetypes as the
+> opponent, with all eleven as my candidates (the opponent's own build among
+> them: its EXPECTED share is 50 by symmetry, and the sampled cell — 50.1 for
+> `def-532` here — enters the tests like any other, a known truth on reported
+> data rather than a control). Bold
+> leaders are RESOLVED cells: the band holds one build. The last column is T2's
+> per-cell reading — which builds the sample shows within 2.5 points of share of
+> the TRUE best response: the corrected upper bound of (candidate − it) is under
+> the margin for EVERY other candidate in the column, not just for the sample
+> leader. That is why a column can list nobody even though its leader is
+> trivially zero behind itself — one noisy candidate denies the simultaneous
+> bound.
+> **Sample** — 10,000 matches per fixture, home and away, SHA-256 seeds; 66
+> fixtures in this mode.
+> **Mode** — League (`gameFlg 0`, draws count half).
+> **Effect** — the raw leader is `gkmin-433` in 8 of 11 columns and 3 cells
+> resolve, all three to `gkmin-433`. **T1 does not fire**: `gkmin-433` is in the
+> band of all eleven opponents, so conditionality is NOT detected — but see the
+> confirmation below, where a disjoint sample of the same fixtures puts it
+> outside one band and T1 does fire. That instability is itself the finding
+> here. **T2 does not pass**: no build — `gkmin-433` included — is shown within
+> 5pp of every other candidate in every column; against its own archetype the
+> best sample response is `def-532` and the corrected upper bound of that
+> 0.8-point gap exceeds the margin, and against `passonly-433` the leader is
+> `def-433`. So
+> the League reading is **UNDECIDED**: this sample did not detect an opponent
+> that re-prices the build, and it cannot rule out re-pricing of up to its own
+> power — 7.0pp of win rate on the worst cell — either. One build,
+> `gkmin-433`, is never beaten by MORE than the gate in any column (T3's
+> per-build reading) — which is consistent with equivalence and is not it. "Field `gkmin-433` regardless" is consistent with the grid; the grid
+> does not establish it.
+> **Source** — `opp-conditional.mts`, sections (2) and (3), `REG`.
+
+### Knockout — CONDITIONAL BEYOND THE WITHIN-MODE MARGIN: T1 fires, T3 holds
+
+| Opponent | Leader | Share | Runner-up | Gap (z) | Shootout reach | Band | Within 5pp of the true best |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+| `flat-433` | `def-433` | 82.8 | `def-532` | +0.3 (0.6) | 21% | `role-433` / `def-433` / `def-532` | `def-433` |
+| `role-433` | `gkheavy-433` | 50.6 | `role-433` | +0.3 (0.5) | 26% | `role-433` / `gkheavy-433` | — |
+| `def-433` | `role-433` | 52.4 | `gkheavy-433` | +0.5 (0.7) | 32% | `role-433` / `def-433` / `gkheavy-433` | `role-433` |
+| `stars-433` | **`gkmin-433`** | 69.9 | `def-532` | +4.8 (7.3) | 5% | `gkmin-433` | `gkmin-433` |
+| `gkheavy-433` | `gkmin-433` | 52.0 | `gkheavy-433` | +1.6 (2.2) | 28% | `role-433` / `gkheavy-433` / `gkmin-433` | `gkmin-433` |
+| `gkmin-433` | **`def-532`** | 72.2 | `def-433` | +8.7 (13.3) | 24% | `def-532` | `def-532` |
+| `shootonly-433` | `role-433` | 63.9 | `def-433` | +2.3 (3.3) | 18% | `role-433` / `def-433` | `role-433` |
+| `passonly-433` | `def-433` | 67.8 | `gkheavy-433` | +0.5 (0.7) | 25% | `role-433` / `def-433` / `gkheavy-433` | `def-433` |
+| `def-532` | **`gkheavy-433`** | 59.9 | `role-433` | +3.0 (4.3) | 47% | `gkheavy-433` | `gkheavy-433` |
+| `bal-442` | **`gkheavy-433`** | 58.9 | `role-433` | +4.0 (5.7) | 31% | `gkheavy-433` | `gkheavy-433` |
+| `atk-352` | `gkheavy-433` | 62.3 | `role-433` | +1.7 (2.5) | 26% | `role-433` / `gkheavy-433` | `gkheavy-433` |
+
+> **Measured on** — the same eleven archetypes, the same construction. Shootout
+> reach is the share of that opponent's matches, averaged over all eleven
+> candidates, that went to penalties — DESCRIPTIVE, see below.
+> **Sample** — 10,000 matches per fixture, home and away, SHA-256 seeds; 66
+> fixtures in this mode.
+> **Mode** — Knockout (`gameFlg 1`: extra time and shootout, every match
+> decided).
+> **Effect** — five distinct raw leaders and **4 of 11 cells resolve, to three
+> different builds**: `gkmin-433` against `stars-433` (z 7.3 over the
+> runner-up), `def-532` against `gkmin-433` (z 13.3 — the cheap keeper's
+> published collapse, seen from the other side), and `gkheavy-433` against both
+> `def-532` (z 4.3) and `bal-442` (z 5.7). **T1 fires**: no build is in every
+> band. `role-433` and `gkheavy-433` share the most bands at seven each, and
+> neither survives: `role-433` is significantly excluded from all four resolved
+> cells, `gkheavy-433` from two.
+> The exclusions are carried by resolved cells at z 4.3 to 13.3, not by noise.
+> **T2 does not pass**: no build is within 5pp of every other candidate in every
+> column — and the `role-433` column names nobody at all once the bound is taken
+> over every candidate rather than the sample leader.
+> **T3 holds**: every one of the eleven builds is beaten by MORE than 5pp of win
+> rate, with the corrected lower bound, against at least one opponent. The
+> `gkmin-433` column alone does it for the other ten — `def-532`'s 72.2 there
+> clears the margin against every one of them, the closest being `def-433` at
+> 63.5 — and `def-532` itself is beaten beyond the margin elsewhere, most
+> clearly by `gkheavy-433` in its own column (59.9 against `def-532`'s 49.5).
+> So the Knockout
+> reading is **CONDITIONAL BEYOND THE WITHIN-MODE MARGIN**: the best build is
+> opponent-conditional, and by more than 5pp of win rate *inside Knockout* — a
+> claim T3 makes, not one inferred from T2 failing. Whether that clears the
+> repository's exposure-weighted gate is neither established nor ruled out here:
+> 5pp is a lower bound, and this grid never plays a locked build across the mix.
+> **Source** — `opp-conditional.mts`, sections (2) and (3), `KO`.
+
+### Confirmation on a fresh seed namespace
+
+Same eleven squads, same N, seeds prefixed `confirm-1|` so no fixture shares a
+match with the run above; T2 and T3 were in the code before it started. Every
+control holds (worst true-zero |z| 2.4, `def-433` on the
+`def-433|gkheavy-433` League control key; pinned-rate guard worst 1.2), and
+Knockout reproduces exactly — **League does not**:
+
+| run | mode | T1 | T2 | T3 | reading | resolved leaders | in every band | never beaten beyond the margin |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| tables above | League | no | no | no | UNDECIDED | `gkmin-433` | `gkmin-433` | `gkmin-433` |
+| `confirm-1` | League | **fires** | no | no | CONDITIONAL, MAGNITUDE UNRESOLVED | `gkmin-433`, `def-433` | none | `gkmin-433`, `def-532` |
+| tables above | Knockout | **fires** | no | **holds** | CONDITIONAL BEYOND THE MARGIN (within mode) | `gkmin-433`, `def-532`, `gkheavy-433` | none | none |
+| `confirm-1` | Knockout | **fires** | no | **holds** | CONDITIONAL BEYOND THE MARGIN (within mode) | `gkmin-433`, `def-532`, `gkheavy-433` | none | none |
+
+**League's T1 is not reproducible at this sample size, and that is the League
+result.** T1 asks whether any build sits in every opponent's band; `gkmin-433`
+does in the reported run and in `confirm-2`, and does not in `confirm-1` — three
+disjoint samples of the same eleven fixtures, two landing one way and one the
+other. The `passonly-433` column is where it turns: `gkmin-433` is inside that
+band at z 3.9 in the reported run and in `confirm-2`, and outside it at z 4.3 in
+`confirm-1`. Which side of T1 a sample lands on is decided by noise at N=10,000,
+so nothing about League should be read as "conditionality was detected" or "was
+not"; the honest statement is UNDECIDED, and a larger N is what would settle it.
+The Knockout verdict carries none of this: T1 fires and T3 holds in all three,
+with the same three resolved leaders.
+
+The confirmatory runs are what the T2/T3 verdicts rest on; the first run's
+tables remain the published numbers because they are the run every figure in
+this section was read from, and mixing them would leave no run owning them.
+
+### What the grid does and does not say about 2.4
+
+**What it says.** In Knockout the answer to "which build should I field" changes
+with the opponent, by amounts the sample resolves (3.0 to 8.7 points of share
+between the leader and the runner-up in the four resolved cells: 4.8, 8.7, 3.0
+and 4.0). In League
+the same grid neither finds such an opponent nor rules one out. The plan's
+sentence in 01 §5 was written mode-blind; measured, the axis is a decision in
+one mode and undecided in the other.
+
+**What it does not say — and an earlier version of this section said it.** It
+does not say that the cup lock is where that decision lives. The lock (#726)
+freezes one eleven when the cup opens and reuses it for every fixture of the
+day, group stage (`gameFlg 0`) and knockout rounds (`gameFlg 1`) alike. A
+manager cannot learn a knockout opponent and then switch to the build this grid
+says beats it; the decision the lock actually forces is *one build against a
+bracket of opponents in sequence*, and a per-opponent best response is not that
+object. What this grid establishes is the prerequisite: that in the mode the
+knockout rounds are played in, a per-opponent best response EXISTS to be
+informed by. Whether a single locked build should be chosen differently given
+the bracket — and whether the scouting surface changes that choice — needs a
+bracket-level experiment, and this file does not contain one. As #729 itself
+notes, a distinct-argmax count of 1 would not have meant "remove 2.4" either:
+the lock is a commitment device on its own.
+
+**What produced the conditional responses is not identified.** The three builds
+that are unique best responses somewhere — `gkmin-433`, `gkheavy-433`,
+`def-532` — differ from the rest of the grid in keeper budget, but not only in
+that: `def-532` carries an ordinary keeper and changes formation and back-line
+allocation, and `GK_MIN`/`GK_HEAVY` redistribute the keeper's points across the
+whole outfield. The keeper section of this file supplies a mechanism that is
+consistent with the pattern — in Knockout the keeper's total is
+outfield-conditional through shootout exposure, and the table's shootout reach
+runs from 5% (`stars-433`) to 47% (`def-532`) across opponents — but consistency
+is not attribution. Isolating the keeper would take a keeper-only,
+fixed-outfield contrast, which this grid does not run.
+
+Two secondary readings survive at the descriptive level. In League the
+cheap-keeper build is the raw leader in 8 of 11 columns, which is this file's
+"smaller keeper total is better in matches that allow draws" seen across the
+whole grid at once. And `role-433` — the Knockout dominant in the 8-candidate
+round robin above — is the raw leader in only 2 of 11 Knockout columns once the
+keeper-budget archetypes are in the grid, and is the unique best response to
+nobody. Dominance in a round robin and being the best response to each opponent
+are different questions, and the second is the one scouting asks.
+
+### What this grid CANNOT decide
+
+- **The build space.** Eleven hand-built archetypes, the same set on both axes.
+  That is a sample, not an argmax over 212-point squads. A conditional best
+  response can only appear among builds that exist in the grid, and a build
+  that beats every leader here could exist outside it. Every claim above is a
+  claim about these eleven.
+- **Nobody re-optimises against a KNOWN opponent.** Every candidate is a
+  pre-built archetype. A squad rebuilt with the opponent's eleven in hand is a
+  different 212-point problem — and it is the search the scouting surface would
+  actually enable. This grid measures whether the choice AMONG fixed builds is
+  conditional, which is the weaker, prerequisite question.
+- **The bracket.** The lock forces one build against a sequence of opponents;
+  the grid asks about one opponent at a time. The object the lock decides is
+  not measured here.
+- **Mechanism.** Formation, keeper budget and outfield allocation move together
+  across these archetypes. Which of them re-prices the build is not separated.
+- **`cond` fixed at 5, tenure 0.** As everywhere in this file. Production
+  applies growth before the engine and, since #794, an involvement-driven
+  condition; neither is in these squads.
+- **Sheets at the default.** The section above showed the sheet axis moves more
+  than any build change does; this grid holds it at the shipped weights on both
+  sides.
+- **Power.** 8 of 11 League cells and 7 of 11 Knockout cells are unresolved,
+  and League's T1 flips between two disjoint samples at this N.
+  T2's margin is 5pp within the mode; the worst cell's 80%-power effect is 7.0pp
+  of win rate, so this sample could not have established equivalence at that margin
+  even where it holds — and T2's bound is taken over every candidate, so a
+  weak candidate with a large standard error can deny it on its own. A larger
+  N is the way to move League out of UNDECIDED.
+
+Re-run after any engine change:
+
+```bash
+npx tsx packages/mcp/skill/reference/probes/opp-conditional.mts   # ~2.7M matches, ~31s
+SEED_NAMESPACE=confirm-2 npx tsx …   # a fresh disjoint sample of the same fixtures. Knockout should reproduce;
+#   League's T1 is not expected to — it flips between samples at this N, which is the League finding itself
+N=4000 npx tsx …   # smoke; the tables are shapes, and the pinned-rate control cannot apply at any default-namespace
+#   N other than 10,000 — those streams overlap the pins, so the two rates are paired rather than comparable
+#   132 `zero-ctl:` control fixtures (22 same-label, 110 pair-key) sit at a family-adjusted bar, which
+#   bounds a valid run's abort probability at 5% — they are NOT independent (the seed key omits the mode,
+#   so each pair's League and Knockout controls share a stream), so 5% is a ceiling, not a rate. The
+#   reported diagonals are NOT checked. Investigate an
+#   exceedance first; only then re-run under another SEED_NAMESPACE — never widen the bar to pass
+```
+
+---
+
 ## Note for the maintainers
 
 > **2026-08-19: this note was rewritten twice in one day.** First it said the