4 Commits

Include renames

Author	SHA1	Message	Date
jochen	3d05d74400	Publish only a commit on its module's trunk; post a pull request's change plan (hq ADR 0238) ... One commit, one plan: a commit off the trunk — a pull request's head, a branch built by hand, a rebuild or replay of one — is for checking. The build seat reads from its clone which branches hold the commit, and the controller records and never registers a build whose commit is not on the branch the module follows (the repository's default for a new one), so nothing off the trunk can be sent. A pull request's check now carries its change plan, computed by the planner: what a merge would build in which order, what each machine would receive, and what is not an ordinary send — the bus step, a module waiting for a person, a provider's consumers.	2026-10-06 22:49:55 +02:00
jochen	58ebe590a5	Ask the planner what a pull request reaches; map a changed file onto modules in one place (hq ADR 0238) ... touchedBy is now the only mapping of changed files onto modules — touched, added, and read by no build — and reachOfMerge the planner's whole answer with the dependency walk. The merge handler, the plan what-if, the merge gate's width and composition, and a pull request's check all ask it, so planning and gating cannot disagree. The gate composes the definitions of the modules a merge would rebuild or add, not every one in the tree, and the check says the dependents a merge would build after them.	2026-10-06 22:34:57 +02:00
jochen	b24bb030ec	A changed file touches exactly the modules whose build reads it (hq issue 280, ADR 0237) ... The builder reads a module's own directory (the repository for one built from its root) and a repository its recipe packages, nothing else. A file in no module's directory was read as shared code and rebuilt everything built from the repository: 103 modules for a merge-check.sh added at the catalogue's root. It now touches nothing, in the merge handler, the release planner and the pull request's check alike, and the gate says so.	2026-10-06 22:34:57 +02:00
jochen	14127d4878	Let the module graph decide what a pull request's check runs, in two layers (hq ADR 0237) ... Every pull request the forge announces is mapped onto the mesh's module graph by the merge handler's rule (issue 278): touching a module — or adding one — runs the gate (mesh/merge-gate), its judge chosen by the graph (the controller judges itself, the node-engine by its validator); a repository of the mesh that touches none runs only its own merge-check.sh (mesh/repo-check), a warning when it has none. Nothing is left pending: a repository outside the mesh touching nothing is told so as a pass. The gate moves out of the per-repository scripts into the build seat, so a script is the repository's own tests and declares its toolchain (go or typescript). The controller's manifest names every verb of its seat again (ADR 0132), held by a test.	2026-10-06 22:34:56 +02:00