fix(delivery): deliver the harness files the dispatch ops apply

[m2ux]

Problem

spawn-agent and continue-agent each Apply two techniques mid-Protocol:

### 1. Resolve harness operation
- Apply resolve-harness-operation with {harness_kind} and operation_kind: spawn
  → {harness_technique}, {harness_operation}

### 2. Dispatch
- Dispatch by applying {harness_technique}'s {harness_operation} Rules section …

Neither reached the orchestrator. CORE_ORCHESTRATOR_TECHNIQUES named harness-compat::spawn-agent and ::continue-agent only, and a technique named inside another technique's Protocol has no delivery path of its own — get_technique resolves only step-bound or first-declared techniques, and no tool loads a technique by id. Resolving the list directly returns spawn-agent's body plus the four group rules, and nothing to apply at the step that dispatches.

An orchestrator arriving there improvises. Observed on a live meta walk: the dispatch step guessed get_resource for harness-compat::claude-code, then for claude-code, took both Resource not found errors, and hand-rolled the spawn from the group contract alone.

Root cause

The #272 host split. Before it, spawn-agent v1.0.0 branched inline:

1. Select the harness-specific invocation by {harness_kind} and dispatch it as foreground:
   - claude-code or cursor — Task(subagent_type=…, description=…, prompt=…)
   - cline — use_subagents { prompt_1: {composed_prompt} }
   - generic — any harness mechanism that starts a new agent … and blocks

harness-compat::spawn-agent was already in the ref list, so the invocation prose arrived inside the op body the orchestrator already received. The split moved that prose into five files and left the ref list naming two. The existing comment on those two entries — "so the orchestrator must receive the harness-specific prose … instead of improvising / inlining" — states the intent the list stopped satisfying.

Change

Five refs added: resolve-harness-operation plus all four harness files.

All four ship rather than the one that applies, because nothing binds {harness_kind} server-side — no session field holds it, no step sets it, and it appears nowhere in src/. The server cannot pick, so the orchestrator selects its own through the map, which stays the single authoritative table. The five files total under 150 lines.

Verification

• npm run check:all — 18/18 guards pass
• Full suite green: 762 passed, 1 skipped file (the single session-crypto EACCES failure is a bubblewrap artifact and passes unsandboxed)
• Delivery probe over the full list: 0 unresolved refs, both Apply hops now present, per-harness rule slices namespaced by source with no collisions

Follow-ups

1. workflow/harness-invoke-surface corrects the stale Task / run_in_background prose these entries now deliver.
2. A chore(corpus) pointer bump after that merges.
3. Optional: bind {harness_kind} from the MCP initialize handshake's clientInfo so only the matching harness file ships. Would let the resolve map do the work it was designed for.

🤖 Generated with Claude Code