Let chat orchestration propose workflows with an Approve, Deny and Edit card #1547

Summary

Part of #1543 (Phase 4). Add a workflow deliverable and a workflow_propose capability so a V2 chat orchestration plan can propose a saved workflow. The proposal renders as a card the user must decide on: Approve (Create & start or Create paused), Deny, or Edit in the V2 workflow editor.

User Value

"Every Monday read my email and tell me what to do this week" gets this week's answer right away, plus a card that sets up the recurring workflow. The user doesn't need to know workflows exist or how to build one, and nothing is created without an explicit click.

Proposed Behavior

• Planner context:

  • a bounded, metadata-only catalog of the user's workflows (the MCP summary shape, following the action-catalog pattern in functions_action_catalog.py:259-298), so the planner can suggest an existing workflow instead of a duplicate
  • a sanitized File Sync source catalog
  • the user's validated browser timezone on RunContext

• Deliverable kind workflow in functions_orchestration_deliverables.py and the V2 plan types, with closed unavailable reasons.

• Capability workflow_propose (Render):

  • gated by enable_chat_orchestration, allow_user_workflows, and a new enable_chat_orchestration_workflows that defaults to False. An empty capability allowlist means "all", so without the new setting an upgrade would turn the capability on silently.
  • requires the WorkflowUser role from RunContext
  • at most one per plan, with a static blueprint input that can't consume upstream outputs
  • its adapter only runs the Phase 2 dry run. It never touches Flask and never writes.

• Routes for accept, status and draft (for Edit), plus deny persistence. Accept mirrors the image-proposal route:

  1. authenticate, then authorize the conversation
  2. load the run and step on the server, and confirm the proposal belongs to that run
  3. confirm the clicker is the requester, and check the role
  4. rebuild and validate
  5. create with a deterministic uuid5(user, proposal_id) ID, so a double click creates one workflow, and write provenance

  Status is a point read of that ID, so there's no new container and no deployer change.

• V2 card that discloses the schedule and timezone, runner and agent, actions and effective Microsoft 365 sources, whether it can send anything, Run as, alerts and runs per month. Calls to action cover Connect Microsoft 365 and Run-as approval.

• Creating from chat always needs this manual decision, even when plan approval is Auto.

Acceptance Criteria

• "Every Monday read my email…" returns this week's preview plus a card, and Approve creates exactly one workflow that runs Monday at the chosen local time and notifies.
• Deny and Edit behave as described, and reloading the chat shows the correct card state.
• Only the requester can act on the card.
• Double submits and retries create one workflow.
• Functional tests (registry and admin option equality, adapter never touches Flask, accept checks), route policy tests for every new route, and Playwright coverage of the card.
• enable_chat_orchestration_workflows documented (docs/admin/*, docs/_data/features.yml, regenerated inventory), guide update, feature doc, release notes and config.py version.

Notes

• Roadmap: §6, Phase 4. Related gotchas in §8: 2, 4 (Microsoft 365 setup), 5 (persistent prompt injection), 6 (Auto plan approval), 7 (thread and identity boundary), 8 (shared conversations), 10 (duplicates), 17 (stale proposals), 18 (test_orchestration_actions_admin.py must match new registry IDs).
• Open decision (§9), with the recommendation: proposals expire after 14 days, and Deny state persists with the run output.
• Depends on: Phase 2 (Add a workflow draft service: dry-run build, blueprint builder and provenance #1545). Phases 5 (Let chat orchestration run existing durable workflows #1551), 6a (Post workflow results back into chat and answer follow-ups from them #1546) and 7 (Hand off big one-time jobs from chat to a durable workflow #1549) depend on this.
• Related: Complete the orchestration harness with Gather, Reason, Render and explicit file creation #1509 (orchestration harness: Gather, Reason, Render), Introduce turn-level orchestration across chat capabilities #1021 (turn-level orchestration), Split Microsoft 365 actions with sharing approvals, live file RAG, and delegated workflow execution #1493 (Microsoft 365 delegated workflow execution).