The running pre-G indexer publishes mesh-catalog's packages only while every package directory it published before is
in the tree; G removed this one, so mesh-catalog's packages are never published (2026-11-13). An empty package keeps
the directory; it goes once G's indexer runs.
Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h
mesh/check checking 53351dd30df2 on b1125c02cfe6 | novox/mesh-catalog#675 in group feat/47-G-join11
mesh-conditions keeps G's form: the keeper reads no observer's state (no reads, no Observers list), so main's zfs entry there goes. The zfs follower says its findings through G's findings writer over its keeper: the keeper gains the publish of the writer's three events on the finding stream finding-events and the hear of mesh-conditions.findings-asked on its own durable, nothing else; each pool or device not ONLINE is scope module, id zfs.<pool>.<device> (the device's own name), kind not-online, on the node. The manifest asks its state findings by template in requires (G §529, §577), and gains the finding-events stream and the consumes, and the keeper's bus the three events and the consumes.
Builds: design 47 G §383, §384, §387, §529, §577, A-339, A-340, A-341, A-342; design 42 zfs-owns-zfs §27, A-32, A-37, A-39, A-41
Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h
mesh/check being carried to 0041b69d1736 on 32f1566cc879 | from 117f933dacf0, mesh-delivery 7221a1e5cd7f, mesh-host 0193949efe9f, mesh-sdk e42b9491c93…
The validator refused zfs and mesh-conditions: mesh-conditions reads zfs.findings, which zfs had moved to bus state in requires, where the new form has no readers (ADR 0596 section 2). The keeper process's bus.state keeps naming findings. The manifest test holds it.
Builds: design 42 zfs-owns-zfs A-46 (A-32, 26, 27)
In the test's temporary directory, or /tmp when the socket path would pass 100 characters, so a long TMPDIR cannot fail the bind.
Builds: design 42 zfs-owns-zfs §18, A-37
Issue 1979, blocking: a date-bound test. The warrant dated 2026-10-29 fell out of the listing's 14 days on 2026-11-13, failing every mesh-catalog check.
Builds: design 42 zfs-owns-zfs (the group's check)
The group's check failed TestRulesBus/NoCatalogueManifestNamesAnInstallation: 11 values name an installation (the vendor sites in the package's zed-functions.sh, resources[13]).
Builds: design 42 zfs-owns-zfs §14, A-2
The group's check failed TestOnlyRootOpensTheKeepersSocketAndANeedlessKeeperIsTheBusDown and TestAKeeperThatDoesNotAnswerIsWarnedOnce: stat /var/tmp: no such file or directory.
Builds: design 42 zfs-owns-zfs §18, A-37
The group's check failed TestEveryControllerKindHasItsHome: the reader zfs's findings are not read by the keeper.
Builds: design 42 zfs-owns-zfs §27, A-32
mesh/delivery-group group feature/1979-zfs-owns-zfs rejected: composed together: the checker's verdict at the members' heads (03f2ebff6ed0): unit: mesh-conditi…
mesh/check failed (9): unit: mesh-conditions/cmd/mesh-conditions.TestEveryControllerKindHasItsHome: the rea…; and 8 more | d15502f3650d on 117f933dacf0
Builds: design 42 zfs-owns-zfs §13, §24, lead answers A-45, A-43
The tools say every event of §25 (snapshot.taken.person, scrub.requested and the others) with mesh/stream.publish on the
stream events, never stdio.Emit; the hand acts' 30 s wait reads the mark (stream.fill) before the act starts, then
stream.read from the next sequence, for at most HandWait.
Builds: design 42 zfs-owns-zfs §25, §24, lead answers A-42, A-12
A failed keeper call in a root process (hand acts, forget, Paused, every call) now adds one warning that the bus is
taken as down, instead of being dropped silently. RunKeeper closes the connection acct.Dial opens when the keeper
stops; the message id's comment says it is nanotime-pid.
Builds: design 42 zfs-owns-zfs A-37
The three root processes declare no bus and reach the keeper's socket; the module invokes the service manager's start. The judge refuses the keeper's bus emits and state until the validator accepts what the module asks for in requires (A-38).
Builds: design 42 zfs-owns-zfs §25, §26, §27, §28, A-6, A-19, A-36, A-37, A-38
Renamed TestTheBundleRunsOnlyTheFormsOfADR0679: each root form is held to its whole argument list, no verb the decision never allows, zgenhostid only with the parsed hostid, a device only as cache or log.
Builds: design 42 zfs-owns-zfs §19
The manifest declares zfs-utils and zfs-dkms, renames scrub-pool to pool, and declares every new value not managed until set; its config file is ${config-json}, the options file, ZED's folder, rc, functions, handlers and drop-in each under their condition, the three ZFS units, the apply (run-once, restarted by its config file) and the run before the distribution's scrub and trim timers. One commit: the three subtasks change the one file module.json.
Builds: design 42 zfs-owns-zfs §6, §7, §8, §9, §11, §12, §13, §14, §15, §18, §20, A-1, A-2, A-3, A-7, A-14, A-15, A-16, A-23
zfs_config also says what the module says before it leaves a node (Z17): the next load of the kernel module uses ZFS's defaults, the three units and /etc/hostid stay.
Builds: design 42 zfs-owns-zfs §28, §30, §10, A-31, A-35
A trim schedule of weekly or monthly with no trim-day or trim-time is one refused value naming it; a keep count of 0 is that kind's none: the existing scheduled ZFS snapshots are kept and a warning names them.
Builds: design 42 zfs-owns-zfs §20, §21, §22, A-33, A-35
A value of another form is refused before anything is written or run; absent and empty are not managed.
Builds: design 42 zfs-owns-zfs §9, §11, A-15, A-23
The node-engine writes a cron step (*/15) as a calendar systemd refuses, so
zfs-mesh-scrub.timer never started and the pool had no scrub schedule. A list
of minutes is written as *-*-* *:0,15,30,45:00, which systemd takes.
Builds: design 42 zfs-owns-zfs §18. Tests: 1979/AC1.
The validator refused the manifest: a bundle's env may not set what the runtime gives every tool bundle. The processes
night and awake keep theirs.
Builds: ADR 0192
Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h
intel-ucode failed an apply on a stale package database and stopped the delivery; an Intel machine
fails the unit by the image check and gets intel-ucode in the change that adds it. Tests: 1977/AC1
and the pinned order string adjusted.
Builds: L10 (issue 1977 note 6)
mesh-tools
jschoubben