Merge pull request 'Issue 245: status calls a module behind when only its repository moved' (#95) from issues/245-behind-means-its-files-changed into main

2026-10-05 13:15:57 +00:00
parent 8aeef9969d 87f80573b8
commit b3e7191ddc
1 changed files with 41 additions and 0 deletions
@@ -0,0 +1,41 @@
+---
+status: open
+opened: 2026-10-05
+located-in: []
+fixed-by:
+amended-design:
+---
+
+# 245 — `status` calls a module behind when only its repository moved
+
+## What was observed
+
+2026-10-05. After three catalogue merges that changed 11 modules, `status` listed **69 modules
+behind their source**, each as `holds <older commit>, source has <newer commit>`, with the advice
+"`build --behind` builds them; `push --behind` sends them on".
+
+Between the two commits, `git diff --name-only` shows changes under 11 module directories only. For
+58 of the 69 modules listed, for example a Bluetooth module, the container runtime's, the forge's,
+the package manager's and the bus's, the diff of the module's own path is empty. Their sources did
+not change; only the repository's commit did.
+
+The merges' plans were right: they rebuilt the changed modules and those that depend on them, by
+tier. Only the report was wrong. An agent following the report's own advice ran `build --behind`,
+which rebuilt all 69. The rebuilt bus module was rolled out, and its container was replaced on the
+control node. Every node's runtime lost the bus for about a minute.
+
+## Why it matters beyond this instance
+
+"Behind" is the word a person and an agent act on, and `status` attaches a command to it. A module
+is held to a commit of its repository, so after any merge almost every module of that repository
+reads behind. The list then says nothing about what needs building: it hides the few modules that
+really are behind among the many that are not, and it invites a rebuild of everything, which is not
+a harmless act (above).
+
+## Open questions
+
+1. Should "behind" compare the module's own sources, its path and whatever its build reads, between
+   the commit it was built from and the repository's head, the way a plan already decides what to
+   rebuild? A module whose files did not change could then simply move its recorded commit forward.
+2. Should `build --behind` use the same comparison, so it can never rebuild an unchanged module?
+3. Should `status` show only the modules an open plan has not yet rebuilt?