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 |
| ENG001 | Establish existing implementation and run constraints | Prototype engineer (not created) | Blocked | Agent creation; relevant project access or confirmation none exists | Verifiable inventory; environment limits; build path; smallest technical risk experiment / PM |
| QA001 | Challenge the prototype proposal and define checks | Playtest and QA reviewer (not created) | Blocked | Agent creation; brief; DES001 proposal | Specific falsification questions, observable checks and severity rules / PM |
| ENG002 | Produce a playable core-loop experiment | Prototype engineer (not created) | Blocked | PM-scoped design, workable environment, reviewed plan | Runnable artifact and revision; controls; meaningful choice; visible consequence; conclusion/retry; observed run evidence / QA then PM |
| QA002 | Independently review the exact prototype build | Playtest and QA reviewer (not created) | Blocked | ENG002 artifact | Run record; reproducible issues; untested areas; gate recommendation / PM |
| 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.