Hold the Flood — Design Tasks

Earlier assignments and submission history. The prior archive index and retired task tables remain in Tasks 003dcc.

Current priority — apply the owner's discovery-first direction

2026-09-07 · Canonical owner answers. This priority supersedes incompatible assignments below. The harvest-dependence twist is rejected; routing enemies is a supporting tool; the prior complete-game scope is insufficient for the owner's 30/90/100–200-hour ambition. Earlier accepted contributions remain evidence, not a requirement to preserve their fiction or mechanics.

Existing queue: pause polishing the old harvest ending, the one-road refuge example, Exchange encounter accounting and the exclusive-service comparison until the Visionary identifies which systems and scenes survive the new direction. Clear factual corrections may still be applied to retained material, but old correction tickets must not drive the new design. No new agent or owner relay is needed for this first redirection pass.

Acceptance is creative, not numerical: the owner should be able to picture the game, its heart and a discovery they want to pursue. The hour targets require a defensible content plan later; they are not satisfied by asserted playtime or grind. Design-only and asset approval gates remain.

Discussion has moved to the hold-the-flood room in Chat. Follow the team workflow: discuss and announce there; keep this board to current assignments and concise outcomes. Existing design-only constraints remain.

CLR102 — current clarity status

In review; PM owns acceptance. Review 3e1da4 finds Brief 342043, The World Below clear enough for owner review. It identifies the scavenger-inventor, Hearth's immediate and longer goals, the Flood, the repeated expedition loop, meaningful build/cargo/route choices and reasons to return without glossary dependence. No new consequential comprehension gap. The progression beyond the answering settlement and support for the 90–200-hour ambition remain explicitly unresolved design/content work for Lead and Campaign, not a clarity question. Next: review only a substantive successor owner/newcomer artifact. Prior-premise findings remain historical; existing review cadence and design-only gates are unchanged.

CMB102 — Choir Cascade disposition

Combat r13 / 600893 supplied useful arithmetic but its four-origin/sixteen-body cap is superseded. It openly missed the owner's screen-wipe target, and PMR011 correctly observed that a finite encounter can be cleared without unbounded global propagation. The one-use Echo Relay item is also retired: its only job was permitting an authored interaction the Choir environment expresses more clearly.

Current integration rule: a full, separately banked Coil and Arc fired through the central furnace's tuned Choir network empties both banks and strikes every Coil-stunned ordinary body in the finite lit wet footprint once, killing it. This lethality is network-specific; ordinary Coil plus Arc keeps Combat's standard chain cap and damage. Crust, Heavy, dry/outside bodies and a later wave survive; the network trips for the expedition. Lead/Combat should mirror this exception without reopening it into a global chain rule. Counts, performance, readability and feel remain untested.

EXT102 — current review status

External Critique r19 / 9b0ba6: replacement premise/expedition was pending at that read; Brief 342043 now exists, but this review supplies no verdict on it. X37 is independently withdrawn on Campaign 93f482's actual route correction, not reopened by redirection. The previous-premise verdict is historical. Next: review the existing replacement-proposal deliverable; no old-scene or service-policy polishing requested. PM owns acceptance; discussion is in project chat.

COL103 — Hearth growth proposal

PMR011: accepted model, timing narrowed. Authored people, fulfilled promises, persistent knowledge, free legality feedback and no hidden decay support the direction. The first return has no fabricated capital fork: pre-credits Hearth changes through returned furnace parts, and salvage may be banked. Tavi/Senn paid projects wait until the plate/lift creates honest field or relationship consequences. Current prices, cast size, defence outcomes and production assets remain unapproved.

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

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.

11. 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, 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.