Kairokuplaybook

Workflows

Saved playbooks on the desktop daemon, and the graph builder in the web app — node kinds, validation, and what a run does.

A playbook is a saved, named way to start work: a recipe (Solo or Build and verify), a brief, and parameters. In its simplest form it is linear — one recipe step. A playbook can also carry a graph: nodes joined by edges, walked in dependency order when the playbook runs.

There are two catalogs, and they do not share rows. The desktop daemon keeps one, which the desktop's Workflow catalog edits and the daemon's playbook.* methods run. The web app keeps its own on your Kairoku account, edited by the graph builder. A playbook saved in one does not appear in the other.

Playbooks never mark plan items done and never create remote Jira or Confluence structure. A playbook is a way to start work, not a second engine.

Desktop — Workflow catalog

Settings → Connections → Workflow catalog on the desktop app saves parameterized playbooks without a graph editor.

  • Workflow kinds lists the recipes available as playbook kinds: solo and build-verify.
  • Save playbook takes a Playbook name, a Workflow kind, and any number of Parameter key / value pairs.
  • Saved playbooks lists what the daemon holds.

The desktop form writes linear playbooks only — the panel's note reads Parameters only — no DAG editor in this release. A graph on a daemon playbook is set through playbook.create / playbook.update on the daemon.

Web app — the graph builder

Settings → Developers → Workflows in the web app is the visual builder. It saves to the web app's own catalog on your Kairoku account — scoped to your personal workspace or organization — not to a daemon, so it needs no daemon and no desktop app.

The page has a Catalog list with New workflow, and an editor: Name, Catalog recipe (solo or build-verify) and Brief, then Save, Run and Add recipe node, above the Workflow graph canvas. A new workflow starts with a Solo recipe node joined to a prompt node; Add recipe node appends another recipe node joined to the last one. Each node on the canvas edits its label, and its recipe and brief or its prompt. Node positions are saved with the graph. Delete workflow removes it from the catalog.

Node kinds

KindRequiredOn run
reciperecipe (solo or build-verify) and a non-empty briefQueues a dispatch for that recipe and announces it
prompta non-empty promptRecorded as a step — a wake with that text; it does not answer a human gate
teammatea teammateId naming a TeammateRecorded as a step for that Teammate

Every node may carry a label and params. Edges have an id, a from and a to; an edge condition field is reserved and ignored in this release. The web canvas edits recipe and prompt nodes; a teammate node is accepted on save but has no editor there.

Validation

Both catalogs refuse a graph on save, not on run:

  • at least one node;
  • unique node ids and unique edge ids;
  • every edge endpoint names a node, and no node points at itself;
  • no cycles — the graph must have a complete topological order;
  • each node carries its kind's required fields.

A rejected save returns the reason to the builder; nothing half-written is kept.

Running

Both catalogs walk the nodes in topological order. For a linear playbook that is one recipe step from the top-level recipe and brief, which must not be empty. The result lists the order used and one entry per node.

On the daemon (playbook.run), recipe nodes queue dispatches (playbook:dispatched, one per node), prompt and Teammate nodes are recorded as steps, and the whole run is announced once (playbook:ran). The daemon's dispatch runner then drains each queued dispatch into an ordinary agent session in the run's workspace, with the brief as its first message — a chat session, not a Floor run. A run does not wait for one dispatch to finish before queuing the next node.

In the web app, Run — enabled once the workflow is saved — records a run with its step order and steps, marked queued, and shows the result. In this release nothing executes a web run: no session, dispatch or Floor run starts from it.

Human-gated plan items still stop for a person either way.

Where this is going

Playbook runs are not listed in the web app yet, and neither kind of run appears on the Floor. The Floor is still the place to run a phase or an item — running work from the plan.

  • Automations — a daemon trigger can reference a saved playbook; firing it does not run the graph
  • Teammates — what a teammate node names
  • Glossary — Playbook, Floor Team, Teammate

On this page