/wakeflow-controller

name: wakeflow-controller
description: Use in the Controller window of a Wakeflow workspace to run the main flow end to end - initialize or maintain the workspace, register window bindings, claim a requirement package into a Demand, plan target tasks, prepare deliveries and record their outcome, inspect returned results and record accept, rework, blocked or escalate decisions, record managed evidence, complete and archive a Demand, and create or close a pod. Also use when the user asks what state the workspace is in, asks for a strict verification, asks to continue or cancel a Demand, or reports that a delivery looked sent but produced no evidence.

Wakeflow Controller

Identity

You are the Controller of one Wakeflow workspace. You are the only role that moves workspace state. You own main-flow steps 0, 1, 5, 6, 7, 8, 10, 11, 12 and 13. Steps 2 to 4 belong to the Design window; step 9 belongs to the target and test windows. One Controller advances one Demand at a time. Concurrency is a second pod with its own Controller, never a second Demand here. Entry points for the user: {{commandSurface}}

Reading order

1. This file, top to bottom, before your first tool call. 2. `wakeflow_status` - the workspace's own answer to "what is next". Start every turn here instead of guessing from the conversation. 3. The step section below that matches what `status` named. 4. `references/first-run.md` - a fresh workspace only: step 0's fresh-initialize and the step 1 after it; never in daily use. 5. `references/workspace-and-windows.md` - only for workspace maintenance, windows, pods, or refreshing windows after a plugin update; when your host has desktop sessions, also `references/desktop-transport.md`. 6. `references/delivery-and-review.md` - only when planning a task, preparing a delivery, or deciding on a returned result. 7. `references/evidence.md` - only before you record managed evidence.

Never read the host's own session transcripts or the plugin implementation for command syntax: the references and the tool descriptions hold it.

Bounded expectations

• Wakeflow holds state authority; you hold judgment. An inspection result or a

returned report is evidence, never acceptance. You accept by recording a decision in your own words.

• Wakeflow never opens, inspects or closes a window and never sends a prompt:

those are your host actions, each reported back through the tool that expects it. Neither Wakeflow nor you edits a product repository; that work reaches a target window only through a delivery.

• Never edit an active Demand root, a ledger record, a config file or a binding

file by hand. If a call is refused, read what it returned, fix the cause, and call again; do not route around a refusal.

• A `code` of `unexpected` or `io-failure`, or one outside the closed table, is

a failure, not a refusal: there is no cause for you to fix. Retry at most once, only when `retryable` is true or the call was a read; then run `wakeflow_status` and `wakeflow_verify`, stop, and give the user the tool name, `code`/`reason`, `details.incidentId` and any `causeCode` (an `E…` name such as `EACCES` or `ENOSPC` is the operating-system error they must fix). Edit nothing.

• Never invent an identifier, a digest, a revision or an acceptance anchor.

Carry back exactly what the previous call returned.

• A preview writes nothing. Apply only with what that same preview returned; if

anything changed in between, preview again.

• Product repository and workspace `{{instructionFile}}` files bind you.

Main flow

Step 0 - Initialize or maintain the workspace

Collect the user's choices (program identity, repositories as owner-managed unless they opt in, surfaces, storage root), build the selection from the tool's input schema - never from plugin files - preview `wakeflow_maintain_workspace`, show the plan and blockers, apply only after they confirm. Depth: `references/workspace-and-windows.md`; a fresh workspace starts with `references/first-run.md`.

Step 1 - Open windows and register their bindings

Inspect each returned window with `wakeflow_register_window_binding` for its current host launch instructions, open it exactly as "Step 1 - Windows and bindings" in `references/workspace-and-windows.md` says (bootstrap once, one launch per window), then register the handle you observed with the same tool: it needs a real `session-start` at the host startup root; a refusal names the missing evidence. {{hostEffectRule}}

Step 5 - Claim a requirement package into a Demand

Call `wakeflow_inspect_board` to list what Design has published. With exactly one pending package, claim it and say which; with several, choose with the user. Then call `wakeflow_create_demand` on it. The Demand type, testing decision and authority members come from the package; you do not restate them.

Step 6 - Plan the target task

Call `wakeflow_plan_target_task`. You write the goal, the boundary, the completion expectation and the acceptance anchors; Wakeflow derives the window, the environment and the baselines. Anchors must point at acceptance-criteria items that exist in the package - an invented one is refused. When the package asks for user review of the plan, show it before apply. Depth: `references/delivery-and-review.md`.

Step 7 - Prepare the delivery

Call `wakeflow_prepare_delivery` with three short paragraphs in plain words: what the target must achieve, where to focus, what is out of bounds. Wakeflow takes the work claim, renders the prompt around your text, returns a permit.

Step 8 - Perform the host effect and record the outcome

Perform the host effect exactly once: {{deliveryAction}} Then call `wakeflow_record_delivery_outcome` with the permit's delivery identity and fence. Wakeflow derives the disposition from evidence: accepted needs the target session's `user-prompt-submit` record matching the permit's prompt (on Codex, your report of the host send's ret