factory-nextlisted

# factory-next The user's accompanying request is this workflow's argument string. Wherever these instructions refer to `$ARGUMENTS`, interpret it as that request. Pick **one** next step in the factory loop for the current repository — diagnose by default, run only when asked. The mechanical routing lives in `factory next`, which reads the same queue snapshot as `factory queue`. Do not re-derive gates from Linear yourself. ## 1. Resolve repo Default: match the current working directory against `config/repos.yaml`. `$ARGUMENTS` may name a repo (`bj29`) or pass flags (`--apply`, `--orchestrated`, `--include-sweep`, `--harness pi`). ## 2. Diagnose From the factory checkout (or any cwd with `factory` on PATH): ```bash factory state --repo <repo> factory next --repo <repo> $ARGUMENTS ``` Show **session history** from `factory state` (what ran earlier in this harness window), then **constraint**, **recommend**, **because**, and any **also** alternates from `factory next`. Both record events to `~/.factory/state/events.jsonl` — `recommend` on every next run, `start` on `--apply`. If `budgetBlocked` is set, stop — no new agent stages today. ## 3. Apply (only when `$ARGUMENTS` contains `--apply`) **One bounded stage, then stop.** Do not loop until idle — that is the supervisor's job, not `/factory-next`. - If the recommendation is a slash command (`/factory-merge`, `/factory-triage`, `/factory-work`, …), run **that command's skill/body** in this session — one pass, defaul