A satellite PR compiles against the set its main last PASSED — so when main is red because the set moved, the fix cannot be proven and may not name the new API

[rbuergi]

A satellite's PR lane compiles against the newest sealed set its own main has PASSED, not the newest sealed set. That is deliberate and right in the normal case — pull requests follow main — but it produces a deadlock in exactly the case where a fix is most urgent: when main is red because the set moved.

Measured today, on the PR fixing the fleet's publication outage

MeshWeaver.Plugins#1873 exists to fix two suites that core changes broke on arrival in set 3.0.0-ci.8596. Its own platform job says:

skip main-cd #8596 …: sealed, but this repo's `main` has not passed on it yet
                      (main's newest passed set is core CD #8587)
set=3.0.0-ci.8587

The resolver is behaving exactly as documented (resolve-platform.py:1016-1019). The consequences, all measured on that PR:

1. The PR lane cannot exercise the regression the PR exists to fix. It builds and runs against the set before the break, so it can go green having proven nothing about the set main will actually use.
2. It is worse than uninformative — it is hostile to the clean fix. The first attempt used the API the breaking core change introduced (PackageInstaller.SetUpdatePolicy, which is what the catalog card itself calls). The PR went red: CS0103 PackageUpdatePolicy, CS0117 SetUpdatePolicy, CS1061 EffectiveUpdatePolicy — the set it compiles against has none of those symbols.
3. So a fix for a set-move regression must compile on the OLD set AND pass on the NEW one, and may name no symbol the new set introduced.

For #1872 that was resolvable — the fix builds the record's legacy shape as JSON (content["autoUpdate"] = true; content.Remove("updatePolicy")), which names nothing new and is the more honest test, since that shape is exactly the population production holds: every record installed before the change. CI offers one oracle, so both were taken locally against two core worktrees — set 8587: 9/9; core main: 9/9, PluginCatalog.Test 734/734, FutuReAnalysisTest 46/46.

But that was luck of this particular break. A set-move regression whose only honest fix requires the new API has no green path at all: the PR cannot compile, and main cannot go green until the PR merges.

Why the current design is still right

Worth stating so the fix is not a loosening. The ceiling exists because a PR that silently resolved a newer set than main has passed would be testing against bytes main has never validated — and #1826/#4265 record what that cost. refuses rather than falling back is the correct default, and a fallback that quietly took the newest sealed set would re-open exactly that hole.

The question, which is not an agent's to answer

Should the PR lane offer an explicit, per-PR opt-in to the newest sealed set when main is red on it — something a human types, that is visible in the run, and that the PR body must justify — rather than a silent fallback?

Arguments the decision has to weigh:

• For: without it, every platform-caused satellite red has this chicken-and-egg, and the only escape is a fix expressible in the old vocabulary. That is a constraint on the shape of the fix, imposed by the lane rather than by the problem.
• Against: an opt-in is a skip-trapdoor wearing a justification, and the fleet's own rule is that a gate must never let the caller decide whether it applies. It would also be reached for under exactly the pressure that makes people careless — a red main.
• A third option: make the deadlock visible rather than escapable — have the resolver say, when it holds a PR back on a set main is red on, that this PR may be unable to prove its own fix, and name the set it would have used. The lane stays honest and the author is told what they cannot measure.

Recorded as item 18 in MeshWeaver.Plugins/Hosting/PortalHostSuites.md with the two-command attribution recipe. Filed here because it is a fleet property, not a Plugins one — .Education, .Reinsurance, .SocialMedia, .Manufacturing and .Crm all call the same lane.

Related: #4299 (the review gap that let the breaking change through unread), Plugins#1872 (the outage), #1826 / #4265 (why the ceiling exists), break-shape 7 in CrossRepoPairGate.md (why no surface gate saw it).

---

🤖 Generated with Claude Code

[rbuergi]

Three corrections from a read-only sweep: the floor already landed, the fleet-property premise is false, and the ceiling cannot tell "red" from "not run"

Measured on core origin/main b8da52e054 and each satellite's main, 2026-09-15.

1. The deadlock is one repo's, not the fleet's. The filing says it is a fleet property because ".Education, .Reinsurance, .SocialMedia, .Manufacturing and .Crm all call the same lane". They do — but the lane passes no ceiling: node-repo-gate.yml:740 runs the resolver as python3 "$SCRIPT" --tester-image … --portal-image … ${FREEZE:+--freeze "$FREEZE"}, with no --passed-on-main and no --passed-ceiling. Reading each of the five repos' main ci.yml over REST (659–1,923 lines, all non-empty): --passed-on-main = 0 occurrences, --passed-ceiling = 0 occurrences, in all five. The only repo that follows main is MeshWeaver.Plugins — .github/workflows/ci.yml:443 FOLLOW_MAIN: ${{ github.event_name == 'pull_request' || github.event_name == 'merge_group' }} → :449. The five satellites take the newest sealed set on every trigger, i.e. they carry the opposite exposure (the #1821 shape), not this one. The decision is real; its blast radius is Plugins.

2. The floor landed ~15 h before this was filed, and the issue cites it as the wrong thing. #4265 (4b217f042f, merged 2026-09-14T04:36Z) added scripts/platform-floor.json, read at resolve-platform.py:495-503, refused at :506-521, applied to every resolution path at :2142-2180 — a freeze explicitly does not exempt it. Plugins' file declares minimum: 8506 with a because naming the adopted symbol. That is exactly the in-diff, human-visible, same-commit declaration the third option here gestures at, and it converts case 3 ("a fix whose only honest form requires the new API") from an opaque CS0103 into a named refusal printing the set, the floor and the reason. It does not resolve the deadlock — it refuses rather than raising the ceiling, and it cannot express "main is red on the set I need". So the #1826 / #4265 citation as "why the ceiling exists" is misattributed: they are why the floor exists. Two precisions: only Plugins carries a floor file (all five satellites 404 on scripts/platform-floor.json), and current_floor() reads a sibling of the executing script while the reusable lanes fetch the canonical into $RUNNER_TEMP (node-repo-gate.yml:729-731) — so a caller repo's floor can never bind the shared lane's resolution, only a vendored platform-ref job's.

3. The mechanism is worse than "compiles against the last passed set" — it cannot distinguish the two cases this issue is about. main_passed_ceiling (resolve-platform.py:540) reads only ?branch=main&event=push&status=success runs. So "main is RED on the newer set" and "main has not run on it yet" produce the identical ceiling and the identical message, and :1015-1019 can only say "main has not passed on it yet" (:981-988). That conflation is by construction, and it is why a fix cannot even report why it is blocked, let alone be proven. Any closing shape has to add the red-vs-not-yet discriminator, or the lag line will keep telling the author the opposite of what is happening.

On overrides: the only one is repo-wide. ceiling_for (:527-535) → if freeze: return None, [f"freeze {freeze} overrides the main ceiling — not consulted"], False, where the freeze is vars.MW_PLATFORM_REF — a repository variable, invisible in any diff, applying to main as well as the PR, documented as an incident instruction. The lanes also take caller-supplied image-digest + platform-image-digest (node-repo-gate.yml:698-712, both-or-neither) and allow-unpinned, but those are caller-workflow inputs. There is no per-PR opt-in.

[rbuergi]

A second ceiling, measured today, that the model in this issue does not cover: the SET pin and the IMAGE pin move independently, and a PR can resolve a newer set while pulling an older image.

This issue reasons entirely in sets — "the newest sealed set its own main has PASSED" — and the resolver is indeed set-based. But a satellite run carries two platform pins, and for a module declaring build=container the image is what compiles it:

compiler: NOT a consumer — MeshWeaver.Blazor.Chat declares build=container,
          so the pinned platform image compiles it

The instance

MeshWeaver.Plugins#1914, run 34954336506 (09:46:12Z):

pin	value
set	3.0.0-ci.8647 — newer than the one Plugins main passed on (8645)
image-digest	sha256:f39e91a93a31…

Core CD's only post-#4375 success whose full trio ran — run 34949019755, 08:48:46Z, head 7d1894fb3, which carries the fix — promoted 9 digests. f39e91a93a31 is not among them. So that run compiled with a builder image from before the promotion, 57 minutes after a post-promotion image existed, while resolving a set that was newer than main's.

The visible cost was a red that looks like content: MeshWeaver.Plugins#1915's asset gate reported "2 of 5 implied static assets are absent" for MeshWeaver.Blazor.Chat, naming that repo's own module, when the fault was the image pin.

Why it matters to this issue specifically

The deadlock described here — "a fix for a set-move regression must compile on the OLD set and pass on the NEW one" — has a twin one layer down: a fix that lives in the platform IMAGE (an emitter, a builder verb, mw-plugin-test) is not exercised by moving the set at all. Checking "is my PR on a set carrying the fix?" answers yes and is still wrong; the question is "is my PR on an image from a promotion carrying it?", and nothing in the lane's output invites that question.

Two consequences worth folding into whatever this issue becomes:

1. Any remedy stated in terms of sets is incomplete for build=container modules. A "compile against the newest sealed set" escape hatch would not have helped Module bundles carry their own dependency closure, derived from deps.json #1914 at all.
2. The refusal should name the pin that decided. The gate's own text already guesses at the mechanism ("a lane still pinned to an image built before MeshWeaver#2384 reds here with nothing wrong in its own diff") — it has the right hypothesis and cannot confirm it, because the digest→promotion mapping is not in front of the reader. Printing the image-digest next to the set, with whether that digest is in the newest promotion, turns an hour of archaeology into a line.

I did the archaeology by hand for #1914 and it took comparing the run's image-digest against the digests in a CD promote job's log. That is cheap for a machine and expensive for a person, which is usually the sign it belongs in the gate.