Context: I've been using stores (beta) as a standalone planning repo, driving changes with coding agents. The store-as-ordinary-git-repo model works well, and I understand the intended concurrency model to be git's own: one actor per checkout, sharing via commit/push/pull. That model has a gap on a single machine: when you want several changes in flight at once with an agent working on each, the natural git answer is one worktree per change (each actor gets its own working tree, index, and branch - the same isolation a teammate's clone provides, locally). Unscoped commands handle this beautifully today: nearest-root resolution means each worktree is self-contained. But everything built on store registration fights it. Four related requests:
-
Worktree-aware store resolution. store register maps an id to exactly one path, so --store <id> - and everything layered on it: the store: pointer in a code repo's config.yaml, and the generated tool/skill instructions that tell agents to append --store - always resolves to that single checkout. From inside a store worktree, an agent following the generated instructions silently reads/writes the registered checkout instead of the one it is standing in. There is currently no way to express "store , but this checkout of it." Possible shapes: --store <id>@<branch>, letting registration know about linked worktrees (git worktree list is cheap), an explicit root-override flag/env var, or simply having --store prefer the enclosing checkout when cwd is inside any worktree of the registered repo. Relatedly, generated instructions could omit --store when the change is being worked inside a store checkout - nearest-root already does the right thing there.
-
Decouple the changes root from the specs root. changes/ and specs/ are welded to one root, and archive applies deltas within it. A layout I keep wanting: change folders live in the code repo (riding the feature branch, merging with the code they describe - the native single-repo flow), while the accumulated spec catalogue lives in a shared store that several repos reference. Today that split is impossible: keeping specs in the store forces changes into the store too. An archive --to <store-id> (or a config key declaring where a root's archived deltas apply) would let the catalogue live where it is shared while work stays where it is reviewed.
-
Harden the archive lock. The archive lock appears to be store-wide and single-shot, with no retry, timeout, or stale-lock detection. Across a team on separate clones it is never contended - but on one machine with multiple checkouts/agents it is exactly where contention lands, and a crashed archive currently leaves a lock nothing cleans up. Per-change locking (the lock is protecting spec-delta application, which is per-change until the final specs write), or at minimum stale detection with an explicit force-style override, would cover it.
-
Document the intended concurrency model. The stores guide is (reasonably) silent on same-machine parallelism. Even a paragraph would help: "one actor per checkout; for parallel changes on one machine, use a worktree per change; unscoped commands resolve per-worktree; --store resolves to the registered path" - plus whatever positions the team takes on 1-3. Right now users discover these semantics by experiment, and the failure mode (writes landing in a different checkout than the one you are standing in) is silent.
Overall theme: stores already have the right bones because they lean on git - these are the places where registration and archive still assume exactly one working tree per machine.
Submitted via OpenSpec CLI
- Version: 1.9.0
- Platform: darwin
- Timestamp: 2026-08-22T17:54:56.409Z
Context: I've been using stores (beta) as a standalone planning repo, driving changes with coding agents. The store-as-ordinary-git-repo model works well, and I understand the intended concurrency model to be git's own: one actor per checkout, sharing via commit/push/pull. That model has a gap on a single machine: when you want several changes in flight at once with an agent working on each, the natural git answer is one worktree per change (each actor gets its own working tree, index, and branch - the same isolation a teammate's clone provides, locally). Unscoped commands handle this beautifully today: nearest-root resolution means each worktree is self-contained. But everything built on store registration fights it. Four related requests:
Worktree-aware store resolution.
store registermaps an id to exactly one path, so--store <id>- and everything layered on it: thestore:pointer in a code repo's config.yaml, and the generated tool/skill instructions that tell agents to append--store- always resolves to that single checkout. From inside a store worktree, an agent following the generated instructions silently reads/writes the registered checkout instead of the one it is standing in. There is currently no way to express "store , but this checkout of it." Possible shapes:--store <id>@<branch>, letting registration know about linked worktrees (git worktree listis cheap), an explicit root-override flag/env var, or simply having--storeprefer the enclosing checkout when cwd is inside any worktree of the registered repo. Relatedly, generated instructions could omit--storewhen the change is being worked inside a store checkout - nearest-root already does the right thing there.Decouple the changes root from the specs root.
changes/andspecs/are welded to one root, andarchiveapplies deltas within it. A layout I keep wanting: change folders live in the code repo (riding the feature branch, merging with the code they describe - the native single-repo flow), while the accumulated spec catalogue lives in a shared store that several repos reference. Today that split is impossible: keeping specs in the store forces changes into the store too. Anarchive --to <store-id>(or a config key declaring where a root's archived deltas apply) would let the catalogue live where it is shared while work stays where it is reviewed.Harden the archive lock. The archive lock appears to be store-wide and single-shot, with no retry, timeout, or stale-lock detection. Across a team on separate clones it is never contended - but on one machine with multiple checkouts/agents it is exactly where contention lands, and a crashed archive currently leaves a lock nothing cleans up. Per-change locking (the lock is protecting spec-delta application, which is per-change until the final specs write), or at minimum stale detection with an explicit force-style override, would cover it.
Document the intended concurrency model. The stores guide is (reasonably) silent on same-machine parallelism. Even a paragraph would help: "one actor per checkout; for parallel changes on one machine, use a worktree per change; unscoped commands resolve per-worktree; --store resolves to the registered path" - plus whatever positions the team takes on 1-3. Right now users discover these semantics by experiment, and the failure mode (writes landing in a different checkout than the one you are standing in) is silent.
Overall theme: stores already have the right bones because they lean on git - these are the places where registration and archive still assume exactly one working tree per machine.
Submitted via OpenSpec CLI