dkg_query view: "working-memory" does not include data from sub-graphs

[Jurij89]

Summary

When querying Working Memory with view: \"working-memory\", the dkg_query tool only returns triples from assertions in the context graph root, excluding any assertions stored in named sub-graphs.

Observed Behavior

• Query without sub-graph scoping returns 10 entities (root level only).
• Same context graph with epcis-demo sub-graph contains 13 additional entities.
• Total: 23 entities, but view: \"working-memory\" only surfaces 10.

Expected Behavior

When querying view: \"working-memory\" for a context graph, the results should include all assertions in that CG, regardless of whether they're in the root or in a named sub-graph.

Workaround

Use explicit GRAPH ?g { ... } filtering in the SPARQL query to target sub-graphs by URI pattern — but this requires knowing the sub-graph naming scheme and is not discoverable.

Steps to Reproduce

1. Create a context graph with a sub-graph.
2. Write assertions to the sub-graph.
3. Query WM with dkg_query view: \"working-memory\".
4. Observe that sub-graph entities are missing from results.

Related

• Plan item S3 (Subgraph Explorer) UI work explicitly relies on sub-graph data being reachable via the same query path as root WM — this gap blocks the UI from rendering a coherent cross-layer sub-graph view.
• The Node UI wmSparql in packages/node-ui/src/ui/hooks/useMemoryEntities.ts:171 uses STRSTARTS(STR(?g), \"${cgUri}/\") && CONTAINS(STR(?g), \"/assertion/\") — it correctly includes sub-graph assertions. The dkg_query tool's view: \"working-memory\" SPARQL likely uses a tighter filter (root-only).

[Jurij89]

Related symptom in the same family — WM Assertions tab also affected:

Confirmed during PR #656 manual testing: assertions created within a named sub-graph do not appear in the Working Memory Assertions tab in the Node UI (only assertions in the context graph root show up).

The Node UI calls `listAssertions(cg, 'wm')` (`packages/node-ui/src/ui/api.ts:561`) which hits the daemon's `/api/assertion/...` route. The same root-only filter that's hiding sub-graph data from `dkg_query view: "working-memory"` is likely also gating this endpoint, with the same fix shape.

Likely a single backend change covers both symptoms — `dkg_query` and `listAssertions` — since they're both downstream of the same root-only sub-graph filter. If the fix turns out to be per-endpoint, split into two issues; for now grouping them here.

[Bojan131]

Automated liveness test added in PR #1129 (docs/testing/ISSUE_LIVENESS_TESTS.md). The test asserts the correct behaviour and currently fails-as-expected (bug confirmed live on main as of 2026-06-11). When this is fixed the test flips RED — remove its it.fails wrapper and close this issue.