2026-09-06 15:55:15
Anonymous:
PM: record owner brief, design-only gate, asset restrictions, and revised team
hold the flood/tasks.md ..
@@ 1,45 1,55 @@
-
# Hold the Flood — Tasks and Evidence
-
-
Maintainer: PM. Updated: 2026-09-06 UTC.
-
Workflow: **Ready → In progress → In review → Accepted**, with **Blocked** and **Cancelled** available. Only PM marks Accepted. Proposed staffing does not mean an agent is running.
-
-
## Current work
-
| ID | Outcome | Owner | State | Dependency | Acceptance evidence / reviewer |
-
| --- | --- | --- | --- | --- | --- |
-
| PM001 | Establish hub, brief, tasks, and copy-ready prompts | PM | Accepted | None | Hub, Brief, Team and Tasks published; page contents and navigation checked by PM |
-
| OWN001 | Establish game intent and known constraints | Project owner, facilitated by PM | Ready | None | Owner answers recorded with unresolved points clearly marked / PM |
-
| DES001 | Propose the smallest test of the intended game | Game designer (not created) | Blocked | Agent creation and core owner brief | One-page interaction specification; choices, feedback, success/failure, three design risks, explicit cuts / PM plus QA critique |
| OWN002 | Play and judge the direction | Project owner, facilitated by PM | Blocked | Runnable reviewed prototype | Owner feedback on intended experience; iterate/pivot/advance decision / PM records |
-
-
DES001's first brief may be short. ENG001 can proceed alongside design once access is available. Do not wait for a large design document.
-
-
## Task detail template
-
- ID and title:
-
- One-sentence player or project outcome:
-
- Implementer / independent reviewer:
-
- State / last meaningful update (UTC):
-
- Dependencies and required access:
-
- Deliverable location and revision:
-
- In scope / explicit cuts:
-
- Acceptance criteria (observable):
-
- Verification performed and result:
-
- Known risks, blocker, next action:
-
- Review verdict, PM acceptance, and supporting links:
-
-
## First playable gate
-
Apply to the approved game concept and platform; adjust only with an explicit task decision.
-
- A reviewer can obtain and start the specified revision using the supplied instructions.
-
- The player can discover the controls and goal.
-
- The intended core action presents at least one meaningful choice with readable consequences.
-
- The short test has a clear end or outcome and can be repeated.
-
- The exact build has been independently exercised. Critical crashes, softlocks, and loss of required progress block acceptance.
-
- The owner has a playtest question to answer. No invented claim of enjoyment or user validation.
-
-
## Review and rework
-
A rejection names the artifact revision, failed criterion, observation or reproduction steps, severity, and smallest useful correction. Engineer addresses the issue; reviewer checks the changed behavior. Avoid circular debate and unlimited polishing. PM decides whether another attempt is justified or the scope should change.
-
-
Current verified output: wiki inspection and initial process setup only. No game agent has been created, and no playable build has been reviewed.
+
# Hold the Flood — Design Tasks
+
+
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.
+
+
## Active design sequence
+
| 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.
+
+
## Superseded or deferred work
+
| 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 |
| 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.
+
+
## What the design document must make clear
+
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.
+
+
## Review criteria
+
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.
+
+
## Progress report
+
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.
