1 changed files with 18 additions and 0 deletions
@@ -52,6 +52,24 @@ the forge's business to know.
 The forge's module already declares the event. The build machine declares that it consumes nothing.
 ## What the trigger cannot be
 **Not one build per changed module.** The modules form a graph: several are built from one
 repository, and some are the base another is compiled on — a runtime image, a compiler base, a
 repository whose context a second module builds from. Firing a build for each changed module
 independently would start work that cannot succeed yet and produce a failure per dependent, for one
 cause.
 Observed while catching the mesh up by hand on 2026-09-27: a compiler base had to move before
 anything compiled against it could build, and when it failed, the right behaviour was for its
 dependents to wait rather than each fail the same way. Fifteen modules shared the cause. A trigger
 that reports it fifteen times has buried it.
 So whatever reacts to the forge's event resolves what changed into an order, builds the bases first,
 and holds a dependent while its base is unbuilt or failed. That is a larger thing than "rebuild what
 the commit touched", and knowing it now is cheaper than discovering it from fifteen identical
 failures.
 ## Open questions
 - Is "the source moved" still a thing a person can assert by hand once the event path exists, or does