Encapsulate games under games/ with catalog session identities

.cursor/rules/alpha-no-compat.mdc

@@ -0,0 +1,18 @@
+---
+description: Alpha has no installed base; do not treat format breaks as bugs
+alwaysApply: true
+---
+
+# Alpha: no compatibility
+
+This project is alpha. There is no installed base. Do not preserve, migrate, or dual-read old formats.
+
+Not bugs:
+- Changing a persistence, wire, CLVM, or API shape
+- Dropping an old save schema, localStorage key, or envelope version
+- Requiring a new session after a format change
+- Missing a migration, fallback decoder, or "existing users" path
+
+Do not propose compatibility shims, version dual-paths, or "this will break saved games" as a finding.
+
+Still a bug: the **current** encoder and decoder disagree, so a value written now cannot be read now in the same build (refresh, resume, round-trip in this code). Fix that by making today's format consistent, not by keeping an old one.

Cargo.toml

@@ -50,6 +50,7 @@ axum = { version = "=0.8.9", features = ["ws"], optional = true }
 [build-dependencies]
 chialisp = "0.5.0"
 clvmr = { version = "=0.17.7" }
+serde_json = "=1.0.145"
 toml = "=0.8.23"
 
 [[bin]]
@@ -59,7 +60,7 @@ required-features = ["sim-server"]
 
 [[bin]]
 name = "gen-krunk-dict"
-path = "src/bin/gen_krunk_dict.rs"
+path = "games/krunk/rust/bin_gen_krunk_dict.rs"
 
 [lib]
 name = "chia_gaming"

GAME_LIFECYCLE.md

@@ -15,13 +15,16 @@ see `OVERVIEW.md`. For on-chain dispute resolution, see `ON_CHAIN.md`.
 
 Games are initiated through a propose/accept flow:
 
-1. **Propose:** The caller submits one group request containing `game_type`,
-   game-specific `parameters`, and one shared `timeout`. Both peers run the same
-   deterministic factory, which produces the ordered game records for the
-   group. The potato holder sends one `BatchAction::ProposeGroup`; both sides
-   record all produced games in `proposed_games`. The receiver gets one
-   `ProposalMade` notification for the group, with the member IDs in factory
-   order; the proposer does not.
+1. **Propose:** The caller submits one group request containing `game_type`
+   (the first generated member's initial validation puzzle hash, not a factory
+   hash or package name), game-specific `parameters`, and one shared `timeout`.
+   Both peers run the same deterministic factory, which produces the ordered
+   game records for the group. The potato holder sends one
+   `BatchAction::ProposeGroup`; both sides record all produced games in
+   `proposed_games`. The receiver gets one `ProposalMade` notification for the
+   group, with the member IDs in factory order; the proposer does not.
+   `ProposalMade` includes the canonical parameter bytes so the UI can decode
+   terms through the selected package.
 2. **Accept:** The receiver (or proposer on a subsequent potato) sends
    `BatchAction::AcceptProposal` actions for every member in the same batch.
    Both sides instantiate every referee and game handler, moving the group into
@@ -33,10 +36,11 @@ Games are initiated through a propose/accept flow:
 
 ### Receiver-Side Proposal Validation
 
-When an incoming `ProposeGroup` is processed, the receiver first runs its
-registered factory with the request's `game_type` and exact `parameters`. The
-wire member list must be non-empty and have the same ordered cardinality as the
-factory result. Each wire member must match the corresponding canonical factory
+When an incoming `ProposeGroup` is processed, the receiver first looks up the
+factory by the request's hash `game_type`, runs it with the exact `parameters`,
+and requires that the first returned record's `initial_validation_program_hash`
+equals that `game_type`. The wire member list must be non-empty and have the
+same ordered cardinality as the factory result. Each wire member must match the corresponding canonical factory
 record: sender/receiver contributions, amount, `sender_goes_first`, initial
 commitments, fixed handlers' derived role, and validator commitment. Any
 failure rejects the batch (triggering rollback and go-on-chain).