The status view consumes seat:mesh-wants.views.asks, seat:mesh-wants.views.wants and
seat:mesh-module-assigner.views.assignments in place of the three mesh-delivery-assigner.views
entries, and its process takes each first view from the tool named for the state; its invokes
lose assigner_read_asks and assigner_read_assignments, and its tools program keeps
assigner_read_wants for a want's key and history reads (A-300).
Builds: design 47 G §717, A-300
Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h
The Delivery contracts module defines the seat mesh-delivery-view (scope mesh, grain whole,
ADR 0540): no verb, no seat event, no family, one state answers (template state, history 5,
view), one key form per kind of mesh-wants' asks with .view after it (A-299), its value the
answer (v, asking, option, words); seatgen writes its Go and TypeScript packages, and the
module's artifacts name them. The status view claims the seat (scope mesh, serves none), its
first-view tool answers (views.FirstViewTool, callers the teller, A-301) replaces
view_read_answers, and it deletes its answer once the ask's key has left asks. The teller
follows the answers by seat:mesh-delivery-view.views.answers and invokes nothing of the view's.
Builds: design 47 G §717, A-299, A-301
Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h
The builder, its tools bundle, the assigner (process and bundle) and the view's tools bundle answered
their seat list's again tool to the modules node-tools and mesh-healers. Their lists are now the
operator, seat:node-tool-runner and seat:mesh-healers, resolved by a holder function:
- meshcatalogclient's Branches.Claimant (moved from the builder's versions.HolderOf, which now asks it)
names the claimant of mesh-module-assigner from the trunk's half, and Branches.SeatHolders follows
that claimant's seat-holders view through the part's wiring. It drops the view and follows the new
claimant's on a catalog change, asks nothing on a timer, and answers seatlist.HoldersIn.
- the assigner answers HoldersIn from its own seat-holders picture (its world in the process, the
watched copy in the bundle).
The builder's and the view's manifests consume seat:mesh-module-assigner.views.seat-holders. The
assigner's seat-holders first-view tool answers both, by module as A-131 has it.
Builds: design 47 G A-298, A-295, A-296, A-210, A-131, §717, §616, §614
Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h
Each asks the seat mesh-broker's show for its finding-events entry (process.Binding, started without waiting), passes it
as the writer's Bindings and hears the seat's recreated and dropped; the watchman's one handler of the seats' events
hands those two to the binding, since a message has one taker. The teller, view and watchman manifests gain the invoke
seat:mesh-broker.show and consume mesh-broker.recreated and dropped. The forge bridge's and the watchman's whole tests
answer show and read the finding-written under the binding's subject.
Builds: design 47 G A-274, §529, §577, A-13
Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h
The view's process hears wait-held and wait-ended of every part (seats and modules; waits.go, manifest consumes) and keeps them in
its state waits under owner.step.node.module (viewstate/waits.go); view_tiers reads them through the tools bundle and names each
module's waits in the sayer's own words, {owner, step, node, on, bound, since, words} (tiers.go waitsHeld), beside the indexer's
pending revisions as the seat mesh-catalog's step take-in. No state of another module is read for a tier's waits.
Builds: design 47 G §512, §376, §498, A-242
view_tiers compares the kept assignment revision whose catalog carries the source revision with the one kept before it,
through the seat mesh-wants' verbs revision and difference (view/difference.go, tiers.go Tiers), and reads the tiers and each
module's after (module and edge kind) from the answer; the view orders nothing. The manifest invokes the two verbs.
Builds: design 47 G §512, §186, A-242
The view read the gate's state source and its history, fixed to the branch main. Each watched branch's source is now
the seat mesh-delivery's verb source given that branch, asked again on its source-moved; the source row and the event
delivered are per branch, a repository's reach is from the source of its modules' registration's first branch, laid
over the reach the view's own state kept at its start, and view_tiers given no revision answers per branch. The
manifest drops its read of mesh-delivery-gate.source and names the source answer's fields it relies on.
Builds: design 47 G §507, §512, §532, §558, A-173, A-225
Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h
The process and the tools bundle read the catalog half through Branches
(FollowBranchesProcess, FollowBranches) and Branches.Entry instead of one
view of a branch named in code; the module's value carries the entry's
manifest-digest bare and computes none. The manifest consumes
registration-changed and source-moved and invokes registrations, and
revision, entry and source in the long form with the fields relied on.
The built binary committed at the module's root goes.
Builds: design 47 G §532, §614, §558, §506, §578, A-103
Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h
The teller follows the view's answers by view_read_answers and
views.answers instead of reading the view's state; the view emits from
its marks state view-marks, as the other owners do.
Builds: design 47 G §431; lead answers A-175, A-178
Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h
The Approve per merge goes with G, so the gate's merge asks are no asks of
the view's; the teller's answers are followed by their views family
(teller_read_answers, then views.answers), never read from its state.
Builds: design 47 G §512, §431; lead answers A-172, A-175
Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h
Builds: design 47 G A-126, A-82 (the view part of fix9-6 70e5845b taken in with the manifest tests' reader of fix9-1 09839e5d, which the view's tests need)
Each drops its old state findings and stream <module>-findings for the requires entries findings (state, history kept) and finding-events (the three finding events, 7 days, 16 MiB); none is a foundation part (§529, A-30).
Builds: design 47 G §387, §529, §577, A-30
Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h
The view's process follows the trunk's catalog half (first view of the seat mesh-catalog's verb revision, then each
catalog-revision of branch main) and hands each changed entry to its model in the form of the value it always kept; its tools
read the newest trunk revision through the verb. The manifest invokes seat:mesh-catalog.revision and consumes
mesh-catalog.catalog-revision instead of the indexer's modules read tool and views family.
Builds: design 47 G §196, test 61
Claude-Session: https://claude.ai/code/session_01JG73KEq4zoDfM9WtYpcQgZ
mesh/check checking e0f510facb17 on b73315ffe05c | novox/mesh-delivery#166 in group fix/1966-bootstrap-no-packages
The running builder predates Go package artifacts ("refused kind: package of language go ... no build module
builds it"), so it can build neither the new builder, the grants module, the Go build module nor the checker:
each new part is needed before the others can be built or delivered. For the bootstrap of the registry
delivery, at the operator's word (19:4x, "do the temporary change"), the package artifacts leave the manifests of
the parts that run; the contracts and SDK modules, which run on no node, keep theirs. They come back in one change
once the new builder runs. Quick vs thorough: quick; the thorough fix is 47/G's tier order (issue 1921 note 80).
Claude-Session: https://claude.ai/code/session_01NcbgfFSnn24M3GcqttoU7i
mesh-delivery's sdk/firstview moved whole into mesh-sdk go/views (J3): the builder, checker, watchman, teller and view
follow each owner's state with views.ProcessReader.Follow(owner, state, tool, stream), naming the owner's read tool as
their invokes name it and its views family as the owner's manifest's `streams` names it ("indexer-views",
"assigner-views"); a refused Follow stops the start. Their beds serve the owners with viewstest.Serve and grant with
viewstest.Grants by the same names. The view's tools ask the owners' read tools by their literal names. The assigner
names its own views family and the indexer's itself (views.AssignerStream and IndexerStream are gone).
Every views.StatusTools call takes handacts.Recorder{Ask: stdio.Ask}: a first view asked again by hand is a hand act,
recorded through seat:mesh-hand-acts.hand-act, which the builder's, checker's, watchman's, teller's and view's
manifests now invoke (a row in each manifest test, each failed first).
Row (A2j's written-time switch): TestRunNeedsItsCredential "a want stood since the assigner's bus wrote it": the
watchman's want time (createdOr) is the time the owner's bus wrote the key, through ProcessReader's first view (failed
with createdOr ignoring the entry's time). sdk/go.mod: nats.go is indirect now.
Claude-Session: https://claude.ai/code/session_01JG73KJNrH5EgFXMKKYSrig
L3 (710c4032) arrives with it. Conflicts, each kept from both sides:
- assigner module.json, manifest_test.go, main.go, tools.go, integration_test.go: A2's first-view tools,
read tools and states beside L3's assigner_engine_reads and engine-reads; the two "consumes" lists
joined into one (the indexer's views and node-engine.manifest-reads-changed).
- builder module.json and manifest_test.go: A3's tools, states, consumes and invokes beside A2g's first
views (DLV-M1); one findings state (A3's, history 5) carries both; reads keep A3o's
mesh-delivery-indexer.packages until the builder follows it (join item).
- builder cmd main.go: rebuilt from A3's with A2g's changes applied (the reader follows modules,
manifests, candidates and placement; one calls connection; one findings bucket, A3's
health.FindingsBucket; FollowPlacement on a goroutine once placement's first view is answered;
buildFromModules in place of the start's settle). Tools main.go: A3's tools then the first-view tools.
- builder run.go: A2k's out-of-step on the end entry, then A3's numbering of a done build.
- view module.json and manifest_test.go: node_manifest_reads and seat:node-engine.manifest-reads beside
A2j's first views and read tools; one invokes list.
- indexer judge rules_test.go: L3's manifest-reads verb and event, without pull-waits (J1 dropped it).
- sdk/go.mod and builder go.mod: both requires kept.
Claude-Session: https://claude.ai/code/session_01JG73KJNrH5EgFXMKKYSrig
ADR 0615 §1, design 25 § 12.2: the manifest drops its twelve reads of the two owners' states and invokes
their twelve read tools. The process follows the six it watches (placement, wants, asks, candidates,
modules, taken) by the first view and then the views families (consumes), through firstview pictures, so
its watch code is unchanged; an owner that is down holds no other watch, and the unanswered first view is
the view's finding (states first-views and findings; tools view_first_views, view_first_view_again).
The tools keep their names, arguments and answers and ask the owners' read tools on each call
(view.OwnerRead; a read of many keys is one paged values read). DLV-V1: a table subtest answers each
tool through the owner's own Read over a fake state and matches what reading the state answered.
The owners' read tools answer no history of a key: indexer_module_history, indexer_heard and view_tiers'
times say so (an error, never none) until the read tool takes a history argument (a request to the join).
Claude-Session: https://claude.ai/code/session_01JG73KJNrH5EgFXMKKYSrig
A module's fingerprint takes the digests of the packages its last build
imported, so the published packages say why a merge moved a module or not;
the state needs a read tool like every other (ADR 0593 §2; D2).
Claude-Session: https://claude.ai/code/session_01NcbgfJ9Gum47zkFKWRaovL
The indexer wrote mesh-catalog's merge 9cdac09a back over the later 69056948,
rolling kernel and mesh-build-image back on the nodes: a merged message's
commit was written whatever the held one was. Before writing or deleting a
module's value, the indexer now asks the forge whether the merge contains the
held commit, keeps the held value when it does not and says so, and leaves the
message for redelivery when the forge cannot say. Each applied merged message
is said in one line with the modules written.
No tool showed what the indexer heard of FORGE nor a modules key's history
with times, so the cause could not be proven: the indexer now records each
FORGE message it handles (sequence, deliveries, times, commit, outcome) in its
state heard, read by indexer_heard, and indexer_module_history reads
modules.<module>'s kept values with their times.
Quick fix (Src order in writeOverlay) rejected: Src is 0 once the source moved
on, as here. Thorough fix chosen: the order is the forge's, on every path that
writes a module (merged message, take-in).
One commit for the branch feat/1126-nodes-compose of mesh-delivery: its 16 commits squashed so its history does not carry the 17.8 MB compiled mesh-delivery-assigner a commit added by mistake and a later one removed (issue 1577). The tree equals the former head ff6c038d. The operator allowed this rewrite of the feature branch on 2026-10-26.
The operator's question (how much are the build nodes used, is ace eligible) took six calls over four tools.
build_usage reads it from the bus's states: seats held (have), capacity (mesh-config resolved), pauses, the
build modules' steps by kind with left-running keys, the last hour and day with total and median time and time
at capacity, the running tries, and the backlog the view program reads from the seats' streams. A try now names
the asks it put, and the checker announces its tries readable, so the view tells a try's asks from a check's.
jschoubben