orchestrate: a subagent definition written mid-session resolves to a generic agent and reports the spawn as successful

[rodrigorjsf]

Found during orchestrate run prd352-20260803-015333 (PRD #352, 12 slices, all passed).

Symptom

The orchestrator wrote two probe subagent definitions to .claude/agents/ and immediately spawned them by their declared name. Both spawns returned Spawned successfully. Both agents came up:

• without the definition's body as their system prompt — one probe reported that the only thing in its context was the spawn prompt; and
• without the definition's tools: restriction — one reported it had SendMessage despite tools: Write.

The registry picked the files up only afterwards, at which point the harness announced New agent types are now available and named both.

Why it matters here

This is the same silent-substitution class the plugin already worries about elsewhere: a spawn that reports success while the agent that comes up is not the agent that was asked for. Neither the declared body nor the declared skills: preload took effect, and nothing said so.

An orchestrator that did not happen to ask the probe to self-report its own system prompt would have read its output as a valid result.

Consequence for the run

Both probe results had to be discarded and the probes re-spawned after registration. Had this happened to a slice role rather than a throwaway probe, the orchestrator would have consumed a full implementer or reviewer pass on an agent with the wrong tools and no role instructions — and the envelope-validation chain would not necessarily have caught it, because a generic agent can still emit a well-formed envelope.

Workaround used

Re-spawn after the New agent types are now available notice appeared.

Suggested fix

This is a harness-level behaviour rather than a plugin defect, so the plugin-side mitigation is documentation: the spine should state that

• agent definitions created during a session are not spawnable until the registry refreshes, and
• a spawn by an unregistered type resolves to a default agent rather than erroring.

Upstream, the correct behaviour is to fail the spawn with an unknown-agent-type error instead of silently substituting.

Scope note — what this issue is and is not about

The missing system prompt / body and the silent success are this issue's payload. The missing tool restriction is reported here as one symptom of the same unregistered-type substitution; the separate question of whether an explicit tools: list is reliably enforced for a properly registered plugin subagent is filed on its own (see the no-Bash-sandbox issue from this run) and should not be folded in here.

Relationship to existing issues (read before deduping)

• Adds evidence to orchestrate: the slice-executor's skills: preload is unverified, and a miss leaves it with no procedure and no error #375 (the slice-executor's skills: preload is unverified, and a miss leaves it with no procedure and no error). This run observed a concrete condition under which a declared skills: preload provably does not take effect — an unregistered agent type — with no error surfaced. orchestrate: the slice-executor's skills: preload is unverified, and a miss leaves it with no procedure and no error #375 remains the right home for the preload-verification ask; this issue covers the registry-refresh race that produces the silent generic-agent substitution in the first place.
• Not orchestrate: the watchdog cannot count a slice-executor's nested spawns when the hook fires from a worktree #374 (watchdog cannot count nested spawns from a worktree) — a hook-context problem, not a spawn-resolution one.

Environment

orchestrate 1.6.0 (plugins/orchestrate/.claude-plugin/plugin.json:3 on development) plus the PRD #352 umbrella branch (slice-executor delegation layer). Run prd352-20260803-015333. Claude Code on WSL2.