pog-mcp 0.9.14 → 0.9.16

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pog-mcp",
-  "version": "0.9.14",
+  "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

@@ -664,10 +664,11 @@ sets it — there is no `fair:` outside the engine's own tests, and every engine
 input is built from an explicit field list — so it is a global constant in
 practice, and setting it on both squads IS the rule change.
 
-**Not swept: the zone-press coefficient.** Its selector is broken — every
-candidate weight is `0.0`, so `weightedPick` falls back to "the first non-GK
-slot" — and a coefficient in front of an undefined selection measures nothing.
-Forbidden until the selector is decided.
+**Not swept: the zone-press coefficient.** At the time its selector was broken —
+every candidate weight was `0.0`, so `weightedPick` fell back to "the first non-GK
+slot" — and a coefficient in front of an undefined selection measures nothing. The
+selector was fixed in #730 (`zp-selector.mts` below); the coefficient is sweepable
+now but has not been swept.
 
 ### The statistic, and why not the obvious one
 
@@ -1702,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
@@ -1810,7 +2179,9 @@ another is classified as a `swap` in `FormationPitch`, which calls `handleDrop`
 so the drop handler wired there never fires. One drag reaches this at team creation; an
 existing team cannot be reordered that way.
 
-**The mechanism is unidentified, and both candidates are back open.**
+**The mechanism is unidentified, and both candidates are back open.** *(Superseded:
+`zp-selector.mts` below identified it — the zone-press fallback, removed by #730. The
+paragraphs that follow are kept as the record of why the first ablation missed it.)*
 
 | candidate | test | result |
 | --- | --- | --- |
@@ -4279,3 +4650,183 @@ literal early broke one seven times; the last was a markdown table's `` `7036372
 the edit script itself. No tsconfig includes those. The remedy is asserting the match count on
 every replacement, so a broken script dies before it touches the file — which is exactly what
 happened. A smoke run is a behavioural check, not the parse gate.
+
+## Is the slot-order lever the zone-press fallback? (`zp-selector.mts`)
+
+Yes — on the one core where a lever exists, and a two-line engine change removes
+it. This settles the question the depth-cap note above left open ("the mechanism
+is unidentified, and both candidates are back open"): the candidate it withdrew
+for the wrong reason was the right one.
+
+### What was broken, exactly
+
+`tryZonePress` drew the presser with the DEFENSIVE appearance table, whose
+`SCENE.ZP` column is all-zero for every position (`D_*_APPR[ZP] = 0/0/0/0`), so
+`weightedPick` had no candidate and fell through to `players[first non-GK]` on
+every zone press. `getPoint` then drew the possessing side's responder on the
+same scene with the same table — same fallback, same slot. Both sides of every
+zone press were therefore the first non-GK slot of their team, a slot the manager
+chooses freely at team creation. The offence column `O_*_APPR[ZP]` (FW 1.0, OMF
+0.9, DMF 0.8, DF 0.7) was populated and unreachable.
+
+The fix draws both with the offence table — the side `getPoint` already scores
+the presser as (`O_*_RATE[ZP]`). It invents no table; it revives one.
+
+It also had to define one case the old code left undefined. `getPoint`'s DMF
+branch carries a ported defect: on the home side it subtracts the ball carrier
+`this.kiten` rather than the acting player. For a zone press `this.kiten` indexes
+the POSSESSING team while the calculation is the PRESSING team's, so it names an
+arbitrary same-numbered player — the keeper included — and makes the press depend
+on the OPPONENT's slot order. The fallback hid this: the presser was always the
+first non-GK slot, so a DMF pressed only when a manager happened to put one
+there. Drawing by weight makes DMF pressers ~19% of presses, so `SCENE.ZP` now
+takes the acting player, like every other position in that switch. The defect is
+untouched everywhere it was measured. That this path really was unreachable is
+now asserted, not assumed: reverting the two selector lines in a source copy
+reproduces the pre-#725 corpus digest exactly.
+
+### Method
+
+Four cores (`flat`, `shaped`, `gkheavy`, `gkmin`), each against a basket of the
+other three, both modes exposure-weighted (knockout 8.1%). Units are pp of WIN
+RATE on that mix. Two engines run the same matches from the same seeds: the
+shipped engine and a copy with the two selector lines patched in a `mkdtemp`
+directory (the `appr-role.mts` pattern; nothing is written inside the
+repository). Three readings per core:
+
+1. **Sweep**: swap each slot j into the first non-GK slot, paired against the
+   base order, on both engines, plus the paired **shipped − fixed contrast** on
+   the same matches. If the lever is the fallback, the shipped column moves and
+   the fixed column does not.
+2. **Best permutation, selected TWICE — once per engine**: 120 permutations
+   scored at 200 seeds, the winner published at 1500 fresh seeds on both
+   engines (selection column and publication column are different seeds, so the
+   selection optimism is not in the published number). The search runs once
+   against the shipped engine and once, independently, against the fixed one.
+   Optimising only against the shipped engine can show the old exploit is gone;
+   it cannot show the fixed engine has no lever of its own, because a
+   permutation the fixed engine would favour is never tried.
+3. **Base shift**: fixed − shipped for the base order itself, descriptive only
+   and outside the family, because it answers a different question (does the fix
+   move the level, not the lever).
+
+Pre-registered family m=132, Bonferroni at α=0.05 → |t| ≥ 3.56 (df 1499). The
+family is every comparison the run prints with a significance mark — each swap
+on both engines (72), every swap's own engine contrast (36, not a preselected
+"widest": nothing picks one and the readings below use several), and the two
+selected permutations on both engines with their contrasts (16 + 4). Every
+interval is a paired per-seed t interval.
+
+Controls, every one of which aborts the run if it fails: the import-rewritten
+engine with no selector change reproduces 1000 stock matches byte-for-byte
+(whole `MatchResult`); a fallback census over 400 matches counts 1056 zero-weight
+fallbacks on the shipped engine (one per zone press) and 0 on the fixed one;
+mirror cells (true z = 0) read z = 0.3/0.2 shipped and 1.2/1.3 fixed; and the
+base order replayed reproduces itself exactly on both engines.
+
+### Result
+
+| core | shipped-selected perm, on shipped | the same perm, on fixed | shipped − fixed (paired) | **fixed-selected perm, on fixed** | sweep swaps significant, shipped / fixed |
+| --- | --- | --- | --- | --- | --- |
+| `shaped` | **+5.20pp** [+0.45, +9.95], t 3.9 | +0.76pp [−3.97, +5.50], t 0.6 | **+4.44pp** [+0.13, +8.74], t 3.7 | **+0.02pp** [−4.60, +4.65], t 0.0 | **4** / 0 |
+| `flat` | −1.57pp [−4.44, +1.30], t −1.9 | −0.79pp [−3.71, +2.13] | −0.78pp [−3.46, +1.90], t −1.0 | −0.21pp [−3.19, +2.76], t −0.3 | 1 / 0 |
+| `gkheavy` | +1.10pp [−2.20, +4.41], t 1.2 | +1.18pp [−2.16, +4.52] | −0.08pp [−3.00, +2.84], t −0.1 | +0.82pp [−2.50, +4.13], t 0.9 | 0 / 0 |
+| `gkmin` | −0.45pp [−3.80, +2.89], t −0.5 | −1.65pp [−5.12, +1.82] | +1.19pp [−1.87, +4.25], t 1.4 | +0.39pp [−3.06, +3.85], t 0.4 | 0 / 0 |
+
+`shaped` is the only core with a lever on the shipped engine, and the fix is what
+takes it away — with one honest limit on how far that can be pushed.
+
+What is RESOLVED: the paired engine contrast. The best permutation's +5.20pp,
+which put a FW (t28) in the slot a DF (t12) held, reads +0.75pp on the fixed
+engine, and the shipped−fixed difference over the same permutation and the same
+matches is **+4.44pp [+0.13, +8.74], t 3.7** — a resolved, corrected difference,
+so the drop is the fix and not noise. The sweep says the same thing with nine
+paired swaps instead of one permutation: the four significant ones (slots 7–10,
++5.19 to +7.02pp, an OMF or FW into the first slot) read +0.46 to −0.31pp fixed,
+every one of their contrasts significant (t 4.3 to 6.5), and the range of the
+whole sweep collapses from 7.02pp to 1.71pp — 0 of 9 significant.
+
+What that one column does NOT resolve: the residual on the SHIPPED-selected
+permutation. +0.76pp carries [−3.97, +5.50], whose upper bound still reaches
+past the 5pp gate, so that reading alone cannot certify the leftover as *below*
+it — non-significance is not equivalence, and the probe says `UNDECIDED vs the
+gate` there rather than `REMOVED`.
+
+What answers the question it was actually asked: give the FIXED engine its own
+search. A permutation chosen against the shipped engine is not what a manager
+optimising against the fixed one would ever pick, so the shipped-selected winner
+cannot speak to whether a lever remains. Under an independent 120-permutation
+search on the fixed engine, **every core comes in below the gate**: `shaped`
++0.02pp [−4.60, +4.65], `flat` −0.21pp, `gkheavy` +0.82pp, `gkmin` +0.39pp, none
+significant (|t| ≤ 0.9). That is an equivalence result at the gate, on all four
+cores, for the engine that ships after this fix. The sweep says the same with
+nine paired swaps: 0 of 9 significant on every core.
+
+`flat` shows the lever's other face: moving its OMF into slot 1 is a LOSS of
+3.48pp (t −4.5) on the shipped engine and +0.30pp on the fixed one, contrast
+−3.78pp (t −4.9). The fallback was hurting managers who put the wrong player
+first as much as it rewarded the right one.
+
+The fixed engine does not create a lever on any core: 0 of 36 sweep swaps are
+significant across the four cores, no fixed-engine gain clears the gate in
+either direction, and its own independent search finds nothing (above).
+One isolated contrast stays marked: `gkheavy` slot 10, −2.77pp (t −3.6), with
+neither engine's own swap significant (−1.49pp t −1.8 shipped, +1.28pp t 1.7
+fixed) — a resolved difference between two unresolved readings, reported and not
+read as a lever. `gkmin` slot 5 (−2.27pp, t −3.5) cleared the old m=88 bar and
+does not clear the m=132 one; it is no longer marked.
+
+Who presses under the fix, from the revived weights, on a 4-3-3: FW 36%, DMF
+19%, OMF 11%, DF 34% (on `gkmin`'s 4-4-2: 24/20/22/34). Under the shipped
+engine: the first slot, a DF in all four cores, 100% of the time.
+
+Base shift for the record: `shaped` +2.75pp [−0.32, +5.81], `flat` −1.20, `gkheavy`
+−0.57, `gkmin` −2.64pp [−4.94, −0.34]. The fix moves levels between cores by a
+few points, as any change to who presses must.
+
+### What it means
+
+- **The +5.7pp of the depth-cap note was the fallback.** Its clone ablation
+  withdrew the candidate because it held POSITION fixed and varied only
+  attributes — but what the fallback delivers into the first slot is a player
+  whose `getPoint` branch depends on position, so a same-position swap could
+  not see it. Disabling the path and re-running the same permutations, which
+  that note said was needed, is what this probe did.
+- **The lever is gone once the fix ships**, so the Skill records nothing about
+  slot order: a lever that no longer exists must not be documented as one.
+- **Determinism** (P5): completed matches are persisted as events and do not
+  change; the live stream and the replay both read those persisted events, so
+  nothing about a match is observable before it is persisted. Every future
+  match changes — a zone press happens about once a match (1.07 on the test
+  teams, up to 7), and the real draw consumes RNG the fallback did not, so every
+  later draw in that match shifts. The scheduler is one Vercel Cron invocation
+  a minute, not a fleet of replicas: a deploy lands between ticks, and the only
+  match that can straddle it is one whose invocation died mid-tick and whose
+  5-minute lease is then reclaimed by a tick running the new build. That match
+  is simulated once, by the new build, from the stored snapshot and seed — the
+  old build never produced a result for it. Determinism is per build; every
+  engine change (#737, #786, #794 before this one) has made such a boundary, and
+  an engine-replay verification whose window spans a deploy sees it as an
+  ENGINE boundary.
+- **Workload tally** (F-1/F-2): predicate D — actor plus responder minus
+  zero-weight fallbacks — is unchanged in meaning, and on the shipped engine
+  every fallback was a zone-press engagement, so D excluded zone presses
+  entirely. Now it counts them: on the test teams that is **+0.10 engagements
+  per player-match, +6.1%** of the tally (5.75% of the fixed engine's D). The
+  F-2 curve is `cond = 5 + a − b·L/(L+L₀)` with `b = 0.4914`, `L₀ = 59.03`; a
+  6.1% inflation of the load L moves condition by at most **0.0075** points
+  (at L = L₀; 0.0006 at the neutral load 1.146, 0.0047 at the p95 14.76) — an
+  order of magnitude below the 0.5 band step and far below anything
+  `cond-effect.mts` could detect. `PLAYER_WORKLOAD_VERSION` is therefore NOT
+  bumped: the version is a hard filter in the form store, so a bump erases
+  every accumulated load league-wide — a reset three orders of magnitude larger
+  than the drift it would prevent. The boundary is recorded here instead, and
+  `L_neutral`/`L₀` are re-measured by `engagement-load.mts` on the first
+  production window after the deploy (C-2 follow-up).
+- **Open sub-decision, recorded**: the responder. The original appears to have
+  skipped the defensive role at ZP entirely (port comment at `game.pl:1924`);
+  drawing it from the same offence column is the smallest change that invents
+  nothing, and "no responder, team term only" was not adopted because the exact
+  original expression cannot be recovered.
+
+5,648,400 matches in about a minute. Whole run: `zp-selector.mts`.