docs(charter+roadmap): pivot to the tactical CRPG (the POC is answered)

The aliveness POC (M0-M2) is proven, so redefine the project as the tactical
CRPG the /mockups describe. Charter: §1 reframed (Code of Conquest / The
Margreave), §10 combat = tactical + action-economy but GRIDLESS (tokens are
flavor, no positional rules), §15 = button-driven actions + free-text NPC
dialogue (Adjudicator reshaped to the optional free-text escape hatch), §16
adopts /mockups as the UI/systems bible, §17 rewritten to the game's scope.
Two conflicts flagged not silently decided (§18): damage determinism (§7 vs
mock ranges → M5) and class names (§8 vs mock callings → M4).

Roadmap: M0-M2 kept as the built engine; M3-M9 re-sequenced around the mock
screens (Theme+shell → creation → combat → dialogue → inventory/sheet → world
systems → framing/AI-flavor/persistence). Streaming stays shelved; v2 NPC
ideas preserved, re-homed to M6.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

CLAUDE.md

@@ -8,13 +8,13 @@ Read this before writing code. When a request conflicts with something written h
 
 ## 1. What this is
 
-A single-player, party-based fantasy RPG. Combat is deterministic JRPG-style. The story skeleton is authored; the *prose* is generated. An AI acts as Dungeon Master — narrating scenes, voicing NPCs, and improvising minor events — while all game state lives in code.
+**Code of Conquest** — a single-player, party-based **tactical CRPG** in a gritty high-fantasy world ("The Margreave"). Turn-based, D&D-flavored combat is deterministic (§7/§10). The story skeleton is authored; the *prose* is generated. An AI acts as Dungeon Master — narrating scenes, voicing NPCs, and improvising minor events — while all game state lives in code.
 
 **Not multiplayer.** Not now, not later. Companions are code-controlled NPCs. Do not introduce networking, lockstep, or authority abstractions "in case."
 
-**Target:** Desktop first (Windows/Linux). Mobile is a later consideration and should not constrain POC decisions.
+**Target:** Desktop first (Windows/Linux), **1920×1080 (16:9), Godot 4.7.** Mobile is a later consideration and should not constrain design.
 
-**Current phase:** POC. The question the POC answers is *does bounded AI dialogue feel alive, or does it feel like a chatbot in a costume?* Everything else is scaffolding for that experiment.
+**Phase.** The original POC question — *does bounded AI dialogue feel alive, or a chatbot in a costume?* — is **answered.** Bounded NPC dialogue, validated moves, and the DM loop are built and live-proven (M0–M2). The project is now **building the game the mockups describe** (§16, `/mockups`): the tactical CRPG across the 11 screens of that UI bible. The AI's job is unchanged — narrate, voice NPCs, improvise — and it never owns state.
 
 ---
 
@@ -348,15 +348,16 @@ Single integer, −100..100, per companion. Adjusted by player choices weighed a
 
 ## 10. Combat
 
-**Positionless, turn-based.** No grid. No flanking. No terrain.
+**Tactical, turn-based, gridless.** Turn order by initiative; an **action economy** (Action · Bonus · Move) per turn; abilities picked from a bar; enemies targeted by click. AC, HP, and initiative in the D&D-flavored idiom of the Combat HUD mockup (§16).
 
-Combat is not the risk surface of this project. Ship the boring one; prove the interesting one.
+**No real movement grid.** The isometric board and tokens are *visual flavor* — there are no positional rules, no flanking, no terrain, no reachable-tile movement. Positioning was the risk surface the old charter warned against; it stays out. The tactics live in the **action economy and resources**, not the map.
 
-- **Damage is deterministic.** No variance rolls on damage.
+- **The player controls only their own character.** The DM resolves the AI companions' and enemies' turns.
+- **Damage is deterministic (§7). OPEN:** the Combat HUD mock rolls damage from a range, but §7 forbids damage variance so Luck can *select* outcomes, not fudge numbers. Reconcile at the combat brainstorm — either fixed damage with Luck governing crit thresholds + borderline status checks, or a conscious, written change to §7. Do **not** silently adopt damage ranges.
 - **Initiative is rolled once at encounter start** and is relatively random. DEX modifies.
-- **The interesting decision is resource management** — MP, cooldowns, consumables. Not matchup-reading. Pick one axis for the POC.
+- **Resources are the interesting axis** — the action economy, cooldowns, consumables. Not matchup-reading.
 - **Luck influences crit thresholds and borderline status checks.** Nothing else. See §7.
-- **Combat flavor text is async and optional.** The numbers land immediately. The prose catches up. If the AI call fails, the fight continues with authored text.
+- **Combat flavor text is async and optional.** The numbers land immediately; the prose (a Narrator/DM call) catches up. If the AI call fails, the fight continues with authored text.
 
 ### Determinism and seeding
 
@@ -366,6 +367,8 @@ This costs nothing now and is nearly impossible to retrofit. It is the differenc
 
 Log the seed *and* the full prompt with every AI call, for the same reason.
 
+The Combat HUD mock's `Component` state machine (initiative order, action economy, ability resolution, victory/defeat) is the reference spec for the GDScript turn manager.
+
 ---
 
 ## 11. The canon log
@@ -454,14 +457,14 @@ Roughly 1–3k tokens per call, dozens of calls per session.
 
 ## 15. Input model
 
-**Hybrid.**
+**Button-driven actions; free-text dialogue.**
 
-- **Menus:** combat, navigation, inventory.
-- **Free text:** dialogue, and explicit "what do you do?" moments.
+- **Buttons / menus:** combat abilities, world actions, navigation, inventory, shop. The player picks from **legal options code presents** — no input can produce an illegal or absurd action ("I triple-backflip off the wall and roundhouse him" never reaches the rules). Bulletproof by construction.
+- **Free text:** **NPC dialogue** — the aliveness surface, kept free-text (bounded by the move vocabulary §6, so wild input is harmless). Plus an optional **"describe your own action"** line on the main window (2a mock) for the tabletop feel.
 
-**The boundary must be visible.** The player should always know which mode they are in. Ambiguity here reads as broken.
+**The boundary must be visible.** The player should always know which mode they are in.
 
-Free text goes to the Adjudicator, which maps it to a legal action or rejects it with an in-world reason.
+**The Adjudicator (§5) is reshaped.** Its primary job is no longer parsing free text into a world action — code presents legal actions as buttons. It survives only as the interpreter for the *optional* free-text "describe your own action" escape hatch: free text → a legal action or an in-world rejection. Most turns never touch it.
 
 ---
 
@@ -470,7 +473,7 @@ Free text goes to the Adjudicator, which maps it to a legal action or rejects it
 - **Client:** Godot 4, **GDScript.** Prefer readability. Drop to C# only if GDScript genuinely cannot do the thing — and say why before you do.
 - **Proxy:** Python, **FastAPI.**
 - **Models:** Ollama (self-hosted, dev/staging) → Replicate (prod). Routed per-role, server-side.
-- **Repo:** greenfield. No existing code.
+- **Repo:** the engine (M0–M2) is built — canon-log contract + client engine, the server model-call pipeline, `/dm/narrate` + `/npc/speak`, bounded moves, considering-state. Build the game on top; follow the existing patterns.
 
 ### Layout
 
@@ -481,9 +484,23 @@ Free text goes to the Adjudicator, which maps it to a legal action or rejects it
   /docs        API-specific docs
   /prompts     Role prompts (versioned, reviewed like code)
 /content       Authored: quests, NPC knowledge lists, fallback text
+/mockups       The UI/systems bible — 11 hi-fi HTML/CSS/JS screen refs + README
 /docs          Cross-cutting docs — roadmap, ADRs, anything affecting both sides
 ```
 
+**`/mockups` is the UI + systems bible.** Eleven high-fidelity HTML/CSS/JS screen
+references (title, character creation, character sheet, inventory, world map,
+quest log, shop, pause/settings, dialogue, combat HUD, main exploration window)
+plus a `README.md` handoff. **Not production code** — each screen is recreated as
+a **Godot 4.7 Control-node scene** pulling from a shared **`Theme`** resource
+(the README's palette, three fonts, and reusable styleboxes keep the look one
+system). Each `.dc.html`'s `Component` class is the **behavior spec** — the
+combat turn manager, dialogue graph, shop economy, and point-buy creation are the
+highest-value logic to port; the seed-data maps (items, quests, locations, units,
+abilities) are starting `Resource`s. Dashed "art slots" are placeholders for real
+art. When the mock and this charter disagree, the disagreement is a decision to
+make, not a default to follow — see §17's reconcile list.
+
 `/api` is still the proxy described in §4 — auth, metering, prompt-hiding, model
 routing. It is named `api` for the client's convenience, not because it is a
 generic pass-through. Docs are split: side-specific docs live under
@@ -494,33 +511,39 @@ Prompts are source code. They get reviewed. They get versioned. Changing a promp
 
 ---
 
-## 17. POC scope
+## 17. Scope — the game (the POC is done)
 
-**~30 minutes of play.**
+The aliveness POC is **answered** (M0–M2, live-proven). The target is now the
+tactical CRPG in the mockups (§16): the 11 screens and the systems they imply —
+character creation, the exploration shell + DM narration, tactical (gridless)
+combat, free-text NPC dialogue, inventory/equipment, character sheet, world-map
+travel, a shop economy, a quest log, title/pause.
 
-- One town, **two NPCs** with authored knowledge lists
-- One dungeon: **three fights, one boss**
-- **Two companions:** Cadwyn, Brannoc
-- **Three playable classes:** Sellsword, Assassin, Priest
-- Luck fully wired: generation, drift, one shrine, one cursed item
-- Full proxy, full role split, full canon log
-- Authored fallback text for every AI surface
+Build it **screen by screen** against the mockups' shared visual system, on the
+proven engine (canon log, DM/NPC pipeline, bounded moves, Luck, character-creation
+model — all already aligned with the mocks). Each screen/system is its own
+**spec → plan → implementation** cycle; the roadmap sequences them toward a
+playable vertical slice first, then breadth.
 
-### The POC's job
+**Unchanged and load-bearing:** §2 (code owns state, AI owns text) — a tactical
+CRPG has *far* more state, all code-owned; the AI stays narrator/DM/NPC-voice.
+Also §3 (tone), §7 (Luck), §9 (companions), the canon log (§11), the output
+contracts (§12), and Failure UX (§13).
 
-Answer one question: **does bounded AI dialogue feel alive, or does it feel like a chatbot in a costume?**
+### To reconcile as we build (flagged, not silently decided)
 
-Test that before building anything else. Every other system exists to make that test possible.
+- **Damage determinism** — §7/§10's deterministic damage vs the Combat HUD mock's
+  damage *ranges* (settle at the combat brainstorm).
+- **Class names** — §8 uses Sellsword/Assassin/Priest/Scholar/Oathbound/Tracker/
+  Berserker; the Character-Creation mock uses callings Sellsword/Cutpurse/
+  Hedge-Mage/Bonesetter/Trapper (same archetypes + primary stats, different
+  names). Settle at the character-creation brainstorm.
 
-### Explicitly out of scope
+### Still out of scope (never / later)
 
-- AI-generated story skeletons (v2 — the seeded story is authored for now)
-- Multiplayer (never)
-- Mobile
-- Credits, payments, auth
-- Companions leaving the party
-- Positional combat
-- More than three classes
+- Multiplayer (**never**) · mobile (later) · AI-generated story skeletons (v2 —
+  the seeded story is authored for now) · credits/payments/auth (retrofit onto
+  the proxy later, §4).
 
 ---