From 27ec6f8500dacccf7e3c53de1cc38affa5a32477 Mon Sep 17 00:00:00 2001 From: jochen Date: Wed, 11 Nov 2026 10:07:47 +0100 Subject: [PATCH] Make the grants part one of G's observers, so its waits are findings MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- 03-DESIGN/01-to-be/25-milestones/bindings-first-view.md | 9 +++++---- .../47-milestones/G-8-findings-heard-as-events.md | 8 +++++++- 2 files changed, 12 insertions(+), 5 deletions(-) diff --git a/03-DESIGN/01-to-be/25-milestones/bindings-first-view.md b/03-DESIGN/01-to-be/25-milestones/bindings-first-view.md index 76a32505..d20878ad 100644 --- a/03-DESIGN/01-to-be/25-milestones/bindings-first-view.md +++ b/03-DESIGN/01-to-be/25-milestones/bindings-first-view.md @@ -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 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 - clears the condition. This form holds until milestone G of design 47 changes how the grants part says what it - finds; G's part does not yet say whether the grants part says these two conditions as findings on a stream of its - own (design 47 G §383, §387), which is a design question of that milestone. Why: the design's choice under ADR - 0615 §6. How it is checked: §8. + clears the condition. This form holds until milestone G of design 47 is delivered; from then the grants part, one + of G's observers (design 47 G §387), writes `first-view-unanswered` and `binding-unlisted` (§4) as findings in its + state `findings`, said as `finding-written` and `finding-cleared` on its finding stream (design 47 G §383) and + 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: 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 diff --git a/03-DESIGN/01-to-be/47-milestones/G-8-findings-heard-as-events.md b/03-DESIGN/01-to-be/47-milestones/G-8-findings-heard-as-events.md index e76ea41b..0eb13026 100644 --- a/03-DESIGN/01-to-be/47-milestones/G-8-findings-heard-as-events.md +++ b/03-DESIGN/01-to-be/47-milestones/G-8-findings-heard-as-events.md @@ -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 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 - 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 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