Home > Wiki > Decisions > Design Clarifications — 2026-05-12

Design Clarifications — 2026-05-12

Status: ACTIVE Agent: opencode/ext-agent (sandshrew) Timestamp UTC: 2026-05-12T01:00:00Z Session: MjF review of game overview — clarifications and additions

1. Curation Agent Is Standalone

When context is routed with the "Curated" method, a standalone curation agent handles the work — NOT the unit, NOT the node function. This agent spawns, reads source output + target task + upstream decisions, filters for relevance, writes curated subset to state, and resolves.

Key capability: decision awareness. If a Define node decided "Use React," the curation agent filters research output to include only React-relevant findings — ignoring Vue/Svelte context entirely.

State keys: routed_context[target][from_source] and decisions (list of made decisions the curation agent checks).

2. Node State Gating

Nodes have prerequisite logic defined at graph compilation. A Design node can't be entered unless its upstream Research node has reached "MVP" status. Node states:

open — enterable
locked — prerequisites not met (shows which)
in_progress — unit working
completed — MVP reached
deepened — MVP + additional depth

Locked nodes display unsatisfied prerequisites. When a prerequisite completes, the node auto-unlocks. Gating logic is compiled into the graph — not bypassable without recompilation.

3. Unit Names Are Placeholders

Rif, Echo, Sherpa are stand-ins. Final agent harnesses, model choices, and role assignments have not been decided. They will be defined once toolchain, model availability, and wiring are settled.

4. One Unit Per Hex

Only one unit can occupy a hex at a time. A unit represents a context trail + agent config profile working on that node's task. Multiple sub-agents (pollers, curation agents, harvesters) may operate behind the scenes, but the unit is the single visible locus of work on the hex grid.

5. Wiki/Repo Wiring — Pending Specification

The mapping between graph state and external surfaces (LLM wiki, Forgejo) must be defined before build. Requirements flagged:

Nodes → Wiki pages (standalone or shared)
Nodes → Forgejo issues (status sync, phase labels)
Output → Branches/PRs (code artifacts linked to nodes)
Source links → Wiki ingest workflow (proper source registration)
Cross-references → Bidirectional linking (wiki ↔ node, forgejo ↔ wiki)

Exact protocol (key mappings, issue templates, auto-linking) to be specified before implementation.

6. Iterative Deepening

The prototype spec is not a hard lock. Wiki pages use status markers: seed (initial concept), active (current model), disputed (needs revision). Both the prototype spec and conceptual ruminations live in the same depot — the wiki harbors both layers simultaneously. Nothing is frozen. Everything is traceable.

Addendum: Runtime Wiki Structure

7. Wiki Opens on RG, Not Mac

The wiki is context-sensitive and opens on the RG40XXV — not cross-device to Mac. The "table of contents" is not the global wiki TOC. It's the most natural top-line page for whatever convention you're viewing:

Node Y → that node's page (output sections, summary, context references)
Unit Y → that unit's page (trail history with links, config, outputs produced)
Trail view → trail as navigable page (each context item linked to source)

8. Runtime Wiki Is Convention-Organized

During a run, the wiki has a temporary structure organized by game conventions:

/runtime/{run_id}/
  nodes/hex_14.md    ← node-specific output
  units/rif.md       ← unit trail + history + links
  index.md           ← runtime TOC by convention

Units maintain their own pages. Nodes maintain their own pages. Trails are navigable pages. Links connect them. Redundancies are fine during runtime.

9. Post-Run Metabolism (Deferred)

After the run, the modular runtime pages get metabolized into the global OmniWiki. The player decides what goes where. This logic is not defined now — only the runtime structure is in scope for the prototype.