live-verify

# `/gflow:live-verify` — Live-verification enforcement gflow-cli reverse-engineers a blackbox: Google Flow. Offline checks (`ruff`, `pyright`, unit/BDD tests) verify gflow-cli's own code does what it's supposed to; they cannot verify Flow still behaves the way it was captured, because Flow is external and changes without notice (see [#174](https://github.com/ffroliva/gflow-cli/issues/174)). This gate enforces two things, both evidence-based (no claim without a fresh verification artifact — see the `superpowers:verification-before-completion` skill): 1. **Part 1 — Pre-flight**, at the *start* of feature/fix work: confirm the checkout reflects current `develop` before investing effort. 2. **Part 2 — Live-verify**, *before claiming done* (after `/code-review` and `/ponytail:ponytail-review`, before commit/PR): exercise the change against real Flow. Full design rationale: [`docs/superpowers/specs/2026-07-19-live-verify-design.md`](../../docs/superpowers/specs/2026-07-19-live-verify-design.md). --- ## Part 1 — Pre-flight Run before writing any code for a new feature/fix: ```bash git fetch origin git rev-parse --abbrev-ref HEAD git rev-list --count HEAD..origin/develop git log --oneline -5 ``` `git rev-list --count HEAD..origin/develop` is an asymmetric DAG set-difference — it counts commits `develop` has that the current `HEAD` lacks, regardless of `HEAD`'s own private unmerged history. This is what catches a genuinely diverged stale branch, not just a behind-by-fast...