EchoSpire: Portals — TODO Inventory¶

Compiled: May 23, 2026

This is the cross-discipline backlog organized into two gates: Kickstarter (pre-launch campaign page, demo slice, and credibility evidence) and Beta (shippable first build for testers and early-access players). These are additive — Beta includes everything from the Kickstarter gate plus the items in its own section.

Kickstarter Gate¶

These items must be done before launching the Kickstarter campaign. The goal is a polished, playable demo slice that can be shown in video, live, and early-press contexts — plus enough production credibility that backers believe the game will ship.

WPF Client — Screen Coverage¶

[ ] Opening Story screen — Five act images exist. API endpoint exists. No view or ViewModel yet. This is the single highest-impact missing piece for game feel. Players currently go from a loading bar straight to hero selection with zero narrative context.
[ ] Hero Builder screen — Reference image exists. All API endpoints exist. No view or ViewModel. The New Hero button hits a placeholder case.
[ ] Combat Encounter screen — The full Core combat state machine runs and is tested; the WPF presentation layer for it does not exist.
[ ] Realm Map screen — Map generation is complete. No WPF map view exists.
[ ] Reward And Event screen — No WPF view exists.
[ ] Sanctuary / Recovery screen — No WPF view exists.
[ ] Run Briefing screen — Stub exists but needs the full quest briefing and starter loadout summary.

WPF Client — Polish And Identity¶

[ ] Animated screen transitions — Every screen change is an instant swap. Games need fade-in/out, slide, or stinger transitions.
[ ] Custom progress indicator — The startup loading bar renders the stock Windows system-chrome pulsing bar. Replace with a branded indicator (pulsing rune, swirling portal, breathing logo).
[ ] Integrate Cinzel Decorative / Cinzel / Cormorant Garamond fonts — Three OFL-licensed fonts have been downloaded to assets/ui/fonts/ and are not yet used in the WPF app. Embed as project resources and replace Segoe UI / Palatino.
[ ] Promote duplicated local styles into Theme.xaml — StartupLoadingView and MainMenuView both define the same styles locally; promote to shared resources.
[ ] Keyboard navigation — All interaction is mouse-click. Roguelikes expect keyboard nav through menus, Enter to confirm, Escape to back.
[ ] Storyteller control — A composable narrative delivery control (Cinematic narration, Dialogue, and TriggeredBeat modes) is needed across Opening Story, tutorial beats, quest intros, and event framing. Currently zero narrative delivery infrastructure exists in WPF.
[ ] Replace stock controls on all gameplay surfaces — No game-branded card control, health bar, enemy intent display, status effect badge, or map node exists yet.

Gameplay Systems — Demo Slice Requirements¶

[ ] Wave 1 cards: convert from shells to runtime-playable — 75 cards have been imported as Dev/inactive rows. They still lack effect payloads, target mappings, and rarity assignments. Activate after verification.
[ ] Quick Play: single playable three-realm run — The full Quick Play shell is now playable end to end in WPF through the combat state machine. Validate the full loop under live load against the API (the current gap is parity with the authored engine path, not raw screen presence).
[ ] Mini-games 2–5: implement the four unbuilt mini-games — Only Game 1 (Stasis Field Calibration / Valerii) is implemented. Games 2–5 (Logic Cascade, Echo Shard Distillation, Soul-Data Recovery, Salvari Pipe Repair) are designed but have Status: ⬜ Planned.
[ ] Artifact pool tuning — The live 20-item production Artifact pool needs tuning: validate that map/economy/sanctuary/treasure/capstone effects produce real run pivots, split authoring across Foundation/Engine/Volatile/Capstone bands, implement acquisition bias by source.
[ ] Content pipeline: startup seed → runtime snapshot reliability — Effect-registry rows and usable combat content are not guaranteed in the DB unless a separate console seeder path was already run. Ensure startup seeding keeps canonical effect-registry rows and baseline cards/enemies present; rebuild published snapshot after seed changes.
[ ] Admin: asset path and AI description editing UI — AssetFilePath and AiGenerativeDescription fields now exist on Card/Enemy/Relic models but there are no Admin UI fields to edit them. Backfill any noncanonical rows still pointing at missing asset paths.

Content — Demo Slice Requirements¶

[ ] Faction banners and leader portraits — These are still empty asset folders. Decide whether to do a polish pass now or defer. (Noted as "presentation-polish work rather than immediate runtime blockers.")
[ ] Biome enemy art coverage — Quick-play fallback enemy key art exists for the current 15-enemy playable pool. Validate coverage is sufficient for the demo realms.
[ ] Opening story narrative finalization — Multiple AI assessments have produced direction. A final canonical opening-story script and panel set (shared prologue before faction selection) has not been authored as production copy. The current material is direction, not final text.

Infrastructure And API¶

[ ] CORS restriction — API currently uses AllowAnyOrigin(). Must be restricted to known origins before public-facing deployment.
[ ] Hosted early-dev tester environment validation — Execute the hosted early-dev runbook and validate the full docs + admin + API path against a live deployment.
[ ] Admin OTLP endpoint — Admin-React browser spans currently emit only to DevTools console via ConsoleSpanExporter. When the API adds an OTLP endpoint, swap for OTLPTraceExporter pointed at /api/telemetry/otlp/v1/traces.

Narrative And Story¶

[ ] Finalize the shared opening prologue — Design consensus exists (fall of the Aevum, Kaelen's unrecognized role, faction selection as the arrival moment) but no production-ready script has been committed. Prerequisite for the Opening Story screen.
[ ] Faction tutorial intro and outro narrative text — Tutorial nodes exist. Final narrative copy for all five faction tutorial openings and closings should be committed as canonical text.

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. None of it is implemented in the runtime, persistence model, or WPF/Admin UI.
[ ] 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 WPF 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 same Core quick-battle engine path the WPF client uses. 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 class values — Max energy, hand size, starting HP, and related stats are still hardcoded defaults.
[ ] 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)¶

[ ] Sound system — Zero audio infrastructure exists. Need ambient loops per screen, UI interaction sounds, transition stingers, and music cues for faction identity.
[ ] 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.
[ ] VFX hooks — Visual language for Stasis, Echo-Lock, Overload, Density, Mutation, and Construct mechanics.
[ ] Presentation hooks — Boss intros, codex reveals, and campaign act transitions.
[ ] Settings and accessibility screen — No view or ViewModel exists.

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.
Unity client migration — WPF MVP must prove the product before a Unity rewrite is justified.
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