pog-mcp 0.9.17 → 0.9.19

package/package.json

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

@@ -4959,3 +4959,369 @@ few points, as any change to who presses must.
   original expression cannot be recovered.
 
 5,648,400 matches in about a minute. Whole run: `zp-selector.mts`.
+
+## Do the six pog axis candidates move the outcome, and are any of them a decision? (`pog-axes.mts`)
+
+Six candidates for the pog playbook (issue #809, gate G0): `balance`, `line`,
+`press`, `build`, `keeper`, `set_piece`. Every one ships as a **selection**
+preference — abilities stay frozen from creation (F-6) and a playbook only
+chooses who starts, at which position, and who takes kicks. This probe
+measures by sweeping 212-point TEMPLATES: the question is whether the engine
+is sensitive to the profile difference at all; selection realizes it
+discretely, checked separately in a 17-player-pool companion measurement.
+
+Five of the six realizations change `squad-lib.mts`'s `build()` inputs;
+`set_piece` instead reassigns the already-built team's `fkKicker`/`pkKicker`
+flags directly (`build()` itself hardcodes those flags onto slots 9/10, so
+this is still a 212-template property, just set via a different code path).
+`D_*_APPR` (issue #745) is the one axis that patches the engine, via the
+`appr-role.mts`/#728 exact-match-count-asserted source-replace pattern.
+
+Eight Codex review rounds (41 findings total, 1 deferred to a follow-up
+issue rather than fixed inline — see "What Codex found") progressively
+hardened the isolation guarantees. Highlights load-bearing for the tables
+below: `balance`/`press` pin the goalkeeper BYTE-IDENTICAL to the base
+squad, including for `mid`. `line` (round 8) instead clones all 11 existing
+players byte-for-byte and relabels only the `position` field to the new
+formation's slot — no attribute rebuild at all, so no GK-pinning pipeline
+is even needed for this axis. `D_*_APPR`'s focus policies override the
+argmax player's selection weight to 1,000,000 (not 1024 — see "What Codex
+found"). `set_piece` ranks FK/PK candidates independently by the actual
+engine formula: `getPoint`/`takePkShot` show both use `atkSkill + cond/2 +
+total/3 + roll`, and FK's single `fkKicker` flag triggers a 50/50 mix of a
+shoot-based and a pass-based branch, so the expected-value-optimal ranking
+for BOTH roles is `(pass+shoot)/2 + total/3` — with a tie-break that keeps
+the two roles on different players. This omitted `ofTeamContrib`, a
+team-aggregate term `getPoint` also adds — round 8's Finding 2, deferred at
+the time (see "What Codex found") and later closed via issue #852: PK needs
+no correction (`takePkShot` bypasses `getPoint` entirely), and FK's ranking
+now adds `0.5*ofTeamContribDirect` (only the direct/shoot branch reaches a
+nonzero team-aggregate term; the crossed/pass branch's rate is 0 for every
+position). Closing it flipped `set_piece`'s own monotone classification —
+see Result and "What Codex found" below.
+
+### Method
+
+Four cores (`flat`, `shaped`, `gkheavy`, `gkmin`). Each axis is a `low`/`mid`/
+`high` ladder; `low`/`high` change exactly one dimension of `build()`'s
+inputs (see `docs/pog/02-axes-measurement.md` §2). Opponent grid = the same
+four cores, both modes, `N=20,000` per cell, seeds keyed on
+`(axis, myCoreKey, oppCoreKey, mode)`. Bonferroni family size (m=706)
+computed analytically before any comparison runs. Non-monotone requires BOTH
+ladder legs to individually clear the bar with opposite signs, on the
+self-play cell. Opponent-conditional requires a candidate to beat both
+others at the same bar, for each opponent.
+
+Adoption is judged on "significant against any of the 4 opponents", which
+does not always match the displayed self-play row alone — both counts are
+now reported side by side for reconciliation (see Result below).
+
+Controls: patch-identity; mirror cells; a `D_*_APPR` policy mirror; a live
+assertion that no knockout match returns a null winner; every 17-player
+pool's full 2^17=131,072 possible 11-subsets checked and validated; and the
+reported grand total checked against a value computed analytically from the
+loop structure.
+
+### Result
+
+| axis | adopted | sig (self-play only) | sig (any of 4 opp) | max \|Δ\| pp | non-monotone | opponent-conditional |
+| --- | --- | --- | --- | --- | --- | --- |
+| `balance` | yes | 7/8 | 8/8 | 33.89 | **0/8** | **0/8** |
+| `line` | yes | 8/8 | 8/8 | 22.87 | 1/8 | 3/8 |
+| `press` | yes | 7/8 | 8/8 | 39.88 | 2/8 | **7/8** |
+| `build` | yes | 7/8 | 8/8 | 12.52 | 1/8 | 0/8 |
+| `keeper` | yes | 8/8 | 8/8 | 19.02 | **0/8** | **0/8** |
+| `set_piece` | yes | 8/8 | 8/8 | 11.38 | **0/8** | 0/8 |
+
+All six adopted (judged on the any-opponent column, matching the code's
+adoption rule); `line`/`press`/`build` non-monotone, `balance`/`keeper`/
+`set_piece` cleanly monotone. G0 passes (3 of 6 non-monotone, above the
+2-required bar). `press` remains the strongest trade-off: 7 of 8 core×mode
+cells have a supported leader that flips across the 4-opponent grid.
+`set_piece`'s non-monotone count in this table (0/8) reflects the #852 fix
+below, not the original round-8 measurement (4/8, `flat`×2 + `gkmin`×2) —
+closing the `ofTeamContrib` gap moved `high`'s FK pick on those two cores
+onto a candidate matching `mid`'s own default FK kicker (same position and
+attributes); the accompanying PK-tiebreak shift measures indistinguishably
+from `mid` too, though for a more specific reason than "identical kickers"
+(see the round-3 correction below) — together removing the dip that made
+those two cores' ladders non-monotone. `shaped`/`gkheavy` are byte-identical to the
+pre-#852 numbers — their position groups aren't attribute-uniform, so the
+added team-aggregate term didn't move the top-ranked candidate. Round 6
+additionally found FK's ranking was missing half its own mechanic (see
+"What Codex found").
+
+`D_*_APPR` (#745's three questions): `focus-total` is now restricted to
+FORWARDS specifically (round 7 — searching all outfielders let a DF win the
+argmax whenever rounding gave one the squad's top total, e.g. `gkheavy`'s
+19-point DF against 18-point forwards, silently testing "focus on whoever
+has the most points" rather than #745's actual forward-specific claim). The
+picture sharpened considerably: only `shaped` (STARS weighting, clearly
+uneven totals with forwards on top) benefits from `focus-total`
+(+16.65/+19.80pp); the other three cores, where totals are flatter or a
+forward isn't the max, take a LARGE loss from forcing defensive duty onto a
+forward (−30 to −46pp) — a much more precise reproduction of #745's own
+conditional claim ("only works when totals are uneven") than the
+all-position version showed. The reversal boundary is confirmed in both
+modes at outfield total-spread 17 (`focus-total` wins, z=36.61 REG / 30.03
+KO); at every lower spread tested (1, 6, 11) `focus-defense` wins
+confirmed, now by far larger margins (up to −47.6pp) since the two policies
+target genuinely different players. Opponent-conditional: 0/8.
+
+**17-pool realizability (exploratory, not gating)**: same construction as
+before (three pools of 17, all 2^17 subsets checked). Two limitations now
+documented, pulling in OPPOSITE directions: (1, round 5) the pool assumes
+each of the 17 individuals' POSITION and kicker flags are fixed at their
+build-time template, but `AGENTS.md` states F-6 freezes ABILITY VALUES
+only, not "pool membership, mutable unminted positions/names, or FK/PK
+choices" — the real product may allow repositioning or kicker reassignment
+this check cannot see, understating realizability; (2, round 7) an
+alternate's total is copied from the slot it replaces, which squad-lib's
+own `slotTotals()` clamps to [10,29] — wider than the production FA
+generator's actual reachable range of 16-28 (`AGENTS.md` §3-16). `pool-shaped`/
+`pool-gkheavy` do produce alternates outside that window (as low as 12, as
+high as 29 — a keeper on `pool-gkheavy`), i.e. synthetic reserves the real
+generator could never mint, which OVERSTATES realizability for any verdict
+depending on one. This exploratory check does not net the two limitations
+against each other — the true direction is unresolved. Full table and
+caveats: `docs/pog/02-axes-measurement.md` §6.
+
+### What Codex found, and what changed (eight review rounds, 41 findings)
+
+Rounds 1–4 are summarized in `docs/pog/02-axes-measurement.md` §7 (GK
+weight-share leaks across three different axes and two different root
+causes, cross-slot scarcity-repair leaks, unvalidated/undersized/
+misnamed pool XIs, unsupported opponent-conditional argmax, combined then
+still-colliding FK/PK selection, proportional instead of concentrated
+`D_*_APPR` policies, `mid` built through a different algorithm than
+`low`/`high`, several doc-accuracy corrections).
+
+**Round 5 (2 P1, 2 P2)** — new defects inside rounds 1–4's fixes:
+
+- `D_*_APPR`'s focus-weight override of 1024 (round 3's fix) wasn't large
+  enough: in the highest-competition scenes (A0/A1, where up to 4 DF plus
+  the GK each carry ~100 stock weight, summing to ~500), 1024 only bought
+  the focal player 62-72% of the draw rather than near-total concentration
+  (measured on `shaped`/A0). `appr-role.mts`'s 1024 was calibrated for the
+  offence table's much smaller competing sums, not this one. Raised to
+  1,000,000 — a three-orders-of-magnitude safety margin that guarantees
+  >99.9% share regardless of competing weight.
+- `set_piece`'s FK/PK ranking (round 4's independent-selection fix) still
+  ranked by the bare `shoot` / `(pass+shoot)/2` stat alone, omitting the
+  `total/3` term `getPoint` and `takePkShot` actually add to the kicker's
+  point. On `flat` (every outfielder has identical `shoot`), ties were
+  broken by JS's stable-sort array order — which happened to correlate with
+  `slotTotals()`'s rounding drift (a couple of slots get one extra total
+  point) — landing the "worst" AND "best" ranking on the same higher-total
+  DF/DMF slot while `mid` uses the FW slots, manufacturing a discontinuity
+  unrelated to kicker quality. Including `total/3` makes ties genuine
+  engine-level ties rather than rounding artifacts wearing a tie's mask.
+- Two P2s: the 17-pool check doesn't model that unminted players' positions
+  and kicker flags are mutable in the real product (`AGENTS.md`) — documented
+  as a lower-bound limitation rather than modeled (modeling it properly needs
+  a lineup solver, P1-2's job); and the "significant" cell counts didn't
+  match the displayed self-play rows (adoption is judged on "any of 4
+  opponents", which a reader can't verify from the self-play table alone) —
+  now both counts are reported side by side.
+
+**Round 6 (1 P1)** — a new defect inside round 5's own fix:
+
+- `set_piece`'s FK ranking (round 5's `total/3` fix) still measured only
+  HALF of the `fkKicker` mechanic. `doFk` sends every free kick through one
+  50/50 coin flip between `doFkDirect` (`getPoint(..., 'shoot', SCENE.FK1)`)
+  and `doFkCross` (`getPoint(..., 'pass', SCENE.FK2)`) — the same single
+  flag governs both branches. Ranking by `shoot + total/3` alone matched
+  only the direct-kick half in isolation (presumably what
+  `docs/tactics/00-plan.md`'s narrower "FK=shoot" finding itself measured),
+  not the blended mechanic the flag actually controls. Reading `getPoint`
+  directly confirmed both branches use the identical
+  `atkSkill + cond/2 + total/3 + roll` shape with only `atkSkill` swapped
+  between `shoot` and `pass`, so the expected-value-optimal FK ranking is
+  `(shoot+pass)/2 + total/3` — the same formula PK already uses. The two
+  roles now genuinely converge on the same "best all-round kicker" ranking,
+  which is the correct consequence of the engine's real mechanics, not a
+  bug — it just means round 4's "PK falls to the next-best candidate when
+  it ties with FK's pick" tie-break now fires on nearly every ladder cell
+  instead of occasionally. **This held only through round 8** — issue #852
+  (below) later added a term to FK's formula alone, so FK and PK diverge
+  again and the tiebreak fires only when they happen to coincide (on
+  `flat`/`gkmin` specifically, it no longer fires at all — see #852's own
+  entry for the mechanics).
+
+**Round 7 (1 P1, 4 P2)** — new defects inside earlier rounds' fixes:
+
+- `D_*_APPR`'s `focus-total` searched the argmax total across ALL outfield
+  positions, not specifically forwards — #745's own claim names "your
+  biggest FORWARD" explicitly. On `gkheavy` (19-point DF vs 18-point
+  forwards) and the B3 boundary's alpha=0 squad, rounding made a DF the
+  squad-wide max, so `focus-total` was silently testing "focus on whoever
+  has the most points" rather than #745's forward-specific policy.
+  Restricting the search to `position === 'FW'` sharpened the picture
+  considerably (see Result above): only `shaped` (clearly uneven totals,
+  forwards on top) benefits, and the other three cores take a large loss
+  (−30 to −46pp) from forcing defensive duty onto a forward — a much more
+  precise reproduction of #745's conditional claim than the all-position
+  version showed.
+- Four P2s: both documents still described FK's ranking as `shoot + total/3`
+  even after round 6 corrected the code to `(pass+shoot)/2 + total/3` —
+  fixed to match the committed treatment; the probe's own header comment
+  claimed all six axes are template-input changes via `build()`, when
+  `set_piece` actually reassigns already-built kicker flags directly — now
+  distinguished; the header also still claimed `mid` is "always the bare
+  core", which stopped being true for `balance`/`press`/`line` once round 4
+  rebuilt `mid` through the same pinned pipeline as `low`/`high` (the exact
+  difference round 4 used to find `balance`'s spurious reversal) — corrected
+  to state the real per-axis contract; and the 17-pool's bench alternates can
+  carry totals outside the production FA generator's actual reachable range
+  of 16-28 (`AGENTS.md` §3-16) — as low as 12, as high as 29 for a keeper —
+  documented as a SECOND limitation pulling in the OPPOSITE direction from
+  round 5's position/kicker-flexibility one (this one makes some "가능"/
+  "부분" verdicts optimistic rather than conservative; the two are not
+  netted against each other).
+
+**Round 8 (2 P1)** — new defects inside earlier rounds' fixes:
+
+- **[Fixed]** `line`'s realization conflated formation change with attribute
+  reallocation. `AGENTS.md` states F-6 freezes ABILITY VALUES only —
+  unminted players' position labels and FK/PK assignments stay mutable — but
+  the pre-round-8 `line` implementation rebuilt the outfield through
+  `buildGkPinnedVariant` using the new formation's mix ratios, so a position
+  change also dragged along an attribute redistribution the real product
+  doesn't require. Rewritten to clone all 11 existing players (GK included)
+  byte-for-byte and relabel only `position` to the new formation's slot —
+  `buildGkPinnedVariant` is no longer needed for this axis at all, since no
+  attribute is touched. The now-dead `avgOutfieldWeightByPosition()` helper
+  was deleted. Re-measured: `flat` (EVEN weighting, where the old and new
+  approaches coincide by construction) is byte-identical; the other three
+  cores show smaller, more isolated formation-only effects (e.g. `shaped`
+  −8.43→−5.00pp) — the axis's own max \|Δ\| drops from 32.20pp to 22.87pp.
+  Non-monotone/opponent-conditional classification is unchanged (1/8, 3/8) —
+  only the magnitude was wrong, not the qualitative call.
+- **[Deferred to a follow-up issue, later closed — see below]** `set_piece`'s
+  FK/PK ranking (`(shoot+pass)/2 + total/3`, fixed in rounds 5–6) omitted
+  `ofTeamContrib`, the team-aggregate term `getPoint`'s full formula also
+  adds: `ofPoint = ofPlayerP + ofTeamContrib`, where `ofTeamContrib =
+  (atkCondSum*atkRate*0.075 + atkAttrSum*atkRate*0.1) * (teamPow/100)`.
+  Codex supplied a concrete counterexample on the `flat` core where including
+  this term could flip the top-ranked candidate. Closing this gap requires
+  extracting the engine's `O_*_RATE` tables and `teamPow` computation — new
+  engine-internals research outside this issue's (#809) measurement scope.
+  Per the coordinator's round-7 scope-management guidance, this was left as a
+  documented "KNOWN LIMITATION" code comment rather than extending the review
+  loop further, and tracked in a separate GitHub issue (linked from PR #840)
+  instead. **At the time, this was believed not to affect `set_piece`'s own
+  adopted/non-monotone verdict — the current ranking already captures the
+  dominant term of the real mechanism; only a secondary correction term is
+  missing.** That belief turned out to be wrong.
+
+**Issue #852 (post-#809) — closed the deferred gap, and it was not merely
+"secondary":** reading `engine.ts` directly settled the exact formula each
+role needs. `takePkShot` bypasses `getPoint` entirely (its own comment says
+so); its formula is `(pass+shoot)/2 + cond/2 + total/3 + roll`, which
+`pkRanking` (`(pass+shoot)/2 + total/3`) matches in RELATIVE ORDER — not
+term-for-term, since it omits `cond/2` and the roll — under this probe's own
+uniform-`cond:5` invariant (now runtime-asserted, not just assumed). PK
+needs no further correction. FK's two branches reach `ofTeamContrib` asymmetrically:
+`getPoint`'s `effScene = (skillType==='shoot' || scene===SCENE.A0) ? 0 :
+scene` forces `doFkDirect` (`skillType:'shoot'`) to always read the A0
+column of `O_*_RATE` (FW 1.0 / OMF 0.5 / DMF 0.2 / DF 0.1, transcribed
+verbatim from the engine source) regardless of `SCENE.FK1`'s own numeric
+value, while `doFkCross` (`skillType:'pass'`, `scene: SCENE.FK2`) reads
+`O_*_RATE[9]` — 0.0 for every position, confirmed by reading all four
+arrays. `reassignKicker()` now adds `0.5*ofTeamContribDirect(p)` (half-
+weighted, matching the 50/50 direct/cross split) to the FK score only.
+Every squad this probe builds has uniform `cond:5` and sums to exactly 212
+(`squad-lib.mts`'s `TOTAL`), so `ofTeamContribDirect` is derived from those
+values rather than hardcoded, keeping the formula self-evidently correct.
+Re-running `N=20,000` end to end (14,066,000 matches, same loop structure,
+self-check passed) confirmed Codex's counterexample was real: on `flat`
+and `gkmin`, the top **FK** candidate actually changes from a marginally
+higher-total DF/OMF to a lower-total FW, because `O_FW_RATE[0]` (1.0) is
+10× `O_DF_RATE[0]` (0.1) — enough to overturn the old ranking's tiny
+`total/3`-driven tiebreak. That FW matches `mid`'s own default FK kicker
+(slot 9) in both position and attributes.
+
+**PK is a separate story — `pkRanking` itself is unchanged by this fix**
+[round-3 review correction]. `ofTeamContribDirect` was added to `fkScore`
+only; `pkRanking` still ranks by the bare `(pass+shoot)/2+total/3`. What
+changes is round 4's tiebreak condition (`pkRanking[0] === fkTarget`): under
+the OLD formula, `fkTarget` coincided with `pkRanking`'s own top pick (both
+picked the same highest-`total` candidate), so the tiebreak fired and PK
+fell to `pkRanking[1]`. Under the NEW formula `fkTarget` moves to a
+different candidate (the promoted FW), so the tiebreak no longer fires and
+PK now gets `pkRanking[0]` directly — a candidate that was previously
+pushed down to second place. The two test cores land differently: on `flat`,
+`pkRanking[0]` is the 20-total DF, so `high`'s PK kicker is now a 20-total
+DF — genuinely DIFFERENT from `mid`'s 19-total FW PK kicker in both
+position and total (not "identical" — the 1-point total gap is just small
+enough that `high%`≈`mid%` at this sample size). On `gkmin`, `pkRanking[0]`
+is an OMF whose `(shoot+pass)/2` (6, from a 6/6 split) happens to exactly
+equal `mid`'s FW PK kicker's `(shoot+pass)/2` (also 6, from a 10/2 split) —
+different position, same average, so `pkScore` itself is identical between
+them, which is the real reason `high` and `mid` measure indistinguishably
+there. `shaped`/`gkheavy` are byte-identical before/after: their position
+groups are non-uniform, so the added term didn't reach far enough to flip
+the top FK candidate there (and the PK tiebreak dynamics above never
+trigger). Net
+effect: `set_piece`'s non-monotone count dropped from 4/8 to 0/8 —
+`set_piece` reclassifies from "adopted, non-monotone" to "adopted,
+monotone," joining `balance`/`keeper`. This does NOT change G0's own
+pass/fail verdict (non-monotone axis count: 4/6→3/6, still above the
+2-required bar) — but it does mean the deferral's own "does not affect the
+verdict" reasoning was incomplete: a secondary correction term changed a
+qualitative classification, not just a number.
+
+**Remaining limitation (PR #858 review, tracked in issue #859) — the cross
+branch still scores the wrong player.** `fkScore`'s 0.5-weighted cross
+contribution still credits the KICKER's own `shoot`/`ofTeamContribDirect`,
+but `doFkCross`'s `crossPoints` (`getPoint(..., 'pass', SCENE.FK2, ...)`) is
+only a binary gate — it never reads `shoot`, and its `ofTeamContrib` is
+provably zero (`O_*_RATE[9]` is 0.0 for every position). If the gate
+succeeds, the actual shot is taken by a SEPARATELY weight-drawn receiver
+(`getPlayer(atk, SCENE.A1, true, kickerIdx)` — excludes the kicker, weighted
+by `O_*_APPR[SCENE.A1]`: OMF 100/FW 50/DMF 30/DF 20), scored by their own
+stats. Promoting a candidate to `fkKicker` therefore has an unmodeled
+second-order cost: removing them from the cross branch's receiver pool —
+exactly what the `flat`/`gkmin` FW promotions above do. Closing this needs
+the receiver draw's expected value (tractable — a weighted average, reusing
+`ofTeamContribDirect`) AND the gate's success probability, which is NOT
+context-free: it depends on which specific opponent defender contests
+`SCENE.FK2` that match, a value this ranking (evaluated once per `Candidate`,
+before any opponent is chosen) cannot know — unlike the 4-opponent grid this
+probe deliberately measures against elsewhere. A genuinely deeper,
+opponent-dependent piece of engine-mechanics research than #852's own gap,
+tracked separately rather than folded into this fix. The measured numbers
+above are still valid (they come from real simulations); the claim that this
+formula's picks are the true optimum is exactly as caveated as this gap.
+
+### What it means
+
+- **G0 passes.** 6/6 adopted, 3/6 non-monotone (originally reported as 4/6 —
+  see issue #852 above: closing `set_piece`'s `ofTeamContrib` gap
+  reclassified it from non-monotone to monotone; the pass/fail verdict
+  itself is unaffected, still comfortably above the 2-required bar).
+  `docs/pog/02-axes-measurement.md` has the full write-up and all eight
+  review rounds' changelogs.
+- **The realizability column's direction is explicitly unresolved, not
+  presented as a clean lower bound** — round 7 found a second limitation
+  (out-of-range synthetic reserves) pulling the opposite way from round 5's
+  (position/kicker flexibility), and this exploratory check does not net
+  them. Important for W1's planning: some "불가능" verdicts could turn
+  "가능" once P1-2 builds a real fixture, but some "가능" verdicts here
+  could also turn out to be unreachable.
+- **Every finding across all eight rounds lived inside a FIX, not the
+  original measurement design** — the generalizable lesson: a control that
+  checks the harness is unbiased (mirror, patch-identity) says nothing about
+  whether a specific numeric choice (a weight constant, a ranking formula, an
+  allocator) actually matches the real mechanism it's meant to approximate.
+  Each of those needed independent verification against the actual engine
+  formula or actual competing magnitudes, not just "does the effect look
+  directionally right."
+
+14,066,000 matches in 182.5s (N=20,000, round-8 re-run — the loop structure
+is unchanged so the match count is identical, only wall-clock varies between
+runs; self-checked against the loop structure). The default `N=6,000`
+reaches the same G0 PASS verdict in about a third of the time. Whole run:
+`pog-axes.mts`. Re-run post-#852 (same `N=20,000`, same loop structure):
+identical 14,066,000 matches in 151.6s — wall-clock varies, the match count
+does not.