bug: agent action implement cannot resolve a workspace for planning-artifact WPs

[robertDouglass]

Summary

Even after repairing Mission 077 lane metadata, spec-kitty agent action implement still cannot start a planning-artifact WP. The command claims it is creating a workspace, but then aborts because no workspace can be resolved for the WP.

This blocks the canonical implement/review loop for planning-artifact work packages such as WP01 in 077-mission-terminology-cleanup.

Concrete failure

Observed in /private/tmp/241/spec-kitty after lane metadata was repaired and status validation passed:

spec-kitty agent action implement WP01 \
  --mission-run 077-mission-terminology-cleanup \
  --agent codex:gpt-5-codex:implementer:orchestrator

Result:

Creating workspace for WP01...
No crashed implementation sessions found.
Error: implement completed but no workspace could be resolved for WP01.

This happened after spec-kitty agent status validate --mission 077-mission-terminology-cleanup was already green.

Why this is a bug

Planning-artifact WPs are valid WPs in the mission model. If the CLI exposes agent action implement WP01, then the workflow layer has to know how to create or resolve the execution context for that WP.

Right now the command surface suggests support, but the underlying workspace resolver only understands lane-backed worktrees.

Likely root cause

From code inspection, there is a split-brain between the generic workspace abstraction and the agent workflow path:

• src/specify_cli/core/worktree.py::create_wp_workspace(...) already has execution-mode handling for planning artifacts and can route them to repo-root execution
• but the implement workflow is still lane-centric:
  • src/specify_cli/lanes/implement_support.py::create_lane_workspace(...) allocates a lane worktree
  • src/specify_cli/workspace_context.py::resolve_workspace_for_wp(...) resolves via lane/worktree context
  • src/specify_cli/cli/commands/agent/workflow.py expects the implement path to yield a workspace path through that lane-backed mechanism

So the system has a planning-artifact execution concept, but the agent action implement path is not consistently using it.

Expected behavior

One of these should happen for planning-artifact WPs:

1. agent action implement uses the same execution-mode-aware workspace abstraction as create_wp_workspace(...) and resolves planning-artifact WPs to repo root, or
2. the command rejects planning-artifact WPs explicitly with a clear message and points the caller to the supported path

The current behavior is the worst of both worlds: it starts the workflow, claims a workspace is being created, and then dies with an internal-resolution error.

Notes

This is separate from the bad lanes.json metadata bug. I hit this only after manually repairing lane metadata, which means even a corrected Mission still cannot use the standard implement loop for planning-artifact WPs.

[robertDouglass]

Validated on a fresh clone of main at dad22b538e2160f2f0a71666491bad60ef60aac3 in /tmp/spec-kitty-20260408-153430.

Additional confirmation and scope tightening:

• The split-brain described in the issue is real on current main.
• The execution-mode-aware workspace abstraction already exists and behaves as advertised:
  • src/specify_cli/core/worktree.py:90-131
  • tests at tests/specify_cli/core/test_worktree.py:54-89
• For a planning_artifact WP, create_wp_workspace(...) returns repo_root directly and does not create a worktree.

I reproduced that directly with a minimal WPMetadata object:

• create_wp_workspace(...) -> /tmp/spec-kitty-20260408-153430/.tmp-issue551

Then I forced the same WP through the lane/worktree resolver path that agent action implement uses:

• resolve_workspace_for_wp(...) -> /tmp/spec-kitty-20260408-153430/.tmp-issue551/.worktrees/077-demo-lane-a
• resolved.exists == False

So the contract mismatch is concrete:

• execution-mode-aware path says: planning artifact runs at repo root
• workflow resolver says: every WP must resolve to a lane-backed .worktrees/<mission>-<lane> path

That resolver is the path used by the action workflow before and after delegated top-level implement:

• src/specify_cli/cli/commands/agent/workflow.py:400-430
• src/specify_cli/workspace_context.py:270-307

This means the problem is larger than one message string. Anything in the action/workflow stack that assumes resolve_workspace_for_wp(...) is universal will mis-handle planning-artifact WPs.

One nuance from reproduction: I did not independently hit the exact original failing CLI transcript in this fresh clone, but I did confirm the underlying invariant violation the transcript depends on. In other words, even if the exact message shifts, the bug remains:

• top-level planning-artifact workspace contract = repo root
• workflow planning-artifact workspace contract = lane worktree

Suggested fix direction:

1. Make resolve_workspace_for_wp(...) execution-mode-aware and able to return repo-root-backed contracts for planning artifacts, or
2. Reject planning-artifact WPs at the action workflow entrypoint with an explicit unsupported-mode error before claiming to create a workspace.

Anything short of that leaves the current contradiction in place.

[robertDouglass]

Closed for GitHub hygiene after PR #803 merged into main.

Evidence: #803 merged at 2026-04-26T12:28:43Z as squash commit 184b172. The PR body and committed issue matrix at kitty-specs/stability-and-hygiene-hardening-2026-04-01KQ4ARB/issue-matrix.md list this issue with a fixed or verified-already-fixed verdict and regression/evidence references.