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 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)
  • 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 (source citation, auto-generated marker, or no-source stand-in marker per .claude/rules/generated-codegen.md) and 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 LocationData.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​

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.

Status: planned

Workflow: docs-only wave

Ships​

Does Not Ship​

  • Test fixture edits.
  • Script changes (those require a separate governance wave).

Files Affected​

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

Authorities​

Open Questions​

  1. Whether the script's GROUP_E_FILES / scan_exact_files() expansion attempted in Wave D iter-1 is genuinely useful and warrants a separate ADR-gated governance wave — proposed answer: defer the question; surface in the audit.

Verification Forecast​

  • bash scripts/check-behavior-vocabulary.sh --check confirms hit count remains at or below the recorded baseline.
  • dotnet test passes (after Wave 0-Build).

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 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-location-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 Location 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 Location, 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: separate narration-safe readback text, 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.
  • Separate narration-safe readback text if that open question resolves in-scope.
  • Annotation and player-note support if that open question resolves 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 a deferred narration-safe or annotation surface 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 separate narration-safe readback text or keeps readable Journal prose only for now. Naming for any eventual runtime slots remains deferred — see pr-open-questions.md § Journal Readback And Annotation Implementation.
  2. Whether player-authored notes ship in the next Journal follow-through or whether the pass limits annotations to system-layer markers — see pr-open-questions.md § Journal Readback And Annotation Implementation.
  3. Whether deeper Current Plan linking and richer Journal metadata ship in one follow-through slice or as separate 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 gd-* design-doc updates required by ADR-0003's story-content-layer agent audit for Act 0 — Runtime Status section in gd-core-base.md, an authorial-only-note in gd-act-0-arrival-and-core.md, glossary and canon cross-link adjustments, and a runtime-constraint note in gd-journal.md.

Status: active (running concurrently with Wave D)

Workflow: docs-only wave

Ships​

  • Runtime Status section in gd-core-base.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).
  • Glossary and canon cross-link adjustments in gd-glossary.md and gd-canon.md that route MC-classification questions to the open-questions backlog rather than asserting a committed term.
  • Runtime-constraint note in gd-journal.md recording that Journal-prose authoring is gated by ADR-0003's accepted story-content surface and is not produced by free-text drafting in design docs.

Does Not Ship​

  • Promotion of any PROPOSED TERM (Corebound, Hero, Champion, Called, Vessel, Unmarked, soul-expansion mechanism, broad-learning-mechanism label) to committed canon.
  • New ul-* or gl-* files.
  • Runtime, Content, Generated, Host, Server, Client, or test changes.
  • Authoring of Day-1 Journal entries, Act 0 mission internal monologue, or voice-readback copy (that is Wave M-prose).

Files Affected​

  • New files: none
  • Modified files:
    • examples/valenar/docs/systems/gd-core-base.md — add Runtime Status section.
    • examples/valenar/docs/acts/gd-act-0-arrival-and-core.md — add authorial-only-note.
    • examples/valenar/docs/gd-glossary.md — adjust cross-links to point MC-classification questions at pr-open-questions.md.
    • examples/valenar/docs/gd-canon.md — adjust cross-links to point MC-classification questions at pr-open-questions.md.
    • examples/valenar/docs/ux/gd-journal.md — add runtime-constraint note on Journal-prose authoring.

Authorities​

Open Questions​

  1. Whether the Runtime Status section in gd-core-base.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 five edited files confirms no PROPOSED TERM was promoted, no new prefix file was introduced, and no runtime / Content / Generated file was touched.
  • Cross-link check confirms gd-glossary.md and gd-canon.md route MC-classification questions to pr-open-questions.md Q7 and Q10.

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, Act 0 mission internal monologue, and voice-readback copy 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/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.
  • Voice-readback copy in story/accepted/ that respects the voice-readback / audiobook practice referenced by ADR-0003 (no UI chips, no hidden-truth terms in early objectives, no omniscient Act 0 exposition).
  • Update to pr-code-sync-audit.md noting which story-content surfaces are now populated.

Does Not Ship​

  • Promotion of any PROPOSED TERM (Corebound, Hero, Champion, Called, Vessel, Unmarked, soul-expansion mechanism, broad-learning-mechanism label) to committed canon.
  • New ul-* or gl-* files.
  • Runtime, Content, Generated, Host, Server, Client, or test changes.
  • Glossary additions for Hero, Champion, Called, Vessel, or Unmarked — these remain blocked behind pr-open-questions.md Q10.
  • Global Hero -> Champion rename or any other vocabulary swap that has not been resolved in pr-open-questions.md first.

Files Affected​

  • New files:
    • examples/valenar/story/accepted/** — Day-1 Journal entries, Act 0 monologue prose, and voice-readback copy 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 composite voice-readback file 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 UI chip text is embedded in voice-readback prose.
  • Cross-link check confirms every prose file cites at least one Wave M-design-locked design surface, not a ul-* or gl-* source directly.
  • pr-open-questions.md Q7, Q10, Q11, Q12, Q13 remain proposed after Wave M-prose — none are silently closed by authored prose.

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 — Location Knowledge Ladder Enum​

Goal: Add LocationKnowledgeState enum (Unknown / Sighted / Scouted / Surveyed / Secured / Claimed / Cleansed / Developed) and migrate examples/valenar/Host/Data/LocationData.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 LocationKnowledgeState enum.
  • Migrated LocationData.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 location module.
  • Modified files:
    • examples/valenar/Host/Data/LocationData.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 § LocationContentState.

Status: planned

Workflow: code wave

Ships​

  • Intensity field on SiteData.
  • Updated LocationContentState 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 LocationContentState usage.
    • examples/valenar/Host/Systems/Sites/* — consumer updates if any.
    • tests/Valenar.Host.Tests/* — test coverage.

Authorities​

Open Questions​

  1. Whether LocationContentState 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.