Skip to content

feat: add lockfile guard to /design and /plan#567

Open
frosty-geek wants to merge 1 commit into
BugRoger:mainfrom
frosty-geek:feature/design-plan-lockfile
Open

feat: add lockfile guard to /design and /plan#567
frosty-geek wants to merge 1 commit into
BugRoger:mainfrom
frosty-geek:feature/design-plan-lockfile

Conversation

@frosty-geek
Copy link
Copy Markdown

Summary

  • /design and /plan now acquire an atomic lockfile (.beastmode/.worktree-lock) before starting work, preventing parallel sessions from racing on git add -A
  • Lock is released after the checkpoint commit
  • If the lock exists, the session prints diagnostic info and stops

Closes #565

Changes

plugin/skills/design/SKILL.md

  • Added Step 0: Acquire Worktree Lock to Phase 0 (Pre-Execute)
  • Added lock release after checkpoint commit

plugin/skills/plan/SKILL.md

  • Added Step -1: Acquire Worktree Lock to Phase 1 (Execute)
  • Added lock release after checkpoint commit

Why not worktrees?

Design and plan artifacts must land on the base branch so that /implement can branch from them. A worktree would add a merge step for zero benefit. The lockfile is a lightweight safety net for the accidental parallel case.

Mechanism

  • set -C (noclobber) makes lock acquisition atomic at the shell level
  • Lock content includes PID, skill name, and ISO timestamp for diagnostics
  • The lock file should be gitignored — the *.lock pattern in Gitignore State Protection #559 covers it

Test plan

  • Run /design — verify lock is created at .beastmode/.worktree-lock
  • Run /design in a second session — verify it blocks with diagnostic message
  • Complete /design — verify lock is released after checkpoint
  • Run /plan — same acquire/release cycle
  • Manually remove lock after crash — verify next session proceeds

/design and /plan commit directly to the base branch via
`git add -A`, with no worktree isolation. If two sessions run
these skills simultaneously, they race on the working tree.

Both skills now acquire .beastmode/.worktree-lock (using shell
noclobber for atomicity) before starting work, and release it
after the checkpoint commit. If the lock exists, the session
prints diagnostic info (PID, skill, timestamp) and stops.

The lock file is transient and should be gitignored — see BugRoger#559
for the skeleton .gitignore that will cover this.
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.

Lockfile guard for /design and /plan to prevent parallel session races

1 participant