ci(scripts): the canonical compile-check learns the registry-served module refs (Plugins#1510) by rbuergi · Pull Request #3761 · Systemorph/MeshWeaver

rbuergi · 2026-09-08T19:26:19Z

Step 1 of centralizing MeshWeaver.Plugins onto the shared scripts. Porting up before switching over, because the order matters.

Why this must land first

MeshWeaver.Plugins fixed a defect in its own copy of compile-check.py (Systemorph/MeshWeaver.Plugins#1510). This canonical copy — the one node-repo-compile-check.yml fetches and runs against every caller's tree — does not have it.

So switching that repo onto this script would silently reintroduce the defect there, and ship it to every satellite that adopts the lane. The centralization is only safe once this is in.

The defect

MeshWeaver.AI, MeshWeaver.Markdown.Collaboration and MeshWeaver.Maps are registry-served (#2276, #3175), so the pinned image's /app no longer carries them. CI tops the reference set up from the run's module bundles — nothing did that for a local --image run.

Result: 15 NEW breaks reported on a pristine checkout of a green main, with the errors naming the content (CS0246/CS0103 on NodeTypes), which reads as the caller's repo breaking. ci.yml already states the failure mode in as many words:

Every NodeType binding that module will fail with CS0246/CS0103 naming the CONTENT, which reads as this repo breaking when the real fault is a missing bundle.

A gate that is red when nothing is wrong is one people learn to ignore — worse than not having it.

The change

MODULE_REFS_NOT_IN_IMAGE + discover_module_refs: the three are found in the caller's own src/<Module>/bin/{Release,Debug}/net10.0 (all three are built there) or in the reference roots CI already supplies. A run whose set is still short refuses with the real cause and the three build commands, instead of reporting content breaks.

MW_REPO_ROOT makes this correct for every caller, not just Plugins — the src/ probe is rooted at ROOT, which is the caller's tree under the lane and the script's own repo otherwise. A caller that builds none of the three is unaffected: CI supplies them in the flat --refs dir and the guard finds them there.

Measured, in the lane's own shape

Run with MW_REPO_ROOT / MW_ALLOW_FILE pointed at a caller's tree, exactly as node-repo-compile-check.yml does:

	result
this script vs `MeshWeaver.Plugins@main`, CI-shaped flat refs	`module refs: 3 present` · 88 clean · 0 NEW break(s)
same, with the three removed from the reference set	exit 1, "the reference set is missing 3 module assemblies…", zero content breaks reported
`--self-test`	9 using-directive shapes + the module-refs guard, both directions

The self-test asserts the guard can fire (empty root → nothing found), collects exactly the three and not a decoy, and absolutizes every path — a relative HintPath is silently dropped by RAR, the same trap discover_refs and discover_ai_refs already absolutize against.

What follows (not in this PR)

Once this is in, MeshWeaver.Plugins deletes its local copy and adopts the shared lane; the satellites inherit both this fix and every later one. gen-manifests.py is the same story in the other direction — this repo's copy is already a strict superset of the Plugins one, so that side needs no port, only the switch.

🤖 Generated with Claude Code

…odule refs (Plugins#1510) MeshWeaver.Plugins fixed a defect in ITS copy of compile-check.py (#1510) and this canonical one — the copy `node-repo-compile-check.yml` fetches and runs against every caller's tree — does not have it. So centralizing that repo onto this script would silently REINTRODUCE the defect for it and ship it to every satellite that adopts the lane. Porting it up first is what makes the centralization safe. The defect: `MeshWeaver.AI`, `MeshWeaver.Markdown.Collaboration` and `MeshWeaver.Maps` are registry-served (#2276, #3175), so the pinned image's /app no longer carries them. CI tops the reference set up from the run's module bundles; nothing did that for a local `--image` run, so the gate reported 15 NEW breaks on a pristine checkout of a green main — with the errors naming the CONTENT, which reads as the caller's repo breaking. A gate that is red when nothing is wrong is one people learn to ignore, which is worse than not having it. Adds MODULE_REFS_NOT_IN_IMAGE and discover_module_refs: the three are found in the caller's own `src/<Module>/bin/{Release,Debug}/net10.0` (all three are built there) or in the reference roots CI already supplies, and a run whose set is still short REFUSES with the real cause and the build commands rather than reporting content breaks. `MW_REPO_ROOT` makes this correct for every caller, not just Plugins: the src/ probe is rooted at ROOT, which is the caller's tree under the lane and the script's own repo otherwise. A caller that builds none of the three is unaffected — CI supplies them in the flat --refs dir and the guard finds them there. Measured, with the lane's own shape (MW_REPO_ROOT + MW_ALLOW_FILE at a caller's tree): this script vs MeshWeaver.Plugins@main, CI-shaped flat refs → module refs: 3 present · 88 clean · 0 NEW break(s) same, with the three removed from the reference set → exit 1, "the reference set is missing 3 module assemblies …", zero content breaks reported --self-test → 9 using-directive shapes + the module-refs guard, both directions The self-test asserts the guard can FIRE (empty root → nothing found), collects exactly the three and not a decoy, and absolutizes every path — a relative HintPath is silently dropped by RAR, which is the same trap discover_refs and discover_ai_refs already absolutize against. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Copilot

🟡 Changes recommended

The new failure remediation text hard-codes a user-specific MeshWeaverRoot path and _self_test includes a redundant import, both of which should be corrected for portability/maintainability.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Updates the canonical .github/scripts/compile-check.py used by the node-repo compile-check lane to correctly handle registry-served module assemblies that are no longer present in the platform image, avoiding misleading “content breaks” when the reference set is incomplete.

Changes:

Added a module-refs discovery helper and a hard failure that explains the real cause when required module assemblies are missing from the reference set.
Extended --self-test to validate the module-refs guard behavior (both “can fire” and “collects exactly the intended assemblies”, with absolute paths).
Emitted a summary line confirming the module refs are present when the guard passes.

File summaries

File	Description
.github/scripts/compile-check.py	Adds discovery + enforcement for registry-served module refs missing from the image, plus self-test coverage for the new guard.

Review details

Files reviewed: 1/1 changed files
Comments generated: 2
Review effort level: Lite

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

+    # reference set is short, so a guard that silently finds nothing to complain about reads
+    # exactly like a complete reference set — the failure this gate exists to stop being
+    # misreported. Assert both directions against a temp tree, with no build output anywhere.
+    import tempfile


+                "\n  Build them once, then re-run this command:\n"
+              + "".join(
+                  f"    dotnet build src/{m} -c Release -p:MeshWeaverRoot=$HOME/code/MeshWeaver/\n"
+                  for m in missing_modules)


github-actions · 2026-09-08T19:30:36Z