ralph-looplisted

# ralph-loop A bounded persistence wrapper around `vibe`. Keeps re-invoking the pipeline on `not ready` verdicts, classifying each blocker into retry / re-plan / escalate, until either `verify-gate` returns `ready` or a budget / halt condition is hit. ralph-loop adds **zero new shortcuts**. The same `verify-gate` evidence-based check, the same surgical-diff pass, the same three self-consistency passes per requirement, the same `review-pack` sign-off gate. ralph-loop does not lower the bar; it removes the manual click between iterations. ## When to invoke - The user wants to walk away from a long verify-fix cycle ("don't bother me unless it's actually stuck"). - The feature has a clear spec, a clean plan, and the failure modes are likely mechanical (test diffs, missing edge cases, predicted-output mismatches). - Wall-clock matters more than tokens for this run. - CI-style runs that should attempt full closure before paging a human. Do NOT invoke for: - Trivial changes — wrapping a 5-minute task in a loop is overhead with no benefit. - Genuinely novel design work — most iterations would classify as `escalate`. Use `/vibe` directly. - Runs where the user wants to read each gate failure and decide manually. ralph-loop is the *autonomous* path; that's a different intent. ## Prerequisites - A `vibe` run is set up or about to start. ralph-loop wraps `vibe`; it does not replace its prerequisites. - Spec exists and is approved (or the loop will start with `brainstorm-lean` like