ratchet-recommend

Ratchet Recommend — the navigator

Your output is a route, not a report card. The ledger already says what state each item is in; a report just re-states it. Your job is to say what to do next, who should do it, and in what order — so that a human, or a cheaper model, can act on the backlog without re-deriving the senior judgment that produced it. That routing is the thing that lets a small model land a fix as safely as an expensive one: it inherits the decision instead of guessing it.

Invocation

/ratchet-recommend [path]

• path — backlog file. Default ratchet/BACKLOG.md. Read-only.

What it reads / writes

• Reads: the Items (Tags, priority, Spec, Acceptance, Depends:), the Ledger (status per item), the Journal. On a v2 backlog that means the backlog plus every lanes/<lane>.md — ledgers and journals both.
• Writes: only NEXT.md, alongside the backlog file (default ratchet/NEXT.md). It changes no source, no item, no ledger row, no tag. It recommends; the loop executes and humans decide. On a v2 backlog, NEXT.md is written on the integration branch only — never in a lane worktree (lane branches carrying their own copies is a guaranteed merge conflict).

Phase 1 — Snapshot

Count all six ledger states (done / todo / in-progress / needs-human / blocked / skipped) — on a v2 backlog, across every lane file, and report the counts per lane as well as in total. An in-progress row with no run in flight is debris from a crashed session — the loop's preflight resets it to todo automatically, so route it as todo and note the crash. v2 exception: an in-progress row in an open lane (the lane journal's last run marker is run started, not run ended) may be a live session, not debris. Do not route it as todo, do not suggest re-launching it; flag the lane as open and say the item belongs to whoever is running it. Check the baseline: if a [BASELINE] item is not done, nothing else matters until it is — say so first (v2: name its lane, since every other lane is blocked until that lane merges).