# ThressGame WONT_FIX Manifest

**Status**: Closing artefact for the `thressgame-100` epic (Wave 6).
**Companion**: `packages/chess/RULES.md` § "Cross-References — ThressGame Rules as Chess Presets".

## Purpose

The ThressGame rule set (https://github.com/Ryukaki/ThressGame) defines a
collection of game-rule hooks under `ruleHooks.js`. Most have working hook
bodies that this codebase ports as either **modifier recipes** (the ~62
`recipe-*` / `tpl-*` shipped through Waves 1-5) or **chess presets** (the
8 preset-shaped rules cross-referenced in `RULES.md`).

This document catalogues the **6 ThressGame rules whose `ruleHooks.js`
entries have empty `{}` bodies** — there is no upstream behaviour to port,
no observable contract to test against, and therefore no implementation
possible. Each entry below cites the source line in `ruleHooks.js`,
explains why we cannot ship a port, and records the recommendation for
future revisits if the upstream code ever defines a body.

This is the **WONT_FIX** list: each entry is intentionally not implemented,
not deferred. A future epic can revisit any entry once upstream defines a
hook body or the design intent is documented separately.

---

## 1. `pawns_with_viagra`

- **Source**: `ruleHooks.js:1626` — `pawns_with_viagra: {}`
- **Status**: Empty `{}` stub. No hook body, no comments, no design intent
  recorded upstream.
- **Reason**: With no hook body, the rule has no observable behaviour. Any
  port would be a guess at what "viagra" means in the context of pawn
  mechanics — and a guess is worse than nothing because it locks an
  arbitrary semantic that future upstream work would have to migrate away
  from.
- **Recommendation**: Revisit only if upstream defines a body OR a design
  doc is added. Until then, this rule is undefined behaviour and ports
  cannot be evaluated for correctness.

## 2. `estrogen`

- **Source**: `ruleHooks.js:1638` — `estrogen: {}`
- **Status**: Empty `{}` stub. No hook body, no comments, no design intent
  recorded upstream.
- **Reason**: Same as `pawns_with_viagra` — no observable behaviour, no way
  to author a faithful port. The name suggests piece-color or piece-type
  flipping but neither is documented; making a guess would lock a wrong
  semantic.
- **Recommendation**: Revisit if upstream defines a body OR adds a design
  spec. No implementation possible today.

## 3. `knee_surgery`

- **Source**: `ruleHooks.js:1698` — `knee_surgery: {}`
- **Status**: Empty `{}` stub. No hook body, no comments, no design intent
  recorded upstream.
- **Reason**: No observable behaviour. The name hints at knight movement
  modification (knights have "knees"?) but the upstream rule list has
  multiple knight-related rules with concrete bodies (e.g. `god_kings`,
  shipped at line 1681 with a populated `getLegalMoveModifiers`). With
  those as the established pattern, an empty body is unambiguously a
  TODO upstream, not an implicit no-op.
- **Recommendation**: Revisit if upstream defines a body. No implementation
  possible today.

## 4. `pawns_learned_strength`

- **Source**: `ruleHooks.js:1699` — `pawns_learned_strength: {}`
- **Status**: Empty `{}` stub. No hook body, no comments, no design intent
  recorded upstream.
- **Reason**: No observable behaviour. The name suggests pawn-power
  enhancement but the upstream rule list has multiple pawn-power rules
  with concrete bodies (e.g. the `cash_grab` family at line 1707+) that
  establish the pattern; an empty body is a TODO upstream.
- **Recommendation**: Revisit if upstream defines a body. Several
  shipped recipes (e.g. `recipe-boosted-pawn`, `tpl-march-of-the-pawnguins`,
  `tpl-the-rumbling`) provide modifier-surface examples of "pawn power"
  patterns; if a future ThressGame body lands, port via one of those
  templates.

## 5. `parry` (RPS handler portion)

- **Source**: `ruleHooks.js:1599-1601`:
  ```js
  parry: {
    // RPS logic is handled in moveHandler.js and server.js
  },
  ```
- **Status**: Empty `{}` body **with an explanatory comment** that locates
  the canonical implementation in `moveHandler.js` / `server.js` —
  source files OUTSIDE the `ruleHooks.js` rule registry that this port
  doesn't have access to.
- **Reason**: The `parry` semantic (rock-paper-scissors capture
  resolution) is **already covered** in our codebase by the
  `recipe-parry` parity recipe (shipped before this epic — exercises the
  `request-choice kind:"rps"` primitive). This WONT_FIX entry exists ONLY
  to document the upstream code-location pointer — the rule itself IS
  implemented, just not via the `ruleHooks.js` body.
- **Recommendation**: No action needed — the parry semantic is shipped.
  This entry is a citation for the upstream code-shape decision (RPS
  logic lives in `moveHandler.js`, not in `ruleHooks.js`).

## 6. `pacman_style` (modifier-form body)

- **Source**: `ruleHooks.js:1670` — `pacman_style: {}`
- **Status**: Empty `{}` body. The board-topology semantics
  (file-axis wrap) are implemented in `getWrapMoves` (`server.js`)
  and the `wrap-board` chess preset, OUTSIDE the `ruleHooks.js` registry.
- **Reason**: Same shape as `parry` — the upstream code splits the
  topology between a registered hook (empty here) and a separate
  move-gen helper (`getWrapMoves`). Our codebase routes both surfaces:
  - **Preset surface**: `wrap-board` (RULES.md § Cylindrical Board)
  - **Modifier surface**: `tpl-pacman-style-cross-ref` (Wave 4, uses
    `set-board-topology({value: "wrap-files"})`)
  - **Cross-ref recipe stub**: `tpl-preset-pacman` (Wave 6, points at
    the preset)
- **Recommendation**: No action needed. The `pacman_style` semantic is
  fully covered by the three surfaces listed above. This entry exists
  to document why the empty `ruleHooks.js` body is not a gap — the
  implementation lives elsewhere upstream and we have parity on both
  the preset and modifier surfaces.

---

## Summary

| Rule                       | Source line             | Action               |
|----------------------------|-------------------------|----------------------|
| `pawns_with_viagra`        | `ruleHooks.js:1626`     | WONT_FIX (no upstream body) |
| `estrogen`                 | `ruleHooks.js:1638`     | WONT_FIX (no upstream body) |
| `knee_surgery`             | `ruleHooks.js:1698`     | WONT_FIX (no upstream body) |
| `pawns_learned_strength`   | `ruleHooks.js:1699`     | WONT_FIX (no upstream body) |
| `parry` (RPS handler part) | `ruleHooks.js:1599-1601`| Documented (semantic shipped via `recipe-parry`) |
| `pacman_style` (hook body) | `ruleHooks.js:1670`     | Documented (semantic shipped via preset + W4 modifier + W6 stub) |

## Coverage accounting

The `thressgame-100` epic locked the effective denominator at **51 rules**
(see `decisions.md` § K):

- **65 raw ThressGame rules** (`ruleHooks.js` registry size)
- **− 6 WONT_FIX** (this manifest)
- **− 8 preset-shaped** (cross-referenced in RULES.md)
- **= 51 effective** (covered by Waves 1-5 modifier recipes)

End-of-W5 coverage: **51/51 (100%)**. Wave 6 closes the discoverability
gap by adding 8 preset-stub recipes (one per preset-shaped rule) so all
65 raw ThressGame names appear somewhere in the Templates modal — either
as a working modifier recipe, as a preset cross-ref stub, or (for the 6
WONT_FIX entries) as documented WONT_FIX in this manifest.