spec-kitty / spec-kitty/spec-kitty
Bug: research and plan split artifact authority in coord-topology missions
- Dominant language
- Python
- Stars
- 1.6k
- Forks
- 165
- Avg merge
- 14h 22m
- Merged PRs (30d)
- 343
Description
## Summary
On Spec Kitty 3.2.6, a normal coordination-topology software-development mission still splits planning artifact authority across the repository root checkout and coordination worktree.
The runtime correctly reports the coordination worktree as the mission directory, but:
- `spec-kitty research` invoked from the coordination worktree writes empty research scaffolding into the repository root checkout.
- `spec-kitty plan --mission --json` invoked from the repository root checkout fails with `SPEC_FILE_MISSING` because it looks for `spec.md` in the root checkout.
- The same plan command invoked from the coordination worktree can read the mission artifacts, while `spec-kitty next` refuses to run there and requires the repository root checkout.
This leaves the operator as the path-reconciliation layer during discovery and planning.
## Environment
- spec-kitty-cli: 3.2.6
- local source SHA: `1cb51fb32515771215f5fe7bc676ecc1b22da57a`
- OS: Linux
- mission type: `software-dev`
- topology: `coord`
- target branch: `main`
## Reproduction
1. Create a coordination-topology mission targeting protected `main`.
2. Materialize its coordination worktree.
3. Author and commit `kitty-specs//spec.md` in the coordination worktree.
4. From the repository root checkout, run:
```bash
spec-kitty plan --mission --json
```
Observed: `SPEC_FILE_MISSING` for the root-checkout path even though the coordination worktree contains the committed spec.
5. From the coordination worktree, run:
```bash
spec-kitty research --mission --json
```
Observed: new empty research files appear under the repository root checkout instead of the coordination worktree.
6. Query runtime from the coordination worktree:
```bash
spec-kitty next --mission --json
```
Observed: the command refuses the nested worktree and requires the repository root checkout.
## Expected behavior
All discovery/plan commands should resolve reads and writes through the same canonical mission execution context. Operators should be able to run the documented command from its permitted checkout without artifacts appearing in another checkout or committed coordination artifacts being reported missing.
## Actual recovery used
- removed the root-checkout research scaffolding after verifying it was generated by this invocation
- authored and validated research/plan artifacts in the coordination worktree
- ran `spec-kitty next` only from the repository root checkout
- explicitly committed mission artifacts and runtime events on the coordination branch
No mission data was lost, but the recovery requires manual path knowledge and bypasses the canonical command as artifact author.
## Relationship
This appears to be a concrete 3.2.6 planning-phase residual or regression under #1619 and the formerly closed #1716. It is distinct from #2533 because no `--start-branch` or stranded-empty coordination worktree is involved.
Contributor guide
Research direction
Start by reproducing the coordination-topology workflow with `spec-kitty research --mission --json`, `spec-kitty plan --mission --json`, and `spec-kitty next --mission --json` from both checkouts. Trace how these entry points resolve the mission execution context; done means discovery and plan reads and writes consistently use the permitted canonical checkout without missing or misplaced artifacts.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- cli, developer-experience, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100