fr-progresslisted

# fr-progress In v2 there is no dedicated progress subcommand surface. Progress queries decompose into one of three primitives: | Operator says | Command | |---|---| | "audit drift on this plan" | `fr apply <plan-dir>` (default dry-run lists what gh would change) | | "status of this spec" | `fr spec status <spec-path>` | | "status of every spec" | `fr spec status --all` | | "mark step done" | `fr plan edit <plan-dir> --tick P<n>.T<n>.S<n>` | | "mark phase done" | `fr plan edit <plan-dir> --complete-phase N [--note ...]` | **Announce at start:** "I'm using fr-progress for [capability]." ## How it works (no separate state store) `vk` is a single state machine: the plan files (`_meta.yaml` + `NN.yaml`) are the source of truth, and every projection (Issue body / labels / state, spec table row) is computed on demand. There is nothing to "sync" — `fr apply` diffs the projection against observed gh state and emits the mutations needed to bring them in line. `fr spec status` walks the plan folders referenced by the spec table and rolls up step / phase counts. ## Audit drift on a plan ```bash fr apply <plan-dir> # default: dry-run; prints what would change fr apply <plan-dir> --yes # apply the changes fr apply --all # walk every plan in docs/superpowers/plans/ fr apply <plan-dir> --format json # machine-readable ``` If the diff is empty, plan and gh are in sync. If it's non-empty, you have an actionable list of label / state / body changes.