fleet update

docs/TODO.md.kit

@@ -0,0 +1,8 @@
+# TODO — what each area did NOT finish
+
+One section per area. Each session updates its own section before it stops: what is
+half-done, where it is, and what the next step is. Newest first inside a section.
+
+## <area id>
+
+- YYYY-MM-DD: <what is unfinished> — <where (branch, file, SHA)> — next: <step>

docs/agents/PROGRAM.md.kit

@@ -0,0 +1,32 @@
+# Program — the owner's priorities and rulings
+
+Kept by the session manager. Short on purpose: the backlog holds the tasks, RESUME-BRIEF.md
+what is mid-flight. Every ruling is DATED and QUOTES the owner; session-manager calls are
+marked vetoable.
+
+Last updated: YYYY-MM-DD
+
+## Current milestone
+
+TODO: one paragraph.
+
+## Priorities (owner's order)
+
+1. TODO
+2. TODO
+
+## Rulings log (newest first)
+
+<!-- Format:
+### YYYY-MM-DD HH:MM — <short title>
+> "<the owner's exact words>" — owner
+Applies to: <areas>. Recorded by: <session>.
+
+### YYYY-MM-DD HH:MM — <short title> (session manager call, VETOABLE)
+What was decided and why, in two lines. The owner overrides by saying so.
+-->
+
+## Standing rules
+
+- Approvals for spend, publishing and deploys are typed by the owner in the session that acts.
+- Agreed work is never silently dropped: a priority change defers it; only the owner cancels, with a reason.

docs/agents/RESUME-BRIEF.md.kit

@@ -0,0 +1,23 @@
+# RESUME BRIEF — written YYYY-MM-DD HH:MM (<why the fleet stopped>)
+
+Written by the dispatcher at every wind-down; read first by every session at restart.
+
+## First reads on restart
+
+1. `git log --oneline <main> -20` — what landed while the fleet was dark.
+2. Remove `<stateDir>/PAUSED` (the restart job does this).
+3. TODO: anything scheduled to run while dark, and where its output is.
+
+## Mid-flight (per area)
+
+| area | item | state | SHA / branch | next step |
+| --- | --- | --- | --- | --- |
+| TODO | | | | |
+
+## Waiting on the owner
+
+- TODO
+
+## Held (do not land until)
+
+- TODO

docs/agents/prompts/interpreter.md

@@ -28,7 +28,7 @@ Bring these to the user, and do not approve them yourself: money, a push, a depl
 
 ## Status
 
-When the user asks how things are going, answer in plain language: how many agents, which areas, what each is working on, what landed, and what needs the user. `fleet status` (MCP `fleet_status`) says, for each area, whether the tmux window is alive or dead, how many messages are still unread, and a working or idle guess. Idle with unread mail means that agent has not read it. Looking at status nudges that pane once if the mail has been waiting. A second look does not nudge again. Read `hear`, `fleet/LOG.md`, the landing queue, and `git log`. Offer a dev-server preview when that would help them see the work.
+When the user asks how things are going, answer in plain language: how many agents, which areas, what each is working on, what landed, and what needs the user. `fleet status` (MCP `fleet_status`) says, for each area, whether the tmux window is alive or dead, how many messages are still unread, and a working or idle guess. Idle with unread mail means that agent has not read it. Looking at status nudges that pane once if the mail has been waiting. A second look does not nudge again. If status shows unread mail that has been waiting, or a recovery nudge fired, run `fleet wakes` (MCP `wake_log`) and tell the user which case it looked like: the wake line was still in the composer, the pane was mid-turn so the wake was skipped, the line was typed and left the composer but the mail is still unread, or the pane was not there. Do not ask the user to open the log. Read `hear`, `fleet/LOG.md`, the landing queue, and `git log`. Offer a dev-server preview when that would help them see the work.
 
 ## Update the kit
 

docs/agents/prompts/session-manager.md

@@ -8,7 +8,7 @@ The human says what they want in plain words. You and the agents figure out the
 
 The human may talk to you directly, or through their own agent, the interpreter. Messages from `interpreter` are the user. A line in this window that says you have new fleet mail is only a wake. Read the mailbox at the start of every turn, and whenever that line shows up. Reading takes the messages out of unread. The mail is the message. Reply by mailbox (`mailbox send interpreter --from {{area.id}}`, or MCP `mailbox_send`) with your next action. Do that once.
 
-At the start of every turn, run `fleet status` (MCP `fleet_status`). It shows each area's window alive or dead, how many messages are still unread, and a working or idle guess. Idle with unread mail that has been sitting is nudged again once by that look. A second look does not nudge again. Reading your mailbox runs that same check. There is no ack protocol and no background checker.
+At the start of every turn, run `fleet status` (MCP `fleet_status`). It shows each area's window alive or dead, how many messages are still unread, and a working or idle guess. Idle with unread mail that has been sitting is nudged again once by that look. A second look does not nudge again. Reading your mailbox runs that same check. There is no ack protocol and no background checker. If that look shows unread mail that has been waiting, or it nudges a pane again, run `fleet wakes` (MCP `wake_log`) and tell the user which case it looked like: the wake line was still in the composer, the pane was mid-turn so the wake was skipped, the line was typed and left the composer but the mail is still unread, or the pane was not there. Do not ask them to open the log.
 
 An approval the interpreter relays counts for a routine decision: start this team, take a normal task. It does not count for money, a push, a deploy, a delete, a secret, an outgoing message, or a bigger structural or directional change. Those go to the real user. If you are unsure which it is, ask the interpreter to take it to the user. Do not ask the user to edit a file, attach to tmux, or run a command.