The plugins gate blamed a compile break for a failure that compiled fine by rbuergi · Pull Request #1103 · Systemorph/MeshWeaver

rbuergi · 2026-08-10T11:31:14Z

1. The message named a cause the report contradicted

The gate judges three checks per NodeType — compile, render, tests — and its own log says which failed:

RED Store/Catalog: compile=Ok render=ok tests=FAILED
    **Area not found**
    No renderer is registered for area `Tests` on hub `Store`.

CI annotated that as "MeshWeaver.Plugins does not compile against this PR … A public API change here breaks plugin node source that is Roslyn-compiled at runtime." One message for all three checks, asserting a cause the report contradicts — and the most expensive wrong lead available, because it is plausible: a public-API break here genuinely does break that repo (plugin node source is Roslyn-compiled from mesh content, so a repo-local rg can never prove a deletion safe — that is how AddSkillSource broke 8 NodeTypes). So the claim reads as authoritative and the investigator goes to diff public signatures. It did exactly that on #1043, whose whole diff was MessageService.cs and two test files.

Now the tester emits one verdict line naming the failing check and the node(s):

GATE FAILED — tests: Store/Catalog — 1 new failure(s), 0 stale allow entr(ies).

CI lifts that line verbatim — it does not re-derive or re-word a cause — and the public-API sentence is kept, conditional on the phase actually being compile. Two failures previously reported as "0 new failure(s)" now name themselves: a fatal error says fatal: …, a stale allow entry says so. A run that fails with nothing recorded says no failing check was recorded rather than picking a phase.

GateSummaryTest pins each of these two-sided: the line must name the check that failed and must not name one that did not — a message that can drift back is the thing being fixed. CI's grep is anchored on ^GATE FAILED (the GateReport.FailedPrefix constant, ASCII), so re-punctuating the line cannot silently unhook the annotation.

2. The `Store/Catalog` failure is a framework defect, not plugin rot — and not the probe path

The hypothesis in the issue (the probe landed on a type path, where "Area not found" is by design) does not hold. Store is the Store package's root, retyped to Store/Catalog by the installer — a correctly-typed instance. The evidence is the available-areas list the failure printed: item for item it is ConfigureDefaultNodeHub's set — AddDefaultLayoutAreas (incl. AddEducationLayoutAreas' CourseNav/Learn/StartExercise/GoToMyCopy and AddDomainLayoutAreas' Catalog/Details/DataModel) plus Invite. Not one area from Store/Catalog's compiled configuration, and not the Space placeholder's either. Hub Store was serving the mesh default configuration: the known partition-root defect (#1055, and 2026-07-29 before it).

It recurred on a commit that already carried #1055's fix (run 31361446933 at 06:18Z; #1055 merged 04:39Z). NOT cached is not NOT pinned: a hub is pinned by address in Mesh.GetHostedHub and never re-reads its node's NodeType, so fixing the resolution does not un-pin the hub a bad resolution already activated. The only thing that does is PackageInstaller's DisposeRequest — fire-and-forget, and conditional on the placeholder dance having run. That residual is not fixed here (it needs a repro and a design decision, not a guess); it is written into both comment blocks that carry this ledger, which now ask three questions instead of two.

The gate now prints which node hosted the Tests run and how it was picked (an instance already in the mesh vs. a throwaway probe it created) — the two are not equivalent, and that difference is what separates the same commit's green and red runs. That line is what makes the third question answerable from CI alone. The host resolution is also bounded now: it queries the index and may create a node, neither with a budget of its own, so a wedge there spent the whole job timeout and reported nothing.

Not done

No continue-on-error, no retry around the probe, no widened timeout, no allow-list entry for Store/Catalog. The gate still fails exactly when it failed before — it just says what failed.

Verification

MeshWeaver.PluginTester.Test: 28/28 pass (12 new).
mw-plugin-test run end-to-end against an empty root: emits GATE FAILED — fatal: …, exit 1 — the line CI greps, produced by the real binary.
-c Release -warnaserror clean: MeshWeaver.PluginTester, MeshWeaver.PluginTester.Test, MeshWeaver.PluginCatalog, MeshWeaver.Hosting.

🤖 Generated with Claude Code

The gate judges three checks per NodeType — compile, render, tests — and its own log says which one failed: RED Store/Catalog: compile=Ok render=ok tests=FAILED **Area not found** No renderer is registered for area `Tests` on hub `Store`. CI then annotated that as: MeshWeaver.Plugins does not compile against this PR … A public API change here breaks plugin node source that is Roslyn-compiled at runtime. One message for all three checks, asserting a cause the report contradicts. And it is the most expensive wrong lead available, because it is PLAUSIBLE: a public-API break here genuinely does break that repo — plugin node source is Roslyn-compiled from mesh content, so a repo-local `rg` can never prove a deletion safe (that is how `AddSkillSource` broke 8 NodeTypes). So the claim reads as authoritative and the investigator goes to diff public signatures that are fine. It did exactly that on #1043, whose entire diff was MessageService.cs and two test files. Now the tester emits ONE verdict line naming the failing check and the node(s): GATE FAILED — tests: Store/Catalog — 1 new failure(s), 0 stale allow entr(ies) CI lifts that line verbatim — it does not re-derive or re-word a cause — and the public-API sentence is kept, CONDITIONAL on the phase actually being `compile`. Two failures that were previously reported as "0 new failure(s)" now name themselves: a fatal error says `fatal: …`, a stale allow entry says so. A run that fails with nothing recorded says "no failing check was recorded" rather than picking a phase — an unexplained failure is cheaper than a confidently wrong one. GateSummaryTest pins each of these two-sided: the line must name the check that failed AND must not name one that did not. Second half: the report now names WHICH node ran the Tests area, and how it was picked. A type's `Tests` area is served by INSTANCE hubs, so the gate probes either an instance already in the mesh or a throwaway probe it creates — and the two are not equivalent. `Store` is the Store package's ROOT, retyped to `Store/Catalog` by the installer; its hub can have been activated while it was still the Space placeholder, and an instance hub never re-binds its configuration, so it serves only the framework's default areas. That is the difference between the same commit's green and red gate runs, and without the host in the report the RED reads as plugin rot (it was in fact read as "the probe landed on a type path" — it had not). The host resolution is also bounded now: it queries the index and may create a node, neither with a budget of its own, so a wedge there spent the whole job timeout and reported nothing. Fixes #1077

…will look The gate's `Store/Catalog` RED is not plugin rot and not the type-hub quirk it was read as. The available-areas list the failure printed is, item for item, `ConfigureDefaultNodeHub`'s set — `AddDefaultLayoutAreas` (Overview, Settings, Search, Files, Threads, Chat, NodeTypes, AccessControl, Groups, Edit, Copy, Move, Recycle, Versions, Delete, Pin/Unpin, StopSync, $Data/$Schema/$Model, plus AddEducationLayoutAreas' CourseNav/Learn/StartExercise/GoToMyCopy and AddDomainLayoutAreas' Catalog/Details/DataModel) plus Invite. Not one area from `Store/Catalog`'s compiled configuration, and not the Space placeholder's either. So hub `Store` — the Store package's ROOT, retyped to the package's own NodeType by the installer — was serving the mesh DEFAULT configuration. That is the known partition-root defect, not a broken plugin. It recurred on a commit that already carried #1055's no-cache fix (run 31361446933, 06:18Z; #1055 merged 04:39Z). NOT cached is not NOT pinned: a hub is pinned by address in Mesh.GetHostedHub and never re-reads its node's NodeType, so fixing the RESOLUTION does not un-pin the hub a bad resolution already activated. The only thing that does is PackageInstaller's DisposeRequest — fire-and-forget, and conditional on the placeholder dance having run. Both comment blocks that carry this ledger now say so, and both now ask three questions instead of two, the third being "is the live hub the one activated inside the provisioning window?" — which the gate's new Tests-host line is what makes answerable from CI alone. Also drops a double period from the no-allowlist verdict line (verified against a real run: `GATE FAILED — fatal: …`), and anchors CI's grep on `^GATE FAILED` with no punctuation, so re-wording the line cannot silently unhook the annotation and drop CI back to a guessed cause.

…b8c94e40160

Copilot

Pull request overview

This PR makes the cross-repo plugins gate report what actually failed (compile/render/tests) and which node hosted a failing Tests run, then wires CI to lift that verdict line verbatim instead of emitting a generic “does not compile / public API change” annotation.

Changes:

Add a stable GATE FAILED — … headline that names the failing check(s) + scope(s), including fatal/stale-allow cases, and print it as the single CI-consumed verdict line.
Record and print the resolved Tests host (shipped instance vs. created probe) and bound the host-resolution path with the same timeout budget as the render/test probe.
Update the GitHub Actions workflow to tee the tester output, extract the ^GATE FAILED line into job outputs, and only mention “public API change” when the verdict actually includes compile:.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
tools/MeshWeaver.PluginTester/PluginGateRunner.cs	Bounds and instruments `Tests` host resolution; reports which node hosted `Tests` and how it was chosen.
tools/MeshWeaver.PluginTester/GateReport.cs	Adds `FailedPrefix` and prints a phase-accurate verdict headline as the single CI-consumed failure line; prints `TestsHost` detail.
tools/MeshWeaver.PluginTester/GateAllowlist.cs	Introduces `GateVerdict.Headline(...)` to generate a stable, phase-accurate one-line failure summary from report/verdict data.
test/MeshWeaver.PluginTester.Test/GateSummaryTest.cs	Pins the failure headline against drift and asserts “two-sided” behavior (names failing phase, does not name non-failing phase).
src/MeshWeaver.PluginCatalog/PackageInstaller.cs	Updates the comment ledger to reflect the 2026-08-10 recurrence and why host reporting matters diagnostically.
src/MeshWeaver.Hosting/PathResolutionService.cs	Extends the comment ledger explaining the “not cached vs not pinned” residual and ties it to the new host reporting.
.github/workflows/dotnet-test.yml	Lifts the tester’s `^GATE FAILED` line verbatim into job output + annotations; keeps the API-break sentence conditional on `compile:`.

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

github-actions · 2026-08-10T11:45:04Z