fix(cli): preserve soundwave-authored slug across handoff to decepticon

[Lempkey]

Summary

• Adds queuedEngagementSlugRef to capture the slug emitted by Soundwave's complete_engagement_planning tool via the engagement_ready custom event (useAgent.ts:303)
• Extracts buildSubmitInput() as a pure helper that applies slug precedence: the queued handoff slug wins over DECEPTICON_ENGAGEMENT env var, which may be stale or empty for engagements created during the Soundwave interview
• Clears the queued slug in handleStreamComplete (alongside the existing pendingHandoffRef clear) so it is not re-injected on subsequent Decepticon submits on the same thread
• Leaves pendingHandoffRef boolean semantics untouched; the handoff still fires even when the engagement_ready event carries no slug

Root cause

pendingHandoffRef captured the slug at L303 but the slug string was discarded at L535 (pendingHandoffRef.current = null) before the next Decepticon submit at L687 could use it. The submit fell back to process.env.DECEPTICON_ENGAGEMENT, which is the launcher-set value and is stale when the operator created a new engagement during the interview.

Test plan

• npm run typecheck — TypeScript clean
• npm test — 8 new tests in buildSubmitInput.test.ts pass, 24 total pass
• End-to-end: run a full Soundwave interview (make dev + make cli), complete planning, verify the first Decepticon message includes the correct engagement_name (requires full stack — impractical for CI)

Note on downstream failures

Filesystem tool failures (#152, #173, #175) are downstream symptoms that still require a follow-up PR fixing _normalize_engagement_workspace at decepticon/middleware/filesystem.py:32 — that function currently rejects /workspace as "no engagement workspace" and will continue to do so until repaired. This PR fixes the slug-drop at the handoff point; the middleware fix unblocks the filesystem tools.

Closes #159

[Lempkey]

Thanks for the thorough review. The high-severity finding was correct — `queuedEngagementSlugRef` was being nulled inside `handleStreamComplete()` (during the Soundwave teardown), which ran before the auto-submitted Decepticon `submit()` could consume it. The ref arrived as `null` at `buildSubmitInput`, so it always fell back to the stale env var.

Fix (7247f00):

Two changes in `useAgent.ts`:

1. Removed `queuedEngagementSlugRef.current = null` from `handleStreamComplete`. A comment explains the intent: the ref must survive until the Decepticon run consumes it.

2. In `submit()`, capture the slug into a local before the stream starts, then clear the ref only after `processStream()` resolves successfully:

```typescript
const handoffSlug = queuedEngagementSlugRef.current;
const { input, streamConfig } = buildSubmitInput({ handoffSlug, ... });

try {
const stream = client.runs.stream(...);
await processStream(stream, abortController);
if (handoffSlug) queuedEngagementSlugRef.current = null; // clear after success
} catch (err) {
// slug retained on failure — safe to retry
...
}
```

On the lifecycle test gap: Agreed the existing tests don't cover the `engagement_ready → handleStreamComplete → next submit` sequence. Adding those requires `@testing-library/react` + jsdom (the current vitest config uses `environment: "node"`), which is out of scope for this fix. Happy to follow up in a separate PR if the maintainers want to expand the test infrastructure.

[PurpleCHOIms]

After re-examining the root cause of this regression (#159), I concluded that the architecture itself — letting the LLM be the source of truth for the engagement slug — is the actual problem. Replacing this PR with #182 (refactor/engagement-handoff-signal-only), which takes the opposite approach.

Why the redirect

The natural product flow:

1. Launcher (Go picker UI / web env) decides the engagement slug — the user picks or types it once at session start.
2. Soundwave writes RoE/CONOPS/Deconfliction into the already-mounted /workspace/plan/.
3. Decepticon picks up the same /workspace after handoff.

Under this flow the slug is launcher-owned. The slug Soundwave's LLM emits via complete_engagement_planning(engagement_name=…) is just an echo, and there is no reason to treat it as authoritative. This PR's queuedEngagementSlugRef + queue/clear lifecycle was designed to privilege the LLM-emitted slug, but if the launcher-mounted directory and the LLM-emitted slug ever diverge (hallucination, normalization variance), state and filesystem can mismatch — a worse failure mode than the original drop.

What #182 does instead

• Drops the engagement_name argument from complete_engagement_planning → pure boolean handoff signal.
• The CLI injects launcher's env-set slug into config.configurable on every submit.
• EngagementContextMiddleware.before_agent hydrates configurable into state.
• The "slug drop" bug class no longer exists — there is no slug channel to drop from.
• queuedEngagementSlugRef becomes unnecessary.

What survives

Your regression tests (buildSubmitInput.test.ts) and root-cause analysis were spot on — #159 was diagnosed correctly here, and #182 was designed so that the same issue closes. If you'd like to dispatch follow-up work after this closes, that would be welcome.

Closing this PR.