Skip to main content

Valenar Roadmap

Status board for the current Valenar implementation surface.

This page is intentionally narrower than the full design tree. It records what the prototype already proves, what remains explicitly prototype-only, and which surfaces are the next likely implementation consumers.

Current Runtime Surface​

The live Valenar prototype already exercises these broad slices:

  • backend-owned read models for map, queue, inventory, camp, character sheet, and objective-facing UI
  • queueable MC activities backed by the server snapshot
  • Territory dossier, feature drill-in, and map selection flows
  • combat chronicle surfaces and a growing combat-screen design
  • a settlement/runtime bridge strong enough to test ownership, buildings, inventory, and camp state
  • shared Activity Detail host (Waves M / B / C, Activity Detail task) with 7 logical openers backed by server-truthful blockedReason, parentRunId, and childRunId projections; 2 openers (TerritoryContextPanel name tap and Current Plan / Situations) remain deferred to dedicated follow-up waves

Prototype Boundaries​

The prototype is still a stepping-in fixture in several important ways:

  • the map is not the final world-scale contract
  • many screens prove ownership and interaction shape before full content depth
  • compiler-owned catalog/helper authority is emitted under examples/valenar-v2/Generated/obj/**/SecsGenerated/*.g.cs
  • checked-in examples/valenar-v2/Generated/ retains only Valenar.V2.Generated.csproj plus host-owned ValenarHostIds.cs

Near-Term Implementation Consumers​

These docs are the main current consumers for future implementation waves:

Recent Wave Outcomes​

  • Foundation Hardening — in-flight. Multi-wave docs-and-runtime effort scoping every gameplay contract that lacked runtime backing (Quest Threads / Missions, Pressure-to-Front emergence, Realm / PolityRank, Act progression, Province Defense Plans, Character Conditions, Labor / Capacity, Combat Contact Engagements, Generation Validation reports, and the storyBias placeholder). Wave 0 scoped the effort and locked the wave breakdown; Wave 0.5 fixed the docs-site sync gap that hid earlier contract additions from the published mirror; Waves 2a and 2b ran the lore audit and produced ADRs ad-0007 (Quest Thread / Mission scope primitives), ad-0008 (Pressure-to-Front emergence state machine), ad-0009 (Realm scope + PolityRank orthogonality), ad-0010 (Act progression / ActState scope), ad-0011 (True Harm placeholder convention), ad-0012 (Character Conditions and Injuries as Modifiers), and ad-0013 (Scope/State/Channel/Template archetype pattern); Waves 3a / 3b / 3c authored the state-machine and primitive design docs and patched the existing system docs to cite the new ADRs; Wave 4 (this wave) syncs the project / process docs. Waves 5a / 5b / 5c (source / Generated / lowering), Wave 6 (runtime backing), Wave 7 (tests), and the Final cross-artifact verification wave are planned next. See pr-wave-roadmap.md § Foundation Hardening for the full wave list.
  • Wave D (Territory Rename Docs) — complete. Renamed four Valenar docs (Locations → Territories), applied the Location → Territory substitution across all live design docs, added four new system docs (gd-forces.md, gd-operations.md, gd-defense-zones.md, gd-fronts.md), added Fieldcraft and Technique Runtime Note sections to gd-character-skills.md and gd-queue-and-activity-execution.md, added ADR docs/adr/ad-0005-territory-rename-and-force-model.md, and updated .claude/rules/valenar-generation.md to reflect post-migration paths.
  • Wave S (closed; carries blocker) — .secs source rename + Fieldcraft + Force/Operation/DefenseZone/Front source files + WorldData JSON-schema rename are committed. Wave S close leaves 20 GeneratedProvenanceTests failing, which is expected behavior pending Wave G; the failing tests and the explicit Wave G remediation plan are recorded in pr-code-sync-audit.md § Wave S Outcome. The behavior-vocabulary baseline residue (159 vs 158) at Wave S close comes from the preexisting .claude/rules/orchestrator-mode.md edit and is out of Wave S scope; it is not a Wave S regression.
  • Wave G (blocking on Wave S commit, must run next) — compiler-owned territory output alignment under examples/valenar-v2/Generated/obj/**/SecsGenerated/*.g.cs, with checked-in Generated/ still limited to the generated project file plus host-owned ValenarHostIds.cs. Wave G is the unblock for the 20 failing GeneratedProvenanceTests and must run after Wave S commits before any further wave depends on a green dotnet test tests/Valenar.Host.Tests/.
  • Waves M/C/T (deferred) — See pr-wave-roadmap.md for the dispatch graph: Wave M = Host/ and Server/ rename + Force/Operation/DefenseZone/Front runtime + WorldData DTO record rename; Wave C = Client/ rename + TerritoryContextPanel + Force/Front UI; Wave T = test rename + new Force/Territory/Fieldcraft tests.
  • Wave Q (Dynamic Quest Pressure and Cross-Act Lane Architecture): docs-only. Created gd-dynamic-quest-pressure-model.md as the planning-layer generation contract; created 7 cross-act Quest Thread lane owner docs under quest-threads/; patched the Quest Thread taxonomy in gd-quest-and-lore-design.md to acknowledge campaign-spanning lanes without introducing a new tier; removed Interacting from gd-feature-generation-contract.md and gd-territory-generation-contract.md (10→9 state ladder, runtime enum unchanged); closed the drift note in gd-state-axes-and-thresholds.md; added Quest Hooks sections to world-pressure / corruption-reclamation / fronts / operations docs; added Dynamic Objective Sources / Dynamic Pressure Ranking sections to objectives-clues-missions and current-plan; extended the Journal Entry Classes with a paragraph about dynamic events (no new lane); added 2 bullets to gd-canon.md Planning And Behavior Canon. Runtime implementation deferred to Waves QP / QL / QF / QR.
  • Wave M (Cross-Act Lane Visibility in Act Docs): docs-only. Added ## Cross-Act Quest Thread Lanes sections to all 9 act docs with act-specific descriptions of how each cross-act lane manifests in that act; updated examples/valenar/docs/README.md Quest Owners section to list the 7 cross-act lane owners; replaced the stale "future cross-act Quest Thread" sentence with current state.
  • Wave D (Roadmap and Governance Alignment): docs-only. Added Waves QP / QL / QF / QR to pr-wave-roadmap.md Tier 3; added 5 open questions (Q-OQ-1 through Q-OQ-5) to pr-open-questions.md; added Wave Q subsection and Open Drift Items entries to pr-code-sync-audit.md; created ad-0006-dynamic-quest-pressure-and-cross-act-lane-decisions.md formalizing the four Q1-Q4 decisions.

Deferred Follow-Ups​

  • Stage-vocabulary rename (Settlement.Stage vs Act-stage). Flagged by ad-0009-realm-scope-and-polity-rank-orthogonality.md (lines 98–105 and 219–230) as a follow-up rename concern. The Settlement.Stage per-Settlement population-size ladder and the Act-progression "stage" wording in the ../acts/README.md tree are two unrelated meanings on the same English word. Per the no-fallback redesign-propagation rule and the file-rename stop in .claude/rules/orchestrator-mode.md, the rename requires a separate deliberate migration prompt naming exact source and destination paths (gd-settlements-and-outposts.md, the ../acts/gd-act-*.md docs, the Settlement.Stage Generated declarations, the React client UI labels). Foundation Hardening waves do NOT execute this rename. Status: deferred — awaiting deliberate migration prompt.

Working Rule​

When a wave lands, update the doc that owns the behavior first, then update this page if the implementation boundary changed in a way other waves must respect. For the pending follow-up wave plan, see pr-wave-roadmap.md.