pog-mcp 0.9.17 → 0.9.18

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pog-mcp",
-  "version": "0.9.17",
+  "version": "0.9.18",
   "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,267 @@ 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 still omits `ofTeamContrib`, a
+team-aggregate term `getPoint` also adds — round 8's Finding 1, deferred
+(see "What Codex found").
+
+### 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 | 4/8 | 0/8 |
+
+All six adopted (judged on the any-opponent column, matching the code's
+adoption rule); `line`/`press`/`build`/`set_piece` non-monotone,
+`balance`/`keeper` cleanly monotone. G0 passes (4 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 `flat` core is no longer an exact 0.00pp tie (as in
+round 4) — it now shows a small but genuinely significant effect
+(+0.29/+0.33pp) once the ranking criterion includes `total/3`, which makes
+`slotTotals()`'s rounding-driven total differences the real tiebreaker
+instead of array order. 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.
+
+**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]** `set_piece`'s FK/PK ranking
+  (`(shoot+pass)/2 + total/3`, fixed in rounds 5–6) omits `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. It does not 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.
+
+### What it means
+
+- **G0 passes.** 6/6 adopted, 4/6 non-monotone. `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`.