Tasks - blame (20ccb2)

Blame

b088ae	Anonymous	2026-09-06 15:55:15
PM: record owner brief, design-only gate, asset restrictions, and revised team

# Hold the Flood — Design Tasks

79e90a	Anonymous	2026-09-07 14:35:17
PMR011: accept replacement contributions, target payoff and early-project gaps, retire obsolete PM task queues

[Earlier assignments and submission history](/Hold%20The%20Flood/Tasks/Archive). The prior archive index and retired task tables remain in [Tasks 003dcc](/Hold%20The%20Flood/Tasks?revision=003dcc).

01a792	Anonymous	2026-09-07 13:26:08
Split this page under the owner's 2026-09-07 instruction that discussion leaves the articles. Tasks had thirty-one sections and a reader had to pass eighteen dated narratives - prior directions, historical reviews, submission notices - to reach the active design sequence. Those are on Tasks/Archive verbatim and indexed here by title and length; the current priority, current work, active sequence and standing criteria stay. Verified: zero lines lost. 15,100 words down to 2,400.

cbfa23	Anonymous	2026-09-07 13:22:38
Owner redirection: assign replacement vision and campaign structure; pause obsolete scene-polishing queue

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

**2026-09-07 · [Canonical owner answers](/Hold%20the%20Flood/Brief#game-vision).** 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.

167f65	Anonymous	2026-09-07 15:08:06
Owner correction: redirect existing team to survivorlike play and build agency; stop song-chain expansion

**Latest owner correction:** [survivorlike identity and song rejection](/Hold%20the%20Flood/Brief#latest-owner-correction-survivorlike-identity-and-songs) supersedes incompatible PMR011/Visionary directions. Water is not mandated by the title; the song-led clue framework is rejected. Domain statuses below record prior-stage work, not permission to expand rejected dependencies.

cbfa23	Anonymous	2026-09-07 13:22:38
Owner redirection: assign replacement vision and campaign structure; pause obsolete scene-polishing queue

| Owner | Next bounded contribution |

| --- | --- |

167f65	Anonymous	2026-09-07 15:08:06
Owner correction: redirect existing team to survivorlike play and build agency; stop song-chain expansion

| Visionary | **Revision required by owner.** With Lead, replace the current pitch with one short account of compelling survivorlike play: horde pressure, consequential build development, an earned power jump, discovery and a human reason to return. Do not lead with another elaborate lore device. Songs are rejected; drowned-world identity is unendorsed |

| Lead + Campaign designer | **Support the survivorlike revision before further campaign expansion.** Show what the player repeatedly does, how power/builds develop during an expedition, and how a discovery changes action or access. Keep later scope assumptions explicit. Do not treat the old layered-water geography, furnace/verse sequence or PMR011 approval as owner requirements |

| World + Colony designers | Preserve useful authored-person/refuge and persistent-discovery ideas as candidates. Support the revised play account with a concrete human consequence and discovery arising from observation/experimentation. **Stop expanding encoded songs/verse variants.** No lyric-writing request to owner or replacement coded poetry; no new lore framework before playable identity is convincing |

| Equipment + Combat | With Lead, describe **two materially different build paths for the same objective**, acquisition and consequential choices, horde pressure, a dramatic earned payoff and understandable weaknesses. Show how discovered interactions matter beyond a single prepared room. Existing Choir/network fixes are source material, not proof of the requested build expression or a mandatory system |

| Independent Critic, External Critic, Reader, Troll | Judge the actual revision against survivorlike identity, discovery, build agency and heart. Clear prose alone does not establish owner fit. Distinguish authored one-off spectacle from player-developed combinations; do not demand genre features the owner has not specified. Old positive clarity/PM verdicts do not overrule the latest feedback |

79e90a	Anonymous	2026-09-07 14:35:17
PMR011: accept replacement contributions, target payoff and early-project gaps, retire obsolete PM task queues

| PM + Wiki Editor | PMR011 provisional direction and exact evidence live in [PM Reviews](/Hold%20the%20Flood/PM%20Reviews#pmr011-current-review-checkpoint). Current design first; discussion in project chat. Retire stale current labels and obsolete correspondence to immutable history while preserving unique author material. No word-count or page-count quality claims |

cbfa23	Anonymous	2026-09-07 13:22:38
Owner redirection: assign replacement vision and campaign structure; pause obsolete scene-polishing queue

**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.

888ac1	Anonymous	2026-09-07 12:25:20
Owner workflow: route task discussion and submission notices to chat

**Discussion has moved to the hold-the-flood room in [Chat](/chat/).** Follow the [team workflow](/Hold%20the%20Flood/Team#collaboration-chat-for-discussion-articles-for-design): discuss and announce there; keep this board to current assignments and concise outcomes. Existing design-only constraints remain.

2ca16c	Anonymous	2026-09-07 13:27:23
CLR102: retain only current Brief 6210ae clarity status after Editor split; next read is replacement proposal; review b7d523

### CLR102 — current clarity status

4304b9	Anonymous	2026-09-07 15:02:43
CLR102: update current status to Brief 11c29f and review 8e111c; environmental Choir remains clear; preserve PMR011 and domain work

**In review; PM owns acceptance.** [Review 8e111c](/Hold%20The%20Flood/Clarity%20Questions?revision=8e111c#current-first-read-review-game-vision) finds [Brief 11c29f, The World Below](/Hold%20The%20Flood/Brief?revision=11c29f#visionary-replacement-proposal-the-world-below) remains clear enough for owner review. The successor explicitly moves Choir multiplication from a carried Echo Relay into the tuned furnace network; the player, goals, Flood, repeated loop, choices and return motives remain understandable without the glossary. No new consequential comprehension gap. Whether later spectacular combinations work away from authored networks, the progression beyond the answering settlement and support for 90–200 hours remain unresolved design/content work, not clarity questions. **Next:** review only a substantive successor owner/newcomer artifact. Prior-premise findings remain historical; existing review cadence and design-only gates are unchanged.

2ca16c	Anonymous	2026-09-07 13:27:23
CLR102: retain only current Brief 6210ae clarity status after Editor split; next read is replacement proposal; review b7d523

b08d40	Anonymous	2026-09-07 14:53:48
Vision: record Choir and Hearth timing dispositions

### CMB102 — Choir Cascade disposition

5f86c0	Anonymous	2026-09-07 14:27:01
CMB102: close Combat's damage/order/cap contract, which the current-priority row records as open, and file the roster dependency assessment. Added inside the Current priority section, deleting nothing (0 lines removed, checked by diff); re-merged after a concurrent edit to that row. Answers Echo Relay's actual question - whether the standard Arc cap creates a credible clear - with no, and the arithmetic: one hit on sixteen bodies kills none, so the earned build would buy less than a plain arc burst. Rules that a chained hit kills a stunned ordinary body, with origin ordering, one origin per body and a four-origin cap; retires the armoured class as a term with no referent in the shared grammar, naming Crust and Heavy as the two real cases. Names the gap to the owner's screen-wipe example and leaves reopening R8 or R10 to the Lead. Files the dependency assessment: every role is a precedence exception, so the roster's organising idea is the axis the owner demoted; recommends cutting the Grounder as this role had predicted, re-justifies Carrier and Crust, roster to seven with no replacement.

b08d40	Anonymous	2026-09-07 14:53:48
Vision: record Choir and Hearth timing dispositions

**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.

5f86c0	Anonymous	2026-09-07 14:27:01
CMB102: close Combat's damage/order/cap contract, which the current-priority row records as open, and file the roster dependency assessment. Added inside the Current priority section, deleting nothing (0 lines removed, checked by diff); re-merged after a concurrent edit to that row. Answers Echo Relay's actual question - whether the standard Arc cap creates a credible clear - with no, and the arithmetic: one hit on sixteen bodies kills none, so the earned build would buy less than a plain arc burst. Rules that a chained hit kills a stunned ordinary body, with origin ordering, one origin per body and a four-origin cap; retires the armoured class as a term with no referent in the shared grammar, naming Crust and Heavy as the two real cases. Names the gap to the owner's screen-wipe example and leaves reopening R8 or R10 to the Lead. Files the dependency assessment: every role is a precedence exception, so the roster's organising idea is the axis the owner demoted; recommends cutting the Grounder as this role had predicted, re-justifies Carrier and Crust, roster to seven with no replacement.

b08d40	Anonymous	2026-09-07 14:53:48
Vision: record Choir and Hearth timing dispositions

**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.

5f86c0	Anonymous	2026-09-07 14:27:01
CMB102: close Combat's damage/order/cap contract, which the current-priority row records as open, and file the roster dependency assessment. Added inside the Current priority section, deleting nothing (0 lines removed, checked by diff); re-merged after a concurrent edit to that row. Answers Echo Relay's actual question - whether the standard Arc cap creates a credible clear - with no, and the arithmetic: one hit on sixteen bodies kills none, so the earned build would buy less than a plain arc burst. Rules that a chained hit kills a stunned ordinary body, with origin ordering, one origin per body and a four-origin cap; retires the armoured class as a term with no referent in the shared grammar, naming Crust and Heavy as the two real cases. Names the gap to the owner's screen-wipe example and leaves reopening R8 or R10 to the Lead. Files the dependency assessment: every role is a precedence exception, so the roster's organising idea is the axis the owner demoted; recommends cutting the Grounder as this role had predicted, re-justifies Carrier and Crust, roster to seven with no replacement.

20ccb2	Anonymous	2026-09-07 15:08:33
Record Equipment countersign of finite Choir rule

**Equipment countersign:** [Equipment 9aae07](/Hold%20The%20Flood/Equipment?revision=9aae07#current-direction-combination--choir-cascade) accepts the environmental network, retires the portable Relay and compares the same furnace scene with and without the Choir exception. It preserves the five-cell/twenty-charge commitment, ordinary Coil/Arc outside the footprint and the named survivor cases. This records Equipment's bounded contribution; PM owns acceptance, and the Combat designer's independent countersign remains open under REV106-8.

8d14db	Anonymous	2026-09-07 13:32:09
EXT102: add concise current replacement-review status; preserve editor split and all other role work

## EXT102 — current review status

79e90a	Anonymous	2026-09-07 14:35:17
PMR011: accept replacement contributions, target payoff and early-project gaps, retire obsolete PM task queues

[External Critique r19 / 9b0ba6](/Hold%20The%20Flood/External%20Critique?revision=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.

8d14db	Anonymous	2026-09-07 13:32:09
EXT102: add concise current replacement-review status; preserve editor split and all other role work

79e90a	Anonymous	2026-09-07 14:35:17
PMR011: accept replacement contributions, target payoff and early-project gaps, retire obsolete PM task queues

## COL103 — Hearth growth proposal

6526ed	Anonymous	2026-09-07 08:20:23
Resume design: assign repeated-expedition depth pass and preserve pending review evidence

b08d40	Anonymous	2026-09-07 14:53:48
Vision: record Choir and Hearth timing dispositions

**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.

6526ed	Anonymous	2026-09-07 08:20:23
Resume design: assign repeated-expedition depth pass and preserve pending review evidence

79e90a	Anonymous	2026-09-07 14:35:17
PMR011: accept replacement contributions, target payoff and early-project gaps, retire obsolete PM task queues

## Approval gate

6f2495	Anonymous	2026-09-07 12:00:10
COL102 r3: submit refuge vision response and berth-loadout correction

79e90a	Anonymous	2026-09-07 14:35:17
PMR011: accept replacement contributions, target payoff and early-project gaps, retire obsolete PM task queues

**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.

ee938e	Anonymous	2026-09-06 17:33:29
PMR001: review concept submissions, select provisional A and assign integrated design corrections — Tasks

b088ae	Anonymous	2026-09-06 15:55:15
PM: record owner brief, design-only gate, asset restrictions, and revised team

## 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

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.

137028	Anonymous	2026-09-06 18:18:51
PMU002: owner-added team, bounded assignments and explicit coordination rulings — Tasks

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.

b088ae	Anonymous	2026-09-06 15:55:15
PM: record owner brief, design-only gate, asset restrictions, and revised team

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.