docs(decisions): restructure into pql governance DQR tree
Phase 1 of the pql migration. Moves the flat decisions/*.md layout into
governance/{decisions,questions,rejected}/<domain>.md — the tree pql's
`decisions sync` parses natively (record type from subdir, domain from
filename stem). Proven against pql 1.6.2: sync reports 357 records
(237 D / 108 Q / 12 R), 1057 refs, broken: 0; validate ok.
- 6 D-domain files -> governance/decisions/ (git renames)
- 5 questions-<domain>.md -> governance/questions/<domain>.md (prefix dropped)
- rejected.md split by domain -> governance/rejected/{architecture(R-001..010),
economics(R-011),perception(R-012)}.md
- decisions/README.md + questions.md index folded into governance/README.md;
pql's `decisions sync` now auto-maintains the record index appended below
the hand-written domain guidance (no more manual ID-list table upkeep).
- .pql/config.yaml: canonical vault config (tracked, not ignored).
Link rewrites are token-preserving: only the relative `foo.md` path portion
changes (e.g. `rejected.md#r-011` -> `../rejected/economics.md#r-011`); every
`[D-NNN]` bracket text and `#anchor` stays byte-identical, so pql's reference
extraction is unaffected. The one-shot transform is committed at
tooling/pql-migrate/restructure_decisions.py for provenance.
Codebase path references to decisions/ (CLAUDE.md, rules, skills, docs) are
updated in a follow-up commit.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
Claude Opus 4.8
@@ -0,0 +1,35 @@
|
||||
# pql configuration for The Settled Reach.
|
||||
# Decision/question/rejected records live under governance/{decisions,questions,rejected}/
|
||||
# (pql's DQR tree); the vault is the whole repo.
|
||||
|
||||
# Frontmatter dialect: yaml | toml.
|
||||
frontmatter: yaml
|
||||
|
||||
# Wikilink dialect: obsidian | pandoc | markdown.
|
||||
wikilinks: obsidian
|
||||
|
||||
# Where to draw tag information from: any subset of [inline, frontmatter].
|
||||
tags:
|
||||
sources: [inline, frontmatter]
|
||||
|
||||
# Glob patterns to exclude from indexing. Built-in defaults (.git/, .pql/,
|
||||
# sqlite sidecars) are always honoured. Use .pqlignore for richer rules.
|
||||
exclude:
|
||||
- "**/.obsidian/**"
|
||||
- "**/node_modules/**"
|
||||
|
||||
# Per-vault ignore files the indexer consults when walking. Default follows
|
||||
# .gitignore so pql piggy-backs on what the repo already excludes (build
|
||||
# outputs, vendored deps, the rebuildable .pql/*.db).
|
||||
ignore_files: [.gitignore]
|
||||
|
||||
# Populate file.gitmtime / file.gitauthor from git log.
|
||||
git_metadata: false
|
||||
|
||||
# Build an FTS5 index of note bodies. Off by default; only worth turning on
|
||||
# if you actually use 'body MATCH ...' queries.
|
||||
fts: false
|
||||
|
||||
# Optional aliases — short names usable as PQL macros.
|
||||
# aliases:
|
||||
# members: "type = 'council-member'"
|
||||
@@ -1,48 +0,0 @@
|
||||
# Decisions
|
||||
|
||||
Confirmed decisions, open questions, and rejected alternatives for The Settled Reach.
|
||||
|
||||
Decisions are split by domain. Each agent's briefing indicates which files to read. When in doubt about where a decision belongs: if it constrains **how we build**, it's architecture. If it defines **what we build**, it's scope. If it defines **what the player experiences**, it's content or perception. If it defines **how the team works**, it's process.
|
||||
|
||||
Cross-domain decisions live in one file with cross-reference notes in related files. Split threshold: when any file exceeds ~350 lines, review whether it should split.
|
||||
|
||||
## Domain Files
|
||||
|
||||
| File | Domain | Decisions |
|
||||
|------|--------|-----------|
|
||||
| [architecture.md](architecture.md) | Technical foundation | D-008, D-009, D-010, D-012, D-020, D-026, D-030, D-031, D-041, D-042, D-054, D-055, D-066, D-068, D-073, D-085, D-088, D-094, D-096, D-097, D-099, D-100, D-101, D-102, D-103, D-106, D-108, D-109, D-113, D-133, D-134, D-135, D-136, D-137, D-141, D-148, D-149, D-150, D-151, D-152, D-188, D-191, D-192, D-194–D-218, D-220 |
|
||||
| [perception.md](perception.md) | Player observation | D-011, D-015, D-016, D-017, D-018, D-019, D-033, D-043, D-044, D-045, D-046, D-047, D-048, D-049, D-052, D-056, D-057, D-058, D-059, D-060, D-061, D-067, D-069, D-070, D-071, D-072, D-076, D-077, D-078, D-086, D-238 |
|
||||
| [content.md](content.md) | NPC, dialogue, templates | D-023, D-024, D-025, D-028, D-029, D-032, D-034, D-035, D-036, D-037, D-050, D-062, D-063, D-064, D-074, D-075, D-084, D-090, D-092, D-093, D-095, D-098, D-104, D-105, D-107, D-121, D-122, D-123, D-124, D-125, D-126, D-127, D-128, D-129, D-130, D-131, D-132, D-138, D-139, D-140, D-142, D-147 |
|
||||
| [scope.md](scope.md) | Game concept, prototype | D-001, D-003, D-005, D-006, D-007, D-013, D-014, D-027, D-038, D-039, D-051, D-053, D-065, D-087, D-089, D-091, D-114, D-115, D-116, D-117, D-118, D-119, D-120, D-145, D-146, D-153, D-154, D-155, D-156, D-157 |
|
||||
| [economics.md](economics.md) | Economics layer, currencies, corporations, simulation | D-171, D-172, D-173, D-174, D-175, D-176, D-177, D-178, D-179, D-180, D-181, D-182, D-183, D-184, D-185, D-186, D-187, D-189, D-190 |
|
||||
| [process.md](process.md) | Team, workflow | D-004, D-021, D-022, D-040, D-221 |
|
||||
| [questions.md](questions.md) | Open questions (index) | Q-001 through Q-094 |
|
||||
| [questions-architecture.md](questions-architecture.md) | Technical questions | Q-001, Q-006, Q-009, Q-018–Q-023, Q-029, Q-030, Q-046, Q-059, Q-060, Q-063–Q-094 |
|
||||
| [questions-perception.md](questions-perception.md) | Observation questions | Q-003, Q-014, Q-016, Q-024–Q-026, Q-051, Q-053, Q-054 |
|
||||
| [questions-content.md](questions-content.md) | Narrative questions | Q-010, Q-012–Q-015, Q-017, Q-028, Q-031, Q-033, Q-040–Q-045, Q-047–Q-050, Q-052, Q-056, Q-057, Q-WTF-039, Q-WTF-040, Q-WTF-041 |
|
||||
| [questions-scope.md](questions-scope.md) | Scope questions | Q-002, Q-004, Q-005, Q-007, Q-008, Q-011, Q-027, Q-032, Q-034–Q-039, Q-058, Q-061, Q-062 |
|
||||
| [rejected.md](rejected.md) | Rejected alternatives | R-001 through R-011 |
|
||||
|
||||
## Querying Decisions
|
||||
|
||||
The SQLite database contains a `decisions` table synced from these files. Common queries:
|
||||
|
||||
```bash
|
||||
# All active architecture decisions
|
||||
tooling/db/sqlite-query "SELECT id, title FROM decisions WHERE domain='architecture' AND status='active'"
|
||||
|
||||
# Decisions without implementing tickets
|
||||
make decisions-orphan
|
||||
|
||||
# Decision coverage by domain
|
||||
make decisions-coverage
|
||||
```
|
||||
|
||||
## Adding a Decision
|
||||
|
||||
1. Edit the appropriate domain file
|
||||
2. Follow the existing format (`### D-NNN: Title` heading)
|
||||
3. Commit — the pre-commit hook runs `decisions-sync` automatically
|
||||
4. Update relevant agent briefings if needed
|
||||
|
||||
*Maintained by Qatux.*
|
||||
@@ -1,38 +0,0 @@
|
||||
# Open Questions
|
||||
|
||||
Tracked questions awaiting discussion or resolution. Split by domain, mirroring the D-record structure.
|
||||
|
||||
## Domain Files
|
||||
|
||||
| File | Domain | Questions |
|
||||
|------|--------|-----------|
|
||||
| [questions-architecture.md](questions-architecture.md) | Technical foundation | Q-001, Q-006, Q-009, Q-018–Q-023, Q-029, Q-030, Q-046, Q-059, Q-060, Q-063–Q-094, Q-096–Q-109 |
|
||||
| [questions-perception.md](questions-perception.md) | Player observation | Q-003, Q-014, Q-016, Q-024, Q-025, Q-026, Q-051, Q-053, Q-054 |
|
||||
| [questions-content.md](questions-content.md) | Narrative, NPCs, setting | Q-010, Q-012, Q-013, Q-015, Q-017, Q-028, Q-031, Q-033, Q-040–Q-045, Q-047–Q-050, Q-052, Q-056, Q-057, Q-095, Q-WTF-039, Q-WTF-040, Q-WTF-041 |
|
||||
| [questions-scope.md](questions-scope.md) | Game concept, prototype | Q-002, Q-004, Q-005, Q-007, Q-008, Q-011, Q-027, Q-032, Q-034–Q-039, Q-058, Q-061, Q-062 |
|
||||
|
||||
## Status Summary
|
||||
|
||||
| Domain | Total | Resolved | Partial | Open |
|
||||
|--------|-------|----------|---------|------|
|
||||
| Architecture | 46 | 6 | 1 | 39 |
|
||||
| Perception | 9 | 5 | 0 | 4 |
|
||||
| Content | 25 | 11 | 2 | 12 |
|
||||
| Scope | 17 | 6 | 2 | 9 |
|
||||
| **Total** | **97** | **28** | **5** | **64** |
|
||||
|
||||
*Updated 2026-04-05: Full recount. Q-002, Q-004, Q-005, Q-007 closed as resolved (D-117/D-166). Architecture index corrected (was 13, actually 46 — Q-060 through Q-094 were missing from index).*
|
||||
|
||||
## Adding a Question
|
||||
|
||||
1. Claim an ID: `tooling/db/decision claim Q questions "title"`
|
||||
2. Edit the appropriate domain file (`questions-{domain}.md`)
|
||||
3. Follow the existing format (`### Q-NNN: Title` heading)
|
||||
4. Update the domain file footer count
|
||||
5. Update this index: add the ID to the domain table row, update status summary
|
||||
|
||||
## Domain Guide
|
||||
|
||||
When in doubt about where a question belongs: if it constrains **how we build**, it's architecture. If it defines **what the player observes or knows**, it's perception. If it defines **narrative, NPCs, dialogue, or setting**, it's content. If it defines **what we ship or how big it is**, it's scope.
|
||||
|
||||
*97 questions. Last updated: 2026-04-21 (Q-095 resolved — D-193 Lattice Commission).*
|
||||
@@ -0,0 +1,435 @@
|
||||
# Governance — Decisions, Questions, Rejected
|
||||
|
||||
Structured planning records for The Settled Reach. `pql decisions sync` parses
|
||||
these into `.pql/pql.db`; query them with `pql decisions …`.
|
||||
|
||||
## Layout
|
||||
|
||||
Records live in three per-type subdirectories, split by domain:
|
||||
|
||||
```
|
||||
governance/
|
||||
decisions/<domain>.md # D-NNN — confirmed design decisions
|
||||
questions/<domain>.md # Q-NNN — open questions (may resolve into a D or R)
|
||||
rejected/<domain>.md # R-NNN — rejected alternatives (kept for the audit trail)
|
||||
```
|
||||
|
||||
The parser infers **record type from the parent subdirectory** and **domain from
|
||||
the filename stem**. A `### D-NNN: Title` (or `Q-`/`R-`) heading begins each record;
|
||||
`- **Field:** value` lines and inline `[D-NNN](…#anchor)` links carry the metadata
|
||||
and cross-references pql indexes.
|
||||
|
||||
Current domains: `architecture`, `content`, `economics`, `perception`, `process`,
|
||||
`scope`. Create a new `<domain>.md` in the relevant subdir when records land in a
|
||||
new domain.
|
||||
|
||||
## Domain guide
|
||||
|
||||
When in doubt where a record belongs:
|
||||
|
||||
- **architecture** — constrains *how we build* (engine, protocols, data structures, performance).
|
||||
- **scope** — defines *what we build* (game concept, feature scope, prototype shape).
|
||||
- **perception** — defines *what the player observes or knows* (camera, fog, LOS, audio).
|
||||
- **content** — defines *narrative, NPCs, dialogue, setting, templates*.
|
||||
- **economics** — the economics layer (currencies, commodities, corporations, simulation).
|
||||
- **process** — defines *how the team works* (workflow, commits, branches, reviews).
|
||||
|
||||
Cross-domain records live in one file with `[D-NNN](../<subdir>/<domain>.md#…)` links
|
||||
to the related domain.
|
||||
|
||||
## Querying
|
||||
|
||||
```bash
|
||||
pql decisions list # every record
|
||||
pql decisions list --type confirmed --domain architecture
|
||||
pql decisions show D-010 --with-tickets # a record + its implementing tickets
|
||||
pql decisions read D-238 # full markdown body
|
||||
pql decisions refs D-010 # cross-references in/out
|
||||
pql decisions coverage # decisions ↔ ticket coverage
|
||||
```
|
||||
|
||||
## Adding a record
|
||||
|
||||
1. **Claim an ID** (no side effects): `pql decisions claim D <domain> "title"`
|
||||
(use `Q` for a question, `R` for a rejected alternative).
|
||||
2. Edit the appropriate file (`decisions/<domain>.md`, `questions/<domain>.md`,
|
||||
or `rejected/<domain>.md`). Follow the existing `### D-NNN: Title` format.
|
||||
3. Commit. The pre-commit hook runs `pql decisions validate` (malformed-record gate)
|
||||
and stages the planning changelog.
|
||||
4. Update relevant agent briefings if needed.
|
||||
|
||||
When a question resolves, set its `- **Status:** Resolved → [D-NNN](../decisions/<domain>.md#…)`
|
||||
line in place — keep the Q-record for the audit trail rather than deleting it.
|
||||
|
||||
*Maintained by Qatux.*
|
||||
|
||||
<!-- pql:records (auto-generated; do not edit manually) -->
|
||||
|
||||
## Decisions
|
||||
|
||||
- [D-001: Build a custom game, not a mod](decisions/scope.md#d-001-build-a-custom-game-not-a-mod) — _scope_
|
||||
- [D-002: Dynasty grand strategy concept [SUPERSEDED]](decisions/scope.md#d-002-dynasty-grand-strategy-concept-superseded) — _scope_
|
||||
- [D-003: The Settled Reach is the first campaign, not the only possible one](decisions/scope.md#d-003-the-settled-reach-is-the-first-campaign-not-the-only-possible-one) — _scope_
|
||||
- [D-004: Team composition confirmed](decisions/process.md#d-004-team-composition-confirmed) — _process_
|
||||
- [D-005: Core concept - single character, first-person, story-generator](decisions/scope.md#d-005-core-concept---single-character-first-person-story-generator) — _scope_
|
||||
- [D-006: Prototype scenario — Institute/Armstrong/Guardians [SUPERSEDED]](decisions/scope.md#d-006-prototype-scenario--institutearmstrongguardians-superseded) — _scope_
|
||||
- [D-007: Five pillars of game design](decisions/scope.md#d-007-five-pillars-of-game-design) — _scope_
|
||||
- [D-008: Action pillar design principles](decisions/architecture.md#d-008-action-pillar-design-principles) — _architecture_
|
||||
- [D-009: Multiplayer - design for it, build single-player first](decisions/architecture.md#d-009-multiplayer---design-for-it-build-single-player-first) — _architecture_
|
||||
- [D-010: Multiplayer-ready architectural baseline](decisions/architecture.md#d-010-multiplayer-ready-architectural-baseline) — _architecture_
|
||||
- [D-011: Fog of perception is non-negotiable (Pillar 1 infrastructure)](decisions/perception.md#d-011-fog-of-perception-is-non-negotiable-pillar-1-infrastructure) — _perception_
|
||||
- [D-012: Chunk-based map architecture for future borderless generation](decisions/architecture.md#d-012-chunk-based-map-architecture-for-future-borderless-generation) — _architecture_
|
||||
- [D-013: Diegetic insert/POI navigation system](decisions/scope.md#d-013-diegetic-insertpoi-navigation-system) — _scope_
|
||||
- [D-014: v0.1 map specification [SUPERSEDED]](decisions/scope.md#d-014-v01-map-specification-superseded) — _scope_
|
||||
- [D-015: Camera locked to character, rotation as future option](decisions/perception.md#d-015-camera-locked-to-character-rotation-as-future-option) — _perception_
|
||||
- [D-016: Internal monologue as core perception/atmosphere system](decisions/perception.md#d-016-internal-monologue-as-core-perceptionatmosphere-system) — _perception_
|
||||
- [D-017: Perception modes as character-build system](decisions/perception.md#d-017-perception-modes-as-character-build-system) — _perception_
|
||||
- [D-018: Three-range sound model](decisions/perception.md#d-018-three-range-sound-model) — _perception_
|
||||
- [D-019: Top-down confirmed as primary camera, 3D cutscenes for key moments [SUPERSEDED by D-148]](decisions/perception.md#d-019-top-down-confirmed-as-primary-camera-3d-cutscenes-for-key-moments-superseded-by-d-148) — _perception_
|
||||
- [D-020: Engine and architecture selection — Godot client + Rust simulation via subprocess/IPC](decisions/architecture.md#d-020-engine-and-architecture-selection--godot-client--rust-simulation-via-subprocessipc) — _architecture_
|
||||
- [D-021: Official project title — "The Settled Reach"](decisions/process.md#d-021-official-project-title--the-settled-reach) — _process_
|
||||
- [D-022: Process — Round-based collaboration workflow](decisions/process.md#d-022-process--round-based-collaboration-workflow) — _process_
|
||||
- [D-023: Three-tier content model with life-sim substrate](decisions/content.md#d-023-three-tier-content-model-with-life-sim-substrate) — _content_
|
||||
- [D-024: NPC generation model — 10 axes + combat component](decisions/content.md#d-024-npc-generation-model--10-axes--combat-component) — _content_
|
||||
- [D-025: Social site / functional cluster as atomic template unit](decisions/content.md#d-025-social-site--functional-cluster-as-atomic-template-unit) — _content_
|
||||
- [D-026: Simulation tiers with timestamp-based eviction](decisions/architecture.md#d-026-simulation-tiers-with-timestamp-based-eviction) — _architecture_
|
||||
- [D-027: Vertical slice — smuggler + detective, two-character proof [SUPERSEDED]](decisions/scope.md#d-027-vertical-slice--smuggler--detective-two-character-proof-superseded) — _scope_
|
||||
- [D-028: Dialogue architecture — tagged line pools with four relational layers](decisions/content.md#d-028-dialogue-architecture--tagged-line-pools-with-four-relational-layers) — _content_
|
||||
- [D-029: Population entanglement ratio — 30/50/20](decisions/content.md#d-029-population-entanglement-ratio--305020) — _content_
|
||||
- [D-030: Testability architecture — 8 decisions for ticket #214](decisions/architecture.md#d-030-testability-architecture--8-decisions-for-ticket-214) — _architecture_
|
||||
- [D-031: Time system — game clock and day phases](decisions/architecture.md#d-031-time-system--game-clock-and-day-phases) — _architecture_
|
||||
- [D-032: Separate monologue pools per character [SUPERSEDED — deferred to Phase 6]](decisions/content.md#d-032-separate-monologue-pools-per-character-superseded--deferred-to-phase-6) — _content_
|
||||
- [D-033: Entity color = relationship to player](decisions/perception.md#d-033-entity-color--relationship-to-player) — _perception_
|
||||
- [D-034: THE FRIEND — production-level NPC pattern](decisions/content.md#d-034-the-friend--production-level-npc-pattern) — _content_
|
||||
- [D-035: Converged tag taxonomy for dialogue and monologue line pools](decisions/content.md#d-035-converged-tag-taxonomy-for-dialogue-and-monologue-line-pools) — _content_
|
||||
- [D-036: Sova Transit District / Van Maanen's Star as v0.1 setting](decisions/content.md#d-036-sova-transit-district--van-maanens-star-as-v01-setting) — _content_
|
||||
- [D-037: Contraband specification — unlicensed lattice components](decisions/content.md#d-037-contraband-specification--unlicensed-lattice-components) — _content_
|
||||
- [D-038: Audio in v0.1 scope — 8 files via Stable Audio Open](decisions/scope.md#d-038-audio-in-v01-scope--8-files-via-stable-audio-open) — _scope_
|
||||
- [D-039: v0.1 wow moment scope — all 6 moments [SUPERSEDED]](decisions/scope.md#d-039-v01-wow-moment-scope--all-6-moments-superseded) — _scope_
|
||||
- [D-040: Wiki taxonomy structure — hierarchical with YAML frontmatter](decisions/process.md#d-040-wiki-taxonomy-structure--hierarchical-with-yaml-frontmatter) — _process_
|
||||
- [D-041: Knowledge Graph Data Model](decisions/architecture.md#d-041-knowledge-graph-data-model) — _architecture_
|
||||
- [D-042: UI microcopy format — YAML via GDScript autoload](decisions/architecture.md#d-042-ui-microcopy-format--yaml-via-gdscript-autoload) — _architecture_
|
||||
- [D-043: Art direction — visual style ("functional warmth")](decisions/perception.md#d-043-art-direction--visual-style-functional-warmth) — _perception_
|
||||
- [D-044: Art direction — visual hierarchy (entity > object > structure)](decisions/perception.md#d-044-art-direction--visual-hierarchy-entity--object--structure) — _perception_
|
||||
- [D-045: Art direction — environmental neutrality (strict zero shift)](decisions/perception.md#d-045-art-direction--environmental-neutrality-strict-zero-shift) — _perception_
|
||||
- [D-046: Art direction — lighting system (three-reference model)](decisions/perception.md#d-046-art-direction--lighting-system-three-reference-model) — _perception_
|
||||
- [D-047: Art direction — two-tier animation system](decisions/perception.md#d-047-art-direction--two-tier-animation-system) — _perception_
|
||||
- [D-048: Neural insert overlay — visual design](decisions/perception.md#d-048-neural-insert-overlay--visual-design) — _perception_
|
||||
- [D-049: Z-level rendering stack (8 layers)](decisions/perception.md#d-049-z-level-rendering-stack-8-layers) — _perception_
|
||||
- [D-050: Velen — Van Maanen's Star primary world](decisions/content.md#d-050-velen--van-maanens-star-primary-world) — _content_
|
||||
- [D-051: "Settling is placement" — design principle](decisions/scope.md#d-051-settling-is-placement--design-principle) — _scope_
|
||||
- [D-052: Character favorite colors — object-layer identification](decisions/perception.md#d-052-character-favorite-colors--object-layer-identification) — _perception_
|
||||
- [D-053: Movement as stance toggle system](decisions/scope.md#d-053-movement-as-stance-toggle-system) — _scope_
|
||||
- [D-054: Tile-based movement with same-tile occupancy](decisions/architecture.md#d-054-tile-based-movement-with-same-tile-occupancy) — _architecture_
|
||||
- [D-055: Sprint explicitly suppresses interaction buffer](decisions/architecture.md#d-055-sprint-explicitly-suppresses-interaction-buffer) — _architecture_
|
||||
- [D-056: Cursor states — insert-styled geometric](decisions/perception.md#d-056-cursor-states--insert-styled-geometric) — _perception_
|
||||
- [D-057: Entity interaction — vertical list, insert-styled [PARTIALLY SUPERSEDED — archetype portion deferred to Phase 6]](decisions/perception.md#d-057-entity-interaction--vertical-list-insert-styled-partially-superseded--archetype-portion-deferred-to-phase-6) — _perception_
|
||||
- [D-058: World menu — radial, 4 spokes](decisions/perception.md#d-058-world-menu--radial-4-spokes) — _perception_
|
||||
- [D-059: Fog — shader-based, five layers, knowledge-graph-driven](decisions/perception.md#d-059-fog--shader-based-five-layers-knowledge-graph-driven) — _perception_
|
||||
- [D-060: Cognitive delay for fog recognition](decisions/perception.md#d-060-cognitive-delay-for-fog-recognition) — _perception_
|
||||
- [D-061: Dialogue box — unified conversation log, bottom screen, max 20% height, no portraits](decisions/perception.md#d-061-dialogue-box--unified-conversation-log-bottom-screen-max-20-height-no-portraits) — _perception_
|
||||
- [D-062: Invisible locked dialogue options](decisions/content.md#d-062-invisible-locked-dialogue-options) — _content_
|
||||
- [D-063: Confrontation — same box, different weight](decisions/content.md#d-063-confrontation--same-box-different-weight) — _content_
|
||||
- [D-064: Walk-away — three-phase consequences](decisions/content.md#d-064-walk-away--three-phase-consequences) — _content_
|
||||
- [D-065: Smuggler inventory — knowledge-primary with physical evidence [SUPERSEDED]](decisions/scope.md#d-065-smuggler-inventory--knowledge-primary-with-physical-evidence-superseded) — _scope_
|
||||
- [D-066: Dual-scale grid — 0.5m simulation, 1m visual (2x retina factor)](decisions/architecture.md#d-066-dual-scale-grid--05m-simulation-1m-visual-2x-retina-factor) — _architecture_
|
||||
- [D-067: Recognition chime fires at onset of cognitive delay](decisions/perception.md#d-067-recognition-chime-fires-at-onset-of-cognitive-delay) — _perception_
|
||||
- [D-068: 5-bus audio architecture](decisions/architecture.md#d-068-5-bus-audio-architecture) — _architecture_
|
||||
- [D-069: Audio dip profiles for dialogue and confrontation](decisions/perception.md#d-069-audio-dip-profiles-for-dialogue-and-confrontation) — _perception_
|
||||
- [D-070: Confrontation as cognitive vulnerability](decisions/perception.md#d-070-confrontation-as-cognitive-vulnerability) — _perception_
|
||||
- [D-071: No ambient dip for eavesdropping — ListeningFocus boost](decisions/perception.md#d-071-no-ambient-dip-for-eavesdropping--listeningfocus-boost) — _perception_
|
||||
- [D-072: Universal event-driven conversation murmur](decisions/perception.md#d-072-universal-event-driven-conversation-murmur) — _perception_
|
||||
- [D-073: Zone crossfade approach — hard boundary, soft audio transition](decisions/architecture.md#d-073-zone-crossfade-approach--hard-boundary-soft-audio-transition) — _architecture_
|
||||
- [D-074: Audio aesthetic identity — insert-tech vs organic](decisions/content.md#d-074-audio-aesthetic-identity--insert-tech-vs-organic) — _content_
|
||||
- [D-075: Dialogue filtering — layered confidence gate on trust tier (OQ-18 resolution)](decisions/content.md#d-075-dialogue-filtering--layered-confidence-gate-on-trust-tier-oq-18-resolution) — _content_
|
||||
- [D-076: Dialogue box max-width — 1200px (OQ-29 resolution)](decisions/perception.md#d-076-dialogue-box-max-width--1200px-oq-29-resolution) — _perception_
|
||||
- [D-077: Zone temperature memory — server-tracked zone_id (OQ-09 resolution)](decisions/perception.md#d-077-zone-temperature-memory--server-tracked-zone-id-oq-09-resolution) — _perception_
|
||||
- [D-078: ~~Overheard NPC conversation — passive dialogue panel with occlusion filter~~ SCRAPPED (R-012)](decisions/perception.md#d-078-overheard-npc-conversation--passive-dialogue-panel-with-occlusion-filter-scrapped-r-012) — _perception_
|
||||
- [D-079: Knowledge Grant Architecture](decisions/perception.md#d-079-knowledge-grant-architecture) — _perception_
|
||||
- [D-080: NPC-to-NPC Knowledge Propagation](decisions/perception.md#d-080-npc-to-npc-knowledge-propagation) — _perception_
|
||||
- [D-081: Unprompted Disclosure Design](decisions/perception.md#d-081-unprompted-disclosure-design) — _perception_
|
||||
- [D-082: NPC Information Boundaries — MVP Scope](decisions/perception.md#d-082-npc-information-boundaries--mvp-scope) — _perception_
|
||||
- [D-083: Contradiction Detection Pipeline](decisions/perception.md#d-083-contradiction-detection-pipeline) — _perception_
|
||||
- [D-084: Dual-namespace line ID scheme — role pool + instance override](decisions/content.md#d-084-dual-namespace-line-id-scheme--role-pool--instance-override) — _content_
|
||||
- [D-085: Per-game save directory structure](decisions/architecture.md#d-085-per-game-save-directory-structure) — _architecture_
|
||||
- [D-086: Insert icon system — custom SVG, no icon font](decisions/perception.md#d-086-insert-icon-system--custom-svg-no-icon-font) — _perception_
|
||||
- [D-087: v0.1 triangle configuration — 3 active forks, 2 passive tensions [SUPERSEDED]](decisions/scope.md#d-087-v01-triangle-configuration--3-active-forks-2-passive-tensions-superseded) — _scope_
|
||||
- [D-088: 3-state pause system — Normal/Overlay/Paused, server-authoritative](decisions/architecture.md#d-088-3-state-pause-system--normaloverlaypaused-server-authoritative) — _architecture_
|
||||
- [D-089: Self-contained triangle forks for v0.1, no cross-triangle cascade [SUPERSEDED]](decisions/scope.md#d-089-self-contained-triangle-forks-for-v01-no-cross-triangle-cascade-superseded) — _scope_
|
||||
- [D-090: PC voice registers — smuggler and detective speech patterns `[SUPERSEDED]`](decisions/content.md#d-090-pc-voice-registers--smuggler-and-detective-speech-patterns-superseded) — _content_
|
||||
- [D-091: Complicity as named thematic core [SUPERSEDED]](decisions/scope.md#d-091-complicity-as-named-thematic-core-superseded) — _scope_
|
||||
- [D-092: Anchor line requirement in NPC style guide](decisions/content.md#d-092-anchor-line-requirement-in-npc-style-guide) — _content_
|
||||
- [D-093: Sova Transit District — Spatial Layout and District Topology](decisions/content.md#d-093-sova-transit-district--spatial-layout-and-district-topology) — _content_
|
||||
- [D-094: District Spatial Hierarchy — Chunk, Block, District Naming and Sizes](decisions/architecture.md#d-094-district-spatial-hierarchy--chunk-block-district-naming-and-sizes) — _architecture_
|
||||
- [D-095: Horizon Stations and Gate Infrastructure — Transport Lore](decisions/content.md#d-095-horizon-stations-and-gate-infrastructure--transport-lore) — _content_
|
||||
- [D-096: DistrictLayoutMode — Grid and Organic Support](decisions/architecture.md#d-096-districtlayoutmode--grid-and-organic-support) — _architecture_
|
||||
- [D-097: Guarantee Tier System — Universal / Full-Only / Conditional](decisions/architecture.md#d-097-guarantee-tier-system--universal--full-only--conditional) — _architecture_
|
||||
- [D-098: TrianglePurpose Enum](decisions/content.md#d-098-trianglepurpose-enum) — _content_
|
||||
- [D-099: WallBackside / TileBehindState — Dual Classification](decisions/architecture.md#d-099-wallbackside--tilebehindstate--dual-classification) — _architecture_
|
||||
- [D-100: Dynamic Modification via Overlay — DamageOverlay and RegenerationStrategy](decisions/architecture.md#d-100-dynamic-modification-via-overlay--damageoverlay-and-regenerationstrategy) — _architecture_
|
||||
- [D-101: ZonePalette Modifier System](decisions/architecture.md#d-101-zonepalette-modifier-system) — _architecture_
|
||||
- [D-102: Horizon View Corridor as Coastal Guarantee](decisions/architecture.md#d-102-horizon-view-corridor-as-coastal-guarantee) — _architecture_
|
||||
- [D-103: Assassin Lens Spatial Guarantees — A-1 through A-4](decisions/architecture.md#d-103-assassin-lens-spatial-guarantees--a-1-through-a-4) — _architecture_
|
||||
- [D-104: Heritage Grammar Overlay for Non-Urban Palettes](decisions/content.md#d-104-heritage-grammar-overlay-for-non-urban-palettes) — _content_
|
||||
- [D-105: Non-Urban Informal Zone Typology](decisions/content.md#d-105-non-urban-informal-zone-typology) — _content_
|
||||
- [D-106: Vertical Scale Architecture and Rooftop Bar Clause](decisions/architecture.md#d-106-vertical-scale-architecture-and-rooftop-bar-clause) — _architecture_
|
||||
- [D-107: Trauma Events as EraModification Subtypes](decisions/content.md#d-107-trauma-events-as-eramodification-subtypes) — _content_
|
||||
- [D-108: MobileChunk Specification](decisions/architecture.md#d-108-mobilechunk-specification) — _architecture_
|
||||
- [D-109: DamageOverlay / RegenerationStrategy Prohibition — Architectural Mandate](decisions/architecture.md#d-109-damageoverlay--regenerationstrategy-prohibition--architectural-mandate) — _architecture_
|
||||
- [D-110: Signed Z-Level Addressing — base_z u8 → i8](decisions/architecture.md#d-110-signed-z-level-addressing--base-z-u8--i8) — _architecture_
|
||||
- [D-111: MobileChunk Idle State Covers Stationary Player Installations](decisions/architecture.md#d-111-mobilechunk-idle-state-covers-stationary-player-installations) — _architecture_
|
||||
- [D-112: No Separate Location Instancing System](decisions/architecture.md#d-112-no-separate-location-instancing-system) — _architecture_
|
||||
- [D-113: Tile data model — extensible per-tile properties](decisions/architecture.md#d-113-tile-data-model--extensible-per-tile-properties) — _architecture_
|
||||
- [D-114: v0.2 proof-of-life — generator + graphics, not hand-built slice](decisions/scope.md#d-114-v02-proof-of-life--generator--graphics-not-hand-built-slice) — _scope_
|
||||
- [D-115: Character creation scoped to skills + bookmark for v0.2](decisions/scope.md#d-115-character-creation-scoped-to-skills--bookmark-for-v02) — _scope_
|
||||
- [D-116: Religion is not a game system](decisions/scope.md#d-116-religion-is-not-a-game-system) — _scope_
|
||||
- [D-117: Tycoon is the v0.2 bookmark — zero investigation content](decisions/scope.md#d-117-tycoon-is-the-v02-bookmark--zero-investigation-content) — _scope_
|
||||
- [D-118: Small business owner starting state — tycoon is aspiration, not starting position](decisions/scope.md#d-118-small-business-owner-starting-state--tycoon-is-aspiration-not-starting-position) — _scope_
|
||||
- [D-119: Generator spike confirmed for Sprint 25 — critical path](decisions/scope.md#d-119-generator-spike-confirmed-for-sprint-25--critical-path) — _scope_
|
||||
- [D-120: No skill ceiling in v0.2 — transhumanist ladder deferred](decisions/scope.md#d-120-no-skill-ceiling-in-v02--transhumanist-ladder-deferred) — _scope_
|
||||
- [D-121: Voice is culture-driven — job as modifier](decisions/content.md#d-121-voice-is-culture-driven--job-as-modifier) — _content_
|
||||
- [D-122: All NPCs generated — no named hand-authored characters](decisions/content.md#d-122-all-npcs-generated--no-named-hand-authored-characters) — _content_
|
||||
- [D-123: Generative AI for NPC content — build-time authoring tool and runtime voice pipeline](decisions/content.md#d-123-generative-ai-for-npc-content--build-time-authoring-tool-and-runtime-voice-pipeline) — _content_
|
||||
- [D-124: In-game ollama for live NPC dialogue — ~~deferred~~ SUPERSEDED by D-138](decisions/content.md#d-124-in-game-ollama-for-live-npc-dialogue--deferred-superseded-by-d-138) — _content_
|
||||
- [D-125: World is quietly responsive — gradient of caring by social proximity](decisions/content.md#d-125-world-is-quietly-responsive--gradient-of-caring-by-social-proximity) — _content_
|
||||
- [D-126: Groundhog Day alarm clock homage — first game day only](decisions/content.md#d-126-groundhog-day-alarm-clock-homage--first-game-day-only) — _content_
|
||||
- [D-127: Player choices are the content — Rimworld model, job as rails](decisions/content.md#d-127-player-choices-are-the-content--rimworld-model-job-as-rails) — _content_
|
||||
- [D-128: Culture implicit in starting location — Van Maanen's Star equals Van Maanen's Star culture](decisions/content.md#d-128-culture-implicit-in-starting-location--van-maanens-star-equals-van-maanens-star-culture) — _content_
|
||||
- [D-129: NPC personality — traits + behavior first, relationships codified for systems](decisions/content.md#d-129-npc-personality--traits--behavior-first-relationships-codified-for-systems) — _content_
|
||||
- [D-130: Fully emergent moral arc for v0.2 — generator proves relationships readable first](decisions/content.md#d-130-fully-emergent-moral-arc-for-v02--generator-proves-relationships-readable-first) — _content_
|
||||
- [D-131: Broad economic verb vocabulary — life verbs, not tycoon-specific](decisions/content.md#d-131-broad-economic-verb-vocabulary--life-verbs-not-tycoon-specific) — _content_
|
||||
- [D-132: Dual-scale consequence model — Rimworld sharp events and DF slow accumulation](decisions/content.md#d-132-dual-scale-consequence-model--rimworld-sharp-events-and-df-slow-accumulation) — _content_
|
||||
- [D-133: Skills affect outcome — same verbs available, skill determines quality](decisions/architecture.md#d-133-skills-affect-outcome--same-verbs-available-skill-determines-quality) — _architecture_
|
||||
- [D-134: Full character customization — hair, clothing, colors at tile scale](decisions/architecture.md#d-134-full-character-customization--hair-clothing-colors-at-tile-scale) — _architecture_
|
||||
- [D-135: Setting delivery via both layers — visual world + insert in parallel](decisions/architecture.md#d-135-setting-delivery-via-both-layers--visual-world--insert-in-parallel) — _architecture_
|
||||
- [D-136: First Settled Reach moment — auto-generated apartment + insert activation](decisions/architecture.md#d-136-first-settled-reach-moment--auto-generated-apartment--insert-activation) — _architecture_
|
||||
- [D-137: Generator produces both structural and cosmetic variety at different scales](decisions/architecture.md#d-137-generator-produces-both-structural-and-cosmetic-variety-at-different-scales) — _architecture_
|
||||
- [D-138: LLM Re-voicing Pipeline for NPC Voice](decisions/content.md#d-138-llm-re-voicing-pipeline-for-npc-voice) — _content_
|
||||
- [D-139: Composable behavior primitives — three-layer assembly model](decisions/content.md#d-139-composable-behavior-primitives--three-layer-assembly-model) — _content_
|
||||
- [D-140: Dialogue re-voicing quality constraints — Paula's six rules](decisions/content.md#d-140-dialogue-re-voicing-quality-constraints--paulas-six-rules) — _content_
|
||||
- [D-141: PlatformInfo — client-side OS abstraction autoload](decisions/architecture.md#d-141-platforminfo--client-side-os-abstraction-autoload) — _architecture_
|
||||
- [D-142: Zone-type template architecture for scalable NPC behavior](decisions/content.md#d-142-zone-type-template-architecture-for-scalable-npc-behavior) — _content_
|
||||
- [D-143: GD calendar epoch — Gate Discovery (2300 AD) as year 0](decisions/content.md#d-143-gd-calendar-epoch--gate-discovery-2300-ad-as-year-0) — _content_
|
||||
- [D-144: Sirius (GJ 244A / S-067) as Reach capital — seat of the Concord Assembly](decisions/content.md#d-144-sirius-gj-244a--s-067-as-reach-capital--seat-of-the-concord-assembly) — _content_
|
||||
- [D-145: Base building DLC — GJ 902 unclaimed moon as player settlement site](decisions/scope.md#d-145-base-building-dlc--gj-902-unclaimed-moon-as-player-settlement-site) — _scope_
|
||||
- [D-146: Character creation preview — tile-scale sprite with heavy zoom](decisions/scope.md#d-146-character-creation-preview--tile-scale-sprite-with-heavy-zoom) — _scope_
|
||||
- [D-147: Aesthetic taste as character personality trait — shared root for cosmetic and environmental expression](decisions/content.md#d-147-aesthetic-taste-as-character-personality-trait--shared-root-for-cosmetic-and-environmental-expression) — _content_
|
||||
- [D-148: 30° low-angle camera with 45° map rotation — supersedes D-019](decisions/architecture.md#d-148-30-low-angle-camera-with-45-map-rotation--supersedes-d-019) — _architecture_
|
||||
- [D-149: 3D characters rendered live in scene — not pre-rendered sprites](decisions/architecture.md#d-149-3d-characters-rendered-live-in-scene--not-pre-rendered-sprites) — _architecture_
|
||||
- [D-150: Character outline — inverted hull method](decisions/architecture.md#d-150-character-outline--inverted-hull-method) — _architecture_
|
||||
- [D-151: Direction count — 8 server-side facings, 4 visual groups client Sprint 28](decisions/architecture.md#d-151-direction-count--8-server-side-facings-4-visual-groups-client-sprint-28) — _architecture_
|
||||
- [D-152: Character LOD — performance-driven budget, not distance threshold](decisions/architecture.md#d-152-character-lod--performance-driven-budget-not-distance-threshold) — _architecture_
|
||||
- [D-153: Player character not visually distinct from NPCs](decisions/scope.md#d-153-player-character-not-visually-distinct-from-npcs) — _scope_
|
||||
- [D-154: Character outline is not a relationship indicator — uniform dark](decisions/scope.md#d-154-character-outline-is-not-a-relationship-indicator--uniform-dark) — _scope_
|
||||
- [D-155: Character editor rotation — cardinal directions only, no free-spin](decisions/scope.md#d-155-character-editor-rotation--cardinal-directions-only-no-free-spin) — _scope_
|
||||
- [D-156: Faction colors are narrative, not a visual compositor concern](decisions/scope.md#d-156-faction-colors-are-narrative-not-a-visual-compositor-concern) — _scope_
|
||||
- [D-157: Game start sequence — alarm clock fade from black, not camera pull-back](decisions/scope.md#d-157-game-start-sequence--alarm-clock-fade-from-black-not-camera-pull-back) — _scope_
|
||||
- [D-158: Frontal camera angle is default for character editor / mugshot UI](decisions/scope.md#d-158-frontal-camera-angle-is-default-for-character-editor--mugshot-ui) — _scope_
|
||||
- [D-159: Character body type enum: 5 types × 2 genders + 1 child skeleton (11 total)](decisions/scope.md#d-159-character-body-type-enum-5-types--2-genders--1-child-skeleton-11-total) — _scope_
|
||||
- [D-160: Body meshes must be segmented into 18 bone-group regions](decisions/architecture.md#d-160-body-meshes-must-be-segmented-into-18-bone-group-regions) — _architecture_
|
||||
- [D-161: Head is always a separate mesh on the Head bone](decisions/architecture.md#d-161-head-is-always-a-separate-mesh-on-the-head-bone) — _architecture_
|
||||
- [D-162: Clothing is pre-baked per body type via Blender Surface Deform](decisions/architecture.md#d-162-clothing-is-pre-baked-per-body-type-via-blender-surface-deform) — _architecture_
|
||||
- [D-163: Trellis generates unique heads per character via BoneAttachment3D](decisions/architecture.md#d-163-trellis-generates-unique-heads-per-character-via-boneattachment3d) — _architecture_
|
||||
- [D-164: Fork Quaternius skeleton, replace all body meshes](decisions/architecture.md#d-164-fork-quaternius-skeleton-replace-all-body-meshes) — _architecture_
|
||||
- [D-165: Character creator color palette: 5x9 muted hues + 1x9 neutral gray](decisions/scope.md#d-165-character-creator-color-palette-5x9-muted-hues--1x9-neutral-gray) — _scope_
|
||||
- [D-166: Development Cascade — 6-Phase First-Things-First Build Order](decisions/architecture.md#d-166-development-cascade--6-phase-first-things-first-build-order) — _architecture_
|
||||
- [D-167: Heritage Roots Superseded — Corridor Cultural System Replaces Abstract Roots](decisions/content.md#d-167-heritage-roots-superseded--corridor-cultural-system-replaces-abstract-roots) — _content_
|
||||
- [D-168: Iserlohn (GJ-532c) planet name — keep, real-city origin documented](decisions/content.md#d-168-iserlohn-gj-532c-planet-name--keep-real-city-origin-documented) — _content_
|
||||
- [D-169: Implant UI component library — Control node tree with custom Theme](decisions/architecture.md#d-169-implant-ui-component-library--control-node-tree-with-custom-theme) — _architecture_
|
||||
- [D-170: HUD visibility groups — gameplay vs implant layers](decisions/architecture.md#d-170-hud-visibility-groups--gameplay-vs-implant-layers) — _architecture_
|
||||
- [D-171: Three-Currency System](decisions/economics.md#d-171-three-currency-system) — _economics_
|
||||
- [D-172: Currency Zone Initialization](decisions/economics.md#d-172-currency-zone-initialization) — _economics_
|
||||
- [D-173: Commodity Taxonomy](decisions/economics.md#d-173-commodity-taxonomy) — _economics_
|
||||
- [D-174: Shadow Economy Layer](decisions/economics.md#d-174-shadow-economy-layer) — _economics_
|
||||
- [D-175: Corporation Taxonomy and Prerequisite](decisions/economics.md#d-175-corporation-taxonomy-and-prerequisite) — _economics_
|
||||
- [D-176: Productivity Seeding](decisions/economics.md#d-176-productivity-seeding) — _economics_
|
||||
- [D-177: Productivity Constraints (Lore-Derived)](decisions/economics.md#d-177-productivity-constraints-lore-derived) — _economics_
|
||||
- [D-178: Economic Model Architecture](decisions/economics.md#d-178-economic-model-architecture) — _economics_
|
||||
- [D-179: Stability Acceptance Criteria](decisions/economics.md#d-179-stability-acceptance-criteria) — _economics_
|
||||
- [D-180: Event Input Port](decisions/economics.md#d-180-event-input-port) — _economics_
|
||||
- [D-181: Signal Vocabulary](decisions/economics.md#d-181-signal-vocabulary) — _economics_
|
||||
- [D-182: TOML Source of Truth for Economics Data](decisions/economics.md#d-182-toml-source-of-truth-for-economics-data) — _economics_
|
||||
- [D-183: Iterative Economics Development Cycle](decisions/economics.md#d-183-iterative-economics-development-cycle) — _economics_
|
||||
- [D-184: Commodity Catalog (36 Types)](decisions/economics.md#d-184-commodity-catalog-36-types) — _economics_
|
||||
- [D-185: Brands Are Not Commodities](decisions/economics.md#d-185-brands-are-not-commodities) — _economics_
|
||||
- [D-186: Gate Transmission Levels (Mass + Data + Energy)](decisions/economics.md#d-186-gate-transmission-levels-mass--data--energy) — _economics_
|
||||
- [D-187: Fusion Fuel as Intermediate (8:1 Water Yield)](decisions/economics.md#d-187-fusion-fuel-as-intermediate-81-water-yield) — _economics_
|
||||
- [D-188: Rename biome_summary to planet_class across codebase](decisions/architecture.md#d-188-rename-biome-summary-to-planet-class-across-codebase) — _architecture_
|
||||
- [D-189: Brand Layer Architecture](decisions/economics.md#d-189-brand-layer-architecture) — _economics_
|
||||
- [D-190: Brand Volume Calibration — Population-Relative Scale](decisions/economics.md#d-190-brand-volume-calibration--population-relative-scale) — _economics_
|
||||
- [D-191: Atlas of the Reach — Phase 3 Scope and Pipeline](decisions/architecture.md#d-191-atlas-of-the-reach--phase-3-scope-and-pipeline) — _architecture_
|
||||
- [D-192: Drop PROTOCOL_VERSION lockstep handshake](decisions/architecture.md#d-192-drop-protocol-version-lockstep-handshake) — _architecture_
|
||||
- [D-193: Lattice Commission — canonical long-form of the Commission](decisions/content.md#d-193-lattice-commission--canonical-long-form-of-the-commission) — _content_
|
||||
- [D-194: Three-Component District Mix Algorithm for City District Type Distribution](decisions/architecture.md#d-194-three-component-district-mix-algorithm-for-city-district-type-distribution) — _architecture_
|
||||
- [D-195: Attractor-Matching Compatibility Matrix for Generative City Placement](decisions/architecture.md#d-195-attractor-matching-compatibility-matrix-for-generative-city-placement) — _architecture_
|
||||
- [D-196: SettlementClass Enum and Latent Settlement Active/Ghost Logic](decisions/architecture.md#d-196-settlementclass-enum-and-latent-settlement-activeghost-logic) — _architecture_
|
||||
- [D-197: prosperity_baseline Derivation Formula with Topographic Gradient](decisions/architecture.md#d-197-prosperity-baseline-derivation-formula-with-topographic-gradient) — _architecture_
|
||||
- [D-198: Economic Simulation Independence from Layer 1–2 Spatial Data](decisions/architecture.md#d-198-economic-simulation-independence-from-layer-12-spatial-data) — _architecture_
|
||||
- [D-199: 6-Field Minimum Economic Read Set for City Generation Context](decisions/architecture.md#d-199-6-field-minimum-economic-read-set-for-city-generation-context) — _architecture_
|
||||
- [D-200: Three-Tier Execution Model (Build-Time / Runtime-Background / Runtime-On-Demand)](decisions/architecture.md#d-200-three-tier-execution-model-build-time--runtime-background--runtime-on-demand) — _architecture_
|
||||
- [D-201: Spatial Hierarchy — Eight Tiers with Locked Dimensions](decisions/architecture.md#d-201-spatial-hierarchy--eight-tiers-with-locked-dimensions) — _architecture_
|
||||
- [D-202: Heightmap BLOB Storage Schema (atlas_body_heightmaps)](decisions/architecture.md#d-202-heightmap-blob-storage-schema-atlas-body-heightmaps) — _architecture_
|
||||
- [D-203: BodyWorldState Bevy Resource with LRU Cache](decisions/architecture.md#d-203-bodyworldstate-bevy-resource-with-lru-cache) — _architecture_
|
||||
- [D-204: body_radius_km Column on bodies Table](decisions/architecture.md#d-204-body-radius-km-column-on-bodies-table) — _architecture_
|
||||
- [D-205: Province Boundary Pre-Computation (atlas_province_boundaries)](decisions/architecture.md#d-205-province-boundary-pre-computation-atlas-province-boundaries) — _architecture_
|
||||
- [D-206: Background Generation Priority Queue and Rayon Thread Infrastructure](decisions/architecture.md#d-206-background-generation-priority-queue-and-rayon-thread-infrastructure) — _architecture_
|
||||
- [D-207: Fully Generative Placement — markers.json Stripped to Topographic Features](decisions/architecture.md#d-207-fully-generative-placement--markersjson-stripped-to-topographic-features) — _architecture_
|
||||
- [D-208: D8 Priority-Flood Drainage Routing — Layer 1 Empty World](decisions/architecture.md#d-208-d8-priority-flood-drainage-routing--layer-1-empty-world) — _architecture_
|
||||
- [D-209: Geographic Feature Tag Extraction (7 Settlement Attractor Tags)](decisions/architecture.md#d-209-geographic-feature-tag-extraction-7-settlement-attractor-tags) — _architecture_
|
||||
- [D-210: Sub-Biome Variant Classification and terrain_modification_cost](decisions/architecture.md#d-210-sub-biome-variant-classification-and-terrain-modification-cost) — _architecture_
|
||||
- [D-211: Attractor-Matching Five-Phase Pipeline for Settlement Placement](decisions/architecture.md#d-211-attractor-matching-five-phase-pipeline-for-settlement-placement) — _architecture_
|
||||
- [D-212: TerritorialStatus Priority-Ordered Derivation Algorithm](decisions/architecture.md#d-212-territorialstatus-priority-ordered-derivation-algorithm) — _architecture_
|
||||
- [D-213: FoundingOrientation Enum and Spatial Grid Rotation](decisions/architecture.md#d-213-foundingorientation-enum-and-spatial-grid-rotation) — _architecture_
|
||||
- [D-214: PoliticalArchetype Enum and Settlement Spatial Character](decisions/architecture.md#d-214-politicalarchetype-enum-and-settlement-spatial-character) — _architecture_
|
||||
- [D-215: Five Explicit Political Archetype Spatial Arrangement Patterns](decisions/architecture.md#d-215-five-explicit-political-archetype-spatial-arrangement-patterns) — _architecture_
|
||||
- [D-216: BlockIrregularity from founding_age — Layout Age Character](decisions/architecture.md#d-216-blockirregularity-from-founding-age--layout-age-character) — _architecture_
|
||||
- [D-217: Tile Condition Thresholds (0.63 / 0.43 / 0.23)](decisions/architecture.md#d-217-tile-condition-thresholds-063--043--023) — _architecture_
|
||||
- [D-218: WorldTier Enum Canonical Values (Epicenter/Regional/Backwater/Passage/Waypoint)](decisions/architecture.md#d-218-worldtier-enum-canonical-values-epicenterregionalbackwaterpassagewaypoint) — _architecture_
|
||||
- [D-220: Settlement Density Model — Tile Scale, Density Classes, and Vertical Pressure](decisions/architecture.md#d-220-settlement-density-model--tile-scale-density-classes-and-vertical-pressure) — _architecture_
|
||||
- [D-221: Replace sprint workflow with kanban + milestones](decisions/process.md#d-221-replace-sprint-workflow-with-kanban--milestones) — _process_
|
||||
- [D-222: Spatial hierarchy and naming — Subtile to District, lore vs code](decisions/architecture.md#d-222-spatial-hierarchy-and-naming--subtile-to-district-lore-vs-code) — _architecture_
|
||||
- [D-223: Authored content as a flavored name pool — markers names-only, hand-authored templates removed](decisions/architecture.md#d-223-authored-content-as-a-flavored-name-pool--markers-names-only-hand-authored-templates-removed) — _architecture_
|
||||
- [D-224: SeedChain — deterministic seed-derivation contract](decisions/architecture.md#d-224-seedchain--deterministic-seed-derivation-contract) — _architecture_
|
||||
- [D-225: Atlas layer-stream proxy — compute-on-demand, mod-first (resolves Q-098)](decisions/architecture.md#d-225-atlas-layer-stream-proxy--compute-on-demand-mod-first-resolves-q-098) — _architecture_
|
||||
- [D-226: Live-pause inspection harness — agent-navigable, real-UI debug/review](decisions/architecture.md#d-226-live-pause-inspection-harness--agent-navigable-real-ui-debugreview) — _architecture_
|
||||
- [D-227: Deterministic-rebuild world model — derive-don't-store, cache, tile mutators, volumetric](decisions/architecture.md#d-227-deterministic-rebuild-world-model--derive-dont-store-cache-tile-mutators-volumetric) — _architecture_
|
||||
- [D-228: Composite tile schema — orthogonal axes, derived shape, region-level morphology](decisions/architecture.md#d-228-composite-tile-schema--orthogonal-axes-derived-shape-region-level-morphology) — _architecture_
|
||||
- [D-229: Building-property-tag schema — the step-3 fill output](decisions/architecture.md#d-229-building-property-tag-schema--the-step-3-fill-output) — _architecture_
|
||||
- [D-230: FillChunk two-phase execution model — background-plan / on-demand-derive](decisions/architecture.md#d-230-fillchunk-two-phase-execution-model--background-plan--on-demand-derive) — _architecture_
|
||||
- [D-231: DoorSpec and InteriorDescriptor — the step3→step4 boundary and the Phase-6 seed](decisions/architecture.md#d-231-doorspec-and-interiordescriptor--the-step3step4-boundary-and-the-phase-6-seed) — _architecture_
|
||||
- [D-232: Architecture-flavor — trait-template catalog (economically gated, seed-drawn, wiki-biased)](decisions/architecture.md#d-232-architecture-flavor--trait-template-catalog-economically-gated-seed-drawn-wiki-biased) — _architecture_
|
||||
- [D-233: Economic signal → block-fill vocabulary — `BulkClass` × `ProductionUbiquity`](decisions/architecture.md#d-233-economic-signal--block-fill-vocabulary--bulkclass--productionubiquity) — _architecture_
|
||||
- [D-234: Morphology zone → street and footprint constraints](decisions/architecture.md#d-234-morphology-zone--street-and-footprint-constraints) — _architecture_
|
||||
- [D-235: Building exterior visual grammar and material vocabulary](decisions/architecture.md#d-235-building-exterior-visual-grammar-and-material-vocabulary) — _architecture_
|
||||
- [D-236: Sol / GJ-0 — player-inaccessible, Atlas highest-level only, deeper Sol is future DLC](decisions/scope.md#d-236-sol--gj-0--player-inaccessible-atlas-highest-level-only-deeper-sol-is-future-dlc) — _scope_
|
||||
- [D-237: Authored per-system specialisation layer — `economic_specialization` + `cultural_specialization` + `dominant_faction`](decisions/architecture.md#d-237-authored-per-system-specialisation-layer--economic-specialization--cultural-specialization--dominant-faction) — _architecture_
|
||||
- [D-238: Symmetric shadowcasting (Albert Ford) selected for LOS computation](decisions/perception.md#d-238-symmetric-shadowcasting-albert-ford-selected-for-los-computation) — _perception_
|
||||
|
||||
## Open questions
|
||||
|
||||
- [Q-003: Art direction / presentation style](questions/perception.md#q-003-art-direction--presentation-style) — _perception_
|
||||
- [Q-008: Licensing / distribution model](questions/scope.md#q-008-licensing--distribution-model) — _scope_
|
||||
- [Q-010: Storyteller AI design](questions/content.md#q-010-storyteller-ai-design) — _content_
|
||||
- [Q-013: Line previewer temporal progression](questions/content.md#q-013-line-previewer-temporal-progression) — _content_
|
||||
- [Q-017: Triangle pressure threshold](questions/content.md#q-017-triangle-pressure-threshold) — _content_
|
||||
- [Q-019: Entity ID stability strategy](questions/architecture.md#q-019-entity-id-stability-strategy) — _architecture_
|
||||
- [Q-020: Multi-entity collision resolution](questions/architecture.md#q-020-multi-entity-collision-resolution) — _architecture_
|
||||
- [Q-021: Tick budget overflow policy](questions/architecture.md#q-021-tick-budget-overflow-policy) — _architecture_
|
||||
- [Q-022: NPC pathfinding cache eviction](questions/architecture.md#q-022-npc-pathfinding-cache-eviction) — _architecture_
|
||||
- [Q-023: Debug visualization scope](questions/architecture.md#q-023-debug-visualization-scope) — _architecture_
|
||||
- [Q-027: Fast-travel system design](questions/scope.md#q-027-fast-travel-system-design) — _scope_
|
||||
- [Q-029: Save file format design](questions/architecture.md#q-029-save-file-format-design) — _architecture_
|
||||
- [Q-030: Seed configuration schema](questions/architecture.md#q-030-seed-configuration-schema) — _architecture_
|
||||
- [Q-031: Combined content style guide](questions/content.md#q-031-combined-content-style-guide) — _content_
|
||||
- [Q-032: Cultural ingredients menu](questions/scope.md#q-032-cultural-ingredients-menu) — _scope_
|
||||
- [Q-033: Three-system NPC architecture](questions/content.md#q-033-three-system-npc-architecture) — _content_
|
||||
- [Q-034: PC archetypes](questions/scope.md#q-034-pc-archetypes) — _scope_
|
||||
- [Q-035: Sacred/Profane/Middle Kingdom framework](questions/scope.md#q-035-sacredprofanemiddle-kingdom-framework) — _scope_
|
||||
- [Q-036: District skeleton as generator output](questions/scope.md#q-036-district-skeleton-as-generator-output) — _scope_
|
||||
- [Q-037: Generator development pipeline](questions/scope.md#q-037-generator-development-pipeline) — _scope_
|
||||
- [Q-038: Authored content estimate at 300-world scale](questions/scope.md#q-038-authored-content-estimate-at-300-world-scale) — _scope_
|
||||
- [Q-042: Intra-system transport networks — passenger vs. freight, vehicles and modes](questions/content.md#q-042-intra-system-transport-networks--passenger-vs-freight-vehicles-and-modes) — _content_
|
||||
- [Q-045: Axis 11 — Network Footprint NPC tag](questions/content.md#q-045-axis-11--network-footprint-npc-tag) — _content_
|
||||
- [Q-047: Mobile environment social arc — structural representation of journey timeline](questions/content.md#q-047-mobile-environment-social-arc--structural-representation-of-journey-timeline) — _content_
|
||||
- [Q-048: DramaDensity enum naming — 3-level vs 5-level](questions/content.md#q-048-dramadensity-enum-naming--3-level-vs-5-level) — _content_
|
||||
- [Q-049: ObjectTag vocabulary co-maintenance — Miri and Araminta shared dependency](questions/content.md#q-049-objecttag-vocabulary-co-maintenance--miri-and-araminta-shared-dependency) — _content_
|
||||
- [Q-050: Assassination difficulty synthesis — formal spec combining stored baseline with on-demand computation](questions/content.md#q-050-assassination-difficulty-synthesis--formal-spec-combining-stored-baseline-with-on-demand-computation) — _content_
|
||||
- [Q-051: Speech bubble indicator over speaking NPCs](questions/perception.md#q-051-speech-bubble-indicator-over-speaking-npcs) — _perception_
|
||||
- [Q-052: Storyteller hint delivery — parallel diegetic channels when player does not act](questions/content.md#q-052-storyteller-hint-delivery--parallel-diegetic-channels-when-player-does-not-act) — _content_
|
||||
- [Q-053: Insert workspace boards — design philosophy and information architecture](questions/perception.md#q-053-insert-workspace-boards--design-philosophy-and-information-architecture) — _perception_
|
||||
- [Q-054: Insert workspace board — rendering primitive and data contract](questions/perception.md#q-054-insert-workspace-board--rendering-primitive-and-data-contract) — _perception_
|
||||
- [Q-056: Zone spec needs location_context field (surface/station/vessel)](questions/content.md#q-056-zone-spec-needs-location-context-field-surfacestationvessel) — _content_
|
||||
- [Q-058: Runtime behavior text serving system](questions/scope.md#q-058-runtime-behavior-text-serving-system) — _scope_
|
||||
- [Q-060: Can Surface Deform produce acceptable clothing at extreme body types?](questions/architecture.md#q-060-can-surface-deform-produce-acceptable-clothing-at-extreme-body-types) — _architecture_
|
||||
- [Q-061: How many base clothing meshes needed for v0.2 proof-of-life?](questions/scope.md#q-061-how-many-base-clothing-meshes-needed-for-v02-proof-of-life) — _scope_
|
||||
- [Q-062: What does Quaternius Source tier include for body types?](questions/scope.md#q-062-what-does-quaternius-source-tier-include-for-body-types) — _scope_
|
||||
- [Q-063: Footstep VFX system (Godot Asset Library #4122)](questions/architecture.md#q-063-footstep-vfx-system-godot-asset-library-4122) — _architecture_
|
||||
- [Q-065: Shooting mechanics — Deep RayCast 3D vs Ballistic Penetration System vs server-side](questions/architecture.md#q-065-shooting-mechanics--deep-raycast-3d-vs-ballistic-penetration-system-vs-server-side) — _architecture_
|
||||
- [Q-066: PathMesh3D for procedural environment geometry](questions/architecture.md#q-066-pathmesh3d-for-procedural-environment-geometry) — _architecture_
|
||||
- [Q-067: Vehicle physics for in-world transport](questions/architecture.md#q-067-vehicle-physics-for-in-world-transport) — _architecture_
|
||||
- [Q-068: Procedural terrain generation patterns — chunk loading and noise](questions/architecture.md#q-068-procedural-terrain-generation-patterns--chunk-loading-and-noise) — _architecture_
|
||||
- [Q-069: GPU cloth simulation for dynamic clothing](questions/architecture.md#q-069-gpu-cloth-simulation-for-dynamic-clothing) — _architecture_
|
||||
- [Q-070: NobodyWho LLM patterns vs our Rust voice pipeline](questions/architecture.md#q-070-nobodywho-llm-patterns-vs-our-rust-voice-pipeline) — _architecture_
|
||||
- [Q-071: Steam integration template for multiplayer lobbies](questions/architecture.md#q-071-steam-integration-template-for-multiplayer-lobbies) — _architecture_
|
||||
- [Q-072: BitTorrent for P2P asset/mod/world state distribution](questions/architecture.md#q-072-bittorrent-for-p2p-assetmodworld-state-distribution) — _architecture_
|
||||
- [Q-073: BehaviourToolkit patterns for Rust NPC AI](questions/architecture.md#q-073-behaviourtoolkit-patterns-for-rust-npc-ai) — _architecture_
|
||||
- [Q-074: Screenshot manager for in-game captures and bug reports](questions/architecture.md#q-074-screenshot-manager-for-in-game-captures-and-bug-reports) — _architecture_
|
||||
- [Q-075: RichText3D for in-world text rendering](questions/architecture.md#q-075-richtext3d-for-in-world-text-rendering) — _architecture_
|
||||
- [Q-076: DeformableMesh for runtime environment and damage variation](questions/architecture.md#q-076-deformablemesh-for-runtime-environment-and-damage-variation) — _architecture_
|
||||
- [Q-077: World generation architecture → PROMOTED TO WORKSHOP](questions/architecture.md#q-077-world-generation-architecture--promoted-to-workshop) — _architecture_
|
||||
- [Q-078: God rays for atmospheric lighting](questions/architecture.md#q-078-god-rays-for-atmospheric-lighting) — _architecture_
|
||||
- [Q-079: GridMapLayer — 2D tile logic driving 3D grid rendering](questions/architecture.md#q-079-gridmaplayer--2d-tile-logic-driving-3d-grid-rendering) — _architecture_
|
||||
- [Q-080: Mod loader architecture reference](questions/architecture.md#q-080-mod-loader-architecture-reference) — _architecture_
|
||||
- [Q-081: VisionCone3D for client-side fog refinement](questions/architecture.md#q-081-visioncone3d-for-client-side-fog-refinement) — _architecture_
|
||||
- [Q-082: VoronoiShatter for destruction effects](questions/architecture.md#q-082-voronoishatter-for-destruction-effects) — _architecture_
|
||||
- [Q-083: ThemeGen for dynamic insert styling and value-level theming](questions/architecture.md#q-083-themegen-for-dynamic-insert-styling-and-value-level-theming) — _architecture_
|
||||
- [Q-084: Isometric point-and-click navigation pattern](questions/architecture.md#q-084-isometric-point-and-click-navigation-pattern) — _architecture_
|
||||
- [Q-085: Portal rendering for spatial transitions and viewports](questions/architecture.md#q-085-portal-rendering-for-spatial-transitions-and-viewports) — _architecture_
|
||||
- [Q-086: Day/night cycle — server time driving client lighting](questions/architecture.md#q-086-daynight-cycle--server-time-driving-client-lighting) — _architecture_
|
||||
- [Q-087: Water shader for environment zones](questions/architecture.md#q-087-water-shader-for-environment-zones) — _architecture_
|
||||
- [Q-088: Spatial audio for information-aware sound](questions/architecture.md#q-088-spatial-audio-for-information-aware-sound) — _architecture_
|
||||
- [Q-089: Procedural star rendering for space viewports and star map](questions/architecture.md#q-089-procedural-star-rendering-for-space-viewports-and-star-map) — _architecture_
|
||||
- [Q-090: Markov chains for procedural name/text generation in Rust](questions/architecture.md#q-090-markov-chains-for-procedural-nametext-generation-in-rust) — _architecture_
|
||||
- [Q-091: Event-driven audio system](questions/architecture.md#q-091-event-driven-audio-system) — _architecture_
|
||||
- [Q-092: Modular settings menu as foundation for #735](questions/architecture.md#q-092-modular-settings-menu-as-foundation-for-735) — _architecture_
|
||||
- [Q-093: Tile-based exploration map in player insert (Google Maps for the implant)](questions/architecture.md#q-093-tile-based-exploration-map-in-player-insert-google-maps-for-the-implant) — _architecture_
|
||||
- [Q-097: Strip "What They Don't Talk About" from corporation pages](questions/content.md#q-097-strip-what-they-dont-talk-about-from-corporation-pages) — _content_
|
||||
- [Q-099: Mod content catalog — body rows / terrain_reference overlay for systems.db](questions/architecture.md#q-099-mod-content-catalog--body-rows--terrain-reference-overlay-for-systemsdb) — _architecture_
|
||||
- [Q-101: Refinement / derivation contract — coarse hint → fine geometry + morphology algorithm family](questions/architecture.md#q-101-refinement--derivation-contract--coarse-hint--fine-geometry--morphology-algorithm-family) — _architecture_
|
||||
- [Q-102: Cohesion-matrix algorithm — seam-free continuous variation](questions/architecture.md#q-102-cohesion-matrix-algorithm--seam-free-continuous-variation) — _architecture_
|
||||
- [Q-103: Tile-mutator op schema](questions/architecture.md#q-103-tile-mutator-op-schema) — _architecture_
|
||||
- [Q-105: Region seasonal/clock state — the shared cheap-dynamism source](questions/architecture.md#q-105-region-seasonalclock-state--the-shared-cheap-dynamism-source) — _architecture_
|
||||
- [Q-107: Wiki → Atlas content-set consolidation](questions/architecture.md#q-107-wiki--atlas-content-set-consolidation) — _architecture_
|
||||
- [Q-108: Subterranean / domed / sealed-habitat settlement morphology — does the built-world fill model need a surface-vs-enclosed branch](questions/architecture.md#q-108-subterranean--domed--sealed-habitat-settlement-morphology--does-the-built-world-fill-model-need-a-surface-vs-enclosed-branch) — _architecture_
|
||||
- [Q-109: Cascade generation-source dispatch — planetary / station / mod-DLC-forked / save-only](questions/architecture.md#q-109-cascade-generation-source-dispatch--planetary--station--mod-dlc-forked--save-only) — _architecture_
|
||||
|
||||
## Resolved questions
|
||||
|
||||
- [Q-001: Game engine selection](questions/architecture.md#q-001-game-engine-selection) — _architecture_
|
||||
- [Q-002: Scope of v0.1 playable prototype](questions/scope.md#q-002-scope-of-v01-playable-prototype) — _scope_
|
||||
- [Q-004: One campaign spanning all eras or separate era scenarios?](questions/scope.md#q-004-one-campaign-spanning-all-eras-or-separate-era-scenarios) — _scope_
|
||||
- [Q-005: Scale for prototype - locations, characters, factions](questions/scope.md#q-005-scale-for-prototype---locations-characters-factions) — _scope_
|
||||
- [Q-006: Multiplayer or single-player only?](questions/architecture.md#q-006-multiplayer-or-single-player-only) — _architecture_
|
||||
- [Q-007: Target platform(s)](questions/scope.md#q-007-target-platforms) — _scope_
|
||||
- [Q-009: Time system](questions/architecture.md#q-009-time-system) — _architecture_
|
||||
- [Q-011: Character selection and playable characters](questions/scope.md#q-011-character-selection-and-playable-characters) — _scope_
|
||||
- [Q-012: Generation expansion method for dialogue](questions/content.md#q-012-generation-expansion-method-for-dialogue) — _content_
|
||||
- [Q-014: Audio timing with monologue chime](questions/perception.md#q-014-audio-timing-with-monologue-chime) — _perception_
|
||||
- [Q-015: Generation expansion for THE FRIEND content](questions/content.md#q-015-generation-expansion-for-the-friend-content) — _content_
|
||||
- [Q-016: Knowledge hierarchy for monologue prerequisites](questions/perception.md#q-016-knowledge-hierarchy-for-monologue-prerequisites) — _perception_
|
||||
- [Q-018: Shadowcasting algorithm selection](questions/architecture.md#q-018-shadowcasting-algorithm-selection) — _architecture_
|
||||
- [Q-024: Gossip propagation timing](questions/perception.md#q-024-gossip-propagation-timing) — _perception_
|
||||
- [Q-025: Knowledge graph cap and eviction strategy](questions/perception.md#q-025-knowledge-graph-cap-and-eviction-strategy) — _perception_
|
||||
- [Q-026: Contradiction detection algorithm](questions/perception.md#q-026-contradiction-detection-algorithm) — _perception_
|
||||
- [Q-028: Collision-resistant line IDs for auto-generated NPCs](questions/content.md#q-028-collision-resistant-line-ids-for-auto-generated-npcs) — _content_
|
||||
- [Q-039: Gate topology generation](questions/scope.md#q-039-gate-topology-generation) — _scope_
|
||||
- [Q-040: Gate dual-use topology — freight and commuter on shared span gate infrastructure](questions/content.md#q-040-gate-dual-use-topology--freight-and-commuter-on-shared-span-gate-infrastructure) — _content_
|
||||
- [Q-041: Interstellar travel mechanics — horizon stations and gate architecture](questions/content.md#q-041-interstellar-travel-mechanics--horizon-stations-and-gate-architecture) — _content_
|
||||
- [Q-043: Station internal transit — intra-station transport system between districts](questions/content.md#q-043-station-internal-transit--intra-station-transport-system-between-districts) — _content_
|
||||
- [Q-044: Gate-train integration — do transport vehicles use gates directly or transfer on each side](questions/content.md#q-044-gate-train-integration--do-transport-vehicles-use-gates-directly-or-transfer-on-each-side) — _content_
|
||||
- [Q-046: Departure schedule model — departure windows as generator output for docked vessels](questions/architecture.md#q-046-departure-schedule-model--departure-windows-as-generator-output-for-docked-vessels) — _architecture_
|
||||
- [Q-057: Composable behavior generation — decompose culture × role × context into assembled behaviors](questions/content.md#q-057-composable-behavior-generation--decompose-culture--role--context-into-assembled-behaviors) — _content_
|
||||
- [Q-059: PlatformInfo full interface scope](questions/architecture.md#q-059-platforminfo-full-interface-scope) — _architecture_
|
||||
- [Q-064: 3D planet generator for wiki system screenshots](questions/architecture.md#q-064-3d-planet-generator-for-wiki-system-screenshots) — _architecture_
|
||||
- [Q-094: Chart widgets for economy/market insert UI](questions/architecture.md#q-094-chart-widgets-for-economymarket-insert-ui) — _architecture_
|
||||
- [Q-095: Commission formal name — authoritative designation](questions/content.md#q-095-commission-formal-name--authoritative-designation) — _content_
|
||||
- [Q-096: Replace sprint workflow with kanban + milestones](questions/process.md#q-096-replace-sprint-workflow-with-kanban--milestones) — _process_
|
||||
- [Q-098: Persistence of generated river/city mapping outputs](questions/architecture.md#q-098-persistence-of-generated-rivercity-mapping-outputs) — _architecture_
|
||||
- [Q-100: Biome authority — Python sim vs Rust cascade](questions/architecture.md#q-100-biome-authority--python-sim-vs-rust-cascade) — _architecture_
|
||||
- [Q-104: Floor-index ↔ absolute voxel-z coordinate mapping](questions/architecture.md#q-104-floor-index--absolute-voxel-z-coordinate-mapping) — _architecture_
|
||||
- [Q-106: Era-band stacking depth for layered architecture-flavor](questions/architecture.md#q-106-era-band-stacking-depth-for-layered-architecture-flavor) — _architecture_
|
||||
|
||||
## Rejected
|
||||
|
||||
- [R-001: Stellaris mod](rejected/architecture.md#r-001-stellaris-mod) — _architecture_
|
||||
- [R-002: CK3 total conversion](rejected/architecture.md#r-002-ck3-total-conversion) — _architecture_
|
||||
- [R-003: Other existing games (Distant Worlds 2, GalCiv IV, Sins of a Solar Empire II, Victoria 3)](rejected/architecture.md#r-003-other-existing-games-distant-worlds-2-galciv-iv-sins-of-a-solar-empire-ii-victoria-3) — _architecture_
|
||||
- [R-004: Pure Bevy (Rust) — no Godot](rejected/architecture.md#r-004-pure-bevy-rust--no-godot) — _architecture_
|
||||
- [R-005: Pure Godot (GDScript or C#)](rejected/architecture.md#r-005-pure-godot-gdscript-or-c) — _architecture_
|
||||
- [R-006: Godot + Rust via GDExtension](rejected/architecture.md#r-006-godot--rust-via-gdextension) — _architecture_
|
||||
- [R-007: Godot + C++ via GDExtension](rejected/architecture.md#r-007-godot--c-via-gdextension) — _architecture_
|
||||
- [R-008: Fyrox (pure Rust engine)](rejected/architecture.md#r-008-fyrox-pure-rust-engine) — _architecture_
|
||||
- [R-009: Custom framework (Rust + raylib/macroquad)](rejected/architecture.md#r-009-custom-framework-rust--raylibmacroquad) — _architecture_
|
||||
- [R-010: protobuf for client-server serialization](rejected/architecture.md#r-010-protobuf-for-client-server-serialization) — _architecture_
|
||||
- [R-011: Single currency for Phase 2 economics](rejected/economics.md#r-011-single-currency-for-phase-2-economics) — _economics_
|
||||
- [R-012: Overheard NPC conversation system (D-078) — scrapped](rejected/perception.md#r-012-overheard-npc-conversation-system-d-078--scrapped) — _perception_
|
||||
@@ -494,7 +494,7 @@ Technical foundation decisions that constrain implementation: engine, client-ser
|
||||
- **Rationale:** OS calls were scattered across HardwareDetector, AiDialogueDetector (duplicate), and SimBridge. A central abstraction prevents duplication, provides a single seam for platform-specific behavior, and keeps the client self-sufficient per D-010 (information boundaries) and future multiplayer readiness.
|
||||
- **Raised by:** Team Leader (Jeroen)
|
||||
- **Dissent:** Centralized server detection was considered and rejected — server may not share hardware with client in future multiplayer scenarios.
|
||||
- **Cross-reference:** [D-138](content.md#d-138-llm-re-voicing-pipeline-for-npc-voice) (hardware detection for voice pipeline), [D-010](#d-010) (information boundaries), [Q-059](questions-architecture.md#q-059-platforminfo-full-interface-scope) (full interface scope — open)
|
||||
- **Cross-reference:** [D-138](content.md#d-138-llm-re-voicing-pipeline-for-npc-voice) (hardware detection for voice pipeline), [D-010](#d-010) (information boundaries), [Q-059](../questions/architecture.md#q-059-platforminfo-full-interface-scope) (full interface scope — open)
|
||||
|
||||
---
|
||||
|
||||
@@ -1567,7 +1567,7 @@ Technical foundation decisions that constrain implementation: engine, client-ser
|
||||
- **Open sub-questions:** the geology-model fidelity (simple depth-horizon stack vs tectonic-grade folding/faults) and how far `FloorMaterial` is derived now vs deferred to the city layers (both tracked in D-228 / Q-101); the mutator op schema (Q-103).
|
||||
- **Implementation:** Phase 4+ (epic #750). The caching substrate exists at the atlas level (`BodyWorldStateCache`, D-203/D-225); the tile/voxel cache, mutator overlay, and geology derivation land as the cascade reaches the tile layers. No migration needed pre-save (D-202 `schema_version` lineage covers future drift once saves exist).
|
||||
- **Raised by:** Jeroen (derive-don't-store, volumetric, drop-the-floor-cap directives) + Claude, atlas-derivation workshop, 2026-05-25.
|
||||
- **Cross-reference:** [D-010](#d-010) (determinism — now save-critical), [D-222](#d-222) (subtile/tile/chunk hierarchy), [D-110](#d-110) (signed z-levels), [D-225](#d-225) (layer-stream proxy + cache pattern), [D-203](#d-203) (LRU cache tier), [D-224](#d-224) (SeedChain — feeds `derive`), [D-228](#d-228) (composite tile schema — the derived value type), [Q-101](questions-architecture.md#q-101) (refinement contract), [Q-103](questions-architecture.md#q-103) (mutator op schema), [Q-104](questions-architecture.md#q-104) (floor↔voxel-z mapping)
|
||||
- **Cross-reference:** [D-010](#d-010) (determinism — now save-critical), [D-222](#d-222) (subtile/tile/chunk hierarchy), [D-110](#d-110) (signed z-levels), [D-225](#d-225) (layer-stream proxy + cache pattern), [D-203](#d-203) (LRU cache tier), [D-224](#d-224) (SeedChain — feeds `derive`), [D-228](#d-228) (composite tile schema — the derived value type), [Q-101](../questions/architecture.md#q-101) (refinement contract), [Q-103](../questions/architecture.md#q-103) (mutator op schema), [Q-104](../questions/architecture.md#q-104) (floor↔voxel-z mapping)
|
||||
- **Dissent:** None
|
||||
|
||||
---
|
||||
@@ -1586,7 +1586,7 @@ Technical foundation decisions that constrain implementation: engine, client-ser
|
||||
- **Open sub-questions:** how far the `FloorMaterial` / `Vegetation` vocabularies are enumerated now vs deferred to the settlement layers; the exact morphology-zone vocabulary; the dynamic water-height model (→ Q-105).
|
||||
- **Implementation:** Phase 4+ (epic #750), as the cascade reaches the tile layers. Today's `TileKind` (D-049 render stack) is the seed of the per-subtile axes; `SubBiomeVariant` (D-210) is the region biome axis.
|
||||
- **Raised by:** Jeroen (FloorMaterial, shape-from-material, cohesion-matrix directives) + Claude, with the atlas-derivation workshop four — Tyre (composite data-structure), Gestalt (tag model + tactical form), Nigel (morphology-as-character), Burnelli (economic distinctions), 2026-05-25.
|
||||
- **Cross-reference:** [D-227](#d-227) (derive-don't-store — these axes are the derived value type), [D-010](#d-010), [D-210](#d-210) (sub-biome — region biome axis), [D-222](#d-222) (subtile/tile), [D-049](#d-049) (z-stack render — `TileKind` seed), [D-208](#d-208) (D8 — flow-direction source), [D-226](#d-226) (dynamic-state inspection — the water overlay), [Q-100](questions-architecture.md#q-100) (biome authority), [Q-101](questions-architecture.md#q-101) (refinement contract), [Q-102](questions-architecture.md#q-102) (cohesion-matrix algorithm), [Q-105](questions-architecture.md#q-105) (dynamic water-height)
|
||||
- **Cross-reference:** [D-227](#d-227) (derive-don't-store — these axes are the derived value type), [D-010](#d-010), [D-210](#d-210) (sub-biome — region biome axis), [D-222](#d-222) (subtile/tile), [D-049](#d-049) (z-stack render — `TileKind` seed), [D-208](#d-208) (D8 — flow-direction source), [D-226](#d-226) (dynamic-state inspection — the water overlay), [Q-100](../questions/architecture.md#q-100) (biome authority), [Q-101](../questions/architecture.md#q-101) (refinement contract), [Q-102](../questions/architecture.md#q-102) (cohesion-matrix algorithm), [Q-105](../questions/architecture.md#q-105) (dynamic water-height)
|
||||
- **Dissent:** None
|
||||
|
||||
---
|
||||
@@ -1604,12 +1604,12 @@ Technical foundation decisions that constrain implementation: engine, client-ser
|
||||
- **`FloorExtent { base_floor: i8, floor_count: u8, heights: FloorHeightProfile }`** where `FloorHeightProfile = Uniform(u8) | Variable(Vec<u8>)`. **Q-104 resolution (the D-110 ↔ D-227 bridge):** two pure functions — `floor_at_voxel_z(z) -> Option<i8>` and `voxel_range_for_floor(f) -> Option<(i32,i32)>` — map D-110 floor-index addressing onto D-227 physical voxel-z. Default `Uniform(3)` (3 voxels ≈ 3 m/floor, per Jeroen); a cathedral/hangar is `Uniform(10)`; a mixed-use stack is `Variable([5,3,3,3,3])`. The `Variable` branch carries per-floor memory only when floors actually differ.
|
||||
- **Rationale:** A typed tag is the single contract that lets the atlas render a building, the guarantee audit validate a district, and Phase 6 seed an interior — all from one frozen object. String stubs cannot carry any of that. Orthogonal fields (what / where / how-tall / who-may-enter / cultural / era / condition) compose without a combinatorial enum explosion, matching D-228's axis discipline at the building scale.
|
||||
- **Implementation:** Phase 4+ (epic forthcoming). Replaces the stub fields on `BlockSkeleton`/`QuarterSkeleton` in `server/src/simulation/generator.rs`.
|
||||
- **Amended 2026-06-05 (#957 — authored zone-type selection table):** the `(ZoningType + economic_role + seed) → ZoneTypeId` lookup is made concrete for the **planetary** cascade. A third input, **`setting` (SettingType)**, is added as a *tweaker* (not a surface/station switch — station & orbital bodies run a separate cascade per [Q-109](questions-architecture.md#q-109) and own the station-only ids `residential_station`/`extraction_space`/`port_space`/`rural_orbital`, which this table never selects). `zone_type_for(zoning, role, setting, seed)` builds a candidate slice from the base table below, applies the setting tweaker, then deterministically seed-picks one id. Every base cell is non-empty (no empty slices — mirrors D-195's no-zero rule); an unknown role falls back to the ZoningType default.
|
||||
- **Amended 2026-06-05 (#957 — authored zone-type selection table):** the `(ZoningType + economic_role + seed) → ZoneTypeId` lookup is made concrete for the **planetary** cascade. A third input, **`setting` (SettingType)**, is added as a *tweaker* (not a surface/station switch — station & orbital bodies run a separate cascade per [Q-109](../questions/architecture.md#q-109) and own the station-only ids `residential_station`/`extraction_space`/`port_space`/`rural_orbital`, which this table never selects). `zone_type_for(zoning, role, setting, seed)` builds a candidate slice from the base table below, applies the setting tweaker, then deterministically seed-picks one id. Every base cell is non-empty (no empty slices — mirrors D-195's no-zero rule); an unknown role falls back to the ZoningType default.
|
||||
- **Base table (planetary variants):** Commercial → `[commercial_market, entertainment_hospitality]` (financial→`[diplomatic_elite, commercial_market]`; transit_hub→`[commercial_transit, commercial_market]`; service_mixed→ +`entertainment_venue`). Residential → `[residential_surface]` (agricultural→`[rural_agricultural, rural_pastoral]`; extraction→`[residential_dispersed, residential_surface]`). Industrial → `[industrial_manufacturing, industrial_freight]` (manufacturing→`[industrial_manufacturing, industrial_processing]`; extraction→`[extraction_surface, industrial_processing]`; agricultural→`[industrial_processing]`). Administrative → `[administrative_civil]` (institutional→ +`administrative_judicial, diplomatic_elite`; research→`[research_station, administrative_civil]`; service_mixed→ +`medical_facility`). Transit → `[port_surface]` (transit_hub→`[commercial_transit, port_surface]`; manufacturing|extraction→`[industrial_freight, port_surface]`). Recreational → `[entertainment_venue, entertainment_hospitality]` (research|institutional→ +`archaeological_site`). Restricted → `[security_checkpoint]` (military→`[military_garrison, security_checkpoint, detention_facility]`; research→`[research_station, security_checkpoint]`; institutional→`[detention_facility, security_checkpoint]`). Mixed → `[residential_surface, commercial_market, administrative_civil]`.
|
||||
- **`setting` tweaker (post-pass):** Maritime/Water → `port_surface`⇒`port_maritime` (+`port_fishing` for Transit), `rural_*`⇒`rural_aquaculture`, `extraction_surface`⇒`extraction_platform`. Agricultural → bias `rural_agricultural`/`rural_pastoral` into Residential/Mixed. Wilderness → surface `wilderness_frontier`/`residential_dispersed` at the frontier. Urban/other → base unchanged.
|
||||
- **Entry-class U-curve threshold (gap fill):** the "low prosperity on a Commercial zone → BreachOnly" degrade uses the D-217 bands — `prosperity_baseline_bps < 2300` (the D-217 Broken band) → `BreachOnly`. **Era** follows this record as written (`founding_age_years + prosperity_baseline + seed`); the round-3 "distance-to-origin" note is dropped (not in the data model). **FloorExtent** uses the D-220 density-class floor midpoints with seed-jitter within the class range. **Doors** are **not** populated here — `doors: Vec::new()`; door derivation (D-231) is #979.
|
||||
- **Raised by:** Tyre (schema + FloorExtent/Q-104), Gestalt (BuildingEntryClass, derivation), Miri (flavor_ref), economic-built-world workshop round 2, 2026-05-25.
|
||||
- **Cross-reference:** [D-142](content.md#d-142) (zone-type taxonomy), [D-096](#d-096) (layout mode), [D-197](#d-197) (prosperity baseline), [D-217](#d-217) (tile condition), [D-110](#d-110) (signed z-levels), [D-227](#d-227) (voxel substrate), [D-101](#d-101) (ZonePalette), [D-028](#d-028) (dialogue access — name disambiguated), [D-230](#d-230), [D-231](#d-231), [D-232](#d-232), [Q-104](questions-architecture.md#q-104) (resolved here)
|
||||
- **Cross-reference:** [D-142](content.md#d-142) (zone-type taxonomy), [D-096](#d-096) (layout mode), [D-197](#d-197) (prosperity baseline), [D-217](#d-217) (tile condition), [D-110](#d-110) (signed z-levels), [D-227](#d-227) (voxel substrate), [D-101](#d-101) (ZonePalette), [D-028](#d-028) (dialogue access — name disambiguated), [D-230](#d-230), [D-231](#d-231), [D-232](#d-232), [Q-104](../questions/architecture.md#q-104) (resolved here)
|
||||
- **Dissent:** None
|
||||
|
||||
---
|
||||
@@ -1658,7 +1658,7 @@ Technical foundation decisions that constrain implementation: engine, client-ser
|
||||
- **Source-location deferred:** the human-authored *source* home (catalog file + `bias.json`) rides on **Q-107** (wiki → Atlas content-set consolidation). The generator-facing tables are invariant to it, so the fill seam is unblocked regardless.
|
||||
- **Implementation:** Phase 4+ (mechanism + sparse catalog); visual themes fill in across Phase 5+ and post-launch behind the fallback chain. `ObjectTag`/material vocabulary is Miri + Araminta co-maintained.
|
||||
- **Raised by:** Jeroen (the trait-template / economically-founded / wiki-biased model + the swerve, corridor-pool, era-as-maintenance, and logical/asset-split refinements), with Miri (lead synthesis), Burnelli (eligibility), Nigel (draw + variety math + guardrails), Araminta (visual bundle + composition), economic-built-world workshop rounds 2–3, 2026-05-25.
|
||||
- **Cross-reference:** [D-167](content.md#d-167) (corridor cultural system — completed here), [D-223](content.md#d-223) (Gemma naming pipeline + corridor mixing), [D-142](content.md#d-142) (zone types — the function baseline filtered by templates), [D-228](#d-228) (morphology zone), [D-233](#d-233) (economic channel — what vs how), [D-234](#d-234) (morphology→street — the hard-gate layer), [D-235](#d-235) (visual bundle + fallback hierarchy), [D-217](#d-217)/[D-198](#d-198) (condition — where era's wear lands), [D-224](#d-224) (SeedChain — the draw PRNG), [D-199](#d-199) (read-set — extended), [D-237](#d-237) (authored `cultural_specialization` — template-pool selection), [D-101](#d-101)/[D-104](content.md#d-104)/[D-105](content.md#d-105)/[D-107](content.md#d-107) (superseded in part), [Q-106](questions-architecture.md#q-106) (era reframed), [Q-107](questions-architecture.md#q-107) (source location)
|
||||
- **Cross-reference:** [D-167](content.md#d-167) (corridor cultural system — completed here), [D-223](content.md#d-223) (Gemma naming pipeline + corridor mixing), [D-142](content.md#d-142) (zone types — the function baseline filtered by templates), [D-228](#d-228) (morphology zone), [D-233](#d-233) (economic channel — what vs how), [D-234](#d-234) (morphology→street — the hard-gate layer), [D-235](#d-235) (visual bundle + fallback hierarchy), [D-217](#d-217)/[D-198](#d-198) (condition — where era's wear lands), [D-224](#d-224) (SeedChain — the draw PRNG), [D-199](#d-199) (read-set — extended), [D-237](#d-237) (authored `cultural_specialization` — template-pool selection), [D-101](#d-101)/[D-104](content.md#d-104)/[D-105](content.md#d-105)/[D-107](content.md#d-107) (superseded in part), [Q-106](../questions/architecture.md#q-106) (era reframed), [Q-107](../questions/architecture.md#q-107) (source location)
|
||||
- **Dissent:** None
|
||||
|
||||
---
|
||||
@@ -1695,7 +1695,7 @@ Technical foundation decisions that constrain implementation: engine, client-ser
|
||||
- **Implementation:** Phase 4+. Consumed in the plan phase (D-230) when laying streets and subdividing blocks.
|
||||
- **Implemented 2026-06-06 (#957):** the street network + footprint subdivision land in `skeleton_gen.rs` (absorbing #976 into #957 — one coherent walkable-quarter deliverable). `AccessPoint`/`CorridorSpine`/`ChunkLayout` are now typed structs (were `String` stubs): access nodes from road-entry octants + reservation gates; arterial corridors as a morphology-gated graph (Ribbon for fjord/canyon/mountain-pass, HubSpoke for delta/island/enclosed water, Prim-MST mesh otherwise), ±45°-snapped (a); per-block local lattice modulated by D-096 Grid/Organic. Footprint subdivision is a density-scaled BSP into axis-aligned `TileRect`s with D-233 BulkClass roofed-coverage. **Waterfront rule (b):** the water-facing quarter edge (from the settlement's `Coastal` founding orientation, D-213) drops its street setback to 0 so buildings present flush to the quay. The water bearing itself is now extracted in Layer 1 (`TerrainAnalysis::water_bearing`, 8-octant integer) and fed into D-213 founding orientation (#956's `0` stub is gone for coastal/river settlements). **Pending dependency:** the waterfront rule reads `CityGenerationContext.founding_orientation`, which `city_context_reader` still stubs to `Cardinal` — real per-settlement orientation only reaches quarter generation once the **Layer-3 placement → Layer-4 `GenerateSkeleton` dispatch** is wired (it must copy the placement's founding orientation into the context). That cross-layer dispatch is the remaining integration; the rule is correct and tested, awaiting its input pipeline.
|
||||
- **Raised by:** Nigel, economic-built-world workshop round 2, 2026-05-25.
|
||||
- **Cross-reference:** [D-228](#d-228) (morphology zone), [D-215](#d-215) (arrangement patterns — gated), [D-096](#d-096) (layout mode / ±45° cap), [D-220](#d-220) (density), [D-229](#d-229), [D-213](#d-213) (founding orientation — water bearing), [Q-106](questions-architecture.md#q-106), [Q-109](questions-architecture.md#q-109)
|
||||
- **Cross-reference:** [D-228](#d-228) (morphology zone), [D-215](#d-215) (arrangement patterns — gated), [D-096](#d-096) (layout mode / ±45° cap), [D-220](#d-220) (density), [D-229](#d-229), [D-213](#d-213) (founding orientation — water bearing), [Q-106](../questions/architecture.md#q-106), [Q-109](../questions/architecture.md#q-109)
|
||||
- **Dissent:** None
|
||||
|
||||
---
|
||||
@@ -581,7 +581,7 @@ How narrative, NPCs, and world content are created: content tiers, NPC generatio
|
||||
---
|
||||
|
||||
### ~~Content Pattern Note: Generator-compatible overheard conversation format (ticket #664)~~ SCRAPPED (R-012)
|
||||
- **Superseded:** 2026-04-10. NPC ambient interaction model scrapped. See [R-012](rejected.md#r-012-overheard-npc-conversation-system-d-078--scrapped).
|
||||
- **Superseded:** 2026-04-10. NPC ambient interaction model scrapped. See [R-012](../rejected/perception.md#r-012-overheard-npc-conversation-system-d-078--scrapped).
|
||||
|
||||
---
|
||||
|
||||
@@ -615,7 +615,7 @@ How narrative, NPCs, and world content are created: content tiers, NPC generatio
|
||||
- **Decision:** The Concord Assembly's regulatory authority is formally named **"the Lattice Commission"**. In-prose short form remains "the Commission" (unambiguous in context). Drift forms that appeared in earlier copy reviews — "Concord Commission" and "Assembly Commission" — are **non-canonical** and must be corrected wherever they appear. The long-form is required for institutional POI signage, tractus fee legal text, wiki page headers, and any formal/legal context.
|
||||
- **Rationale:** The Commission's regulated domain — implant hardware, medical-grade replacements, pharmaceutical production, and safety-critical manufactured goods that feed the Lattice — is what authorizes and scopes its jurisdiction. Naming it after the regulated domain (rather than the parent Assembly) mirrors how real-world regulatory bodies are often named by what they regulate (FDA, FAA, NRC) rather than by their chartering body. It also disambiguates from "Concord" which otherwise appears in the Concord Assembly itself, the Concord's member systems, etc. The Commission has no authority in Compact member systems — its identity is Lattice-scoped, not Concord-scoped.
|
||||
- **Affects:** Wiki content (all `wiki/factions/`, `wiki/technology/`, `wiki/corporations/` pages that reference the Commission), marker POI naming (e.g. `"Lattice Commission — Sirius Office"`), formal legal text in tractus fee documentation, institutional signage, institution templates in `wiki/_templates/`, dialogue pools, copy guides.
|
||||
- **Resolves:** [Q-095](questions-content.md#q-095-commission-formal-name--authoritative-designation)
|
||||
- **Resolves:** [Q-095](../questions/content.md#q-095-commission-formal-name--authoritative-designation)
|
||||
- **Raised by:** Copy review (Sprint 35, PR #127); resolved by Jeroen on 2026-04-21
|
||||
- **Dissent:** None.
|
||||
|
||||
@@ -15,7 +15,7 @@ This domain covers: currency system, commodity taxonomy, shadow economy, corpora
|
||||
- Commission fines and certification fees are Tractus-denominated (the Commission is Assembly-funded). Compact members paying Commission costs face currency conversion friction — this is a structural driver of the shadow economy in the Compact zone, not a coincidence.
|
||||
- **Rationale:** Three currencies create structural economic bloc tension without requiring event generation. The Tractus/Mark divide maps directly to the Assembly vs. Compact political divide. Sol's untraceable nature makes it the natural medium for crime — it has lore grounding and mechanical function without requiring a formal exchange rate.
|
||||
- **Raised by:** Full planning team, Sprint 32 Workshop #796. Lead directive on political framing.
|
||||
- **Dissent:** Burnelli-Sheldon (economist) recommended single currency for Phase 2 — see [R-011](rejected.md#r-011-single-currency-for-phase-2-economics). Overruled by lead.
|
||||
- **Dissent:** Burnelli-Sheldon (economist) recommended single currency for Phase 2 — see [R-011](../rejected/economics.md#r-011-single-currency-for-phase-2-economics). Overruled by lead.
|
||||
|
||||
---
|
||||
|
||||
@@ -385,7 +385,7 @@ How the player observes and interacts with the world: camera, fog, line-of-sight
|
||||
|
||||
### D-078: ~~Overheard NPC conversation — passive dialogue panel with occlusion filter~~ SCRAPPED (R-012)
|
||||
- **Date:** 2026-02-19
|
||||
- **Superseded:** 2026-04-10. The entire NPC ambient interaction model is scrapped and will be rebuilt from scratch after a walkable environment exists (Phase 5+). See [R-012](rejected.md#r-012-overheard-npc-conversation-system-d-078--scrapped).
|
||||
- **Superseded:** 2026-04-10. The entire NPC ambient interaction model is scrapped and will be rebuilt from scratch after a walkable environment exists (Phase 5+). See [R-012](../rejected/perception.md#r-012-overheard-npc-conversation-system-d-078--scrapped).
|
||||
- **Original decision:** NPC-to-NPC conversations overheard by the player are displayed in the **dialogue panel in passive mode** (read-only, no response options). An **occlusion filter** degrades displayed text based on distance, ambient noise, and player effort (ListeningFocus stance). Monologue remains a separate channel — it reacts to overheard content via the `witness_interaction` trigger but does not carry conversation text itself.
|
||||
- **Passive panel behavior:**
|
||||
- Same D-061 dialogue box, but read-only — no response options rendered.
|
||||
@@ -5,23 +5,23 @@ Technical foundation questions: engine, protocols, data structures, performance,
|
||||
---
|
||||
|
||||
### Q-001: Game engine selection
|
||||
- **Status:** Resolved → [D-020](architecture.md#d-020-engine-and-architecture-selection--godot-client--rust-simulation-via-subprocessipc)
|
||||
- **Status:** Resolved → [D-020](../decisions/architecture.md#d-020-engine-and-architecture-selection--godot-client--rust-simulation-via-subprocessipc)
|
||||
|
||||
### Q-006: Multiplayer or single-player only?
|
||||
- **Status:** Resolved → [D-009](architecture.md#d-009-multiplayer---design-for-it-build-single-player-first)
|
||||
- **Status:** Resolved → [D-009](../decisions/architecture.md#d-009-multiplayer---design-for-it-build-single-player-first)
|
||||
|
||||
### Q-009: Time system
|
||||
- **Status:** Resolved → [D-031](architecture.md#d-031-time-system--game-clock-and-day-phases)
|
||||
- **Status:** Resolved → [D-031](../decisions/architecture.md#d-031-time-system--game-clock-and-day-phases)
|
||||
|
||||
### Q-018: Shadowcasting algorithm selection
|
||||
- **Status:** Resolved → [D-238](perception.md#d-238-symmetric-shadowcasting-albert-ford-selected-for-los-computation)
|
||||
- **Status:** Resolved → [D-238](../decisions/perception.md#d-238-symmetric-shadowcasting-albert-ford-selected-for-los-computation)
|
||||
- **Question:** Which line-of-sight algorithm should be used? Symmetric shadowcasting (Albert Ford) vs recursive shadowcasting. Both are proven but differ in symmetry properties (symmetric: if A sees B, then B sees A) and implementation complexity. Requires benchmarking at 150x150 map scale with 30 entities to validate performance within 100ms tick budget.
|
||||
- **Context:** D-011 mandates LOS shadowcasting for fog of perception. Architecture review identified this as unspecified (audit section 2.2). Critical for Sprint 2 perception pipeline.
|
||||
- **Assigned to:** Tyre, Dudley
|
||||
- **Source:** Architecture Review Audit 2026-02-11
|
||||
|
||||
### Q-019: Entity ID stability strategy
|
||||
- **Status:** Partially resolved → [D-041](architecture.md#d-041-knowledge-graph-data-model)
|
||||
- **Status:** Partially resolved → [D-041](../decisions/architecture.md#d-041-knowledge-graph-data-model)
|
||||
- **Resolution:** Server-side: `StableEntityId` component + `EntityRegistry` resource provides bidirectional `StableId(u64) <-> Entity` mapping. StableId assigned once at entity spawn, never changes, persists across save/load. Knowledge graphs reference StableId, not bevy Entity. Client-side mapping (Godot StableId -> scene node lifecycle) remains open.
|
||||
- **Remaining:** Client-side entity lifecycle management, scene node mapping strategy.
|
||||
- **Date partially resolved:** 2026-02-11
|
||||
@@ -84,7 +84,7 @@ Technical foundation questions: engine, protocols, data structures, performance,
|
||||
- **Assigned to:** Tyre + Miri
|
||||
|
||||
### Q-059: PlatformInfo full interface scope
|
||||
- **Status:** Resolved → [D-141](architecture.md#d-141-platforminfo--client-side-os-abstraction-autoload)
|
||||
- **Status:** Resolved → [D-141](../decisions/architecture.md#d-141-platforminfo--client-side-os-abstraction-autoload)
|
||||
- **Question:** What properties should `PlatformInfo` expose beyond power state, memory, and file paths?
|
||||
- **Resolution:** 23 properties across 7 categories (power, memory, CPU, GPU, platform identity, display, locale), 1 signal (`power_profile_changed`), 2 methods (`refresh_memory`, `get_diagnostics`). Researched Unity SystemInfo, Unreal FPlatformMisc, SDL3. Skip: GPU VRAM (not available in Godot), CPU frequency, audio devices (AudioManager owns that), network connectivity (single-player), VM detection. Add properties only when a ticket needs them — no stubs. `get_diagnostics()` returns flat Dictionary for bug reports.
|
||||
- **Date raised:** 2026-03-13
|
||||
@@ -326,16 +326,16 @@ Technical foundation questions: engine, protocols, data structures, performance,
|
||||
- **Date resolved:** 2026-04-05
|
||||
- **Resolution:** No player-facing economic UI is in scope for Phase 2. The Phase 2 deliverable is the autonomous simulation ticking on investor screens — no player verbs, no insert UI for market data. Chart widget evaluation (Easy Charts plugin, ThemeGen integration, information boundary application) deferred until Phase 3 when the player interaction layer begins.
|
||||
- **Question:** Easy Charts (https://github.com/fenix-hub/godot-engine.easy-charts) — line charts, bar charts, scatter plots, pie charts in Godot. For the insert UI: (a) commodity price history graphs (X4/EVE-style market view), (b) faction reputation trends over time, (c) supply/demand curves per station, (d) character stat progression, (e) economy health indicators. The diegetic justification: the player's implant has market analytics. Data comes from server via ObserverSnapshot (the player only sees market data they have access to — information boundary applies). Evaluate whether this plugin's visual style can be themed to match our insert aesthetic (ThemeGen Q-083 integration).
|
||||
- **Cross-reference:** Economy system (X4/EVE inspiration), insert UI, Q-083 (ThemeGen), information boundary, [D-181](economics.md#d-181-signal-vocabulary) (signal vocabulary — Phase 3 player access)
|
||||
- **Cross-reference:** Economy system (X4/EVE inspiration), insert UI, Q-083 (ThemeGen), information boundary, [D-181](../decisions/economics.md#d-181-signal-vocabulary) (signal vocabulary — Phase 3 player access)
|
||||
|
||||
---
|
||||
|
||||
### Q-098: Persistence of generated river/city mapping outputs
|
||||
- **Status:** Resolved — D-225 (atlas layer-stream proxy), 2026-05-23
|
||||
- **Resolution:** Resolved against the question's own premise. The viewer does **not** need a durable store under the LRU: the cascade is deterministic and ~45 ms, so eviction → recompute is acceptable. Baking into `systems.db` (option a) is rejected — it bloats the install and makes modded bodies second-class. Decision: **lazy compute on demand**, served by a mod-first **layer-stream proxy** that resolves a body's source files (base + mod dirs) and streams the computed `Layer1Output` over the existing IPC bridge, backed by the D-203 in-memory LRU (miss → background `AnalyzeBody`; eviction → recompute). See [D-225](architecture.md#d-225). The mod-content-catalog corner (mods adding *new* body rows / `terrain_reference` to the binary `systems.db`) is spun off to Q-099.
|
||||
- **Resolution:** Resolved against the question's own premise. The viewer does **not** need a durable store under the LRU: the cascade is deterministic and ~45 ms, so eviction → recompute is acceptable. Baking into `systems.db` (option a) is rejected — it bloats the install and makes modded bodies second-class. Decision: **lazy compute on demand**, served by a mod-first **layer-stream proxy** that resolves a body's source files (base + mod dirs) and streams the computed `Layer1Output` over the existing IPC bridge, backed by the D-203 in-memory LRU (miss → background `AnalyzeBody`; eviction → recompute). See [D-225](../decisions/architecture.md#d-225). The mod-content-catalog corner (mods adding *new* body rows / `terrain_reference` to the binary `systems.db`) is spun off to Q-099.
|
||||
- **Question:** The deterministic cascade can recompute river courses (D8 drainage, D-208) and city placements (economic sim + attractor matching, D-211) from seed at any time, so persisting them is a *cost* optimization, not a correctness need. But the compute is expensive — recomputing per session or per atlas view is waste. How are these mapping outputs persisted so they are computed **once per body and kept**? D-203's BodyWorldState cache is an LRU — it *evicts* (volatile). The fork: **(a)** build-time bake into `systems.db` (D-200 build-time tier — precompute all, ship); **(b)** lazy compute + persist at runtime (cache DB / savegame — compute on first visit, keep); **(c)** hybrid. Whatever the answer, the in-memory LRU should sit over a *durable* store so eviction triggers a cheap reload, not a recompute.
|
||||
- **Context:** Raised 2026-05-22 looking ahead from the Phase 4 markers strip (#951). Refines D-200 (three-tier execution) and D-203 (LRU cache). Gates the Atlas layer viewer (#960), which needs persisted mapping to render without recomputing. Determinism (#952) guarantees recompute is always a valid fallback.
|
||||
- **Cross-reference:** [D-200](architecture.md#d-200), [D-203](architecture.md#d-203), [D-208](architecture.md#d-208), [D-211](architecture.md#d-211), #952 (determinism harness), #960 (atlas viewer)
|
||||
- **Cross-reference:** [D-200](../decisions/architecture.md#d-200), [D-203](../decisions/architecture.md#d-203), [D-208](../decisions/architecture.md#d-208), [D-211](../decisions/architecture.md#d-211), #952 (determinism harness), #960 (atlas viewer)
|
||||
|
||||
---
|
||||
|
||||
@@ -343,7 +343,7 @@ Technical foundation questions: engine, protocols, data structures, performance,
|
||||
- **Status:** Open — spun off from D-225 (2026-05-23)
|
||||
- **Question:** D-225 resolves mod *file* resolution (a mod body's source `heightmap.png` is found by searching mod dirs over the base install). But a mod adding a *new* body also needs that body discoverable: the `bodies` row and its `terrain_reference` live in `systems.db`, which is binary and source-canonical (D-189) — mods cannot append to it. How does a mod register new bodies (and other DB-resident catalog rows)? Options: a mod manifest the server merges into an in-memory catalog overlay at load; a parallel mod catalog DB layered over the `systems.db` reads; or a documented mod build step. Out of scope for #960 (base-install resolution ships the viewer); needed before third-party bodies are first-class.
|
||||
- **Context:** Raised 2026-05-23 from the D-225 mod-first layer-stream proxy design. The proxy makes first-party and mod bodies flow through an identical resolve→compute→stream path *given a resolvable source file*; this question is the remaining gap — getting a mod's new body into the catalog the resolver consults.
|
||||
- **Cross-reference:** [D-225](architecture.md#d-225), [D-189](architecture.md#d-189) (systems.db source-canonical), #960 (atlas viewer — base-install only for now)
|
||||
- **Cross-reference:** [D-225](../decisions/architecture.md#d-225), [D-189](../decisions/architecture.md#d-189) (systems.db source-canonical), #960 (atlas viewer — base-install only for now)
|
||||
|
||||
---
|
||||
|
||||
@@ -351,7 +351,7 @@ Technical foundation questions: engine, protocols, data structures, performance,
|
||||
- **Status:** Resolved in principle (Jeroen, 2026-05-25) — implementation detail open. The baked heightmap + reliefmap are deterministic *inputs* (gameplay never touches them), so the natural world is `f(reliefmap, heightmap, seed)` and the cascade **derives from** the baked artifacts, never independently re-derives. The biome/climate the reliefmap encodes is therefore **baked as data the Rust cascade reads** (option A below); `subbiome::classify`'s independent re-derivation is reconciled away. Open: exactly which data layers to bake + the Rust read path.
|
||||
- **Question:** Two independent biome systems exist. `planet_simulation.py` (build-time) computes biome from a Whittaker table + sim-derived temperature/moisture and colours `reliefmap.png` — the authoritative *visual*. `subbiome::classify` (Rust, runtime, D-210) re-derives `SubBiomeVariant` from proxies (elevation percentile, slope, river-distance moisture, latitude temperature). They diverge — a cold fjord coast reads `CoastalLowland` in Rust, which lacks the temperature field. Which is canonical? (A) Python canonical → bake temperature + moisture as additional atlas layers the Rust cascade reads (richer; more storage/pipeline; mod-friendly per D-225); (B) Rust canonical → re-render reliefmaps from cascade output at bake time (simpler; loses the atmospheric sim; regenerates ~267 reliefmaps); (C) keep split (pragmatic; contradicts the dual-artifact principle, D-226). Related sub-fork: the Python river-carve (colours the reliefmap) and the Rust D8 network (D-208) also diverge — the dual artifact requires reconciling them.
|
||||
- **Context:** Tyre's top integration snag. Blocks the biome axis of D-228 and the dual-artifact reconciliation. Tyre's lean: A long-term, B for Phase 4, with the expansion path designed in.
|
||||
- **Cross-reference:** [D-228](architecture.md#d-228), [D-226](architecture.md#d-226), [D-210](architecture.md#d-210), [D-208](architecture.md#d-208), [D-225](architecture.md#d-225), `tooling/planet-gen/planet_simulation.py`, `server/src/atlas/subbiome.rs`
|
||||
- **Cross-reference:** [D-228](../decisions/architecture.md#d-228), [D-226](../decisions/architecture.md#d-226), [D-210](../decisions/architecture.md#d-210), [D-208](../decisions/architecture.md#d-208), [D-225](../decisions/architecture.md#d-225), `tooling/planet-gen/planet_simulation.py`, `server/src/atlas/subbiome.rs`
|
||||
|
||||
---
|
||||
|
||||
@@ -359,7 +359,7 @@ Technical foundation questions: engine, protocols, data structures, performance,
|
||||
- **Status:** Open — the atlas-derivation workshop's primary technical output, not yet specified (2026-05-25)
|
||||
- **Question:** How does a coarse, map-scale hint (a ~78 km Layer-1 cell) plus a seed become fine, ~1 m-voxel coherent geometry — deterministically, without squaring — across ~3 scale jumps (78 km cell → ~1 km region → 64 m chunk → 1 m voxel)? Needs: the inter-layer hint+seed→geometry API (Tyre sketched a `RegionHint`); a **context-driven morphology algorithm family** selected by local context (rivers meander in lowlands / incise in mountains; coasts dune / crag / fjord by slope + lithology + glaciation), ≥6 distinct generators (meander, incised gorge, braided delta, dune strand, cliff coast, fjord, mountain pass); integer-only *structural* decisions (D-010), f64 confined to within-voxel interpolation; clean transitions between adjacent morphology families. **Unowned dependency:** the ocean/lake mask — D-223 stripped the markers.json polygons that D-209 `CoastalAccess`/`LakeShore` extraction referenced, so the mask must instead be derived from the heightmap sea-level threshold or a baked water-bodies layer. Lithology is a required input (promoted load-bearing by the volumetric subsurface, D-227). Also in scope: **body-class parameters** (hydrosphere, tectonic activity, atmosphere) must modulate river-network *density* — the effective river threshold — so an arid body and an oceanic body differ in *how many* rivers, not just where they run (today `RIVER_THRESHOLD` is a global constant, Nigel); and **river flow direction** (upstream/downstream — gates effort vs speed, and feeds the seasonal water model) derives from the D8 network at query time.
|
||||
- **Context:** The heart of the atlas→tile derivation; surfaces as the cascade builds the region → chunk → voxel layers.
|
||||
- **Cross-reference:** [D-227](architecture.md#d-227), [D-228](architecture.md#d-228), [D-208](architecture.md#d-208), [D-209](architecture.md#d-209), [D-223](architecture.md#d-223), [D-010](architecture.md#d-010), [D-222](architecture.md#d-222)
|
||||
- **Cross-reference:** [D-227](../decisions/architecture.md#d-227), [D-228](../decisions/architecture.md#d-228), [D-208](../decisions/architecture.md#d-208), [D-209](../decisions/architecture.md#d-209), [D-223](../decisions/architecture.md#d-223), [D-010](../decisions/architecture.md#d-010), [D-222](../decisions/architecture.md#d-222)
|
||||
|
||||
---
|
||||
|
||||
@@ -367,7 +367,7 @@ Technical foundation questions: engine, protocols, data structures, performance,
|
||||
- **Status:** Open — deferred from D-228 (2026-05-25)
|
||||
- **Question:** D-228 mandates that intra-region material / sub-biome scatter come from a **global, position-keyed continuous noise field** so chunk/region boundaries never read as grid seams, while authored straight lines (roads, plazas) stay crisp. Concretely: the noise basis (value / Perlin / simplex / worley); keying on world position (not chunk index) to stay continuous across boundaries; how material / sub-biome thresholds map onto it; integer-only / determinism (D-010); and how authored linear features composite over the continuous field without bleeding.
|
||||
- **Context:** The anti-squaring principle pushed down to the material layer.
|
||||
- **Cross-reference:** [D-228](architecture.md#d-228), [D-227](architecture.md#d-227), [D-010](architecture.md#d-010)
|
||||
- **Cross-reference:** [D-228](../decisions/architecture.md#d-228), [D-227](../decisions/architecture.md#d-227), [D-010](../decisions/architecture.md#d-010)
|
||||
|
||||
---
|
||||
|
||||
@@ -375,7 +375,7 @@ Technical foundation questions: engine, protocols, data structures, performance,
|
||||
- **Status:** Open — deferred from D-227 (2026-05-25)
|
||||
- **Question:** D-227 makes tile mutators the sole persisted state (save = `seed + mutator log`). What does one mutator record — a full per-voxel override, or typed ops (`Dig`, `Build(FloorMaterial)`, `Place(object)`, `Destroy(object)`, `SetMaterial`)? Typed ops are compact, semantic, replayable, but need a fixed op vocabulary; full overrides are simple but heavier and lose intent. Also: replay ordering / conflict semantics, and confirmation that a position-keyed mutator stays valid across re-derivation (determinism guarantees an identical base — to be pinned).
|
||||
- **Context:** Needed when the save system is built (Phase 5+).
|
||||
- **Cross-reference:** [D-227](architecture.md#d-227), [D-010](architecture.md#d-010)
|
||||
- **Cross-reference:** [D-227](../decisions/architecture.md#d-227), [D-010](../decisions/architecture.md#d-010)
|
||||
|
||||
---
|
||||
|
||||
@@ -384,7 +384,7 @@ Technical foundation questions: engine, protocols, data structures, performance,
|
||||
- **Resolution:** Resolved via `FloorExtent { base_floor, floor_count, FloorHeightProfile::{Uniform|Variable} }` + the pure functions `floor_at_voxel_z` / `voxel_range_for_floor`.
|
||||
- **Question:** D-227 introduces an absolute physical z coordinate (metres, continuous over the voxel grid) alongside D-110's floor-*index* addressing (`base_z: i8`, a story-counting integer). The two coexist but the bridge is undefined: "the floor at `base_z = -2`" → which absolute voxel-z values does it span? With variable-height floors (D-227 — default 3 voxels, a cathedral ~10), the mapping is **non-linear** (a floor's voxel-z depends on the heights of the floors below it). What is the mapping function, and where is it owned (a per-building floor table? a region floor-height index?)? Needed before anything queries both systems (Phase 5 building interiors / vertical movement). Gap, not contradiction — D-227 and D-110 do not conflict.
|
||||
- **Context:** Raised in the atlas-derivation workshop (Tyre, Round 2 review of D-227).
|
||||
- **Cross-reference:** [D-227](architecture.md#d-227), [D-110](architecture.md#d-110), [D-049](architecture.md#d-049), [D-222](architecture.md#d-222)
|
||||
- **Cross-reference:** [D-227](../decisions/architecture.md#d-227), [D-110](../decisions/architecture.md#d-110), [D-049](../decisions/architecture.md#d-049), [D-222](../decisions/architecture.md#d-222)
|
||||
|
||||
---
|
||||
|
||||
@@ -392,7 +392,7 @@ Technical foundation questions: engine, protocols, data structures, performance,
|
||||
- **Status:** Open — committed in principle (D-228); model details open (2026-05-25)
|
||||
- **Question:** D-228 commits to a deliberately cheap, deterministic, **region-level seasonal/clock state** — computed *once* per region per phase, inherited by its tiles — from which a family of **transient surface conditions** derive — all computed from the region's seasonal + tidal + weather phase, none of it stored: **flooded tiles** (floodplain / tidal-flat / seasonal-river, where the water-height crosses local elevation), **snow & ice cover**, **puddles** (weather / rain), **weather** generally, and the **farmland crop cycle** (sown → growing → ripe → harvested → fallow). The model must stay "nearly free" — simple deterministic functions of the in-game clock + body/region parameters, no per-tile or per-frame simulation. Open: the exact phase functions — a **seasonal** term phased by hemisphere (latitude sign), driven by the year clock; a **tidal** term only when the body has a moon (no satellite → no tide), driven by the lunar/day clock with amplitude from the satellite config; a **weather** term (shorter-term precipitation → puddles + general conditions); how snow/ice depth, puddles, flood extent, weather, and the crop cycle each read the same state; the **snow/ice cover model** — D-228 removed `Snow`/`Ice` from `TerrainMaterial`, so snow/ice are *entirely* this seasonal cover overlay (permanent only where climate never melts them — poles, glaciers), depth rising/falling with the seasonal phase; determinism (state = `f(clock, region)` → reproducible) and its interaction with the cache + the D-226 pause/inspection (a frozen phase for stable inspection); and recompute cadence (per phase-change, not per frame).
|
||||
- **Context:** Grew from the floodplain dependency — "floodplain is only feasible if water heights move" — into a general cheap-dynamism source. Jeroen's constraints: clock + hemisphere bound, moon-gated tides, computed once per region, simple rules; snow / weather / crop cycle ride the same calculation.
|
||||
- **Cross-reference:** [D-228](architecture.md#d-228), [D-227](architecture.md#d-227), [D-226](architecture.md#d-226) (dynamic-state inspection), [D-010](architecture.md#d-010)
|
||||
- **Cross-reference:** [D-228](../decisions/architecture.md#d-228), [D-227](../decisions/architecture.md#d-227), [D-226](../decisions/architecture.md#d-226) (dynamic-state inspection), [D-010](../decisions/architecture.md#d-010)
|
||||
|
||||
---
|
||||
|
||||
@@ -400,30 +400,30 @@ Technical foundation questions: engine, protocols, data structures, performance,
|
||||
- **Status:** Resolved 2026-05-25 by D-232 (round 3) — the question is dissolved, not answered.
|
||||
- **Question (original):** D-232 (round-2 draft) made flavor a three-layer resolution (body × district × era-band). How many era-bands does a settlement produce as a function of `founding_age_years`? What is the minimum age-gap between bands? How do the flavor slices differ between bands?
|
||||
- **Resolution:** The round-3 rewrite of D-232 **retired the era-band material-progression entirely.** The Reach is post-space-travel throughout — there is no stone→concrete→glass tech ladder, so era is *not* a flavor-stacking axis. A block's construction era (still derived from distance-to-founding-origin, D-229) reads as **maintenance/wear** through the condition layer (D-217/D-198); the occasional out-of-vogue building is handled by D-232's **deviation system** (the "past-vogue holdover" — temporal sibling of the spatial swerve), not by multi-band flavor stacking. So there are no era-bands to count.
|
||||
- **Cross-reference:** [D-232](architecture.md#d-232), [D-229](architecture.md#d-229), [D-217](architecture.md#d-217)/[D-198](architecture.md#d-198) (condition — where era's wear lands)
|
||||
- **Cross-reference:** [D-232](../decisions/architecture.md#d-232), [D-229](../decisions/architecture.md#d-229), [D-217](../decisions/architecture.md#d-217)/[D-198](../decisions/architecture.md#d-198) (condition — where era's wear lands)
|
||||
|
||||
---
|
||||
|
||||
### Q-107: Wiki → Atlas content-set consolidation
|
||||
- **Status:** Open — raised by Jeroen (2026-05-25)
|
||||
- **Question:** The wiki pages live semi-outside game scope yet are piped into Atlas content screens AND are now a generator input (D-232 architecture-flavor distilled from wiki prose). Where authored per-body content lives (frontmatter vs companion file vs a consolidated tree) should follow a consolidation of ALL wiki content — pages + heightmaps + markers + architecture-flavor — into one first-class, baked Atlas content set (the "move it into a `gamedata/` subtree" instinct), not a per-feature hack. The generator-facing tables (`trait_templates` + `atlas_body_trait_bias`, D-232) are invariant to the source location, so this does not block the fill seam.
|
||||
- **Cross-reference:** [D-232](architecture.md#d-232), [D-223](architecture.md#d-223), [D-191](architecture.md#d-191) (Atlas/settlement), and the development cascade (Phase 1 wiki + Phase 3 Atlas)
|
||||
- **Cross-reference:** [D-232](../decisions/architecture.md#d-232), [D-223](../decisions/architecture.md#d-223), [D-191](../decisions/architecture.md#d-191) (Atlas/settlement), and the development cascade (Phase 1 wiki + Phase 3 Atlas)
|
||||
|
||||
---
|
||||
|
||||
### Q-108: Subterranean / domed / sealed-habitat settlement morphology — does the built-world fill model need a surface-vs-enclosed branch
|
||||
- **Status:** Open — raised 2026-05-31 (system-economic-specialization workshop follow-up, via Vuurkloof / GJ 35)
|
||||
- **Question:** The economic-built-world fill model (D-233, re-amended by [D-237](architecture.md#d-237)) is implicitly a **surface** model — it derives a roofed-coverage fraction, an operations-surface remainder, and a concentrate-vs-scatter spread across open ground. But `bodies.settlement_pattern` already carries non-surface morphologies for real bodies: `underground_concentrated` (e.g. Vuurkloof / GJ35c, built into ravine walls), `cave`, `domed`, `underground_complex` (~12+ bodies on `underground_concentrated` alone, more across the others). **Nothing in the current chain reads `settlement_pattern`** — it is not in the [D-199](architecture.md#d-199) read-set, not consumed by `city_context_reader`, not branched on in `skeleton_gen` / D-233 fill. The engine *primitives* exist ([D-110](architecture.md#d-110) signed `base_z`, the `UndergroundComplex` reservation, [D-106](architecture.md#d-106) vertical scale — "a deep mine is an inverted skyscraper"), but no morphology switch connects `settlement_pattern` to them at the built-world layer. So an enclosed-habitat body like Vuurkloof would currently generate as a *surface* geothermal town (conduits and exchange stations spread across open ground), contradicting authored lore (underground-concentrated, ravine-wall construction). Does the fill model need a first-class **surface-vs-enclosed (subterranean / domed / sealed-habitat) morphology branch**, and where does it live — (a) `settlement_pattern` as a hard-gate input to D-233/D-237 fill selecting an enclosed coverage/vocabulary model; (b) a separate morphology layer above D-233 the economic vocabulary plugs into; (c) treat domed/sealed (pressurized surface envelope) as distinct from true subterranean (excavated z-negative)? And how does verticality (D-106/D-110) compose with the coverage model when a settlement is primarily vertical/subsurface, and how does `morphology_zone` (D-228/D-234, terrain-driven street geometry) behave when there is no open street plane?
|
||||
- **Question:** The economic-built-world fill model (D-233, re-amended by [D-237](../decisions/architecture.md#d-237)) is implicitly a **surface** model — it derives a roofed-coverage fraction, an operations-surface remainder, and a concentrate-vs-scatter spread across open ground. But `bodies.settlement_pattern` already carries non-surface morphologies for real bodies: `underground_concentrated` (e.g. Vuurkloof / GJ35c, built into ravine walls), `cave`, `domed`, `underground_complex` (~12+ bodies on `underground_concentrated` alone, more across the others). **Nothing in the current chain reads `settlement_pattern`** — it is not in the [D-199](../decisions/architecture.md#d-199) read-set, not consumed by `city_context_reader`, not branched on in `skeleton_gen` / D-233 fill. The engine *primitives* exist ([D-110](../decisions/architecture.md#d-110) signed `base_z`, the `UndergroundComplex` reservation, [D-106](../decisions/architecture.md#d-106) vertical scale — "a deep mine is an inverted skyscraper"), but no morphology switch connects `settlement_pattern` to them at the built-world layer. So an enclosed-habitat body like Vuurkloof would currently generate as a *surface* geothermal town (conduits and exchange stations spread across open ground), contradicting authored lore (underground-concentrated, ravine-wall construction). Does the fill model need a first-class **surface-vs-enclosed (subterranean / domed / sealed-habitat) morphology branch**, and where does it live — (a) `settlement_pattern` as a hard-gate input to D-233/D-237 fill selecting an enclosed coverage/vocabulary model; (b) a separate morphology layer above D-233 the economic vocabulary plugs into; (c) treat domed/sealed (pressurized surface envelope) as distinct from true subterranean (excavated z-negative)? And how does verticality (D-106/D-110) compose with the coverage model when a settlement is primarily vertical/subsurface, and how does `morphology_zone` (D-228/D-234, terrain-driven street geometry) behave when there is no open street plane?
|
||||
- **Context:** D-237 *inherited* D-233's surface assumption; it did not introduce the gap and does not block on it (surface bodies — the majority — are correct today). But enclosed-habitat bodies are authored lore and will read wrong until resolved. Wants its own debate/workshop with Tyre (z-level architecture), Burnelli (coverage model), Miri (which bodies, what they must read as), Araminta (how enclosed interiors are visually distinct). Tracked by ticket #1018; schedule before the Phase 4 content pass authors built form for enclosed-habitat bodies.
|
||||
- **Cross-reference:** [D-233](architecture.md#d-233) (surface coverage model — would be amended), [D-237](architecture.md#d-237) (authored specialization layer — inherits the surface assumption), [D-199](architecture.md#d-199) (read-set — would need `settlement_pattern`), [D-220](architecture.md#d-220) (density / vertical pressure), [D-106](architecture.md#d-106) (vertical scale), [D-110](architecture.md#d-110) (signed z-levels), [D-228](architecture.md#d-228)/[D-234](architecture.md#d-234) (morphology zone / street geometry), [D-196](architecture.md#d-196) (SettlementClass — orthogonal; this is morphology, not active/ghost)
|
||||
- **Cross-reference:** [D-233](../decisions/architecture.md#d-233) (surface coverage model — would be amended), [D-237](../decisions/architecture.md#d-237) (authored specialization layer — inherits the surface assumption), [D-199](../decisions/architecture.md#d-199) (read-set — would need `settlement_pattern`), [D-220](../decisions/architecture.md#d-220) (density / vertical pressure), [D-106](../decisions/architecture.md#d-106) (vertical scale), [D-110](../decisions/architecture.md#d-110) (signed z-levels), [D-228](../decisions/architecture.md#d-228)/[D-234](../decisions/architecture.md#d-234) (morphology zone / street geometry), [D-196](../decisions/architecture.md#d-196) (SettlementClass — orthogonal; this is morphology, not active/ghost)
|
||||
|
||||
---
|
||||
|
||||
### Q-109: Cascade generation-source dispatch — planetary / station / mod-DLC-forked / save-only
|
||||
- **Status:** Open — raised by Jeroen (2026-06-05, during #957 zone-selection authoring)
|
||||
- **Question:** The generation cascade currently has a single implicit path: every body runs the planetary generator (`run_cascade` → Layers 0–5). But a body's `SettingType` (or a sibling `GenerationSource` discriminator) should **dispatch at the cascade entry** to one of several generation sources: (a) **planetary** — the default terrain→quarter→tile cascade (#955/#956/#957…); (b) **station / orbital** — a *separate* cascade that owns the station-only zone types (`residential_station`, `extraction_space`, `port_space`, `rural_orbital`) and its own layout model, rather than branching the planetary code (this is why #957's zone-selection table deliberately excludes those ids — see [D-229](architecture.md#d-229) amendment 2026-06-05); (c) **mod / DLC-forked** — a value that routes generation to externally-provided code/templates (a mod or DLC name), so third-party content can supply a body's built form without patching core; (d) **save-only / `player_base`** — disables auto-generation entirely and loads the body's built world from a save file (player-constructed bases must persist, not regenerate). Where does this discriminator live — on `SettingType` itself (it already carries `Station`/`Orbital` variants) or a dedicated `GenerationSource` enum at the `run_cascade` entry? How does the mod/DLC fork resolve to external code (registry? trait object? content-pack manifest?)? And how does save-only compose with the D-203 hot cache and the D-225 compute-on-demand proxy (a `player_base` body must never enqueue an `AnalyzeBody`)?
|
||||
- **Question:** The generation cascade currently has a single implicit path: every body runs the planetary generator (`run_cascade` → Layers 0–5). But a body's `SettingType` (or a sibling `GenerationSource` discriminator) should **dispatch at the cascade entry** to one of several generation sources: (a) **planetary** — the default terrain→quarter→tile cascade (#955/#956/#957…); (b) **station / orbital** — a *separate* cascade that owns the station-only zone types (`residential_station`, `extraction_space`, `port_space`, `rural_orbital`) and its own layout model, rather than branching the planetary code (this is why #957's zone-selection table deliberately excludes those ids — see [D-229](../decisions/architecture.md#d-229) amendment 2026-06-05); (c) **mod / DLC-forked** — a value that routes generation to externally-provided code/templates (a mod or DLC name), so third-party content can supply a body's built form without patching core; (d) **save-only / `player_base`** — disables auto-generation entirely and loads the body's built world from a save file (player-constructed bases must persist, not regenerate). Where does this discriminator live — on `SettingType` itself (it already carries `Station`/`Orbital` variants) or a dedicated `GenerationSource` enum at the `run_cascade` entry? How does the mod/DLC fork resolve to external code (registry? trait object? content-pack manifest?)? And how does save-only compose with the D-203 hot cache and the D-225 compute-on-demand proxy (a `player_base` body must never enqueue an `AnalyzeBody`)?
|
||||
- **Context:** Surfaced while authoring #957's `(ZoningType × economic_role × setting)` zone-selection table: `setting` is the right *tweaker* within the planetary path, but it is also the natural *dispatch* point above it — the two roles are distinct and only the tweaker belongs in #957. The dispatch is a cross-cutting routing seam above any single layer; capturing it here so #957 stays scoped to the planetary path. Not blocking — the planetary path is the only live source today. Wants Tyre (cascade architecture) + a look at modding/DLC strategy and the savegame model (Phase 5+) before it's decided.
|
||||
- **Cross-reference:** [D-200](architecture.md#d-200) (runtime cascade), [D-225](architecture.md#d-225) (compute-on-demand proxy — save-only must bypass), [D-203](architecture.md#d-203) (hot cache), [D-229](architecture.md#d-229) (zone-selection — excludes station ids for this reason), D-222 (Quarter/spatial tiers), and the development cascade (Phase 5 player control + savegame)
|
||||
- **Cross-reference:** [D-200](../decisions/architecture.md#d-200) (runtime cascade), [D-225](../decisions/architecture.md#d-225) (compute-on-demand proxy — save-only must bypass), [D-203](../decisions/architecture.md#d-203) (hot cache), [D-229](../decisions/architecture.md#d-229) (zone-selection — excludes station ids for this reason), D-222 (Quarter/spatial tiers), and the development cascade (Phase 5 player control + savegame)
|
||||
|
||||
---
|
||||
|
||||
@@ -14,7 +14,7 @@ Narrative, NPCs, dialogue, templates, setting, worldbuilding, and storyteller me
|
||||
- **Question:** How does the 4x generation expansion pass work? LLM-based, template-based, or rule-based? Affects how base lines are authored — LLM needs style-strong anchors; rules need substitution patterns.
|
||||
- **Assigned to:** Gestalt, Mellanie
|
||||
- **Source:** Content Gap Analysis Workshop (Mellanie R2)
|
||||
- **Resolution:** LLM-based re-voicing via bundled Gemma 2B Q4. Culture-neutral semantic base text is the LLM seed; culture injectors + trait modifiers + tell-context tone shape the output. Resolved by [D-138](content.md#d-138-llm-re-voicing-pipeline-for-npc-voice) (LLM Voice Pipeline Workshop, 2026-03-07).
|
||||
- **Resolution:** LLM-based re-voicing via bundled Gemma 2B Q4. Culture-neutral semantic base text is the LLM seed; culture injectors + trait modifiers + tell-context tone shape the output. Resolved by [D-138](../decisions/content.md#d-138-llm-re-voicing-pipeline-for-npc-voice) (LLM Voice Pipeline Workshop, 2026-03-07).
|
||||
|
||||
### Q-013: Line previewer temporal progression
|
||||
- **Status:** Open
|
||||
@@ -36,7 +36,7 @@ Narrative, NPCs, dialogue, templates, setting, worldbuilding, and storyteller me
|
||||
- **Source:** Content Gap Analysis Workshop (Gestalt R2)
|
||||
|
||||
### Q-028: Collision-resistant line IDs for auto-generated NPCs
|
||||
- **Status:** Resolved → [D-084](content.md#d-084-dual-namespace-line-id-scheme--role-pool--instance-override)
|
||||
- **Status:** Resolved → [D-084](../decisions/content.md#d-084-dual-namespace-line-id-scheme--role-pool--instance-override)
|
||||
- **Resolution:** The collision problem is mostly already solved by the role-pool architecture: `dock-worker_d_###` lines are shared content for all instances of the role, not per-instance IDs. A true collision (two distinct authored lines sharing the same ID) cannot occur with one file per role. For the edge case of authored instance-specific content, a role-slug + zero-padded generation counter suffix produces `dock-worker-07_d_001`. Counter is seeded-deterministic. No schema change, no migration. Hand-authored NPCs unchanged.
|
||||
- **Closed by:** Gestalt (Sprint 18, #544). 2026-02-25.
|
||||
- **Ticket:** #544
|
||||
@@ -50,7 +50,7 @@ Narrative, NPCs, dialogue, templates, setting, worldbuilding, and storyteller me
|
||||
- **Source:** Wiki Review Workshop R2
|
||||
|
||||
### Q-033: Three-system NPC architecture
|
||||
- **Status:** Partially resolved — reframed by [D-122](content.md#d-122-all-npcs-generated--no-named-hand-authored-characters) (all NPCs generated)
|
||||
- **Status:** Partially resolved — reframed by [D-122](../decisions/content.md#d-122-all-npcs-generated--no-named-hand-authored-characters) (all NPCs generated)
|
||||
- **Reframe:** The 9-pattern x 6-motivation composition matrix survives as a generator template taxonomy (the FRIEND pattern explicitly survives as a generator template per D-034 amendment). Both D-024 and this matrix now describe generator output format, not hand-authoring assignments. The NpcBlueprint struct (Sprint 25) encodes patterns and motivations. Full formal adoption of the 9x6 matrix as the canonical generator taxonomy remains open — the composable behavior engine (D-139) may inform how patterns map to behavior primitives.
|
||||
- **Question:** Should NPCs be formally composed from 9 thematic patterns (FRIEND, MIRROR, ANCHOR, GHOST, CATALYST, THRESHOLD, REMNANT, SYSTEM, NOBODY) x 6 functional motivations (HANDLER, WITNESS, TURNCOAT, CIVILIAN, OPERATOR, SKEPTIC)? D-024 defines 10 axes + combat but predates this refined system. The wiki-review workshop produced a full composition matrix with drama ratings and forbidden combinations. Does this supersede D-024 or extend it?
|
||||
- **Assigned to:** Gestalt, Paula
|
||||
@@ -206,16 +206,16 @@ Narrative, NPCs, dialogue, templates, setting, worldbuilding, and storyteller me
|
||||
---
|
||||
|
||||
### Q-WTF-039: Character creation — portrait render or tile-scale preview?
|
||||
- **Status:** Resolved → [D-146](scope.md#d-146-character-creation-preview--tile-scale-sprite-with-heavy-zoom)
|
||||
- **Status:** Resolved → [D-146](../decisions/scope.md#d-146-character-creation-preview--tile-scale-sprite-with-heavy-zoom)
|
||||
- **Question:** Does the character creation screen show a portrait render or a tile-scale in-world preview of the player character? Affects #618 (CK3-style character creation screen) team assignment: portrait render is a visual team deliverable; tile-scale preview is client.
|
||||
- **Resolution:** Tile-scale sprite with heavy zoom. The creation screen shows the game sprite rendered at high resolution, zoomed in so cosmetic details are clearly visible. Same approach as Rimworld: one rendering pipeline, no separate portrait system. #618 stays as a single client ticket. Resolved by [D-146](scope.md#d-146-character-creation-preview--tile-scale-sprite-with-heavy-zoom).
|
||||
- **Resolution:** Tile-scale sprite with heavy zoom. The creation screen shows the game sprite rendered at high resolution, zoomed in so cosmetic details are clearly visible. Same approach as Rimworld: one rendering pipeline, no separate portrait system. #618 stays as a single client ticket. Resolved by [D-146](../decisions/scope.md#d-146-character-creation-preview--tile-scale-sprite-with-heavy-zoom).
|
||||
- **Assigned to:** Tyre (architecture), confirmed by project lead
|
||||
- **Source:** Sprint 27 planning pass (2026-03-17)
|
||||
|
||||
### Q-WTF-040: Do creation choices trace into the generated apartment?
|
||||
- **Status:** Resolved → [D-147](content.md#d-147-aesthetic-taste-as-character-personality-trait--shared-root-for-cosmetic-and-environmental-expression)
|
||||
- **Status:** Resolved → [D-147](../decisions/content.md#d-147-aesthetic-taste-as-character-personality-trait--shared-root-for-cosmetic-and-environmental-expression)
|
||||
- **Question:** If the player picks hair colour and clothing in #619, does the generator use those choices when laying out the starting apartment (furniture style, colour palette)? Affects #617 scope and dependency.
|
||||
- **Resolution:** Not directly. Cosmetic choices do not pipeline into the apartment generator. Instead, characters have an `aesthetic_taste` personality trait that independently informs both appearance choices and living space. Someone who likes teal picks teal clothing AND owns a teal vase — but through shared taste, not data coupling. #619 does NOT block #617. Resolved by [D-147](content.md#d-147-aesthetic-taste-as-character-personality-trait--shared-root-for-cosmetic-and-environmental-expression).
|
||||
- **Resolution:** Not directly. Cosmetic choices do not pipeline into the apartment generator. Instead, characters have an `aesthetic_taste` personality trait that independently informs both appearance choices and living space. Someone who likes teal picks teal clothing AND owns a teal vase — but through shared taste, not data coupling. #619 does NOT block #617. Resolved by [D-147](../decisions/content.md#d-147-aesthetic-taste-as-character-personality-trait--shared-root-for-cosmetic-and-environmental-expression).
|
||||
- **Assigned to:** Gestalt (systems), Paula (narrative), confirmed by project lead
|
||||
- **Source:** Sprint 27 planning pass (2026-03-17)
|
||||
|
||||
@@ -229,7 +229,7 @@ Narrative, NPCs, dialogue, templates, setting, worldbuilding, and storyteller me
|
||||
---
|
||||
|
||||
### Q-095: Commission formal name — authoritative designation
|
||||
- **Status:** Resolved — see [D-193](content.md#d-193-lattice-commission--canonical-long-form-of-the-commission) (2026-04-21)
|
||||
- **Status:** Resolved — see [D-193](../decisions/content.md#d-193-lattice-commission--canonical-long-form-of-the-commission) (2026-04-21)
|
||||
- **Resolution:** Canonical long-form is **"the Lattice Commission"**. Short form "the Commission" remains standard in-prose. "Concord Commission" and "Assembly Commission" drift forms are non-canonical.
|
||||
- **Question:** What is the full formal name of the Concord Assembly's regulatory authority? In-prose use is "the Commission", but several drift forms have appeared in copy reviews ("Concord Commission", "Assembly Commission", "Lattice Commission"). A canonical long-form is needed for formal/legal contexts, institutional signage, and wiki headers.
|
||||
- **Context:** The Commission certifies implant hardware, medical equipment, pharmaceutical production, and safety-critical manufactured goods under tractus-denominated fees. It has no authority in Compact member systems. Current glossary guidance is to use "the Commission" until the full name is resolved, but authors writing institutional POIs and formal documents need a decision.
|
||||
@@ -10,18 +10,18 @@ Player observation, information systems, UI surfaces, knowledge mechanics, and i
|
||||
- **Assigned to:** Araminta (lead)
|
||||
|
||||
### Q-014: Audio timing with monologue chime
|
||||
- **Status:** Resolved → [D-067](perception.md#d-067-recognition-chime-fires-at-onset-of-cognitive-delay)
|
||||
- **Status:** Resolved → [D-067](../decisions/perception.md#d-067-recognition-chime-fires-at-onset-of-cognitive-delay)
|
||||
- **Resolution:** Chime fires at ONSET of cognitive delay, not completion. 300-400ms duration, overlapping delay start. Chime is "unresolved" — opens a question, doesn't answer one. Sequence: hear/sense → chime plays → 0.6s delay begins → monologue text during delay → blob transitions to D-033 color → recognition complete.
|
||||
- **Date resolved:** 2026-02-16
|
||||
|
||||
### Q-016: Knowledge hierarchy for monologue prerequisites
|
||||
- **Status:** Resolved → [D-041](architecture.md#d-041-knowledge-graph-data-model)
|
||||
- **Status:** Resolved → [D-041](../decisions/architecture.md#d-041-knowledge-graph-data-model)
|
||||
- **Resolution:** 4-level hierarchy: `Suspects < KnowsOf < KnowsDetails < Direct`. Suspects = "something's off", gates initial investigation and vague monologue. KnowsOf = "X is involved in Y", gates topic-specific dialogue and peer-tier access. KnowsDetails = actionable detail, gates confrontation and secret-tier dialogue. Direct = currently in LOS, provides live position data. Maps to D-028 access tiers and D-035 prerequisite tags.
|
||||
- **Date resolved:** 2026-02-11
|
||||
- **Source:** Knowledge Graph & Information Boundaries Workshop
|
||||
|
||||
### Q-024: Gossip propagation timing
|
||||
- **Status:** Resolved → [D-080](perception.md#d-080-npc-to-npc-knowledge-propagation)
|
||||
- **Status:** Resolved → [D-080](../decisions/perception.md#d-080-npc-to-npc-knowledge-propagation)
|
||||
- **Resolution:** Knowledge transfer occurs via a separate `transfer_npc_knowledge` Bevy system running `after(run_npc_conversations)`. Transfer fires once per conversation at conversation start (immediate during conversation, not queued). Rate: 1–3 facts drawn by recency. Trust-tier gated. See D-080 for full specification.
|
||||
- **Closed by:** Knowledge Flow & NPC Information Boundaries Workshop — unanimous. 2026-02-24.
|
||||
- **Source:** Knowledge Graph & Information Boundaries Workshop (Gestalt Round 1); resolved in Knowledge Flow & NPC Information Boundaries Workshop Round 2.
|
||||
@@ -34,7 +34,7 @@ Player observation, information systems, UI surfaces, knowledge mechanics, and i
|
||||
- **Source:** Knowledge Graph & Information Boundaries Workshop (Dudley Round 1, section 8.3). Architecture audit 2026-02-23. Workshop confirmation 2026-02-24.
|
||||
|
||||
### Q-026: Contradiction detection algorithm
|
||||
- **Status:** Resolved → [D-083](perception.md#d-083-contradiction-detection-pipeline)
|
||||
- **Status:** Resolved → [D-083](../decisions/perception.md#d-083-contradiction-detection-pipeline)
|
||||
- **Resolution:** Event-driven detection at KG write time in `observe_entity()`, using `ContradictionClaim` struct. Location contradiction is automatic (Sprint 17): position comparison + time window (CONTRADICTION_WINDOW_TICKS = 600). Attribute and fact contradiction are content-authored (Sprint 18). Both ToldBy and DirectObservation entries receive Contradicted state (epistemic neutrality). `ContradictionDetected` event → monologue with resolved display names → relationship shift → AnomalyMarker via existing pipeline.
|
||||
- **Closed by:** Knowledge Flow & NPC Information Boundaries Workshop — unanimous on architecture. 2026-02-24.
|
||||
- **Source:** Knowledge Graph & Information Boundaries Workshop (Gestalt/Paula Round 1); resolved in Knowledge Flow & NPC Information Boundaries Workshop Round 2.
|
||||
@@ -5,25 +5,25 @@ Game concept, prototype boundaries, production pipeline, and feature decisions.
|
||||
---
|
||||
|
||||
### Q-002: Scope of v0.1 playable prototype
|
||||
- **Status:** Resolved → [D-117](scope.md#d-117-tycoon-is-the-v02-bookmark--zero-investigation-content), [D-166](architecture.md#d-166-development-cascade--6-phase-first-things-first-build-order)
|
||||
- **Status:** Resolved → [D-117](../decisions/scope.md#d-117-tycoon-is-the-v02-bookmark--zero-investigation-content), [D-166](../decisions/architecture.md#d-166-development-cascade--6-phase-first-things-first-build-order)
|
||||
- **Resolution:** The v0.1 prototype framing is superseded. D-117 establishes the tycoon as the v0.2 bookmark; D-166 defines the 6-phase development cascade as the authoritative build order. Prototype scope is determined by the cascade phases, not a standalone v0.1 spec.
|
||||
- **Date resolved:** 2026-03-24 (D-166 development cascade)
|
||||
- **Assigned to:** Full team
|
||||
|
||||
### Q-004: One campaign spanning all eras or separate era scenarios?
|
||||
- **Status:** Resolved (implicitly) → [D-117](scope.md#d-117-tycoon-is-the-v02-bookmark--zero-investigation-content), [D-166](architecture.md#d-166-development-cascade--6-phase-first-things-first-build-order)
|
||||
- **Status:** Resolved (implicitly) → [D-117](../decisions/scope.md#d-117-tycoon-is-the-v02-bookmark--zero-investigation-content), [D-166](../decisions/architecture.md#d-166-development-cascade--6-phase-first-things-first-build-order)
|
||||
- **Resolution:** v0.2 is single-era (contemporary Settled Reach). The development cascade (D-166) defers all multi-era considerations well beyond current scope. The question remains interesting for the full game but is not load-bearing for any active phase.
|
||||
- **Date resolved:** 2026-04-05 (closed as implicitly resolved)
|
||||
- **Assigned to:** Gore, Miri to lead discussion
|
||||
|
||||
### Q-005: Scale for prototype - locations, characters, factions
|
||||
- **Status:** Resolved → [D-117](scope.md#d-117-tycoon-is-the-v02-bookmark--zero-investigation-content), [D-118](scope.md#d-118-small-business-owner-starting-state--3-configurations), [D-166](architecture.md#d-166-development-cascade--6-phase-first-things-first-build-order)
|
||||
- **Status:** Resolved → [D-117](../decisions/scope.md#d-117-tycoon-is-the-v02-bookmark--zero-investigation-content), [D-118](../decisions/scope.md#d-118-small-business-owner-starting-state--3-configurations), [D-166](../decisions/architecture.md#d-166-development-cascade--6-phase-first-things-first-build-order)
|
||||
- **Resolution:** Scale is determined by the development cascade (D-166), not pre-scoped. 301 systems in the star map. All NPCs generated (D-122). Single character type (tycoon, D-117). Starting configurations defined in D-118. The "~10-20 characters" estimate is obsolete — NPC count is a generator output, not a hand-authored target.
|
||||
- **Date resolved:** 2026-03-24 (D-166 development cascade)
|
||||
- **Assigned to:** Gestalt, Tyre, Miri
|
||||
|
||||
### Q-007: Target platform(s)
|
||||
- **Status:** Resolved (implicitly) → [D-020](architecture.md#d-020-engine-and-architecture-selection--godot-client--rust-simulation-via-subprocessipc)
|
||||
- **Status:** Resolved (implicitly) → [D-020](../decisions/architecture.md#d-020-engine-and-architecture-selection--godot-client--rust-simulation-via-subprocessipc)
|
||||
- **Resolution:** Godot 4 + Rust architecture (D-020) inherently supports cross-platform via Godot's export system. Primary development on Linux (Fedora). No platform-specific constraints have emerged. Cross-platform export is a deployment task, not an architectural decision.
|
||||
- **Date resolved:** 2026-04-05 (closed as implicitly resolved)
|
||||
- **Assigned to:** Tyre
|
||||
@@ -34,7 +34,7 @@ Game concept, prototype boundaries, production pipeline, and feature decisions.
|
||||
- **Assigned to:** Team Leader
|
||||
|
||||
### Q-011: Character selection and playable characters
|
||||
- **Status:** Resolved → [D-117](scope.md#d-117-tycoon-is-the-v02-bookmark--zero-investigation-content), [D-115](scope.md#d-115-character-creation-scoped-to-skills--bookmark-for-v02), [D-122](content.md#d-122-all-npcs-generated--no-named-hand-authored-characters)
|
||||
- **Status:** Resolved → [D-117](../decisions/scope.md#d-117-tycoon-is-the-v02-bookmark--zero-investigation-content), [D-115](../decisions/scope.md#d-115-character-creation-scoped-to-skills--bookmark-for-v02), [D-122](../decisions/content.md#d-122-all-npcs-generated--no-named-hand-authored-characters)
|
||||
- **Resolution:** v0.2 has one playable character type: the tycoon (small business owner starting state, D-118). One bookmark. All NPCs are generated — no canon named characters. Character creation is skills + bookmark only. The "how different are their starting positions?" question is answered by the small business owner economic variation (D-118: bar, logistics contract, storage franchise as starting configurations). The "canon characters vs original" question is answered by D-122: all NPCs generated, no canon characters exist in v0.2.
|
||||
- **Date resolved:** 2026-03-05 (Where's the Fun? Workshop)
|
||||
- **Question:** Which characters are playable in the prototype? How different are their starting positions? Can you play canon characters or only original ones?
|
||||
@@ -58,7 +58,7 @@ Game concept, prototype boundaries, production pipeline, and feature decisions.
|
||||
- **Source:** Wiki Review Workshop R4, lead interview
|
||||
|
||||
### Q-034: PC archetypes
|
||||
- **Status:** Partially resolved → [D-117](scope.md#d-117-tycoon-is-the-v02-bookmark--zero-investigation-content) (v0.2 scope only: tycoon bookmark, zero investigation)
|
||||
- **Status:** Partially resolved → [D-117](../decisions/scope.md#d-117-tycoon-is-the-v02-bookmark--zero-investigation-content) (v0.2 scope only: tycoon bookmark, zero investigation)
|
||||
- **Partial resolution:** v0.2 scope is settled — one bookmark (tycoon, small business owner start per D-118). Smuggler and detective are abandoned for v0.2. The full 8-archetype model, fluid archetype transitions, and "vulnerable window" mechanics remain undesigned for the full game. The "detective, smuggler, tycoon are jobs you can have, not the game's identity" framing (Where's the Fun? Workshop) is the guiding principle for future archetype design.
|
||||
- **Question:** Should the full game support 8 fluid PC archetypes (Smuggler, Detective, Engineer, Diplomat, Medic, Scholar, Soldier, Merchant) with transition mechanics where archetype shifts during play based on player behavior? The lead approved 8 archetypes with fluid transitions as a game mechanic. v0.1 ships smuggler + detective only (D-027). Full archetype spec, transition triggers, and "vulnerable window" mechanics are undesigned. NOTE: The character-creation-game-setup workshop (Q-011) will address this — coordinate.
|
||||
- **Assigned to:** Nigel, Gestalt
|
||||
@@ -77,7 +77,7 @@ Game concept, prototype boundaries, production pipeline, and feature decisions.
|
||||
- **Source:** Wiki Review Workshop R4
|
||||
|
||||
### Q-037: Generator development pipeline
|
||||
- **Status:** Partially resolved → [D-119](scope.md#d-119-generator-spike-confirmed-for-sprint-25--critical-path), [D-166](architecture.md#d-166-development-cascade--6-phase-first-things-first-build-order)
|
||||
- **Status:** Partially resolved → [D-119](../decisions/scope.md#d-119-generator-spike-confirmed-for-sprint-25--critical-path), [D-166](../decisions/architecture.md#d-166-development-cascade--6-phase-first-things-first-build-order)
|
||||
- **Partial resolution:** D-166 (development cascade) establishes a strict 6-phase build order. The generator falls in Phase 5 (World Generation), not Phase 1. D-119's Sprint 25 sequencing is superseded by the cascade. The 6-phase pipeline spec (Ingredient Authoring, Template Authoring, Generator Development, Validation Development, Generation + Review, Hand-Elevation) remains open pending Phase 5.
|
||||
- **Question:** Should content production follow a 6-phase generator pipeline (Ingredient Authoring, Template Authoring, Generator Development, Validation Development, Generation + Review, Hand-Elevation)? The wiki-review workshop proposed this as the production model for 300 worlds. SI mapped a release path (v0.1 hand-authored, v0.2-0.5 template expansion, v0.6-0.10 generator development, pre-v1.0 validation). Needs scope assessment and sprint planning integration.
|
||||
- **Assigned to:** SI, Tyre
|
||||
@@ -1,8 +1,6 @@
|
||||
# Rejected Alternatives
|
||||
# Rejected Alternatives — Architecture
|
||||
|
||||
Alternatives considered and rejected, with rationale preserved for future reference.
|
||||
|
||||
---
|
||||
Rejected proposals in the **architecture** domain, rationale preserved for the audit trail.
|
||||
|
||||
### R-001: Stellaris mod
|
||||
- **Rejected:** 2026-02-08
|
||||
@@ -18,15 +16,15 @@ Alternatives considered and rejected, with rationale preserved for future refere
|
||||
|
||||
### R-004: Pure Bevy (Rust) — no Godot
|
||||
- **Rejected:** 2026-02-09
|
||||
- **Reason:** No visual editor (level design is code-only). UI framework in flux. API breaks significantly between versions. For a solo developer who needs visual tools for hand-crafted buildings ([D-014](scope.md#d-014-v01-map-specification)), Godot's editor is a massive productivity advantage. Bevy's ECS is used — just not its renderer.
|
||||
- **Reason:** No visual editor (level design is code-only). UI framework in flux. API breaks significantly between versions. For a solo developer who needs visual tools for hand-crafted buildings ([D-014](../decisions/scope.md#d-014-v01-map-specification)), Godot's editor is a massive productivity advantage. Bevy's ECS is used — just not its renderer.
|
||||
|
||||
### R-005: Pure Godot (GDScript or C#)
|
||||
- **Rejected:** 2026-02-09
|
||||
- **Reason:** Scene tree paradigm fights ECS-style simulation. Perception queries ([D-017](perception.md#d-017-perception-modes-as-character-build-system)) and information boundaries ([D-010](architecture.md#d-010-multiplayer-ready-architectural-baseline)) map naturally to ECS component queries, not scene tree traversal. Multi-core scaling for expanded content impossible in GDScript. Kept as kill-switch fallback if Rust architecture exceeds time budget.
|
||||
- **Reason:** Scene tree paradigm fights ECS-style simulation. Perception queries ([D-017](../decisions/perception.md#d-017-perception-modes-as-character-build-system)) and information boundaries ([D-010](../decisions/architecture.md#d-010-multiplayer-ready-architectural-baseline)) map naturally to ECS component queries, not scene tree traversal. Multi-core scaling for expanded content impossible in GDScript. Kept as kill-switch fallback if Rust architecture exceeds time budget.
|
||||
|
||||
### R-006: Godot + Rust via GDExtension
|
||||
- **Rejected:** 2026-02-09
|
||||
- **Reason:** gdext is pre-1.0 with breaking API changes. Godot version upgrades break GDExtension ABI. Thread safety at FFI boundary is CRITICAL risk (`Gd<T>` is `!Send`/`!Sync`). Couples Rust and Godot learning curves. Subprocess/IPC achieves the same architecture without the FFI risk surface, and maps directly to [D-010](architecture.md#d-010-multiplayer-ready-architectural-baseline) client-server. See `docs/architecture/risk-godot-rust-bridge.md` for full analysis.
|
||||
- **Reason:** gdext is pre-1.0 with breaking API changes. Godot version upgrades break GDExtension ABI. Thread safety at FFI boundary is CRITICAL risk (`Gd<T>` is `!Send`/`!Sync`). Couples Rust and Godot learning curves. Subprocess/IPC achieves the same architecture without the FFI risk surface, and maps directly to [D-010](../decisions/architecture.md#d-010-multiplayer-ready-architectural-baseline) client-server. See `docs/architecture/risk-godot-rust-bridge.md` for full analysis.
|
||||
|
||||
### R-007: Godot + C++ via GDExtension
|
||||
- **Rejected:** 2026-02-09
|
||||
@@ -42,22 +40,4 @@ Alternatives considered and rejected, with rationale preserved for future refere
|
||||
|
||||
### R-010: protobuf for client-server serialization
|
||||
- **Rejected:** 2026-02-09
|
||||
- **Reason:** Schema evolution across independent deployments is a problem we don't have (one developer, client and server ship together). Poor GDScript support. Rigid schema fights dynamic HUD composition driven by perception modes ([D-017](perception.md#d-017-perception-modes-as-character-build-system)). MessagePack's schema-optional nature fits better.
|
||||
|
||||
### R-011: Single currency for Phase 2 economics
|
||||
- **Rejected:** 2026-04-05
|
||||
- **Proposed by:** Burnelli-Sheldon (economist), Sprint 32 Workshop #796 Round 1
|
||||
- **Proposal:** Use a single currency for the Phase 2 economics simulation to reduce model complexity; exchange-rate mechanics could be added in a later phase.
|
||||
- **Reason:** Three currencies create structural economic bloc tension as an emergent property of initialization, requiring no event generation. The Tractus/Mark divide maps directly to the canonical Assembly vs. Compact political divide. Deferring to a later phase would require retrofitting political geography into a running simulation. Complexity cost low; design value high.
|
||||
- **Raised by:** Lead directive overruling the recommendation.
|
||||
- **Cross-reference:** [D-171 (economics.md)](economics.md#d-171-three-currency-system)
|
||||
- **Note:** Canonical location is `rejected.md`. Two duplicate copies in `economics.md` were removed 2026-06-06 (id-collision cleanup).
|
||||
|
||||
### R-012: Overheard NPC conversation system (D-078) — scrapped
|
||||
- **Rejected:** 2026-04-10
|
||||
- **Reason:** The entire NPC ambient interaction model (overheard conversations, room grammar, zone-type NPC population, behavior engine for physical spaces) is scrapped. These systems were designed speculatively before a walkable environment exists. The NPC interaction model will be designed and built from scratch after Phase 5 (world generation at tile level) is complete. All content authored against these systems (overheard.ron, zone-type conversation pools) is orphaned. Related content pattern note in content.md and D-078 in perception.md are superseded.
|
||||
- **Cross-reference:** D-078 (perception.md), content pattern note (content.md #664)
|
||||
|
||||
---
|
||||
|
||||
*12 rejected alternatives. Last updated: 2026-04-10*
|
||||
- **Reason:** Schema evolution across independent deployments is a problem we don't have (one developer, client and server ship together). Poor GDScript support. Rigid schema fights dynamic HUD composition driven by perception modes ([D-017](../decisions/perception.md#d-017-perception-modes-as-character-build-system)). MessagePack's schema-optional nature fits better.
|
||||
@@ -0,0 +1,12 @@
|
||||
# Rejected Alternatives — Economics
|
||||
|
||||
Rejected proposals in the **economics** domain, rationale preserved for the audit trail.
|
||||
|
||||
### R-011: Single currency for Phase 2 economics
|
||||
- **Rejected:** 2026-04-05
|
||||
- **Proposed by:** Burnelli-Sheldon (economist), Sprint 32 Workshop #796 Round 1
|
||||
- **Proposal:** Use a single currency for the Phase 2 economics simulation to reduce model complexity; exchange-rate mechanics could be added in a later phase.
|
||||
- **Reason:** Three currencies create structural economic bloc tension as an emergent property of initialization, requiring no event generation. The Tractus/Mark divide maps directly to the canonical Assembly vs. Compact political divide. Deferring to a later phase would require retrofitting political geography into a running simulation. Complexity cost low; design value high.
|
||||
- **Raised by:** Lead directive overruling the recommendation.
|
||||
- **Cross-reference:** [D-171 (economics.md)](../decisions/economics.md#d-171-three-currency-system)
|
||||
- **Note:** Canonical location is `rejected.md`. Two duplicate copies in `economics.md` were removed 2026-06-06 (id-collision cleanup).
|
||||
@@ -0,0 +1,8 @@
|
||||
# Rejected Alternatives — Perception
|
||||
|
||||
Rejected proposals in the **perception** domain, rationale preserved for the audit trail.
|
||||
|
||||
### R-012: Overheard NPC conversation system (D-078) — scrapped
|
||||
- **Rejected:** 2026-04-10
|
||||
- **Reason:** The entire NPC ambient interaction model (overheard conversations, room grammar, zone-type NPC population, behavior engine for physical spaces) is scrapped. These systems were designed speculatively before a walkable environment exists. The NPC interaction model will be designed and built from scratch after Phase 5 (world generation at tile level) is complete. All content authored against these systems (overheard.ron, zone-type conversation pools) is orphaned. Related content pattern note in content.md and D-078 in perception.md are superseded.
|
||||
- **Cross-reference:** D-078 (perception.md), content pattern note (content.md #664)
|
||||
@@ -0,0 +1,154 @@
|
||||
#!/usr/bin/env python3
|
||||
"""Restructure decisions/ into the pql governance/ DQR tree (pql migration, Phase 1).
|
||||
|
||||
Moves the flat decisions/*.md layout into governance/{decisions,questions,rejected}/<domain>.md,
|
||||
which is what `pql decisions sync` parses (type from subdir, domain from filename stem).
|
||||
|
||||
Link rewrites are TOKEN-PRESERVING: only the relative `foo.md` path portion of a
|
||||
markdown link changes; the `[D-NNN]` bracket text and `#d-nnn-...` anchor stay
|
||||
byte-identical, so pql's reference extraction is unaffected regardless of whether it
|
||||
reads bracket text, anchor, or path.
|
||||
|
||||
Default is a dry run (prints every planned move + link change). Pass --apply to execute.
|
||||
Idempotent-ish: re-running after apply is a no-op for moves (sources already gone).
|
||||
"""
|
||||
import re
|
||||
import subprocess
|
||||
import sys
|
||||
from pathlib import Path
|
||||
|
||||
ROOT = Path("/var/mnt/data/projects/settled-reach/main")
|
||||
APPLY = "--apply" in sys.argv
|
||||
|
||||
DSTEMS = {"architecture", "content", "economics", "perception", "process", "scope"}
|
||||
QSTEMS = ["architecture", "content", "perception", "process", "scope"]
|
||||
|
||||
# R-record -> domain (R-001..R-010 platform/engine = architecture; R-011 economics; R-012 perception)
|
||||
def rdomain(n: int) -> str:
|
||||
if n == 11:
|
||||
return "economics"
|
||||
if n == 12:
|
||||
return "perception"
|
||||
return "architecture"
|
||||
|
||||
REJECTED_DOMAINS = sorted({rdomain(n) for n in range(1, 13)}) # architecture, economics, perception
|
||||
|
||||
LINK = re.compile(r"\]\((?P<path>[A-Za-z0-9_-]+\.md)(?P<frag>#[^)]*)?\)")
|
||||
|
||||
|
||||
def new_target_path(path: str, frag: str, src_subdir: str):
|
||||
"""Return the rewritten relative path for a link target, or None to leave unchanged."""
|
||||
stem = path[:-3]
|
||||
if path == "rejected.md":
|
||||
m = re.match(r"#r-0*(\d+)", frag or "")
|
||||
rd = rdomain(int(m.group(1))) if m else "architecture"
|
||||
ttype, tdom = "rejected", rd
|
||||
elif path.startswith("questions-"):
|
||||
ttype, tdom = "questions", stem[len("questions-"):]
|
||||
elif path in ("questions.md", "README.md"):
|
||||
ttype, tdom = "index", None
|
||||
elif stem in DSTEMS:
|
||||
ttype, tdom = "decisions", stem
|
||||
else:
|
||||
return None # unknown stem; leave as-is
|
||||
|
||||
if ttype == "index":
|
||||
return "README.md" if src_subdir == "root" else "../README.md"
|
||||
if ttype == src_subdir:
|
||||
# same subdir: bare filename
|
||||
return f"{tdom}.md"
|
||||
# cross-subdir
|
||||
prefix = "" if src_subdir == "root" else "../"
|
||||
return f"{prefix}{ttype}/{tdom}.md"
|
||||
|
||||
|
||||
def rewrite_links(text: str, src_subdir: str):
|
||||
changes = []
|
||||
|
||||
def repl(mo):
|
||||
path, frag = mo.group("path"), mo.group("frag") or ""
|
||||
np = new_target_path(path, frag, src_subdir)
|
||||
if np is None or np == path:
|
||||
return mo.group(0)
|
||||
changes.append((f"{path}{frag}", f"{np}{frag}"))
|
||||
return f"]({np}{frag})"
|
||||
|
||||
return LINK.sub(repl, text), changes
|
||||
|
||||
|
||||
def git(*args):
|
||||
subprocess.run(["git", "-C", str(ROOT), *args], check=True)
|
||||
|
||||
|
||||
def log_changes(rel, changes):
|
||||
if changes:
|
||||
print(f" {rel}: {len(changes)} link(s) rewritten")
|
||||
for old, new in changes:
|
||||
print(f" {old} -> {new}")
|
||||
|
||||
|
||||
def move_and_rewrite(src_rel, dst_rel, src_subdir):
|
||||
src, dst = ROOT / src_rel, ROOT / dst_rel
|
||||
text = src.read_text(encoding="utf-8")
|
||||
new_text, changes = rewrite_links(text, src_subdir)
|
||||
print(f"MOVE {src_rel} -> {dst_rel}")
|
||||
log_changes(dst_rel, changes)
|
||||
if APPLY:
|
||||
dst.parent.mkdir(parents=True, exist_ok=True)
|
||||
git("mv", src_rel, dst_rel)
|
||||
dst.write_text(new_text, encoding="utf-8")
|
||||
|
||||
|
||||
def split_rejected():
|
||||
src_rel = "decisions/rejected.md"
|
||||
text = (ROOT / src_rel).read_text(encoding="utf-8")
|
||||
# split into records on '### R-' headings
|
||||
parts = re.split(r"(?m)^(?=### R-\d)", text)
|
||||
head = parts[0] # title + intro before first record
|
||||
records = parts[1:]
|
||||
buckets = {d: [] for d in REJECTED_DOMAINS}
|
||||
for rec in records:
|
||||
m = re.match(r"### R-0*(\d+)", rec)
|
||||
n = int(m.group(1))
|
||||
# strip a trailing '---' / footer that may cling to the last record
|
||||
body = re.split(r"(?m)^---\s*$", rec)[0].rstrip() + "\n"
|
||||
buckets[rdomain(n)].append(body)
|
||||
print(f"SPLIT {src_rel} -> {len(REJECTED_DOMAINS)} domain files")
|
||||
for dom, recs in buckets.items():
|
||||
dst_rel = f"governance/rejected/{dom}.md"
|
||||
title = f"# Rejected Alternatives — {dom.capitalize()}\n\nRejected proposals in the **{dom}** domain, rationale preserved for the audit trail.\n\n"
|
||||
content = title + "\n".join(recs).rstrip() + "\n"
|
||||
content, changes = rewrite_links(content, "rejected")
|
||||
print(f" -> {dst_rel}: {len(recs)} record(s)")
|
||||
log_changes(dst_rel, changes)
|
||||
if APPLY:
|
||||
(ROOT / dst_rel).parent.mkdir(parents=True, exist_ok=True)
|
||||
(ROOT / dst_rel).write_text(content, encoding="utf-8")
|
||||
if APPLY:
|
||||
git("rm", src_rel)
|
||||
|
||||
|
||||
def main():
|
||||
print(f"=== restructure_decisions.py ({'APPLY' if APPLY else 'DRY-RUN'}) ===\n")
|
||||
# 1. D-domain files -> governance/decisions/
|
||||
for s in sorted(DSTEMS):
|
||||
move_and_rewrite(f"decisions/{s}.md", f"governance/decisions/{s}.md", "decisions")
|
||||
print()
|
||||
# 2. questions-<domain>.md -> governance/questions/<domain>.md
|
||||
for q in QSTEMS:
|
||||
move_and_rewrite(f"decisions/questions-{q}.md", f"governance/questions/{q}.md", "questions")
|
||||
print()
|
||||
# 3. rejected.md -> governance/rejected/<domain>.md (split by domain)
|
||||
split_rejected()
|
||||
print()
|
||||
# 4. index files (README.md, questions.md) are folded into governance/README.md by hand;
|
||||
# remove the originals here.
|
||||
for idx in ("decisions/README.md", "decisions/questions.md"):
|
||||
print(f"REMOVE {idx} (folded into governance/README.md)")
|
||||
if APPLY:
|
||||
git("rm", idx)
|
||||
print("\nDone." + ("" if APPLY else " (dry run — pass --apply to execute)"))
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
Reference in New Issue
Block a user