settled-reach/governance/decisions/process.md

Process Decisions

How the team works: composition, naming, workflow.

---

D-004: Team composition confirmed

• Date: 2026-02-08
• Decision: Team of 8 agents + Team Leader.

Agent	Role
MIRI	Lore Expert & Canon Guardian
OZZIE	Player Experience / "Wow Factor" Advocate
PAULA	Narrative & Political Depth
GORE	Themes & Endgame Design
GESTALT	Systems Design & Fun Factor
NIGEL	Sandbox & Replayability
TYRE	Technical Architecture & Feasibility
SCRIBE	Documenter
Jeroen	Team Leader, final decisions

D-021: Official project title — "The Settled Reach"

• Date: 2026-02-10
• Decision: The official project and game title is "The Settled Reach". The domain settledreach.com has been secured. Individual campaigns or scenarios can have subtitles in the format "The Settled Reach: [Scenario Name]" but the core title remains consistent.
• Rationale: Following Round 14's worldbuilding confirmation establishing the Settled Reach as the original setting, the Team Leader confirmed this as the official project title. The name reflects the setting's core tension: a civilization that has "settled" across the stars but whose "reach" is ultimately limited by infrastructure it doesn't fully control or understand.
• Repository note: The repository folder and git history will remain as "commonwealth" for historical continuity and to avoid breaking existing paths. The code name vs official title distinction is acceptable (similar to how game projects often have internal code names).
• Raised by: Team Leader (Jeroen), following Round 14 worldbuilding discussion.
• Dissent: None.

D-022: Process — Round-based collaboration workflow

• Date: 2026-02-10
• Decision: Going forward, discussions are captured directly in round documents at docs/discussions/round-NN-topic.md rather than in DISCUSSION.md. DISCUSSION.md has become unwieldy to manage and archive. Qatux must be included in all team interactions (single-agent or multi-agent) to document discussions.
• Rationale: DISCUSSION.md grew to 26,000+ tokens and became clunky to archive. Direct round document creation is cleaner and more maintainable. Qatux's inclusion ensures no decisions or context are lost.
• New workflow:
  1. Create round document at docs/discussions/round-NN-topic.md
  2. Document collaboration within that file
  3. Extract decisions to appropriate domain file in decisions/
  4. Update discussions README
  5. Re-index as needed
• Raised by: Team Leader (Jeroen).
• Dissent: None.
• Effective: Immediately (Round 15 onward).

D-040: Wiki taxonomy structure — hierarchical with YAML frontmatter

• Date: 2026-02-11
• Decision: The project maintains a wiki at wiki/ with a hierarchical directory structure, YAML frontmatter metadata on every entry, and template-driven creation. The structure must be established NOW (project lead directive) and scale from v0.1 (1 system, 1 station, 15 NPCs) to full game (hundreds of systems, thousands of NPCs).
• Directory structure:
  • wiki/_templates/ — entry templates (star-system, station, district, location, character, faction, technology, cultural-group, contraband-type, lore-entry, institution, species, event, concept)
  • wiki/star-systems/ — spatial hierarchy (system → station → district → location)
  • wiki/characters/ — flat structure (characters move between locations)
  • wiki/factions/ — political and institutional bodies
  • wiki/technology/ — technology categories with tier sub-entries
  • wiki/cultural-groups/ — cultures, subcultures, movements
  • wiki/contraband/ — illegal/restricted goods
  • wiki/lore/ — historical events, concepts, cosmology
  • wiki/concepts/ — game-mechanical concepts with lore basis
  • wiki/_meta/ — naming conventions, style guide, cross-reference index
• Design principles: (1) Game-first, not encyclopedia-first — every entry serves the content pipeline. (2) Hierarchical with cross-references via IDs, not file paths. (3) Metadata-rich YAML frontmatter enabling programmatic queries. (4) Template-driven — new entries follow category templates. (5) Every entry has a status field: proposed → draft → canonical.
• Governance: Miri owns wiki structure (new categories, templates, structural decisions). Anyone can create entries within their domain following templates. Qatux maintains the index and cross-references.
• Cross-reference: Setting (D-036)
• Raised by: Miri (Round 2 proposal with full directory structure and 7 YAML schemas), project lead (non-negotiable, directive T-5)
• Dissent: None

---

D-221: Replace sprint workflow with kanban + milestones

• Date: 2026-05-03
• Decision: Sprint-based workflow (38 sprints, Sprint 1–38) replaced by kanban + milestones. Sprint infrastructure deleted from the repo — git history serves as the archive. No rollback provision maintained in the codebase.
• What stays: Cascade phases (macro direction), agent personalities (divergence engines), D-records, tickets (descriptive not prescriptive), workshops, rules/memory system.
• What changes:
  • Sprint boundaries → milestones tied to concrete deliverables (cascade phase, feature gate)
  • Sprint briefings → live ticket queries (ticket list --status in_progress + dependency graph)
  • Team branches (sprint-N/team) → topic branches per logical work unit
  • File-scope restrictions per team → removed; any agent can touch any file
  • Version v0.1.{sprint_number} → v0.{phase}.{n} tied to cascade phases
  • Si (project manager) → Si (refinement manager) + new clerk agent (institutional guardrail)
  • /sprint-start → /whats-next (dependency-driven batch selection with parallel Si refinement review)
  • /pr-push → /pr-process (author-side review cycle: commit, push, pick up reviewer comments, dispatch fixes)
  • Milestones are many-to-many with tickets, can run in parallel, can block other milestones
• What dies: Sprint CLI (tooling/db/sprint), sprint skills (/sprint-start, /sprint-plan, /sprint-status), sprint briefing files, sprint close/kickoff ceremonies, team-scoped file restrictions.
• Rationale: Structural failure modes across Sprints 37–38: ticket-as-contract (agents execute the letter instead of reading the code), artificial delay (ready work parked for "next sprint"), role theater (file-scope restrictions blocking one-liner fixes), order rigidity (stale briefings), locking on bad design (ticket authority overriding code reality), self-review collapse (coding + reviewing in same context window). See Q-096 for full analysis.
• Test plan: First milestone is Tier 0+1 planet-down-cascade work (6 schema tables + 6 Python importers). Measurement: did work flow or stall? Did removing file-scope restrictions cause chaos? Did tickets-as-description work?
• Source: Q-096 (raised 2026-04-20, expanded 2026-05-01)
• Raised by: Jeroen
• Dissent: None
• Amendment (2026-06-12): Milestones are retired. pql has no milestone entity; phase gating is the cascade ticket hierarchy — initiative T-745 holds the six phase epics, a ticket is in a phase by being parented under that phase epic, and the active phase is the in_progress phase epic (currently T-750, Phase 4). The two milestone bullets above ("Sprint boundaries → milestones tied to concrete deliverables" and "Milestones are many-to-many with tickets, can run in parallel, can block other milestones") are superseded by this mechanism; kanban, topic branches, and the rest of the record stand. Phase-independent maintenance and test-debt work lives under a dedicated maintenance initiative rather than a phase epic. See CLAUDE.md "Work Modes" and .claude/rules/ticket-cli.md, which already describe the hierarchy model.

---

D-241: Spike binary artifacts are local-only — gitignored, never tracked

• Date: 2026-06-12
• Decision: Binary artifacts under spikes/ (models .glb/.gltf/.bin/.fbx/.blend, textures/renders .png/.jpg/.webp/.exr/.hdr, archives .zip) are local-only: gitignored going forward, and the 416 previously tracked files (~1.7 GB at tip) are removed from the index (kept on disk). What stays tracked in spikes/: verdict/handover markdown, spike code (.py/.gd/.tscn/.gdshader), and small config/JSON — the knowledge, not the bytes.
• Rationale: Tracked spike binaries made every clone pay ~1.7 GB for prototype outputs that are reproducible from purchased source packs (docs/assets/downloads/, already gitignored) plus the tracked spike scripts; the weight grows with every Phase-4/5 asset spike. An audit scan (fable-ous.md S-14) found zero markdown-embedded images in spikes/, so untracking breaks no documentation. The repo already uses this pattern for vendor/ and docs/assets/downloads/.
• Boundary: Production assets are promoted out of spikes/ into client/assets/ (with manifest registration) and remain fully tracked there — promotion is the act that makes an asset repo-canonical. Spike outputs that matter must either be promoted or be reproducible from tracked scripts.
• Not included: History rewrite. The ~1.7 GB remains in git history; purging it (filter-repo/LFS migration) is a separate, deliberately unmade decision — revisit if clone cost becomes a real problem.
• Raised by: Jeroen (directive, 2026-06-12), from the fable-ous.md audit finding S-14.
• Dissent: None.
• Cross-reference: .gitignore spikes section, docs/assets/downloads/ (purchased sources), fable-ous.md §2 S-14.

---

6 decisions. Last updated: 2026-06-12