Intent: the adversarial review of aa650c80c4 (scratchpad rvaa65) found, on Fossil 2.27: (a) the comment of Place#hosted, docs/fossil.md and HISTORY.md decision 116's cost sentence said that a holder of Fossil's settings alone meets only a command writing them, but every fossil command reads the settings as it starts, OCX's wait, a fossil sql shell, before its DETACH runs, so with a reader holding the settings and a writer of them waiting at its COMMIT, which keeps every new reader out, fossil add, fossil bundle import and the wait by -R each failed after 30.03 s, "database is locked" at SELECT value FROM global_config, Fossil waiting 15 s there and 15 s at SELECT fts5(?1) before it; a wait failing so counts as a try, so the bound the comments gave, three waits each of 15 s, or in a checkout 30 s, does not hold there: OCX's tag on a repository whose settings were so held 240 s failed after 210.22 s, four runs and three waits of about 30 s each (tried on aa650c80c4, scratchpad sf/ot.cr). (b) A clone of a repository file meeting a writer of the settings failed after 15 s and left its file, so its run again failed "file already exists". Checked against what OCX does before changing anything: OCX clones only by URL (launch's clone step through Workspaces.remote!, which refuses all but http and https; poll's server, which it signs in to over HTTP first), and Fossil 2.27 takes away the file a clone by URL made as it fails so: a clone by URL meeting a writer of the settings failed after 15.03 s and left no file, and OCX's Place#clone on aa650c80c4 met a writer holding the settings 20 s and cloned after 20.1 s, and one holding them 70 s failed it (Locked) after 60.14 s, leaving no file, each wait between its runs finding no repository and counting as a try (scratchpad sf/oc.cr). So the leftover is no path of OCX's, and nothing in its code changes for it; the comment of Place#clone says why its run again starts clean. (c) While OCX's commit runs again against a reader of the settings, the account's other fossil commands wait at their start: of 70 reads, one a second, during a 60 s hold, 42 failed after up to 30.03 s, 44 on 4228a3de0b; recorded in the backlog, not changed.

Expression: src/ocx/fossil.cr: the comment of LET_GO adds that the shell reads the settings as it starts, before the DETACH, so one keeping their new readers out holds the wait there, failing it, saying LOCKED, after twice BUSY; TRIES's, that each wait is up to BUSY after up to twice BUSY as it starts, or in a checkout two such; Place#hosted's, that a writer holding the settings alone meets only a command writing them, a run failing so counting as a run again, while one keeping their new readers out fails each run and each wait at its start after twice BUSY, a wait failing so counting as a try, and the bound so. src/ocx/fossil/sync.cr: the comment of Place#clone, that a run meeting a writer of the settings leaves no file, Fossil 2.27 taking away the file a clone by URL made, though not that of a clone of a repository file, which OCX never makes, and that the wait before its run again finds no repository and counts as a try. No code behaves differently. Docs: docs/fossil.md, "Forum posts": the settings point says a writer holding them alone, and a new point, every fossil command reading the settings as it starts, with the review's numbers and the clone by URL; "Clones and logins" drops its copy of the point that a repository has no forumpost table until its first post, which "Forum posts" holds, so the file stays within 400 lines; HISTORY.md decision 117, correcting decision 116's cost sentence, its wait standing; docs/backlog.md, a row for (c) with the review's numbers. The protocol's definitions are unchanged.

Review: Gemma (gemma4:31b) read the whole diff with its intent twice (scratchpad gemma-reviews/settings-followup-reply.json and settings-followup-2-reply.json, the second asked to read each comment against the code beside it): "I find nothing." and "I found no defects." Held: none. Misread: none. Wrong: none.

Demonstrates: no example demonstrates a comment, and no behaviour changed, so the guards hold the edited files and the examples hold the code as before: spec/guards/size_spec.cr (each file at most 400 lines, docs/fossil.md at 400), spec/guards/documents_spec.cr and spec/guards/delineation_spec.cr (the edited documents rendering, each document named by a link), spec/guards/checkin_spec.cr (this comment), spec/ocx/fossil_spec.cr and spec/ocx/writers_spec.cr (src/ocx/fossil.cr and src/ocx/fossil/sync.cr waiting and running again as before), spec/coverage/run.cr (every statement still covered); the trials on aa650c80c4 above, in the scratchpad. crystal run ci.cr green: 497 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: 31c712a101 user: opus-ocx2 tags: agent-tools

Intent: the adversarial review of 39c646f7ad (scratchpad rv211-e/x39) found, confirmed on Fossil 2.27: in a checkout, OCX's wait, fossil sql there with no -R and BEGIN EXCLUSIVE, opened the repository as its main database, then .fslckout, then Fossil's settings, and took their locks in that order, keeping each while it waited for the next, so with only .fslckout held by a writer outside OCX it took the repository's exclusive lock at once and kept it, at each of its waits: a read of the repository and /timeline took 14.36 s during it (0.01 s beside a wait by -R); while OCX's add met .fslckout held 70 s, 15 of 50 pages took over 15 s, the longest 29.99 s, with no one holding the repository; and a person's commit-like command in the checkout, holding .fslckout and reading the repository, lost its write of the repository, "database is locked (5)". HISTORY.md decision 114 and the comments of LET_GO and Place#hosted, which said the wait waited on both, were wrong for this case. With two waits, in the review's trials and again here: each of those 50 pages answered within 0.01 s; the person's write was kept and OCX's add went through after 2.77 s (2.76 s here); and a commit in a checkout whose repository a reader held 20 s was stored after 19.69 s (19.7 s here).

Expression: src/ocx/fossil.cr: Place#hosted makes a command's wait, in a checkout, two: first fossil sql there with --no-repository and an empty main database (:memory:), which opens the checkout's own database with nothing but Fossil's settings after it, then, only once that has gone through, fossil sql -R on the repository alone, which opens no checkout database; the wait goes through only as both do, so the counting of tries and runs again is unchanged; a command naming its repository waits by -R alone, as before; a new private Place#let_go_of? makes one such wait; naming .fslckout itself as the main database opens it twice and the wait waits on itself, as tried; the comments of LET_GO, TRIES, hosted and let_go_of? say so, and that in a checkout a wait takes up to twice BUSY. spec/support/stand_in_fossil.cr: Holder::Person, a person's own fossil command in a checkout, as fossil commit is, writing the checkout's own database and reading its repository in one transaction, and, as it lets go, writing the repository's setting KEPT and committing (Holder#lets_go), where every other holder rolls back; Holder#waited_on, the shell test by which the stand-in knows OCX's wait is on the holder's database, a wait on the repository naming it by -R first and one on a checkout's own database naming no repository; the holder's sql shell keeps Fossil's settings in the stand-in's own directory, its HOME, since a writer's BEGIN IMMEDIATE takes the lock of every database its shell opens, the settings database among them, which OCX's first wait in a checkout opens too (spec/ocx/post_spec.cr's clone held at its write's first run failed so); holding_until's waited returns only once OCX's wait is asleep in SQLite's busy wait, as /proc/PID/wchan says, so it has taken each lock it takes before the holder's, where before it returned as the wait started and a read could come before the old wait locked the repository. spec/ocx/fossil_spec.cr: the new example. Docs: HISTORY.md decision 115, amending decision 114 and naming the review, decision 113's bound being in a checkout three waits of up to 30 s each; docs/fossil.md, "Forum posts", what was tried: the order fossil sql in a checkout opens and locks its databases, the stalled reads and the lost write, --no-repository :memory:, and .fslckout as the main database waiting on itself; docs/interfaces.md, fossil sql's row. The protocol's definitions are unchanged: section 5 and failure case 35 speak of a writer holding the repository, for which a wait in a checkout is still up to 15 s, its first wait going through at once where no one holds the checkout's own database.

Review: Gemma (gemma4:31b) read the change four times (scratchpad gemma-split-1.txt to -4.txt, the whole diff). Held: none. Misread, each a clarity finding, the code changed and asked again: first and second rounds, each opening that the two waits' let_go was flawed, overwritten by the second wait, or the repository's wait skipped when the first did not go through, each taken back by Gemma itself: hosted's comment now says the second wait is made only once the first has gone through and that the wait goes through only as both do, and the two assignments became one expression, let_go = (!in_checkout || let_go_of?(["--no-repository", ":memory:"])) && let_go_of?(["-R", file]). Wrong: third round, about counting each run as a try or a run again at the loop's start, code unchanged here, which it read right in the end; fourth round, that a wait on the checkout's own database that does not go through leaves the repository never waited on: the run after it meets that holder first, and the repository's wait follows once the first goes through, as Gemma itself then said.

Demonstrates: spec/ocx/fossil_spec.cr (in a checkout, a writer holding its own database alone, then a person's command holding it and reading the repository, while an add there waits: a read of the repository through the fossil program answers within a second, the add goes through once each lets go, and the person's write of the repository as it let go is kept; against 39c646f7ad's src/ocx/fossil.cr each read failed, nothing after a second, and the person's write was lost; and, as before, a writer holding the checkout's own database while add and commit run there, and past each wait), spec/ocx/writers_spec.cr (a read within a second while a report waits for a writer, and a reader holding the repository while a report write runs, OCX's waits known once asleep), spec/ocx/post_spec.cr (a post in a clone held at its write's first run, written whole and pushed once, the holder's settings apart from OCX's), spec/ocx/create_spec.cr (a run held past each wait of its write stores nothing), spec/support/stand_in_fossil.cr (Holder::Person, Holder#waited_on, the holder's own settings, holding_until answering once OCX's wait is asleep), src/ocx/fossil.cr, spec/guards/size_spec.cr (each file at most 400 lines), spec/guards/causation_spec.cr (no timer added), spec/guards/interfaces_spec.cr and spec/guards/documents_spec.cr (the edited documents rendering with their links), spec/coverage/run.cr (every statement still covered, Place#let_go_of? among them). crystal run ci.cr green: 496 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: 4228a3de0b user: opus-ocx2 tags: agent-tools