Render the template's prompt when launching an agent via MCP

[selfcontained]

The bug

dispatch_launch_agent accepted a templateId but only ever used it for worktree settings and record-keeping — template.prompt was never read. An MCP caller passing templateId plus a short prompt got an agent whose entire prompt was that short string: every one of the template's own instructions was silently dropped. The web UI's launch path (TemplateService.launchTemplate) has always rendered it, so the two launch surfaces disagreed.

Impact was broad — every MCP caller using templateId, not just one workflow — and invisible, since the launch succeeds and the agent just behaves as if the template said nothing.

The fix

One assembly point.renderTemplatePrompt(template, args, appendix?) in the new apps/server/src/templates/launch-prompt.ts is now the only place a template's prompt becomes an agent's startup prompt — substitute args, then the caller's own text, then the self-improvement footer. TemplateService.launchTemplate sits on it too. Both paths previously encoded that rule independently, which is the same class of divergence this PR exists to fix.

Free text → args. The UI collects one value per {{D:...}} arg from a form; an MCP caller has only free text, so renderTemplatePromptFromFreeText resolves it:

• dispatch_launch_agent takes an optional templateArgs map keyed by arg name.
• A single arg left unset after templateArgs takes the caller's prompt. Anything not consumed follows the rendered template.
• Args nobody supplies render empty rather than failing the launch or leaking literal {{D:...}}; the launch result names them.

Discovery.get_template and list_templates now report a parsed promptArgs list — the same parse the UI's launch form uses to build its fields. Without it a caller would have to recognise placeholder syntax inside the prompt text to know what templateArgs wants.

model, fullAccess, agentType, and cwd still inherit from the launching agent as the tool's docs promise — full UI parity there would change behavior for every existing MCP caller and is out of scope for this bug.

Two ways caller args were silently mishandled

Both found by review, both fixed with tests and confirmed live:

• A templateArgs key matching no arg was dropped — and the arg it was meant for then counted as unset, so the free-text prompt took that slot and nothing warned. {prUrl: "..."} against {{D:PR URL|required}} produced Review review it please. with an empty note. Unmatched keys are now reported, and their presence suppresses the one-arg fill shortcut, since an unmatched key is evidence the caller was aiming a different value at that slot.
• An arg written in two cases half-rendered. Values resolve per-arg but substituteArgs resolves per-occurrence, so a name-keyed value only reached the occurrence whose spelling matched: {{D:Repo}} / {{D:repo}} with {Repo: "dispatch"} rendered Repo: dispatch / again: . Args now collapse into key space before rendering.

Verification

Unit tests cover both renderers and the handler path — lone arg, no args, templateArgs, unset args, unrecognized keys, case-collision, repeated args, Object-member arg names, caller values containing {{D:...}} syntax, appendix-before-footer ordering, and the promptArgs discovery half through both get_template and list_templates.

Exercised live over the real MCP endpoint against an isolated dev stack, reading each launched claude process's argv to confirm what it actually received:

Launch	Prompt the agent got
2 args + templateArgs	Review the diff for security. then the caller's prompt
1 arg, no args passed	caller's prompt substituted into it, plus the self-improvement footer
2 args, none passed	Review for . then the caller's prompt; result named both unset args
misspelled key	Review . then the caller's prompt; result named the unrecognized key and the unfilled arg
arg in two cases	Repo: dispatch / again: dispatch

pnpm run check, pnpm run test, and pnpm run test:e2e all pass.

Reviews

Architecture and backend-security personas both reviewed; nine findings between them, all fixed and verified by the reviewers.

Follow-up (not in this diff)

The "Idea Inbox" template works around this bug by fetching the Build Idea template and substituting the arg itself, then passing both the substituted text andtemplateId. Once this ships, that stopgap would nest the rendered prompt inside the arg. Its instructions need updating after the fix is live on the server — merged is not deployed. Feature-detect: the new server's dispatch_launch_agent has templateArgs and get_template returns promptArgs.