Maintainer: PM. Revision: design-only reset, 2026-09-06 UTC.

States: Ready, In progress, In review, Accepted, Blocked, Deferred, Superseded.

A proposed agent is not assumed to exist. PM accepts design work; the owner authorizes a phase change.

| ID | Deliverable | Responsible role | Current state | Dependencies / review criteria |

| --- | --- | --- | --- | --- |

| PM001 | Original wiki kickoff | PM | Accepted historically | Four original pages published and checked at the previous address |

| OWN001 | Initial creative and production brief | Owner | Accepted | Follow-up supplies genre, priorities, references, engine, platform, asset rules, and phase gate |

| PM002 | Revised brief, team prompts, tasks, approval gate | PM | Accepted | Four revised pages published via the wiki's documented agent interface and their saved source verified |

| DES101 | Two compact concept directions and one recommendation | Lead Game and Systems Designer | Blocked on agent invocation | Each: player fantasy, main actions, survival pressure, discovery, build expression, progression, one distinct interaction, major scope cuts / critic + PM |

| WLD101 | Exploration and mystery contribution | World and Mystery Designer | Blocked on agent invocation | Can start alongside DES101; show a complete clue-to-deduction-to-action chain, knowledge progression, and pressure/curiosity tradeoff / lead + critic |

| OWN101 | Steer the recommended concept | Owner, facilitated by PM | Waiting for concept packet | Confirm or adjust premise and priorities; this is not development approval |

| DES102 | Integrated game design document draft | Lead Game and Systems Designer | Waiting for working concept | Integrate accepted world/mystery work; meet the document criteria below / critic + PM |

| REV101 | Independent design critique | Independent Design Critic | Blocked on agent invocation and first draft | Start with DES101/WLD101 when available; identify specific contradictions, weak choices, asset/scope risks and corrections / PM |

| DES103 | Revised owner-facing design document | Lead Game and Systems Designer | Waiting for integrated draft and critique | Resolve material findings; preserve explicit unknowns; concise pitch plus supporting detail / PM |

| OWN102 | Design verdict and possible development authorization | Owner | Waiting for reviewed document | Revise / reject / approve design; development remains gated until explicitly authorized |

DES101 and WLD101 begin from the confirmed brief; they may propose assumptions for undecided setting details. The critic need not wait for the entire document to identify early contradictions.

| Previous ID / assignment | New status | Reason |

| --- | --- | --- |

| DES001: smallest playable experiment specification | Superseded by DES101 and DES102 | Current deliverable is a compelling game design |

| ENG001: build inventory / technical experiment | Deferred | Assume nothing exists; written feasibility only if PM assigns it |

| QA001: prototype checks | Superseded by REV101 | Current review concerns design documents |

| ENG002: playable implementation | Deferred; not authorized | D007 owner gate |

| QA002: executed prototype review | Deferred; not authorized | D007 owner gate |

| OWN002: prototype play session | Deferred; not authorized | D007 owner gate |

Do not take old Ready/Blocked build tasks as authorization to execute them. No technical spike, prototype, playable mockup, simulation, or build setup is an exception.

1. **Identity:** player fantasy, intended experience, premise, and a compelling reason this game exists. Explain it in its own terms, with references as supporting context.

2. **Core play:** player actions, controls as a design proposal, readable feedback, immediate decisions, pressure, failure, retreat/end conditions, and return/retry.

3. **Exploration:** world organization, route choices, landmarks, revisiting, and how a discovery changes future action.

4. **Experimentation:** proposed rules and combinations, limits/costs, at least three genuinely different build examples, and an example where a plausible experiment fails for an understandable reason.

5. **Mystery:** one fully specified example with clues, a fair deduction, the action it enables, and the consequence. Mark solutions as designer spoilers. Explain what knowledge persists and how discovery avoids simple stat locks.

6. **Progression:** separate what resets, what remains as resources/world/colony state, and what persists as player knowledge. Explain any colony loop's actual decisions and cost.

7. **Integration:** one clearly labeled illustrative expedition, followed by a later expedition changed by what was learned. Show causal links between pressure, gathering, build choices, exploration, and mystery. Do not invent playtest outcomes.

8. **Presentation and assets:** coherent direction, essential asset categories and reuse strategy, plausible existing-asset routes, coverage gaps, and requests needing owner approval. Asset availability and usage terms must not be invented.

9. **Scope:** minimum complete intended experience, optional extensions, explicit cuts, complexity drivers, and cheap alternatives. Avoid huge item/lore catalogues before the rules justify them.

10. **Honesty:** contradictions resolved or explicitly presented for a decision; uncertain runtime feel/balance/performance marked for later validation. No claims of tested enjoyment.

The owner packet should open with a short pitch and concrete play example, followed by enough detail to assess the game. Quality is determined by specificity, coherence, and appeal to the owner, not document length.

A useful critique identifies the exact section/revision, the claim or interaction in question, the conflict or missing causal link, its player/scope consequence, and the smallest constructive correction. Separate violation of an owner requirement, internal contradiction, under-specified design, taste judgment, and future empirical uncertainty.

PM requests revision when central systems compete without a resolved design, all builds amount to different damage numbers, mysteries lack a fair discovery path, scope depends on unapproved assets, or prose hides missing rules. Document review does not establish actual balance, feasibility, or fun.

Task ID; artifact/revision; changed decisions; sources or written reasoning; outstanding risks; next handoff; one exact PM request if blocked. Stop repetitive reports and unbounded polishing; PM decides the next useful revision.