| Name | Modified | Size | Downloads / Week |
|---|---|---|---|
| Parent folder | |||
| flow-next v1.0.0 source code.tar.gz | 2026-05-09 | 5.6 MB | |
| flow-next v1.0.0 source code.zip | 2026-05-09 | 6.2 MB | |
| README.md | 2026-05-09 | 8.7 kB | |
| Totals: 3 Items | 11.8 MB | 0 | |
What changed
flowctl epicrenamed toflowctl spec;.flow/epics/JSON sidecars relocated under.flow/specs/(markdown specs already lived there in 0.x);epic-scoutrenamed tospec-scout;/flow-next:epic-reviewrenamed to/flow-next:spec-completion-review. Two years of "epic spec" prose collapsed into one word —spec— across the entire flow-next surface. The plugin now ships epic-free: skills, commands, agents, slash-command markdown, smoke tests, internal docs, root README + plugin README + CLAUDE.md +.flow/usage.md, Ralph init templates, and the Codex mirror all use spec vocabulary as canonical. Worker-prompt heredoc fields renamedEPIC_ID → SPEC_ID; Ralph init template variableEPICS_FILE → SPECS_FILE; cognitive-aid payload keyepic_id → spec_id(both surface in dual-emit during the alias window). Why now? Two reasons: (1) "epic" overloaded "release-train epic" in user vocabulary and produced cross-team friction every time a new contributor read flow-next prose; (2) flow-swarm — the planned multi-agent orchestrator — needs thespeclexicon as its canonical primitive, and shipping the rename in 1.0 closes the last design ambiguity before flow-swarm's first cut.
What still works
- All 0.x scripts and CLAUDE.md examples keep working through 1.x. The
flowctl epic*CLI surface stays as a deprecation alias layer that calls into canonicalcmd_specs_*/cmd_spec_*entry points.--epicargparse flags remain accepted (alongside new--spec); JSON read responses dual-emitspec_idandepic_idso existing pipelines see both keys; on read,.flow/epics/is auto-fallback when.flow/specs/is absent. The legacyEPIC_IDheredoc field is still parsed by the worker prompt; the legacyEPICS_FILEvariable is still recognized by Ralph init. Every alias path emits a one-time stderr deprecation hint pointing at the canonical CLI; suppress withFLOW_NO_DEPRECATION=1(mirrors the existingflowctl memory migrateprecedent). End result: copy-pasted CLAUDE.md examples from 0.x repos run unchanged on 1.0.0; existing.flow/epics/directories require zero immediate action.
Two migration paths
- Interactive (recommended):
/flow-next:setup— host agent walks the user through the migration, shows the dry-run plan, prompts for confirmation, and runsflowctl migrate-rename --yeson consent. - Deterministic (automation):
flowctl migrate-rename --dry-runfirst to preview the plan; thenflowctl migrate-rename --yesto apply. The migration is transactional — atomic backup at.flow/.backup-pre-1.0/, lockfile-guarded against concurrent runs, sentinel.flow/.migration-manifestfor idempotency, crash-recovery decision tree on every invocation. Moves the JSON sidecars.flow/epics/<id>.json→.flow/specs/<id>.json(the markdown specs already lived at.flow/specs/<id>.mdin 0.x — only the sidecars relocate), rewritesepic:→spec:keys inmeta.jsonand per-task JSON state files, removes the now-empty.flow/epics/directory, and stamps the post-migration sentinel.flow/.flow_version. End state: spec JSON + spec markdown colocated under.flow/specs/.
Optional cleanup
- Refresh your CLAUDE.md / AGENTS.md prose. Aliases keep examples working through 1.x (see Alias removal timeline below), but the deprecation banner stops nagging once your prose uses
flowctl speceverywhere. Quicksedsnippet:bash # In-place rewrite (BSD sed — macOS); GNU sed users drop the empty -i argument. sed -i '' \ -e 's|flowctl epic create|flowctl spec create|g' \ -e 's|flowctl epic set-plan|flowctl spec set-plan|g' \ -e 's|flowctl epics|flowctl specs|g' \ -e 's|flowctl epic |flowctl spec |g' \ -e 's|--epic |--spec |g' \ -e 's|\.flow/epics/|.flow/specs/|g' \ CLAUDE.md AGENTS.mdAlways commit your CLAUDE.md / AGENTS.md before running this; review the diff and tweak edge cases (deprecation context, fenced-code examples that intentionally show the legacy form). A futureflowctl migrate-docs --dry-runhelper will automate this with diff-preview semantics — deferred from 1.0.0 to keep the release surface tight.
Alias removal timeline
- Aliases are not deprecated forever. The current contract: aliases keep working through all of 1.x, with stderr deprecation hints (suppressible via
FLOW_NO_DEPRECATION=1). Soft removal target is 2.0.0 — telemetry-driven, NOT calendar-driven. We'll watch the deprecation-hint stderr counts (and direct user feedback) for the duration of 1.x; if real-worldflowctl epicinvocations have effectively zeroed out, 2.0.0 drops the alias layer. If usage stays high, the alias layer stays. R28 explicitly forbids hard-coded sunset dates — a flag day with no escape hatch is a footgun on a tool that runs in production loops.
Rollback
flowctl migrate-rollback --yesrestores the pre-1.0 layout. The migration writes a transactional backup to.flow/.backup-pre-1.0/before touching anything; rollback restores from that backup, deletes.flow/specs/+.flow/.migration-manifest, and re-asserts.flow/epics/. Post-migration writes (new specs / task updates / done summaries authored after migrate-rename) are detected and rollback refuses by default — pass--force-overwrite-post-migration-changesto discard them explicitly. Lockfile-guarded so a peer migrate-rename + migrate-rollback can't race.
Auto-managed .flow/.gitignore
flowctl initandflowctl migrate-renamenow write.flow/.gitignorewith patterns that exclude transient migration + per-run state from version control. Auto-managed block:gitignore # Auto-managed by flowctl — do not edit above this marker. .checkpoint-*.json receipts/ tmp/ .backup-pre-1.0/ .banner-acknowledged .migrating .migration-manifest # End of auto-managed block. User patterns below this line are preserved.Idempotent on subsequent invocations; user-added patterns below the footer are preserved on update. Why this matters: without it, the firstgit add -Aafter runningflowctl migrate-renamewould commit a multi-megabyte.flow/.backup-pre-1.0/directory, the per-developer.flow/.banner-acknowledgedtimestamp, and the stale.flow/.migratinglockfile..flow/.flow_versionis intentionally NOT in the auto-managed block — that's the schema sentinel and should be tracked per repo so multiple devs share the migrated state (semantics likeCargo.lock).
Known issue (anthropics/claude-code#52218)
- Claude Code's plugin auto-update may stale on bundled hook changes. When a flow-next release ships hook-file changes (Ralph guard hooks, PreToolUse matchers), Claude Code's plugin auto-update path occasionally serves the cached pre-update hook bundle even after the manifest version bumps. Symptom:
flowctlCLI reports 1.0.0 but Ralph guard hooks behave like 0.42.0. Workaround: run/plugin update flow-nextmanually once after upgrading; this forces a hot-reload of the bundled hook bundle. Tracking upstream: anthropics/claude-code#52218. Codex (scripts/install-codex.sh flow-next) and Factory Droid plugin paths are unaffected — only the Claude Code marketplace auto-update path exhibits this behavior.
Notes
- Why
specand notepic-spec/feature-spec/plan? Single-word primitives compose better in CLI grammar.flowctl spec createreads cleanly;flowctl epic-spec createreads as if there's an unspokenepicparent. The shorter form also matches GitHub'sgh pr create/gh issue createcadence — the rename brings flow-next in line with the existing CLI lexicon users already have in muscle memory. - Why a major bump? Renaming the canonical CLI surface and the on-disk directory layout is a breaking-change-shaped event even when aliases preserve every behavior. Semver says: don't surprise people. 1.0.0 is also a deliberate signal — flow-next has been production-stable since the 0.30.0 era; the version number was holding the ecosystem back from treating it as a 1.x dependency. Both motivations align.
- Why dual-emit JSON instead of a hard cutover? Dual-emit lets downstream tooling (the future flow-swarm orchestrator, third-party integrators reading flowctl JSON output) migrate at their own cadence inside the 1.x window. JSON consumers reading
epic_idkeep working; consumers readingspec_idsee the new canonical key from day one. The dual-emit overhead is two extra dictionary entries per response — measured cost, not theoretical.