stack/agents/gizmoduck/work/queue-264/BUILD.md

Row 264 build notes (Gizmoduck)

T1 item 7: independent sessions, compaction counts and clear context. Gitea #1769, Vikunja 463 (design) and 466 (Claude compaction format, T3's dependency, linked and not built here). Brief: docs/plans/2026-10-21_t1-sessions.md, "T1 item 7: independent sessions, compaction counts and clear context" (blob ff0be0c79). Reviewer Duckworth, gate owner Sage. Branch gizmoduck/row264 from refactor da9555ca2. MVP due 10-27.

The brief pins its code citations at cca206cdc. git diff --stat cca206cdc da9555ca2 over every cited source file is empty, so F1-F11 still hold line for line. Only docs/prd/mosaic-stack.md moved.

Phase A: what the code has today

• Bus. threads binds one instance per thread (schema.sql:240-250). thread_claims keys on thread alone (:251-261), and message_threads maps a message to a thread (:262-265). Schema is 3j (store.mjs:17). The thread tables first appear in migrations/3d-3e.sql.
• Launcher. check() refuses a second run for the same instance and thread (launcher.mjs:233-240, registry.running(b.id, instance, thread)).
• Seat. threadStore() makes one session/ and one claude-projects/ per thread (session.mjs:51-74). The registry's running key is business, instance and thread (:215-218).
• Runner. stop() sends TERM to the child group, then KILL after 5 s (runner.mjs:402-414). It has no drain, no idle acknowledgement and no dequeue fence. D7 step 2 needs all three.

Consumer audit (D9), first pass

git grep -F over packages//src/ and adapters/* at da9555ca2:

Name	Files and hits
thread_claims	broker.mjs 12, store.mjs 1
message_threads	broker.mjs 9
thread_opens	broker.mjs 4, store.mjs 1
threadStore	launcher.mjs 4, sandbox.mjs 7, session.mjs 3
running(	launcher.mjs 5, session.mjs 1

Still to read: the broker holder, agents, end, usage, reply correlation and pending-approval paths named in D9, the two adapters (F5), both harness plugins, the conversation reader (F8) and the Console. Each gets a file:line row here before the first code commit.

Proposed slices

One seat can't build D1-D9 in six days and keep every slice reviewable. I propose five candidates under row 264, each with its own manifest and Duckworth round:

1. 264a bus. Session tables, claim key (organization, thread, instance, session) with a generation, the D3 default session, the D9 bus mapping, session.list and session.create, and an optional session selector on the thread verbs. Tests: T1 bus half, T2 claims, T7 legacy clients and the rollback refusal.
2. 264b seat and launcher. Per-session native store and workspace, the single-writer fence, the registry key with session, sandbox mounts of the selected store only, and pinned native ids in both adapters. Tests: T1 run half, T2 workspace and path mutants.
3. 264c compaction count. Host collector, exact for Pi. Claude shows unknown with the 466 reason until that format is pinned. Tests: T3 Pi half.
4. 264d clear. The D7 journal, the runner drain fence and idle acknowledgement, stop proof, then retirement and successor in one transaction. Tests: T4, T6.
5. 264e surface. mosaic session CLI and the Console chooser, count and clear confirmation. Tests: T5 for the legacy single human, T7 Console half.

Phase A rulings (sage-2235)

Q1-Q7 went to Sage in gizmoduck-0154. Sage's answers are in agents/sage/work/queue-264/RULINGS.md at 5f5b51dd6. In short:

• Q1. Five candidates in the order a, b, c, d, e, each with its own manifest, Duckworth round and landing. Row 264 carries 264a. Sage adds rows for 264b-264e. All five are MVP.
• Q2. 264a builds as 3j-3k.sql. If 236 or 206 lands first, I rebase onto a new branch name, take the next label, and rerun the whole bus suite, the schema.test.mjs counts and the T46 lists.
• Q3. PRD 1.13 has landed, and REQ-ROLE-2 (mosaic-stack.md:323-329) already carries the session text. Build to it.
• Q4. Row 194's lifecycle path owns the stop. honker/row194-b5 dfabbbe8a is read-only reference. 264d rebases onto 194's landing. The runner's dequeue fence and idle acknowledgement are new code and a named review item. No 194 code gets copied.
• Q5. One shared admission hook for every session start, using today's limits and revocation. Of 191 and 264b, whichever lands second wires 191's checks in. No setting turns it off, and a check that's configured but unavailable fails closed.
• Q6. 264c lands with Pi exact and Claude unknown with the 466 reason. The Claude half of T3 stays open on row 264 and Vikunja 466.
• Q7. Legacy single human only. Collaborator and share paths refuse. A4 and the full matrix go to whichever of 264 and 193 lands second.

264a design: the bus

Line numbers are at da9555ca2 unless they say otherwise.

Schema 3j-3k

• sessions, new and immutable: id, at, business, thread, instance, owner, name, op (the creation operation key) and predecessor (null until 264d's clear). UNIQUE (thread, name) and (thread, op), so a repeated create with the same key finds the first row. Guard triggers check that the business, instance and owner match the thread's, and that a predecessor sits in the same thread.
• session_defaults, new and append-only: thread, session, at, by. The latest row per thread is that thread's default (D3). A trigger checks that the session is in the thread.
• thread_claims, message_threads and thread_opens are rebuilt, each with a session column, and thread_claims also gets generation. Rows are copied with their seq values and every old column as it was, and the sequence carries over, as 3h-3i.sql did for usage_records. That is a named review item: the copy adds two derived columns and changes nothing else.
• Each existing thread gets one legacy default session with id equal to the thread id, the name default, op legacy-3k, and the thread's own at and owner. Every copied row names that session. This is D9's immutable mapping. 264b binds it to the existing native store at threads/<business>/<thread>/session/. A new thread's default session gets a random id.
• generation is the claim's number within its session, counting from 1. A release or revoke carries its claim's number. On copy, it's the count of claim rows in the thread up to that row.
• Triggers keyed on the thread now key on the session: one holder, release only while held, only the holder releases, and a generation check. These two keep their thread meaning: one held session per run per business, and the business check. New checks: the claim's, message's and open's session is in the named thread. delivery_same_thread becomes delivery_same_session, which sends a threaded message only to its own session's holder.
• A 3j binary refuses a 3k store with schema-mismatch (store.mjs:181-186), which covers D9's rollback refusal. T7 tests it.

Broker

• Run binding. bindLaunch takes an optional session. When it's missing, the run gets the thread's default session, which is the D3 path for today's launcher. The binding refuses a session that isn't in its thread. The run's s.session then drives role.claim, #own, message.receive and the reply routing.
• Lookups. #threadHolder(thread) becomes #sessionHolder(session), which #recipient, #routeThread, #threadHolders, #claimEnd, threadIdle and run end all use. #threadFor returns a thread and its session: a thread run's own, or the session of the nearest threaded message up the reply chain. #specThread uses the opened thread's default session.
• Launcher view. threadsState and threadIdle keep their row shape, one row per thread computed on its default session. Until 264b, the launcher starts only default sessions. Messages to another session wait, and nothing reaches the default session's run.
• Verbs:
  • The thread verbs take an optional session, and leaving it out uses the default (D3). thread.create also makes the default session. thread.messages without a session reads the default session.
  • session.list {thread} and session.create {thread, name, op} (D8: metadata only). The build dropped session.get, session.open and session.send. thread.open, thread.send and thread.messages take an optional session, which does the same job with one owner check and one code path.
  • All of them are human or tester only, through #human/#thread, the same owner check as the thread verbs (Q7: single human, no shares). They go into TESTER_VERBS.
• Other readers. #grantNotice, #raisedThread and the decision-close path (:736, :1500, :2941) read the holder run's claim row. The rebuilt thread_claims keeps that query working, and the session comes along from the same row.

Tests and lists

• New file packages/bus/tests/sessions.test.mjs:
  • T1 bus half: two sessions in one thread, distinct histories, receive and reply isolation, and a non-thread role refused.
  • T2: one holder per session, generation fencing, sibling delivery refused by the trigger.
  • T7: legacy clients, the 3j-3k migration from a fixture (default session id = thread id, rows copied with seq), and the rollback refusal.
• A new fixtures/schema-3j.sql.
• Update the schema.test.mjs pins (:519-525), the '3j' version pins in the migration tests, COUNTED in scripts/stack-release.sh:404, and the T46 lists in packages/cli/tests/stack-release.test.mjs:860-934. Also timedTables (store.mjs:65-79) and the broker clock-seed list (:325-336).

Duckworth's design checks (duckworth-0106)

Duckworth had no objection to the in-place rebuild and asked for seven checks. Where each one is:

1. The cross-table trigger. 3j-3k.sql drops delivery_same_thread before any rename and creates delivery_same_session after the new tables.
2. Index names. The step drops thread_claims_thread and message_threads_thread before the renames, so the new tables can reuse the names.
3. Per-table triggers. The step drops each guard and append-only trigger and creates it again with text that matches schema.sql. The digest check at store.mjs:231 enforces that, and the T7 sqlite_master comparison shows it.
4. Generation counts claim rows only. T7's fixture is Duckworth's: claim, release, claim, revoke, giving 1, 1, 2, 2, with t2's claim between them.
5. Sequences. Rows keep their seq values, sqlite_sequence carries over, and T7 checks that the next insert is 41 after 40.
6. Id collisions. A legacy session id is its thread's id. sessions_id_not_thread refuses a session id that names another thread, and threads_id_not_session refuses a thread id that names a session. New ids come from randomUUID.
7. thread_one_per_run. The inner max(seq) is per session.

Duckworth's early look (duckworth-0107) and Sage's ruling (sage-2257)

Duckworth read 312cf33a1 with git only and found nothing blocking. Round 2 (gizmoduck/row264-r2, rebased on dcd8d4dda with no shared paths) answers his notes:

1. Retired-generation replay. Sage ruled it into 264a (sage-2257). #agent now states the thread run's fence in generations: the session's latest claim must have the generation of the run's own latest claim (#runGeneration). This refuses nothing new. The trigger thread_claim_generation gives each claim in a session its own number, so with h.op 'claim' the generations match exactly when h.holder_run is the run, which is the check it replaced (duckworth-0108). 312cf33a1 would most likely refuse the same calls. A new sessions.test case has a released run and a revoked run each try decision.withdraw, message.receive and message.read after another run claims the next generation. All refuse not-holder and every table's row count stays the same. The workspace and path halves of T2 stay in 264b.
2. assistant.stop keeps returning {thread, run}. Adding session would change the pins in tester-threads.test and threads.test for a field no caller reads yet. The Console stop in 264e is the first reader, so the field goes there.
3. #route refuses an unknown session with session-not-found instead of a TypeError.
4. The README's session section says the default retry answers on new threads only, because a migrated default has op legacy-3k (legacy-3l from round 5).
5. The Row 155 comment at the role.revoke end now says "held thread session".

Mutants

Each runs on a copy of the candidate tree with one edit, and the named test must fail.

• M1 (sage-2257). In #agent, replace h.generation !== this.#runGeneration(s) with false. Killed by sessions.test "a released or revoked run's retired generation". M1 removes the thread run's fence entirely, so the kill shows the refusal is tested, not that generations add a check. A mutant that puts back h.holder_run !== s.run survives by equivalence. That isn't a coverage gap.
• M2 (mos-1279, sage-2688, sage-2690). Four edits, and the restore sha check covers all four files:
  1. broker.mjs:5251, in message.receive: drop the mt.session=? filter (the session clause and its argument).
  2. 3k-3l.sql: drop the delivery_same_session trigger.
  3. schema.sql: drop the same trigger.
  4. store.mjs:16: set SCHEMA_SHA256 to the sha256 of the mutated schema.sql, with the replace sessions.test:432 uses. store.mjs:94 checks schema.sql against it at import (duckworth-0144). LEGACY_SHA256 stays. The chain check at :117 holds because both SQL files drop the trigger. Without edits 2-4, the trigger refuses #delivery's INSERT first. request() then returns storage-refused before any assertion runs. That happened at r13 (duckworth-0143). A kill counts only as an assertion in a test that exercises receive: sessions.test T1 :89, T7 :422, or another receive assertion the log names. A failure only at the trigger's own pin (:164-170) doesn't count, and neither does a thrown error. The killing test is expected to be T1, where a1 would take the second session's message.
• M3. In 3k-3l.sql, count every claim row for generation instead of op='claim' rows only. Killed by sessions.test T7, generations 1, 1, 1, 2, 2.

Phase 4 rerun on r13 (mos-1279, sage-2688). The r13 gate's phases 1-3 carry. M1-M4 rerun whole on 2cc34aef8 plus this note, each under timeout -k 10 300 (Run limits). Any survivor, throw or non-receive kill goes to Mos unplaced.

Dry run

Before writing any node test, I ran 3j-3k.sql in an in-memory Python sqlite3 on a 3j fixture (gizmo-264-out/dry-3k.py, no repo code). The claims were kept with generations 1, 1, 1, 2, 2 in seq order for the mixed t1/t2 fixture. Seq 40 carried over and the next insert was 41. The migrated sqlite_master matched a fresh schema.sql, 119 rows each. Every guard refused its bad write.

Hand-made threads in tests

A thread that a test writes by hand has no default session, because only thread.create and the migration write one. The broker refuses such a thread with session-not-found, and the launcher view leaves it out. So every test that inserts a threads row now also writes the legacy-shape default session (DEFAULT_SESSION in threads, end-launch, thread-cli, thread-launch and chat tests). That mirrors the migration's rows rather than inventing a third shape.

Round 5: on row 236, the step is 3k-3l

Row 236 (8f51900b5, which round 5 is built on) adds migrations/3j-3k.sql with the gitea_users and gitea_grants tables, and lands first. By the landing-order label (Q2, sage-2412) 264a's step moves one version. The design above still says 3j-3k; read it as 3k-3l.

• migrations/3k-3l.sql is round 4's 3j-3k.sql with three renames and nothing else: the copy tables are *_3k, and the op values are legacy-3l and migration-3l. The op values name the step's target version, as round 4's legacy-3k did on 3j-3k (sage-2415). No earlier migration set a precedent either way.
• store.mjs runs 236's 3j to 3k step, then 3k to 3l. SCHEMA_VERSION is 3l, and SCHEMA_SHA256 is the merged schema.sql's, cd68512212ce8bf8f5631138b2e63a340fa7b940088430649bb7784af7df162a. schema.sql merged with no conflict: 264a's edits are above 236's two tables at the end.
• The T7 fixture is fixtures/schema-3k.sql, 236's schema.sql at 8f51900b5 (SHA-256 aba92408...). 236's fixtures/schema-3j.sql is the same blob round 4 added, so that path no longer differs.
• Pins: schema.test 22 tables and 86 triggers; README 22 tables and 87 triggers. Every '3k' version pin is '3l', the comment-migration future step is 3l to 3m, and each copied engine also copies 3k-3l.sql.
• account-migration and grant-migration filter both 236's objects and the 3k-3l objects. gitea-migration.test (236's) now reads its store after both steps: version 3l, rows skips sessions and session_defaults, master skips the 3k-3l objects, and its failing engine copies 3k-3l.sql. Its 3j engine already stripped every step after 3i-3j.
• sessions.test's engine is a 3k engine: 236's schema and steps through 3j-3k, no 3k-3l.
• The restore guard lists merged with no conflict: 236 adds gitea_users and gitea_grants to T46's untimed, and 264a adds sessions and session_defaults to COUNTED and LISTED.

Dry run (gizmo-264-out/dry-3l.py, Python sqlite3 in memory, no repo node): 3k-3l.sql on 236's schema kept every claim with generations 1, 1, 1, 2, 2, kept seq 40 with 41 next, and the migrated sqlite_master matched a fresh schema.sql, 121 rows each. Against round 4's run from 86f95bb27 (dry-3k-r4.py), the output differs only in the op values and the 119 rows that 236's two tables make 121.

Round 5 on landed 236 (47a35bf43)

Row 236 landed at bd5f11ded and refactor was 47a35bf43 (sage-2579). The prep commits moved from 8f51900b5 to 47a35bf43 by cherry-pick. schema.sql, the migrations, store.mjs and the fixtures are the same as the prep tip 4b369ddba, so the SHA-256 and the dry run above still hold.

• Two conflicts, both with row 194. In broker.mjs TESTER_VERBS keeps 194's instance.launch, instance.end and instance.request and then 264a's session.list and session.create, and the private fields keep 194's block before 264a's claim comment. tester-writes.test pins the same list in the same order.
• Row 205's message-filter.test (new since 8f51900b5) makes threads and message_threads rows by hand. Its threads now get the default session, as the other hand-made threads do, and its message_threads rows name that session. That makes 19 touched test files, not 18.
• A defect from round 1: edit-264a-6.py wrote DEFAULT_SESSION with bare ' quotes inside single-quoted strings in threads.test, end-launch.test and chat.test. Those three files could not parse in any earlier round. The quotes are now escaped. The two cli tests used double quotes and were fine. Runs below records no run, so no reported result rests on those files.
• Every broker insert into thread_claims, thread_opens and message_threads names a session, 194's new callers included. 194's lifecycle-verbs.test reads thread_claims by thread only.
• Pins on this base: schema.test 22 tables and 86 triggers, README 22 tables and 87 triggers, COUNTED and LISTED carry sessions and session_defaults, T46's untimed list carries 236's gitea_users and gitea_grants.

Correction (sage-2581)

Rounds 1 to 4 never parsed bus threads.test, bus end-launch.test or webui chat.test. Each had the bare quotes in DEFAULT_SESSION described above, from edit-264a-6.py in round 1. No run claimed those files: this packet's Runs section was empty through round 4 and the r4 gate was voided before it started (sage-2412). Round 5 escapes the quotes.

The round 5 gate is wider than the plan above (sage-2581, mos-1200: a rebase carries no result). Each of the 19 touched test files runs whole on its own, then the bus, cli and webui suites whole, then every scripts/test-*.sh, then the mutants, with every skip named.

Round 6 on landed 274 (0165be266)

Row 274 (FED R3) landed at 4c485c63b and refactor was 0165be266 (sage-2588). The round 5 commits moved from 47a35bf43 by cherry-pick. broker.mjs is the only path both rows change.

• Four conflicts in broker.mjs, all from 274's user principal. USER_VERBS and USER_LEVEL follow TESTER_VERBS, which ends with the session verbs as before. In thread.open, thread.send and thread.messages each verb keeps 274's !s.tester && !s.user check and #grantedThread, and adds 264a's optional session key, #threadSession and the session on thread_opens and #route. thread.send keeps 274's return, where a user's message writes no human.input.
• Users stay at the seven ruled verbs (sage-2576): session.list and session.create are not in USER_VERBS. user-principal.test:133 already checks every verb outside the list refuses a user, and that set now includes the two session verbs.
• 274's B6 check (a run answers a user only in reply to that user's message in its thread) joins message_threads by thread, not by session. No code change: a user can't call session.create, and #thread refuses anyone but the owner, so a user's thread has only its default session and the two scopes are the same rows. A slice that lets a user add sessions (264e) must make it session-scoped and test it.
• 274's other writes and tests make threads through the broker, so each gets its default session. Its tests read thread_opens and message_threads by thread, and those columns stay.
• schema.sql, the migrations, store.mjs and the fixtures are unchanged from round 5, and so are the touched test files: 19.

Round 7 on landed 277 (980cec88c)

Row 277 (thread.claims, #1782) landed at 62f53b1e0, after row 256 (f12441d4f), and refactor was 980cec88c (sage-2608). The round 6 commits moved from 0165be266 by cherry-pick with no conflict, and the range-diff is = for all eleven.

• 256 changes packages/bus/src/runtime.mjs, packages/business/src/instance-settings.mjs and packages/webui/src/public/agents.js. None is a manifest path and none of their changed lines names a thread, a session, message_threads or thread_claims. Three touched tests load these modules (bus chief-of-staff and tester-writes, cli thread-launch), so the whole-file runs cover 256's code.
• 277's thread.claims took the latest thread_claims row per thread. With sessions that is the last claim of any session, so a second held session would hide the first (duckworth-0123 N3, sage-2591). It now joins sessions and takes each session's latest row, as #threadHolders does, ordered by thread then session. The result keeps 277's five keys: two rows of one thread differ by holder_run, and mosaic agents prints each as its own thread line. Adding the session id to the row is left to the slice that shows sessions to the owner.
• thread-claims.test (277's) makes its threads by hand, so each now gets the default session the migration gives an old thread (C5, :47), and its T5 message names that session (:111). T6 holds two sessions of one thread, sees both rows, releases one and sees the other (C4). M4 swaps the query back to 277's per-thread latest row and must fail T6.
• 274's thread-scoped user reply check binds row 272 (264e) in docs/plans/DEFERRED.md, written here (sage-2608): a slice that lets a user add sessions makes it session-scoped.
• 277's other tests: message-filter.test's claim pin reads thread.claims for a thread made with its default session, and the cli format and tester tests use stub rows or no threads.
• Touched test files: 20 (thread-claims.test joins). Mutants M1-M4.

Correction: the r7 red (sage-2621, duckworth-0129)

The r7 gate on Sage's CLEAR (sage-2619) stopped on its first file. account-migration.test failed 2 of 3: "3h copy migrates to 3i" at :87 and "a 3h→3i step that fails partway" at :136. Each compares a whole snapshot of the store after the steps to 3l, sqlite_sequence included, with the snapshot before them, and found two more rows: session_defaults and sessions, both at seq 0.

The cause is mine. 3k-3l.sql:50-52 fills sessions and session_defaults with INSERT ... SELECT, and SQLite writes a sqlite_sequence row for an AUTOINCREMENT table on that insert even when it copies no row. My round 1 schema commit (67fded6af then, 31fcecf7b in r8) changed the file's version pin, master filter and engine copy, but no round ran the file before r7 (Correction above: no run was claimed). The same gap held in every migration test that dumps sqlite_sequence.

What I read in r8, before any run: every touched test (and every bus, cli and webui test that calls migrateSchema) that compares a whole snapshot or whole table across a step to 3l. git grep migrateSchema and git grep sqlite_sequence over packages/*/tests/* and scripts/* gave the list. A Python sqlite3 dry run of the real steps on each fixture's shape (gizmo-264-out/dry-seq-r8.py, no repo node) gave the rows after the step.

• account-migration :87 and :136: red as run. Fixed. :132 compares before the 3l step (the failing 3h→3i engine rolls back) and is unchanged.
• gitea-migration :90 (3j to 3l) and grant-migration :95 (3i to 3l): rows() leaves out the new tables by name but keeps sqlite_sequence. Same two rows at seq 0. Fixed. gitea :113 and grant :117 compare after a rolled-back step and are unchanged.
• usage-migration :67 (3g to 3l), name-migration :65 (3f to 3l), spec-migration :61 (3e to 3l): whole snapshots with sqlite_sequence. Their fixtures have one thread, so the two rows are at seq 1. Fixed. In usage-migration the step also moves the thread_claims and thread_opens rows after instance_names' (3k-3l.sql:84-86 deletes and writes them again), so its snapshot now reads sqlite_sequence by name, as account-migration's has since row 126 (ca15d73e9).
• Read and not affected: thread-migration :110 and :144 compare messages and deliveries only; sessions.test T7 and the D9 refusal compare named 3l tables, 3l against 3l, and :177 lists table names; each engine-refusal test (account :156, gitea and grant's third test) compares 3l with 3l; comment-migration and chief-of-staff count rows and compare no snapshot; stack-release.test T46 lists table names from schema.sql, and its --migrate tests run stub copies at 3g to 3h.

The fix, in all six files: the compare after the step leaves out the two new rows and asserts them exactly, names and seq, so an extra row of any other name still fails. account, gitea and grant leave out the rows SESSIONS_3L names (sage-2621); their stores have no thread rows, so nothing else in that list has a sequence row. usage, name and spec leave out only sessions and session_defaults, because their thread_claims and thread_opens rows must stay in the compare: the step carries those seqs. Nothing else in the files changes.

Round 9 on landed 278 (385a7194c)

Row 278 (thread claims in the Console) landed, and refactor moved from 6af85df4b to 385a7194c, fast-forward (sage-2657). r8's 15 commits moved by rebase with no conflict, and the range-diff is = for all fifteen.

• 278 changes packages/webui (src/cli.mjs, src/serve.mjs, src/public/bus.js, README, and the tests shell, thread-claims and thread-claims-browser), BUILD-LOG.md and its own packet. None is a manifest path.
• Webui reads by 264a's tests: stack-release.test reads packages/webui/src/cli.mjs at :718 (a --tester-port match, still present) and its copy tests at :2475-2573 replace or append the whole file, so 278's added line doesn't reach them. No 264a test pins a hash of a webui file; the 64-hex pins in the migration tests and sessions.test are fixture DDL.
• 278's thread.claims reader in bus.js renders one table row per result row and checks only that thread, holder_run, harness and at are strings, so 264a's per-session rows (a thread with two held sessions lists twice, five keys kept) show as two rows. 278's three webui tests use fake bus objects and never reach the broker's query.

Round 10 on landed 281 (e479521d3)

Row 281 (a fire or delete revokes the instance's grants) landed, and refactor moved from 385a7194c to e479521d3, fast-forward (sage-2668). r9's 16 commits moved by rebase with no conflict, and the range-diff gives all 16 =. The r9 run never started (sage-2665), so no result carries over.

• 281's paths over 385a7194c: packages/bus/src/broker.mjs, five tests (bus fire-revokes-grants, gitea-grant, grant-executor, lifecycle-revoke; cli lifecycle) and its own packet. The one shared path is broker.mjs, and the hunks don't touch: 264a's at :128, :455-:1081 and :3276-:5537, 281's at :396-:400 and :1273-:3831 (base lines).
• 264a removes #routeThread, #threadFor and #threadHolder. No line 281 adds calls them, and every private name the merged broker calls is defined. No line 281 adds names thread_claims, thread_opens, sessions or session_defaults; its section 3a "claim" is the host-key claim.
• 281's tests name no schema version, migration, sqlite_sequence, thread_claims or 64-hex pin. cli lifecycle.test's sessions are launcher.registry.sessions, which 264a doesn't change.
• No 264a test reads a 281 path as text or pins its hash. The touched tests that import broker.mjs run against the merged file in this round's gate, which is the test of the pair.
• 281's gate (its BUILD.md, "Whole packages") recorded the cli suite at 591 s, longer than the 535 s the table used. 3x is 1773 s, so the cli limit goes from 1650 s to 1800 s. Its other times (bus 23 s, each scripts/test-*.sh at most 36 s) are under the table's, and those limits stand.

Correction: the r11 red, T2 (mos-1277, sage-2676)

The r11 gate (75f049ed2, ffc49615, CLEAR sage-2674) went red in its first phase at sessions.test T2 "a released or revoked run's retired generation", :204: the events table had 10 rows before the three refused calls and 13 after. Every other table's count was equal. request()'s catch (broker.mjs:4242) sends each refusal through #refused (:4081-:4096), which writes one action.refused event with body {code}. r2's base dcd8d4dda has the same catch, so the assertion that every table's row count stays the same (round 2, item 1 above) could never pass. Sage reproduced it at 72fc5a330, ed6773f72 and 75f049ed2, and the three rows are action.refused {"code":"not-holder"}. Mos ruled it a test defect, not a product fault.

Mos's reading of sage-2257: "writes nothing" means a retired generation's approval, delivery and read write no approval, delivery, read or claim state. The refusal trail stays. Commit 19 (test only) makes refused() say that, for both calls (released and revoked):

• every table's row count stays equal except events;
• each refused call adds exactly one event, kind action.refused with body {"code":"not-holder"}, checked after each call in call order (withdraw, receive, read), so events grows by three.

Before the next gate, one survey pass runs the touched files the r10 and r11 runs never reached (sage-2676 step 3), with M1 against the fixed T2.

Run limits (sage-2634, sage-2637, sage-2647, mos-1275)

Every run in run-264 goes through timeout -k 10 LIMIT, so a hang stops the run instead of holding the slot. Each LIMIT is at least 3x the longest recorded run of that file, suite or script. The records are my own gate logs (ℹ duration_ms for node runs, the lap lines for scripts), the times in committed BUILD.md files, and row 278's committed receipts: SHELL-LIMITS.json (row 196's longest per script) and run3/whole/results.json in agents/gander/work/queue-278. A timeout with no failed test is a hang, not a pass or a red, and goes to Sage first (sage-2637). A timeout in the shell phase goes to Mos unplaced (mos-1275).

Run	Longest recorded	Where	LIMIT
stack-release.test alone	575 s	the r12 survey, 2026-10-22 (row 234 r3 singles with mutants: 505 s; plain r3: 482 s); 3 x 575 = 1725 (mos-1275 item 3)	1800 s
each other touched file alone	15 s (thread-launch.test); end-launch, gitea-migration, message-filter, sessions, thread-claims, thread-cli and chat have none	rows 234, 235, 210 logs	300 s
bus suite	23 s	row 235 run 1b; row 278 run 3: 22.5 s	900 s
cli suite	591 s	row 281's gate, 2026-10-22 (row 235 run 1: 535 s; Megavolt row 199: 472 s)	1800 s
webui suite	57 s	row 278 run 3 (row 66 r2: about 60 s)	600 s
each scripts/test-*.sh	42 s (test-foundation); task 36.8, queue 23.4, land-work 12.6, release 12.2, discord 8.8, conductor 8.1, config 3.2, extension-package 3.0, auth 1.9	the longest of row 268's gate (2026-10-22 04:40Z), row 196's receipts and row 278 run 3	900 s
mutant probes M1-M4 (sessions.test, thread-claims.test)	1 s wall each (longest ℹ duration_ms 512, M3)	the r13p4 rerun, 2026-10-22 14:08:43Z to 14:08:45Z	300 s

Runs

• r7 a23afbf95 on 980cec88c, Sage's CLEAR sage-2619, 2026-10-22 11:29:47Z. HEAD and the manifest digest eb7c1ab3 printed and matched. RED on the first file, account-migration.test 1 pass 2 fail (Correction above); the run stopped there as ruled, with no retry. The sweep found 0 node processes in the worktree. Slot returned.
• r10 54f65f9ab on e479521d3, Sage's CLEAR sage-2669, 2026-10-22 13:11Z. RED on the first file, account-migration.test :106: later3l missed the 3l trigger threads_id_not_session (3k-3l.sql:104). Mos ruled option A (mos-1276): commit 18 names it in account-, gitea- and grant-migration. On r11 all 8 *-migration files ran whole, 25/25, 0 skipped (2026-10-22 13:14:25Z).
• r11 75f049ed2 on e479521d3, manifest ffc49615, Sage's CLEAR sage-2674, 2026-10-22 13:16:37Z. Phase 1 was green for account-migration 3/3, chief-of-staff 42/42, comment-migration 5/5, end-launch 7/7, gitea-migration 5/5, grant-migration 6/6, message-filter 6/6, name-migration 1/1 and schema 1/1. Then RED at sessions.test T2 :204 (Correction: the r11 red, above), and the run stopped. 0 node processes left. Mos ruled a test defect (mos-1277): commit 19.
• r12 93f4af12b on e479521d3, manifest 16603087, survey pass (sage-2676 step 3), Sage's CLEAR sage-2678, 2026-10-22 13:24:09Z to 13:34:07Z, 598 s. Each file whole under timeout -k 10, with no stop on red and no edits, all 0 skipped and 0 todo: sessions 7/7, spec-migration 1/1, tester-writes 8/8, thread-claims 6/6, thread-migration 3/3, threads 16/17 RED, usage-migration 1/1, thread-cli 11/11, thread-launch 11/11, chat 23/23, stack-release 218/218 in 575 s. M1 against the fixed T2: rc=1, killed on an assertion, file restored, sessions 6/7 with T2 sage-2257 the only failure ("Missing expected exception: approval" at :204). Log gizmo-264-out/r12-survey/probes/M1.log. Mos accepted M1 killed by T2 alone at r12 (mos-1278 item 4). The threads.test red: :330 expected /only to its thread's holder/ (:341, from row 121, 2c16d6b93) and got the 3l trigger's "only to its session's holder". Mos ruled option A (mos-1278): delivery_same_thread in the base (schema.sql:300-306 at e479521d3) and delivery_same_session (3k-3l.sql:147-153) share the WHEN, the ops and the holder check, and differ only in taking the latest claim per session and in the text, so :330 keeps its strength. Commit 20 changes :341 to /only to its session's holder/ and nothing else in that file.
• r13 gate, 2cc34aef8 on e479521d3, manifest 65e04d27, Sage's CLEAR sage-2684. Start 2026-10-22 13:39:53Z, busy count 0, HEAD and digest printed and matched, blobs checked with sha256sum -c. Every count below has 0 fail, 0 cancelled and 0 todo.
  • Phase 1, the 20 touched files whole, one at a time, all 0 skipped, wall 600 s: bus account-migration 3/3, chief-of-staff 42/42, comment-migration 5/5, end-launch 7/7, gitea-migration 5/5, grant-migration 6/6, message-filter 6/6, name-migration 1/1, schema 1/1, sessions 7/7, spec-migration 1/1, tester-writes 8/8, thread-claims 6/6, thread-migration 3/3, threads 17/17, usage-migration 1/1; cli stack-release 218/218, thread-cli 11/11, thread-launch 11/11; webui chat 23/23.
  • Phase 2, suites whole: bus 827/827 (23 s), cli 837/837 (593 s), webui 345 pass of 346 with 1 skipped (55 s). The skip is the esbuild 0.28.1 editor rebuild (Duckworth named it in duckworth-0146; DEFERRED row 264a N2).
  • Phase 3, the 10 scripts/test-*.sh, all rc=0: auth 15, conductor 17, config 31, discord 81, extension-package 18, foundation 44 (36 s), land-work 86, queue 156 node tests and 28 suite checks, release 14, task 91. The worktree was clean after.
  • Phase 4: M1 killed by T2 at sessions.test:204 (6/7). M2 then failed with no assertion: T1 (:89) and T7 (:422) threw storage-refused from #refused (broker.mjs:4082) through request()'s catch (:4242), because the delivery_same_session trigger refused #delivery's INSERT. The run stopped there at 14:02:47Z, total wall 1374 s, and M3 and M4 did not run. 0 node processes left. Mos ruled option B (mos-1279): phases 1-3 carry and phase 4 reruns with M2's four edits.
  • Logs: gizmo-264-out/r13-run.out, with the per-file, suite and probe logs under gizmo-264-out/r13/single, r13/suite and r13/probes.
• r13p4, phase 4 rerun under mos-1279 at HEAD 84f53540d (2cc34aef8 plus commit 21, the M2 note in this file), Sage's CLEAR sage-2688 with the fourth edit confirmed in sage-2690. Start 2026-10-22 14:08:43Z, busy count 0. git diff --name-only 2cc34aef8..HEAD was this file only, and the non-BUILD.md blobs matched manifest 65e04d27. Kit gizmo-264-out/probes-264-r13p4.py (--check ok), each probe under timeout -k 10 300, each file restored and its sha checked. End 14:08:45Z, failures 0, 0 node processes left.
  • M1, the #agent generation fence set to false: killed, sessions 6/7, T2 sage-2257 at sessions.test:204 (assert.throws(fn, { code: 'not-holder' }, label)).
  • M2, four edits: the mt.session=? clause and its argument dropped from message.receive (broker.mjs:5251), delivery_same_session dropped from 3k-3l.sql and from schema.sql, and store.mjs:16 SCHEMA_SHA256 set to the sha256 of the mutated schema.sql. Killed, sessions 4/7, by T1 at sessions.test:89 (a1's receive got the second session's message). T7 also failed on its receive assertion at :422. T2 failed at :168, the trigger's own pin, which doesn't count as a kill under mos-1279. The kill rule: only an assertion in a test that exercises receive counts, never a thrown error.
  • M3, generation counted over every claim row in 3k-3l.sql: killed, sessions 6/7, T7 at sessions.test:390 (the thread_claims generations).
  • M4, thread.claims back to the latest row per thread: killed, thread-claims 5/6, T6 at thread-claims.test:133 (two held sessions list as two rows).
  • Logs: gizmo-264-out/r13p4-run.out and gizmo-264-out/r13p4/probes/M1.log to M4.log.