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

2026-10-01 01:27:49 +02:00
parent 3627f7e9db
commit f841845b0d
2 changed files with 27 additions and 4 deletions
@@ -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