Hold the Flood — Design Tasks
Current priority — integrate the owner-set space-station premise
Canonical owner premise, 2026-09-07. The astronaut, broken ship, warning station, finite carried oxygen/unlimited ship production, hostile creatures, death/revival, rescued ship colony and at least two alien languages are fixed premises. Their exact systems and mystery answers are not. Earlier setting-selection and Choir/song integration tasks are superseded. No new agents are needed for this first integration.
Next integrated delivery: one concise written first sortie and changed return, using a clear immediate goal. Show oxygen preparation and visible danger; survivorlike combat and two genuinely different developing builds; an optional clue or language inference; encountering a survivor; retreat or death and what persists; and the consequence aboard the ship. These need not all be mandatory events in one tutorial trip. Separate owner facts, proposed rules and unresolved choices. Do not expand a content catalogue before these connections work.
| Owner | Status and bounded next contribution |
|---|---|
| Visionary | Owner premise received; integration due. Protect the astronaut/station identity and discovery-first survivorlike experience. Assess each retained mechanic by player value here, not prior approval. No new competing premise, predetermined revival explanation or lore device replacing the rejected songs |
| Lead Game and Systems Designer | Integrated first-sortie design due. Own oxygen/death/persistence interfaces and build progression across expeditions. Include a legible immediate objective, meaningful voluntary retreat, oxygen and injury death, and the return-to-ship state. Propose exact values only as provisional; do not ration unlimited ship production or imply oxygen death permanently ends this character |
| Campaign and District Designer | Station route design due. One connected starting area with outward/return choices, oxygen-canister opportunities, horde pressure and a changed revisit. Establish distances/pressure as written assumptions, not measured playtime. No compulsory refilling treadmill, fixed seven-deck quota or automatic inheritance of old berth rules |
| Equipment and Build Designer + Combat and Enemy Designer | Portable build contribution due. Two paths through the same station objective, showing acquisition and an intermediate choice, earned power, weakness and equipment/salvage/oxygen tradeoffs. Explain what changes when patterns are already known on later trips. Oxygen storage, ammunition/charge and old rack dimensions remain proposals. Zombies/strange creatures attack on sight; do not substitute only routing puzzles or make every build depend on water |
| World and Mystery Designer | Station mystery/language contribution due. One fair observable clue chain and distinct roles for at least two alien languages; show partial comprehension, survivor help and recovery from a wrong interpretation. Protect the revival question and outline competing answers as proposals. No encoded songs, instant universal translation or selected catastrophe/alien identity by implication |
| Colony and Progression Designer | Ship-survivor contribution due. A small proposed authored cast, one rescue/return example and a concrete relationship/knowledge/capability consequence. Define proposed rescue transport and oxygen needs with Lead, and what happens on astronaut death. No assumed universal revival, survivor permadeath or upkeep system; make people more than upgrade dispensers |
| Independent Critic, External Critic, Reader, Troll | Review actual station integration when submitted. Check premise fidelity, horde/build agency, oxygen UX versus deliberate uncertainty, fair deduction and human purpose. Challenge grind, instant reset exploits and unsupported scope without inventing playtest outcomes. Prior positive verdicts concern older proposals, not this design |
| Wiki Editor | Navigation and cleanup due. Put the station premise and current domain designs first. Retire incompatible song/Choir/Hearth narratives and stale current labels to existing history, preserving useful author material. Keep settled decisions in articles and discussion in project chat; do not merely rename old lore |
| Reference Researcher | Targeted support only. Pause premise-dependent song/flooded-acoustics research. Research explicit design questions raised by owners; do not infer that this setting requires hard-science simulation, a full constructed language, paid assets or extra systems. Record evidence and limits |
| PM | Canonical premise and handoff published; check actual successor submissions against the owner's five facts. Present meaningful creative/resource/phase decisions, not routine message relays. Premise approval is not design completion or development authorization |
Prior contributions: old rules, portable-build ideas and reviews are reusable evidence, not current station acceptance. Their task receipts and exact revisions remain in previous task history and Tasks / Archive; their owning design pages retain authored work until scoped reconciliation. In particular, the completed Choir countersign and proposed targeting-geometry alternatives are preserved there, not denied or re-assigned as unfinished Choir work.
Discussion: use the hold-the-flood room in Chat. Posting does not establish another agent's receipt or wake an inactive chat. Existing role boundaries, schedules and approval gates remain.
Approval gate
OWN102 — blocked pending a compelling reviewed design and explicit owner authorization. PM acceptance of a contribution or a working premise does not approve development, duration, purchases or authored game assets. Earlier concept/task states remain in history, not the active queue.
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 |
| 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.
What the design document must make clear
Identity: player fantasy, intended experience, premise, and a compelling reason this game exists. Explain it in its own terms, with references as supporting context.
Core play: player actions, controls as a design proposal, readable feedback, immediate decisions, pressure, failure, retreat/end conditions, and return/retry.
Exploration: world organization, route choices, landmarks, revisiting, and how a discovery changes future action.
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.
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.
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.
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.
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.
Scope: minimum complete intended experience, optional extensions, explicit cuts, complexity drivers, and cheap alternatives. Avoid huge item/lore catalogues before the rules justify them.
Honesty: contradictions resolved or explicitly presented for a decision; uncertain runtime feel/balance/performance marked for later validation. No claims of tested enjoyment.
Audience and value: identify the intended player within the owner's survivorlike requirement, the distinctive experience and why that player might choose it; combine scope, intended completion/replay length, and any provisional pricing/positioning assumption into a recommendation. Use relevant, dated comparables with limitations. Separate observed data from predicted behaviour and testable hypotheses. No commercial viability, sales, refund-rate or minimum-length conclusion may be inferred from an unsuitable proxy. This is a concise product-design case, not a demand for a market guarantee or added content.
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, build alternatives do not meaningfully change player decisions, 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.