Make the grants part one of G's observers, so its waits are findings
mesh/delivery closed: a newer head of the same pull request
mesh/check pass 27ec6f8500da on f1fe609b3e85 | unit 43 run, 0 kept, 1 skipped | integration 43 run, 0 kept, 1 skipped | composition passed in 91s on 3…

G-4 §200 already had the grants part write view-waits as a finding, while
G-8 §387 left it out of the observers that say findings as events. Adding
it, with its state findings and finding stream in its old sections, lets
the bindings first view's two conditions move to findings at G's delivery.

Claude-Session: https://claude.ai/code/session_01JG73KEq4zoDfM9WtYpcQgZ
This commit is contained in:
2026-11-11 10:08:04 +01:00
parent c098518cc8
commit 27ec6f8500
2 changed files with 12 additions and 5 deletions
@@ -93,10 +93,11 @@ choice, to the bus module's. Each choice below says so.
names the owner and the tool of its other first views, and it then takes the events from its durable consumer as names the owner and the tool of its other first views, and it then takes the events from its durable consumer as
they come, so the live path never waits on the first view. It keeps asking, from 10 seconds, doubling, at most they come, so the live path never waits on the first view. It keeps asking, from 10 seconds, doubling, at most
every 5 minutes, the backoff the bus module keeps for its own first view (design 25 bus-state §1); the answer every 5 minutes, the backoff the bus module keeps for its own first view (design 25 bus-state §1); the answer
clears the condition. This form holds until milestone G of design 47 changes how the grants part says what it clears the condition. This form holds until milestone G of design 47 is delivered; from then the grants part, one
finds; G's part does not yet say whether the grants part says these two conditions as findings on a stream of its of G's observers (design 47 G §387), writes `first-view-unanswered` and `binding-unlisted` (§4) as findings in its
own (design 47 G §383, §387), which is a design question of that milestone. Why: the design's choice under ADR state `findings`, said as `finding-written` and `finding-cleared` on its finding stream (design 47 G §383) and
0615 §6. How it is checked: §8. stated at its start (§384), naming the same things. Why: the design's choice under ADR 0615 §6. How it is checked:
§8; from G, G's own checks of §383 and §387.
- §6 **The tools that read and steer it.** `grants_first_views` shows the first view `bindings` beside the others: - §6 **The tools that read and steer it.** `grants_first_views` shows the first view `bindings` beside the others:
the seat and verb (`mesh-broker.list`), when it was asked and answered, how many entries the answer listed, how the seat and verb (`mesh-broker.list`), when it was asked and answered, how many entries the answer listed, how
many bindings it wrote and rewrote, the bindings it found unlisted, how many asks and hand acts, and whether its many bindings it wrote and rewrote, the bindings it found unlisted, how many asks and hand acts, and whether its
@@ -121,7 +121,13 @@ record says so in its Why. Round 3 of the review by architectural domain (2026-1
`minio` and `nfs-server` in mesh-catalog; `mesh-delivery-assigner`, `mesh-delivery-builder`, `mesh-delivery-checker` (until its `minio` and `nfs-server` in mesh-catalog; `mesh-delivery-assigner`, `mesh-delivery-builder`, `mesh-delivery-checker` (until its
removal, ADR 0667 §12), `mesh-delivery-indexer`, `mesh-delivery-teller`, `mesh-delivery-view`, `mesh-delivery-watchman` and removal, ADR 0667 §12), `mesh-delivery-indexer`, `mesh-delivery-teller`, `mesh-delivery-view`, `mesh-delivery-watchman` and
`mesh-enrolment` in mesh-delivery; `mesh-host`, the node-engine; `node-tools`, the tool runner, in mesh-tools; and the modules that gain `mesh-enrolment` in mesh-delivery; `mesh-host`, the node-engine; `node-tools`, the tool runner, in mesh-tools; and the modules that gain
findings in G, the runner (`mesh-delivery-pipeline`, §355) and the forge bridge (`mesh-delivery-forge-bridge`, for `branch-unprotected`, §17). The manifest findings in G, the runner (`mesh-delivery-pipeline`, §355), the forge bridge (`mesh-delivery-forge-bridge`, for `branch-unprotected`, §17) and
the grants part (`mesh-grants`). The grants part, a foundation part, gains in G its state `findings` and its finding stream in its old
`state` and `streams` sections (ADR 0595 §10), and writes there, instead of raising them through the operator channel, its findings
about what it waits for: `view-waits` (§200), `first-view-unanswered`, `first-view-empty` and `binding-unlisted` (design 25
bindings-first-view §4, §5), each naming what it named as a condition; its other conditions stay as they are. Why the grants part:
§200 already has it write `view-waits` as a finding, and a part that says what it waits for only from its process's
memory is the kind §384 ends (lead-47, 2026-11-11, taking the design writer's recommendation). The manifest
validator refuses a manifest declaring the state `findings` without that stream and that `consumes`. Why: an validator refuses a manifest declaring the state `findings` without that stream and that `consumes`. Why: an
observer whose stream is missing says nothing the keeper hears; the list is read from main on 2026-11-11 and the rule observer whose stream is missing says nothing the keeper hears; the list is read from main on 2026-11-11 and the rule
is the design's choice. How it is checked: unit (manifest validator), a manifest with `findings` and no finding is the design's choice. How it is checked: unit (manifest validator), a manifest with `findings` and no finding