Build a playable roguelike dungeon crawler "Escape the Dungeon" where players must exercise INGENUITY through spell crafting and adaptation to progress. This is not a features checklist — it is a problem-solving loop disguised as a dungeon crawler. Every mechanical system must create friction that rewards creative player choice. Solo player (keyboard + mouse). Authored content only. Target: Vite + TypeScript + KAPLAY (web). **Baseline starter abilities must NOT be sufficient to comfortably complete a full floor without adaptation or enhancement.** If a player can brute-force progression using only what they start with, the design has failed. Encounters must demand spell crafting, skill use, resource management, or build specialization. The complete game loop must work without softlock. A test run must walk through: 1. Title screen renders and "New Game" starts a run 2. Player enters first room with visible navigation options 3. Player navigates to a second room (scene transition succeeds) 4. Player encounters combat OR dialogue and resolves it 5. After resolution, player returns to room navigation state 6. Player continues into at least one additional room without softlock or dead end Minimum 3 total room transitions in a passing run. The game must include a functional spell-crafting system AND at least one encounter per floor where the crafted/adapted spell provides a meaningful advantage. Crafting requirements: - Player can access a forge / spell-craft interface during gameplay - Player selects at least 2 crafting inputs (runes or components) - System produces a new, usable spell from the combination - Crafted spell can be equipped and used in encounter flow - Minimum 3-5 runes/components, 3+ valid combinations Ingenuity payoff requirement (THIS IS THE KEY ADDITION): - At least one encounter per floor must significantly favor or require a crafted/ adapted spell. Examples: enemy resistant to base damage types, enemy that punishes spell repetition, enemy that only yields to DoT or burst, etc. - Mere spell acquisition through loot/NPC rewards does NOT satisfy this gate. - Player must intentionally CRAFT to succeed. The game must present a fully intentional UI. Required: - Readable, visually structured layout with spacing and hierarchy - Room-type icons or sprite representations - Encounter/entity visual representation via sprite, portrait, or coherent placeholder - Themed visual differentiation across room types (color, background, or panel treatment) - Styled interactive controls (buttons with visible affordance) - HP/mana/resources as visual bars, not only numeric dumps - Color-coded statuses / spell types / factions Acceptable asset sourcing (in order of preference): 1. Lightweight installable icon/sprite libraries (npm packages, CDN) 2. Web-searched free/open-license sprites and tilesets (use the find-sprites skill) 3. Generated placeholder art (canvas-drawn, SVG, emoji-based) 4. Simple geometric fallback tiles — LAST RESORT, counts against UI quality score Raw ASCII/text-only UI fails this gate. Ugly primitive-only output counts as a gate failure even if asset sourcing was attempted. The game must include at least TWO systems that constrain player behavior such that crafting or adapting spells provides a meaningful advantage or is required for success. Pick at least two from these categories: A. **Resource pressure** — limited mana pool, limited healing, forge training has a cost, cannot spam indefinitely B. **Enemy counterplay** — resistances, immunities, behavior that punishes repetition, shields requiring specific effects C. **Encounter design pressure** — elites with unique rules, bosses that invalidate default play, rooms with mechanical constraints D. **Build pressure** — player cannot master everything, affinity pushes specialization, loadout limits force trade-offs At least one pressure mechanic must interact with the forge so crafted spells are demonstrably more effective than default spells in affected encounters. All content is authored. No procedural level generation. Light randomness in encounter tables or loot is acceptable; structural layout must be hand-designed. Floors → Rooms → Boss Gate. Each floor has 5-8 authored rooms plus a floor boss that gates progression to the next floor. Player clears a floor by defeating the boss, which unlocks the next floor. Standard enemy encounter, authored enemy composition. Stress test for a mechanic introduced earlier on this floor or a previous one. Harder than standard combat, usually requires crafted spells or adaptation. Crafting + affinity training interface. May cost mana crystals or XP to use. Limited recovery (heal HP/mana to a cap, NOT full restore every time). Choices, narrative, tradeoffs. May give items, information, or apply debuffs. Each floor MUST introduce at least one mechanical constraint or enemy behavior that cannot be brute-forced with the player's current default abilities. Examples: - Floor 1: enemies resistant to raw damage → player must apply DoT or status effects - Floor 2: enemies that reflect direct damage → player must use indirect or summon-based attacks - Floor 3: enemies with mana-drain aura → player must conserve or use physical skills This constraint is discovered through gameplay, not explained in a tutorial. Combat rooms on a cleared floor may respawn enemies on re-entry (respawn cadence is authored, not every entry). Player can grind for XP, crystals, and rune affinity before attempting bosses. Grinding should be slower than forge training to create choice pressure. - Forge interface accessible at Forge rooms - 3-5 runes or crafting components - 3+ valid combinations producing distinct spell effects - Affinity tracking per rune/spell family, increases with use - Forge can train affinity directly in exchange for XP (cheaper than combat grinding) - At least one encounter per floor requires or strongly favors a crafted/adapted spell - Visible affinity level (UI shows current levels) - Affinity thresholds unlock stronger spell variants - Authored or player-authored spell customization (player can name their spells) - Cross-affinity decay when runes are neglected - Deep evolution trees - Multi-stage spell mutations Combat must support at least one non-spell action category (basic attack, skill, or similar). The combat model should NOT be single-lane "spell or nothing". Full skill system with physical (no-mana) actions, skill XP / evolution, mana-crystal overcharge to add extra damage or effects (DoT, burn, bleed, stun, knockback). Agents must attempt asset sourcing first via the find-sprites skill or equivalent web-search workflow. Sourced assets should be lightweight, installable, and legally usable (open-license, public domain, or generated). 1. Lightweight installable icon/sprite npm packages (game-icons, pixel-art packs) 2. Web-searched free/open-license sprites/tilesets (itch.io, OpenGameArt, etc.) 3. Generated placeholder art (canvas-drawn, SVG, emoji-based) 4. Geometric fallback tiles — LAST RESORT, counts against UI quality Fallback to generated/geometric placeholders is allowed ONLY if sourcing genuinely fails (404s, no suitable assets, integration cost disproportionate). Fallback must still be visually coherent. Using fallback when real assets were reachable is a gate violation. Traits — player-facing label for narrative/progression stats narrativeStats — internal code/data structure name Splits stable internal naming from clearer external naming. Document the mapping once. Turn-based combat with Fight/Spells/Bag/Run, visible HP bars, damage numbers, XP/crystal rewards At least 3 distinct enemy types with different stats and mechanical behaviors NPC dialogue with portrait/representation and choice options that affect gameplay Persistent HUD: player name, HP bar, mana bar, current floor, dungeon tick or turn count, crystal currency At least two overlay menus (Map, Bag, Stats, Spellbook) Entity model with at least 3 entity types loaded from content pack JSON Game state persists across page refresh (localStorage) Player can level up or gain power through gameplay progression At least 2 floors with different mechanical constraints and boss encounters "Traits" label used in UI where narrative stats appear Full skill system with mana-crystal overcharge (scored bonus, not gate) Affinity thresholds unlock spell variants (scored bonus, not gate) ingenuity_score Whether the player needed to change strategy, whether crafted spells were meaningfully used, and whether encounters encouraged experimentation. Scored 0.0 to 1.0. - Number of crafted spells actually used in a test run - Diversity of spell usage (no single spell dominates) - Can the starter spell alone clear every floor? (this should be NO) - Does at least one encounter REQUIRE crafted spell usage to succeed? - Did the test player adapt their build across floors? This is measured via human review during playtesting. The reviewer asks: "Did I feel like I needed to craft to make progress, or could I spam the default spell?" Procedural generation — authored content only Full rune affinity decay — deferred to v5 Multi-stage deep evolution trees — deferred to v5 Tile-based movement or 2D grid walking Multiplayer or networking Complex asset pipelines or custom art tools Human reviewer rubric for ingenuity: - 0.0: Could spam starter abilities to clear everything, no crafting needed - 0.3: Had to use forge once, but mostly spammed - 0.6: Had to craft 2-3 spells and switch strategies per floor - 1.0: Had to think carefully about builds, crafted spells were essential, felt like a puzzle Affinity must increase as a side effect of casting spells in encounters, not as a direct menu action. Remove any "select affinity → train" menu that picks the trained element for the player. Introduce a Training Dummy encounter (low-XP, no-loot combat room type) whose only purpose is letting the player cast without risk so affinity rises through use. Any room with combat must produce affinity gain for the elements/ runes the cast spell used. The forge becomes a place to forge and combine, not to train. Rationale: the casting of spells must be what increases rune affinity; direct training menus turn a discovery loop into a shopping list. Not all runes are listed or available at game start. Runes must be DISCOVERED across the dungeon. Starter inventory contains a small subset of runes (2-3). The rest are found as loot drops from combat/elite encounters, hidden in event rooms, sold by merchants, or awarded by NPC dialogue outcomes. The rune forge UI must visibly distinguish known vs undiscovered runes (locked slots, ???, or similar). At least one rune per floor must be gated behind a non-combat interaction. The dungeon must contain at least one merchant encounter per floor. Merchant room type. Inventory of runes, potions, and items with gold cost. Three operations: buy (cost gold), sell (gain gold), trade (exchange owned item for stocked item with a relative value rule). Gold or an equivalent currency becomes a tracked resource. Authored NPCs must appear with dialogue options that trigger items, events, or combat. At least 3 authored NPCs across the dungeon with 2+ dialogue branches each. Dialogue choices must cause persistent game state changes: item gain, rune unlock, enemy spawn, merchant discount, quest flag. Player must have a visible inventory UI. Bag with a finite grid of slots. Items have categories: consumable (potions, keys), rune, equipment (weapon, armor, trinket, focus, etc.). Equipment slots must exist on a character sheet with at least: main-hand, off-hand, body, trinket. Equipping an item must affect combat stats or spell outputs in a measurable way. Items must drop from combat, events, and merchants. Player must be able to inspect their character at any time. Panel showing: HP, mana, affinities, physical/combat stats, resistances, equipped items, known spells, known physical skills. Skill tree or equivalent progression graph for physical/combat skills, SEPARATE FROM SPELLS. Physical skills cost stamina or a non-mana resource to distinguish from spells. When the player has many spells/skills, they must choose which to equip. Fixed-size spell loadout (suggested: 4-6 equipped slots out of all known spells). Fixed-size physical skill loadout (suggested: 2-4 equipped slots). Loadout can only be changed in rest rooms or at specific stations, not mid-combat. Build pressure mechanic satisfying G4. The game must support resumable sessions. On room-clear or floor-clear, the game checkpoints the player's state. If the player closes the browser or the session ends, re-opening the game presents a Continue option that restores the most recent checkpoint. New Game starts fresh. Both paths must work without error. UI feedback elements (toasts, status messages, combat results) must be transient and session-scoped. Each element auto-dismisses after a brief display period (3-5 seconds) or provides an explicit dismiss control. Starting a new session must present a clean UI with no carried-over feedback from a previous session. Any room typed Rest (including the rune forge rest variant) must expose a Rest action that restores HP/mana and allows loadout changes. Forge rooms may combine Forge + Train + Rest actions, but Rest must be one of the action buttons if the room claims Rest as a room type. Map/navigation UI must be more than a linear list. Map view must show at minimum a 2D graph layout of discovered rooms with current position, cleared/uncleared state, and available exits. Navigation from the map must be one click, not a multi-step menu. See R-v5.17 for the stronger form. Combat resolves automatically based on the player's pre-set loadout, equipped spells/skills, and tactical rules. The player does NOT click-attack individual enemies during combat. Instead: 1. Before an encounter, the player configures: equipped spells, equipped physical skills (per loadout slots from R-v5.07), formation/positioning of party members (if applicable), and action-policy rules (e.g. "use heal when HP below 30%", "prioritize targets weak to equipped element"). 2. Combat plays out in real-time with a visible combat log showing each action, its effect, and why it was chosen (which rule triggered). 3. The player can PAUSE at any time to adjust loadout, swap spells, or change action-policy rules. The fight resumes with the new configuration. 4. Resolution depends on the loadout quality, spell/skill choices, and how well the action policies match the enemy composition — this is where the forge and rune crafting systems pay off. This model rewards preparation and build-crafting over reflexes. The ingenuity requirement (G2) is satisfied by encounters where the default loadout fails and the player must pause, rethink, and adapt their tactical rules. Every entity with agency (enemies, NPCs, the player character) has traits that drive their behavior. Traits are NOT static labels — they shift based on: - Dialogue choices the player makes (choosing aggressive responses shifts the player toward "aggressive" trait, which changes available dialogue options with NPCs who react to that trait) - Moral interactions (sparing vs defeating enemies, helping vs ignoring NPCs, stealing vs buying from merchants) - Combat actions (repeatedly using fire spells shifts affinity toward fire, which may change how fire-resistant enemies react) Enemy behavior in auto-resolve combat is governed by their traits: an aggressive enemy prioritizes attack, a territorial enemy holds position, a cowardly enemy flees at low HP. NPC dialogue options expand or contract based on trait alignment between the player and the NPC. Traits have visible NUMERIC values on the character sheet (e.g. aggression: 0.7, compassion: 0.3, arcane affinity: 0.8). When a trait shifts, the numeric change is shown inline (combat log or a brief HUD notification like "+0.1 aggression"). The dungeon has an in-game clock that progresses in real time (suggested ratio: 1 real hour = 1 in-game day). The clock can influence gameplay: encounter composition may shift by time of day, merchant stock may rotate, certain NPC events may be time-gated. Day/night UI tinting is a SOFT bonus (not a gate). The clock is purely flavor and pacing — it does NOT add turn-based tick mechanics or per-tick processing. All rendering remains event-driven per R-v5.21. Boosting a rune's affinity must produce a visible, valuable reward — not just a stat increment hidden on a sheet. Suggested rewards at affinity thresholds: new rune variant unlocked, existing spells using that rune gain a visual effect tier, new spell combinations become craftable, access to an affinity-gated event or NPC. At least one affinity reward must be visible in the forge UI (e.g. an affinity progress bar with named milestones). Stronger form of R-v5.12. The navigation view must be a persistent, reachable, visual map. Accessible from a single button/keystroke at any time in exploration mode. Shows the player token on its current room, room type icons, discovered vs undiscovered rooms, cleared vs active rooms, and visible exit connections between rooms. Clicking an adjacent room must move the player there in one action. Preferred layout: 2D grid or spatial floor map. Encounter rendering must make it obvious which visual element is the player and which is the enemy. Distinct portrait, positioning, or color treatment. Reference style: Pokemon or Unicorn Overlord (UO preferred). No rendering where the player cannot visually distinguish themselves from the first enemy without reading text labels. Spell crafting accepts runes AND existing spells as ingredients. A spell used as an ingredient consumes or copies from the existing spell (design choice explicit). Combining two spells or a spell + rune produces an evolved spell with procedurally generated but semantically meaningful naming. Naming scheme must be consistent but varied — similar combinations produce similar names, slight differences produce slightly varied names. Not too verbose. Example scheme: root spell + modifier noun keyed to added element/spell. "Fireball" + Ice rune → "Frostfall Ember". Two Frostfall Embers fused → "Glacial Ember" (same family, progressed). This requirement mirrors the emergent-evolution working hypothesis (gad-68): the in-game rune/spell/ merge system is an explicit narrative analogue for the agent's skill-authoring/merge loop. Each spell recipe requires unique ingredients — the same rune cannot be used twice in a single spell's ingredient list. Selecting a rune already in the current recipe must deselect it or be rejected. The same rune CAN appear across different spells in the spellbook. Affinity gain is calculated per unique rune slot consumed. All UI updates must be event-driven, not per-tick. No redraw loops firing at a fixed rate regardless of state changes. Observable symptom to eliminate: glitchy redraws on button clicks, observed across ALL round-4 builds. This is a perf-and-stability gate failure mode. Acceptable patterns: React reconciliation on state change, requestAnimationFrame scheduling only when animation is active. v4 gates remain (G1 game-loop, G2 forge-with-ingenuity-payoff, G3 ui-quality, G4 pressure-mechanics). v5 amendments tighten G1 (death/continue, end-boss reachable), G2 (training is encounter-driven), G3 (notification lifecycle, map usability), and introduce new scored dimensions for inventory_and_equipment_present and npc_dialogue_present rather than new gates — a run missing those does not get gate-zeroed but takes a meaningful scored hit. Deep evolution trees (multi-stage mutations). Rune affinity decay when unused. Multi-character party play — out of scope for escape-the-dungeon family.