phase2-backlog-snowball

The second phase: a PRD becomes a test-grounded, reviewed backlog. Phase 2's job is to make failure visible before any feature code exists (design for test, define good vs bad), then to break the work into a backlog that snowballs — small at first, gathering mass and momentum, never planned deeper than current knowledge supports.

Phase 3 (phase3-backlog-ralph) will execute this backlog. The quality of phase 3 is capped by the quality of what phase 2 grounds and plans here.

When to use

• A satisfactory PRD exists (from phase1-prd-grill or given) and the work is not yet broken down. Locate it first (default: PRD.md at repo root; phase 1 records the final path in its last commit message).
• "design the tests / acceptance", "break this into a backlog", "populate / plan the work", "what's good vs bad here", "set up the task list".

Do NOT use before a PRD exists (do phase 1), or to implement tasks (that is phase 3).

Core principle

• Design for test before task breakdown. You cannot plan work honestly until you have defined what "good" and "bad" look like and how the system tells you it is wrong (the grounding negative feedback). Tests/oracles/gates are designed here, not discovered in phase 3.
• Functionality first; hardening is planned, not sprinkled. Ground the ACCEPTANCE SIGNAL deeply (the e2e check that proves it works) but keep feature-task ACs lean: the happy path plus the failure modes that lose data or lie to the user. Exhaustive edge/property/fuzz coverage, doc audits, and polish are planned as an explicit HARDENING-WAVE block at the end of the wave — never woven into feature tasks, and never aimed at surfaces still tentative enough to be rewritten (hardening tentative code is planned waste).
• Label irreversibility. Using the PRD's irreversibility map, tag the tasks whose bugs cannot be walked back — on-disk/wire formats, data-integrity writers, migrations, published APIs, freeze points — with an explicit label (e.g. irreversible). Phase 3 runs its deep review gate on exactly these and ships everything else at feature velocity, so a missing label is a real hole and a gratuitous label is real drag.
• Plan only as deep as knowledge supports. Firm project → full breakdown. Tentative/experimental project → plan wave 1 only; do NOT plan deep ahead; the wave ends with an explicit re-plan task.
• Let the snowball grow and roll. Foundations first; every task delivers standalone value; no task blocks future work; momentum and incremental commits over big-bang planning.
• The backlog is not accepted until subagents have attacked it.
• Shared honesty spine with the rest of the trilogy: no fake completeness, tentative flagged as tentative, phase-1 weak assumptions carried as explicit risks/spikes, never over-plan an experiment.

The phase (in order)

A. Design for test / grounding negative feedback

From the PRD's "what good / what bad looks like" seeds, write a durable testing/grounding doc (e.g. TESTING.md / a Definition-of- Done section). Define concretely:

• The acceptance signal(s) — the strongest end-to-end check that, if green, means it genuinely works (e.g. golden/differential test, byte-identical output, contract test, measurable metric threshold).
• Good vs bad, observable — not adjectives; conditions a test or a human can verify.
• The negative feedback — how the system tells us it is wrong: the gates (build/lint/test/e2e), the oracles, the "prove the check bites" stance. If nothing can fail, nothing is grounded.

This doc is what phase 3's review gate and implementer contract lean on. It is a phase-2 deliverable, not a phase-3 afterthought.

B. Decide planning depth — firm vs tentative

Read the PRD's Tentative-vs-Committed field (firm or experimental — a discrete field phase 1 sets, not prose to infer).

• Firm → break the whole project down.

• Tentative / experimental → plan wave 1 in real detail only. Do not plan deeply ahead. The final task of the wave is an explicit re-plan task, and it must be self-describing so the phase-3 loop-back is mechanical, not folklore. That task is NOT implementation; its description MUST state the handoff in-band, e.g.:

  "Re-plan task — not feature code. Re-invoke phase2-backlog-snowball with: the PRD, the current TESTING / grounding doc, and the lessons/notes wave N produced. Plan wave N+1 to the depth the new knowledge now supports. Write no implementation in this task."

  Its acceptance criteria: (a) wave N+1 tasks exist in the tracker; (b) the new wave again ends with its own re-plan task unless the project is now firm enough for a full breakdown; (c) the TESTING/grounding doc is updated with what wave N taught. State that shallow-ahead planning is deliberate, not laziness: planning ahead of knowledge on an experiment manufactures false certainty.

C. Populate the backlog (tracker CLI only)

Fine-grained, atomic, testable/verifiable tasks. Each task: clear title, the "why" (description), sensible outcome-oriented acceptance criteria that include testing and honest-limitations, dependency edges, foundations before features. Feature-task ACs are LEAN by doctrine: the acceptance signal, the happy path, and the data-loss/lying-to-the-user failure modes — exhaustive edge coverage belongs to the wave-end hardening block, not here. Apply the irreversible label where it is earned (core principle above); phase 3 branches its gate on it. Never reference future tasks. Tracker CLI only — never hand-edit task files. Snowball ordering: earliest tasks are small and unblock the most.

D. Intersperse journeys; consolidate hardening at the wave's end

As first-class backlog items (not afterthoughts):

• a UX/UI / e2e journey task roughly every ~5 implementation tasks — exercise the thing as a user, end to end. Journeys stay interspersed because they catch integration drift cheaply and their findings are feature work, not polish.
• review checkpoints only where they guard something: before an irreversibility event (a format freeze, a publish, a migration) — not on a fixed cadence. A mid-wave review of tentative code audits work that may be rewritten.
• a HARDENING-WAVE block at the end of the wave, after the wave's surfaces have stabilized: deep review passes, edge/property/fuzz enlargement, doc validation, plus every deferred finding phase 3 filed along the way. One consolidated block, deep-gated in phase 3, against code that will not move again.

E. Multi-subagent backlog review (the gate)

Before the backlog is "accepted", spawn all relevant reviewer subagents in parallel, read-only, on the proposed backlog. "All relevant" has a concrete floor and a selection rule, so this doesn't degrade to "just spawn one":

• Always: mped-architect (architecture / consistency / honesty) and qa-test-runner (is the test grounding real, do the ACs actually bite) — same two named agent types the rest of the trilogy uses.
• Then add one reviewer per distinct risk surface the PRD names (e.g. a security reviewer if it touches auth/secrets; a data/schema reviewer if it has a persistence model; a UX reviewer if it has a user-facing surface; a tooling reviewer if it ships a build/CLI). Two reviewers is the floor, not a shortcut — if you cannot name a second risk surface, that itself is a finding.

Ask each: gaps, wrong dependencies, missing test grounding, over-/under-planning, tasks that aren't atomic/testable, what a hostile reviewer would attack. Collect feedback, revise the backlog, record the decisions. The backlog is not done until it survives this gate.

Commit discipline

Commit incrementally throughout — the PRD refinements (if any), the testing/grounding doc, the backlog as it forms, the review-driven revisions, the decisions. Small commits, honest messages. Incremental commits across phases 1 and 2 are mandatory.

Exit condition & handoff

• Mechanically done when: test-grounding doc exists; the backlog is populated to the right depth (full, or wave-1 + a self-describing re-plan task per §B); review/UX/e2e tasks are interspersed; the multi-subagent review gate has been run and its feedback folded in; everything committed.
• These conditions are necessary, not sufficient. Phase 3 is expensive and autonomous, so before handing off, surface to the human an explicit checkpoint: the grounded backlog + what the subagent reviewers attacked + open risks — "proceed to autonomous execution?" Consistent with the trilogy's spine (phase 1 trained the human to own "good enough"; do not silently auto-launch phase 3).
• Handoff to phase3-backlog-ralph: it executes the backlog under its own orchestrator/implementer/review loop. For tentative projects, phase 3 runs wave 1 and reaches the self-describing re-plan task (§B), whose own description re-invokes phase2-backlog-snowball for wave N+1 — the loop-back is carried in the task, not assumed. The snowball's next roll.

Anti-patterns

• Breaking work down before defining good/bad and the negative feedback (planning on ungrounded ground).
• Deep-planning all waves of an experimental project up front.
• A backlog with no test grounding, or "what good looks like" left as an adjective.
• Skipping the multi-subagent backlog review, or treating its findings as optional.
• No interspersed UX/e2e journey tasks and no planned hardening block ("we'll test at the end" with nothing scheduled).
• Over-grounding tentative surfaces: exhaustive property suites, edge matrices, or review checkpoints woven into feature tasks on code the wave may rewrite — the planned-waste mirror of "no testing at all".
• Missing irreversible labels on format/data-integrity/migration tasks (phase 3 will ship them without deep review) — or labeling everything irreversible (phase 3 becomes the slow loop again).
• Tasks that aren't atomic or aren't verifiable.
• Big-bang planning with no incremental commits.
• Forgetting the wave's terminal re-plan task, so phase 3 finishes wave 1 with nowhere to go.