Skip to content

fix(init): replace stale "v0.1" conflict error with actionable message#4

Merged
kevinkod merged 1 commit intomainfrom
fix/3-init-here-stale-error
May 1, 2026
Merged

fix(init): replace stale "v0.1" conflict error with actionable message#4
kevinkod merged 1 commit intomainfrom
fix/3-init-here-stale-error

Conversation

@kevinkod
Copy link
Copy Markdown
Contributor

@kevinkod kevinkod commented May 1, 2026

Closes #3.

Summary

  • Replace hardcoded "Specflow v0.1 does not yet support upgrading an existing project." with a version-agnostic, actionable message.
  • New message lists both escape hatches: specflow init --here --force (re-init in place with backups) and specflow upgrade (incremental update when a lock already exists).
  • Exit code 3, stderr routing, and the conflict file list are unchanged.

Before

error: target already contains 1 specflow-managed file(s):
  - .claude/commands/specflow.specify.md

Specflow v0.1 does not yet support upgrading an existing project. Remove these files or run init into a clean directory.

After

error: target already contains 1 specflow-managed file(s):
  - .claude/commands/specflow.specify.md

To proceed:
  • Run specflow init --here --force to re-initialise in place (existing files are backed up to *.specflow.bak).
  • Or run specflow upgrade if this project was previously initialised by Specflow.

Test plan

  • deno task test — 312 / 312 pass.
  • Existing test specflow init refuses to overwrite a pre-existing .claude/ extended with three assertions: stderr now mentions specflow init --here --force, mentions specflow upgrade, and contains no v0.1 substring (regression guard against another stale version sneaking in).
  • Manual smoke run reproducing the exact conflict scenario — output matches the "After" block above with exit code 3.

🤖 Generated with Claude Code

Closes #3.

The init handler hardcoded "Specflow v0.1 does not yet support upgrading
an existing project" — still printed in v0.6.x, and gave the user no way
out other than "remove these files".

The new message is version-agnostic and lists both escape hatches:
specflow init --here --force (re-init in place, backs up existing files)
and specflow upgrade (incremental update if a lock already exists).

Exit code, stderr routing, and the conflict file list are unchanged.
Test asserts the new commands appear and that no version string leaks
back into the message.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@kevinkod kevinkod merged commit 96176c0 into main May 1, 2026
4 checks passed
@kevinkod kevinkod deleted the fix/3-init-here-stale-error branch May 1, 2026 15:24
kevinkod added a commit that referenced this pull request May 1, 2026
Adds the in-repo collaboration scaffolding so it's available to any
Claude Code session (local or remote routine) cloning this repo:

- CLAUDE.md — working contract: Kevin gives orders, Claude does the
  work; never ask Kevin to perform an action. Default to acting when
  authority is implied.
- .claude/agents/architect.md — read-only architectural research
  agent for non-trivial cross-subsystem changes.
- .claude/agents/product-owner.md — owns every backlog mutation on
  GitHub Project #4 (mkrlabs/specflow).
- .claude/skills/backlog/ — the toolbox the PO uses (gh-based
  list/view/add/move/clarify scripts hard-wired to Project #4).

Each agent has a memory dir at .claude/agents/<name>/memory/ with a
seeded MEMORY.md index that fills as decisions, drift flags, and
preferences accumulate.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
kevinkod added a commit that referenced this pull request May 1, 2026
Adds a grooming wrapper that fires `claude -p` headless against this
repo and dispatches the product-owner subagent to clarify any items
sitting in Project #4's Backlog column. Wired up via a launchd job
(StartInterval=1800s, every 30 min) on the maintainer's Mac.

Files:
- .claude/settings.json — pre-approved tool allow-list scoped to
  what grooming needs (gh, backlog skill scripts, jq, read-only git,
  Task for subagent dispatch, WebFetch for the PO to follow links).
  Without this, headless `claude -p` blocks at every tool call
  waiting for interactive approval and the run silently fails.
- scripts/groom-backlog-local.sh — the wrapper. Runs from any
  machine with claude CLI authenticated and gh authed for
  mkrlabs/specflow.

The launchd plist itself lives at
~/Library/LaunchAgents/com.specflow.groom-backlog.plist (not
committed — has user-specific paths). Logs land in
~/Library/Logs/specflow/groom-backlog.log.

First validated run posted French clarification comments on #1
(docs site) and #2 (Antigravity harness) with the marker prefix
"🤖 specflow-groom-backlog clarification:" so future runs skip
already-processed items.

Cloud routines (Claude Code Routines) were tried first but
suffered from invisible-from-outside execution delays and the same
permissions issue. Local launchd is the more deterministic path.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Fix init --here bug

1 participant