The workflow spine

Kiln used to have four peer surfaces for getting work done — the inbox, plans, the squad, and the activity tray — each with its own mental model, linked only by the user's memory. A real piece of work crosses all four: a signal arrives, you decide to do it, an agent works it, a proposal lands, the diff becomes a PR. But nothing held that work's identity as it travelled. Start a plan and the agent you dispatched didn't know the plan existed; its proposal didn't tick a step; the activity tray couldn't say which plan a running agent was serving.

The spine is the thread that fixes this. One narrative now runs through every surface:

Signal → Intent → Work → Change → Ship Inbox → Plan → Agents → Diff → PR

The plan is the unit of intent — the spine — and the other surfaces are phases or lenses of it:

• The Inbox (⌘T) is the funnel: unowned signals (issues, TODOs, CI, loops) entering. Its job is triage — dismiss, hand off to an agent, or promote into a plan. Every row carries one split button: add to plan (the signal becomes a step on the current plan, keeping a #42 / Foo.swift:10 source chip so it remembers where it came from) or make a plan (a fresh plan from the signal) when there's no current plan. That universal verb is what merges the two backlogs — Inbox signals and plan steps stop being retyped into each other.
• The Plan is the committed intent: the local PR-in-waiting, carrying the issue link, branch, base, and a step checklist. It's home base.
• The Agents (the squad) are the labour applied to a plan's steps. A run is "working step X of plan Y."
• The Activity tray is the live "now" lens on that labour — a runtime monitor, not a place work lives.
• The Diff is the output: steps converge into it, and it ships as the PR.

Connecting labour to intent

Each squad run and proposal carries a reference back to the plan and step it's serving, so the work stays tied to its intent. A plan is the single source of truth — a reference to a deleted plan or step simply resolves to nothing rather than dangling.

The status ladder

A plan step used to be a bare done/not-done toggle. Now it reads its place on a ladder, driven by the labour flowing through it rather than hand-toggled:

todo  →  working  →  proposed  →  done

• todo — nobody's on it.
• working — an agent is working on it.
• proposed — the agent came back with a proposal awaiting review.
• done — landed, or approved into the diff.

done stays bridged to the old binary done flag (and the on-disk field), so existing call sites, TODO.md checkboxes, and files written before the ladder existed all still read true. The transitions are monotonic where it matters: reconciling a proposal set only ever walks a step forward toward review — a done step is never reopened.

How the loop closes

1. Dispatch. On a plan step, send an agent marks the step working and dispatches it to the squad. The batch verb — Send off the agents — works all todo steps in sequence. Both verbs leave the plan surface to open the squad, since home base is somewhere you return to, not somewhere you implement from.
2. Carry. The dispatched squad member carries the intent; the proposal it raises inherits it, so the work stays tied to what it came from — no re-typing.
3. Reconcile. When the squad's proposal set changes, plan-backed proposals awaiting review move to proposed.
4. Finish. Applying a proposal moves its step to done — the finish line.

The plan becomes a live dashboard: each step shows its glyph and an in-flight word (working, review), so you read where the work is, not just what you typed.

Drafting a plan with AI

Forming a plan is the blank page a pull request never has — a fresh title and an empty intent box. Two sparkle buttons let an AI help fill it:

• Draft (next to the intent box) writes the "why" — two or three sentences in your voice — from the title, the linked issue, and any diff so far. It reads Redraft once there's intent to replace.
• Suggest steps (next to the steps header) proposes three to six concrete steps, appended as normal, editable rows tagged ai so they read as suggestions to keep or drop, never auto-committed work.

Drafting a plan is deliberate and once-per-plan, so it prefers the cloud (when an API key is present) and falls back to on-device.

The spine made visible

A running agent says what it's serving, not just that it's busy. The Activity tray's task rows show the plan's title and the glyph of the step it's on.

The tray also shows the path ahead, not just the work in flight. The current plan's not-yet-started steps queue into a Next up band beneath the running rows — one row per step, in plan order, so the squad's backlog is visible alongside what it's already doing. A step leaves the band the moment it's dispatched (it becomes the agent working it) and rejoins nothing once done. The rows are queue markers, not selectable tasks: tapping one opens the plan rather than a shell. Next up sits below Active and above Stale.

The versatility guardrail

The spine is structure when you want it, never mandatory overhead. Kiln serves two users:

• The planner: issue → plan → steps → dispatch → ship.
• The cracker-on (the direct workflow mode case): chat to Potter, dispatch a signal, edit, ship the diff — no plan at all.

Ambient agents (Nanny, Pulse, Stewards), issue vetting, and CI fixes are maintenance, not intent — they stay unscoped. Only deliberate work threads through a plan. The value is the option to thread, not the obligation.