session-groomlisted

# Session Groom Keep the backlog ready: research each unprepared work item, verify it, and record the breakdown on it. Open with one sentence saying what you are about to do and what it will produce. ## Non-Negotiables 1. **Idempotent.** Running groom twice over a healthy backlog changes nothing. Only act on items marked `needs_breakdown`, items whose body carries no verified instructions, and items explicitly flagged for re-research. 2. **Verify before recording.** A breakdown goes on the record only after the work is confirmed feasible and grounded in the actual code — files exist, the approach is sound. Don't fabricate paths or tests. 3. **Grooming is not acceptance.** Clearing `needs_breakdown` prepares an item; it does not make it executable. `select` still refuses a `captured` item by name, and a verified breakdown confers no eligibility — acceptance is a separate decision by someone with the authority to make it. Never treat "I researched it and it's fine" as that decision. 4. **Never rewrite the scope region.** Instructions, files and tests go in the body, which is outside the fingerprint, so recording them leaves an existing acceptance intact. If the research shows the accepted scope itself is wrong, that is an escalation (Step 4), not a reword. 5. **Gate the big ones.** If an item turns out to be a significant or architecture-touching change, do not record a breakdown for it — escalate to a cowork `/session-research-design` session and leave a note on the record