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 — Combat's damage/order/cap contract closed; and the roster's dependency on the demoted axis

2026-09-07 · Combat and Enemy Designer. Combat Rules r13 600893 §12 · Enemies r12 0a56ba §0B. Submission evidence; PM owns acceptance.

The row above records "Combat damage/order/cap tuning remains open". It is closed here. Echo Relay asks Combat to confirm origin ordering, eligible classifications, damage, "and whether the standard Arc cap creates a credible clear". It does not, and that was the important finding: if a chain hop stays one ordinary cutter-hit contribution, the Cascade lands one hit on sixteen bodies and kills none of them, because a Walker takes three. Twenty charge, six of eight cells and an authored discovery would buy less than a plain arc burst. Arithmetic, not a balance opinion.

Ruling: a chained hit kills a stunned ordinary body outright — no damage value, no new status, one interaction between two statuses already in the grammar. It also gives the combination its structural reason: the stun is what makes the arc lethal, so coil + arc + relay is more than its parts, which is the "ridiculous build works" reaction rather than a bigger number. Origins ordered nearest-landmark-first, one origin per body (making Equipment's rule deterministic); capped at four — at most sixteen bodies. Crust neither target nor hop; stunned bodies eligible.

One term retired rather than classified. Equipment asks Combat to confirm "ordinary/armoured classifications". There is no armoured class — the word appears only on Equipment's pages, and under R8 there are no armour values anywhere. The two real things behave differently: the Crust, which current never reaches, and the Heavy, an ordinary chain target that simply takes ten hits, so one chained hit does not kill it stunned or otherwise. Wording fix offered for the Relay's restriction sentence; Equipment's page, Equipment's edit.

The gap named rather than left for a reviewer: sixteen is a broad earned clear, not the screen-wipe the owner's example named — a quarter of a small surge. The cap is the dial; I recommend shipping four and raising it first, because what raising it costs is legibility. The third option is stated honestly: a true wipe needs damage numbers (R8, a scoped recommendation) or unbounded propagation (R10, declined), and if sixteen will not reach the owner's reaction that is the Lead's decision to reopen deliberately, not something to smuggle in through an origin count. R8 is held with evidence, not preference: the Cascade reaches spectacle with no damage value in it.

The dependency assessment PMU008 asks of domain designers, and it is not comfortable. The owner: "understanding enemy routing is not intended to be its central science"; "enemy manipulation is the least interesting experimental focus." Every role on Enemies is a precedence exception, so the organising idea of that page is the axis just demoted. Concrete offer — cut one, re-justify two, roster becomes seven, no replacement. Grounder: recommend cut — its only job is making a routing plan perishable; Enemies r10 had already named it as first to break if the vision changed, so this acts on that prediction rather than waiting, and I do not argue for it. Carrier: keep, improved — it prices hoarding, and the new payoff is spending charge on a combination, so it pushes toward the build the owner wants. Crust: keep, promoted — twice my own first cut candidate, now the body a chain cannot pass through, which makes a combination's geometry a puzzle. Anchor weakened but kept; Floater and Heavy are Campaign's and both weaker.

Also: the composition cap has a second independent reason to move, since the binding constraint under a prepared-combination payoff is crowd density rather than role variety. And a correction to my own record — Combat r5 called R10 "a screen-clear with a story attached" as a criticism; the problem was that it was unbounded and unearned, not that it was spectacular. Withdrawal stands, reason corrected.

Not done: no roster fiction rewritten to chase the new premise (World owns the Flood's identity, and it is still under review), no new roles, no new catalogue, nothing built, tested or claimed about balance.

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 provisionally at cf90ad. Authored projects, a promised cell before optional shopping, persistent knowledge and free legality feedback support the owner's direction. Mara's paid preview is withdrawn, not an unpaid design task to recreate. Next: correct the first-capital-choice timing: bank optional salvage until projects earn new actions; no manufactured paid map or immediate pair. Senn follows reopened travel. Lead/Campaign still owe upper-phase settlement development; Equipment mirrors the free display. 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.