v0.9.1 Phase 2: Workflow steps reference Fleet roles (not raw prompts/profiles)

[Hmbown]

Parent: #4175

Problem

Workflow tasks today often embed raw prompts, inline model hints, or duplicate AgentProfile fields. That violates the separation: Workflow owns WHAT ORDER; Fleet owns WHO; AgentProfile owns config.

Scope

Phase 2: workflow lowering resolves fleet roles at execution time.

Workflow step contract

Workflow steps declare a role (and optional task prompt), not a full AgentProfile:

{ role: "scout", prompt: "Investigate #4090 Ctrl+C path. Read-only." }
{ role: "implementer", prompt: "Fix #4090 with minimal diff." }
{ role: "reviewer", prompt: "Review diff for regressions." }

At run time:

workflow.run({ fleet: "v0868-stopship", ... })
  → for each step: fleet.resolve(role) → AgentProfile
  → runtime.spawn(resolved_profile, ...)

Fleet resolution

• Fleet roster maps role names → AgentProfile ids / saved profiles.
• Precedence (unchanged from v0.9.0 remaining: make AgentProfile canonical for Fleet rosters #4111 / v0.9.0 2.19: make AgentProfile the canonical Fleet actor contract #4136): explicit task fields > saved profile > role default > operator inherit.
• Receipts record resolved_role, resolved_profile, resolved_provider, resolved_model, route_source.

CLI entrypoint

codewhale workflow run stopship --issue 4090 --fleet v0868-stopship --runtime tmux

Creates a Lane (#4176 Phase 1) and executes workflow steps through Fleet resolution.

Non-goals

• Changing AgentProfile schema (v0.9.0 remaining: make AgentProfile canonical for Fleet rosters #4111, v0.9.0 2.19: make AgentProfile the canonical Fleet actor contract #4136, v0.9.0 2.20: let Fleet profiles save provider model and thinking #4137 remain the Fleet/Profile lane)
• tmux/session management (Runtime, v0.9.0 Phase 1: Lane CLI + Runtime backends (tmux, worktrees, stream-json logs) #4176)
• Verification gates between roles (Phase 3, v0.9.1 Phase 3: Workflow gates and handoffs between Fleet roles #4179)

Acceptance criteria

• Workflow JS/IR supports role: on task steps; rejects inline provider/model as required fields.
• workflow run requires --fleet <name> (or configured default fleet).
• Fleet resolver is the single path for workflow spawns and direct agent(profile:) launches (v0.9.0 remaining: make AgentProfile canonical for Fleet rosters #4111).
• TaskStarted events include resolved role + profile + route (v0.9.0 remaining: Workflow automatic launch and unified activity UI #4110 checklist).
• Unit tests: unknown role fails clearly; known role resolves to configured profile.
• workflows/v0868_stopship_lane.workflow.js updated to role-based steps (follow-up in v0.9.1: Stopship workflow as fleet-backed lane (dogfood #4090/#4093/#4094) #4178).

Related

• v0.9.1 architecture: Fleet / Workflow / Lane / Runtime product model (canonical tracker) #4175 — Product model tracker
• v0.9.0 Phase 1: Lane CLI + Runtime backends (tmux, worktrees, stream-json logs) #4176 — Phase 1: Lane CLI + Runtime
• v0.9.1 Phase 3: Workflow gates and handoffs between Fleet roles #4179 — Phase 3: Gates + handoffs
• v0.9.1: Stopship workflow as fleet-backed lane (dogfood #4090/#4093/#4094) #4178 — Stopship dogfood lane
• v0.9.0 remaining: make AgentProfile canonical for Fleet rosters #4111, v0.9.0 2.19: make AgentProfile the canonical Fleet actor contract #4136, v0.9.0 2.20: let Fleet profiles save provider model and thinking #4137 — AgentProfile + Fleet roster
• v0.9.0 remaining: Workflow automatic launch and unified activity UI #4110 — Typed workflow events + receipts
• v0.9.0 Workflow: product-readiness tracker #4038 — Workflow product-readiness
• v0.9.2 Workflow: wire the model-facing workflow tool and run driver #2974 — Model-facing workflow tool