spec-kitty / spec-kitty/spec-kitty

Bug: research and plan split artifact authority in coord-topology missions

Open
#2,683 1 comment 0 reactions 0 assignees View on GitHub
git reliability workflow
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.