Repository navigation
Fresh install cannot activate the AI engine: closure-shadow refusal + no Assemblies entry leaves Skill/Agent types unregistered #2584
Description
Measured 2026-08-28 on a fresh disposable mesh (education e2e harness, memex-portal-ai:main built 06:47Z, registry consumer against memex.meshweaver.cloud with a valid mwi_ key).
Since the engine was delisted from the image's Modules:Assemblies (the endgame of the 08-27 incident: ship it as the AI store package), a FRESH installation has no way to activate it:
- The
AIpackage installs, but landing its module is refused by design:
Module 'MeshWeaver.AI' refused: 'MeshWeaver.AI.dll' is part of the application closure, and modules/MeshWeaver.AI/ would SHADOW it at the next boot (ResolveModulePath probes the modules folder first).
(First observed as the misleadinglanding failed — the module is unchangedwarn.) - With no
Modules:Assembliesentry and no landable bundle, the engine never activates → theSkill/Agent/Providerpartitions are never served, the platform NodeTypesSkillandAgentnever register, and 13 of 37 platform-baseline packages fail to install (Install of 'Store' failed: NodeType(s) not registered: Skill,Hosting: … Skill, Agent, …) — reconcile after reconcile, every boot. Modules:Requiredstill listsMeshWeaver.AI.dll, so on a guarded deployment a roll stalls; on the harness the pod reports Healthy and simply comes up without chat, models, skills or agents.
Existing deployments survive because their engine activation pre-dates the delisting; every NEW installation hits this wall. Workaround used: set Modules__Assemblies__0=MeshWeaver.AI.dll explicitly — which the appsettings comment itself warns will shadow the store entry once one exists.
Suggested direction: as long as MeshWeaver.AI.dll ships in the app closure, the closure copy should be usable as the activation source when the package is installed (treat "in closure + package installed" as an implicit module entry), or the image should keep the Assemblies entry until the DLL leaves the closure.
Related: after the engine was force-activated, the boot wedged in a PingRequest → target=Skill … AccessContext must never be null storm (~200 fails/5min) plus [PackageInstaller] root Skill never answered after its recycle — the engine-served static Skill partition colliding with the registry still offering the (now consolidated-away) Skill/Agent packages; MeshWeaver.Plugins#799 removes that collision at the source.
🤖 Generated with Claude Code
Activity
rbuergi commentedon Aug 28, 2026
Status 2026-08-28: the delivery vehicle for the engine-as-module is MeshWeaver.Plugins#786 (open, auto-merge armed); the end-state that removes the closure-shadow refusal at its root — decoupling Blazor.Portal from MeshWeaver.AI types so the engine's DLL can leave the app closure — is filed as #2599.
Keep this open until a fresh install (the education e2e harness shape used in the report above) demonstrably activates the engine:
AIpackage installs, module lands without the shadow refusal, and theSkill/Agent/Providerpartitions serve.rbuergi commentedon Aug 28, 2026
Downstream evidence from the plugins FOLLOW_RELEASE wave (run 33179845657, dispatched 14:22Z — before plugins#814 merged at 14:54Z), bake leg on a FRESH mesh:
The CS0103 set is what this issue PREDICTS one step further downstream than the original harness reached: the in-mesh compile reference set is composed from ACTIVATED modules, so with no engine activation every plugin source referencing MeshWeaver.AI types fails on exactly those names (meshweaver-plugins-46 confirmed the 'Store/Plugin' line verbatim from the 08:31Z harness run; the CS0103s were never reached there).
Possible second defect, kept separate on purpose:
Hub AI was disposed while SubscribeRequest … deferred behind its initialization gatesdid NOT appear in the morning harness. The AI package's root hub tearing down mid-subscribe may be its own fault that #814 merely hides. Re-check on the first image built with #814 in it (core CD keys images on core HEAD; the first post-#814 mint is the #2605 merge at 15:00Z). If the line survives, it gets its own issue.rbuergi commentedon Aug 30, 2026
Fixed for the shipped shape: Plugins#814 restored the engine to the portal hosts'
Modules:Assembliesbaseline, and fresh installs activate it again — today's Education disposable-mesh runs boot with[ModuleLoad] MeshWeaver.AI … source=storeand the AI-dependent NodeTypes compile (Education#231's run, 2026-08-30). The end-state this interim fix defers — the engine as a genuinely landable, updatable module with the DLL out of the app closure — is Systemorph/MeshWeaver.Plugins#977.