Summary
On a repository with multiple git worktrees, store resolution hard-fails with ambiguous legacy profile stores, blocking every tool call (status, storage_status, active_project, serve) for that repo — even though only one profile shard's store_manifest.json actually claims the main repo root.
Because all git worktrees share the main repo's .git common-dir, the resolver groups every worktree's shard under the same git identity and refuses to pick one, instead of keying each shard to its own manifest project_root (which is unambiguous).
Environment
- tracedecay
0.0.66 (also reproduced on 0.0.52)
- macOS, installed via Homebrew
- Profile-sharded storage layout (
~/.tracedecay/projects/<project_id>/store_manifest.json)
Repro
- Main repo
R at ~/work/repo with its own profile shard whose store_manifest.project_root == ~/work/repo.
- Create several git worktrees of
R (e.g. git worktree add, or agent tooling that spawns worktrees). Each worktree accrues its own profile shard whose store_manifest.project_root == <worktree path>.
- Run any tool from
R, e.g. tracedecay tool tracedecay_storage_status --args '{}'.
Actual
Error: config error: ambiguous legacy profile stores for '~/work/repo':
project_id=proj_aaaa... path='.../projects/proj_aaaa...' graph_health=healthy ...;
project_id=proj_bbbb... path='.../projects/proj_bbbb...' graph_health=healthy ...;
... (one entry per worktree shard) ...
Every tool call errors identically. The graph server is unusable for the repo despite exactly one shard's manifest claiming the repo root.
Expected
- Disambiguate identity by
store_manifest.project_root rather than by shared git common-dir. When exactly one non-blocked shard's manifest matches the resolved cwd, select it instead of erroring.
- Worktree shards should be treated as their own distinct projects (their manifests already point at the worktree paths).
- Failing that, provide an explicit override (env var /
--project-id flag / config) to pin the active shard so the repo can be recovered without deleting live-worktree data.
Workarounds attempted (none unblock, non-destructively)
migrate registry-gc --apply — removes only rows whose root is gone; live worktree roots remain, so no effect.migrate reconstruct (dry-run) — reports N eligible, M blocked ... apply supported: no; blocked stores fail the atomic batch.upgrade 0.0.52 → 0.0.66 — same error persists.- No
--path / --project-id / env override bypasses the guard.
The only ways to unblock delete or move shards that belong to currently active worktrees, which isn't acceptable while those worktrees are in use.
Impact
Repos driven by parallel agent workflows routinely have many live git worktrees. In that setup tracedecay becomes fully blocked for the primary repo and cannot be recovered non-destructively.
Summary
On a repository with multiple git worktrees, store resolution hard-fails with
ambiguous legacy profile stores, blocking every tool call (status,storage_status,active_project,serve) for that repo — even though only one profile shard'sstore_manifest.jsonactually claims the main repo root.Because all git worktrees share the main repo's
.gitcommon-dir, the resolver groups every worktree's shard under the same git identity and refuses to pick one, instead of keying each shard to its own manifestproject_root(which is unambiguous).Environment
0.0.66(also reproduced on0.0.52)~/.tracedecay/projects/<project_id>/store_manifest.json)Repro
Rat~/work/repowith its own profile shard whosestore_manifest.project_root == ~/work/repo.R(e.g.git worktree add, or agent tooling that spawns worktrees). Each worktree accrues its own profile shard whosestore_manifest.project_root == <worktree path>.R, e.g.tracedecay tool tracedecay_storage_status --args '{}'.Actual
Every tool call errors identically. The graph server is unusable for the repo despite exactly one shard's manifest claiming the repo root.
Expected
store_manifest.project_rootrather than by shared git common-dir. When exactly one non-blocked shard's manifest matches the resolved cwd, select it instead of erroring.--project-idflag / config) to pin the active shard so the repo can be recovered without deleting live-worktree data.Workarounds attempted (none unblock, non-destructively)
migrate registry-gc --apply— removes only rows whose root is gone; live worktree roots remain, so no effect.migrate reconstruct(dry-run) — reportsN eligible, M blocked ... apply supported: no; blocked stores fail the atomic batch.upgrade 0.0.52 → 0.0.66— same error persists.--path/--project-id/ env override bypasses the guard.The only ways to unblock delete or move shards that belong to currently active worktrees, which isn't acceptable while those worktrees are in use.
Impact
Repos driven by parallel agent workflows routinely have many live git worktrees. In that setup tracedecay becomes fully blocked for the primary repo and cannot be recovered non-destructively.