Repository navigation
Local dev portal renders NOTHING: db552ffbf emptied the Debug view-pack ItemGroup while its comment still claims it keeps local dev whole #2289
Description
What is broken
db552ffbf (merged today) emptied the Debug-only view-pack ItemGroup in memex/Memex.Portal.Monolith/Memex.Portal.Monolith.csproj — while leaving the comment that says it "keeps local dev whole".
Consequence: a developer dotnet run registers no MarkdownControl view, so every control renders as its model's ToString(). Proven by E2E screenshots, not inferred.
Why this is worse than a broken dev loop
🚨 It silently degrades every E2E_LAUNCH=1 test. Text assertions still pass against the ToString() dump — the model's text is in there, so a page.GetByText(...) finds it. So the suite goes green against a portal that is rendering nothing correctly.
That is the shape this codebase keeps producing and that tonight's sweep has been clearing: a check that cannot observe the failure mode reports success. Compare #2258 (a test asserting on the in-memory dictionary while corruption happened in the serializer) and #2186 (a fix verified against a code path nothing calls).
The comment is the trap
The ItemGroup is empty and the comment above it still asserts the opposite. Anyone reading the file — or grepping for how local dev gets its views — is told the mechanism is intact. That is the same defect class as PromptCell.cs:27 claiming TrainingSimResponder "is retired" while 12 live pages call it (#1610), and as the [OUTSTANDING] header on Chart Drift naming a token that is actually provisioned but invalid (#1709).
Scope
Belongs to the modularization programme (#2169 / the view-pack lane), not to whoever trips over it. The question is whether local dev should:
- carry the packs in Debug (restore the ItemGroup, and make the comment true), or
- resolve them from the registry like production does (and then the comment should say that),
but it should not be left asserting a mechanism that no longer exists.
Acceptance
Whichever route: an E2E assertion that fails when controls render as ToString(). A text-only assertion cannot see this — that is precisely how it shipped green.
Activity
rbuergi commentedon Aug 26, 2026
Superseded — the described file/project no longer exists in this repo. Closing.
Verified against
origin/main(current tip0bc512901).The whole project is gone. PR #2293 ("Delete Blazor and the portal GUI from core", merge
commit
00cc169c5,merged 2026-08-26 11:43 UTC — today, after this issue was filed) deletes
memex/Memex.Portal.Monolith/from MeshWeaver core entirely, including the exact file this issueis about (
Memex.Portal.Monolith.csproj) and the empty DebugItemGroupit flags:The whole Monolith dev portal + GUI moved to
Systemorph/MeshWeaver.PluginsasMemex.Portal.Gui/src/Memex.Portal.Monolith, per the modularization programme (#2169 Phase B).Confirmed the bug does not exist in the new location either. The project's current home,
Systemorph/MeshWeaver.Plugins:src/Memex.Portal.Monolith/Memex.Portal.Monolith.csproj, has theDebug-only
ItemGroupcorrectly populated:— and the accompanying comment ("Debug-conditioned ships-the-bits keeps local dev whole") is
accurate there: the references ARE present, so
dotnet runin that repo registers the view packsas described.
What happened, for the record:
db552ffbf(2026-08-25 17:57 UTC, "Blazor view definitionsleave the platform: DefaultViews and GraphViews move out") emptied the
ItemGroupin this repo'scopy of the file while retiring the last two Blazor view-pack sources still living in core — a
transitional state that lasted about 18 hours before #2293 removed the whole project the next
morning. The comment genuinely was stale for that window, exactly as reported; it just isn't a
window that exists any more, in a file that doesn't exist any more, in this repo.
Nothing to fix in MeshWeaver core — closing. If local dev in the new
Memex.Portal.Monolithhomeever regresses the same way, that's a
Systemorph/MeshWeaver.Pluginsissue.