flow-next v1.12.0

Added

• Spec readiness signal — a human-owned ready flag, the entry gate for autonomous execution (fn-58 / FLOW-7). A spec now carries a ready boolean (default false) marking it "complete enough to hand to an agent" — orthogonal to status (open|done; a ready spec stays open through planning and work), human-owned or tracker-projected, never agent-inferred. The gate is strictly opt-in: non-adopters see no prompts, warnings, or badge noise anywhere.
  • flowctl spec ready <id> / spec unready <id> — idempotent toggles (no write, no updated_at bump when the flag already matches; "changed" reported in --json). The on-disk flag is lazy: the sidecar carries ready only after a toggle actually changes state (spec create never writes it; absent reads false) — zero working-tree churn for non-adopters. Every JSON read surface (show, specs, list) emits an explicit "ready": <bool>, and ready specs get a [ready] badge in specs/list output (badge only when set — no draft-noise). Task ids rejected; done specs allowed; epic ready/epic unready aliases included. New regression suite tests/test_spec_ready.py (lazy purity, idempotency, badge/JSON surfaces) wired into CI + both smoke scripts.
  • Tracker projection (tracker.readyState) — for tracker-connected repos, the /flow-next:tracker-sync discovery ceremony asks one optional, skippable question: which tracker workflow state means "ready for work"? (Linear: a workflow-state name, matched case-insensitive/trimmed — names, not state.type, since a custom "Ready" state is typically type=unstarted; GitHub: a label, pre-created idempotently — present ⇒ ready, absent ⇒ not ready, a normal state). Every pull-side sync (pull/reconcile) projects the state onto the local ready flag — one-way, tracker → local, tracker authoritative (a local spec ready is overwritten on the next sync). Change-only event-tagged receipts (silent on echo); a stale/renamed configured state warns + noop receipt + flag untouched + the sync continues. readyState lives at the tracker top level (sibling of conflictTiebreak); null = projection off.
  • Adoption-gated prompting layer — the same in-use gate (≥1 ready spec OR tracker.readyState configured) governs every new prompt, so non-adopters see zero new questions. /flow-next:capture and /flow-next:interview offer an optional end-of-authoring "Mark ready?" consent (default keep-draft; gated OFF when readyState is configured — never invite a local edit the next sync would revert; autofix never writes readiness). /flow-next:plan soft-checks readiness before the scout fan-out: not-ready + adopted ⇒ one warn-not-block question (default proceed — planning is non-destructive), with the option set split by mode (local: proceed / mark-ready-then-proceed / abort; tracker-authoritative: proceed / abort / update-tracker-state-then-rerun — local mark-ready never offered). Non-interactive/Ralph auto-proceeds with one stderr line. capture --rewrite resets ready → false (a full re-authoring re-opens the blessing) and announces the reset only when it actually changed the flag; interview refinement never auto-resets.

Notes

• Readiness is the shared entry gate for the forthcoming build-loop specs (fn-59/fn-60) but stands alone as backlog hygiene — knowing which specs are blessed vs still-draft. No new status value; no --ready filter flag in v1 (specs --json + jq covers selection); readiness is pull-only for tracker users (no outbound push). Both flowctl.py copies (canonical scripts/ + dogfood .flow/bin/) updated in lockstep. Codex mirror regenerated (the three net-new ask sites — capture/interview mark-ready, plan soft-check, ceremony readiness question — verified transformed to plain-text numbered prompts). Docs: GLOSSARY "Ready" term, architecture.md (lazy spec-JSON field), flowctl.md (spec ready/unready, tracker.readyState, alias rows), tracker-sync.md (readiness projection), setup usage.md.