pog-mcp 0.9.18 → 0.9.19

package/package.json

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

@@ -4991,9 +4991,14 @@ 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").
+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
 
@@ -5026,19 +5031,25 @@ loop structure.
 | `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 |
+| `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`/`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").
+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
@@ -5131,7 +5142,11 @@ still-colliding FK/PK selection, proportional instead of concentrated
   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.
+  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:
 
@@ -5182,10 +5197,10 @@ still-colliding FK/PK selection, proportional instead of concentrated
   −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 =
+- **[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
@@ -5194,14 +5209,99 @@ still-colliding FK/PK selection, proportional instead of concentrated
   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.
+  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, 4/6 non-monotone. `docs/pog/02-axes-measurement.md`
-  has the full write-up and all eight review rounds' changelogs.
+- **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
@@ -5222,4 +5322,6 @@ still-colliding FK/PK selection, proportional instead of concentrated
 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`.
+`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.