refactor(cognition,#1295): generate_recipe PR-1 — Rust types+prompt+parser+validator slice

[joelteply]

Summary

• First slice of `RecipeGenerateServerCommand.ts` (371 LOC) → Rust per the oxidization mission (TS-side AI logic that violates 'TS is thin glue' directive — umbrella triage #1248 umbrella). Same shape as oxidizer: migrate ProposalRatingAdapter.rateProposalsWithAI to Rust cognition/rate_proposals #1289 (rate_proposals): pure-functions slice first, IPC handler in PR-2, TS shim collapse in PR-3.
• 4 modules + 40 tests pass.
• Ships the carrier-types architecture from the #1295 design comment.

Carrier-types choice

Unlike #1289's prompt (pure data → pure prompt), RecipeGenerateServerCommand's TS prompt depends on runtime registry state: `TemplateRegistry.list()` for the available-templates block + `RecipeLoader.getInstance().getAllRecipes()` for collision-avoidance hints. Carrying this state across the IPC boundary as explicit `RecipeGenerationRequest` fields (rather than as Rust-side global state) keeps the prompt builder + validator pure, testable, and parity-checkable.

What's in this PR (4 modules)

• types.rs — RecipeTemplateInfo, RecipeGenerateHints, RecipeGenerationRequest, RecipeGenerationResponse, RecipeDefinitionShape (5 ts-rs camelCase exports). 5 round-trip tests.
• prompt.rs — `build_recipe_system_prompt` + `build_recipe_user_prompt` mirror TS byte-for-byte (schema block, available-templates list, standard-pipeline pattern, rules, hints rendering). 8 tests covering anchors + 0/N templates + every hint combination.
• parser.rs — `parse_recipe_from_ai_response` extracts the JSON envelope via the same `/\{[\s\S]*\}/` regex as TS, tolerates prose preamble + markdown fences. Typed `ParseError::NoJsonEnvelope` / `MalformedJson` with raw_preview capped at 500 chars (mirrors TS `slice(0, 500)`). 7 edge-case tests.
• validator.rs — Structural validation (required fields, kebab-case uniqueId, pipeline shape, RAG template messageHistory, strategy enum + arrays, role schema, in-request duplicate check). FS collision check + sentinel-template existence stay TS-side (PR-3 shim). 12 tests.

What stays TS-side (PR-3 shim concerns)

• Filesystem collision check (`existing-recipes.some(r => r.uniqueId === recipe.uniqueId)`) — pure FS state
• Sentinel-template existence (`TemplateRegistry.has(tmpl)`) — runtime-registry state
• File save (`fs.writeFileSync(...)`) — JTAG framework concern
• Recipe cache reload — RecipeLoader concern

Why no fallback

Per #1262 (no-CPU-fallback audit), the TS path's silent error-on-malformed-JSON returns `{ success: false, error: '...' }`. Rust returns typed `Err` — PR-2 IPC handler maps it to `validationErrors[]` for the JTAG envelope, preserving diagnostic info.

Next

• PR-2: `cognition/generate-recipe` IPC command in modules/cognition.rs wiring `AIProviderRegistry::generate_text` + the prompt+parser+validator (Anthropic default, 0.4 temperature, 4000 max_tokens — matches TS).
• PR-3: `RecipeGenerateServerCommand.ts` becomes thin shim that gathers templates + existing recipe IDs, calls Rust, FS-collision-checks + saves on success path.

Test plan

• cargo test cognition::generate_recipe — 40/40 pass
• cargo check — clean
• ts-rs auto-emits all 5 types to shared/generated/cognition/
• precommit: TS compile + browser-ping + chat-roundtrip PASSED
• pre-push: TS + ESLint baseline + Rust compile + Rust tests PASSED
• Reviewer: confirm carrier-types shape (templates + existing IDs as request fields) aligns with the architecture for the next batch of registry-dependent oxidizers

🤖 Generated with Claude Code