fix(activity): spawn's docs named a recipe purpose that resolves to NOTHING (#274)

[joelteply]

activity/spawn told every caller — human, citizen, and schema consumer — that the recipe argument takes benchmark. No such purpose exists.

The authored recipe's purpose is benchmark/hard-rs. RecipeExperienceSource keys on the exact string, and unknown_purpose_yields_none pins that an unknown purpose resolves to None. So anyone following the documented affordance got a room bound to a purpose nothing can project — and per the binding comment in spawn's own run, that room then "will project as a plain chat room."

A benchmark run silently becoming a chat room is the academy failure in miniature. And academy is what we have: 131 cards accumulated in one room, 130,954 work events against 910 messages, 36 cards frozen under claims heartbeating unbroken since 2026-08-07 with two releases ever.

The stale list appeared twice — the command DESCRIPTION (what a citizen reads when choosing a tool) and the recipe param doc (what schema consumers read). Both fixed.

Why not just substitute a corrected list

Recipes are data, overlaid from disk by builtins_with_overlay. Any enumeration in a comment is stale the moment someone authors a recipe — it re-hardcodes precisely what the loader exists to keep dynamic. Both docs now point at the catalogue and state the rule that actually matters: the purpose is exact, family names do not resolve.

Not fixed here, and it's the larger half

Spawn does not validate that the recipe resolves. A typo still mints a chat room silently — a fallback, in a subsystem whose own loader cites [[fallbacks-are-illegal-fail-loud]]. The fix needs the experience source threaded into ActivitySpawn so it can refuse with the live purposes() list, which already exists. Tracked on #274.

Related and also open: the only authored benchmark recipe is one specific gym, so academy/bench/<swe-run> has no template. Per this module's own design that's an authoring act — a new recipe file, zero code — not a mechanism to invent.

Verification

• rustfmt --check clean on the changed file
• cargo check -p continuum-core --lib --features metal,accelerate clean
• Docs only; no behaviour change beyond what callers are told
• No generated TS binding exists for ActivitySpawnParams, so no binding drift

🤖 Generated with Claude Code

https://claude.ai/code/session_01LoTjvf5j3Ez13g6k8mRkFo