Run watch (be told when a long run you started ends)

An agent that starts a long command detached hands Omniscio the run's process number, and Omniscio itself tells that session, and its crew lead, when the run ends, with the exit code and the log path. It works after the agent's own watcher died, while the session is asleep, and across an app restart.

What it is

A watcher that lives inside Omniscio rather than inside the session. An agent registers a running process once, with POST /run-watches; from then on Omniscio checks every 15 seconds whether that process is still the same run, and when it is not, sends the "your run has ended" notice.

It exists because the usual ways of hearing that a detached run ended all die with the session. A background shell is ended when the session is parked or restarted, and a watcher loop the agent started itself goes with it. A crew member's lead, meanwhile, heard nothing at all.

Where to find it

Agent-facing only: a route on the local control server, documented for agents in the installed Omniscio skill (omniscio-scheduling, the run-watches surface). Nothing in the app's screens shows it; the notice arrives as an ordinary peer message from "Run watch" in the session's chat.

How it behaves

The short version

Step	What happens
Start the run	The agent starts it detached (on Windows through WMI) and has it write its exit code to a file beside its log.
Register	`POST /run-watches` with the process id, a label, the log path and the exit-code file. `201` = watching.
The run ends	Within about 30 seconds the session gets "The run … has ended with exit code N", the time watched, and the log path.
A crew member	Their lead gets the same notice, naming the member.
Too long	At the limit (12 hours unless the agent asked otherwise, at most 2 days) the notice says the run is still running and the watch stops.

What it will not do

It never touches the run. It does not start, stop, pause or kill anything; it only looks.
It never reports a stale exit code. An exit-code file older than the run (say, yesterday's green run) or holding anything but a number is ignored, and the notice says to read the log.
It never mistakes a reused process number for the run. On Windows the number and the process's start time must both match.
It never acts for another session. A watch belongs to the session that registered it; another session cannot list or cancel it, and cannot register one in its name.

When things go wrong

The run already ended before registering → 409, "read its log now".
The session cannot be reached (it was deleted, or the app was down for hours) → its lead is still told; the session's own delivery is retried each sweep for two hours, then recorded as undelivered, visible in GET /run-watches.
The app restarts mid-run → the watch is read back from disk, and a run that ended while the app was down is reported at the first sweep after start.

For agents

How to start a run so it outlives the session (the tested WMI command) and the full register call: run-watches.md.
How the parts fit and where they bite: run-watch-map.md.
What a watch owes: run-watch-contract.md.