Intent: the live test on the server, 2026-10-23 at 00:32 UTC, release 3869da228e7d: a Codex task, run eabbfe740e in thread 682044729e, changed docs/backlog.md as asked and exited 0 in about 20 s; its watcher stored the kept logs, post da84f83b4d, but their index failed, "database is locked", as a writer outside OCX held the repository, and the watcher ended the run lost, ended f58c4d8268, before sharing the patch. The maintainer, 2026-10-22: "Let me know when one click on `accept` is going to give me the functionality I'm seeking", and "the contract on this box is as long as the development doesn't disrupt the server, let the agents go a bit nuts". A post the node stored is written, not failed: every writer of the node's reports goes on in protocol v1 section 10's order, kept logs, shares, verdict, ended; nothing waits for the writer to let go, and no report is written twice; a write that stores nothing still fails. Tried on this host first: under an open BEGIN IMMEDIATE, Fossil 2.27's test-content-put and test-crosslink each fail at once, so no put is stored while such a writer holds the repository, and the spec's writer holds it at each index, never at a put.

Expression: src/ocx/fossil.cr: Fossil::Locked, a command that met a writer outside OCX, raised where "database is locked" was raised before; Fossil::Unfinished, a write that stored its artifact and did not finish, carrying its hash. src/ocx/fossil/forum.cr: put_post indexes each post an earlier write left stored and not indexed, keeping the Unfinished of each such a writer still holds the repository against by its hash, not raising it, so the write goes on; the same post written again and left so still is named again, never put twice; its own index (indexing) or tag (tagged) meeting such a writer raises Unfinished naming it, any other failure as before; index_stored_posts, the node's check's mend, still raises for a post it cannot index, so the check decides nothing without it; stored_posts is the query both read. src/ocx/fossil/tickets.cr: a change whose tag meets such a writer raises Unfinished. src/ocx/fossil/sync.cr: checked_out's close meeting such a writer fails nothing, leaving only Fossil's note of a checkout removed all the same. src/ocx/node.cr: reply takes an Unfinished as written on the server's repository, answering its hash, unless the report is to be seen first, a started, which others must see before its process launches, or the node is on a clone, whose server must hold it; it starts Fossil's backoffice after an ended only once the ended is written whole, as the hook lists each artifact once and would list one left so before it can be read; report says which, and two comments are rewrapped so the file stays at 400 lines. Docs: docs/protocol-v1-failures.md, case 35; docs/protocol-v1-fossil.md, section 5, the write order and its failures; docs/fossil.md, "Forum posts", what was tried; docs/interfaces.md, the post row and the node's backoffice; docs/design/modules.json and its generated docs/design/modules.md; docs/backlog.md, the row "A watcher's kept-log post that meets a writer outside OCX ends the watcher" removed, and a row for what stays open: a report left so that the hook lists before it is indexed reaches no round, so no session whose ends is true is given it, status shows the run unended and a stop before the check is answered lost too, and a write that stores nothing still ends the run lost; HISTORY.md decision 110, after the send_runs decision 109 that landed meanwhile.

Review: Gemma (gemma4:31b) read the change four times (scratchpad gemma-locked-index-1.txt to -4.txt). First: that a started left so would be taken as written and its process launched, which it corrected itself, as reply raises for a report to be seen: a misread, so the rescue now says why it raises; that the watcher would handle a started's Unfinished as a generic crash: wrong, as Unfinished is a Failed and propagates as the Failed did before, which the case 30 example shows, and the check answers the run lost, as the docs say; and that Fossil's backoffice, started after every ended, lists one left so before it can be read, so no round reads it: held, so reply starts none after an ended left so, and what stays open is in docs/backlog.md. Second: that the same post written again, left so still, raises rather than answering its hash: a misread of the intent, as it is named again in the Unfinished, which the node takes as written and create and post report; put_post now finds that post first and says so, and the intent says it. Third: that a writer that holds on makes every later write fail in a loop: wrong, as each write tries each left post's index once, keeps its Unfinished without raising it, and puts its own, with no retry; as a misread, the comment now says the Unfinished is kept, not raised, so the write goes on. Fourth: that reply returning the hash of an unfinished post hides it from its caller: wrong, as that is the intent for every writer of the node's reports, which all write through reply, none of which reads the report back as visible, a started excepted. One finding held.

Demonstrates: spec/ocx/watcher_spec.cr (case 35: a writer outside OCX, an open BEGIN IMMEDIATE through fossil sql, holds the served repository at each index from the kept logs' on; the run shares its file and ends exited 0, its four reports distinct, three stored and none indexed; the node's check under that writer raises Unfinished; with the writer gone the next post indexes each, in order, and the check writes no other report and tags the ended; case 30: a started whose index meets the writer raises Unfinished, launching nothing), spec/ocx/fossil_spec.cr (a post whose tag meets the writer is Unfinished, stored and indexed and untagged; a close meeting the writer fails nothing and hides no failure, another close failure still named), spec/ocx/create_spec.cr (a run written again while the writer still holds its index is named again, and none is put twice), spec/ocx/hook_spec.cr (case 33 now from a put that stores nothing, a Fossil::Locked given whole), spec/support/stand_in_fossil.cr (the writer, held, and the failure's words), spec/ocx/post_spec.cr and spec/ocx/remote_node_spec.cr (a clone's post and a node on a clone fail as before), src/ocx/fossil.cr, src/ocx/fossil/forum.cr, src/ocx/fossil/tickets.cr, src/ocx/fossil/sync.cr and src/ocx/node.cr, spec/guards/size_spec.cr (src/ocx/node.cr at 400 lines), spec/guards/derivation_spec.cr (docs/design/modules.md as docs/design/modules.json generates it), spec/guards/interfaces_spec.cr and spec/guards/documents_spec.cr (the edited documents rendering with their links). Not demonstrated: that no backoffice starts after an ended left so, whose absence only a wait could show. crystal run ci.cr green: 488 examples, 0 failures.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QVpmCsBwVF3d4zhMHHDAxs check-in: d9dd05e7dd user: opus-ocx2 tags: agent-tools

Intent: an adversarial review of the check-ins of decisions 104 to 107 found, each confirmed, two gaps in OCX in the bounds within which a node takes a run from a user holding R alone (two more were in the Codex task's pattern and the session's steps, data outside the tree). First, nothing limited how many such runs ran at once: a run waited only while another run of its own process.user was in the node's care, and its sender picks process.user, so a sender naming a new user for each run could start any number; a node cannot cap memory (row 8 refuses memory) and each sandbox's /tmp is a tmpfs of no set size, so such runs together could exhaust the server's memory. Second, nothing limited the size of a file such a run shares, and each share lands in every clone that fetches it. The maintainer, 2026-10-22: "the contract on this box is as long as the development doesn't disrupt the server, let the agents go a bit nuts", and "don't change the design... make the design work." Runs that exhaust the server's memory, or shares that fill every clone, would disrupt it, so the bounds must hold; no new key or word. Runs an admin or setup sent are unchanged: no such run holds one back, and one holds no such run back.

Expression: src/ocx/decisions.cr: Sender#alone?, a sender holding neither admin nor setup; Situation#r_busy; a LIFE row after the per-user one: a run whose sender is alone waits while r_busy, with the note "a run from a user holding R alone is in this node's care, which takes one such run at a time". src/ocx/care.cr: the node's one lock of such runs, r-alone.lock in its directory (ALONE), read by Node.r_busy? as busy? reads a user's; took? is public, as a watcher tries that lock under the node's lock. src/ocx/node/view.cr: the situation read from the node's directory, which rounds, status, run's dry run and the hand-on read, passes r_busy from that lock. src/ocx/watcher.cr: the watcher opens r-alone.lock beside its user's lock; each time it decides the run under the node's lock, before its workspace steps and again before started, waits_alone? takes that lock, without waiting, for a run that reads whose sender is alone, or finds it held already by the same file, and the decision reads whether another holds it, so the decision and the lock agree under one hold of the node's lock and nothing depends on timing; every take is non-blocking under the node's lock, so none can deadlock. The lock stays held for the run's whole care, its process's life, and is let go with the user's and the run's once it is over; then following hands on, under the node's lock, the first run of its user now to start and, after a run whose sender is alone, the first such run now to start (Watched.next_runs, which was next_run, one run), each read from the node's directory; src/ocx/hook.cr hands each to a watcher of its own. A watcher that finds the lock held writes nothing and hands on as after any run, so a run its brief hold turned away is not left waiting. r-senders.json: limits gain "files": "256M", which Bounds already enforces as a cap, so such a run states files within it, and the kernel ends a process writing a larger file budget. docs/protocol-v1.md, section 10's waiting row, adds such runs; USAGE.md, "Let an agent send runs", gives the file's files cap, a share among the files it bounds, and one such run at a time, keeping the file at 400 lines; HISTORY.md decision 108 records both, amending decision 75 and the file decision 105 shipped, quoting the box contract and naming the review's findings; GLOSSARY.md's Watcher says what it holds and hands on; docs/design/modules.json and its generated docs/design/modules.md say the same of src/ocx/care.cr and src/ocx/watcher.cr. A Codex task's pattern must now state a files limit within 256M, or a node refuses it, naming the limit.

Review: Gemma (gemma4:31b) read the change six times (scratchpad gemma-r-run-one-at-a-time-1.txt to -6). First, that the lock is held for the whole run, which it called a risk, proposing it be let go while the process runs: wrong, as holding it for the run's care is what takes one such run at a time, as the user's lock is held, and the kernel lets go of a killed watcher's lock; that unlocking the run's lock inside watched interferes with its caller: wrong, as that unlock was there before, taking the run out of care before the hand-on; and that the explicit unlocks are redundant since the blocks close the files: wrong, as following runs inside those blocks and must read the locks free; as misreads, watched's comment now says each lock is held for the run's care and let go before following reads the directory. Second, a deadlock from opening r-alone.lock outside the user's lock: wrong, as File.open takes no lock and every take is non-blocking under the node's lock; as a misread, the open now says it takes nothing. Third, fourth and fifth, that the lock taken while deciding is let go once the decision, or prepared, returns, so a second run starts: wrong, as a flock stays held on its open file until unlocked or closed, prepared returns only once the process has ended, and the spec fails with r_busy forced false; as misreads, took? says a lock taken stays held, prepared's comment says it waits for the process to end, and the take is waits_alone?, named for what it does, rather than inside a function building the situation. Sixth, now reading the lock as held through the run, that the second decision re-locks the same file, fragile: wrong, as flock on a file already holding the lock succeeds, which took? says, and that decision finds a stop that came since; and that following reads the lock through a separate open while the ending watcher has not closed its file: wrong, as flock_unlock lets go at once, before following, and following and every take hold the node's lock, so a run handed on that another watcher beat waits under its own hold and is handed on again by that watcher. No finding held.

Demonstrates: spec/ocx/watcher_spec.cr (two runs from a user holding R alone, of builder and coder, arriving together, both handed by one round; while the first runs, the second's watcher writes nothing and the node decides it waiting with the note; a run stone, holding setup, sent as tester starts and ends exited 0 meanwhile; once the first ends its next_runs is the second, which starts and ends exited 0; with r_busy forced false the second starts at once and the example fails; the case 26 example reads next_runs), spec/ocx/ending_spec.cr (case 33 hands on next_runs), spec/ocx/decisions_spec.cr (such a run waits with the note while r_busy, and runs setup or admin sent start; the shipped r-senders.json refuses no files limit and files 1G, naming the cap 256M, and takes a Codex task within it), src/ocx/decisions.cr, src/ocx/care.cr, src/ocx/node/view.cr, src/ocx/watcher.cr and src/ocx/hook.cr (the lock, the row, the hand-on), spec/guards/size_spec.cr (USAGE.md at 400 lines, src/ocx/watcher.cr 398), spec/guards/derivation_spec.cr (docs/design/modules.md as docs/design/modules.json generates it) and spec/guards/documents_spec.cr (the edited documents rendering with their links). crystal run ci.cr green: 483 examples, 0 failures.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QVpmCsBwVF3d4zhMHHDAxs check-in: 3869da228e user: opus-ocx2 tags: agent-tools