Skip to main content

Open Questions

Status: living document — questions are added by waves and closed by user decisions or ADRs. Closed questions are moved to the relevant ADR or design doc rather than deleted from here. Status terms follow pr-status-and-sync-policy.md.

Purpose​

This document collects open questions that waves surface but that have not yet been resolved by user decision, ADR, or implementation. When a question is resolved, the implementer removes it from here and records the resolution in the relevant ADR, design doc, or decision note. Questions that span multiple waves belong here rather than in wave briefs, so that the wave brief stays focused on the wave's edits and the unresolved-question backlog stays visible across waves.

A question in this doc is not a TODO comment. It is a decision the project is consciously deferring because the answer requires either user input, an architectural decision worth its own ADR, or implementation evidence that is not yet available.

Wave D Decisions (Closed)​

The following questions raised by Wave 0 of the Territory rename / Force model migration were resolved by user decision at Wave D dispatch and are recorded in ../../../../docs/adr/ad-0005-territory-rename-and-force-model.md:

  • Q1 — File rename mode. Resolved: Full file-path migration approved per the Wave 0 manifest. Wave D handles docs renames; Waves S/G/M/C/T handle code renames. No backwards-compatibility aliases are preserved.
  • Q3 — Technique runtime. Resolved as Option C: Technique is a vocabulary token, not a runtime entity. Technique is not declared as a SECS scope and is not declared as a SECS template. Activities take an optional TechniqueRef typed arg. Skills feed channels that bias technique outcomes. Dispatch routes through on_action and channel resolution.
  • Q4 — Force/Operation/DefenseZone/Front split. Resolved: four separate files committed under examples/valenar/docs/systems/: gd-forces.md, gd-operations.md, gd-defense-zones.md, gd-fronts.md.
  • Q5 — Player position model. Resolved: four separate scalar fields on scope Character: long CurrentTerritoryId (required), long CurrentPlaceAnchorId (0 = none), long CurrentSiteId (0 = none), long CurrentSiteNodeId (0 = none). Replaces the prior single position scalar (the field formerly known as CurrentLocationId, renamed to CurrentTerritoryId and widened from int to long as part of this resolution). Wave S writes the .secs source.
  • Q6 — Right-click panel. Resolved: TerritoryContextPanel.tsx (not MapContextPanel). Wave C performs the React rename.

Behavior Vocabulary​

Wave D formalized Routine Activity and Composite Activity as planning-layer sub-forms of activity in docs/design/behavior-vocabulary.md and in systems/objectives-clues-missions.md. The remaining behavior-vocabulary questions are:

  • Whether Routine Activity and Composite Activity need their own ADR formalizing their sub-form status, or whether the behavior-vocabulary update in Wave D is sufficient. Today these terms are documented in the design doc's allowlist; they are not separately ADR'd. A future ADR may be desirable if downstream docs (combat doc, queue doc) need to refer to a single normative source for the sub-form distinction.

  • Whether the planning vocabulary doc should carry a section explaining when to use routine activity vs composite activity vs bare activity in player-facing prose. Wave D's rewrite uses the two sub-forms but does not enumerate concrete guidance on which to pick when authors are unsure. The vocabulary is currently governed by tone and context only.

See also: pr-wave-roadmap.md § ADR-Routine for the pending ADR stub.

Combat Screen Vocabulary​

Wave D renamed action_ref to activity_ref in ux/combat-dungeon-screen.md. Open questions:

  • Whether activity_ref is the correct field name for the renamed action_ref field in the behavior-branch template shape, or whether a different name (such as decision_ref or behavior_ref) is more appropriate for a template field holding a "which activity to fire" reference. The combat doc is a proposal, not part of the current client contract; the field name will be finalized when the proposal is implemented.

  • Whether the combat doc's existing behavior_ref field naming (used elsewhere in the same proposal for branch-bearing behavior templates) should be reconciled with activity_ref in a single pass when the proposal moves to implementation.

Tag Taxonomy​

catalogs/tag-catalog.md lists 14 committed tags and 19 planned terrain-derived tags. Open questions:

  • Whether the planned terrain tags in gd-territory-generation-contract.md need a unified registry doc beyond the tag catalog, or whether the current split (catalog enumerates committed + planned; design surface in systems/tags-and-classification.md) is sufficient.

  • When the terrain tags should be promoted from "planned" to committed Content. The promotion path is documented in the catalog, but the trigger condition (production generator readiness, specific generator features that need the tags) is not yet specified.

  • Whether the modifier-vs-structural-predicate split should be enforced syntactically (e.g., a separate valenar:modifier-tag/... namespace) or remain a convention. Today it is a convention.

  • Whether the "settlement-anchor" produced tag on the DormantNexus feature in examples/valenar-v2/Content/territories/features/dormant_nexus.secs should be renamed (candidate names: core-anchor, anchor-site) to match the committed Core Grounds wording, where the Nexus/Wardheart anchors the Core layer and the Settlement layer is a separate Act 2 step. The Core Grounds docs wave added a present-tense clarifying comment above the ProducedTags declaration so readers can distinguish the tag's site-suitability role from the Nexus's Core-anchor role, but the tag string itself was deliberately not renamed: the value participates in FeatureCapability.SettlementAnchor binding shape and any rename has runtime implications that belong to a content / runtime wave, not a docs-and-comment wave.

See also: pr-wave-roadmap.md § ADR-Terrain-tags for the pending ADR stub.

State Axes​

systems/state-axes-and-thresholds.md documents three axes, each with TBD elements. Open questions:

  • Numeric intensity field for the Territory knowledge axis: no committed enum yet; field name (surveyProgress or otherwise) is TBD; scale (0–100, 0–1, integer step count) is TBD.

  • Numeric intensity field for the Site state axis: RESOLVED by Wave R-2 (2026-05-10). Field name StateIntensity, type int, default 0. Bare integer per the unified convention established by R-1's KnowledgeIntensity. Lives on SiteData, hashed as H.StateIntensity, declared in Generated/Declarations.cs, and read/written through the Site branch of HostBridge. Tracks intensity on the State (progress ladder) axis, not on DiscoveryState. Numeric thresholds within each ladder label remain TBD per a future balance wave; wire projection (SiteSnapshot) is deferred to a future Server wave. See systems/state-axes-and-thresholds.md "Site State Axis" and pr-code-sync-audit.md.

  • Feature discovery intensity field: PARTIALLY RESOLVED by Wave R-3 (2026-05-10). Field foundation shipped: int DiscoveryIntensity on FeatureData, default 0, hashed as H.DiscoveryIntensity, declared in Generated/Declarations.cs, and read/written through the Feature branch of HostBridge. Bare integer per the unified convention established by R-1's KnowledgeIntensity and R-2's StateIntensity. Wire projection (FeatureSnapshot.discoveryIntensity) is deferred to a future Server wave, mirroring R-2's SiteSnapshot deferral. See systems/state-axes-and-thresholds.md "Feature Discovery Axis" and pr-code-sync-audit.md.

  • Feature discovery intensity thresholds (the 0–100 ranges per label): whether these become committed numeric thresholds or remain design-intent guidance. The authority doc explicitly defers these to a balance pass. Closing this requires a future balance-pass wave.

  • Whether a unified progress / intensity field convention should be established across all three axes before implementing them individually, so that the storage shape and the wire shape are consistent.

See also: pr-wave-roadmap.md § ADR-State-intensity for the pending ADR stub.

Feature Category vs Tag​

generation/feature-generation-contract.md defines Feature categories (NaturalResource, Water, Food, Forest, Mineral, etc.) separately from the tag vocabulary in Content/common/tags.secs. Open question:

  • Whether Feature categories should eventually be expressed as committed TagId constants (like the structural-predicate tags) or remain as a separate FeatureFamily enum. Today the two are intentionally distinct: categories drive generation placement; tags drive propagation filters and bulk modifier selection. The question is whether a future ADR should unify them so that propagation filters can use Feature category as a has_tag argument without an enum-to-tag translation step.

See also: pr-wave-roadmap.md § ADR-Category-vs-tag for the pending ADR stub.

Journal Follow-Through Scope​

gd-journal.md now commits the Journal record model, day-bucket organization, state-gate rule, Journal/Chronicle split, and the shipped baseline dedicated Journal query/version/client path. The remaining Journal questions are follow-through scoping questions for the next implementation slice, not first-pass model questions:

  • Whether the next Journal follow-through ships system-authored annotations only, or also ships player-authored notes on day pages.

  • Whether deeper Current Plan linking and richer site / lore-artefact / character / faction metadata ship in one follow-through slice or in staged sub-slices.

See also: pr-wave-roadmap.md § Wave J — Journal Runtime Follow-Through.

Universe-lore remaining deferred names (Wave U exploration)​

These entries track only names and bible-only naming decisions that remain genuinely deferred. Committed cosmology, Corebound classification, higher-being notice limits, and soul/capacity rules now live in the accepted authority files rather than in this backlog:

1. Continent names (deferred by Wave U)​

The universe lore established that multiple continents exist (ul-cosmology.md), but no continent names are committed. The Valenar starting Zone is on one continent whose name is deferred. Question: what are the committed continent names, and which continent hosts Game 1? Status: proposed (canon-tier question requiring user decision).

2. God names and domains (deferred by Wave U)​

ul-divine-layer.md confirms gods exist and the pantheon is plural, but no individual god names or domains are committed to canon (the Game 1 ceiling rule caps exposure at hinted). Question: what are the hard-canon god names in the universe bible, for internal consistency even if Game 1 never reveals them? Status: bible-only-tier decision requiring user input.

3. Hero Order name (deferred by Wave U)​

lh-game1-cosmology-hooks.md references "an organized order predated the current era" and notes it is not named in Game 1. Question: what is the committed internal name for the historical Hero Order (for bible-only use)? Status: bible-only-tier decision.

Closed by accepted authority docs (2026-05-13)​

The following were removed from the open-question backlog because the accepted authority docs now commit them directly:

Activity Detail — Deferred Opener Decisions​

Wave C (Activity Detail) shipped the shared Activity Detail host and 7 logical openers but deferred two opener integrations. The ActivityDetailOpenerSource union at examples/valenar/Client/src/components/activity-detail/activityDetailRequest.ts lines 23–32 already reserves both source values; no future syntax invention is needed. The openers are deferred because the host components that would call them do not yet invoke open('left', ACTIVITY_DETAIL_MODE_ID, ...).

1. TerritoryContextPanel name tap (source: 'context-panel')​

TerritoryContextPanel at examples/valenar/Client/src/components/map/TerritoryContextPanel.tsx renders activity availability for the selected territory. Tapping an activity name should open Activity Detail with source: 'context-panel'. The opener source value is declared at activityDetailRequest.ts:29; no caller is wired today.

Prerequisites: none from Wave B / Wave C (Activity Detail). The backend fields and the shared host are already live. Acceptance: TerritoryContextPanel tapping an activity name calls open('left', ACTIVITY_DETAIL_MODE_ID, makeActivityDetailRequest({ activityId, source: 'context-panel', sourceLabel: 'Map', territoryId, territoryName }), 'wide').

Open sub-question: whether the tap inspect-before-queue UX (a confirm step before opening) is needed, or whether the inline-open pattern that 'queue' and 'dossier' openers already use is the correct shape. Wave D (Activity Detail) defers this UX decision to the implementer of Wave TerritoryContextPanel (Activity Detail).

2. Current Plan / Situations opener (source: 'plan')​

The Current Plan surface (gd-current-plan.md) describes Activity Detail drill-in from the plan / situations context. The 'plan' source value is declared at activityDetailRequest.ts:27 but no caller is wired today.

Prerequisites: none from Wave B (Activity Detail); the Current Plan surface itself must present drillable activity references before this opener can wire. Acceptance: an activity reference in Current Plan or Situations calls the opener with source: 'plan', activityId, and the appropriate territoryId context.

Open sub-question: whether Current Plan presents drillable activity references in the current client surface, or whether a design / implementation pass is needed first. Wave D (Activity Detail) flags this as a design-gate blocker for Wave Plan (Activity Detail) so the orchestrator confirms the Current Plan readiness before dispatching.

See also: pr-wave-roadmap.md § Wave TerritoryContextPanel (Activity Detail) and pr-wave-roadmap.md § Wave Plan (Activity Detail).

Wave B Field-Name Sync in gd-* Docs​

Wave M (Activity Detail) owner docs use abstract phrasing — "the parent-run / child-run reference Wave B (Activity Detail) exposes — Wave B-owned, pending sync" — because Wave B (Activity Detail) had not yet committed field names at the time of authoring. Wave B (Activity Detail) has since committed the field names in HEAD:

  • C#: ActivityRunSnapshot.ParentRunId : long?, ActivityRunSnapshot.ChildRunId : long?, QueueItemSnapshot.BlockedReason : string?, PlayerActivityQueueItemReadModel.BlockedReason : string?.
  • TypeScript: parentRunId?: number | null, childRunId?: number | null, blockedReason?: string | null on the corresponding snapshot and queue-item types.

Open question: should the gd-* owner docs (gd-shell-screen-model.md, gd-queue-screen.md, gd-territory-dossier.md, gd-current-plan.md, gd-journal.md, gd-activity-catalog.md) be synced to replace the abstract phrasing with the committed names, and have their ## Implementation status rows updated from "Deferred, Wave B" to "Current" or to "Deferred, Wave C" depending on whether the runtime caller is wired?

Wave D (Activity Detail) deferred this work to a dedicated wave rather than absorbing it into a Wave D-Detail docs-only scope. The proposed wave is Wave B-sync (Activity Detail) in pr-wave-roadmap.md. The decision the orchestrator owes:

  1. Dispatch Wave B-sync (Activity Detail) as a dedicated docs-only wave.
  2. Fold the sync into a future content-update wave (e.g., the next Wave M-prose or Wave J slice that already touches these files).
  3. Split per-doc to keep diff noise small.

The default Wave D (Activity Detail) recommendation is option 1 (a dedicated wave) because the 7 gd-* docs are file-disjoint with all current Tier 1, Tier 2, and Tier 3 waves and a focused docs-only wave is the lowest-risk path.

See also: pr-wave-roadmap.md § Wave B-sync (Activity Detail).

Vitest / JS Test Setup​

Wave T noted (per pr-code-sync-audit.md § tests/ § Wave T): "the Valenar Client still has no JS test runner; introducing one is a separate setup wave." No vitest or jest runner is present in examples/valenar/Client/package.json. The Activity Detail host component (ActivityDetailHost.tsx) and its view-model (useActivityDetailViewModel.ts) are the highest-priority candidates for a JS unit-test suite — the nesting / drill-stack logic, the depth guard, and the breadcrumb derivation are all pure functions amenable to fast unit tests.

Open question: which test framework, what directory layout, and what is the acceptance bar for the setup wave? Vitest + React Testing Library is the standard choice for Vite projects, but the user has not committed to Vitest specifically.

This needs a dedicated Wave Vitest entry decision before the wave is dispatched:

  1. Framework choice — Vitest + React Testing Library is the recommended default; Jest + React Testing Library is the legacy alternative.
  2. Directory layout — colocate .test.ts files next to source, use a sibling tests/ directory, or use a top-level Client/tests/.
  3. Acceptance bar — one passing test on the Activity Detail view-model, or a broader coverage threshold? Wave D (Activity Detail) recommends one passing test as the minimum bar so the runner ships without scope creep.

See also: pr-wave-roadmap.md § Wave Vitest.

Wave Q — Dynamic Quest Pressure and Cross-Act Lanes​

Wave Q (Dynamic Quest Pressure and Cross-Act Lane Architecture) shipped the docs-only contract for state-driven quest pressure and the seven cross-act Quest Thread lanes. Four user decisions (Q1–Q4) are formalized in ad-0006-dynamic-quest-pressure-and-cross-act-lane-decisions.md. The following questions remain open and span the planned Waves QP, QL, QF, and QR runtime entries in pr-wave-roadmap.md.

Q-OQ-1: Saga Arc taxonomy clarification​

The Saga Arc sits above the seven cross-act Quest Thread lanes (Core/Truth, Survival/Settlement, Pressure/Corruption, People/Retinue, Faction/Polity, Rune/Crafting/True Harm, Reclamation/Crown). Q3 locked the lanes as Quest Threads with act_scope: cross-act; the Saga Arc itself remains the multi-act outcome surface above the lanes.

Open question: whether the Saga Arc should be promoted from an implicit narrative envelope to a committed vocabulary tier in gd-quest-and-lore-design.md, or whether the existing Act Arc + cross-act Quest Thread + saga-spanning qualifier triple is sufficient to describe end-game framing without a new tier name. The Q3 decision (no new tier) governs the cross-act lane case; this question concerns whether the saga-final outcome surface needs a separate label.

Status: CLOSED by Foundation Hardening ad-0007-quest-thread-and-mission-scope-primitives.md (2026-05-17). Cross-act lanes remain Quest Threads with act_scope: cross-act; no new tier is introduced. The saga-final outcome surface is owned by the existing Quest Thread / Mission state-machine plus the Act 7 -> CampaignEnded transition committed by ad-0010-act-progression-actstate-scope.md; no separate "Saga Arc" label is promoted.

See also: pr-wave-roadmap.md § Wave QL and pr-wave-roadmap.md § Wave QF.

Q-OQ-2: Boundary between Local Quest and Mission for emergent vs authored quests​

gd-objectives-clues-missions.md defines Local Quest and Mission as adjacent planning-layer artifacts. The dynamic quest pressure generator (Wave QP) emits mission candidates from world-state source facts. Wave QL authors per-lane Mission rungs.

Open question: whether emergent generator output and authored mission rungs share the same artifact kind (Mission) at runtime, or whether the emergent form should be classified as Local Quest and the authored form as Mission, so the player-facing distinction is preserved in the read-model. The current proposal is one kind (Mission) for both, with the source-fact field marking emergent provenance; the alternative is two kinds with separate UI affordances.

Status: CLOSED by Foundation Hardening resolver decision R1 (2026-05-17), formalized in ad-0007-quest-thread-and-mission-scope-primitives.md. Single Mission scope at runtime; the source-fact field marks emergent vs authored provenance; player-facing distinction is carried by read-model projection, not by a separate scope kind.

See also: pr-wave-roadmap.md § Wave QP and pr-wave-roadmap.md § Wave QR.

Q-OQ-3: Global consequence chain depth budget​

The Generator Contract Rules require each generated mission to declare a consequence-if-ignored chain. Chained consequences may themselves trigger further mission candidates (a feature transition fires a consequence, which mutates world state, which the generator reads next tick, which emits new candidates). Without a depth bound, a single ignored mission window can in principle cascade indefinitely.

Open question: what global depth budget bounds consequence chains? Per the no-fallback tenet, a chain that exceeds the budget must fail loudly (throw, log, reject) rather than silently truncate. The proposed answers are (a) a per-tick budget on total consequences fired, (b) a per-chain depth budget, or (c) both. The exact numeric values must be exposed as world-size-parameterized Config fields per the numerical-thresholds-UI-exposed discipline, not hardcoded constants.

Status: deferred to Wave 5a runtime backing (Foundation Hardening). The Quest Thread / Mission scope primitives committed by ad-0007-quest-thread-and-mission-scope-primitives.md fix the cardinality and lifecycle of the artifacts a consequence chain can touch; the chain-depth budget itself remains a balance-pass decision pending Wave 5a / Wave 6 runtime evidence and cannot be resolved without that evidence. The budget will land as world-size-parameterized Config fields, not hardcoded constants.

See also: pr-wave-roadmap.md § Wave QP and pr-wave-roadmap.md § Wave QF.

Q-OQ-4: Urgency Signal Contract numeric vs qualitative ranking​

gd-dynamic-quest-pressure-model.md § Urgency Signal Contract defines urgency signals that surface from world-state pressure into Current Plan. Wave QR commits the UrgencyRank field shape.

Open question: whether UrgencyRank is a numeric scalar (0–100, or a fixed-point integer per the unified-intensity convention from ADR-State-intensity) or a qualitative ordinal enum (e.g., Background / Watch / Pressing / Critical). Numeric supports sort, weighting, and balance passes; qualitative supports stable player-facing labels. The proposed answer is numeric with a qualitative label projection derived from threshold ranges, so the two surfaces stay in sync; the qualitative label set is the open part.

Status: deferred to Wave 5a runtime backing (Foundation Hardening). The QuestThread / Mission scope primitives in ad-0007-quest-thread-and-mission-scope-primitives.md do not pre-commit the UrgencyRank channel shape; that channel lands in Wave 5a alongside the rest of the Quest Thread / Mission channels. Numeric vs ordinal will be resolved at that authoring point.

See also: pr-wave-roadmap.md § Wave QR.

Q-OQ-5: Reclamation/Crown lane resolution and end-game state surface​

The Reclamation/Crown Quest Thread lane runs the full Saga Arc and resolves only when the saga concludes (per the Q3 decision recorded in ad-0006-dynamic-quest-pressure-and-cross-act-lane-decisions.md). Reclamation outcomes (crown founding, polity advancement, regional recovery) cascade into other lanes and into the world-state pressure surface.

Open question: what runtime surface owns the end-game saga-resolution state for the Reclamation/Crown lane? The candidates are (a) a new SagaResolutionReadModel projection that surfaces the lane's final arc, (b) overload of the existing gd-realm-ranks-and-polity.md realm rank surface, or (c) a Journal-only readback with no separate read-model. The proposed answer is (a) a dedicated read-model; finalization depends on Wave QL's authored mission rungs and Wave QF's proof-slice tests.

Status: partly CLOSED by Foundation Hardening ad-0010-act-progression-actstate-scope.md (2026-05-17); remainder deferred. The Act 7 -> CampaignEnded transition committed by ad-0010 owns the saga-resolution state transition; the Reclamation/Crown lane resolves through that transition rather than through a separate SagaResolutionReadModel. The apex-demon resolution shape (the specific scope-state row that records the apex-demon outcome at Act 7 -> CampaignEnded) remains deferred per ad-0011-true-harm-placeholder-convention.md and the Act 7 gate spec's <TBD:ApexDemonResolutionStateId> marker. Closing the remainder requires a future user decision on the apex-demon resolution shape; it is not a runtime-backing wave decision.

See also: ../quest-threads/gd-quest-thread-reclamation-crown.md, pr-wave-roadmap.md § Wave QL, and pr-wave-roadmap.md § Wave QR.

Foundation Hardening — Deferred Items​

The Foundation Hardening (see pr-wave-roadmap.md § Tier 5 — Foundation Hardening) authored the ADR-level decisions and the state-machine / primitives design docs for Quest Thread / Mission, Pressure-to-Front emergence, Realm / PolityRank, Act progression, Province Defense Plan PlanState, Character Conditions and Injuries, Labor / Capacity, Combat ContactEngagement, Generation Validation, and the storyBias placeholder. The following items remain explicitly deferred to later Foundation Hardening waves and must not be silently resolved by an authoring agent picking a default.

Q-FH-1: Per-act gate predicate balance-pass numbers​

Each Act gate spec (gd-act-0-arrival-and-core.md through gd-act-7-*.md plus the Act 7 gate spec referenced by ad-0010-act-progression-actstate-scope.md) declares structural gate predicates (e.g., "first Settlement founded", "Province rank reached", "apex-demon resolution stage fired"). Numeric thresholds within those predicates (population counts, pressure thresholds, polity-tier counts, defense-plan coverage percentages) are design intent, not committed values.

Status: deferred to Wave 5a / Wave 6 balance-pass authoring. Numeric values must be exposed as world-size-parameterized Config fields per the numerical-thresholds-UI-exposed discipline. No hardcoded constants. No silent default if a predicate is unsatisfied — the gate must report the missing-predicate state explicitly.

Q-FH-2: Force / Front / Operation transition predicates​

ad-0008-pressure-to-front-emergence-scope-state-machine.md committed the ThreatSource + FrontCandidate scope primitives and the emergence state machine that lifts a pressure source into a Front. The exact predicates that fire the state-machine transitions (the pressure thresholds, the contact frequency thresholds, the reclamation-pressure thresholds that re-quiesce a Front) were locked structurally but not numerically. Per Foundation Hardening resolver decision R13 (hybrid: structural commitments now, numeric commitments in Wave 5a / Wave 6), the transition predicates remain deferred.

Status: deferred to Wave 5a / Wave 6 per resolver R13. Closure requires runtime evidence from the Wave 6 host system; no balance-pass authoring may pick numeric defaults before that evidence exists.

Q-FH-3: storyBias formula authoring​

gd-feature-generation-contract.md § Placement Formula lists storyBias as a placement-score multiplier. Today, legacy/v1/examples/valenar/Generated/Territories/FeaturePlacement/FeaturePlacementQuery.cs:190 returns => 1.0 as a silent stub. Per Foundation Hardening resolver decision R17, the silent stub is a tenet violation (silent fallback) and must be replaced. The R17 sequence is:

  1. Wave 5a: replace => 1.0 with throw new NotImplementedException so the absence of the formula fails loudly, per the no-fallback rule.
  2. Wave 5a / Wave 6: author the storyBias formula consuming real source-fact channels once the channel sources required by the formula land.

Status: deferred to Wave 5a runtime backing per resolver R17. No authoring agent may resolve this open question by picking a placeholder formula. The current => 1.0 value is an illegal silent default and must not be replaced by another silent default.

Q-FH-4: Stage-vocabulary rename (Settlement.Stage vs Act-stage)​

ad-0009-realm-scope-and-polity-rank-orthogonality.md (lines 98–105 and 219–230) flags the Stage-vocabulary overload as a follow-up rename concern. The Settlement.Stage per-Settlement population-size ladder and the Act-progression "stage" wording in the ../acts/README.md tree share the English word "stage" with two unrelated meanings.

Per the no-fallback redesign-propagation rule and the file-rename stop in .claude/rules/orchestrator-mode.md, the rename requires a separate deliberate migration prompt naming exact source and destination paths (gd-settlements-and-outposts.md, the ../acts/gd-act-*.md docs, the Settlement.Stage Generated declarations, the React client UI labels).

Status: deferred — awaiting deliberate migration prompt. Foundation Hardening waves do NOT execute this rename. ad-0009 commits the orthogonality decision and flags the rename; Wave 4 of the Foundation Hardening surfaces it as a follow-up; no Foundation Hardening wave resolves it.

Process And File Layout​

1. ADR placement for gd-* files within docs/lore/ vs staying in flat directories​

Wave D's ADR (ad-0002-lore-docs-migration.md) resolves the deferral from pr-file-conventions.md line 39 by keeping gd-* files in their existing subdirectories. This is a Wave D decision. Question: is there any future driver to move gd-* files into a docs/lore/gd/ subtree? Current answer: no — the implementer's decision is to stay in-place. RESOLVED by Wave D ADR (2026-05-10). Closing this question; the resolution lives in ad-0002.

2. current-ux/ directory prefix scope​

Wave D renames only SCREENSHOTS_REFRESH.md (now pr-screenshots-refresh.md) in current-ux/. The screenshot PNG files and stage-0-mockups/ HTML are binary/non-md assets and are not renamed. Question: should a future wave establish a naming convention for the screenshot manifest files, or is the ad-hoc Playwright capture approach the permanent pattern? Status: open.

Wave S — Syntax Migration Deferrals​

1. One-shot cadence author-facing form​

frequency once; has been removed from Content/world/systems/map_generation.secs. The committed author-facing one-shot syntax needs design: Cadence.Once requires a TickRate.Create("valenar:frequency/once", ...) entry, but TickRate is designed for repeating cadences. TickRateId.Once is a runtime sentinel. The .secs source form needs resolution.

2. method void OnCreated() on registry-only contracts​

Design doc says registry-only contracts should not declare methods (SECS0213 reserved), but Recipe still has OnCreated. Removal requires host code coordination.

3. root_scope None​

Design doc shows root_scope None; in registry-only examples, but None is not a committed scope name. Current root_scope Recipe; and root_scope SpellRoot; work with the current engine.

4. Food tag declaration​

Content/policies/character_survival.secs references tags = Food in a selector, but Food is not declared in Content/common/tags.secs. Needs resolution: either add the tag or change the selector.