🚨 A platform build published tonight removes AI types from the in-mesh compile surface — 12 Reinsurance NodeTypes broke on an UNCHANGED commit

The measurement

MeshWeaver.Reinsurance main, the same commit, one hour apart:

run	framework	source	result
`33114326364` 20:38	`s81a9b60ed905b4f5263f55ff8369976d`	`7f454af0`	179/179 compiled, 0 new failures
`33119003918` 21:37	`s96fb96913046dff7a1d6773286ad3fc8`	`7f454af0`	167/179 — 12 NEW failures

Identical content. Different platform build. A framework change published between those two runs
removed a set of AI types from the surface in-mesh source compiles against.

What went missing

Not one symbol — a cluster, which is the signature of an assembly leaving the compilation surface
rather than a deletion:

CS0246  The type or namespace name 'ThreadMessage' could not be found            (×4)
CS1061  'IMessageHub' does not contain a definition for 'StartThread'
        and no accessible extension method 'StartThread' accepting a first argument…
CS0246  The type or namespace name 'ChatClientCredentialResolver' could not be found
CS0246  The type or namespace name 'AiSettings' could not be found                (×many)
CS0103  The name 'AiSettingsNodeType' does not exist in the current context       (×many)

StartThread is the canonical thread-submission extension AGENTS.md documents as the entry
point. AiSettingsNodeType is the same type whose AddSkillSource was deleted in #683 and put
nine plugin partitions on the compilation-error overlay in production — the precedent is in the
repo's own memory.

Why nothing went red until now

This is the case AGENTS.md opens with:

🚨🚨🚨 Green CI does NOT mean the mesh compiles — in-mesh source is invisible to dotnet build.
Deleting or renaming ANY public framework surface is a breaking change to code the compiler cannot
see… A clean -c Release -warnaserror build proves nothing here.

Every core PR tonight was green. The 12 failures live in Reinsurance's in-mesh Source/*.cs, which
only the bake gate compiles — and only against whichever platform image it pulls.

Why it is urgent rather than merely broken

Per AGENTS.md: a NodeType left at CompileError refuses portal readiness and parks every
instance hub for the full 60 s activation budget — hung pages, failed liveness probes, dropped
silos. And a framework-version bump recompiles every dynamic NodeType, so this does not trickle in;
it lands wholesale on the next roll.

Mitigating, for the moment only: memex has not self-updated since 14:27 (#2494/#2553), so the
running fleet is still on ci.6105 and has not met this framework. The stalled roller is the only
thing standing between this and the overlay. When #2494 is fixed, this ships.

Where to look

Between the two runs, main merged the AI-exit and extraction work — #2537 ("AI tools: 22 Task
bridges gone"), #2547 ("Speech.Contract and the log watcher leave core (#2276)"), alongside
#2540/#2542/#2549. Earlier, 16497893b moved the AI engine behind an assembly attribute.

The shape of the breakage — a whole namespace's worth of types vanishing at once, not one renamed
member — points at MeshWeaver.AI no longer being among the references in-mesh NodeType
compilation sees, rather than at any individual deletion. That is a one-line difference in whatever
assembles the compilation's reference set, and it is worth confirming before anything is reverted.

What I did not do

I did not revert anything or add allow-list entries. 0 known-debt failure(s) allowed is the right
setting and the 12 should not be papered into it — AGENTS.md is explicit that an allow-list entry
here is the band-aid, and the sweep protocol (Search('nodeType:NodeType') → LspDiagnosticsForNode
per type → fix roots first) is the actual remedy.

Check the other node repos before assuming this is Reinsurance's alone — SocialMedia, Education
and Manufacturing consume the same platform image and their bakes have not all run against
s96fb969… yet.

Narrowing it — three candidates excluded by measurement, so nobody retraces them.

Not a deletion: every named type still exists on `main`

src/MeshWeaver.AI/AiSettingsNodeType.cs            ← 'AiSettingsNodeType'
src/MeshWeaver.AI/ChatClientCredentialResolver.cs  ← 'ChatClientCredentialResolver'
src/MeshWeaver.AI/HubThreadExtensions.cs           ← 'StartThread'

So this is not the #683 shape (a public surface deleted with in-mesh callers). The source is intact; the types are simply not visible where the bake compiles.

Not #2541, despite the name

feat/2276-gate-loads-external-modules touches PluginGateRunner.cs, which is exactly the right neighbourhood — but the diff is a pure refactor of that block. MeshWeaver.AI.dll was already Modules:Assemblies:0 and Modules:Required:0 before it; the change only lifts the dictionary into a variable so extra --module paths can be appended. Behaviour for the AI module is unchanged.

Not a failure to resolve the module

The gate fails RED with an explicit message when a required module does not resolve beside the binary ("the gate's required module(s) did not resolve… A run whose modules are missing cannot gate"). That did not happen — the run proceeded to compile and produced 12 CS0246/CS1061/CS0103. So MeshWeaver.AI.dll was found and activated.

Which leaves the interesting question

The module loaded, the types exist in it, and in-mesh source still cannot name them. That is a registration / compile-reference question, not a packaging one: either the AI module's assembly stopped being contributed to the reference set that NodeType compilation sees, or its types stopped being registered in a way includeGlobalTypes picks up.

Worth checking against tonight's two changes that touch exactly that seam:

A host-bound mesh builder carries its configuration — the SERVE half of #1209 (#2517) #2534 — MeshHostApplicationBuilder now takes the configuration at construction, so Features:StaticRepoSync:Partitions is honoured where it previously read as absent (that was the whole defect). The gate sets Features:StaticRepoSync:Partitions:0 = Agent. A setting that was silently ignored and is now obeyed is a behaviour change on the module path by construction — and this is the first bake to run with it.
AI tools: 22 Task bridges gone, 17 uncancellable tool calls fixed, the ThreadPool hop made drainable #2537 — the AI Task-bridge purge, which is the only other change in the window touching MeshWeaver.AI itself.

I have not confirmed either; both are hypotheses with a reason, not findings. The decisive experiment is cheap: bake the same Reinsurance commit against the last-green framework s81a9b60ed905b4f5263f55ff8369976d and the red s96fb96913046dff7a1d6773286ad3fc8, and diff what the compilation's reference set contains.

Retracting the #2534 hypothesis from my previous comment — I checked it and it does not hold.

I suggested #2534 was the likely cause on the reasoning that Features:StaticRepoSync:Partitions had been silently ignored and is now honoured, so the gate would newly serve Agent from an empty in-memory partition. That reasoning requires the gate's builder.Configuration to have been null before. It never was:

PluginGateRunner.cs:701   .InstallConfiguredModules(gateModules, …)

InstallConfiguredModules is precisely the helper that did hand the configuration over — that is what #2534's whole finding turned on (the portal composes its own module union and calls InstallAssemblies directly; the gate does not). So the gate has always read that setting, and #2534 changed the portal, not this path.

Exclusions so far, so the search space is small

candidate	excluded by
a public surface was deleted (#683's shape)	all five types present on `main`: `Thread.cs:447` (`ThreadMessage`), `AiSettings.cs:15`, `AiSettingsNodeType.cs`, `ChatClientCredentialResolver.cs`, `HubThreadExtensions.cs` (`StartThread`)
types moved to another assembly	all five still under `src/MeshWeaver.AI/`
#2541 (`gate-loads-external-modules`)	pure refactor; `MeshWeaver.AI.dll` was already `Modules:Assemblies:0` and `Modules:Required:0`
the module failed to resolve	the gate fails RED and names it; instead it compiled and produced CS0246
#2534 (configuration at construction)	the gate uses `InstallConfiguredModules`, which always passed configuration

What remains is a change inside itself or in how its types reach the compile surface, between framework (green, 20:38) and (red, 21:37). The only merge in that window touching the assembly is #2537 (the AI -bridge purge). That is where I would look next, and I have not verified it.

The decisive experiment is unchanged and cheap: bake the same Reinsurance commit () against both framework builds and diff what the compilation's reference set contains. That answers it without guessing.

What remains is a change inside MeshWeaver.AI itself, or in how its types reach the compile
surface, between framework s81a9b60ed905b4f5263f55ff8369976d (green, 20:38) and
s96fb96913046dff7a1d6773286ad3fc8 (red, 21:37). The only merge in that window touching the
assembly is #2537 (the AI Task-bridge purge). That is where I would look next, and I have
not verified it.

The decisive experiment is unchanged and cheap: bake the same Reinsurance commit (7f454af0)
against both framework builds and diff what the compilation's reference set contains. That answers
it without guessing.

(Reposting the closing paragraphs — the previous comment lost four code spans to shell expansion,
so it read as if the sentences had no subjects. The exclusion table above it is intact.)

Attributed: `35a9c95c4`, and the subject line says it

35a9c95c4  2026-08-27 20:58:11 +0200
"The AI engine leaves the content surface — the gate lands it as a MODULE (#2276)"

20:58 sits exactly between the green bake (20:38) and the red one (21:37), and its diff is four
files:

src/MeshWeaver.Compiler/FrameworkBuildIdentity.cs        ← the framework hash itself
tools/MeshWeaver.PluginTester/PluginGateRunner.cs        ← the gate
tools/MeshWeaver.PluginTester/*.csproj  (×2)             ← the module closure lane

FrameworkBuildIdentity.cs is what produces the identity that changed from
s81a9b60ed905b4f5263f55ff8369976d to s96fb96913046dff7a1d6773286ad3fc8. So this commit is the
framework change, not merely a commit inside its window.

The mechanism, and it is one line of composition

In-mesh NodeType compilation builds its reference set at
MeshNodeCompilationService.cs:183-185:

private readonly Lazy<IReadOnlyList<MetadataReference>> meshReferences = new(() =>
    CompileReferences.ComposeWithModules(
        hub.ServiceProvider.GetServices<InstalledModuleAssembly>().ToArray()));

— a base set plus the assemblies of installed modules, registered one-by-one at
MeshBuilder.cs:231 (services.AddSingleton(new InstalledModuleAssembly(assembly))).

So AI types reach in-mesh source either because the AI engine is part of the content surface,
or because MeshWeaver.AI is registered as an InstalledModuleAssembly. This commit moves it
from the first to the second. The gate's required-module check still passes — the module resolves and
loads, which is why nothing failed RED — but AiSettings, ThreadMessage, AiSettingsNodeType,
ChatClientCredentialResolver and the StartThread extension are no longer where Reinsurance's
in-mesh source was resolving them from.

That matches every symptom precisely: a cluster of types from one assembly disappearing at once,
with the assembly itself present, no deletion, and no gate-level error.

This supersedes both of my earlier guesses

#2534 was retracted above. #2537 was also wrong — its diff touches only MeshPlugin.cs and
Plugins/* (tool implementations), and no module registration, AiMeshModuleAttribute, global-type
or NodeType-registration code. It cannot have moved the compile surface.

What this does not settle

Whether Reinsurance's in-mesh source should be following the AI engine, or whether the module's
assembly should be reaching the compile surface and is not. Those are opposite fixes:

if the intent is that AI types remain available to in-mesh source, then the module's
InstalledModuleAssembly registration is not reaching this mesh's service tree in the bake, and
that is the bug;
if the intent is that content stops depending on the AI engine directly, then the 12 Reinsurance
NodeTypes need porting, and this is expected fallout of MeshWeaver.AI leaves the platform: carve out the three non-AI surfaces, then move the engine to MeshWeaver.Plugins #2276 that simply had no gate to announce
it.

The commit's own message ("leaves the content surface") reads like the second. If so, the
right follow-up is not a revert but a port plus a heads-up to every node repo — and the fact that
this surfaced only because a bake happened to re-run on an unchanged commit is itself worth fixing:
nothing announced a content-surface removal to the repos that consume it.

🚨 Either way the ordering against #2494 stands. The fleet has not rolled since 14:27, so no
instance has met this framework. Fixing the roll before this is resolved delivers 12 CompileError
NodeTypes to production, which refuse portal readiness.

Blast radius: staggered, and the most exposed repo has not met it yet

Each node repo pulls its own platform image, so they encounter the new framework at different times.
Measured just now:

repo	latest main bake	framework	result
`MeshWeaver.Reinsurance`	21:37	`s96fb96913046dff7a1d6773286ad3fc8`	167/179 — 12 new
`MeshWeaver.SocialMedia`	21:38	`sae3a9fec4bd24c473d387132a4d86ba8`	43/43 ✅
`MeshWeaver.Manufacturing`	21:38	(no bake job in this run)	—
`MeshWeaver.Education`	19:07	(pre-change)	red for an unrelated reason — #2548

Two things follow.

SocialMedia's green is not evidence that the change is safe. It baked against a third framework
(sae3a9fec…, neither the green nor the red Reinsurance one) and its 43 NodeTypes do not reference
the AI engine. It discriminates nothing about this defect.

🚨 Education is the repo to watch, and it has not baked against the new framework at all. Its
last main bake is 19:07 — before 35a9c95c4 (20:58) — and it is red for the separate view-pack
reason (#2548). It also carries by far the most AI-dependent content: AgenticBusiness,
AgenticOffice, AgenticPrimer, AgenticPrimerDe, AgenticEngineering. If in-mesh source there
names AiSettings, ThreadMessage or StartThread the way Reinsurance's does, it meets the same
wall on its next bake — and it will look like a new failure on whatever change happens to trigger
that run, not like fallout from this one.

Worth doing before that happens: grep the node repos' in-mesh source for the five names, so the
port list is known in advance rather than discovered one red bake at a time.

ThreadMessage · AiSettings · AiSettingsNodeType · ChatClientCredentialResolver · StartThread

That is the announcement this change did not make.

Correction: the 12 are not Reinsurance's content. They span THREE packages, and five are `Store`.

I said above that Education "has not met it yet" and was "the repo to watch". Both wrong. The bake
names every failing type, and I should have read that before reasoning about which repo owns them:

RED Edu/PromptCell

RED Store/Catalog
RED Store/Installer
RED Store/Maintenance
RED Store/Order
RED Store/Plugin

RED UWDeepfield/IndustryNewsFeed
RED UWDeepfield/TreatyCommunication
RED UWDeepfield/TreatyDecision
RED UWDeepfield/TreatyIteration
RED UWDeepfield/TreatyMemento
RED UWDeepfield/TreatySubmission

Five of the twelve are Store/* — the plugins repo's own Store package, which every instance
runs. Store/Catalog and Store/Plugin are what render the store front and its package pages.
That is a materially bigger surface than a single vertical's content, and it is the part that should
drive the decision.

One is Edu/PromptCell — so Education's content is already breaking. It simply surfaced
through Reinsurance's gate, because that gate installs the Edu package as a dependency. My "not yet
affected" was an artefact of looking at which repo's CI happened to run, not at what the run
compiled.

Six are UWDeepfield/*, Reinsurance's own — and a grep of that repo for the five names finds
exactly two files, both using only .StartThread(:

UWDeepfield/IndustryNewsFeed/Source/IndustryNewsFeedLayoutAreas.cs
UWDeepfield/TreatySubmission/Source/TreatyDecisionLayoutAreas5.cs

So the other four UWDeepfield types fail through shared source or a dependency, not their own direct
use — which means a port list built by grepping each repo would have missed a third of them. The
bake's own RED list is the authority; a text search is not.

What this changes

The decision is not "port one vertical's content". Store/* is platform-adjacent content that
every portal serves, so "content stops depending on the AI engine" means changing the Store
package too — and that is a much bigger call than MeshWeaver.AI leaves the platform: carve out the three non-AI surfaces, then move the engine to MeshWeaver.Plugins #2276's commit message implies on its face.
Store/Catalog appearing here is worth cross-checking against
MeshWeaver.Plugins#776, which reports Store/Catalog intermittently failing the mesh gate
("did not answer within 15s"). Different symptom, plausibly the same root; worth confirming before
they are treated as two problems.
The staggering point still holds, but for the opposite reason: repos are not protected by not
having baked yet. They are exposed the moment any bake anywhere installs these packages.

Evidence now leans toward "the module's assembly should reach the compile surface and does not"

Stating this as a weighting, not a conclusion — I have been wrong three times on this issue tonight
by publishing an inference before checking it, so here is what is measured and what is not.

Measured. MeshBuilder.cs:218-233 composes the compile reference set as TPA + installed
modules, and its comment states the transition exactly:

a module leaving the publish closure leaves TRUSTED_PLATFORM_ASSEMBLIES, so compilation composes
TPA + these

So before 35a9c95c4, MeshWeaver.AI was in the publish closure → in TPA → visible to in-mesh
compilation unconditionally. After it, the only route is the InstalledModuleAssembly singleton
registered a few lines below.

Measured. That registration is deliberately skipped for a skewed module:

Only the modules that actually installed are recorded as installed. A skewed one is deliberately
NOT in this list: it contributes no nodes, and letting it into the in-mesh compile reference set
would hand every dynamic NodeType the same broken signatures.

That would explain the symptom exactly — module loads, required-module check passes, types absent.

Measured, and it argues against that explanation: the bake log contains no skew or
incompatible-module report (grep -i "incompatible|skew|MissingMethod|TypeLoad" → nothing). So the
AI module was not classified incompatible; it installed normally and should be in the list.

Not measured, and this is the gap: whether the InstalledModuleAssembly singletons actually
reach the service provider the compile service resolves from, in the bake's mesh specifically.
MeshNodeCompilationService takes them from hub.ServiceProvider through a Lazy whose comment
asserts "modules install at boot, before any compile runs" — an ordering claim I have not verified
holds for the gate's composition.

Why this matters for the decision

It shifts the likely fix from "port 12 NodeTypes across three packages, including the Store" —
which would be a substantial content change touching what every instance serves — toward "the
transition dropped one registration path and needs it restored", which is small and does not touch
content at all.

I would not act on that yet. The one experiment that settles it is still the cheap one: bake
7f454af0 against both frameworks and dump what CompileReferences.ComposeWithModules actually
returns in each. That answers "is MeshWeaver.AI in the reference set?" directly, instead of
reasoning about whether it ought to be.

The change knew it was removing a surface, restored four assemblies, and missed the fifth — the engine itself

35a9c95c4's diff to tools/MeshWeaver.PluginTester/MeshWeaver.PluginTester.csproj is the whole
story, and it is worth quoting rather than paraphrasing:

-    <ProjectReference Include="..\..\src\MeshWeaver.AI\MeshWeaver.AI.csproj" />
+    <!-- 🚨 MeshWeaver.AI is deliberately NOT a ProjectReference (#2276): the engine left the
+         content surface and ships as a registry MODULE … A compiled reference here would put
+         MeshWeaver.AI back into the framework identity for every bake host, and an image shipping
+         AI.dll in its app closure 409s the registry module. -->
+    <!-- These four used to arrive TRANSITIVELY through MeshWeaver.AI and are still part of the
+         content surface (in-mesh source compiles against them), so the closure keeps them
+         directly now that the engine reference is gone. -->
+    <ProjectReference Include="…\MeshWeaver.Mesh.Operations.csproj" />
+    <ProjectReference Include="…\MeshWeaver.Application.Styles.csproj" />
+    <ProjectReference Include="…\MeshWeaver.Markdown.Collaboration.csproj" />
+    <ProjectReference Include="…\MeshWeaver.ContentCollections.Indexing.Graph.csproj" />

The author identified the exact hazard and handled four fifths of it. Removing the reference
drops everything it used to supply transitively; four such assemblies were named and restored
explicitly, with the reason written down.

What was not accounted for is MeshWeaver.AI's own types. The change treats the engine as
something in-mesh source reaches through rather than something it compiles against. The 12 RED
NodeTypes say otherwise — Edu/PromptCell, five Store/*, six UWDeepfield/* name AiSettings,
ThreadMessage, AiSettingsNodeType, ChatClientCredentialResolver and StartThread directly.

So the earlier framing was wrong in both directions

Not "the registration path broke" (it is working as designed — the module lane is deliberate), and
not simply "port the content" (nobody decided that; the inventory was incomplete). It is:

the AI engine's public types are part of the content surface, and the change that moved the
engine out did not carry that surface with it.

Which makes the decision specific, and the constraint is already documented

The comment rules out the obvious fix in advance, correctly:

A compiled reference here would put MeshWeaver.AI back into the framework identity for every bake
host, and an image shipping AI.dll in its app closure 409s the registry module.

So restoring the ProjectReference trades this defect for a different one. The real options are:

Make the module lane supply the compile surface — i.e. the InstalledModuleAssembly route
genuinely reaching CompileReferences.ComposeWithModules in the bake. If that already works for
other modules, this is a gap in the AI module's path specifically and is small.
Split the engine: a small MeshWeaver.AI.Contract-shaped assembly carrying the types content
compiles against (AiSettings, ThreadMessage, StartThread, …) stays in the closure; the
engine itself rides the module lane. This is the shape the four restored references already
imply.
Port the 12 off AI types — the largest option, and the one that touches Store/*, which every
instance serves.

(2) looks closest to the intent already expressed in that comment, but this is a design call about
what "content surface" means, and it is yours rather than mine.

Nothing here changes the ordering against #2494. The fleet has not rolled since 14:27, so no
instance has met this framework; fixing the roll first ships 12 CompileError NodeTypes.

Same cause as #2563, two different consequences — worth reading together

#2563 (filed 00:57 on memex-cloud) and this issue are the bundle half and the compile half of
one change: the AI engine leaving ContentSurfaceAssemblies (#2524 / 35a9c95c4) to ship as a
registry module.

	#2563 — bundle half	#2561 — compile half
what fails	prebuilt bundles referencing AI are declined	in-mesh source referencing AI types will not compile
why	dependency records not comparable: bundles carry `ref:<hash>`, a module presents `mvid:<…>`	AI left TPA with the publish closure; types now reachable only via `InstalledModuleAssembly`
symptom	218 of 351 NodeTypes recompile on first access	12 NodeTypes `CompileError` — `Edu/PromptCell`, 5× `Store/`, 6× `UWDeepfield/`
severity	degraded, not an outage	refuses portal readiness

#2563 names the mechanism more precisely than I did and is worth quoting here, because it explains
why nothing failed loudly: ref: and mvid: are not comparable, so the gate declines correctly.
A gate doing its job produced a silent, fleet-wide recompile.

Two things this changes about what I wrote above

1. memex-cloud has ALREADY met the change. I said no instance had, on the strength of memex
not having rolled since 14:27 (#2494/#2553). That is true of memex and false of memex-cloud,
which rolls on a different path. So the "stalled roller is the only thing protecting production" line
holds for one instance, not the fleet.

2. The observed severity there is degradation, not breakage — 218 first-access compiles, pages
working. That is the bundle half landing alone. Whether memex-cloud also carries the twelve
CompileError types depends on which of those packages it has installed; Store/* is on every
instance, so that is worth checking directly rather than inferring.

Both point at the same decision, which is the one this issue ends on: whether the engine's public
types are content surface (→ they must remain reachable, by a contract assembly or by the module lane
genuinely supplying the compile references) or whether content ports off them (→ 12 NodeTypes,
including the Store package every instance serves).

Fixing either half alone leaves the other. And #2563's own framing — "correctly, by a gate doing its
job" — is the right way to hold it: nothing here is misbehaving; a surface moved and two consumers
of that surface were not moved with it.

The Store/* half was already analysed, five days before it broke: Systemorph/MeshWeaver.Plugins#764.

Filed 08-27 off a Copilot review on the AI registry cutover, it names the mechanism precisely:

Store/Installer/Source/Localizer.cs imports MeshWeaver.AI for the per-user skill-source merge: AiSettingsNodeType.MergeSkillSource / .PathFor / AiSettings. Since the cutover the engine is a registry module, so Store content compiles against it only where the module is installed (ComposeWithModules).

That is this issue's mechanism, written down before the failure.

But it contains one assumption the measurement falsifies, and it is the load-bearing one:

The gate lands the engine at boot, so CI covers the composed state.

The composed state is exactly what failed. The gate had Modules:Assemblies:0 and Modules:Required:0 set to MeshWeaver.AI.dll throughout, and it fails RED naming the module when one does not resolve — it did not. The engine landed, and five Store/* types still failed CS0246 'AiSettings'.

So the broken case is not only "a deployment that removes the AI module", which is how #764 scoped its severity. It is the composed state too — module present, required, and its types still absent from the reference set.

Two independent readings now converge on the same fix. #764's first option:

move the AiSettings merge seam to a contract assembly (the frozen-namespace shape #2398 used)

is option (2) in my comment above, reached separately. Its second option — skip skill-source merging when the AI module is absent — does not cover the measured case, because nothing is absent.

And #764 names a consequence I had not: Store/Installer is among the five CompileError types, and the installer is the only route to reinstall the engine. That bootstrap deadlock was written up as hypothetical; it is the state today on any mesh baking against s96fb969…. Whichever fix lands has to leave the installer compilable without the engine, or recovery has no entry point.

Fixed for the compile surface: since #2630/#2707 the gates compose MeshWeaver.AI from the sealed plugins publication, and Reinsurance compiles 179/179 on today's image (run 33295773044). The bundle half remains #2563.

Navigation Menu

Repository navigation

🚨 A platform build published tonight removes AI types from the in-mesh compile surface — 12 Reinsurance NodeTypes broke on an UNCHANGED commit #2561

The measurement

What went missing

Why nothing went red until now

Why it is urgent rather than merely broken

Where to look

What I did not do

Not a deletion: every named type still exists on `main`

Not #2541, despite the name

Not a failure to resolve the module

Which leaves the interesting question

Exclusions so far, so the search space is small

Attributed: `35a9c95c4`, and the subject line says it

The mechanism, and it is one line of composition

This supersedes both of my earlier guesses

What this does not settle

Blast radius: staggered, and the most exposed repo has not met it yet

Correction: the 12 are not Reinsurance's content. They span THREE packages, and five are `Store`.

What this changes

Evidence now leans toward "the module's assembly should reach the compile surface and does not"

Why this matters for the decision

The change knew it was removing a surface, restored four assemblies, and missed the fifth — the engine itself

So the earlier framing was wrong in both directions

Which makes the decision specific, and the constraint is already documented

Same cause as #2563, two different consequences — worth reading together

Two things this changes about what I wrote above

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

🚨 A platform build published tonight removes AI types from the in-mesh compile surface — 12 Reinsurance NodeTypes broke on an UNCHANGED commit #2561

Description

The measurement

What went missing

Why nothing went red until now

Why it is urgent rather than merely broken

Where to look

What I did not do

Activity

rbuergi commented on Aug 27, 2026

Not a deletion: every named type still exists on main

Not #2541, despite the name

Not a failure to resolve the module

Which leaves the interesting question

rbuergi commented on Aug 27, 2026

Exclusions so far, so the search space is small

rbuergi commented on Aug 27, 2026

rbuergi commented on Aug 27, 2026

Attributed: 35a9c95c4, and the subject line says it

The mechanism, and it is one line of composition

This supersedes both of my earlier guesses

What this does not settle

rbuergi commented on Aug 27, 2026

Blast radius: staggered, and the most exposed repo has not met it yet

rbuergi commented on Aug 27, 2026

Correction: the 12 are not Reinsurance's content. They span THREE packages, and five are Store.

What this changes

rbuergi commented on Aug 28, 2026

Evidence now leans toward "the module's assembly should reach the compile surface and does not"

Why this matters for the decision

rbuergi commented on Aug 28, 2026

The change knew it was removing a surface, restored four assemblies, and missed the fifth — the engine itself

So the earlier framing was wrong in both directions

Which makes the decision specific, and the constraint is already documented

rbuergi commented on Aug 28, 2026

Same cause as #2563, two different consequences — worth reading together

Two things this changes about what I wrote above

rbuergi commented on Aug 28, 2026

rbuergi commented on Aug 30, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Not a deletion: every named type still exists on `main`

Attributed: `35a9c95c4`, and the subject line says it

Correction: the 12 are not Reinsurance's content. They span THREE packages, and five are `Store`.