1## Purpose2Define the separation between pure catalog metadata and concrete built-in game runtime registration.34## Requirements56### Requirement: Pure Catalog Index7The catalog package SHALL index puzzle definitions, aliases, daily metadata, variants, and legacy modes without importing concrete game implementations.89#### Scenario: Build catalog10- **WHEN** definitions are passed to the catalog builder11- **THEN** duplicate canonical names, duplicate aliases, invalid Elo values, missing daily modes, and invalid legacy mode targets are rejected1213### Requirement: Concrete Runtime Registry14The registry package MUST compose built-in game entries, imports, help text, print adapters, variants, and legacy mode spawners.1516#### Scenario: Resolve game name17- **WHEN** a canonical game name or alias is supplied18- **THEN** the registry returns the concrete entry for that built-in game1920### Requirement: Variant First Creation21Puzzle creation SHALL prefer registered variants with target Elo, while preserving legacy named modes as compatibility aliases to variant Elo presets.2223#### Scenario: Resolve legacy mode24- **WHEN** a legacy mode title is supplied to CLI creation25- **THEN** PuzzleTea resolves it to the target variant and preset Elo rather than treating modes as the primary creation model2627### Requirement: Daily Eligibility28The registry SHALL expose daily-capable entries from metadata and skip duplicate game IDs so daily selection has at most one concrete spawner per game.2930#### Scenario: Build daily entries31- **WHEN** daily entries are requested32- **THEN** the registry returns seeded spawners tied to registered daily mode metadata