Three changes today, all small, all driven by friction I hit in the past week. First: granular backlog list edits. assist backlog update could only replace the entire acceptance criteria or task list — which meant fixing a typo in AC #2 of a 6-item list required passing all six in. Added --add-ac, --edit-ac <n>, --remove-ac <n> and matching --add-task / --edit-task / --remove-task / --add-check / --edit-check / --remove-check for phase tasks and manual checks. Indexing is 1-based to match how the items are displayed. The all-replacing update got renamed to update-field so the command surface stays explicit about whether you’re replacing or mutating.

Second: a bug I hit twice while running the new backlog flow. assist backlog run was capturing the plan once via prepareRun and looping over that frozen snapshot, so if Claude appended a phase during the last phase (which is a normal thing to do — discovering work that needs splitting out), the new phase got skipped in favour of jumping straight to the review phase. Fixed by re-resolving the plan from the DB after each executePhase via reloadPlan, so newly-added trailing phases extend the loop instead of being dropped. Pulled runPhases and runReview out into their own files in the process — run.ts is now a thin orchestrator.

Third: a cli-hook tweak. I’d been piping assist complexity through grep/sed to narrow its output, which triggers permission prompts because the compound command isn’t on any allow list. But assist complexity already has maintainability/cyclomatic/halstead sub-commands that produce focused output without any post-processing. The hook now detects piped/chained assist complexity invocations and denies them with a specific reason pointing at the sub-commands, instead of falling through to a generic prompt. The general shape is reusable — SUBCOMMAND_READS is a list, more entries can be added when another command grows the same pattern.