Six NodeTypes cannot compile on memex-cloud — the compile gate passed against the platform CI ships, the portal runs an older one

Six NodeTypes on memex.meshweaver.cloud stopped compiling at 2026-09-14T06:59:28Z, forty minutes after a satellite merge. The content is correct and the source-level compile gate ran and passed; the running platform image is simply older than the API the content calls. Nothing is broken in code — the remedy is a roll. What is missing is not a gate but a target: no gate compares the delivered source against the image the receiving instance runs.

What is failing

Every NodeType whose source set includes MeshWeaver.Plugins Store/Publishing/Source/RegistryPackages.cs:

CS0246 Error: The type or namespace name 'PlanTierRefusal' could not be found …
CS1061 Error: 'RegistryPackageSource' does not contain a definition for 'ListCatalog'
              and no accessible extension method 'ListCatalog' …

Measured from Admin/_LogIncident/6fbefdb26bd2a200 (read on memex.systemorph.com), whose ten retained samples all fall between 06:59:28Z and 11:26:05Z today, across three pods:

NodeType	samples
`Store/Plugin`	3
`Store/Catalog`	2
`Store/Enrollment`	1
`Store/Provision`	1
`Store/Maintenance`	1
`Hosting/InstanceRequest`	1

🚨 Six is a FLOOR, not a count. samples[] is a bounded ring, ten deep against occurrences: 68. The failing replica's own /health bake-report read previouslybroken=11 at 2026-09-14T08:44:39Z.

Root cause — measured, not inferred


core PR #4102, commit `00fa2b69f9`, merged 2026-09-12T17:28:05Z	adds `PlanTierRefusal` (`src/MeshWeaver.Mesh.Contract/Security/PlanTierRefusal.cs`) and `RegistryPackageSource.ListCatalog` (`src/MeshWeaver.PluginCatalog/RegistryPackageSource.cs:95`)
both portals serve `3.0.0+c84c6c05503228860df03c4a8b596e497e6d218c`, commit dated 2026-09-12T09:30:22Z	10 `/api/version` samples today — 6 on memex.meshweaver.cloud, 4 on memex.systemorph.com, all identical, so not one unlucky replica
the surface at the running commit	`PlanTierRefusal.cs` is a file `00fa2b69f9` added, and it is absent at `c84c6c055` — read directly, not inferred from ancestry
MeshWeaver.Plugins `Store/Publishing/Source/RegistryPackages.cs`, changed by `dd9c96b4c8` (PR #1837), 2026-09-14T06:19:40Z ("fix(#1802): a declined package names the PLAN…")	the in-mesh Code node now calls both symbols
first failing compile	2026-09-14T06:59:28Z — forty minutes later

🚨 What the CS1061 establishes, and what it does not. RegistryPackageSource resolved — the assembly is on the reference set — so the fault is in the platform assembly's surface, not in a source node that failed to land. That is what distinguishes this from #3485 / #4257 / Missing Declared Sources, which produce a bare CS0246 and have a completely different remedy. It does not by itself give the direction: a member removed in a newer platform, or an extension method out of scope, read identically. The direction here was confirmed on the surface, as the third row above records. Given that, no recompile can cure it — the reference set is the same on every attempt.

Remedy

Roll memex-cloud (and memex) to a sealed set containing 00fa2b69f9 — an InstanceAction on the control instance, i.e. a maintainer decision, not something I should do.

🚨 One roll covers two open items. 00fa2b69f9 is an ancestor of dbdaaacc3, so any set carrying the #4163 fix that #3432 has been waiting on since 2026-09-13 also carries this API. #3432's own comment names 3.0.0-ci.8484 (core 87805faaa) as the nearest such set; anything newer works too.

Why the gates were green, and why the sweep did not name it

Written up as Doc/Architecture/CompiledAgainstAnotherPlatform (PR #4313). In short:

The source-level gate exists and it passed. compile-check / Compile every NodeType (vs core) on dd9c96b4c8 is completed/success (48 success, 11 skipped, 0 failures). It passed correctly: MeshWeaver.Plugins resolves the platform per run (scripts/resolve-platform.py — the newest SEALED set of core's main-cd), and that set carries fix(#4097): a module refused by plan tier says so on the instance — /health, the package card and the self-updater name the tier, not the consequence #4102. The Module Platform Link Gate is the one gate that measures against the platform actually running — and it measures bytes. So the gap is one of target, not coverage.
Roslyn ran because the prebuilt was declined. PrebuiltAssemblySeeder adopts the CI bake when the framework identity matches; the bake was produced against the newer platform, the identity did not match c84c6c055, so the fallback compiled the new source against the old reference set. Modules:RequirePrebuilt (default OFF) would have made that decline a named install-time error — naming package, registry, framework identity and architecture — instead of a doomed compile.
The sweep is not the denominator. search 'nodeType:NodeType content.compilationStatus:Error partitions:all' limit:200 answered 8 at 12:43Z today, all Hosting/*, naming none of the six — that is 8 of N ≥ 200 over M unknown (the companion count came back truncated: true; the envelope carried no coverage field on this image). Two independent reasons, neither a bug in the sweep: it is RLS-filtered — no AgenticOffice/* rows for this identity, while the same deployment's system-side /health counts 594 instances of three AgenticOffice types — and compilationStatus is one shared field over a per-replica compile, so a replica still serving an adopted prebuilt leaves it Ok.

What would close this class (options, not a decision)

Wire the baseline arm onto the satellite's own PR. node-repo-compile-check.yml already implements it: judge-against-baseline compiles the content a second time against baseline-image-digest — "the PREVIOUS platform image (digest) — what the fleet runs today" — and compat-verdict.py classifies each failure. It is wired into the platform's satellite-compat lane, which runs when core promotes; "a node repo checking its own PR leaves it false and keeps the plain gate." The content half is the one that lands first and reaches portals fastest, and it is the half with no baseline reading.
Turn on Modules:RequirePrebuilt on production portals. It does not close the window, but it converts a doomed fallback compile into a named refusal at install time.
Make the parked NodeType name the platform build it failed against. NodeTypeDefinition already carries CompiledFrameworkVersion and FailedBuildInputs (fw=<identity>), so the fact is recorded — as a hash, not as something a reader can compare to a commit without extra work.
Nothing — it clears on the next roll, and a gate on every install may cost more than the window. A legitimate answer, but it should be chosen rather than arrived at by never naming the failure mode.

_{All reads read-only (get / search / curl /api/version / curl /health) plus local repository history and the GitHub REST API. No mesh data was changed, and no instance was rolled or restarted.}

🤖 Generated with Claude Code

Verified, and the remedy is already the roll everyone is waiting on — set 3.0.0-ci.8581, not 8484

Confirmed the ancestry independently against origin/main:

claim	verdict
`PlanTierRefusal` absent at `c84c6c055` (what both portals serve)	absent — `src/MeshWeaver.Mesh.Contract/Security/PlanTierRefusal.cs` does not exist at that commit
set 8581 (`f639c7130`) carries #4102 (`00fa2b69f9`)	yes
set 8581 carries `dbdaaacc3` — the #4163 fix that #3432 is blocked on	yes

So one roll onto 3.0.0-ci.8581 clears all of it, and 8484 is not the target to aim for: it is older than the seal that finally exists, and it carries none of today's delivery-freeze work.

What that single roll delivers

this issue — the six-plus NodeTypes failing CS0246 PlanTierRefusal / CS1061 ListCatalog since 06:59:28Z;
6,925 Started sync/ hubs hold ~2.7 GB of a 3.5 GB live heap — population MEASURED, cause NOT established (split from #3321) #3432 — blocked on dbdaaacc3 since 2026-09-13;
8 of 19 Hosting NodeTypes are at compilationStatus:Error on memex-cloud — three declared source nodes never landed and the install logged nothing #4259 — the Hosting NodeTypes at compilationStatus:Error, plus the boot-install-lands-on-the-seal fix (fix(#4259): the boot default install lands on the sealed commit, never the branch tip #4292);
Plugins#1823, SocialMedia#182, Education#324 — all open on the roll and nothing else;
core#3780 — its frozen ticket receives the outstanding comment once the comment-debt clock (Plugins#1841) is running.

The structural point worth keeping

MeshWeaver.Plugins#1837 changed an in-mesh Code node to call symbols that exist in core main but not in the image the portal runs, and its compile-check gate passed correctly — the gate compiles against the newest sealed core set, not against the commit the portal is serving. That is the AGENTS.md rule ("green CI does not mean the mesh compiles") in a form the rule does not yet spell out: the gap is not CI-vs-runtime, it is sealed-set-vs-rolled-image, and it opens every time a portal lags a seal. It stayed shut while the fleet rolled often; it has been open since 2026-09-12T12:34Z, the last image-moving action (Ops/Actions/helm-memex-ci8411-20260912).

Not proposing a gate for it here — the honest remedy is that portals do not lag seals for two days. But it belongs on the record, because the next person will read the green compile-check and conclude the call was safe.

The roll is the maintainer's. No roll, restart or dispatch has been made from this session.

🤖 Generated with Claude Code

User-visible impact, sampled 2026-09-14 13:1xZ

The consequence is not confined to a log line. /health's content-types census — system-side, past RLS — names the types whose content a replica cannot type, "so their pages render empty". Four calls to memex.meshweaver.cloud (which land on four replicas you do not choose) returned, among others:

Store/Catalog ×15      Store/Plugin ×23      Store/Provision ×1

Store/Catalog, Store/Plugin and Store/Provision are three of the six NodeTypes that cannot compile, so those instances render empty for whoever opens them — the Store pages on the public portal.

🚨 Attribute only those three. The same samples also list Store/Tier ×22, Store/Subscription ×1—2, Store/Install ×3 and Store/Coupon ×1, which are not among the six failing types; content-types degrades for other reasons too (a declined or absent module bundle), and it records a degradation only when a read degrades, so it is neither a superset nor a subset of the compile failures. It is corroboration for the three it shares, not a count of the damage.

_{Four curl /health reads, nothing else.}

Still live on memex-cloud, 2026-09-15 04:5xZ — and the remedy has NOT been applied

Measured read-only, no InstanceAction written:


`memex.meshweaver.cloud/api/version`	`3.0.0+c84c6c05503228860df03c4a8b596e497e6d218c` — the same 09-12 commit this issue names
`/health`	Degraded, `content-types` naming 8 node types whose content this replica cannot type, incl. `Store/Plugin ×78` (last `AgenticEngineering`) and `Edu/CourseInvite ×50`
Ops actions for memex-cloud	newest write is `sample-memex-cloud-20260913-3732` (2026-09-13 18:57Z); everything since is `Logs`. No Roll, no Reconcile.

So the platform skew this issue is about is unchanged on the public instance: core #4102 (PlanTierRefusal, RegistryPackageSource.ListCatalog) merged 2026-09-12T17:28Z, the running commit is dated 09-12T09:30Z, and the in-mesh sources call both.

For contrast, the control instance HAS been rolled — memex.systemorph.com now answers b8143398a7 (set 3.0.0-ci.8612) after the 22:2xZ helm-lane deploy, and its /health names 6 rather than the previous count.

🚨 Before rolling memex-cloud, note what the memex roll cost. The first attempt (reconcile-memex-20260914-nav-rail, 20:13Z) never passed the bake gate: Store/Catalog PARKED on CS1061 'StoreTexts' does not contain a definition for 'ExploreCta' because that partition held a MIX of two Store commits — the defect now filed as #4355 (registry auto-update and the seal reconciler write one GitSynced partition with separate bookkeeping). memex-cloud is the registry itself and carries far more Store content, so a roll there can park the same way. #4355 has a fix in progress; rolling after it lands is the cheaper order.

Re-measured this on the live portal, and the picture is worse and far less stable than the filing records. Eight /health reads of memex.meshweaver.cloud, 2026-09-15 ~10:3xZ:

call	`content-types` says
1	25 node type(s)
2	34
3	8
4	34
5	34
6	30
7	25
8	34

Eight calls, five distinct response bodies (by md5), counts spanning 8 to 34. The filing's "six" and "#4259's eight" are both inside that range — they were one replica's answer, not the portal's.

That sharpens what AGENTS.md already warns ("repeated calls sample DIFFERENT replicas … one call answers about ONE replica you did not choose"): the recorded instance was 10 calls → 2 disjoint bodies on 2026-09-11. It is now 8 calls → 5 bodies, so whatever is going on has become more uneven, not less.

The union across all eight samples: 46 distinct node types

Not a per-replica count — the set of types that at least one replica could not type. Heaviest by instance count: Edu/CourseInvite, Edu/Quiz, Systemorph/Event, Store/Plugin (×72), Hosting/Deployment (×15).

Spanning, among others: Store/* (Catalog, Coupon, Install, Plugin, Provision, Subscription), Edu/* (AnswerSheet, CourseCatalog, CourseInvite, Quiz), Reinsurance/*, SST/*, SocialMedia/* (Post, PostsHub, Profile), Hosting/{Deployment,DeploymentStatus,Publication}, Approvals/Desk, Signature/Desk, Claims/Claim.

Every one of those renders its pages empty on whichever replica cannot type it — and a viewer hits a different replica per request.

Two things this changes

A single /health read cannot state this issue's number. Any count quoted without saying how many calls produced it, and how many distinct bodies came back, is one replica's opinion. The honest form is the table above.
Edu/CourseInvite is not a disposable-mesh artefact. I saw it degrade in MeshWeaver.Education's install shards this morning and recorded it there as a standing condition on that lane; it is degrading here, in production, at up to ×292. The two are the same defect, and the Education lane is simply a place it is visible.

The per-replica instrument with no guesswork remains the Hosting API's Sample (each pod's whole /health body); I have not run one — it is a write on the control instance and the fleet has had enough moving parts this morning.

Followed the degradation to its cause, and found a second thing on the way: the instrument that should have announced this reports Healthy.

`bake-report`, read on the same eight calls

bake-report: Healthy — compiling sweep at 2026-09-12T12:55:17+00:00:
             framework=sd608997 total=353 baked=295 pending=58
             frameworkstale=55 previouslybroken=3

Identical on every replica that printed it (4 of 8 — the other 4 omit the entry entirely, which per AGENTS.md is "the check is not registered in this host", not a clean reading).

Three facts in that one line:

The sweep is from 2026-09-12. Three days old. This matches the standing note that memex-cloud has not been rolled since c84c6c05 (09-12).
pending=58, frameworkstale=55 — 58 of 353 node types are unbaked, and 55 of those are stale against the current framework identity. That is the supply side of the 46-type union content-types reports from the demand side: a type whose module was never baked for this framework cannot be typed when something reads it.
🚨 It says Healthy.

Why the third fact matters more than the first two

A health entry that reports Healthy while 58 of 353 types are pending and 55 are framework-stale cannot announce the condition it exists to measure. The degradation had to be discovered from the other entry (content-types), which only records a type once a read has already degraded — i.e. after a user has seen an empty page.

So the ordering is exactly backwards from what the pair is for: the leading indicator says fine, the trailing indicator says 8–34 depending on which replica answers.

That is the same shape this repository has catalogued repeatedly (#4299's family): an answer that reads like a pass. It is worth deciding what bake-report should say at pending=58 frameworkstale=55 — my reading is that any non-zero frameworkstale on a replica serving traffic is at least Degraded, because it is a promise that some page renders empty. But the threshold is a judgement, and this issue is where the evidence now sits.

What still closes the underlying problem

The roll. frameworkstale=55 against a 09-12 bake is what a roll clears, and that is already the recorded remedy for #4314/#4259 — this comment does not change it. What it adds is that the roll's absence has been invisible to the fleet's own health check for three days, and that is separately fixable.

🚨 Correcting my own suggestion in the comment above, before anyone acts on it — it would take the fleet down.

I wrote: "any non-zero frameworkstale on a replica serving traffic is at least Degraded." I then read NodeTypeBakeHealthCheck and that is wrong, in the direction that causes an outage rather than a reporting gap.

What `bake-report` actually is

It is a readiness gate, not a census, and its own header says what its verdicts mean:

Wiring the bake into /health therefore turns a NodeType that no longer compiles from a production incident into a STALLED ROLLOUT: the new pod never goes ready, traffic never moves, and the previous image keeps serving.

and, for a first deployment:

refusing readiness means the install does not come up — the pod fails its startupProbe and restarts.

So Healthy here does not claim "the mesh is fully baked". It claims "this pod may take traffic". BakePhase.Complete => Healthy(state.Detail) is the sweep having finished; the counts ride in the detail string, deliberately, as payload rather than as verdict.

Making frameworkstale > 0 non-Healthy would therefore hold every pod out of rotation on any portal with a single stale type — stalling rolls fleet-wide and black-holing first deployments. That converts today's invisible-but-serving condition into an unservable one. It is precisely the band-aid shape this repository bans, pointed the wrong way: I would have "fixed" the signal by breaking the thing it reports on.

What the real gap is, restated

The gap is not that this check answers Healthy. It is that nothing non-gating reports pending/frameworkstale as a condition. The counts exist, on every replica, in a string — and the only consumer that turns them into a verdict is a gate that must not fail on them.

So the fix, if one is wanted, is a separate entry (or an existing census-tagged one) that reads the same NodeTypeBakeGateState and reports staleness without touching rotation — the same split AGENTS.md already describes for the two census-tagged entries, which "print their reading whatever the status" precisely so that "I measured nothing" and "I measured, and it was clean" are different sentences.

What stands from the earlier comment

Everything measured, none of the prescription:

eight /health reads → five distinct bodies, content-types spanning 8–34;
union of 46 node types across the samples; heaviest AgenticOffice/Rechnung ×1404, SocialMedia/Post ×994, AgenticOffice/Buchungsjournal ×702, Edu/CourseInvite ×292;
bake-report identical on the 4 replicas that print it: sweep of 2026-09-12, pending=58 frameworkstale=55;
the remedy for the underlying condition is still the roll.

{"body":"The six named types are no longer at compilationStatus:Error — but this issue's thesis is right, and the per-replica data now shows it far better than the shared field could.\n\nSweep on memex.meshweaver.cloud, 2026-09-16:\n\n\nsearch 'nodeType:NodeType content.compilationStatus:Error partitions:all' limit:200\n -> count: 1, truncated: false (Essentials/Mailbox — unrelated to the Store/Publishing source set)\n\n\nSo CS0246 PlanTierRefusal / CS1061 ListCatalog do not reproduce on the shared field. Do not read that as resolved — this issue said from the start that the content is correct and the running image is older than the API it calls, and compilationStatus is one SHARED field over a compile every replica does at boot, so it cannot see a per-replica failure at all.\n\n## What the replica-named instrument shows now (#4218 landed, so Sample answers)\n\nOps/Status/memex-cloud v1224 carries all 8 pods, and the count of node types a replica cannot TYPE tracks pod age, monotonically:\n\n| pod started | untypable types |\n|---|---|\n| 2026-09-12 12:49 | 32 |\n| 2026-09-13 08:06 | 18 |\n| 2026-09-13 21:50 | 7 |\n| 2026-09-14 22:28 | 7 |\n| 2026-09-16 00:06–00:18 | 2–6 |\n\nEvery pod runs the same tag (3.0.0-ci.8411), so this is not an image split — it is what each process loaded at ITS boot. The oldest says so outright:\n\n\npending_module_activation: Degraded — 20 module(s) are landed but not yet loaded in this\nprocess — a restart activates them: MeshWeaver.AI.Anthropic, MeshWeaver.AI.AppleIntelligence, …\n\n\nThat is this issue's mechanism confirmed from the other side: the delivered content moved, the process did not, and nothing compared the two. A restart converges the landed-but-unloaded half; the image gap (core c84c6c05, 2026-09-12) still needs the roll.\n\n## The ask is unchanged and still unbuilt\n\n> What is missing is not a gate but a target: no gate compares the delivered source against the image the receiving instance runs.\n\nStill true. Leaving open on that, not on the six types — and noting the sibling shape in #4348 (a satellite PR compiles against the set its main last PASSED), which is the same missing comparison one hop upstream."}

2026-09-17 — five days on: memex-cloud still runs the image this issue names, and the missing TARGET is still missing

Re-measured read-only today. Nothing rolled, nothing written.

The skew is unchanged on the public portal

curl https://memex.meshweaver.cloud/api/version
  -> 3.0.0+c84c6c05503228860df03c4a8b596e497e6d218c

c84c6c05 is dated 2026-09-12T09:30:22Z — byte-for-byte the commit this issue was filed against
on 09-14. Core #4102 (00fa2b69f9, PlanTierRefusal + RegistryPackageSource.ListCatalog) merged
2026-09-12T17:28Z and is on main today (src/MeshWeaver.Mesh.Contract/Security/PlanTierRefusal.cs,
src/MeshWeaver.PluginCatalog/RegistryPackageSource.cs:95). So the recorded remedy — the roll — has
not been applied in five days. For contrast the control instance has moved on: memex.systemorph.com
answers 3.0.0+afde4eab… (2026-09-15T21:50Z).

The gate this issue asks for is still unbuilt

Systemorph/MeshWeaver.Plugins@main still resolves its compile target as the newest sealed core
set (scripts/resolve-platform.py, job platform-ref in .github/workflows/ci.yml) — never the
commit a receiving instance is serving. Core's shared node-repo-compile-check.yml does carry a
judge-against-baseline arm (:133), but Plugins' compile-check is inline in its own ci.yml and
does not call it, and no arm anywhere compares delivered source against a running image. The body's
sentence therefore still holds verbatim:

What is missing is not a gate but a target: no gate compares the delivered source against the
image the receiving instance runs.

What the failure looks like on memex-cloud today — same class, different symbols

The six types this issue named are not at compilationStatus: Error any more (as the 09-16 comment
recorded). What the shared field shows instead, 2026-09-17:

search 'nodeType:NodeType content.compilationStatus:Error partitions:all'  -> count: 7
  Hosting/{Backup, Deployment, FleetConsole, InstanceAction, InstanceRequest, Issue, PlatformBuildInbox}

Hosting/Issue fails with CS0117 'IssueKinds' does not contain a definition for 'JobFailed',
CS0103 'SafeUrl', CS1061 'IssueContent' does not contain a definition for 'Workload', at
adoptedModuleVersion: 1.18.7 against currentModuleVersion: 1.22. Those are in-partition
symbols, not platform API — so this particular set is the other skew (a partition holding two
package versions at once, #4355 / #4588), not the platform-vs-content one this issue is about. Kept
apart deliberately: same "nothing compiled the combination that is actually deployed" family, two
different denominators, two different remedies.

Standing, unchanged

Open on the missing target, not on any specific type. The roll remains the maintainer's, and the
per-replica reading (#4218's Sample) remains the instrument that can see what the shared
compilationStatus field structurally cannot. Sibling shape one hop upstream: #4348.

_{Read-only 2026-09-17: two curl /api/version reads, one search per portal, fresh shallow clones of Systemorph/MeshWeaver@main and Systemorph/MeshWeaver.Plugins@main. No mesh write, no roll.}

Closing: the remedy this issue named has been applied, and the per-replica instrument says the symptom is gone

This issue said from the first line that nothing is broken in code — the remedy is a roll, onto a
sealed set containing 00fa2b69f9 (#4102). That roll happened this morning. Measured read-only
2026-09-19 ~18:5xZ; nothing was written, rolled or restarted.

The image moved, on both portals

portal	`/api/version`	commit dated
memex.meshweaver.cloud	`3.0.0+c25f86ae85b7050f0fffa45d81444cc69cbb64d8`	2026-09-19T07:32:15Z
memex.systemorph.com	`3.0.0+96f88406b419215a40b3aa97cd4c414ea7b3eb19`	2026-09-19T07:11:56Z

Four /api/version samples of memex.meshweaver.cloud, all c25f86ae — repeated calls land on
different replicas, so this is not one lucky pod. Ops/Status/memex (sampled 18:53:11Z) agrees for the
control instance: 2/2 ready, generations: 1, converged: true, both replicas on
3.0.0-ci.8968 / 96f88406, started 08:10:37Z and 08:11:39Z.

Ancestry, the test this thread has used throughout:

git merge-base --is-ancestor 00fa2b69f9 c25f86ae…   → yes   (memex-cloud)
git merge-base --is-ancestor 00fa2b69f9 96f88406…   → yes   (memex)
git merge-base --is-ancestor dbdaaacc3  c25f86ae…   → yes   (#4163, the fix #3432 waits on)
git merge-base --is-ancestor dbdaaacc3  96f88406…   → yes

So the single roll the 2026-09-14 13:12Z comment described — "one roll onto a set carrying both
00fa2b69f9 and dbdaaacc3 clears all of it" — has landed, five days later than hoped and onto a
much newer set than 8581.

The symptom, on the instrument this thread ended up trusting

Not the shared field. memex.meshweaver.cloud /health, bake-report, sweep at 2026-09-19T08:40:11Z,
framework s573b826:

OUTCOME CENSUS (sweep completed): every one of the 300 type(s) that reached a verdict has a usable
assembly on this replica. Denominator: 362 of 362 enumerated type(s) reported an outcome; of those,
62 reached NO verdict (timed out, or waiting on something that did) and 0 were withdrawn by their own
repository.

content-types on the same body names six types, and five of the six this issue named are gone
from it: no Store/Plugin, no Store/Provision, no Store/Enrollment, no Store/Maintenance, no
Hosting/InstanceRequest.

The shared-field sweep agrees, cited only as agreement because this thread established it is the weaker
instrument:

search 'nodeType:NodeType content.compilationStatus:Error partitions:all' limit:200
  → count: 0, truncated: false, coverage.partitions: 124 partitions

0 of N over M = 124 readable partitions, with N a floor — the companion
search 'nodeType:NodeType partitions:all' limit:200 came back truncated: true at 200, so N ≥ 200.
Unlike the 2026-09-14 reading, the envelope now carries coverage, so the denominator is stated rather
than unknown.

What is left in `content-types`, and why it is NOT this issue

Store/Catalog ×13 still appears — with a different reason string, and the same /health body names
the cause:

pending_module_activation: Degraded — … 8 landed module generation(s) are DECLINED in favour of the copy this image ships … MeshWeaver.AI v1.12.3 … built for another platform (framework gecd8279ec5f8055b4dcf8a57e6e830a87a33d863; this deployment runs gc25f86ae85b7050f0fffa45d81444cc69cbb64d8)

That is the declined-generation root, not CS0246 PlanTierRefusal / CS1061 ListCatalog — and, as the
payload itself says, a restart does not change it and neither does re-installing. Attributing it
here would be wrong in the same way this issue warned about on 2026-09-14 ("Attribute only those
three").

The class question is not closed by this, and is not lost

"No gate compares the delivered source against the image the receiving instance runs" is the durable
half of this filing, and its home is the committed page, not this thread —
Doc/Architecture/CompiledAgainstAnotherPlatform
→ "What would close this class", carrying all four options including "Nothing" stated as a choice
rather than arrived at. One of them has moved since: option 3's spirit — make the unusable NodeType
visible per replica — shipped as the /health OUTCOME CENSUS (61ea9c7da908aab6cae1b16f60eefc5f8d801635,
NodeTypeBakeReportRegistry), which is what produced the reading quoted above and is live on both
portals. #4632 tracks the remainder of that instrument.

Closing the incident: its measured subject was six-plus NodeTypes failing to compile on
memex-cloud because the running platform predated the API they call, and that condition no longer
holds on either portal.

_{All reads read-only: curl /api/version ×5, curl /health, two mesh search calls, one get of

Ops/Status/memex, and local git merge-base. No mesh node was written, no InstanceAction filed, no

instance rolled or restarted.}

Addendum — a positive check on all six named types, because "0 at Error" has two causes and this
thread is the one that established that.

Asked the other way round, so a row coming back means the field was read and says Ok, not that a row was
missing:

search 'nodeType:NodeType content.compilationStatus:Ok namespace:Store'         → 17, coverage: [store]
search 'nodeType:NodeType content.compilationStatus:Ok namespace:Hosting name:*Instance*' → 2, coverage: [hosting]

type named in this issue	present at `compilationStatus: Ok`?
`Store/Plugin`	yes (v14125, 2026-09-19T08:43:40Z)
`Store/Catalog`	yes (v3458)
`Store/Enrollment`	yes (v1511)
`Store/Maintenance`	yes (v839)
`Store/Provision`	yes (v1818)
`Hosting/InstanceRequest`	yes (v8912, 2026-09-19T08:43:29Z)

Six of six, each with its own version and a lastModified from this morning's boot sweep. All the
Store/* rows come back under coverage.partitions: ["store"] and the Hosting/* one under
["hosting"], so the reads reached the partitions the types actually live in rather than being answered
from a fan-out that happened not to include them.

That is still the shared field, with the per-replica caveat this thread wrote down — but it is now a
positive reading of it for every named type, on top of the /health OUTCOME CENSUS ("every one of the
300 type(s) that reached a verdict has a usable assembly on this replica") which is the per-replica one.
Both point the same way, and neither is the bare zero.

Navigation Menu

Repository navigation

Six NodeTypes cannot compile on memex-cloud — the compile gate passed against the platform CI ships, the portal runs an older one #4314

What is failing

Root cause — measured, not inferred

Remedy

Why the gates were green, and why the sweep did not name it

What would close this class (options, not a decision)

Verified, and the remedy is already the roll everyone is waiting on — set 3.0.0-ci.8581, not 8484

What that single roll delivers

The structural point worth keeping

User-visible impact, sampled 2026-09-14 13:1xZ

Still live on memex-cloud, 2026-09-15 04:5xZ — and the remedy has NOT been applied

The union across all eight samples: 46 distinct node types

Two things this changes

`bake-report`, read on the same eight calls

Why the third fact matters more than the first two

What still closes the underlying problem

What `bake-report` actually is

What the real gap is, restated

What stands from the earlier comment

2026-09-17 — five days on: memex-cloud still runs the image this issue names, and the missing TARGET is still missing

The skew is unchanged on the public portal

The gate this issue asks for is still unbuilt

What the failure looks like on memex-cloud today — same class, different symbols

Standing, unchanged

Closing: the remedy this issue named has been applied, and the per-replica instrument says the symptom is gone

The image moved, on both portals

The symptom, on the instrument this thread ended up trusting

What is left in `content-types`, and why it is NOT this issue

The class question is not closed by this, and is not lost

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Six NodeTypes cannot compile on memex-cloud — the compile gate passed against the platform CI ships, the portal runs an older one #4314

Description

What is failing

Root cause — measured, not inferred

Remedy

Why the gates were green, and why the sweep did not name it

What would close this class (options, not a decision)

Activity

rbuergi commented on Sep 14, 2026

Verified, and the remedy is already the roll everyone is waiting on — set 3.0.0-ci.8581, not 8484

What that single roll delivers

The structural point worth keeping

rbuergi commented on Sep 14, 2026

User-visible impact, sampled 2026-09-14 13:1xZ

rbuergi commented on Sep 15, 2026

Still live on memex-cloud, 2026-09-15 04:5xZ — and the remedy has NOT been applied

rbuergi commented on Sep 15, 2026

The union across all eight samples: 46 distinct node types

Two things this changes

rbuergi commented on Sep 15, 2026

bake-report, read on the same eight calls

Why the third fact matters more than the first two

What still closes the underlying problem

rbuergi commented on Sep 15, 2026

What bake-report actually is

What the real gap is, restated

What stands from the earlier comment

rbuergi commented on Sep 16, 2026

rbuergi commented on Sep 17, 2026

2026-09-17 — five days on: memex-cloud still runs the image this issue names, and the missing TARGET is still missing

The skew is unchanged on the public portal

The gate this issue asks for is still unbuilt

What the failure looks like on memex-cloud today — same class, different symbols

Standing, unchanged

rbuergi commented on Sep 19, 2026

Closing: the remedy this issue named has been applied, and the per-replica instrument says the symptom is gone

The image moved, on both portals

The symptom, on the instrument this thread ended up trusting

What is left in content-types, and why it is NOT this issue

The class question is not closed by this, and is not lost

rbuergi commented on Sep 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

`bake-report`, read on the same eight calls

What `bake-report` actually is

What is left in `content-types`, and why it is NOT this issue