The grants part's composer gains Bucket.MaxMiB and Bucket.MaxBytes() (as mesh-sdk's buscompose has them): the bucket's stream is
created with that cap and an assertion raises a held one to it; an entry naming none keeps the mesh's cap, so no bucket of today
changes.
Builds: design 47 G §469, §695
Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h
The seat list's verbs saying `chunks: true` (ChunkVerbsOf, as KeptEventsOf) give the principal that answers the verb (a module's
own account for a seat it holds, the tool runner's for a carried module's) the publish of the chunk subjects and the
subscription to the acks, and an account naming the verb by name in `invokes` the reverse; a `*` entry none. The bus module's
keeper holds a standing grant of the restore subjects of the restricted streams, and only those.
Builds: design 47 G §681, A-45, A-60
Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h
The part adopts meshcatalogclient's branch follower on a views.ProcessReader holding its held finding writer (so its
view-waits is the reader's); the manifest of the build a want or a have names is the catalog graph's entry of that
fingerprint, not a builder's build (the `builds` read is gone); until every first view of the catalog half is in, the pass
keeps the list in force and only adds, says so in its log and in grants_first_views.
Builds: design 47 G §684, §444, §614, §191, A-5, A-52
Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h
The part's state `findings`, its finding stream `mesh-grants-findings` and the consume of `mesh-conditions.findings-asked`
are declared in module.json; the process makes mesh-sdk's held writer (Asked from the contract) and starts it once its
state is bound. Its other conditions stay said to the operator channel. gofmt of bus.go and grants_test.go.
Builds: design 47 G §388 (G-8), §529 (G-12), A-51 (G-20)
Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h
The definitions of definedEventsOf name mesh-sdk's three finding events and the seat mesh-conditions's findings-asked
(its generated contract's SubjectFindingsAsked). readRunningWhole is deleted: the part's durable on running is heard through
process.Account.HearSeatEvents with process.OnRead. The bootstrapped definitions name the kept events before the seat list is
read, so the part's first durable never filters running on EVENTS (a held consumer only gains filters).
Builds: design 47 G §556, §641, §644, A-3, A-13, A-17, A-19
Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h
A seat definition's events of the seat list, and mesh-sdk's four finding events (views.FindingSubjects), so a `*` emitter before one reaches each declaring module's own stream; any other `*` entry stays the shared stream's.
Builds: design 47 G §386, §474, §644
Claude-Session: https://claude.ai/code/session_01JG73KEq4zoDfM9WtYpcQgZ
A release writes an ask to compose; the pass says wait-ended how released once, and a wait whose grant came says how ran. The events go through Conn.EmitSeat.
The late finding is the watchman's (design 47 G §269), not written here.
Builds: design 47 G §276, §266, §269, G-20 A-10, A-12
Claude-Session: https://claude.ai/code/session_01JG73KEq4zoDfM9WtYpcQgZ
Kept in its own state, clock-from the start of this version's first pass, the bound 10 minutes. The seat's wait-held and
wait-ended events and acting-part-late are not built (see the report).
Builds: design 47 G §276, §266, §269 (G-20 A-7); A-6 needs no change: the part reads the wants view and consumes no wanted
Claude-Session: https://claude.ai/code/session_01JG73KEq4zoDfM9WtYpcQgZ
Until the read ends the part acts on none of running and grants_first_views names the stream waiting; an event older by at
than the one held changes nothing. The ordered consumer's grants are not built (a question to the lead).
Builds: design 47 G §556, §199
Claude-Session: https://claude.ai/code/session_01JG73KEq4zoDfM9WtYpcQgZ
SeatsToPassOn takes what each node-engine's running said and a reader of entries, Assignment names the module and its
branch, Hearing takes the defined-events function (nil here: GR4's). HearRunning keeps a stopped running with no
fingerprint and no manifest, and a stopped module claims nothing on its node.
Builds: design 47 G §404, §459, §199, §386 (nil defines none)
Claude-Session: https://claude.ai/code/session_01JG73KEq4zoDfM9WtYpcQgZ
The part binds its own durable on the node-engine's kept stream (HearKept, tried at every wake until the pass has made it),
the seat's holders are read from the manifest of the digest each node says it runs, and a node-engine's account is granted its
own node at the part its definition names (running.<node>.*) and its durable on the kept stream by name.
Claude-Session: https://claude.ai/code/session_01JG73KEq4zoDfM9WtYpcQgZ
Builds: design 47 G §199, §249, §309
An answer no entry of which carries binding gets, for a key-value or object-store
entry whose settings hold the bus object its bus-name names, the binding composed
from the answer's own fields; a stream, a ledger and an entry not held stay
unbound and are logged once per answer; grants_first_views shows composed and
unbound (1966/AC203-3..n). An answer where any entry carries binding is applied
by §4 alone.
Builds: design 25 bindings-first-view §9, §4, §6, §7, §8
Claude-Session: https://claude.ai/code/session_01JG73KEq4zoDfM9WtYpcQgZ
mesh/check checking 8501968154b4 on 8f5cbce46845 | novox/mesh-delivery#203 in group fix/1966-bindings-first-view
No pause between two failed asks runs past the bound (two minutes): the ask at the bound raises
first-view-unanswered and releases the held events, well inside the events consumer's five deliveries
of 30 s. An answer's binding is taken as it lists it, with no fallback to an event's types (§4).
Checks: the unit start row requires the raise at exactly the bound; the whole test says the created
before the bound and requires the condition raised when it is applied (fails without the process's
hold), and waits on the kept first-views status for the held answer instead of a sleep.
Builds: design 25 bindings-first-view §3, §4, §5, §8 (hq d0760629, PR 543)
Claude-Session: https://claude.ai/code/session_01JG73KEq4zoDfM9WtYpcQgZ
The process hands an event of the seat mesh-broker to BindingsView.Hold, which
applies and acknowledges it after the answer or past the bound, so a restart
finds it delivered again (one delivered again while held keeps its place by its
stream sequence). Unit rows: the answer's bucket differs from the held created's
and the held event's stands. Whole test: an answer that lists a binding dropped
since its ask does not write it back (fails without the check). Neutral caller
name in the by-hand asks.
Builds: design 25 bindings-first-view §3, §4, §8 (hq d0760629, PR 543)
Claude-Session: https://claude.ai/code/session_01JG73KEq4zoDfM9WtYpcQgZ
At each start and on grants_first_view_again with state bindings, the part asks
list, writes the bindings the answer carries that it holds none of or another of,
keeps and raises binding-unlisted for those the answer omits, never writes over
an event heard since the ask, holds the seat's events until the answer or the
bound, and raises first-view-unanswered naming mesh-broker and list past two
minutes while composing as before. grants_first_views shows the first view
beside the others. Cases are rows and subtests of the existing tests.
Builds: design 25 bindings-first-view §1, §3, §4, §5, §6, §7, §8 (hq d0760629, PR 543)
Claude-Session: https://claude.ai/code/session_01JG73KEq4zoDfM9WtYpcQgZ
mesh/check checking a78c5700fdf4 on fb69c8dee691 | novox/mesh-delivery#188 in group fix/1966-requires-state
The grants part wrote a binding into a membership on the bus module's
created, but granted its subjects to no account but the ledger's, so
distribution's program and the tool runner carrying it were refused their
own key-value, object store and stream entries (issue 1966, ADR 0595 §1,
design 25 § 12.2). The kept bindings now reach Declared in the same pass that
writes them into the membership, and one function, boundOf, grants each to
the module's own account and the tool runner, as its old section is granted;
a process's bus.state names a key-value entry as an old state. The composed
membership carries the bindings, so grants_membership's two sides agree.
Claude-Session: https://claude.ai/code/session_01NcbgfFSnn24M3GcqttoU7i
The operator, 2026-11-09 09:07: raise only. The grants part's assert raises it, says it in its asserted event and the
journal with the old and new cap, and grants_assert asks it by hand.
Claude-Session: https://claude.ai/code/session_01NcbgfFSnn24M3GcqttoU7i
The markers and the values of the lists taken away before the purge still fill
the state user-list. Before its first pass the process purges every
sealed-grants key whose last operation is a delete or purge marker, and every
user's key of a list the index of kept lists does not name; never a kept
list's key nor another key of the state, and nothing when the index cannot be
read. It logs the counts and the state's bytes before and after.
Claude-Session: https://claude.ai/code/session_01NcbgfFfQ4Z9UE5jK32PmE5
A key-value delete only adds a marker: every value of the per-user keys of the
lists older than the two kept stayed in the state user-list's stream, which
reached 94% of its 64 MiB cap on 2026-11-08 (5,968 keys, 13,228 values). At the
cap the bus refuses grants' next write of the sealed list and deliveries lock.
The part now takes those keys away through a purger on the process's own
JetStream connection, a publish to the key's own subject the account already
writes on; the tools, with no purger, still delete.
Claude-Session: https://claude.ai/code/session_01NcbgfFfQ4Z9UE5jK32PmE5
Since 16:39 the running assigner cannot answer its wants page within a call's
bound, and the failed wants read held the whole user list, so no new build got
its credential. As the assignments view already does, an unanswered wants view
now composes what runs from each have's fingerprint, is said as a gap that is no
failed read, and keeps the pass to one that only adds (keepsLoaded), so the list
is held only where it would take from a loaded user.
Claude-Session: https://claude.ai/code/session_01NcbgfFfQ4Z9UE5jK32PmE5
The channel refuses a raised condition whose explanation does not open with
"Needs you: " and its needs, so seven of grants' conditions, among them
first-view-unanswered, never reached the operator. One helper now writes both,
and every condition the unit tests say passes the channel's own check.
Claude-Session: https://claude.ai/code/session_01NcbgfFfQ4Z9UE5jK32PmE5
mesh/check failed (2): integration: mesh-delivery-assigner/cmd/mesh-delivery-assigner.TestAProposalIsAnswer…; and 1 more | 5452fa92a731 on f9cadbfdbb93
A running build older than the trunk lost reads it still uses (the vault's read of the assigner's placement), failing every node-engine pass. Memberships now come from the union of the have's build, the want's and the trunk's manifest.
Claude-Session: https://claude.ai/code/session_01NcbgfFfQ4Z9UE5jK32PmE5
The grants part built the node-engine's declaration with its consumes alone,
so a node's account was granted none of the engine manifest's invokes: ace's
engine could not publish mesh.seat.mesh-catalog.call.seat-definitions.node~ace,
read no seat list and composed nothing new. And its consumes of
mesh-catalog's seat-definition events were granted on the emitter's subject
only, where the engine subscribes the seat's (ADR 0636 §4).
The engine's declaration now carries its invokes and the seats it watches,
split by the same consumedOf a placed module's consumes are; the node's
account is granted the invokes as a module's are (in its own caller token
by callerNamed) and the watched events on each seat's subject by the same
watchedEvents a module's use. Its consumes stay granted on the emitter's
subjects too, so nothing granted before is taken away.
Claude-Session: https://claude.ai/code/session_01NcbgfFfQ4Z9UE5jK32PmE5
Fault: the new assigner composes a membership that drops the placement seats and adds its state view-marks. The partial pass
kept the published one whole, so the assigner's tools never got view-marks, its assignments view never answered, and the
pass never left its partial state (third bootstrap loop of the kind after #170 and #171).
Kind: the bootstrap hold freezes whole entries, so a grant needed to end the hold is never given.
Quick fix: special-case the assigner (or let additions through for it). Rejected: the next module that gains a state meets the same loop.
Thorough fix: while a pass keeps what the bus loaded, publish the union of the membership last published and the one composed
(every list, deduplicated, published entries first; the private network, contributions and bindings the pass's), published
when it differs; the pass says what it kept beyond the composed one. The user list already unions (KeepLoaded), additions pass there.
Claude-Session: https://claude.ai/code/session_01NcbgfFfQ4Z9UE5jK32PmE5
Review round 1 of issue 1966's keep-what-is-loaded fix.
- KeepLoaded intersected the denies, and the composer gives every composed user an empty
deny, so a user in force with a wide publish and a deny was sealed with no deny. The
union of every deny any list says is kept now, and Losses counts a deny dropped.
- A pass composing part of the mesh (the seat list unread, or placed by the haves) no
longer narrows a published membership: one whose published value serves, hears or gives
more than the pass composes is kept as published and said so (not_published), so a tool
runner or a seat holder goes on serving what it serves while keeping its login.
Claude-Session: https://claude.ai/code/session_01NcbgfFfQ4Z9UE5jK32PmE5
Issue 1966: the list sealed 2026-11-07 23:09, composed while the seat list was unread
(only the bootstrapped seats compose), took the node seats from the tool runners, the
vault's reads from the node-engines and the seat queues from the build modules, and left
out ledger.novox.mesh-knowledge.
- While the seat list is unread (the gate's MayAct with no seat) or a pass is placed by
the haves, each user of the loaded list and of the list in force is sealed with the
union of what the pass composes and what those lists give it (publish, subscribe,
responses; a deny only where every list saying one denies it), kept the way a refused
principal is; the users so kept are the pass's kept_loaded.
- In such a pass a list that still takes a permission from, or leaves out, a loaded user
is held (user-list-held), naming each user and how many permissions it loses.
- A held module keeps its ledger account, ledger.<node>.<module>, with its other users:
heldModuleUsers matched <node>.<module>[.<process>] only, which dropped the ledger user.
Claude-Session: https://claude.ai/code/session_01NcbgfFfQ4Z9UE5jK32PmE5
Bootstrap only (issue 1966, notes 63 and 64; the operator chose it 2026-11-07 22:19,
bending ADR 0567 §9 for the bootstrap). An assigner that serves no first views answers
no assignments, so the grants part placed nothing and wrote no grant, membership or
bucket for anything, not even for the assigner that would serve the view.
When the assignments read fails and the haves read, each module is placed on the node
whose have says it runs (any phase but removed), the bus node found among them, and what
runs composed from each have's fingerprint instead of the assigner's wants. Said as a gap
naming the fallback, and kept as Inputs.ByHaves: such a pass retires no account and deletes
no withheld hearing (ReadFailures), and seals no list that drops a user of the list in
force or of the loaded list (holdsBack). Once the view answers, the fallback is unused.
Quick fix; the thorough one stays the module-graph edge (the assigner's views before the
grants part that reads them) in the delivery plan.
Claude-Session: https://claude.ai/code/session_01NcbgfFfQ4Z9UE5jK32PmE5
Dropped since the hear was removed (ADR 0625 §4); the golden user list and the grants case now hold the node user's subscriptions. The indexer's open-tries comment says it refuses an answer without the key.
Claude-Session: https://claude.ai/code/session_01NcbgfFSnn24M3GcqttoU7i
jschoubben