Skip to content

EchoSpire: Portals — TODO Inventory

Active track rewritten 2026-10-28 (Claude, at Scott's request). This replaces the 2026-10-27 DR-01–DR-20 list, which Scott discarded. It restores the September Demo Release Backlog's release and polish work (full text: commit f5a69cf, 2026-09-02, never merged to master) and folds in what was built since: four crafts, real-time combat, the 3D battlefield, hero creation, Living Ruin menus and the launcher.

Findings come from the repositories and Unity scripts, 2026-10-28. The build was not launched for this pass. Re-check a line in the built Unity player before calling it done.

Client rule

Unity is the sole client for the demo, Steam demo, and Kickstarter. All gameplay, UX, visual, audio, performance, and end-to-end assessments use the built Unity client. WPF is legacy reference only; it never establishes Unity readiness or defects. Shared-engine tests supplement Unity verification and never replace it.

The goal

A stranger downloads the free Steam demo with no account, plays the lie (the orientation), gets read, chooses a House, is inducted, and feels their House win them a fight — and it looks and sounds finished. Ship five inductions, advertise four: the Salvari are discovered, never marketed. Steam demo first; Kickstarter after wishlist data (settled 2026-08-28). The game funds the venue; this release is step one, not extra scope.

Where things stand (2026-10-28)

Built and working

  • Four-craft combat lab (Anchor, Refiner, Rigger, Fitter): a native C# port of craft-lab-2.0.0 with 6,836 browser-parity transitions. Defaults to real time with tactical pause since 2026-10-25 (EchoSpire.Unity/Design/CraftPlaytest.md).
  • 3D battlefield foundations: Sunblasted Canyon stage, battle camera, biome foundations, aim arrows, queued-intent previews, action forecast.
  • Hero creator UX (Origin → Appearance → Identity) with faction crests and backgrounds, craft emblems and eight Meshy starter models. A preview only: it saves no hero, and appearance choices don't reach the battle model yet.
  • Living Ruin loading and main-menu screens; streaming theme music.
  • Windows launcher with self-update and incremental game updates; playtest feed at 1.0.17. The signing pipeline exists but is not enabled (see R-07).
  • Website: canon copy, House quiz, the Book, both signup forms (fixed 2026-10-27).
  • Story canon for the orientation (Preface v7) and all five inductions (canon passes resolved 2026-09-01; scripts in story/drafts/inductions/ and story/sudowrite/inductions/).
  • Five mini-game handlers server-side (src/EchoSpire.API/Services/MiniGames/).
  • Steam store preparation notes: planning/demo-readiness/steam-preparation.md (store copy draft, capsule sizes, capture brief). Kept as reference.

Not built in Unity yet

The playable orientation; quest-beat presentation; sorting and House choice from the orientation; all five inductions; the mini-games; a settings screen; sound effects and volume control; offline play; Steam packaging. The main route still requires an account sign-in. Campaign and Quick Play runs still use the older Anchor rules, not the craft lab.

0. Protect the work — do first

  • [ ] Back up the Unity repository. C:\Dev\EchoSpire\EchoSpire.Unity has no git remote. Its 75 commits exist only on this machine. Branch experiment/desert-realm-3d-prototype is 72 commits ahead of master and has uncommitted model materials. Add a private remote and push every branch. Agent can do this once Scott names or creates the repository.
  • [ ] Decide what becomes Unity master. Merge the experiment branch, or keep it experimental and record why.
  • [ ] Reconcile the story checkout. EchoSpirePortals is on story/preface-panel-fixes, 17 commits ahead of and 56 behind master, with uncommitted bible, docs and Book edits. Commit and merge, so canon and the backlog have one home.
  • [ ] Clean up stale worktrees under C:\Dev\EchoSpire\*-wt once their branches are merged or abandoned. Look before deleting; some hold unpushed work.
  • [x] Commit the 2026-10-28 "Every death leaves an echo" ruling (00-pillars.md, canon-decisions.md). Done with this backlog.

1. Decisions only Scott can make

These gate the build. Each is a sitting or a one-line ruling; log it in the doc that owns it.

ID Decision Why it blocks Recommendation
D-01 Combat model: real time with tactical pause (lab default since 10-25), or turn-based (Demo 3, still what game-overview.md and combat-rules.md say) Every fight, tutorial, induction and the trailer depend on it. The docs and the build disagree Play both in the 1.0.17 lab, then lock one and update both docs
D-02 Craft slate: ratify the four (Anchor, Refiner, Rigger, Fitter) or change them. game-overview.md still lists five older classes; four-crafts.md proposed Anchor, Rigger, Double, Stoker Hero creator, technique content and induction pairings all key off it Ratify what the lab plays, then retire the old class table
D-03 Backend shape for the demo (WO-R1): bundled local server, offline local-content mode, or hosted service A Steam demo must run with no account and no server. Everything in section 4 waits on this Offline local-content mode: normal for single-player demos and cheapest at Next Fest scale
D-04 Orientation source: Preface v7 (five questions; the Book and site use it) or the v12 proposal (four choice moments) The orientation script and sorting instrument are built from it Your call; v12 is still marked proposed
D-05 Craft per induction: which craft each House's induction plays (the golden path), and whether the player's own choice overrides it Induction scripts were written before the crafts Decide with D-02
D-06 Hero creation in the demo: does a demo player create a hero (and which customisation ships), or start as a preset Decides whether saves and the appearance-to-model pipeline are demo scope Keep creation; limit customisation to the eight starter models
D-07 Demo presentation: is the 3D battlefield the demo look, and which realm(s) ship Sets art, performance and minimum-spec work Ship one realm well (Sunblasted Canyon)
D-08 Death-to-echo scope for the demo The tagline promises it (ruled 10-28) Start from the September WO-D5 "Death record, Tier 1"; Tiers 2–3 stay parked
D-09 Book Chapter Five ("The Chore List", the Salvari chapter) is linked publicly Marketing never acknowledges the Salvari Hide it from the public contents until the reveal
D-10 Steam launch path: direct exe or through the launcher Packaging, updates and support Direct exe on Steam; launcher for the website build
D-11 Target Next Fest edition Sets every date below. Registration closes weeks before the event, and the demo must be approved first Pick the edition, then work back
D-12 Mini-games: keep each House's mini-game as an induction beat, or cut some for the demo Five Unity surfaces to build Decide per House after D-05

2. Build the demo route (Unity)

Order: orientation → House choice → one induction end to end → the other four. Self-playtest starts the moment the first induction works (B-14).

Story route

  • [ ] B-01 · Orientation production script (WO-A2) from D-04: official voice, conflicting-order choice nodes, hairline cracks, scripted failure, sorting verdict, "Choose your House." Done when it passes the anti-tells checklist and Scott would show it to a stranger.
  • [ ] B-02 · Quest-beat presentation screen (WO-B2). The rendering layer for the orientation and inductions. Done when a scripted quest node renders and advances in a Unity build with no silent no-ops.
  • [ ] B-03 · Playable orientation. The anchored record as a questline that teaches the core game (opening contract, 00-pillars.md). Only the Anchor opening trial exists today.
  • [ ] B-04 · Sorting instrument (WO-D3). Read the orientation choices, give an advisory verdict in the host's words, allow a free override.
  • [ ] B-05 · Salvari doors (WO-D2). "No allegiance indicated"; the hidden path; the Salvari absent from the advertised House select.
  • [ ] B-06 · Induction scripts revised for the crafts (WO-A3, after D-05). Each passes the cover test with the House name hidden.
  • [ ] B-07 · Five inductions built. Each back half is a mini-run: real map choices, one rest/shop beat, real fights, a finale where the House passive visibly changes the outcome (WO-D4).
  • [ ] B-08 · House passive conferral (WO-C4) at the induction climax, re-specified for D-01 combat. Tooltip, data and handler say the same sentence for all five.
  • [ ] B-09 · Mini-games as induction beats (WO-D1) per D-12. Handlers exist server-side; Unity surfaces don't.
  • [ ] B-10 · Event pool (WO-D7): 12–20 real asymmetric choices.
  • [ ] B-11 · Death to echo, demo tier per D-08.
  • [ ] B-12 · Finish and unlock (WO-D10): finishing an induction unlocks its craft and House independently in Quick Play; the fifth slot reads redacted, not absent. Meta endpoints are stubs today.
  • [ ] B-13 · End-of-demo question (WO-M4): sorted House, chosen House, play again? Feeds telemetry.
  • [ ] B-14 · Self-playtest cadence (WO-D8): orientation plus one induction, twice a week, timed, clean profile, rotating Houses.
  • [ ] B-15 · Design lock (WO-D9): two consecutive playtests with no structural change requests. Gates section 3 polish.

Combat and content (after D-01 and D-02)

  • [ ] B-16 · Move the locked combat rules from the lab into real runs. Campaign and Quick Play still use the earlier Anchor rules.
  • [ ] B-17 · Technique and House content for the demo: each demo craft's kit and each House's Flexible-slot techniques, all executing. Replaces the old card-count targets.
  • [ ] B-18 · Enemies and biome coverage for the demo realm(s) (D-07), with art.
  • [ ] B-19 · Hero creator to a real hero per D-06: save the hero, map appearance IDs into the shared recipe, drive the battle model and portrait from it.
  • [ ] B-20 · Update the design docs to the locked rules: game-overview.md (class table, "no real-time clock"), combat-rules.md, rules-glossary.md.

3. Make it look and sound finished (after B-15)

  • [ ] P-01 · Audio pass (WO-P3). Only theme music exists. Needed: UI sounds, combat impacts and craft cues, an ambient loop per screen, a transition stinger, one House cue each, and a volume mixer. Licensed packs are in C:\Dev\EchoSpire-Library\sound-packs\. The biggest gap between playable and polished; don't leave it last.
  • [ ] P-02 · Settings screen (WO-P6): master/music/effects volume, resolution and window mode, text size, key bindings, quit. The menu's Options is feedback only.
  • [ ] P-03 · Screen transitions and branded loading (WO-P1, P2).
  • [ ] P-04 · Keyboard and gamepad navigation (WO-P5) for menus, confirm and back.
  • [ ] P-05 · VFX for the craft mechanics (WO-P4). The House passive must look like it won the fight.
  • [ ] P-06 · House identity art in game (WO-P7). Reuse the approved creator crests and backgrounds.
  • [ ] P-07 · Text fit, resolution scaling, pause on focus loss checked at 16:9, 16:10 and ultrawide.

4. Make it releasable (after D-03)

  • [ ] R-01 · Offline demo mode per D-03: the demo plays with no API.
  • [ ] R-02 · Remove the sign-in wall (WO-R2). A demo player never sees login or register. The dev auto-login (DevLoginFile.cs, StartupLoadingController) must be impossible in release builds.
  • [ ] R-03 · Assets and content inside the build (WO-R3, R4). One pinned content snapshot; no live blob or content-manifest dependency.
  • [ ] R-04 · Save and resume (WO-R5): quit mid-induction and come back.
  • [ ] R-05 · Strip developer surfaces (WO-R6): lab flags (--craft-playtest and friends), probes, developer gallery, skip flags, review entries.
  • [ ] R-06 · Crash handling and honest opt-in telemetry (WO-R7).
  • [ ] R-07 · Code signing. launcher-release.yml supports signed releases (require_signing). It's waiting on Microsoft identity validation for Azure Trusted Signing (Scott). Current website downloads are unsigned ("signed": false), so Windows SmartScreen warns on every install.
  • [ ] R-08 · Restrict CORS (WO-R9). The API uses AllowAnyOrigin().
  • [ ] R-09 · Performance and system requirements. Measure the 3D scenes on modest hardware; set minimum and recommended specs from tests, not guesses.
  • [ ] R-10 · Cold-machine test (WO-R10): someone who isn't Scott completes the demo on their own hardware with no instructions.

5. Steam

  • [ ] S-01 · Steamworks account (Scott): Steam Direct app fee, tax interview, bank and identity checks. Takes days; start early.
  • [ ] S-02 · Coming Soon page as early as possible. Wishlists only count from the day it's live. Needs:
  • four capsules (920×430, 462×174, 1232×706, 748×896)
  • at least five 1920×1080 screenshots from the Unity build
  • short and long copy (draft in steam-preparation.md)
  • no mention of the Salvari

Can go up with a first asset set and improve later. - [ ] S-03 · Steam AI content survey, backed by the asset inventory (K-08). - [ ] S-04 · Gameplay trailer (WO-M1), 60–90 seconds of actual play. Not the teaser. - [ ] S-05 · Steam build: demo app, depot, launch option per D-10, redistributables, fresh-machine install, update and uninstall. - [ ] S-06 · Build review. Allow at least a week plus corrections before the Next Fest deadline. - [ ] S-07 · Next Fest registration for the D-11 edition. Check the dates on Steamworks. - [ ] S-08 · Website: a wishlist button once the page exists; update the playtest line ("Anchor · Sunblasted Ruin · Stance & Guard") to whatever the current build plays. - [ ] S-09 · Ship the demo and read the wishlist number (WO-M5).

6. Kickstarter (after S-09 data)

  • [ ] K-01 · Kickstarter account (Scott): creator identity, bank, and which business entity runs it.
  • [ ] K-02 · Pre-launch page (needs Kickstarter approval) and a follow link on the website. Followers are the launch-day signal.
  • [ ] K-03 · Freeze the teaser (WO-M2). Lock the slate copy, run the cold-viewing test ("Who was talking at the end?"), fix and close it. Script: story/drafts/kickstarter-teaser-script-v7.md.
  • [ ] K-04 · Campaign video: the teaser plus gameplay from S-04.
  • [ ] K-05 · Campaign page: pitch, reward tiers, stretch goals, risks and challenges, roadmap (four campaigns and one redacted entry; Salvari last).
  • [ ] K-06 · Budget and goal: cost to finish the game, Kickstarter's 5% fee plus payment processing, reward fulfilment, taxes. The goal follows the budget and the S-09 audience data.
  • [ ] K-07 · Kickstarter AI disclosure, required for projects that use AI-generated content.
  • [ ] K-08 · Asset provenance and licensing: what ships, made with what, under which plan. Check:
  • the commercial plans used for Suno, ElevenLabs, Midjourney, Meshy and the built-in image generation
  • the melody-lab cover sources, whose model licence was set aside "for cover-only use"

Steam (S-03) and Kickstarter (K-07) both depend on this. - [ ] K-09 · Email list. Signups land in ks_signups only: no export, no sending provider, no unsubscribe path. Add those, then the launch-day email. - [ ] K-10 · Audience channels: press kit page, a community home (Discord or similar), regular devlogs, social accounts. - [ ] K-11 · Launch date, chosen against Next Fest results and the K-06 budget.

Historical backlog — verify before use

Everything below predates the demo plan above. Unchecked boxes are not automatically live defects. Items that moved into the active track have been removed from here.

Beta Gate

These items are needed for a shippable Beta build — the first build that goes to real outside testers or Early Access. Beta builds on the Kickstarter gate and adds the systems and content needed for meaningful replayability and a complete campaign arc.

Campaign And Progression Systems

  • [ ] Quest system driving run parameters — Quest templates exist but run parameters are not yet actually driven by them. Implement so faction, seed, realm count, objectives, and boss selection are all quest-owned.
  • [ ] Single-realm sector progression — A full campaign run needs sector progression with escalating pressure, revealed breach-sites, and realm-wide passive effects. The map generator supports arbitrary realm indices; the orchestration layer does not yet implement it.
  • [ ] Multi-realm run orchestration — Three or more realms with realm-to-realm transitions and escalating difficulty. GameRunner needs realm-to-realm progression logic.
  • [ ] Realm-wide passive rules — Every realm should apply a global passive (beneficial, harmful, or double-edged) that alters encounter texture and card valuations.
  • [ ] Hero progression implementation (levels 2–10) — XP earning, level-up events, binary flavor choice at each level, and capstone rows are designed in hero-progression-and-difficulty.md. Verify current Unity gameplay and persistence against that design before estimating missing work; historical WPF implementation claims do not establish Unity status.
  • [ ] XP pacing definition and implementation — How XP is earned across tutorial, campaign realms, and endgame must be locked and implemented.
  • [ ] Meta progression: replace stub endpoints — GET /api/v1/meta/currency → { balance: 0 }, unlocks → [], progression → { level: 1, xp: 0 } are all stubs. Implement meta-currency earned from runs, cross-run unlock tracking, and spending flows.
  • [ ] Hero campaign state promotion — Define and implement when a completed or abandoned run promotes progress back into HeroCampaignState and HeroProgressionState.
  • [ ] Authored faction quest arcs — Write the full 4-act campaign outline for each faction (Valerii, Axiom, Syndicate, Censors, Salvari), including recurring cast, narrative act beats, and quest spine after the tutorial.
  • [ ] Rival hero encounter rules and content — Design and implement faction-vs-faction opponent heroes as a distinct encounter type: AI policy, rewards, narrative framing, and Unity presentation.
  • [ ] Faction-versus-faction battle differentiation — Define how these differ from monster fights in rewards, pacing, AI behavior, and political narrative payoff.

Content Scale

  • [ ] Campaign-scale card pool — Tutorial scope is roughly 8–9 cards per class faction combo. A real run needs 30–50 per faction with rarity distribution designed and implemented. Includes rarity reward cadence.
  • [ ] Construct and anomaly rosters — Build the full construct roster (Machinist) and anomaly variant pool (Catalyst) beyond tutorial-scope content.
  • [ ] Enemy roster expansion — Design enemies for each realm and faction pressure type. Define enemy HP and damage scaling formulas across difficulty tiers (currently placeholder values).
  • [ ] Boss roster beyond tutorial scope — Campaign and endgame boss designs, each with faction-specific mechanics.
  • [ ] Random event variety — Current event pool is limited. Build enough variety for repeatable campaigns with meaningful asymmetrical choices.
  • [ ] Relic / Artifact pool expansion — Design relics that interact with each class mechanic and faction passive. The current 20-item pool is too combat-passive-heavy. Add at minimum one deliberately high-variance Artifact per class mechanic and per faction identity.
  • [ ] Realm roster production — Build a production realm roster covering climatic, historical-echo, foreign civilization, machine-scar, and conceptual-failure realm categories.
  • [ ] Faction-specific events, elite encounters, and ambient world interactions — World flavor beyond combat nodes.

Save, Resume, And Persistence Hardening

  • [ ] Pin active runs to immutable published content snapshots — Runs should be pinned to the snapshot version they started on; resume must restore against the pinned snapshot, not current live data.
  • [ ] Save-schema migration and compatibility rules — Now that hero identity, hero profile, hero campaign state, and active runs are separated, older persisted run versions need a migration contract.
  • [ ] Mid-combat and mid-event resume paths — Save at sanctuary only. Full mid-combat and mid-event resume needs integration testing and hardening.
  • [ ] Explicit save-and-quit — Outside sanctuary-only autosave.
  • [ ] Session management policy — Refresh-token revocation, logout handling, and external provider linking.

Simulation And Analytics

  • [ ] Simulation analytics endpoints — GET /api/v1/simulation/results, /analytics, and /outliers are still TODO stubs.
  • [ ] Simulator harness parity — Replace the placeholder simulator harness with an automated runner that exercises the shared rules used by the Unity client; retain separate native Unity verification. Randomize faction/class combinations while honoring authored starter decks.
  • [ ] Stronger AI play policies — Beyond random-only baseline: greedy, heuristic, and objective-aware policies so simulation data resembles competent human play.
  • [ ] Balance dashboards — Automated reports from telemetry: dead cards, overperformers, weak archetypes, bad encounter spikes.
  • [ ] Enemy scaling formulas — HP, damage, and ability scaling across realms and difficulty tiers is still placeholder.
  • [ ] Difficulty tier definitions — What changes between tiers is not specified.

Admin And Tooling

  • [ ] Shared API/Admin validation for quest nested payloads — Invalid JSON-shaped content in QuestTemplate authored sections should be rejected before publish.
  • [ ] Admin: operator account management — Deeper run actions such as safe abandon, restore diagnostics, and save-schema inspection.
  • [ ] Admin: card effects editor — List<CardEffect> — cannot assign effects to cards in Admin yet.
  • [ ] Admin: enemy intent pattern editor — List<IntentEntry> — cannot script enemy behavior in Admin yet.
  • [ ] Admin: faction passive, signature cards, and class restriction editors — Still missing sub-editors.
  • [ ] Admin: class mechanic params, innate/ultimate ability, and starter card editors — Still missing.
  • [ ] Admin: relic passive params and trigger condition editors — Still missing.
  • [ ] Admin: rift-template authoring with type-specific variable validation — Add authoring DTOs and preview support for each official rift type payload.
  • [ ] Admin: publish safeguards — Content validation summaries, stronger rollback confidence checks, and publish safety guardrails.
  • [ ] Admin: relationship views — Which cards belong to which class/faction/effect, cross-entity dependency visualization.
  • [ ] Admin: bulk import/export — Batch content workflows.
  • [ ] Admin: hero progression row editing — Authoring interface for level 2–10 class-power rows.
  • [ ] Admin: rival hero encounter authoring — Admin surface for faction-vs-faction opponent hero content.

Architecture And API

  • [ ] Replace placeholder combat defaults with data-driven craft values — Starting HP and related stats are still hardcoded defaults. (Demo 3 and the craft lab have no Energy.)
  • [ ] Auth expansion — External provider linking, refresh-token revocation policy, and account lifecycle management.
  • [ ] Gameplay event / effect result / trigger batch / UX event canonical schemas — Define the versioned contracts for GameplayEvent, EffectResult, TriggeredEffectBatch, and UxEvent.
  • [ ] First effect-module manifest schema — Compatibility policy and activation rules.
  • [ ] Shared type-specific authoring DTOs for each rift type — Combat, Elite, Boss, Event, Shop, Rest, Treasure, Anchor, Protection, and Sanctuary rift payloads need explicit persisted DTOs, not JSON-assisted editing.
  • [ ] Run mode field on runs — Campaign vs QuickPlay to prevent active-run lookup collisions and enforce correct resume logic.
  • [ ] Realm and quest contracts expansion — Provenance, sector tags, realm passives, and sector progression logic.
  • [ ] Gameplay AI policy contracts — Deterministic enemy / boss / rival hero AI policy layer.

QA And Production Hardening

  • [ ] CI coverage for build, tests, migrations, and content validation — Stronger automated gating.
  • [ ] Operational monitoring and failure reporting — For API and background systems.
  • [ ] Regression coverage for deterministic seeds and golden run sets — Verify that same seed + same decisions always produce identical output across code changes.
  • [ ] Content validation as part of publish workflow — Automated checks before content goes live.

Audio, Visual, And Presentation Direction (Beta Polish)

  • [ ] Production art direction package — Cathedral sci-fi environments, UI, and faction identity. Commission or spec remaining art assets beyond the first-pass AI-generated pool.
  • [ ] Presentation hooks — Boss intros, codex reveals, and campaign act transitions.

Narrative And World (Beta Completeness)

  • [ ] Codex structure — In-game reference for world history, sectors, leaders, classes, and major events.
  • [ ] Narrative style rules — Dialogue, briefings, codex, and event writing voice guide so faction voice stays consistent across authors.
  • [ ] Realm anthology — Distinct realms with flavor, provenance, and political meaning. At minimum enough to support a full campaign arc.
  • [ ] Gamebook audio edition (ElevenLabs) (parked 2026-09-03; Scott-initiated) — Preface first. Voice Design sheets for the 16-voice Preface cast are in story/drafts/graphic-novel/voices/; Scott creates the voices and records IDs in voice-ids.md. Next: v3-annotated Preface + EPUB for ElevenLabs Audiobooks (per-character casting), published to ElevenReader for listening. Not on the Demo Release Backlog; does not block WO-P3.
  • [ ] Recurring cast definition — For each faction campaign: handler, ally, rival, outsider, and leader-facing relationship.
  • [ ] Faction-against-faction storyline arcs — Political conflict connected to gameplay encounters.

Deferred Items (Intentionally Not Beta)

The following items are tracked but intentionally deferred past Beta:

  • Hero-level card unlocks — Quick Play keeps showing all cards while iterating; locking the pool now would hide content during playtest. Requires per-hero progression store, unlockLevel field on cards, and Quick Play hero requirement changes. See /memories/repo/deferred-features.md for full implementation notes.
  • Multiplayer / leaderboards / seeded daily runs — Single-player first.
  • Legacy WPF work — outside the demo and Kickstarter scope. Unity is already the working client; no WPF-first migration gate applies.
  • Public community data API — Post-Beta ecosystem work.
  • Consumables / Field Devices / Contraband layer — Deferred until the Artifact system proves stable.
  • Endgame mastery structure and threat tiers — Long-tail post-Beta replayability.
  • Competitive seeded daily runs — Future feature.

Open Design Decisions (Not Yet Locked)

These are blocking decisions that need to be locked before the dependent feature work can proceed:

  • XP pacing and hero progression earning — How XP is granted across tutorial, campaign realms, and endgame.
  • Persistent power ceiling — How much hero power carries into new runs without flattening roguelike tension.
  • Anchor / Axiom synergy — The one undocumented class/faction pairing. All others have documented synergies.
  • Catalyst faction availability — Catalyst is only available to 2 of 5 factions. Intentional thematic purity or a replayability concern?
  • Echo-Lock exact-5 edge case — What happens if a card tries to apply stack 6 to an enemy already at 5?
  • Density "without taking Life damage" definition — Does a partially blocked hit generate Density or not?
  • Stasis on player counterplay — Hard CC with no stated counterplay. Intentional or a gap?
  • Simulation in-process worker vs. dedicated worker service — Decide before production deployment shape is locked.
  • Treasure and Anchor interaction depth — Final player interaction model is still not locked.
  • Consumable layer decision — Formalize Field Devices / Contraband only after Artifact layer proves stable.

Source documents: docs/official/master-todo.md, docs/official/next-steps.md, docs/official/production-roadmap.md, docs/official/wpf-audit-and-next-build-pass.md, docs/official/wpf-mvp-kickoff.md, docs/official/hero-progression-and-difficulty.md, docs/official/quick-play-end-to-end-plan.md, docs/tech/DevelopmentStatus.md, docs/tech/MiniGames.md, /memories/repo/deferred-features.md