These cases describe the implemented protocol. Their numbers remain useful to specs. A node means only the host where the daemon acts on runs, named by hostname.

Crashes and retries

1. The daemon stops. Detached watchers retain their locks. The restarted daemon pulls whole and reads every run again.

2. The watcher stops. A free run lock with durable taken state ends the old processes and posts lost, never launches again. ending retries the held report; done does nothing. Malformed state is taken.

3. Two watchers take one run. Only one takes its lock under the round lock. It decides again before preparing and launching.

4. An arrival is missed. Chat is only a wake. A whole pull finds artifacts by receipt; restart reads all runs again.

5. A run arrives twice. Its hash is unchanged. Its lock, durable state and counted reports prevent a second launch.

6. A stop precedes launch. Address and sender checks and refusal rows 1 and 2 precede the stop. The stop precedes later refusals and ends it stopped.

7. A stop follows launch. The watcher ends the process and its children, then posts stopped. Other sessions in that thread stay.

8. A process exits before a stop is read. The watcher uses the state it can confirm. A later stop changes no counted ended.

9. An artifact lies about its author. The server's receipt proves who sent it; its user card does not.

10. A report adds a key or outcome. Unknown report keys are ignored. An unfamiliar text outcome still ends the run. A stop with any content key is ignored.

Input and delivery

1. A process reads nothing. Input may close unread; its exit, rather than a broken pipe, ends the run.

2. A session reads slowly. A pipe bounds waiting input; OCX does not wait forever to add a whole line to a full pipe.

3. A wake is missed. The next chat answer, even empty, triggers a whole pull. A chat error item causes one new sign-in and retry; another ends the daemon.

Refusals

1. A run has an unknown key. It is refused, naming that key, including a key within one of its parts.

2. The command is absent. started is written, launch fails and it ends exited nonzero, with kept logs explaining why.

3. A sender lacks permission. A matching address grants nothing. Without admin, setup or R, it ends refused.

4. A report is forged. It counts only when received from the run's to, answering it by re. Admin writing as admin cannot answer another user's run.

5. A sandboxed agent starts a manual run. MCP withholds run; start it on the acting clone's host.

Across hosts

1. A run names another clone. Only the full server-code and to both matching cause action. Others pass by without posting a refusal.

2. The server is unreachable. A failed or incomplete pull publishes no completion. Pull or receipt failure ends the daemon, saying why, and nothing starts it again on its own: on a host with no OCX web page, as the client is, a person starts it (confine daemon, inside the host's namespaces), and its watchers run on meanwhile, given nothing. The maintainer chose this over an automatic restart, which could loop (2026-11-02). OCX's web page, on a host whose settings name a daemon_root, starts one when none holds the lock under ROOT/state/, as aarch64-1's settings do; the client's name none. A watcher's failed receipt read waits for another completion.

3. A run is written into the acting clone. Without a server receipt it allows nothing. Pushed as its own to, it is refused. Send runs as their actual senders.

4. The process posts progress. Its own clone syncs as its process's user. A session elsewhere hears that user, not the acting clone's user.

5. The host stops around launch. taken precedes started, and launch waits for confirmation. Recovery never relaunches. A counted ended settles it without local state too.

6. An artifact is not received yet. It is skipped while later received artifacts may be given. If received later, it may then be given in server order. A failed receipt request gives nothing from that read and retries at the next completion.

7. The process names a clone's user. It is refused: a process must never be able to write that clone's reports.

8. Two runs share a process's user. Both may run at once: no per-user lock. Each collects the unchanged approved password. An explicit reset changes it. The separate lock for R alone remains.

9. A clone's user writes audited. It never counts. See verdicts.

Removal once saved

1. A child remains at process exit. OCX ends the process's children before reading or removing the workspace.

2. The server lacks work. Changed files, extra files, a stash or unpushed artifacts keep the workspace. ended.workspace says why. A failed removal never claims removed.

A process that reads nothing

1. The run line exceeds the input pipe. A process exiting before reading it still ends with its own exit code.

2. A terminal fills. Typing stops when the process ends or a stop ends it. A session with deliveries: start waits for the next process.

The watcher’s failures

1. A program takes a log file's place. A directory named stderr.log prevents that file being kept; logs may still be posted.

2. The watcher fails after started. It ends the process, logs the failure, keeps a requested removal unread and posts lost. Failed final posting leaves ending for recovery. Publications already made stay made.

Children outside a sandbox

1. An unconfined process leaves children. OCX ends its Linux session's process groups. A child starting a separate session with setsid can escape; only a sandbox confines it. Recovery checks start times and boot identity before ending old processes.

Other writers

1. A post has no confirmed answer. At a new completion the watcher checks sender, text and reply target, retrying only if absent. It holds only its run lock while waiting; other runs may decide.

A sandbox left running

1. A sandbox does not end with its parent. On stop OCX ends the remaining init after its outer process ends. A killed watcher relies on recovery finding what the old lock names. A sandbox in another session whose outer process already ended can outlive that link. R runs require ends_with_parent.

Daemon and completion failures

1. Chat fails or a pull hangs. A chat poll answering Fossil's error item, which it gives only to a login it no longer signs in, as once an admin saves that user in any repository of its login group, makes the daemon sign in again, once, from its own file, and ask again; only a second such answer, or any other chat failure, ends it, saying what Fossil said. A pull past ten minutes is killed and publishes no completion. Restart pulls before waiting again.

2. The daemon restarts with watchers running. Their locks stay held, those runs stay in care, done runs stay done and waiting runs are reconsidered.

3. A post's answer is lost. The next completion checks sender, text and target before retry. A stop confirmed while started is unknown prevents launch.

4. A node reboots. State and completion files survive; locks do not. The daemon pulls whole first. The old lock's boot identity prevents ending a new process with a reused number.

5. A verdict is requested without i. Refused before launch. Files without y are reported as not shared.

Passwords, addresses and publication

A lost collect answer can be collected again without changing a password. An unapproved login is refused. An older local password is used only when the server explicitly says none is approved. A new clone has a new server-code; old runs must be sent again naming it. Several published clone files require an explicit address. Added fields in server answers are ignored; required fields and receipt targets are still checked.

Completion and republication are built. A publication failure leaves the process's ended unchanged and retains the workspace. A publish retries unfinished publications under the run lock; see the rules.