novox/hq
3
0
Fork 0
Code Issues 2 Pull Requests 1 Releases Wiki Activity

Issue 176 resolved: a build is taken in where its outcome is heard; the build tool answers with the id

Browse Source
This commit is contained in:
jschoubben
2026-10-01 01:27:49 +02:00
parent 3627f7e9db
commit f841845b0d
2 changed files with 27 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
04-ISSUES/176-the-consoles-build-tool-neither-waits-nor-registers/00-report.md
+23 -3
View File
@@ -1,9 +1,9 @@
---
status: located
status: resolved
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:
fixed-by: mesh-controller PR 179 (one take-in for a build's outcome, called by the waiting command and by the daemon; `--wait 0` asks and returns the id; the seat verb says `--self` for a forge path); ADR 0157 (mesh-controller PR 178) gave the tool something to hear
amended-design: 03-DESIGN/01-to-be/18-building-a-module.md
---
# 176 — The console's `build` tool neither waits nor registers, and does not take a forge path
@@ -52,3 +52,23 @@ repository given without a scheme is a path on the git seat, and the verb says s
- 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.
## Resolved, 2026-10-01
Registration moved to where the outcome is heard. One function takes a build's outcome in — records
the build, parses the manifest, refuses a definition that names an installation, registers the module
with its source as the seat and path the request carried and the outcome echoes — and both the
command that waited and the daemon that follows the role's `built` event call it. So a build asked
for by anything that could not wait reaches the catalogue the same as one asked for by hand, and the
same outcome heard twice writes one row twice with the same values.
The tool keeps not waiting, and says so: `build --wait 0` publishes the work and answers with the
build's id, and `builds --log <id>` follows the build line by line ([ADR 0157](../../02-DECISIONS/0157-a-build-says-what-it-does-on-the-bus-as-it-happens.md)),
which is what a tool call over the bus can do in the seconds it has. A repository given without a
scheme is said to be a path on the git seat, so the forge-path form the tool's description invites
now works.
The open question is answered by the shape: a tool call does not wait; it asks, gets the id, and
follows. *How it is checked:* the shared take-in against a raised store — registered with the seat
source, a definition naming an installation recorded and refused, a failure said in the builder's
words — and the tool's mapping of a forge path against a URL.