Mikael Hugo d52c869433 feat(sf-from-source): single-writer project lock via flock on .sf/sf.lock ... Two SF processes writing to the same .sf/sf.db over WAL caused torn pages and "database disk image is malformed" corruption (observed 2026-05-17 in dogfood-5 — the project DB ended up with B-tree pointer-map desync at page 69, requiring a backup restore). The session-lock in src/resources/extensions/sf/session-lock.js exists but is only acquired from auto-start.js when autonomous mode starts. Interactive sf or pre-autonomous-start work did not take it, so a second sf could open the same DB and contend. Promote the lock to the shell wrapper so EVERY sf invocation in a write-capable mode acquires a project-level flock on .sf/sf.lock BEFORE node is launched. Read-only commands (logs, status, dash, sessions, list, --version, --help) skip the lock to keep concurrent read use-cases working. SF_SKIP_LOCK=1 escape hatch for tests that intentionally exercise concurrent paths. On collision the wrapper prints the current lock holder (pid + args + cwd + started timestamp) so the operator can identify the conflicting session, then exits with 75 (EX_TEMPFAIL). The lock is released automatically when the wrapper bash exits — no stale-lock recovery needed since flock is kernel-owned and dies with the fd. The fd opens in read+write mode (`<>`) WITHOUT truncating so the collision branch can still cat the existing holder; truncation happens only after flock succeeds, preventing two racers from clobbering each other's metadata. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>		2026-05-17 01:59:06 +02:00
..
sf-from-source	feat(sf-from-source): single-writer project lock via flock on .sf/sf.lock	2026-05-17 01:59:06 +02:00