Skip to main content

Wave Roadmap

Status: target. This document is the current plan-of-record for follow-up waves deferred from Wave D and the Final Wave. None of the listed waves have been dispatched. Each wave entry is current as a plan item; implementation state of the underlying runtime surface is tracked in pr-code-sync-audit.md.

Purpose​

This document is a dispatch registry for waves that are planned but not yet dispatched. It complements pr-wave-template.md — the blank wave-brief form — by holding pending wave instances ready to lift into a dispatch prompt. Maintainers looking for "the next wave to dispatch" should start here.

It cross-references two sibling working docs:

  • pr-roadmap.md — the runtime-state board that records what the prototype already proves and which surfaces are the next likely implementation consumers.
  • pr-code-sync-audit.md — the drift tracker that enumerates known divergence between docs, Content/, Generated/, Host/, Server/, Client/, src/SECS.*, tests/, and scripts/.

This doc is a plan registry, not a status board. A wave entry leaving this doc means the wave shipped (in which case its outcome is recorded in pr-code-sync-audit.md) or was abandoned with a note in the relevant ADR. Wave entries are not deleted on completion; they are moved to the corresponding wave-history record.

Dispatch Graph​

Wave 0-Build
    |
    +-- Wave J
    |     |
    |     +-- Wave QP (Dynamic Quest Pressure Generator Runtime)
    |               |
    |               +-- Wave QL (Cross-Act Lane Mission Ladders) --+
    |               |                                              |
    |               +-- Wave QR (Read-Model Extensions) ----------+
    |               |                                              |
    |               +-- Wave QF (First Proof Slice) [after QL]
    |
    +-- Wave M-design --> Wave M-prose
    |
    +-- Wave S --+
    |            |
    +-- Wave G --+
    |            |-- Wave T --> Wave Z (gating, baseline to 0)
    +-- Wave L --+
    |            |
    +-- Wave Cl -+
    |
    +-- ADR-Routine --------+
    |                       |
    +-- ADR-Terrain-tags ---+
    |                       +--> (no Tier 3 dep)
    +-- ADR-State-intensity -+
    |                        +--> Wave R-1 --> Wave R-2 --> Wave R-3 --> Wave R-4
    +-- ADR-Category-vs-tag -+
                             +--> (no Tier 3 dep)
(Activity Detail / Nested Surface Alignment task — SHIPPED)
    Wave M (Activity Detail)
        --> Wave B (Activity Detail)
            --> Wave C (Activity Detail) [shipped; 2 openers deferred]
            |       |
            |       +-- Wave TerritoryContextPanel (Activity Detail) [planned]
            |       +-- Wave Plan (Activity Detail) [planned, design-gated]
            |
            +-- Wave B-sync (Activity Detail) [planned, docs-only field-name sync]
            |
            +-- Wave T (Activity Detail = additive scope of vocabulary-cleanup Wave T above; shipped)
            |
            +-- Wave D (Activity Detail) [shipped; this implementation/process docs sync wave]

    Wave Vitest [planned; JS test runner setup; orchestrator framework choice pending]

Wave-Naming Disambiguation Note​

Two distinct task threads use single-letter wave names in this doc:

  • Vocabulary cleanup thread: Wave 0-Build, Wave J, Wave M-design, Wave M-prose, Wave S, Wave G, Wave L, Wave Cl, Wave T, Wave Z, Wave R-1 through Wave R-4, plus the four Tier 2 ADR stubs.
  • Activity Detail / Nested Surface Alignment task thread: Wave M (Activity Detail), Wave B (Activity Detail), Wave C (Activity Detail), Wave T (Activity Detail — additive scope of the vocabulary- cleanup Wave T above; the same wave shipped both halves), Wave D (Activity Detail), and the planned Wave TerritoryContextPanel (Activity Detail), Wave Plan (Activity Detail), and Wave B-sync (Activity Detail).

The Activity Detail task waves carry the (Activity Detail) task suffix in their roadmap entries below to avoid collision with the vocabulary-cleanup story-layer waves of similar letter names. "Wave T" is the only collision case: it is a single shipped wave that delivered both the original Wave T charter and the Activity Detail- additive scope. The Wave M-design / Wave M-prose entries belong to the vocabulary-cleanup thread, not the Activity Detail task.

"Wave M" in the wave-entry list below refers to the original vocabulary-cleanup thread (Wave M-design / Wave M-prose). A separate docs-only "Wave M (Cross-Act Lane Visibility in Act Docs)" shipped the act-doc additions for the 7 cross-act Quest Thread lanes; that work is recorded retrospectively in pr-roadmap.md § Recent Wave Outcomes and does not get a standalone wave entry here because the scope has already shipped. Wave Q (Dynamic Quest Pressure and Cross-Act Lane Architecture) is the upstream docs-only wave that motivated both Wave M (Cross-Act Lane Visibility in Act Docs) and the planned Waves QP / QL / QF / QR Tier 3 runtime entries below.

  • Wave J dispatches after Wave 0-Build PASS. It is independent of the ADR-State-intensity / R-series chain, but it should run as its own implementation wave because the Host/Server/Client surfaces overlap with other runtime work.
  • Wave M-design is a docs-only wave currently active concurrently with Wave D; it is file-disjoint from the Tier 1 audit waves and from the R-series, but is the upstream authority for Wave M-prose.
  • Wave M-prose is a docs-only wave that depends on Wave M-design PASS so that authored prose references a locked design surface.
  • Wave S, G, L, Cl dispatch as a single parallel message (file-disjoint).
  • Wave T dispatches after Wave 0-Build PASS (test runs require build).
  • Tier 2 ADRs dispatch in a single parallel message after Wave 0-Build PASS.
  • Wave Z dispatches only after S, G, L, Cl, T all return verifier PASS.
  • R-1 through R-4 dispatch sequentially, each gated on the previous PASS plus ADR-State-intensity PASS.

Tier 0 — Build Blocker​

Wave 0-Build — Resolver Rename Propagation​

Goal: Propagate the StatResolver to ChannelResolver type rename to 9 benchmark files and 2 character-trainer Host files so dotnet build SECS.sln returns success.

Status: planned

Workflow: code wave

Ships​

Does Not Ship​

  • Any other engine refactor.
  • Any vocabulary cleanup.

Files Affected​

  • New files: none
  • Modified files:
    • benchmarks/SECS.Benchmarks/AllocationBenchmarks.cs — type-name update at all call sites.
    • benchmarks/SECS.Benchmarks/BenchmarkHost.cs — type-name update at all call sites.
    • benchmarks/SECS.Benchmarks/CachedHierarchicalBenchmarks.cs — type-name update at all call sites.
    • benchmarks/SECS.Benchmarks/CommandProcessBenchmarks.cs — type-name update at all call sites.
    • benchmarks/SECS.Benchmarks/HierarchicalBenchmarks.cs — type-name update at all call sites.
    • benchmarks/SECS.Benchmarks/HierarchicalScenario.cs — type-name update at all call sites.
    • benchmarks/SECS.Benchmarks/QueryBenchmarks.cs — type-name update at all call sites.
    • benchmarks/SECS.Benchmarks/ScenarioBuilder.cs — type-name update at all call sites.
    • benchmarks/SECS.Benchmarks/StatResolutionBenchmarks.cs — type-name update at all call sites.
    • examples/character-trainer/Host/Bridge/HostBridge.cs — type-name update at all call sites.
    • examples/character-trainer/Host/GameRuntime.cs — type-name update at all call sites.
    • examples/valenar/docs/implementation/code-sync-audit.md — mark blocker resolved.

Authorities​

Open Questions​

  1. Whether the rename is purely mechanical (s/StatResolver/ChannelResolver/g) or requires API-shape changes per call site — proposed answer: confirm by reading one call site before bulk-renaming.

Verification Forecast​

  • dotnet build SECS.sln succeeds.
  • dotnet test tests/SECS.Engine.Tests/SECS.Engine.Tests.csproj passes.

Parallelism​

None. Tier 0 gating wave; all other waves depend on this PASS.

Tier 1 — Vocabulary Cleanup Waves​

Wave S — Content and Engine Source Vocabulary Audit​

Goal: Audit Content/**/*.secs and src/SECS.*/**/*.cs for tokens listed in docs/design/behavior-vocabulary.md § Removed and lower the behavior-vocabulary baseline toward zero.

Status: planned

Workflow: docs-only wave (audit report only; recommends but does not perform code edits)

Ships​

  • Wave S subsections appended to pr-code-sync-audit.md § Content/ and § src/SECS.* enumerating every deprecated-vocabulary hit with file:line citations.
  • Recommendation on whether hits need a follow-up code-edit wave.

Does Not Ship​

  • Edits to any .secs or .cs source file.
  • Baseline changes.

Files Affected​

  • New files: none
  • Modified files:
    • examples/valenar/docs/implementation/code-sync-audit.md — append Wave S subsections.

Authorities​

Open Questions​

  1. Whether deprecated-vocabulary hits in Content/ can be fixed inline during Wave S or require a separate code wave with full Explore -> Implement -> Verify protocol — proposed answer: surface as a recommendation in the audit; do not fix inline.

Verification Forecast​

  • bash scripts/check-behavior-vocabulary.sh --check confirms hit count remains at or below the recorded baseline (currently 263).
  • Grep over new audit content confirms no inline deprecated tokens (cross-link references only).

Parallelism​

File-disjoint with G (Generated/**), L (Host/**, Server/**), Cl (Client/**). Dispatches in the same parallel message as G, L, Cl after Wave 0-Build PASS.

Wave G — Generated Provenance and Vocabulary Audit​

Goal: Audit Generated/**/*.cs for provenance-header correctness under the current generated-authority model: checked-in files must be explicit retained host-owned surfaces, while schema/catalog/helper output is compiler-owned under obj/**/SecsGenerated per .claude/rules/generated-codegen.md. Also audit for tokens listed in docs/design/behavior-vocabulary.md § Removed.

Status: planned

Workflow: docs-only wave

Ships​

Does Not Ship​

  • Edits to any Generated/**/*.cs file.
  • Provenance-header changes.

Files Affected​

  • New files: none
  • Modified files:
    • examples/valenar/docs/implementation/code-sync-audit.md — append Wave G subsection.

Authorities​

  • .claude/rules/generated-codegen.md — provenance-header rule.
  • docs/design/behavior-vocabulary.md — normative removed-token list.
  • scripts/check-behavior-vocabulary.sh — guard implementation.

Open Questions​

  1. Whether Generated/Vocabulary/Tags.cs still mirrors Content/common/tags.secs exactly — proposed answer: confirm by side-by-side diff in the audit.

Verification Forecast​

  • bash scripts/check-behavior-vocabulary.sh --check confirms hit count remains at or below the recorded baseline.
  • Grep over new audit content confirms no inline deprecated tokens.

Parallelism​

File-disjoint with S, L, Cl. Dispatches in the same parallel message.

Wave L — Host and Server Vocabulary Audit​

Goal: Audit Host/**/*.cs and Server/**/*.cs for tokens listed in docs/design/behavior-vocabulary.md § Removed and confirm TerritoryData.cs still uses the documented prototype field shape until ADR-State-intensity ships.

Status: planned

Workflow: docs-only wave

Ships​

Does Not Ship​

  • Code edits.

Files Affected​

  • New files: none
  • Modified files:
    • examples/valenar/docs/implementation/code-sync-audit.md — append Wave L subsections.

Authorities​

Open Questions​

  1. Whether Host/Activities/, Host/Combat/, and Host/Bridge/ consumers reference any deprecated combat vocabulary that the Wave D gd-combat-dungeon-screen.md patch did not propagate — proposed answer: scan and report.

Verification Forecast​

  • bash scripts/check-behavior-vocabulary.sh --check confirms hit count remains at or below the recorded baseline.
  • Grep over new audit content confirms no inline deprecated tokens.

Parallelism​

File-disjoint with S, G, Cl. Dispatches in the same parallel message.

Wave Cl — Client Vocabulary Audit​

Goal: Audit Client/src/**/*.ts and Client/src/**/*.tsx for tokens listed in docs/design/behavior-vocabulary.md § Removed, with attention to combat components since gd-combat-dungeon-screen.md was patched in Wave D.

Status: planned

Workflow: docs-only wave

Ships​

Does Not Ship​

  • TypeScript edits.

Files Affected​

  • New files: none
  • Modified files:
    • examples/valenar/docs/implementation/code-sync-audit.md — append Wave Cl subsection.

Authorities​

Open Questions​

  1. Whether gameStore.ts SignalR hub event names use deprecated nouns — proposed answer: scan and report.

Verification Forecast​

  • bash scripts/check-behavior-vocabulary.sh --check confirms hit count remains at or below the recorded baseline.
  • Grep over new audit content confirms no inline deprecated tokens.

Parallelism​

File-disjoint with S, G, L. Dispatches in the same parallel message.

Wave T — Tests and Guard Script Audit (Additive: CI / Validation Consolidation)​

Goal: Audit tests/**/*.cs and scripts/check-behavior-vocabulary.sh for tokens listed in docs/design/behavior-vocabulary.md § Removed and verify the script's GROUP_A_REGEX and GROUP_B_REGEX patterns are complete against the current § Removed list. Additive scope (Activity Detail / Nested Surface Alignment task): consolidate the canonical Valenar validation command set in one place and document the pre-existing behavior-vocabulary baseline drift between the historical 153 floor and the current 158 floor.

Status: shipped (docs-only).

Workflow: docs-only wave

Ships​

Does Not Ship​

  • Test fixture edits.
  • Test framework introduction (Vitest, Jest, RTL, Playwright, Cypress). The Valenar Client still has no JS test runner; introducing one is a separate setup wave.
  • New grep guards or grep-guard scripts.
  • Script changes — scripts/check-behavior-vocabulary.sh is left as-is; the baseline file is NOT rebaselined.
  • .github/workflows/wave-t-validation.yml edits — that workflow is pre-session drift, out of Wave T scope.
  • Python story audit edits (tests/valenar_story_audit/test_validate_story_docs.py).
  • .secs content changes to satisfy any test.

Files Affected​

  • New files: none
  • Modified files:
    • examples/valenar/docs/implementation/pr-code-sync-audit.md — appended Wave T subsections under ## tests/ and ## scripts/.
    • examples/valenar/docs/implementation/pr-wave-roadmap.md — this entry updated to record shipped status and additive scope.

Authorities​

Open Questions​

  1. GROUP_E_FILES / scan_exact_files() expansion — DEFERRED by Wave T. The bespoke gather_stat_channel_doc_files / gather_stat_channel_code_files pattern is sufficient; no generalized mechanism is required today.

Verification Forecast​

  • bash scripts/check-behavior-vocabulary.sh --check returns OK at 158 hits (= current baseline). Wave T does not lower the floor.
  • All canonical validation commands listed in pr-code-sync-audit.md § tests/ § Wave T § Canonical Validation Command Set pass at Wave T verifier time. dotnet test tests/Valenar.Host.Tests returns 219/219 PASS, including GeneratedTemplateFieldAssignmentsMirrorSecsTemplateBodies which the explorer brief incorrectly flagged as failing.

Parallelism​

Depends on Tier 0 (test runs require build). Sequential after Wave 0-Build; can run alongside S, G, L, Cl once they all start. Wave T shipped after Wave 0-Build PASS.

Wave Z — Baseline Reset to Zero (Gating Wave)​

Goal: After all Tier 1 audit waves (S, G, L, Cl, T) return verifier PASS, run bash scripts/check-behavior-vocabulary.sh --baseline to record the new floor. Target floor is 0 hits per .claude/rules/behavior-vocabulary.md line 67.

Status: planned

Workflow: code wave (records new baseline value)

Ships​

Does Not Ship​

  • Doc edits beyond the audit closure note.

Files Affected​

  • New files: none
  • Modified files:
    • scripts/.behavior-vocabulary-baseline — record new floor.
    • examples/valenar/docs/implementation/code-sync-audit.md — closure note.

Authorities​

  • .claude/rules/behavior-vocabulary.md — target end state of 0 hits.
  • scripts/check-behavior-vocabulary.sh — guard implementation.

Open Questions​

  1. Whether reaching exactly 0 is achievable in Wave Z or whether some allowlisted tokens are unavoidable — proposed answer: if the floor cannot reach 0, document why in the audit and lock at the achievable minimum.

Verification Forecast​

  • bash scripts/check-behavior-vocabulary.sh --check returns OK with 0 hits (or the achievable minimum with rationale recorded in the audit).

Parallelism​

Gating. Cannot dispatch until S, G, L, Cl, T all PASS.

Tier 2 — Architectural Decision Records​

ADR-Routine — Routine and Composite Activity Formalization​

Target file: docs/decisions/ADR-XXXX-routine-composite-activity.md (next available ADR number TBD; current numbered ADR is 0002).

Source question: pr-open-questions.md § Behavior Vocabulary — whether the normative bullet at docs/design/behavior-vocabulary.md line 28 introduced by Wave D needs ADR-level standing.

Rationale: Wave D added Routine Activity and Composite Activity as planning-layer sub-forms of activity via a one-line normative bullet. ADR-Routine elevates that to a full architectural decision record so future waves cannot quietly re-introduce a separate planning noun. The ADR documents that Routine Activity and Composite Activity are narrative sub-forms — not new SECS keywords, not new runtime nouns, not separate behavior kinds — and that the full SECS pipeline still treats them as ordinary ActivityRequest instances at execution time.

Dispatch dependency: after Wave 0-Build PASS; parallel with other Tier 2 ADRs and with Tier 1 waves (docs-only, no file overlap).

Tier 3 gate: none.

ADR-Terrain-tags — Terrain Tag Promotion Path​

Target file: docs/decisions/ADR-XXXX-terrain-tag-promotion.md

Source question: pr-open-questions.md § Tag Taxonomy — when the 19 planned terrain tags described in gd-territory-generation-contract.md should be promoted to committed TagId constants in Content/common/tags.secs.

Rationale: gd-tag-catalog.md separates committed tags (14) from planned tags (19). The promotion criterion — "when the production generator is in use" — is informal. ADR-Terrain-tags formalizes the threshold: which generator features must ship, which validation gates must pass, who decides. Without this, every Wave R-* implementer faces the same ambiguous decision.

Dispatch dependency: after Wave 0-Build PASS; parallel with other Tier 2 ADRs.

Tier 3 gate: none directly; informs Wave R-3 and R-4.

ADR-State-intensity — State-Axis Intensity Field Unification​

Target file: docs/decisions/ADR-XXXX-state-axis-intensity.md

Source question: pr-open-questions.md § State Axes — whether a unified progress / intensity field convention should be established across the Territory knowledge axis, Site state axis, and Feature discovery axis before any individual axis is implemented.

Rationale: Three open questions in pr-open-questions.md (intensity field name and scale for Territory, Site, Feature axes) share the same structural decision: what C# type, field name, and value range represent "how far along this axis is the entity." Implementing R-1, R-2, and R-3 with ad-hoc per-axis conventions would create three divergent intensity shapes that are harder to query, tooltip, and mod. The ADR resolves the unified convention (field name, scale, clamp behavior, wire representation) once.

Dispatch dependency: after Wave 0-Build PASS; parallel with other Tier 2 ADRs.

Tier 3 gate: Wave R-1, Wave R-2, and Wave R-3 all wait for this ADR.

ADR-Category-vs-tag — Feature Category vs Tag Unification​

Target file: docs/decisions/ADR-XXXX-feature-category-vs-tag.md

Source question: pr-open-questions.md § Feature Category vs Tag — whether Feature categories (currently a C# enum) should eventually be expressed as TagId constants, or remain as a separate enum.

Rationale: gd-tags-and-classification.md keeps Feature category (primary generation / budget bucket) and tags (overlapping metadata) on separate axes. The question of unification is open. ADR-Category-vs-tag decides: keep separate, unify under tags, or introduce a third concept. The decision shapes how Generated/Vocabulary/ is structured for future content drops.

Dispatch dependency: after Wave 0-Build PASS; parallel with other Tier 2 ADRs.

Tier 3 gate: none.

Tier 3 — Feature Implementation Waves​

Wave J — Journal Runtime Follow-Through​

Goal: Close the remaining Journal contract gap after the shipped baseline dedicated Journal query/version/client path and Journal/Chronicle separation. Wave J is now a follow-through wave for the deferred Journal items only: annotations and player notes, deeper Current Plan linking, richer site / lore-artefact / faction metadata, and any truly still-open Journal-only raw-log phrasing.

Status: planned

Workflow: code wave

Ships​

  • Follow-through on the already-shipped Journal baseline rather than first delivery of it.
  • Annotation and player-note support if the wave brief selects them in-scope.
  • Deeper Journal linking back into Current Plan where prior day context materially explains current pressure.
  • Richer Journal metadata for site, lore-artefact, and faction references.
  • Narrow wording cleanup only if readback verification still finds Journal-only raw-log phrasing residuals.
  • Updated pr-code-sync-audit.md to mark each shipped follow-through item closed.

Does Not Ship​

  • Re-implementing the already-shipped Journal query/version/client path.
  • Re-opening the raw-log versus Journal boundary that is already aligned at the accepted baseline.
  • Merging Chronicle combat chronology back into Journal.
  • Re-owning the shipped Core establishment -> camp-gated first settlement -> settlement-gated realm/governance/construction progression wording slice.
  • New Act 0 authored content or spoiler-revealing lore copy.
  • Combat Chronicle redesign beyond keeping Chronicle separate.
  • Quest-taxonomy simplification or any new runtime planning noun.

Files Affected​

  • New files: only if annotation/player-note support or richer metadata handling needs dedicated DTO / UI support; otherwise none.
  • Modified files:
    • examples/valenar/Host/**/* — Journal projection enrichment, metadata, annotation state, or deeper Current Plan linkage as selected by the wave brief.
    • examples/valenar/Server/**/* — Journal wire-shape changes only for the deferred follow-through fields that transit the server.
    • examples/valenar/Client/src/**/* — Journal UI follow-through, Current Plan linking, richer metadata presentation, annotation/player-note affordances, and any still-real Journal-only raw-log cleanup.
    • tests/Valenar.Host.Tests/* — coverage for whichever follow-through fields or behaviors the wave ships.
    • tests/Valenar.Server.Tests/* — wire-shape coverage for any new Journal payload fields that cross the hub.
    • examples/valenar/docs/implementation/pr-code-sync-audit.md — mark the targeted follow-through items closed.

Authorities​

Open Questions​

  1. Whether the next Journal follow-through ships system-authored annotations only or also ships player-authored notes on day pages — see pr-open-questions.md § Journal Follow-Through Scope.
  2. Whether deeper Current Plan linking and richer Journal metadata ship in one follow-through slice or as staged sub-slices under the same Wave J thread.

Verification Forecast​

  • dotnet build SECS.sln succeeds.
  • dotnet test tests/Valenar.Host.Tests/Valenar.Host.Tests.csproj passes.
  • dotnet test tests/Valenar.Server.Tests/Valenar.Server.Tests.csproj passes if new Journal payload fields cross the hub.
  • cd examples/valenar/Client && npx tsc --noEmit succeeds.
  • Manual spot-check confirms the existing Journal/Chronicle split remains intact and that any added follow-through fields or links behave as shipped.

Parallelism​

Depends on Wave 0-Build PASS. Do not dispatch in parallel with R-1 through R-4 or other Host/Server/Client implementation waves because the runtime and UI surfaces overlap.

Wave M-design — Act 0 Design-Doc Alignment​

Goal: Land the remaining gd-* design-doc follow-through required by ADR-0003's story-content-layer agent audit for Act 0 — Runtime Status language in gd-core.md and an authorial-only note in gd-act-0-arrival-and-core.md — without reopening already-aligned Core, Journal, or MC-classification authority docs.

Status: active (running concurrently with Wave D)

Workflow: docs-only wave

Ships​

  • Runtime Status section in gd-core.md recording the runtime / authorial split.
  • Authorial-only-note in gd-act-0-arrival-and-core.md marking it as design-document scope (not runtime-content scope).

Does Not Ship​

  • Re-opening the committed Corebound / Called / Hero / unmarked split, the higher-being mark-channel rule, or the soul-capacity growth rule.
  • Re-editing gd-glossary.md, gd-canon.md, or gd-journal.md unless a fresh ADR-0003 drift check finds new wording drift.
  • New ul-* or gl-* files.
  • Runtime, Content, Generated, Host, Server, Client, or test changes.
  • Authoring of Day-1 Journal entries or Act 0 mission internal monologue (that is Wave M-prose).

Files Affected​

  • New files: none
  • Modified files:
    • examples/valenar/docs/systems/gd-core.md — add Runtime Status section.
    • examples/valenar/docs/acts/gd-act-0-arrival-and-core.md — add authorial-only-note.

Authorities​

Open Questions​

  1. Whether the Runtime Status section in gd-core.md should mirror the exact wording adopted in gd-act-0-arrival-and-core.md or use a doc-specific phrasing — proposed answer: use doc-specific phrasing keyed off the same authority cite.

Verification Forecast​

  • Grep over the edited files confirms no deferred name was promoted, no new prefix file was introduced, and no runtime / Content / Generated file was touched.
  • Spot-check confirms gd-glossary.md, gd-canon.md, and gd-journal.md already reflect the committed Core / Journal / Corebound authority and did not require new edits.

Parallelism​

Docs-only. File-disjoint with Wave M-prose's target paths (story/accepted/**). Concurrent dispatch with Wave M-prose is permitted once both waves are planned and authorities are pinned.

Wave M-prose — Act 0 Authored Story Content​

Goal: Author Day-1 Journal entries and Act 0 mission internal monologue into story/accepted/ per ad-0003-story-content-layer-and-agent-audit.md, using the design surfaces locked by Wave M-design as the upstream authority.

Status: planned

Workflow: docs-only wave

Ships​

  • Day-1 Journal entries in examples/valenar/docs/story/accepted/ matching ADR-0003's accepted-content shape.
  • Act 0 mission internal-monologue prose in story/accepted/ keyed to the four quest-threads/gd-quest-thread-act-0-*.md design surfaces.
  • Single-authored accepted prose in story/accepted/ with no parallel duplicate-prose lane.
  • Update to pr-code-sync-audit.md noting which story-content surfaces are now populated.

Does Not Ship​

  • Re-opening the committed Corebound / Called / Hero / unmarked split, the higher-being mark-channel rule, or the soul-capacity growth rule.
  • Promotion of deferred names such as continent names, god names, the Hero Order name, or the Zone Wardheart name.
  • New ul-* or gl-* files.
  • Runtime, Content, Generated, Host, Server, Client, or test changes.
  • Glossary or canon rewrites; those authority surfaces are already aligned.
  • Global Hero -> Champion rename or any other vocabulary swap that contradicts the committed taxonomy.
  • Any second authored Journal prose lane.

Files Affected​

  • New files:
    • examples/valenar/docs/story/accepted/** — Day-1 Journal entries and Act 0 monologue prose authored under ADR-0003's accepted-content shape. Exact file list locked by the wave brief at dispatch time.
  • Modified files:
    • examples/valenar/docs/implementation/pr-code-sync-audit.md — record which story-content surfaces are now populated.

Authorities​

Open Questions​

  1. Whether Day-1 Journal entries author one accepted artifact per day or one per Journal entry — proposed answer: per Journal entry, to match gd-journal.md's day-page granularity.
  2. Whether mission internal-monologue prose lives in the same story/accepted/ subtree as Journal entries or a sibling subtree — proposed answer: sibling subtree, decided at wave dispatch from ADR-0003's directory layout.

Verification Forecast​

  • Grep over all new files in story/accepted/ confirms no early objective name uses a hidden-truth term, no Act 0 prose is omniscient, no MC is named "Hero" in a way that asserts canon, and no duplicate prose lane is authored alongside the accepted entry body.
  • Cross-link check confirms every prose file cites at least one Wave M-design-locked design surface, not a ul-* or gl-* source directly.
  • Authored prose does not reopen or rename the committed Corebound / Called / Hero / unmarked split, does not surface higher-being classification mechanics or soul/capacity doctrine above their allowed exposure ceiling, and does not promote deferred names.

Parallelism​

Docs-only. Depends on Wave M-design PASS so that the upstream design surface is locked before authored prose references it. File-disjoint with all Tier 1 audit waves and with the Tier 3 R-series waves.

Wave R-1 — Territory Knowledge Ladder Enum​

Goal: Add TerritoryKnowledgeState enum (Unknown / Sighted / Scouted / Surveyed / Secured / Claimed / Cleansed / Developed) and migrate examples/valenar/Host/Data/TerritoryData.cs from the prototype int Explored field to the enum plus the unified intensity field defined by ADR-State-intensity.

Status: planned

Workflow: code wave

Ships​

  • New TerritoryKnowledgeState enum.
  • Migrated TerritoryData.cs.
  • Updated Generated/Locations/ types.
  • SignalR wire shape updated.
  • Tests added.

Does Not Ship​

  • Site state changes (Wave R-2).
  • Feature thresholds (Wave R-3).

Files Affected​

  • New files: enum declaration in the canonical Generated/host territory module.
  • Modified files:
    • examples/valenar/Host/Data/TerritoryData.cs — migrate prototype field to enum + intensity.
    • examples/valenar/Generated/Locations/* — wire knowledge state through generated types.
    • examples/valenar/Server/Hubs/* — SignalR wire-shape updates.
    • examples/valenar/Client/src/* — consumer updates if the wire shape changes.
    • tests/Valenar.Host.Tests/* — test coverage.

Authorities​

Open Questions​

  1. Whether to migrate the SignalR wire shape in the same wave or in a follow-up Client wave — proposed answer: migrate in the same wave; the wire-shape change is part of the enum semantics.

Verification Forecast​

  • dotnet build SECS.sln succeeds.
  • dotnet test passes.
  • Manual spot-check that the React client renders the new ladder labels.

Parallelism​

Depends on ADR-State-intensity PASS. Sequential before Wave R-2.

Wave R-2 — Site State Intensity Field​

Goal: Add the unified intensity field (per ADR-State-intensity) to examples/valenar/Host/Data/SiteData.cs and examples/valenar/Generated/Locations/FeaturePlacement/FeatureContentTypes.cs § TerritoryContentState.

Status: planned

Workflow: code wave

Ships​

  • Intensity field on SiteData.
  • Updated TerritoryContentState consumers.
  • Tests.

Does Not Ship​

  • Feature thresholds (Wave R-3).

Files Affected​

  • New files: none
  • Modified files:
    • examples/valenar/Host/Data/SiteData.cs — add intensity field.
    • examples/valenar/Generated/Locations/FeaturePlacement/FeatureContentTypes.cs — update TerritoryContentState usage.
    • examples/valenar/Host/Systems/Sites/* — consumer updates if any.
    • tests/Valenar.Host.Tests/* — test coverage.

Authorities​

Open Questions​

  1. Whether TerritoryContentState should be split into a Feature axis and a Site axis or stay unified — proposed answer: stay unified per current design.

Verification Forecast​

  • dotnet build SECS.sln succeeds.
  • dotnet test passes.

Parallelism​

Depends on Wave R-1 PASS and ADR-State-intensity PASS. Sequential before Wave R-3.

Wave R-3 — Feature Numeric Intensity Thresholds​

Goal: Commit the threshold values from gd-state-axes-and-thresholds.md (currently design intent only) into examples/valenar/Generated/Locations/FeaturePlacement/ as committed values that score-and-budget Feature placement consumes.

Status: planned

Workflow: code wave

Ships​

  • Threshold constants in Generated/.
  • Updated Feature placement scoring.
  • Tests.

Does Not Ship​

  • The placement algorithm itself (Wave R-4).

Files Affected​

  • New files: none
  • Modified files:
    • examples/valenar/Generated/Locations/FeaturePlacement/* — commit threshold values.
    • examples/valenar/Host/Systems/Features/* — consumer updates if any.
    • tests/Valenar.Host.Tests/* — test coverage.

Authorities​

Open Questions​

  1. Whether thresholds are world-size-parameterized (per the numerical-thresholds-UI-exposed memory rule) or absolute — proposed answer: parameterize per Discipline 14.

Verification Forecast​

  • dotnet build SECS.sln succeeds.
  • dotnet test passes.

Parallelism​

Depends on Wave R-2 PASS, ADR-State-intensity PASS, Wave G PASS. Sequential before Wave R-4.

Wave R-4 — Score-and-Budget Feature Placement​

Goal: Replace the prototype random-sprinkle Feature placement with the score-and-budget algorithm described in gd-feature-generation-contract.md lines 1143-1169.

Status: planned

Workflow: code wave (significant Host system changes)

Ships​

Does Not Ship​

  • Changes to Feature category enum or tag taxonomy (those depend on ADR-Category-vs-tag).

Files Affected​

  • New files: none
  • Modified files:
    • examples/valenar/Host/Systems/Features/* — replace random-sprinkle with score-and-budget.
    • examples/valenar/Host/Data/FeatureData.cs — adjust shape if the algorithm requires it.
    • examples/valenar/Server/Hubs/* — wire-shape updates if any.
    • tests/Valenar.Host.Tests/* — test coverage.
    • examples/valenar/docs/implementation/code-sync-audit.md — closure note.

Authorities​

Open Questions​

  1. Whether the existing prototype should be kept as a fallback under a feature flag or replaced wholesale — proposed answer: replace wholesale per CLAUDE.md "no backwards compatibility" tenet.

Verification Forecast​

  • dotnet build SECS.sln succeeds.
  • dotnet test passes.
  • Manual spot-check that generated worlds have plausible Feature distributions.

Parallelism​

Depends on Wave R-3 PASS. Sequential.

Wave QP — Dynamic Quest Pressure Generator Runtime​

Goal: Implement the DynamicQuestPressureGenerator C# class that converts world-state source facts (Feature transitions, Territory knowledge advances, Site state changes, pressure escalation, settlement shortages, route safety, faction claims, NPC state, authored story gates) into planning-layer artifacts (objectives, clues/leads, mission candidates, urgency signals, consequence chains, Journal readback hooks) per the binding Generator Contract Rules in gd-dynamic-quest-pressure-model.md.

Status: planned

Workflow: code wave

Ships​

  • DynamicQuestPressureGenerator in Host/Systems/ or a dedicated Host/Planning/ subdirectory (exact path resolved at wave dispatch).
  • Causal source fact binding for every supported trigger in the Feature-Transition Trigger Table.
  • Deterministic urgency ranking for a given world-state snapshot.
  • Failure-forward consequence firing for ignored mission windows.
  • Budget and determinism guards (bounded generation per tick, validation hooks that fail loudly on contract violations).
  • Journal readback hook emission via the existing JournalReadModel / JournalEntryDraft surface.
  • Urgency signals fed into Current Plan urgency synthesis (the field extension for this lives in Read-Model Extensions — Wave QR).
  • Updated pr-code-sync-audit.md to mark the doc-runtime gap for gd-dynamic-quest-pressure-model.md closed.

Does Not Ship​

  • Cross-Act Lane Mission Ladders (Wave QL).
  • First Proof Slice authored content (Wave QF).
  • Read-Model Extensions beyond minimum journal hook wiring (Wave QR).
  • Quest Thread runtime objects — the generator emits artifacts, not thread-tracking state machines.

Files Affected​

  • New files:
    • examples/valenar/Host/Planning/DynamicQuestPressureGenerator.cs (or equivalent path under Host/Systems/)
    • tests/Valenar.Host.Tests/DynamicQuestPressureGeneratorTests.cs
  • Modified files:
    • examples/valenar/Host/ReadModels/ObjectivesReadModel.cs — extend ObjectiveLeadReadModel and ObjectiveMissionReadModel with source-fact fields per Wave QR scope overlap.
    • examples/valenar/Host/ReadModels/JournalReadModel.cs — add urgency source-fact reference field to JournalEntryReadModel if needed.
    • examples/valenar/docs/implementation/pr-code-sync-audit.md — mark gd-dynamic-quest-pressure-model.md gap closed.

Authorities​

Open Questions​

  1. Whether the generator runs as a SECS system (in the tick pipeline) or as a host-side service outside the engine pipeline — proposed answer: resolve at wave dispatch after confirming SECS v2 interface stability.
  2. Whether SECS v2 rewrite is stable before this wave starts (hard dependency on ISecsHostReads interface shape).

Verification Forecast​

  • dotnet build SECS.sln succeeds.
  • dotnet test tests/Valenar.Host.Tests/Valenar.Host.Tests.csproj passes.
  • Unit tests confirm determinism: same world-state snapshot produces same artifact set in same order.
  • Unit tests confirm contract guard: a generated mission without a causal source fact is rejected.
  • Pre-existing hardcoded Urgency: string stub values in ObjectivesReadModel.cs (e.g., "Important", "Survival", "Daylight only") must be REPLACED with generator-driven values, not preserved as fallback. A dual-field shape (old stub + new generator field, old used when generator output is null) is a silent fallback and violates the no-fallback tenet.

Parallelism​

Depends on Wave J PASS, Wave R-4 PASS, ADR-State-intensity PASS. Do not dispatch in parallel with other Host implementation waves.

Wave QL — Cross-Act Lane Mission Ladders​

Goal: Author the per-act Mission entry points for each of the seven cross-act Quest Thread lanes, wiring the first authored Mission rung for each lane in at least Act 0 and Act 1 so the dynamic quest pressure generator has concrete authored missions to escalate from or slot alongside emergent candidates.

Status: planned

Workflow: docs-only wave (authored content in quest-threads/ owner docs; no runtime code)

Ships​

  • Per-lane ## Mission Ladder section in each of the 7 cross-act lane owner docs under quest-threads/, with at least the Act 0 / Act 1 mission entry points specified.
  • Each mission entry satisfies the five Generator Contract Rules in gd-dynamic-quest-pressure-model.md (causal source fact, player-actionable contract, consequence-if-ignored, consequence-if-resolved, Journal readback hook).
  • Updated gd-quest-thread-index.md to note that mission ladders exist.

Does Not Ship​

  • Runtime generator code (Wave QP).
  • Client UI for mission-ladder display.
  • Acts 2-7 mission ladders (future content waves).

Files Affected​

  • New files: none
  • Modified files: 7 cross-act lane owner docs + gd-quest-thread-index.md

Authorities​

Open Questions​

  1. Whether the Mission Ladder section uses a structured frontmatter table per rung or free-form prose with the five contract fields called out explicitly — proposed answer: structured callout block per rung (matching the contract fields), resolved at wave dispatch.
  2. Whether authored mission rungs carry lane-scoped act_scope frontmatter or a separate per-rung metadata block.

Verification Forecast​

  • Grep confirms every mission rung in every ## Mission Ladder section contains all five Generator Contract Rule fields.
  • No mission rung uses a lane name or keyword outside the committed seven-lane set.
  • bash scripts/check-behavior-vocabulary.sh --check returns OK with no new hits.

Parallelism​

Depends on Wave QP PASS (runtime contract must be live before authored mission rungs are locked). Also depends on Wave M (act-doc cross-act sections) being complete so mission-entry anchors are available.

Wave QF — First Proof Slice (Act 0 / Early Act 1)​

Goal: Implement the concrete vertical slice described in gd-dynamic-quest-pressure-model.md § First Proof Slice — five world-state → quest walkthroughs (Water Feature, Food Feature, Old Stones Feature/Site clue, Pressure Feature, Shelter/camp pressure) — end to end: world state creates clues and objectives, mission candidates surface, player acts or ignores, world state changes, Journal records the change, Current Plan updates, and later generation cycles read the changed state.

Status: planned

Workflow: code wave

Ships​

  • All five First Proof Slice walkthroughs exercised and passing as automated tests.
  • Journal readback hooks fire for all five walkthroughs.
  • Urgency signals reach Current Plan for the Pressure Feature walkthrough.
  • Consequence-if-ignored fires and mutates world state for the Water Feature and Pressure Feature walkthroughs.
  • Updated pr-code-sync-audit.md with the proof-slice closure note.

Does Not Ship​

  • Full Acts 1-7 emergent coverage.
  • Client UI changes beyond wiring existing read-model fields.
  • New authored story prose.

Files Affected​

  • New files: tests/Valenar.Host.Tests/DynamicQuestFirstProofSliceTests.cs
  • Modified files: minimal Content/ or Host/ seeds + pr-code-sync-audit.md

Authorities​

Open Questions​

  1. Whether the five walkthroughs require new authored .secs content or whether the existing Content/ seed is sufficient for the test harness — proposed answer: audit Content/ at wave dispatch.
  2. SECS v2 stability dependency (same as Wave QP).

Verification Forecast​

  • dotnet test tests/Valenar.Host.Tests/Valenar.Host.Tests.csproj passes including the five new proof-slice tests.
  • Each test asserts: artifact emitted, world state changed by ignore consequence, Journal entry created, urgency signal updated.

Parallelism​

Depends on Wave QP PASS and Wave QL PASS. Sequential.

Wave QR — Read-Model Extensions for Dynamic Pressure​

Goal: Extend Journal, Current Plan, Objectives, and Territory Dossier read-models with the new fields needed to expose dynamic pressure source facts, urgency signals, and consequence chains to the client.

Status: planned

Workflow: code wave

Ships​

  • ObjectiveLeadReadModel extended with SourceFact: string (causal world-state fact) and LaneName: string (which of the 7 Quest Thread lanes this lead feeds).
  • ObjectiveMissionReadModel extended with SourceFact: string, ConsequenceIfIgnored: string, ConsequenceIfResolved: string, LaneName: string.
  • JournalEntryReadModel extended with SourceFact: string? (non-null for entries authored by the dynamic generator).
  • Current Plan urgency surface extended with a UrgencyItems: IReadOnlyList<UrgencyItemReadModel> projection (new read-model record with SourceFact, UrgencyRank, LaneName).
  • SignalR wire shape updated for the new fields.
  • Client TypeScript types updated.
  • Client hooks updated to surface urgency items.
  • Tests added for new projections.
  • Updated pr-code-sync-audit.md with closure notes.
  • Pre-existing hardcoded Urgency: string stub values in ObjectivesReadModel.cs (lines ~142, 163, 193 — "Important", "Survival", "Daylight only") MUST be replaced with generator-driven values, not co-existed alongside. The dual-field-with-fallback pattern is a silent fallback violation.

Does Not Ship​

  • New client UI components (existing Objectives and Current Plan components consume the new fields; no new component needed unless wave brief determines otherwise).

Files Affected​

  • New files: tests/Valenar.Host.Tests/DynamicPressureReadModelTests.cs
  • Modified files:
    • examples/valenar/Host/ReadModels/ObjectivesReadModel.cs
    • examples/valenar/Host/ReadModels/JournalReadModel.cs
    • examples/valenar/Server/Services/GameSnapshot.cs — wire-shape update.
    • examples/valenar/Client/src/api/types.ts — TypeScript type update.
    • examples/valenar/Client/src/stores/ — hook update.
    • examples/valenar/docs/implementation/pr-code-sync-audit.md

Authorities​

Open Questions​

  1. Whether the Current Plan urgency surface requires a new SignalR hub method or extends the existing snapshot — proposed answer: extend the existing snapshot.
  2. Whether LaneName is a raw string or a typed enum — proposed answer: string for now (matching the seven committed lane keys); promote to typed enum when Wave QL locks the lane set.

Verification Forecast​

  • dotnet build SECS.sln succeeds.
  • dotnet test tests/Valenar.Host.Tests/Valenar.Host.Tests.csproj passes.
  • dotnet test tests/Valenar.Server.Tests/Valenar.Server.Tests.csproj passes.
  • cd examples/valenar/Client && npx tsc --noEmit succeeds.

Parallelism​

Depends on Wave QP PASS. Can run in parallel with Wave QL and Wave QF once QP has shipped.

Activity Detail / Nested Surface Alignment Task​

This tier holds the wave entries for the Activity Detail / Nested Surface Alignment task. The task disambiguates from the vocabulary- cleanup story-layer waves above by carrying the (Activity Detail) task suffix on each wave entry. Outcomes for the shipped waves are recorded in pr-code-sync-audit.md § Activity Detail / Nested Surface Alignment.

Wave M (Activity Detail) — UX Owner Docs​

Goal: Ship 7 UX owner docs anchoring the Activity Detail / Nested Surface Alignment design contract: gd-shell-screen-model.md, gd-queue-screen.md, gd-territory-dossier.md, gd-current-plan.md, gd-objectives-screen.md, gd-journal.md, and gd-activity-catalog.md.

Status: shipped (docs-only).

Workflow: docs-only wave

Ships​

  • 7 owner docs under examples/valenar/docs/ux/ and examples/valenar/docs/catalogs/ each with an ## Implementation status section using the pr-status-and-sync-policy.md vocabulary.
  • Abstract "Wave B (Activity Detail)-owned, pending sync" phrasing for parent-run / child-run / blocked-reason references — intentional because Wave B (Activity Detail) had not yet committed field names at time of authoring.

Does Not Ship​

  • Committed DTO field names (Wave B (Activity Detail)-owned at the time).
  • Client component implementation (Wave C (Activity Detail)-owned).
  • Field-name sync (deferred to Wave B-sync (Activity Detail) below).

Files Affected​

  • New files:
    • examples/valenar/docs/ux/gd-shell-screen-model.md
    • examples/valenar/docs/ux/gd-queue-screen.md
    • examples/valenar/docs/ux/gd-territory-dossier.md
    • examples/valenar/docs/ux/gd-current-plan.md
    • examples/valenar/docs/ux/gd-objectives-screen.md
    • examples/valenar/docs/ux/gd-journal.md
    • examples/valenar/docs/catalogs/gd-activity-catalog.md
  • Modified files: none beyond the owner docs themselves.

Authorities​

Open Questions​

None at wave time. Field-name sync moved to its own scheduled wave; see Wave B-sync (Activity Detail) and pr-open-questions.md § Wave B Field-Name Sync in gd-* Docs.

Verification Forecast​

  • Owner docs render under the Valenar docs hub.
  • Each doc carries an ## Implementation status section.

Parallelism​

Docs-only; file-disjoint with all vocabulary-cleanup tier waves. Wave M (Activity Detail) is the upstream authority for Wave B (Activity Detail).

Wave B (Activity Detail) — Backend Fields, Scout Retirement, Demo Mods, Tests​

Goal: Project engine parent/child run linkage and server-truthful blocked-reason onto the wire surface; retire the legacy Scout lead identifier; retarget demo mods; add host-test coverage for the new projections.

Status: shipped (engine wave committed; field names committed; tests at 219/219 PASS).

Workflow: code wave

Ships​

  • ActivityRunSnapshot.ParentRunId : long? and ActivityRunSnapshot.ChildRunId : long? at Server/Services/GameSnapshot.cs:121–122.
  • QueueItemSnapshot.BlockedReason : string? at Server/Services/GameSnapshot.cs:224.
  • PlayerActivityQueueItemReadModel.BlockedReason : string? at Host/ReadModels/PlayerActivityQueueReadModel.cs:57.
  • TypeScript fields parentRunId?: number | null and childRunId?: number | null on the ActivityRunSnapshot type at Client/src/api/types.ts:663–664.
  • ScoutApproach activity WireId "scout-approach" at Generated/Activities/Character/Site/CharacterSiteActivities.cs:640.
  • Demo mods Generated/Mods/CompatScoutActivityMod.cs and Generated/Mods/ExtendedScoutActivityMod.cs retargeted to the committed ScoutApproach activity hash constant.
  • Engine commit e26c541: ActivityRun.Origin, ActivityRun.ParentRunId, ActivityRun.ChildRunId, ActivityExecutor.StartAt(ActivityRequest, TickContext, int).
  • Test files: tests/Valenar.Host.Tests/ActivityRunNestingProjectionTests.cs (2 tests) and tests/Valenar.Host.Tests/QueueProjectionBlockedReasonTests.cs (2 tests).

The locked field set is exactly parentRunId, childRunId, and blockedReason; Wave B (Activity Detail) did not expose other fields.

Does Not Ship​

  • Client surface for the new fields (Wave C (Activity Detail)-owned).
  • Field-name sync into the Wave M (Activity Detail) owner docs (deferred to Wave B-sync (Activity Detail)).
  • Recursive drill-stack UI (Wave C (Activity Detail)-owned).
  • JS test coverage (deferred to Wave Vitest).

Files Affected​

  • New files:
    • tests/Valenar.Host.Tests/ActivityRunNestingProjectionTests.cs
    • tests/Valenar.Host.Tests/QueueProjectionBlockedReasonTests.cs
  • Modified files:
    • src/SECS.Engine/Activities/ActivityRun.cs
    • src/SECS.Engine/Activities/ActivityExecutor.cs (and 26 other engine files in commit e26c541)
    • examples/valenar/Server/Services/GameSnapshot.cs
    • examples/valenar/Host/ReadModels/PlayerActivityQueueReadModel.cs
    • examples/valenar/Client/src/api/types.ts
    • examples/valenar/Generated/Activities/Character/Site/CharacterSiteActivities.cs
    • examples/valenar/Generated/Mods/CompatScoutActivityMod.cs
    • examples/valenar/Generated/Mods/ExtendedScoutActivityMod.cs

Authorities​

Open Questions​

None remaining. The "PASS-conditional on engine-wave commit" gate that Wave B (Activity Detail) carried at brief time is resolved by engine commit e26c541.

Verification Forecast​

  • dotnet build SECS.sln succeeds.
  • dotnet test tests/Valenar.Host.Tests/Valenar.Host.Tests.csproj returns 219/219 PASS.
  • cd examples/valenar/Client && npx tsc --noEmit succeeds.

Parallelism​

Sequential after Wave M (Activity Detail). Upstream for Wave C (Activity Detail).

Wave C (Activity Detail) — Shared Activity Detail Host and Openers​

Goal: Build the shared Activity Detail host component, the mc/activity-detail mode with rail hidden, the depth/cycle guards, and the wired openers across the Activities/Queue/LocationDossier/ BottomQueueSlots/Journal/Objectives surfaces; cleanup FocusedQueueItem and ActivitiesExpansion.{tsx,module.css}; propagate blockedReason through queueStore.

Status: shipped (2 openers deferred).

Workflow: code wave

Ships​

  • Directory Client/src/components/activity-detail/ carrying ActivityDetailHost.tsx, ActivityDetailHost.module.css, activityDetailRequest.ts, useActivityDetailViewModel.ts.
  • Mode mc/activity-detail with hiddenFromRail: true at Client/src/components/shell/modes.tsx:268,272.
  • hiddenFromRail?: boolean on ModeDef at Client/src/components/shell/modeDef.ts:118.
  • Depth guard ACTIVITY_DETAIL_MAX_DEPTH = 16 at activityDetailRequest.ts:84.
  • 7 logical openers across 9 caller sites (see pr-code-sync-audit.md § Wave C (Activity Detail) for the full caller-site enumeration).
  • Stage0ActivityPresentation.ts fallback cleanup (legitimate display deferral; cross-link to Wave T's blockedReason clarification).
  • FocusedQueueItem replacement (deleted).
  • ActivitiesExpansion.{tsx,module.css} deletion.
  • queueStore.mapQueueItem blockedReason propagation at Client/src/stores/queueStore.ts:197.

Does Not Ship (deferred to dedicated waves)​

  • TerritoryContextPanel name tap opener (source: 'context-panel'). Type union entry already declared at activityDetailRequest.ts:29; no caller wired. See Wave TerritoryContextPanel (Activity Detail).
  • Current Plan / Situations opener (source: 'plan'). Type union entry already declared at activityDetailRequest.ts:27; no caller wired. See Wave Plan (Activity Detail).
  • JS test coverage. See Wave Vitest.

Files Affected​

  • New files:
    • examples/valenar/Client/src/components/activity-detail/ActivityDetailHost.tsx
    • examples/valenar/Client/src/components/activity-detail/ActivityDetailHost.module.css
    • examples/valenar/Client/src/components/activity-detail/activityDetailRequest.ts
    • examples/valenar/Client/src/components/activity-detail/useActivityDetailViewModel.ts
  • Modified files:
    • examples/valenar/Client/src/components/shell/modes.tsx
    • examples/valenar/Client/src/components/shell/modeDef.ts
    • examples/valenar/Client/src/stores/queueStore.ts
    • examples/valenar/Client/src/components/modes/territory/stage0/Stage0ActivityPresentation.ts
    • examples/valenar/Client/src/components/activities/ActivitiesSummary.tsx
    • examples/valenar/Client/src/components/queue/QueueSummary.tsx
    • examples/valenar/Client/src/components/queue/QueueNavigator.tsx
    • examples/valenar/Client/src/components/queue/QueueExpansion.tsx
    • examples/valenar/Client/src/components/modes/territory/stage0/Stage0ActivityRows.tsx
    • examples/valenar/Client/src/components/queue/BottomQueueSlots.tsx
    • examples/valenar/Client/src/components/missions/MissionsExpansion.tsx
  • Deleted files:
    • examples/valenar/Client/src/components/activities/ActivitiesExpansion.tsx
    • examples/valenar/Client/src/components/activities/ActivitiesExpansion.module.css

Authorities​

  • Wave M (Activity Detail) owner docs.
  • Wave B (Activity Detail) — committed backend fields.

Open Questions​

  1. TerritoryContextPanel name tap opener wiring — see pr-open-questions.md § Activity Detail — Deferred Opener Decisions.
  2. Current Plan / Situations opener wiring — same section.

Verification Forecast​

  • cd examples/valenar/Client && npx tsc --noEmit succeeds.
  • dotnet build SECS.sln succeeds.
  • Manual spot-check that 7 logical openers route into the mc/activity-detail mode.

Parallelism​

Sequential after Wave B (Activity Detail). Upstream for the two deferred opener waves.

Wave T (Activity Detail) — CI / Validation Consolidation (additive scope)​

This entry is the additive Activity Detail / Nested Surface scope of the vocabulary-cleanup Wave T above. Wave T shipped both halves in a single docs-only pass; the full entry lives at § Wave T — Tests and Guard Script Audit (Additive: CI / Validation Consolidation).

Status: shipped (docs-only).

Wave TerritoryContextPanel (Activity Detail) — Context Panel Activity Detail Opener​

Goal: Wire the TerritoryContextPanel activity name tap to call open('left', ACTIVITY_DETAIL_MODE_ID, ...) with source: 'context-panel'.

Status: planned (deferred from Wave C (Activity Detail)).

Workflow: code wave (client-only)

Ships​

  • TerritoryContextPanel.tsx taps invoke the Activity Detail opener with source: 'context-panel', the appropriate activityId, locationId, and locationName.

Does Not Ship​

  • Backend changes (Wave B (Activity Detail) fields already cover the opener's data needs).
  • The Current Plan / Situations opener (Wave Plan (Activity Detail)).

Files Affected​

  • New files: none
  • Modified files:
    • examples/valenar/Client/src/components/map/TerritoryContextPanel.tsx
    • examples/valenar/docs/ux/gd-shell-screen-model.md — update implementation status row for the TerritoryContextPanel opener after the code ships.

Authorities​

  • Wave M (Activity Detail) owner doc gd-shell-screen-model.md.
  • activityDetailRequest.ts — 'context-panel' source value already declared in the ActivityDetailOpenerSource union.

Open Questions​

  1. Whether tapping an activity name should open Activity Detail inline (the current 'queue' and 'dossier' opener pattern) or first open a confirm-style inspect step. See pr-open-questions.md § Activity Detail — Deferred Opener Decisions.

Verification Forecast​

  • cd examples/valenar/Client && npx tsc --noEmit succeeds.
  • Manual spot-check: tapping an activity name on TerritoryContextPanel opens the mc/activity-detail mode with breadcrumb "Map" (or equivalent source label).

Parallelism​

Depends on Wave C (Activity Detail) PASS. Client-only; no parallel constraint with other Tier 3 waves beyond shared Client/components/map file scope.

Wave Plan (Activity Detail) — Current Plan / Situations Activity Detail Opener​

Goal: Wire the Current Plan / Situations surface to call the Activity Detail opener with source: 'plan'.

Status: planned (design-gated; deferred from Wave C (Activity Detail)).

Workflow: code wave (likely client-only; server-side TBD if the plan surface needs new activity references).

Ships​

  • Activity references in the Current Plan or Situations surface invoke the Activity Detail opener with source: 'plan', activityId, and any available locationId context.

Does Not Ship​

  • TerritoryContextPanel opener (Wave TerritoryContextPanel (Activity Detail)).

Files Affected​

  • New files: none
  • Modified files:
    • Current Plan / Situations component(s) — locate via gd-current-plan.md at wave dispatch time.
    • examples/valenar/docs/ux/gd-current-plan.md — update implementation status row after the code ships.

Authorities​

  • Wave M (Activity Detail) owner doc gd-current-plan.md.
  • activityDetailRequest.ts — 'plan' source value already declared in the ActivityDetailOpenerSource union.

Open Questions​

  1. Whether the Current Plan surface presents drillable activity references in the current client, or whether a separate design / implementation pass is needed before this wave can dispatch. See pr-open-questions.md § Activity Detail — Deferred Opener Decisions.

Verification Forecast​

  • cd examples/valenar/Client && npx tsc --noEmit succeeds.
  • Manual spot-check: tapping an activity reference in Current Plan or Situations opens the mc/activity-detail mode with breadcrumb "Plan".

Parallelism​

Depends on Wave C (Activity Detail) PASS plus a design-gate confirmation that the Current Plan surface exposes drillable activity references.

Wave B-sync (Activity Detail) — gd-* Doc Field-Name Sync​

Goal: Replace the abstract "Wave B (Activity Detail)-owned, pending sync" phrasing in the 7 Wave M (Activity Detail) owner docs with the committed Wave B (Activity Detail) field names (parentRunId, childRunId, blockedReason), and update each ## Implementation status table row whose status has changed since Wave M (Activity Detail) shipped.

Status: planned (docs-only; pending orchestrator decision on whether the field-name sync runs as a dedicated wave or folds into a future content-update wave). See pr-open-questions.md § Wave B Field-Name Sync in gd-* Docs.

Workflow: docs-only wave

Ships​

  • In each of gd-shell-screen-model.md, gd-queue-screen.md, gd-territory-dossier.md, gd-current-plan.md, gd-journal.md, gd-activity-catalog.md:
    • Replace abstract phrasing about parent-run / child-run / blocked- reason with the committed C# / TypeScript names.
    • Update ## Implementation status rows that previously said "Deferred, Wave B" for now-shipped items to "Current" with the committed field reference.
    • Preserve "Deferred, Wave C" status on rows whose runtime caller is still unwired (TerritoryContextPanel opener, Current Plan opener, recursive drill UI where applicable).

Does Not Ship​

  • Code changes.
  • New owner-doc sections.
  • Wave C (Activity Detail) deferred opener wiring (those have their own waves).

Files Affected​

  • New files: none
  • Modified files:
    • examples/valenar/docs/ux/gd-shell-screen-model.md
    • examples/valenar/docs/ux/gd-queue-screen.md
    • examples/valenar/docs/ux/gd-territory-dossier.md
    • examples/valenar/docs/ux/gd-current-plan.md
    • examples/valenar/docs/ux/gd-journal.md
    • examples/valenar/docs/catalogs/gd-activity-catalog.md

Authorities​

Open Questions​

  1. Whether the sync runs as one wave or splits per-doc to keep diff noise small.

Verification Forecast​

  • Zero occurrences of "Wave B-owned, pending sync" remain in the 6 modified docs.
  • All ## Implementation status rows that were "Deferred, Wave B" for now-shipped items read "Current" with field reference.
  • bash scripts/check-behavior-vocabulary.sh --check returns OK with no new hits introduced by the sync.

Parallelism​

Docs-only; file-disjoint with the TerritoryContextPanel and Plan opener waves.

Wave Vitest — JS Test Runner Setup for Valenar Client​

Goal: Introduce a JS test runner for examples/valenar/Client/src/ so the Activity Detail host component (Client/src/components/activity-detail/) and the view-model (useActivityDetailViewModel.ts) can carry JS unit-test coverage.

Status: planned (framework choice open — see pr-open-questions.md § Vitest / JS Test Setup).

Workflow: code wave

Ships​

  • examples/valenar/Client/package.json updated with the chosen runner and supporting testing libraries.
  • examples/valenar/Client/vite.config.ts (or equivalent) test config block.
  • First test file covering useActivityDetailViewModel.ts or ActivityDetailHost.tsx.

Does Not Ship​

  • Full client test coverage.
  • Playwright / Cypress end-to-end tests.

Files Affected​

  • New files:
    • examples/valenar/Client/src/components/activity-detail/useActivityDetailViewModel.test.ts (or similar)
  • Modified files:
    • examples/valenar/Client/package.json
    • examples/valenar/Client/vite.config.ts (or equivalent)

Authorities​

  • Wave T (Activity Detail) noted in pr-code-sync-audit.md: "the Valenar Client still has no JS test runner; introducing one is a separate setup wave."

Open Questions​

  1. Framework choice — Vitest + React Testing Library is the standard for Vite projects; the user has not committed to Vitest specifically. See pr-open-questions.md § Vitest / JS Test Setup.

Verification Forecast​

  • npm run test --prefix examples/valenar/Client exits 0.
  • cd examples/valenar/Client && npx tsc --noEmit continues to succeed.

Parallelism​

Independent of all other Activity Detail task waves. Can dispatch in parallel with Wave TerritoryContextPanel (Activity Detail), Wave Plan (Activity Detail), and Wave B-sync (Activity Detail).

Wave D (Activity Detail) — Implementation / Process Docs / Backlog Alignment​

Goal: Align the implementation / process docs and the backlog to record the M/B/C/T (Activity Detail) outcomes; add concrete deferred- item backlog entries for the two deferred openers, the field-name sync, and the JS test runner setup; update the runtime-state board.

Status: shipped (docs-only).

Workflow: docs-only wave

Ships​

  • New top-level section pr-code-sync-audit.md § Activity Detail / Nested Surface Alignment.
  • 7 new wave entries in this doc: Wave M (Activity Detail), Wave B (Activity Detail), Wave C (Activity Detail), Wave T (Activity Detail) cross-reference, Wave TerritoryContextPanel (Activity Detail), Wave Plan (Activity Detail), Wave B-sync (Activity Detail), Wave Vitest, and Wave D (Activity Detail) itself.
  • 3 new sections in pr-open-questions.md: deferred opener decisions, Wave B field-name sync question, Vitest / JS test setup framework choice.
  • pr-roadmap.md updates recording the shared Activity Detail host runtime surface and the field-name sync near- term consumer.

Does Not Ship​

  • Touches to the 7 Wave M (Activity Detail) gd-* owner docs.
  • Code, test, script, content, generated, engine source changes.
  • Baseline rebaseline.

Files Affected​

  • New files: none
  • Modified files:
    • examples/valenar/docs/implementation/pr-code-sync-audit.md
    • examples/valenar/docs/implementation/pr-wave-roadmap.md
    • examples/valenar/docs/implementation/pr-open-questions.md
    • examples/valenar/docs/implementation/pr-roadmap.md

Authorities​

Open Questions​

None at wave time. Resolved or deferred questions are recorded in the three pr-open-questions.md sections this wave added.

Verification Forecast​

  • bash scripts/check-behavior-vocabulary.sh --check returns OK at 158/158.
  • bash scripts/check-readonly-boundary.sh --check exits 0.
  • bash scripts/check-secs-source-contract.sh --check exits 0.
  • bash scripts/check-tag-contract.sh --check exits 0.
  • bash scripts/check-save-load-contract.sh --check exits 0.
  • bash scripts/check-activity-provenance-contract.sh exits 0.
  • git diff --name-only HEAD examples/valenar/docs/implementation/ shows only the 4 pr-* files modified.
  • git diff scripts/.behavior-vocabulary-baseline is empty.

Parallelism​

Docs-only; sequential after Wave M / B / C / T (Activity Detail) shipped. File-disjoint with all other planned waves.

Tier 4 — Territory Rename + Force Model Migration​

The Territory Rename and Force Model migration is governed by docs/adr/ad-0005-territory-rename-and-force-model.md. Wave D (Territory Rename) shipped the docs-only pass; subsequent waves (S/G/M/C/T with (Territory Rename) suffix) carry the rename across .secs source, compiler-owned Generated output, Host/Server runtime, Client, and tests. None of the (Territory Rename) waves have been dispatched.

Wave D (Territory Rename) — Docs, ADRs, Specs, Backlog Alignment​

Status: SHIPPED.

Goal: Rename four Valenar docs (gd-locations-features-sites.md → gd-territories-features-sites.md, gd-location-dossier.md → gd-territory-dossier.md, gd-location-generation-contract.md → gd-territory-generation-contract.md, gd-start-location-contract.md → gd-start-territory-contract.md); apply the Location → Territory substitution across every live design doc; commit four new system docs (gd-forces.md, gd-operations.md, gd-defense-zones.md, gd-fronts.md); add ADR-0005; add Fieldcraft and Technique Runtime Note sections to gd-character-skills.md and gd-queue-and-activity-execution.md; update .claude/rules/valenar-generation.md to reflect post-migration paths.

Workflow: docs-only wave (Explore → Implement → Verify).

Ships​

  • 4 doc renames performed via git mv.
  • 4 new design docs in examples/valenar/docs/systems/.
  • 1 new ADR (docs/adr/ad-0005-territory-rename-and-force-model.md).
  • Location → Territory substitution across all live design docs.
  • Closed Q1, Q3, Q4, Q5, Q6 in pr-open-questions.md.
  • .claude/rules/valenar-generation.md paths: glob updated.
  • pr-code-sync-audit.md Active Migration section recording the wave.

Does Not Ship​

  • Any .secs source rename (Wave S Territory).
  • Any Generated output rename (Wave G Territory).
  • Any Host/Server C# code rename (Wave M Territory).
  • Any Client TypeScript / React rename (Wave C Territory).
  • Any test rename or new tests (Wave T Territory).

Wave S (Territory Rename) — .secs Source Rename and Force Sources​

Status: planned

Goal: Rename Content/locations/ → Content/territories/; create Content/forces/ for Force scope and activity sources; create Content/characters/skills/fieldcraft.secs per ADR-0005 §7; update scope Character to carry the four new position fields per ADR-0005 §9 (long CurrentTerritoryId, long CurrentPlaceAnchorId, long CurrentSiteId, long CurrentSiteNodeId); update activity definitions to carry the optional TechniqueRef typed arg per ADR-0005 §8.

Workflow: code wave.

Parallelism: sequential after Wave D (Territory Rename) PASS.

Wave G (Territory Rename) — Compiler-Generated Territory Output Alignment​

Status: planned

Goal: Align compiler-emitted territory output under examples/valenar-v2/Generated/obj/**/SecsGenerated/*.g.cs with the Territory rename; keep checked-in examples/valenar-v2/Generated/ limited to Valenar.V2.Generated.csproj plus host-owned ValenarHostIds.cs; update LocationContentState → TerritoryContentState only through source/compiler authority; add compiler-owned output for Force, Operation, DefenseZone, Front, Fieldcraft, and TechniqueRef per the four new design docs. Do not plan renames for deleted top-level generated helper files.

Workflow: code wave.

Parallelism: sequential after Wave S (Territory Rename) PASS.

Wave M (Territory Rename) — Host and Server Rename + Force/Operation Runtime​

Status: planned

Goal: Rename LocationData → TerritoryData, LocationDossierReadModel → TerritoryDossierReadModel, GameWorld.CoreLocationId → GameWorld.CoreTerritoryId, GameWorld.IsCoreLocation → GameWorld.IsCoreTerritory; rename all internal field, parameter, and variable names that carry Location in their identifier; update SignalR DTOs and ReadModel projections; implement Force/Operation/DefenseZone/Front runtime per the four new design docs.

Workflow: code wave.

Parallelism: sequential after Wave G (Territory Rename) PASS.

Wave C (Territory Rename) — Client Rename and Force/Front UI​

Status: planned

Goal: Rename LocationContextPanel.tsx → TerritoryContextPanel.tsx, LocationPlanningBoard.tsx → TerritoryPlanningBoard.tsx, useLocationDossier.ts → useTerritoryDossier.ts, stage0LocationModel.ts → stage0TerritoryModel.ts, Client/src/components/modes/location/ → Client/src/components/modes/territory/; update capture scenarios in captures.md; update Zustand store keys; add UI surfaces for Force, Operation, DefenseZone, Front per the four new design docs.

Workflow: code wave.

Parallelism: sequential after Wave M (Territory Rename) PASS.

Wave T (Territory Rename) — Test Rename and Force/Territory/Fieldcraft Tests​

Status: planned

Goal: Rename test files and test data referencing the old Location* identifiers; add new tests for Territory, Force, Operation, DefenseZone, Front, Fieldcraft, and TechniqueRef dispatch per the four new design docs.

Workflow: code wave.

Parallelism: sequential after Wave C (Territory Rename) PASS.

Tier 5 — Foundation Hardening​

The Foundation Hardening is a multi-wave docs-and-runtime arc that closes the structural backing gap between Valenar's gameplay contracts and the live runtime surface. Each contract (Quest Threads / Missions, Pressure-to-Front emergence, Realm / PolityRank, Act progression, Province Defense Plans, Character Conditions, Labor / Capacity, Combat Contact Engagements, Generation Validation reports, the storyBias placeholder) is moved from "doc-only" to a fully backed runtime surface by running, in order: an audit wave that produces an ADR per contract family, a state-machine / primitives authoring wave that lands the design docs, a project-doc sync wave (this Wave 4), a source / Generated / lowering wave family, a runtime-backing wave, a test wave, and a final cross-artifact verification wave.

Governing ADRs: ad-0007, ad-0008, ad-0009, ad-0010, ad-0011, ad-0012, ad-0013.

Wave 0 (Foundation Hardening) — Scoping​

Status: completed.

Goal: Enumerate the foundation gaps across every gameplay contract, lock the per-wave breakdown, identify which subsystems require ADR-level decisions before authoring can resume, and record the wave-level dispatch graph.

Workflow: orchestrated explore / resolver / docs-only wave.

Ships​

  • Wave-level breakdown for Waves 0.5 through Final committed to the Foundation Hardening dispatch register.
  • Initial gap inventory: Quest Threads / Missions; Pressure-to-Front emergence; Realm / PolityRank; Act progression; Province Defense Plans; Character Conditions; Labor / Capacity; Combat Contact Engagements; Generation Validation; storyBias stub.

Does Not Ship​

  • Any contract authoring, runtime backing, or test work.

Wave 0.5 (Foundation Hardening) — Docs-Site Sync Fix​

Status: completed.

Goal: Repair the docs-site sync pipeline so contract additions made in legacy/v1/examples/valenar/docs/ propagate to the published mirror under docs-site/content/valenar/**. Without this fix, every Foundation Hardening contract addition would silently fail to reach the published documentation surface.

Workflow: code-and-docs wave (Explore -> Implement -> Verify).

Ships​

  • Working docs-site/scripts/sync-content.mjs against the current legacy/v1/examples/valenar/docs/ source layout.
  • npm run sync / prebuild regenerate the mirror correctly.

Does Not Ship​

  • Any contract authoring or audit. Pure pipeline fix.

Wave 2a (Foundation Hardening) — Quest / Front / Realm / Act Lore Audit and ADRs​

Status: completed.

Goal: Audit the lore and system docs against the Foundation Hardening gap list and produce the per-contract ADRs that lock the scope-and-state-machine decisions before any state-machine doc is authored. Cover Quest Threads and Missions, Pressure-to-Front emergence, Realm and PolityRank orthogonality, Act progression, and the True Harm placeholder convention.

Workflow: docs-only wave.

Ships​

Does Not Ship​

  • State-machine design docs (deferred to Wave 3a).
  • .secs source, Generated output, or runtime code.

Wave 2b (Foundation Hardening) — Conditions, Injuries, Archetype Pattern ADRs​

Status: completed.

Goal: Close the remaining ADR-level decisions for Character Conditions and Injuries (apply-as-Modifiers) and formalize the recurring Scope / State / Channel / Template archetype pattern that every Foundation Hardening contract family instantiates.

Workflow: docs-only wave.

Ships​

Does Not Ship​

  • State-machine design docs (deferred to Wave 3a).
  • Catalog content for specific conditions or injuries (deferred to Wave 3b).

Wave 3a (Foundation Hardening) — State-Machine and Primitives Authoring​

Status: completed.

Goal: Author the state-machine design docs that the Wave 2a / 2b ADRs called for. Land the four new state-machine families (Quest Thread + Mission lifecycle, ThreatSource + FrontCandidate emergence, Realm + PolityRank ladder, ActState progression) and the Province Defense Plan PlanState extension as committed design surface, each citing the governing ADR and each carrying the Runtime Backing Status block per .claude/rules/valenar-contract-backing.md.

Workflow: docs-only wave.

Ships​

  • New / patched system docs covering the four new state-machine families.
  • Quest Thread + Mission scope primitive design docs.
  • ThreatSource + FrontCandidate scope primitive design docs.
  • Realm + PolityRank ladder design docs.
  • ActState scope + Act-progression state-machine design docs.
  • ProvinceDefensePlan PlanState section in gd-defense-zones.md.
  • Glossary, canon, and README propagation per gate item 2 in .claude/rules/valenar-contract-backing.md.

Does Not Ship​

  • .secs source, Generated output, runtime code, or tests.

Wave 3b (Foundation Hardening) — Conditions Catalog and Labor Primitives​

Status: completed.

Goal: Author the Character Conditions and Injuries catalog (per ad-0012), the Labor and Capacity channel primitives doc, the ContactEngagement scope doc, and the ValidationReport host-type doc.

Workflow: docs-only wave.

Ships​

  • gd-character-conditions-and-injuries.md catalog rows plus apply/tend/clear Activity contracts.
  • gd-labor-and-capacity.md Settlement-scope and Province-scope channel families.
  • gd-combat-rules.md ContactEngagement scope section.
  • gd-generation-validation.md ValidationReport host-type surface.

Does Not Ship​

  • .secs source, Generated output, runtime code, or tests.

Wave 3c (Foundation Hardening) — System-Doc Cross-Cite Patches​

Status: completed.

Goal: Patch every pre-existing system doc that referenced one of the Foundation Hardening contracts to cite the new ADR and the new state-machine doc explicitly, replacing soft references with formal backing citations. Update navigation surfaces (README.md, the gd-canon.md index, the gd-glossary.md term table) to reflect the new committed primitives.

Workflow: docs-only wave.

Wave 4 (Foundation Hardening) — Project / Process Doc Sync (this wave)​

Status: in-progress (this wave).

Goal: Update Valenar project / process docs (pr-wave-roadmap.md, pr-code-sync-audit.md, pr-open-questions.md, pr-roadmap.md, pr-status-and-sync-policy.md) to reflect the Foundation Hardening structure, the new pending runtime surfaces, and the resolver decisions that closed or deferred Wave Q open questions.

Workflow: docs-only wave.

Ships​

  • This Tier 5 section in pr-wave-roadmap.md.
  • Pending-runtime-backing rows in pr-code-sync-audit.md § Pending Runtime Backing — Foundation Hardening for every Foundation Hardening contract surface that still needs Wave 5a / Wave 6 backing.
  • Q-OQ-1 through Q-OQ-5 closure / deferral notes in pr-open-questions.md.
  • Foundation Hardening entry in pr-roadmap.md.
  • Stage-vocabulary follow-up rename flag.

Does Not Ship​

  • Any .secs, Generated, runtime, or test work.
  • Any rename. The Stage-vocabulary overload is surfaced as a deferred follow-up per ad-0009 lines 98–105 and 219–230, NOT executed.

Wave 5a (Foundation Hardening) — Content / Generated Source for Quest, Front, Realm, Act, Conditions​

Status: planned.

Goal: Author the .secs source under legacy/v1/examples/valenar/Content/ for each Foundation Hardening contract family, plus matching generated output under legacy/v1/examples/valenar/Generated/.

Workflow: code wave.

Ships:

  • scope QuestThread, scope Mission plus QuestThread / Mission lifecycle channels and on_action labels.
  • scope ThreatSource, scope FrontCandidate plus emergence state-machine channels and on_action labels.
  • scope Realm plus PolityRank channel and ladder on_action labels.
  • scope ActState plus ActProgression channels.
  • ProvinceDefensePlan.PlanState channel addition to existing Province Defense Plan source / Generated rows.
  • Character Conditions and Injuries Modifier templates plus the apply / tend / clear Condition Activity templates per ad-0012.
  • Labor and Capacity channels at Settlement and Province scope.
  • ContactEngagement scope plus combat-rules channels.
  • storyBias formula or system replacing the FeaturePlacementQuery.cs:190 => 1.0 stub (per resolver R17 the stub becomes throw new NotImplementedException in this wave; the authored formula lands when the source-fact dependencies are resolved).
  • Matching generated output for every source addition above.

Workflow: code wave (Explore -> Implement -> Verify).

Parallelism: sequential after Wave 4 PASS.

Wave 5b (Foundation Hardening) — Generated Provenance and Compiler Lowering​

Status: planned.

Goal: Audit and patch every new generated output surface landed by Wave 5a for provenance-header correctness per .claude/rules/generated-codegen.md; ensure each new declaration row carries the correct source citation and the matching FNV-1a-64 H.* hash constant in compiler-owned generated output.

Workflow: code wave.

Parallelism: sequential after Wave 5a PASS.

Wave 5c (Foundation Hardening) — Compiler-Lowering Contract Coverage​

Status: planned.

Goal: Cross-check every compiler-owned generated output surface against the compiler-lowering contract in SECS-Compiler-Plan.md and .claude/rules/generated-codegen.md. Surface any lowering gap that the current SECS compiler still needs to emit but that the existing compiler-owned output does not yet express.

Workflow: docs-only wave (audit only; recommends but does not implement).

Parallelism: sequential after Wave 5b PASS.

Wave 6 (Foundation Hardening) — Runtime Backing​

Status: planned.

Goal: Add the host data classes, host systems, host bridge wiring, Server DTOs, and Client UI surfaces required to back the Wave 5a .secs source. Each Foundation Hardening contract family moves from contract-only to implemented (or, where partial, partial) per the runtime-backing-status vocabulary in .claude/rules/valenar-contract-backing.md.

Workflow: code wave.

Ships:

  • Host/Systems/QuestThreadSystem.cs, Host/Systems/MissionSystem.cs, matching Host/Data types.
  • ThreatSource / FrontCandidate host data + host system for the emergence pipeline.
  • Host/Data/RealmData.cs, Host/Systems/RealmRankSystem.cs plus the singleton-Realm wiring.
  • Host/Data/ActStateData.cs, Host/Systems/ActProgressionSystem.cs plus the Act 7 -> CampaignEnded transition per ad-0010.
  • ProvinceDefensePlan.PlanState read/write paths through HostBridge.
  • Character Conditions apply/tend/clear Activity execution paths in ActivityExecutor plus host code that attaches the apply-as-Modifier rows.
  • Labor / Capacity Settlement-scope and Province-scope channel resolution paths.
  • ContactEngagement scope read/write paths through HostBridge.
  • ValidationReport host type populated by the generation pipeline.
  • storyBias formula authored to consume real source-fact channels (the Wave 5a throw new NotImplementedException is replaced).
  • Server DTOs and Client UI surfaces for each new runtime field.

Parallelism: sequential after Wave 5b PASS; may run in parallel with Wave 5c where Wave 5c is purely audit and Wave 6 is purely runtime authoring.

Wave 7 (Foundation Hardening) — Tests​

Status: planned.

Goal: Author the tests under legacy/v1/tests/Valenar.Host.Tests/ and legacy/v1/tests/Valenar.Server.Tests/ that exercise the Wave 6 runtime surfaces. Cover state-machine transition predicates, on_action label firing, channel resolution shape, and read-model projection wire shape for each Foundation Hardening contract family.

Workflow: code wave.

Parallelism: sequential after Wave 6 PASS.

Wave Final (Foundation Hardening) — Cross-Artifact Verification​

Status: planned.

Goal: Run the cross-artifact verification gate across every Foundation Hardening contract family: confirm each contract carries the runtime-backing status block per .claude/rules/valenar-contract-backing.md; confirm every new adjudicator / runtime term landed in gd-glossary.md, gd-canon.md, and README.md; confirm every deferred dependency has a roadmap / open-question / code-sync entry; confirm no silent fallback survives in the runtime backing.

Workflow: docs-and-tests verification wave.

Parallelism: sequential after Wave 7 PASS.