BinaryClickerV2/BinaryToggle NodeType cannot compile — layout source calls non-existent LayoutAreaHost.GetData<T>()

[meshweaver-cloud]

What is failing

The NodeType BinaryClickerV2/BinaryToggle cannot build its assembly, so the node type is dead — no BinaryToggle instance can be created or rendered. The single blocking Roslyn error is in its layout-area source: a call to host.GetData<BinaryToggleData>() on a LayoutAreaHost, a method that does not exist on that type. The only GetData<T> in scope is the WorkspaceOperations.GetData<T>(EntityStore) extension, which requires an EntityStore receiver — hence the CS1929.

Probable cause

Author error in the node's own source — high confidence. The read was written against an assumed API:

• Everything else in the diagnostic set is warnings (duplicate using directives the compile harness prepends, missing XML comments); the GetData call is the only error.
• Layout Areas documents the actual surface: view functions read through host.Workspace.GetStream<MeshNode>(), and node content goes through GetMeshNodeStream(path) + ContentAs<T> (CRUD Operations).
• The working V1 sibling BinaryClicker/BinaryToggle/Source/BinaryToggleLayoutAreas uses exactly that pattern and compiles fine.

Impact

Contained and low-severity: a broken node type in a sandbox/demo space ("Binary Clicker V2"); no other spaces or platform components are affected, and the compilation pipeline behaved correctly — it caught the error and reported it with full diagnostics. The defect is persistent, though: the sources have carried it since they were authored in early July, so every pod that attempts this compile will fail the same way until the source is fixed.

Where to look / fix

1. BinaryClickerV2/BinaryToggle/Source/BinaryToggleLayout — the var data = host.GetData<BinaryToggleData>(); line. Replace with the documented workspace read, mirroring the V1 layout: host.Workspace.GetStream<MeshNode>() filtered to the hub's path, or workspace.GetMeshNodeStream(path).Select(n => n.ContentAs<BinaryToggleData>(...)).
2. While there: the button action is async (_, __) => { await host.UpdateAsync(...); } — the layout docs require synchronous click handlers (return Task.CompletedTask); async handlers can deadlock the layout pump under load.
3. Stale near-duplicates of the same broken code sit at BinaryClickerV2/Source/BinaryToggleData and BinaryClickerV2/Source/BinaryToggleLayout (they are not part of this compile). Fix or delete them so the broken pattern isn't copied back.
4. After fixing, recycle the BinaryClickerV2/BinaryToggle NodeType hub so a fresh compile runs, and confirm it builds.

Checked for existing incidents/issues covering this component and symptom — none found.

---

Evidence

Fingerprint	c0b1424c7beb28e0
Category	MeshWeaver.Graph.Configuration.MeshNodeCompilationService
Severity	Error
Exception	MeshWeaver.Compiler.CompilationException
Top frame	MeshWeaver.Compiler.EmitPipeline.EmitCompilationToDirectory(CSharpCompilation compilation, String nodeName, String nodePath, String releaseDir, IReadOnlyCollection1 manifestResources, CancellationToken ct, Action2 captureFailure)
Namespace	memex
Pods	memex-portal-deployment-b8f65dc46-vsnwh, memex-portal-deployment-b8f65dc46-lxkzg
Occurrences	2
First seen	2026-09-10 02:26:49Z
Last seen	2026-09-10 02:30:43Z

Recent log lines

2026-09-10 02:26:49Z memex-portal-deployment-b8f65dc46-vsnwh fail: MeshWeaver.Graph.Configuration.MeshNodeCompilationService[0]
      Failed to compile assembly for node 'BinaryClickerV2/BinaryToggle'.
      --- Compiler diagnostics ---
      Compilation failed for 'BinaryClickerV2/BinaryToggle':
      CS1929 Error (line 58): 'LayoutAreaHost' does not contain a definition for 'GetData' and the best extension method overload 'WorkspaceOperations.GetData<BinaryToggleData>(EntityStore)' requires a receiver of type 'MeshWeaver.Data.EntityStore'
      CS0105 Warning (line 27): The using directive for 'System.ComponentModel.DataAnnotations' appeared previously in this namespace
      CS0105 Warning (line 28): The using directive for 'MeshWeaver.Domain' appeared previously in this namespace
      CS0105 Warning (line 29): The using directive for 'System' appeared previously in this namespace
      CS0105 Warning (line 30): The using directive for 'System.Reactive.Linq' appeared previously in this namespace
      CS0105 Warning (line 31): The using directive for 'MeshWeaver.Layout' appeared previously in this namespace
      CS0105 Warning (line 32): The using directive for 'MeshWeaver.Layout.Composition' appeared previously in this namespace
      CS1591 Warning (line 44): Missing XML comment for publicly visible type or member 'BinaryToggleData.Name'
      CS1591 Warning (line 46): Missing XML comment for publicly visible type or member 'BinaryToggleData.IsOn'
      CS1591 Warning (line 56): Missing XML comment for publicly visible type or member 'BinaryToggleLayout.Toggle(LayoutAreaHost, RenderingContext)'
      CS1591 Warning (line 83): Missing XML comment for publicly visible type or member 'BinaryClickerV2_BinaryToggleMeshNodeProviderAttribute'
        … and 1 more diagnostic line(s) — the complete set is on the exception below and in the NodeType's CompilationDiagnostics.
      --- Source discovery ---
      Executed source queries (2):
        - namespace:BinaryClickerV2/BinaryToggle/Source scope:subtree nodeType:Code
       …[truncated]
2026-09-10 02:30:43Z memex-portal-deployment-b8f65dc46-lxkzg fail: MeshWeaver.Graph.Configuration.MeshNodeCompilationService[0]
      Failed to compile assembly for node 'BinaryClickerV2/BinaryToggle'.
      --- Compiler diagnostics ---
      Compilation failed for 'BinaryClickerV2/BinaryToggle':
      CS1929 Error (line 58): 'LayoutAreaHost' does not contain a definition for 'GetData' and the best extension method overload 'WorkspaceOperations.GetData<BinaryToggleData>(EntityStore)' requires a receiver of type 'MeshWeaver.Data.EntityStore'
      CS0105 Warning (line 27): The using directive for 'System.ComponentModel.DataAnnotations' appeared previously in this namespace
      CS0105 Warning (line 28): The using directive for 'MeshWeaver.Domain' appeared previously in this namespace
      CS0105 Warning (line 29): The using directive for 'System' appeared previously in this namespace
      CS0105 Warning (line 30): The using directive for 'System.Reactive.Linq' appeared previously in this namespace
      CS0105 Warning (line 31): The using directive for 'MeshWeaver.Layout' appeared previously in this namespace
      CS0105 Warning (line 32): The using directive for 'MeshWeaver.Layout.Composition' appeared previously in this namespace
      CS1591 Warning (line 44): Missing XML comment for publicly visible type or member 'BinaryToggleData.Name'
      CS1591 Warning (line 46): Missing XML comment for publicly visible type or member 'BinaryToggleData.IsOn'
      CS1591 Warning (line 56): Missing XML comment for publicly visible type or member 'BinaryToggleLayout.Toggle(LayoutAreaHost, RenderingContext)'
      CS1591 Warning (line 83): Missing XML comment for publicly visible type or member 'BinaryClickerV2_BinaryToggleMeshNodeProviderAttribute'
        … and 1 more diagnostic line(s) — the complete set is on the exception below and in the NodeType's CompilationDiagnostics.
      --- Source discovery ---
      Executed source queries (2):
        - namespace:BinaryClickerV2/BinaryToggle/Source scope:subtree nodeType:Code
       …[truncated]

_{Opened automatically from Admin/_LogIncident/c0b1424c7beb28e0. Recurrences are folded into this issue rather than opening new ones.}

[rbuergi]

Investigated 2026-09-10. Three corrections to the draft, and the fix cannot be made from an agent session.

1. The portal is memex.systemorph.com, not memex.meshweaver.cloud

The evidence table's namespace: memex is the Kubernetes namespace, and per
Deployments/memex that is host memex.systemorph.com (db memex). memex.meshweaver.cloud is
namespace memex-cloud. This portal has no BinaryClicker* at all. #1391 walked into the same
trap and corrected itself mid-thread — worth stating up front here, because the MCP server named
memex points at the other one.

2. #1391 already covered this, and was closed on a false negative

#1391 — "Edu/Course and BinaryClickerV2/BinaryToggle are at CompileError on the running
production image", opened 2026-08-13, closed 2026-08-14.

Same NodeType, same CS1929, same two source nodes, same "6× CS0105 + 5× CS1591 — the camouflage".
So the draft's "Checked for existing incidents/issues covering this component and symptom — none
found" is wrong; searching BinaryClicker on this repo returns it.

It was closed on:

get_diagnostics @BinaryClickerV2/BinaryToggle → {"status":"Unknown","message":"Not found: …"}

read as the type is gone. It was never gone. #1391's own earlier comment had already recorded
why: "BinaryClickerV2 is not visible to an admin MCP read, so it is a private-partition copy of
rsalzmann/BinaryClicker". Not found is what a denied read returns too — denied and absent
are the same string — so the close was made on a probe that could not tell them apart. Four weeks
later, unchanged, it is this issue.

3. The node still exists — measured, with a positive control

probe	BinaryClickerV2	PearlTechnology (readable control)
get @…	Not found	full node
search 'namespace:… scope:subtree'	0	10+
get_diagnostics @…	Unknown / Not found	—
lsp_check_node @…	{"ok":true,"diagnostics":[]} — even for invalid C# (→ #3888)	—
autocomplete '@/…/'	names Binary Clicker (Space) and Binary Toggle (NodeType)	names them
get @Admin/Partition/<Ns>	Active, schema binaryclickerv2, created 2026-07-01	Active

The partition drill-down runs RunQueryNodes(…, useSecurityFilter: false) while search/get run
ValidateRead — same storage, same query shape, one differing input. So the difference is
access, not deletion. PearlTechnology answers on every probe, which is the negative control
that rules out a broken instrument.

Consistent with the runtime: the compile failed 7 times across 3 pod generations between
02:26:49Z and 03:11:37Z, i.e. on every boot, long after the triage read it.

4. What actually has to happen — and why not from here

The draft's steps 1–4 are the right content fix (host.GetData<T>() → the documented workspace
read; the async click handler; the stale near-duplicates under BinaryClickerV2/Source/). But
BinaryClickerV2 is a private partition, and global admin is a platform admin, not a data
superuser — Admin/_Access/rbuergi_Access grants nothing here. Reading or patching those Code
nodes needs the owner (rsalzmann, per #1391) or an explicit break-glass elevation, which is the
owner's decision and not something a session should take unilaterally.

Worth noting the cheapest resolution may be deletion, not repair: Admin/Partition holds
four abandoned demo partitions from the same 30 hours — binary-clicker (06-30),
BinaryClicker (06-30), binary-clicker-space (07-01) and BinaryClickerV2 (07-01). The V2 type
has never once compiled since it was authored, so it is previouslybroken and cannot gate
readiness (WasHealthy is false) — the cost is purely the per-boot fail: line and the incident
it manufactures.

5. The generalisable defect, filed and fixed separately

🚨 The pre-prod sweep AGENTS.md mandates cannot see this NodeType either.
search 'nodeType:NodeType content.compilationStatus:Error' on this portal returns 0 right now,
while this type sits at Error and fails every boot. The sweep runs as the caller (RLS-filtered);
the readiness gate enumerates as system. AGENTS.md claimed the two agree "BY CONSTRUCTION" — true of
the verdict, false of the denominator. Corrected, with the positive control for separating denied
from deleted, in #3886.

And the pre-flight the /code edit loop runs, lsp_check_node, returns {"ok":true} for this same
path even when handed text that is not C# — #3888.

_{All reads in this pass were read-only (get / search / autocomplete / get_diagnostics /
lsp_check_node). No mesh data was changed.}

[rbuergi]

Reopened — the 2026-09-10 sweep was not a triage decision

This issue was closed not_planned at 2026-09-10T14:30:08Z by a bulk sweep that PATCHed every open issue in all 13 Systemorph repositories — 311 issues in twelve minutes, no comment on any of them — after a session was asked to "close all issues in all repos". Nothing on this thread was read, and no judgement was made about this issue.

All 82 issues the sweep closed in the MeshWeaver fleet were reviewed afterwards. This one is unresolved: The NodeType is still dead on memex.systemorph.com. This is the SECOND wrongful close of this defect — #1391 was closed on a "Not found" and re-filed here.

Sixteen of the 82 were left closed — their fix had actually landed, or the author had withdrawn them; those should have read completed, not not planned.

[rbuergi]

Investigated 2026-09-11. The fix is still unreachable from an agent session — and the reason is now precise enough to act on.

Not closing this. It would be the third close (#1391 on a Not found, then the 311-issue bulk
sweep), and nothing below licenses one.

1. The partition exists — established positively, on the right portal

The earlier note that get @Admin/Partition/<Ns> "answers Not found for this identity" was
measured on memex.meshweaver.cloud, where no Binary* partition has ever existed
(namespace:Admin/Partition scope:children name:*Binary* → 0). On the portal this issue is
actually about it answers fine:

probe, memex.systemorph.com (/api/version → 3.0.0+45306a33e)	result
get @Admin/Partition/BinaryClickerV2	state: Active, schema: binaryclickerv2, createdAt: 2026-07-01T04:32:52Z, version: 4
search 'namespace:Admin/Partition scope:children'	106 partitions, truncated: false — BinaryClickerV2 and BinaryClicker both listed
get @BinaryClickerV2/BinaryToggle	Not found
search 'namespace:BinaryClickerV2 scope:subtree'	0
autocomplete '@/BinaryClickerV2/'	generic suffixes only — the drill-down that named the nodes in August is gone (#3890 closed that bypass)

So the partition is not deleted, and every node in it is invisible to a global platform
admin (Admin/_Access/rbuergi_Access, role Admin). That is the documented shape, not a
malfunction: a platform admin is not a data superuser, and Admin/_Access confers nothing on
spaces. The distinction this issue keeps dying on — denied vs. deleted, at node granularity —
remains unanswerable by anything I can run.

2. Two instruments that look like answers, and are not

The mandated sweep returns 0, over a denominator that excludes the subject.
search 'nodeType:NodeType content.compilationStatus:Error' → 0, truncated: false. But
search 'nodeType:NodeType' returns 136 readable NodeTypes, truncated: false, and
BinaryClickerV2/BinaryToggle is not one of them. So: 0 of 136 readable NodeTypes — the sweep
is structurally blind to this node and is not evidence about it in either direction.

recycle's refusal is content-free. Confirmed with the invented-path control:

call	answer
recycle @BinaryClickerV2/BinaryToggle	Recycle requires Update permission on the target node — …
recycle @ThisPartitionDoesNotExist_zzz9911/NoSuchType	byte-identical

Authorization runs before the node is resolved, so the message is emitted for a path that cannot
exist. It says nothing about the node — only that I cannot recycle it, which blocks step 4 of
the original plan outright.

3. This issue's own evidence table has stopped tracking reality

Admin/_LogIncident/c0b1424c7beb28e0, re-read today: occurrences: 62, 26 pods,
lastSeen: 2026-09-11T05:22:40Z. None of that belongs to this defect. The normaliser masks the node
path (Failed to compile assembly for node '{value}'), so the fingerprint is a group, and all ten
retained samples[] are one of three other node paths:

• MeshWeaver/samples/Graph/Data/Type/article — CS0246 Article, Matched Code nodes (0)
• MeshWeaver/samples/Graph/Data/Northwind/Product — CS0246 Supplier / Category
• Hosting/InstanceAction — CS0103 ObserverExpiryTests ×1307

Not one is BinaryClickerV2/BinaryToggle. The last occurrence of this node path anywhere in
the record is still the 2026-09-10T02:30:43Z in the issue body.

The table above only looks right because the incident carries
error: "Resource not accessible by integration" beside occurrencesAtLastComment: 2 — the GitHub
sync has been failing since filing, so the counter froze at the two that really were this node. Had
it worked, this issue would now claim 62 occurrences across 26 pods and two portals for a node not
seen in 27 hours.

Tempting inference, explicitly not drawn: that the absence of BinaryClickerV2 from a window
spanning 01:11Z–05:22Z across three pod generations means the node is gone. samples[] is ten
deep against 62 occurrences; it cannot carry that weight. Reading a truncated window as absence is
exactly the move that closed #1391.

4. The instrument that will answer this exists — it is nine hours newer than the running image

nodetype_bake / bake-report enumerates as system, past RLS, so it names a failing NodeType in
a partition nobody can read. /health on memex.systemorph.com is public and currently Degraded,
so it is reachable and reporting — and it publishes exactly five checks: content-types,
pending_module_activation, required_modules, bundle_adoption, roll-up. No bake-report.

running image	3.0.0+45306a33e, built 2026-09-10T23:37:03Z
bake-report lands in	5cf38a690 feat(#3703,#3704): publish the two bake verdicts on /health, 2026-09-11T08:09Z
git ls-tree 45306a33e -- src/MeshWeaver.Hosting/NodeTypeBakeReportRegistry.cs	empty (control: AGENTS.md and DynamicTypePreWarmer.cs at the same commit both list)
distance	58 commits behind main

Nothing is misconfigured — the code is not in the binary. Once memex.systemorph.com rolls to an
image ≥ 5cf38a690, /health answers this issue with no grant and no elevation. That is the
cheapest path to a verdict and it needs no decision from anyone.

5. What is actually blocked, and on whom

Steps 1–4 all require write access to a private partition. Elevation (break-glass) is the
partition owner's decision and audited — not something a session takes unilaterally, and not
something a platform-admin grant covers. #1391 recorded the owner as rsalzmann; I did not
re-establish that (BinaryClickerV2/_Access is itself inside the partition, so it reads as 0 to me).

On the two stale near-duplicates (step 3) — recommend delete, not fix. The compile's own
--- Source discovery --- queries only BinaryClickerV2/BinaryToggle/Source scope:subtree and
…/Test scope:subtree; the copies at BinaryClickerV2/Source/* fall outside both. Nothing compiles
them, so repairing them produces no verification signal at all — you would be editing code no
instrument can tell you is correct, which is the condition that let the broken pattern sit since
July. And the V2 space has never compiled once since it was authored on 2026-07-01, so a delete
cannot regress any working behaviour.

Worth weighing the same way #1391's thread suggested: Admin/Partition still holds four
abandoned demo partitions from the same 30 hours — binary-clicker (06-30), BinaryClicker
(06-30), binary-clicker-space (07-01), BinaryClickerV2 (07-01). Retiring them may be cheaper
than repairing one, and removes the per-boot fail: line that manufactures this incident. Also the
owner's call.

The source is mesh-only — so there is no repo-side route either. Checked every node repo that
could hold it (Memex, MeshWeaver.Plugins, .Education, .Crm, .Reinsurance, .SocialMedia,
.Manufacturing) plus core's own samples/*/Data: 0 files match BinaryToggle|BinaryClicker,
against a positive control of 15,325 files matching MeshWeaver over the same trees. So this is
not a case where a mesh edit would be overwritten by the next GitSync — there is no upstream at all,
and an MCP write to the live portal is the only route the content has.

6. Landed instead

The generalisable findings are committed rather than left in this thread — #4016:

• Doc/GUI/LayoutAreas — a new Reading the Hosting Node's Own Content section. This is the
  actual root cause of the author error: LayoutAreaHost has no GetData<T>(), its GetDataStream<T>(id)
  addresses the layout area's /data/{id} scratch and not the node, and host.GetData<T>() binds
  to WorkspaceOperations.GetData<T>(EntityStore) — so the compiler reports "requires a receiver of
  type EntityStore" rather than "no such method", and sends the reader hunting for an EntityStore
  that was never the answer. The documented read (host.Workspace.GetMeshNodeStream() — no argument
  = the hosting node — plus ContentAs<T>) was nowhere on that page.
• Doc/Architecture/NodeTypeCompilation — a third way nodetype_bake's silence means nothing:
  the check is in main and not in the running image. With the ls-tree-needs-a-control note.
• Doc/Architecture/LogWatchTriage — occurrences / lastSeen / pods[] count the
  fingerprint, across deployments; and a stuck syncer is indistinguishable from an accurate
  counter when read from the issue page.
• Doc/Architecture/LogEntriesAreAQueryResult — a Logs zero needs a same-text positive
  control before it can decide anything.

All reads in this pass were read-only (get / search / autocomplete / recycle, the last
refused). No mesh data was changed.

[systemorph-com]

Still occurring: 82 more since the last update (84 total).

• Last seen: 2026-09-12 07:59:45Z
• Pods: memex-portal-deployment-b8f65dc46-vsnwh, memex-portal-deployment-b8f65dc46-lxkzg, memex-portal-deployment-6546ff4bc8-cj78b, memex-portal-deployment-6546ff4bc8-9wcwl, memex-portal-deployment-5bf869698f-5qgvz, memex-portal-deployment-5bf869698f-6x87d, memex-portal-deployment-59d8fd958f-sszkb, memex-portal-deployment-59d8fd958f-b2z6v, memex-portal-deployment-685fb69888-sjl6z, memex-portal-deployment-685fb69888-f8xxd, memex-portal-deployment-84d46fdb95-f9lb5, memex-portal-deployment-84d46fdb95-mvf8b, memex-portal-deployment-7ffbd9b949-nqkvb, memex-portal-deployment-7ffbd9b949-h8t4d, memex-portal-deployment-7ffbd9b949-rvqk8, memex-portal-deployment-5867566569-k9nmf, memex-portal-deployment-5867566569-c9xbt, memex-portal-deployment-5867566569-z4zzk, memex-portal-deployment-5867566569-frfqx, memex-portal-deployment-7f74766b8d-rltnt, memex-portal-deployment-7f74766b8d-rmjfc, memex-portal-deployment-67f7fc74f6-cqwr5, memex-portal-deployment-67f7fc74f6-cvvnq, memex-portal-deployment-574d54c98d-cdd47, memex-portal-deployment-574d54c98d-vvcwq, memex-portal-deployment-6d7497cb58-jc296, memex-portal-deployment-747c879d8c-ph572, memex-portal-deployment-747c879d8c-w2vsm, memex-portal-deployment-77858cc9cd-9p2xt, memex-portal-deployment-d8bf579fc-wprn8, memex-portal-deployment-d8bf579fc-8lpl4, memex-portal-deployment-7dbb4cf6b4-ndhjx, memex-portal-deployment-584db8fc55-m2g2s, memex-portal-deployment-7dbb4cf6b4-nrb7x, memex-portal-deployment-584db8fc55-db7jd, memex-portal-deployment-868794b948-mrrkd, memex-portal-deployment-849544cd4-d2rwm, memex-portal-deployment-849544cd4-wlwp5, memex-portal-deployment-b855c6d4d-nfq9d, memex-portal-deployment-b855c6d4d-jvb4c

Recent log lines

2026-09-12 07:02:49Z memex-portal-deployment-849544cd4-wlwp5 fail: MeshWeaver.Graph.Configuration.MeshNodeCompilationService[0]
      Failed to compile assembly for node 'BinaryClickerV2/BinaryToggle'.
      --- Compiler diagnostics ---
      Compilation failed for 'BinaryClickerV2/BinaryToggle':
      CS1929 Error (line 58): 'LayoutAreaHost' does not contain a definition for 'GetData' and the best extension method overload 'WorkspaceOperations.GetData<BinaryToggleData>(EntityStore)' requires a receiver of type 'MeshWeaver.Data.EntityStore'
      CS0105 Warning (line 27): The using directive for 'System.ComponentModel.DataAnnotations' appeared previously in this namespace
      CS0105 Warning (line 28): The using directive for 'MeshWeaver.Domain' appeared previously in this namespace
      CS0105 Warning (line 29): The using directive for 'System' appeared previously in this namespace
      CS0105 Warning (line 30): The using directive for 'System.Reactive.Linq' appeared previously in this namespace
      CS0105 Warning (line 31): The using directive for 'MeshWeaver.Layout' appeared previously in this namespace
      CS0105 Warning (line 32): The using directive for 'MeshWeaver.Layout.Composition' appeared previously in this namespace
      CS1591 Warning (line 44): Missing XML comment for publicly visible type or member 'BinaryToggleData.Name'
      CS1591 Warning (line 46): Missing XML comment for publicly visible type or member 'BinaryToggleData.IsOn'
      CS1591 Warning (line 56): Missing XML comment for publicly visible type or member 'BinaryToggleLayout.Toggle(LayoutAreaHost, RenderingContext)'
      CS1591 Warning (line 83): Missing XML comment for publicly visible type or member 'BinaryClickerV2_BinaryToggleMeshNodeProviderAttribute'
        … and 1 more diagnostic line(s) — the complete set is on the exception below and in the NodeType's CompilationDiagnostics.
      --- Source discovery ---
      Executed source queries (2):
        - namespace:BinaryClickerV2/BinaryToggle/Source scope:subtree nodeType:Code
       …[truncated]
2026-09-12 07:57:07Z memex-portal-deployment-b855c6d4d-nfq9d fail: MeshWeaver.Graph.Configuration.MeshNodeCompilationService[0]
      Failed to compile assembly for node 'BinaryClickerV2/BinaryToggle'.
      --- Compiler diagnostics ---
      Compilation failed for 'BinaryClickerV2/BinaryToggle':
      CS1929 Error (line 58): 'LayoutAreaHost' does not contain a definition for 'GetData' and the best extension method overload 'WorkspaceOperations.GetData<BinaryToggleData>(EntityStore)' requires a receiver of type 'MeshWeaver.Data.EntityStore'
      CS0105 Warning (line 27): The using directive for 'System.ComponentModel.DataAnnotations' appeared previously in this namespace
      CS0105 Warning (line 28): The using directive for 'MeshWeaver.Domain' appeared previously in this namespace
      CS0105 Warning (line 29): The using directive for 'System' appeared previously in this namespace
      CS0105 Warning (line 30): The using directive for 'System.Reactive.Linq' appeared previously in this namespace
      CS0105 Warning (line 31): The using directive for 'MeshWeaver.Layout' appeared previously in this namespace
      CS0105 Warning (line 32): The using directive for 'MeshWeaver.Layout.Composition' appeared previously in this namespace
      CS1591 Warning (line 44): Missing XML comment for publicly visible type or member 'BinaryToggleData.Name'
      CS1591 Warning (line 46): Missing XML comment for publicly visible type or member 'BinaryToggleData.IsOn'
      CS1591 Warning (line 56): Missing XML comment for publicly visible type or member 'BinaryToggleLayout.Toggle(LayoutAreaHost, RenderingContext)'
      CS1591 Warning (line 83): Missing XML comment for publicly visible type or member 'BinaryClickerV2_BinaryToggleMeshNodeProviderAttribute'
        … and 1 more diagnostic line(s) — the complete set is on the exception below and in the NodeType's CompilationDiagnostics.
      --- Source discovery ---
      Executed source queries (2):
        - namespace:BinaryClickerV2/BinaryToggle/Source scope:subtree nodeType:Code
       …[truncated]
2026-09-12 07:59:45Z memex-portal-deployment-b855c6d4d-jvb4c fail: MeshWeaver.Graph.Configuration.MeshNodeCompilationService[0]
      Failed to compile assembly for node 'BinaryClickerV2/BinaryToggle'.
      --- Compiler diagnostics ---
      Compilation failed for 'BinaryClickerV2/BinaryToggle':
      CS1929 Error (line 58): 'LayoutAreaHost' does not contain a definition for 'GetData' and the best extension method overload 'WorkspaceOperations.GetData<BinaryToggleData>(EntityStore)' requires a receiver of type 'MeshWeaver.Data.EntityStore'
      CS0105 Warning (line 27): The using directive for 'System.ComponentModel.DataAnnotations' appeared previously in this namespace
      CS0105 Warning (line 28): The using directive for 'MeshWeaver.Domain' appeared previously in this namespace
      CS0105 Warning (line 29): The using directive for 'System' appeared previously in this namespace
      CS0105 Warning (line 30): The using directive for 'System.Reactive.Linq' appeared previously in this namespace
      CS0105 Warning (line 31): The using directive for 'MeshWeaver.Layout' appeared previously in this namespace
      CS0105 Warning (line 32): The using directive for 'MeshWeaver.Layout.Composition' appeared previously in this namespace
      CS1591 Warning (line 44): Missing XML comment for publicly visible type or member 'BinaryToggleData.Name'
      CS1591 Warning (line 46): Missing XML comment for publicly visible type or member 'BinaryToggleData.IsOn'
      CS1591 Warning (line 56): Missing XML comment for publicly visible type or member 'BinaryToggleLayout.Toggle(LayoutAreaHost, RenderingContext)'
      CS1591 Warning (line 83): Missing XML comment for publicly visible type or member 'BinaryClickerV2_BinaryToggleMeshNodeProviderAttribute'
        … and 1 more diagnostic line(s) — the complete set is on the exception below and in the NodeType's CompilationDiagnostics.
      --- Source discovery ---
      Executed source queries (2):
        - namespace:BinaryClickerV2/BinaryToggle/Source scope:subtree nodeType:Code
       …[truncated]

[systemorph-com]

Still occurring: 12 more since the last update (96 total).

• Last seen: 2026-09-12 17:29:57Z
• Pods: memex-portal-deployment-b8f65dc46-vsnwh, memex-portal-deployment-b8f65dc46-lxkzg, memex-portal-deployment-6546ff4bc8-cj78b, memex-portal-deployment-6546ff4bc8-9wcwl, memex-portal-deployment-5bf869698f-5qgvz, memex-portal-deployment-5bf869698f-6x87d, memex-portal-deployment-59d8fd958f-sszkb, memex-portal-deployment-59d8fd958f-b2z6v, memex-portal-deployment-685fb69888-sjl6z, memex-portal-deployment-685fb69888-f8xxd, memex-portal-deployment-84d46fdb95-f9lb5, memex-portal-deployment-84d46fdb95-mvf8b, memex-portal-deployment-7ffbd9b949-nqkvb, memex-portal-deployment-7ffbd9b949-h8t4d, memex-portal-deployment-7ffbd9b949-rvqk8, memex-portal-deployment-5867566569-k9nmf, memex-portal-deployment-5867566569-c9xbt, memex-portal-deployment-5867566569-z4zzk, memex-portal-deployment-5867566569-frfqx, memex-portal-deployment-7f74766b8d-rltnt, memex-portal-deployment-7f74766b8d-rmjfc, memex-portal-deployment-67f7fc74f6-cqwr5, memex-portal-deployment-67f7fc74f6-cvvnq, memex-portal-deployment-574d54c98d-cdd47, memex-portal-deployment-574d54c98d-vvcwq, memex-portal-deployment-6d7497cb58-jc296, memex-portal-deployment-747c879d8c-ph572, memex-portal-deployment-747c879d8c-w2vsm, memex-portal-deployment-77858cc9cd-9p2xt, memex-portal-deployment-d8bf579fc-wprn8, memex-portal-deployment-d8bf579fc-8lpl4, memex-portal-deployment-7dbb4cf6b4-ndhjx, memex-portal-deployment-584db8fc55-m2g2s, memex-portal-deployment-7dbb4cf6b4-nrb7x, memex-portal-deployment-584db8fc55-db7jd, memex-portal-deployment-868794b948-mrrkd, memex-portal-deployment-849544cd4-d2rwm, memex-portal-deployment-849544cd4-wlwp5, memex-portal-deployment-b855c6d4d-nfq9d, memex-portal-deployment-b855c6d4d-jvb4c, memex-portal-deployment-75dff475b6-lckkp, memex-portal-deployment-8ff67f8c7-gcf24, memex-portal-deployment-8ff67f8c7-vm8d7, memex-portal-deployment-5f5fdfbd98-ghh75, memex-portal-deployment-bfc5dcf6f-7z88q, memex-portal-deployment-bfc5dcf6f-d7924, memex-portal-deployment-7fd9668b69-sjm5v, memex-portal-deployment-7fd9668b69-jnwlv

Recent log lines

2026-09-12 12:57:32Z memex-portal-deployment-7fd9668b69-sjm5v fail: MeshWeaver.Graph.Configuration.MeshNodeCompilationService[0]
      Failed to compile assembly for node 'MeshWeaver/samples/Graph/Data/Type/article'.
      --- Compiler diagnostics ---
      Compilation failed for 'MeshWeaver/samples/Graph/Data/Type/article':
      CS0246 Error (line 58): The type or namespace name 'Article' could not be found (are you missing a using directive or an assembly reference?)
      CS1591 Warning (line 32): Missing XML comment for publicly visible type or member 'MeshWeaver_samples_Graph_Data_Type_articleMeshNodeProviderAttribute'
      CS1591 Warning (line 34): Missing XML comment for publicly visible type or member 'MeshWeaver_samples_Graph_Data_Type_articleMeshNodeProviderAttribute.Nodes'
      --- Source discovery ---
      Executed source queries (2):
        - namespace:MeshWeaver/samples/Graph/Data/Type/article/Source scope:subtree nodeType:Code
        - namespace:MeshWeaver/samples/Graph/Data/Type/article/Test scope:subtree nodeType:Code
      Matched Code nodes (0):
        (none) — the configuration lambda cannot reference types because no source files were included. Check that your Source Code nodes exist and that the NodeType's `sources` list points at them.
      
      MeshWeaver.Compiler.CompilationException: Compilation failed for 'MeshWeaver/samples/Graph/Data/Type/article':
      CS0246 Error (line 58): The type or namespace name 'Article' could not be found (are you missing a using directive or an assembly reference?)
      CS1591 Warning (line 32): Missing XML comment for publicly visible type or member 'MeshWeaver_samples_Graph_Data_Type_articleMeshNodeProviderAttribute'
      CS1591 Warning (line 34): Missing XML comment for publicly visible type or member 'MeshWeaver_samples_Graph_Data_Type_articleMeshNodeProviderAttribute.Nodes'
         at MeshWeaver.Compiler.EmitPipeline.EmitCompilationToDirectory(CSharpCompilation compilation, String nodeName, String nodePath, String releaseDir, IReadOnlyCollection`1 mani…[truncated]
2026-09-12 17:29:56Z memex-portal-deployment-7fd9668b69-jnwlv fail: MeshWeaver.Graph.Configuration.MeshNodeCompilationService[0]
      Failed to compile assembly for node 'MeshWeaver/samples/Graph/Data/Northwind/Product'.
      --- Compiler diagnostics ---
      Compilation failed for 'MeshWeaver/samples/Graph/Data/Northwind/Product':
      CS0246 Error (line 51): The type or namespace name 'Supplier' could not be found (are you missing a using directive or an assembly reference?)
      CS0246 Error (line 55): The type or namespace name 'Category' could not be found (are you missing a using directive or an assembly reference?)
      CS0105 Warning (line 27): The using directive for 'System.ComponentModel' appeared previously in this namespace
      CS0105 Warning (line 28): The using directive for 'System.ComponentModel.DataAnnotations' appeared previously in this namespace
      CS0105 Warning (line 29): The using directive for 'MeshWeaver.Domain' appeared previously in this namespace
      CS0105 Warning (line 30): The using directive for 'System.Reactive.Linq' appeared previously in this namespace
      CS0105 Warning (line 31): The using directive for 'MeshWeaver.Domain' appeared previously in this namespace
      CS0105 Warning (line 32): The using directive for 'MeshWeaver.Layout' appeared previously in this namespace
      CS8632 Warning (line 93): The annotation for nullable reference types should only be used in code within a '#nullable' annotations context.
      CS8632 Warning (line 93): The annotation for nullable reference types should only be used in code within a '#nullable' annotations context.
      CS8632 Warning (line 98): The annotation for nullable reference types should only be used in code within a '#nullable' annotations context.
        … and 22 more diagnostic line(s) — the complete set is on the exception below and in the NodeType's CompilationDiagnostics.
      --- Source discovery ---
      Executed source queries (6):
        - namespace:MeshWeaver/samples/Graph/Data/Northwind/Product/Source scope…[truncated]
2026-09-12 17:29:57Z memex-portal-deployment-7fd9668b69-jnwlv fail: MeshWeaver.Graph.Configuration.MeshNodeCompilationService[0]
      Failed to compile assembly for node 'MeshWeaver/samples/Graph/Data/Type/article'.
      --- Compiler diagnostics ---
      Compilation failed for 'MeshWeaver/samples/Graph/Data/Type/article':
      CS0246 Error (line 58): The type or namespace name 'Article' could not be found (are you missing a using directive or an assembly reference?)
      CS1591 Warning (line 32): Missing XML comment for publicly visible type or member 'MeshWeaver_samples_Graph_Data_Type_articleMeshNodeProviderAttribute'
      CS1591 Warning (line 34): Missing XML comment for publicly visible type or member 'MeshWeaver_samples_Graph_Data_Type_articleMeshNodeProviderAttribute.Nodes'
      --- Source discovery ---
      Executed source queries (2):
        - namespace:MeshWeaver/samples/Graph/Data/Type/article/Source scope:subtree nodeType:Code
        - namespace:MeshWeaver/samples/Graph/Data/Type/article/Test scope:subtree nodeType:Code
      Matched Code nodes (0):
        (none) — the configuration lambda cannot reference types because no source files were included. Check that your Source Code nodes exist and that the NodeType's `sources` list points at them.
      
      MeshWeaver.Compiler.CompilationException: Compilation failed for 'MeshWeaver/samples/Graph/Data/Type/article':
      CS0246 Error (line 58): The type or namespace name 'Article' could not be found (are you missing a using directive or an assembly reference?)
      CS1591 Warning (line 32): Missing XML comment for publicly visible type or member 'MeshWeaver_samples_Graph_Data_Type_articleMeshNodeProviderAttribute'
      CS1591 Warning (line 34): Missing XML comment for publicly visible type or member 'MeshWeaver_samples_Graph_Data_Type_articleMeshNodeProviderAttribute.Nodes'
         at MeshWeaver.Compiler.EmitPipeline.EmitCompilationToDirectory(CSharpCompilation compilation, String nodeName, String nodePath, String releaseDir, IReadOnlyCollection`1 mani…[truncated]