Extend WorkOrder as a contextual pre-Run request for managed execution

[eanz17]

Summary

Extend the existing WorkOrder resource as a contextual, persistent request that coordinates managed execution before a Run exists.

Do not introduce a separate Goal resource. The durable request semantics that would otherwise belong to a Goal are already owned by WorkOrder.

Per #3107:

• Run remains the canonical execution resource.
• Activity remains the canonical surface for observing all Runs.
• WorkOrder must not become a parallel execution workspace or lifecycle model.

This issue follows #2789 and reuses the narrowed implementation delivered by #2941.

Product semantics

WorkOrder owns:

• the durable user request;
• requester and assignment;
• reassignment, cancellation, and dispatch decisions;
• optimistic lifecycle concurrency; and
• the typed WorkOrder-to-Run relationship after dispatch.

A WorkOrder:

• may exist before a Run;
• may remain undispatched without a deadline;
• may be reassigned or cancelled only before dispatch;
• links to the resulting Run after dispatch; and
• does not own Run execution state.

Once a Run exists, the following belong exclusively to Run and Activity:

• execution status and progress;
• approval and Needs you;
• failure diagnosis and retry;
• usage and runtime telemetry; and
• execution timeline and runtime output.

WorkOrder Detail must link to Run Detail instead of copying or independently deriving those states.

UX scope

Add only contextual WorkOrder access:

• expose a scoped WorkOrder list or entry from the context that creates or owns the request;
• allow a scoped direct link to WorkOrder Detail;
• show the WorkOrder request, assignment, lifecycle state, and applicable management actions; and
• show Open Run when the existing typed Run reference is available.

Do not:

• add WorkOrder to the global navigation;
• create a global WorkOrder inbox or attention queue;
• mix WorkOrder rows into Activity;
• duplicate Run status, approval, failure, retry, usage, or Needs you UI; or
• infer relationships from IDs, prefixes, correlation IDs, or run_origin.

Contract and implementation constraints

• Reuse the existing create, receipt, dispatch, and observe path delivered by Narrow WorkOrder to durable intent coordination #2941. This is a guardrail, not a request for another execution-entry facade.
• Reuse the existing typed WorkOrder-to-Run fields: run_id, run_actor_id, command_id, and correlation_id.
• Do not add Run-to-WorkOrder reverse lineage until a concrete Run Detail or query consumer requires it. If added later, it must be a typed work_order_id; it must not be inferred from run_origin, naming rules, or correlation.
• Scope-authorized readers may query the scoped WorkOrder read model.
• Mutations remain protected by requester/Scope authorization and expectedLifecycleVersion.
• The frontend must not reproduce the WorkOrder lifecycle state machine. If contextual action controls are included, expose their availability using typed Actor-owned current-state semantics; command handling remains the final authority.
• Do not add Audit navigation in this issue. Audit currently has no typed work_order_id; adding Audit correlation requires a separate concrete consumer and contract change.
• Continue to use WorkOrderCurrentStateDocument as the query source. Do not add a second store, process-local registry, query-time replay, or projection priming.

Acceptance criteria

• A WorkOrder can be created and queried before any Run exists.
• An undispatched WorkOrder remains a durable, addressable request.
• Authorized users can perform the supported assignment, reassignment, cancellation, and dispatch operations.
• Dispatch continues to produce the existing typed WorkOrder-to-Run linkage.
• The contextual WorkOrder surface links to canonical Run Detail after dispatch.
• Runtime progress, approval, attention, failure, retry, and usage remain owned by Activity/Run Detail.
• No top-level WorkOrder navigation, global attention queue, or Activity row is introduced.
• UI authorization and action availability are not inferred from route shape or duplicated client-side lifecycle rules.
• Accepted receipts do not claim Actor commit, read-model visibility, Run start, or completion.
• Reassign, dispatch, and cancel use expectedLifecycleVersion; stale commands fail closed and the UI refreshes from the read model.
• Tests use distinct identity shapes, including workOrderId = "wo-alpha", memberId = "m-alpha", workflowId = "wf-alpha", publishedServiceId = "svc-alpha", and runId = "run-alpha".
• Relevant contracts, projection behavior, authorization paths, and product semantics are covered by tests and documentation.

Non-goals

• A new Goal, Project, Initiative, or Campaign aggregate.
• A second execution lifecycle parallel to Run.
• A global WorkOrder workspace.
• WorkOrder-owned approval or Needs you.
• A WorkOrder-owned post-Run fulfillment or result-acceptance axis. Add orthogonal WorkOrder fulfillment state and evidence references #3200 proposes one separately and requires its own product decision; the contextual surface in this issue does not render or depend on it.
• Query-time projection priming.
• Run-to-WorkOrder reverse lineage without a concrete consumer.
• Scheduled-fire-to-WorkOrder materialization; that belongs in a caller-specific follow-up issue.
• Forcing every Team, member, service, workflow, channel, tool, or chat invocation through WorkOrder.

Related

• Add a first-class WorkOrder resource for authorized Team execution #2789
• Narrow WorkOrder to durable intent coordination #2941
• [Epic][Console vNext] Align the console with the July 2026 product mock flows #3106
• [Product Decision][Console vNext] Lock the Agent / Workflow / Flow resource and navigation model #3107
• [Backend Epic][Console vNext] Define contracts the frontend must not fabricate #3108
• [Backend][Console vNext] Provide global Activity queries and authoritative attention semantics #3112
• [Console vNext][7] Apply the approved Agent / Workflow / Flow navigation model #3118
• Implement Workflow Activity vNext #3189
• Define typed WorkOrder intent acceptance contracts #3199
• Add orthogonal WorkOrder fulfillment state and evidence references #3200
• Expose actor-owned WorkOrder action eligibility reasons #3201
• Add a typed WorkOrder execution budget policy #3202
• Add typed context for recoverable WorkOrder reassignment #3203
• Add WorkOrder observation watermarks and projection-lag telemetry #3204

[eanz17]

The direction is right — extending WorkOrder instead of adding a Goal aggregate is consistent with the #2789 → #2941 trajectory, and the re-introduction bar for a future spanning resource is well stated. Six points before implementation starts:

1. Sequencing with Console vNext. §1 creates a Studio surface, but it is not linked under frontend epic #3106, and #3107 (navigation/resource model) is still undecided — neither mock variant has a "WorkOrders" nav item. Suggest splitting: read-model/API extension can proceed now; the nav mount point should explicitly depend on the #3107 decision, and this issue should be linked under #3106/#3108 so the two efforts don't run parallel surfaces.

2. Attention split vs #3112. WorkOrder deliberately has no approval state (#2941), so "waiting for approval" attention on a WorkOrder detail can only come from the Run authority via runId using the #3112 contract. Suggest an explicit acceptance criterion: WorkOrder attention never re-projects Run approval/input state; Run-level attention on the detail surface is resolved through the #3112 contract by runId. Without this, the natural implementation shortcut is projecting approval facts back into WorkOrderCurrentStateDocument.

3. Pin down who computes allowed actions. "From typed WorkOrder lifecycle semantics" can be read as (a) frontend maps lifecycle_status → actions, or (b) backend exposes typed eligible actions in query-facing state. (a) duplicates the eligibility state machine into the client and will drift when lifecycle grows. Suggest committing to (b): server-derived typed eligibility, versioned with state_version, with actor-side expectedLifecycleVersion fail-closed as the real gate — same principle as #3112's "explicit reason/code rather than frontend substring classification".

4. Audit navigation has no typed key today. AuditCorrelation carries workflow_run_id/command_id/correlation_id but no work_order_id, so pre-dispatch audit facts (create/reassign/cancel) cannot be aggregated per WorkOrder without inferred correlation — which §4 itself forbids. Either add a typed work_order_id correlation dimension on the audit path, or drop audit navigation from this issue's scope.

5. §2 should be labeled "guardrail only, no new behavior". The create→receipt→dispatch→observe path, honest 202, and dedup idempotency all landed in #2941. As written, the section title ("Reusable managed-execution entry path") invites building a new entry abstraction — exactly what the "generic control-plane framework" non-goal forbids. Also suggest moving the scheduled-fire occurrence example ("may reference or create a deterministic WorkOrder occurrence") to an explicit out-of-scope note: per-fire dedupKey construction and occurrence lifecycle ownership are real design work for a separate issue.

6. Missing acceptance criterion: list/attention authorization. Who can see the Scope collection — requester-only or Scope operators? #3112 requires documented authorization boundaries; this issue should mirror that.

[eanz17]

The rewrite resolves all six points from my previous comment — attention ownership, typed action availability, audit removal, guardrail-only entry path, scheduled-fire deferral, and authorization semantics are all now explicit, and the new reverse-lineage guardrail is a good addition beyond them.

One remaining open item: "the context that creates or owns the request" is currently circular — no existing surface creates WorkOrders yet, so the first implementation PR will have to name one concrete mount point (e.g., a Studio Team/Member detail context or Chat). Suggest stating that this choice belongs to the implementing PR and does not carry semantic authority; the navigation model authority remains #3107 and its forthcoming ADR. Related: once that ADR lands, "Per #3107" should cite the ADR rather than the decision comment.