pog-mcp 0.9.14 → 0.9.15

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pog-mcp",
-  "version": "0.9.14",
+  "version": "0.9.15",
   "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
 
@@ -1810,7 +1811,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 +4282,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`.