deleting a bot stops it, and a dead bot wakes up

a bot was deleted tonight and its watcher was still polling a website eleven
minutes later. nothing in the product could find it: a bot's watch is a
detached shell process, killing the harness ends the agent, and the loop it
started is not its child.

so a bot writes <sessionId>.bot.json beside its script — what it watches, the
script, the state file, the pids. that record is the ONLY thing connecting a
process to the bot that owns it, and the brief now says so in those words
rather than as bookkeeping.

the id is in the FILENAME because bots share a directory: deleting knows only
an id, so this is a lookup rather than a scan, and a record whose contents are
damaged still gets found and cleaned up.

DELETE /chat/sessions/:id tears it down after forgetting the tables — children
first then the recorded pid, same ordering as stopCommanderProcesses, so the
loop cannot spawn a replacement between the two. every transcript in the
returned chain, not just the id asked for. unconditional rather than gated on
"was this a bot", because the record only exists in the bots directory and a
branch on cwd is a second place to get it wrong. script and state go too, and
only if they are inside the bots directory — an agent wrote that path.

and the reviver sweeps bots on the same tick. a record with pids and none of
them alive is a stopped watch; there is no armed flag and there should not be,
since the record is written when it arms, so its existence IS the intent. the
three-wake bound is shared, keyed bot-<sessionId>.

the wake prompt forbids reconstructing a watch from memory when the record is
gone: a watch subtly different from the one agreed is worse than none, because
it looks like it is working.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043

src/servers/api/bots/brief.ts

@@ -95,8 +95,31 @@ For a "has it changed" watch, the same shape with the comparison against \`$STAT
 fetch, extract the smallest stable piece, compare, and \`exit 0\` printing the new value when it differs.
 Write the new value to \`$STATE\` **before** exiting, or the next arming fires on the same change again.
 
-4. **When you are handed back**, do what the owner asked, then **re-arm the same script the same way,
-   before you end the turn**. Act, then re-arm, in the one turn. Never build a second loop on top of this.
+4. **Record what you armed, in \`<your-session-id>.bot.json\` in this directory.** This is not optional and
+   it is not bookkeeping — it is the only thing that can stop your watch. Nothing else knows your pid, and
+   a bot that is deleted while its record is missing leaves a process polling a website for ever.
+
+\`\`\`json
+{
+  "sessionId": "6305e570-f26a-4989-a0ae-2135c1076505",
+  "watches": "newweb.fofosfluffybastards.com, every 60s, notify the owner when down",
+  "script": "/abs/path/to/newweb-uptime.sh",
+  "state": "/abs/path/to/newweb-uptime.state",
+  "pids": [1316235],
+  "armedAt": "2026-08-26T07:33:00Z"
+}
+\`\`\`
+
+   **Rewrite it every time you arm**, with the new pid. \`pids\` is an array because a re-arm can briefly
+   overlap; list every process you started that is still meant to be running. Your session id is the file
+   name you were told to use — if you do not know it, look at which transcript you are in.
+
+5. **When you are handed back**, do what the owner asked, then **re-arm the same script the same way,
+   before you end the turn**, and rewrite the record. Act, re-arm, record — in the one turn. Never build a
+   second loop on top of this.
+
+6. **If you are woken and told your watch is gone**, read your own \`.bot.json\`, arm the script it names
+   again, and rewrite it. That file is what survives a reboot; the conversation may be days behind.
 
 Do not go hunting for how any of this works — it is above, and looking costs the owner a minute of tool
 calls before anything is armed.