Description
Spike #8 (tests/spike/005_locking_interop, PR #41) validated SQLite's fcntl-based locking protocol — journal-mode lock ladder, PENDING anti-starvation semantics, the WAL -shm reader-mark protocol, and the POSIX close()-drops-all-locks trap + fd-cache workaround shape — against a live stock sqlite3 CLI process. All 5 experiments pass.
The spike's own exit criteria (and this repo's sandbox) only exercised macOS. The issue explicitly asked for "macOS and Linux both exercised (POSIX lock behavior differs)" — findings.md flags Linux as an open item rather than silently dropping it. CI (.github/workflows/ci.yml) already runs on ubuntu-latest for make test/make lint, but no workflow currently runs any spike target — spikes are exempt/manual by design (tests/spike/** is excluded from the mvl-limit gate and from make test).
Steps to verify
Run make spike-005 (from repo root) or cd tests/spike/005_locking_interop && make run on a Linux box or CI runner with a stock sqlite3 binary on PATH (apt-get install -y sqlite3 on Debian/Ubuntu runners if not preinstalled). All 5 experiments should PASS with output matching the same semantics documented in findings.md.
Suggested approach
- Lightest touch: a one-off
workflow_dispatch GitHub Actions job (ubuntu-latest) that runs make spike-005 — since this is throwaway spike code, not a permanent CI gate, it doesn't need to be wired into the default test/lint jobs.
- Alternative: run manually on any Linux machine and record the output.
Acceptance criteria
Complexity
Estimate: trivial
Reasoning: no new design or code — same experiments, same harness, a different OS to run it on. The only real work is finding/using a Linux runner and reading the output.
Context
Follow-up from #8 / PR #41.
Description
Spike #8 (
tests/spike/005_locking_interop, PR #41) validated SQLite's fcntl-based locking protocol — journal-mode lock ladder, PENDING anti-starvation semantics, the WAL-shmreader-mark protocol, and the POSIX close()-drops-all-locks trap + fd-cache workaround shape — against a live stocksqlite3CLI process. All 5 experiments pass.The spike's own exit criteria (and this repo's sandbox) only exercised macOS. The issue explicitly asked for "macOS and Linux both exercised (POSIX lock behavior differs)" — findings.md flags Linux as an open item rather than silently dropping it. CI (
.github/workflows/ci.yml) already runs onubuntu-latestformake test/make lint, but no workflow currently runs any spike target — spikes are exempt/manual by design (tests/spike/**is excluded from themvl-limitgate and frommake test).Steps to verify
Run
make spike-005(from repo root) orcd tests/spike/005_locking_interop && make runon a Linux box or CI runner with a stocksqlite3binary onPATH(apt-get install -y sqlite3on Debian/Ubuntu runners if not preinstalled). All 5 experiments should PASS with output matching the same semantics documented infindings.md.Suggested approach
workflow_dispatchGitHub Actions job (ubuntu-latest) that runsmake spike-005— since this is throwaway spike code, not a permanent CI gate, it doesn't need to be wired into the defaulttest/lintjobs.Acceptance criteria
make spike-005run on Linux, all 5 experiments PASS (or a real divergence from macOS is documented as a new finding — POSIX lock semantics can differ across kernels)findings.md's "Linux — not exercised" line updated with the result.openspec/plan.md's Concurrency Contract "macOS and Linux both exercised" language can be closed out (or a divergence finding is folded in)Complexity
Estimate: trivial
Reasoning: no new design or code — same experiments, same harness, a different OS to run it on. The only real work is finding/using a Linux runner and reading the output.
Context
Follow-up from #8 / PR #41.