Issue 176: the console's build tool neither waits nor registers, and does not take a forge path

2026-10-01 00:29:05 +02:00
parent fe706af63a
commit 93f828c5eb
1 changed files with 54 additions and 0 deletions
@@ -0,0 +1,54 @@
+---
+status: located
+opened: 2026-10-01
+located-in: [mesh-controller cmd/mesh-controller/seatverbs.go (argvFor, "build": `--wait 0`, no `--self`), mesh-controller cmd/mesh-controller/main.go (builds.Built records a build and registers nothing)]
+fixed-by:
+amended-design:
+---
+
+# 176 — The console's `build` tool neither waits nor registers, and does not take a forge path
+
+## What was observed
+
+Eight media modules held by the mesh had not been rebuilt after their manifests changed, because a
+merge rebuilds only the modules whose recorded source is the merged repository and theirs was another
+one. Asked through the console — the controller's `build` tool, served on its seat
+([ADR 0154](../../02-DECISIONS/0154-the-meshs-own-verbs-are-the-controller-seats-tools.md)) —
+with the repository given as its path on the forge, the way the tool's own description invites:
+
+- every call answered at once with *no build machine answered within 0s … the work is queued*;
+- the builder, asked in the same breath, failed each one with *cannot clone novox/mesh-catalog*: the
+  path was handed to `git clone` as written, because the tool never says the repository is a path on
+  the forge holding the git seat (`--self`), which the command line requires for that form;
+- given the repository's URL instead, the call still answered within zero seconds, the build ran on
+  the builder, its result was heard and recorded — and the module was **not registered**: what hears a
+  finished build records the build and stops; only the caller that waited would have parsed the
+  manifest and registered it, and the caller had gone.
+
+So the console can start a build and never learn its outcome, and a build it starts cannot change
+what the mesh holds. The tool's description — *have the build machine build a repository and record
+what came out* — is true of the build record and false of the module.
+
+## Why this is here
+
+The seat verb was written as fire-and-forget, deliberately (`--wait 0`), so that a tool call over the
+bus does not sit for the minutes a build takes. That reasoning moved the wait but not the work that
+followed it: registration lives in the waiting caller, not in the path that hears the result. The two
+halves of "build" — asking, and taking in what came back — are split across the command and the
+event handler, and the tool reaches only the first.
+
+The forge-path form is a second, smaller gap: the seat verb maps three arguments and forgets the flag
+the same command needs to read one of them.
+
+## What would be right
+
+Registration belongs where the result is heard, once, so a build's outcome reaches the mesh whoever
+asked and whether or not they waited — the same rule as an announcement's builds. The tool then
+answers with what it can say at once (asked, queued, or refused) and `builds` says the rest. A
+repository given without a scheme is a path on the git seat, and the verb says so.
+
+## Open questions
+
+- Should a tool call be able to wait at all? A builder answers in minutes; the console's transport
+  holds a call for a bounded time. If not, the tool needs a way to follow one build — which is the
+  builder's missing progress (no tools, no events) named in the console's review of 2026-10-01.