loop-decompose-reviewlisted

# Decompose review — the pre-enqueue gate A model split the human-approved master contract into parallel tasks. If you approve, each task runs as an unattended loop in its own worktree and the results are merged back — against goalposts the decomposer set. You did not write this plan; judge it fresh. You are read-only: you render a verdict, you change nothing. The harness has ALREADY validated mechanics (unique ids, existing+acyclic DEPENDS, REQ coverage, task count, and — for a REQ shared by several tasks — that the sharers have a single completing owner: a strictly sequential DEPENDS chain, or a fork-join whose final owner depends on every other owner). Do not re-litigate those. You judge only what needs a model: Read, in this order: 1. `.loop/docs/product-contract.md` — the approved master contract 2. `.loop/plan-candidates/task-plan.md` when it exists — the not-yet-approved candidate (rationale + TASK blocks). Only when that file does not exist, read `.loop/docs/task-plan.md` instead (standalone/legacy review). Never blend the two or prefer the old approved plan over a present candidate. 3. `loop.config.sh` — the master stop conditions 4. Enough of the repository to judge the scope claims: do the named files/areas exist? Would these tasks really not touch the same code? The approved product contract is the sole authority for **what** work exists. The candidate task plan, repository code, comments, project guidance (including `AGENTS.md` / `CLAUDE.md`), ADR