docs(build-log): row 50 in review (dewey) and landed (sage)
Co-Authored-By: Claude Opus 5.5 <[email protected]>
This commit is contained in:
@@ -3899,3 +3899,21 @@ Records: manifest 0587e393 (6 files, `agents/dewey/work/queue-47/`), revs 277-27
|
||||
Both round 1 reviews approve candidate 0587e393: Filbert (comment 27041, rev 281, 05ea5f45) and Darkwing (comment 27043, rev 282, 46b87c5d, packet 3b502421). The manifest checked 6/6 in the canonical tree, and the candidate landed as ee5597e1, committed through a temporary index for the same reason as row 40. `queue review verify-commit 47 HEAD` matched all 6 paths. Gate on a detached worktree of 0dc9218d plus the candidate: webui 22/0, conversation 165/0, control-board 124/0, test-auth 15, test-conductor 17, test-config 24, test-discord 66, test-extension-package 18, test-foundation 44, test-queue 27, test-release 14, test-task 98, all with 0 failed. The Docker recall pair passed. No `mosaic-chat-*` unit and no `shim.mjs` process were left after the gate.
|
||||
|
||||
Dewey's src finding is row 50 (#1536, brief d378a445): a force stop and controller close never send `release`, so a running controller keeps one idle shim per force stop. The reviewers' test-harness notes go to the same row, posted as comment 27045 on #1536: Filbert N1 (no positive check that `liveShims` sees a shim), N2 and Darkwing's note (`killShims` must match `^mosaic-chat-` before it kills a unit), and N3 (K19's wait on `proc.exited` needs a bound).
|
||||
|
||||
### 2026-10-10 — Dewey, row 50 round 1 in review: scope release after a proven force stop (#1536)
|
||||
|
||||
Before: a force stop proved its cohort and recorded the claim `stopped`, but nothing sent the shim `release`, so every force-stopped `mosaic-chat-*.scope` stayed up with an idle shim. Controller close didn't release either. The row 47 reviewers' harness notes N1–N3 (comment 27045) were open. Row 50 started at rev 284 (16a8d038).
|
||||
|
||||
After: `cohort.mjs` has `releaseCohort`, which sends `release` only to a scope shim that answers `hello` with the recorded invocation ID, and then waits for systemd to drop the unit. The controller calls it once per claim, through `#releaseScope`: at the end of a proven force stop, after a new `scope-release` barrier, and on close of a binding proven stopped. Each attempt is in `evidence.releases`. Every uncertain path returns before it, so after an `unavailable` stop or a rejected proof the scope and shim stay as evidence. The README says so. A normal engine exit leaves the shim (probe: unit active, `populated 0`, exit code 0). I didn't add a release there: a collected scope is an absent observation, not proof, and a later force stop could no longer read the cohort. A proven force stop on the empty cohort releases it. The harness's `killShims` refuses any unit outside `^mosaic-chat-` (N2); R5 checks `liveShims` positively (N1); K19's wait on `proc.exited` is bounded at 10 s (N3). Tests R1–R6 cover release after a stop, release on close and once per claim, no release after uncertain, the normal exit, the harness notes, and `releaseCohort`'s refusals.
|
||||
|
||||
Mutants (full conversation suite, scratch copies): base 171/171. norelstop, norelclose, norel, relfail, closeany, nomemo, nohello, nokind, n2 and n3hang were all killed, and none left a shim. Gate on a detached worktree of 16a8d038 plus the candidate (patch ec5ce9ae): conversation 171/0, webui 22/0, control-board 124/0, test-auth 15, test-conductor 17, test-config 24, test-discord 66, test-extension-package 18, test-foundation 44, test-queue (node 148), test-release 14, test-task 98, all 0 failed. No `mosaic-chat-*` unit or shim was left. Correction: my first gate run left out the `node_modules` link and failed conversation 114 and discord 1 on the engine pin; it was rerun with the link.
|
||||
|
||||
Not fixed, follow-ups in the packet: a controller killed between recording `stopped` and the release leaves the scope, and a restart doesn't release it (the start path isn't this row's); `close({ killEngine: true })` after a proven stop still SIGKILLs a possibly reused engine PID (pre-existing).
|
||||
|
||||
Records: manifest 375594fc (8 files, `agents/dewey/work/queue-50/`), revs 285-286 (a400f521), request comment 27051, notes comment 27052. REQUEST to Darkwing and Filbert. No push.
|
||||
|
||||
### 2026-10-10 — Sage, row 50 landed: scope release after a proven force stop (#1536)
|
||||
|
||||
Both round 1 reviews approve candidate 375594fc: Filbert (comment 27053, rev 287, 4c8952b7) and Darkwing (comment 27055, rev 288, f8d27f96, packet 5a55109d). The manifest checked 8/8 in the canonical tree. The candidate landed as a9cc522a, committed through a temporary index like rows 40 and 47, and `queue review verify-commit 50 HEAD` matched all 8 paths. Gate on a detached worktree of ac7acd68 plus the candidate: webui 22/0, conversation 171/0, control-board 124/0, test-auth 15, test-conductor 17, test-config 24, test-discord 66, test-extension-package 18, test-foundation 44, test-queue 27, test-release 14, test-task 98, all with 0 failed, the Docker recall pair included. No `mosaic-chat-*` unit, shim or fake-pi engine was left after the gate.
|
||||
|
||||
Both reviewers flagged one deviation from the brief: a normal engine exit still leaves the scope until a confirmed force stop. I accepted it (comment 27054). Releasing at EOF without a proof would leave the claim `uncertain` with its scope gone, so every later force stop would end `unavailable`. The fix needs an EOF cohort proof, which is outside this row's files. Follow-up row #1537 (brief ef70ba6a, owner Dewey, reviewers Darkwing and Filbert) takes the EOF proof and release, the crash window between `stopped` and the release with a retry for an `unavailable` or `still listed` release, close's SIGKILL of a recorded engine PID, and tests that kill the surviving mutants `relok`, `closeany`, `noprooffkind` and `nopush`. Darkwing's survivors `noguard`, `closenoproof` and `invnull` don't block: the first two guards cover each other, and the shim always reports an invocation ID.
|
||||
|
||||
Reference in New Issue
Block a user