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

03-DESIGN/01-to-be/18-building-a-module.md

@@ -282,7 +282,10 @@ One build is one subject. A reader follows it by subscribing that subject and no
 events stream keeps it for a week, so `builds --log <id>` — on the command line and as the
 controller's seat verb through the console — reads it back afterwards. `builds` lists every build's
 id beside it, and `build` says the id it asked with. The mesh keeps no second copy: the stream is the
-log. A viewer of builds, when one is built, is a subscriber over these subjects and the outcome; the
+log. The console's `build` tool asks and answers at once with the id; the outcome is taken in — the
+build recorded, the module registered with its source — by whoever hears it, the waiting command or
+the daemon following the role's event, so a build nobody waited for still reaches the catalogue
+([issue 176](../../04-ISSUES/176-the-consoles-build-tool-neither-waits-nor-registers/00-report.md)). A viewer of builds, when one is built, is a subscriber over these subjects and the outcome; the
 builder needs nothing more for it.
 
 *How it is checked:* the holder's grant is exactly `started`, `built` and `log.*` (broker test); a

04-ISSUES/176-the-consoles-build-tool-neither-waits-nor-registers/00-report.md

@@ -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:
+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:
+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.