Add a workflow draft service: dry-run build, blueprint builder and provenance #1545

Summary

Part of #1543 (Phase 2). A server-side draft service that turns a small, bounded workflow blueprint into a complete workflow definition and validates it without saving anything. Phases 3, 4 and 7 build on it, and #1347 can use it.

User Value

Before a workflow exists, the user needs to see exactly what it would do. A dry-run build lets the proposal card and the editor preview come from the same code that saves workflows, so what the user approves is what gets created. Because a deterministic server builder produces the definition, model output never becomes a workflow directly.

Proposed Behavior

• Dry-run build. Factor normalization and reference authorization out of save_personal_workflow (functions_personal_workflows.py:814) and save_group_workflow (functions_group_workflows.py:451). The build writes nothing to Cosmos and creates no workflow conversation. The save functions become build plus persist, with unchanged behavior.

• Blueprint schema, closed and bounded (JSON Schema Draft 2020-12):

  • name and description
  • trigger: manual, calendar, interval, or file_sync with source_ids
  • up to 5 tasks, each with a title, instructions, a runner (an agent reference or the model) and inputs
  • alerts, run_as (self or none), and durable: true

  There are no free-form destinations, endpoints, deployments or secrets.

• Deterministic builder that maps a blueprint to a v2 task-based definition:

  • digests alert on every run at info or low severity, so results reach the bell instead of arriving silently
  • File Sync triggers default to wait_mode: complete, continue_mode: changed and use_changed_documents

• Provenance. origin records the source, conversation, orchestration run, proposal, creation time and whether it was edited. It's outside the Run-as fingerprint allowlist.

• Limits. A per-user cap on workflows created by orchestration, and a minimum cadence for them.

Acceptance Criteria

• A valid blueprint builds and validates with zero writes.
• Invalid or forbidden input (unknown fields, free-form destinations, too many tasks, unauthorized references) is rejected with clear, stable error codes.
• Saving through the existing personal and group paths produces byte-for-byte the same result as before, proven by parity tests.
• Functional tests cover dry-run parity, zero writes, builder output, and rejection of invalid or forbidden fields.
• Any new setting is documented (docs/admin/*, docs/_data/features.yml, regenerated inventory). Feature doc, release notes and config.py version updated.

Notes

• Roadmap: §6, Phase 2. Related gotchas in §8: 2 (the model runner loads core plugins only, so email, OpenAPI and MCP need an agent runner), 9 (silent workflows), 11 (cost and caps), 14 (keep blueprints small and deterministic).
• Open decision (§9), with the recommendation: cap orchestration-created workflows at 20 per user with a minimum cadence of hourly, both admin-editable.
• Depends on: Phase 1 (Add calendar schedules (day, time and timezone) to workflows #1544). Phases 3 (Add an AI workflow assistant to the V2 workflow editor #1548), 4 (Let chat orchestration propose workflows with an Approve, Deny and Edit card #1547) and 7 (Hand off big one-time jobs from chat to a durable workflow #1549) depend on this, and Update the SimpleChat action for task-based workflows and reorganize its capability list #1347 can create task-based workflows through it (Phase 8, Workflow orchestration follow-ons: group workflows, SimpleChat action parity and plan replay #1550).