consolidation.ts (consolidateEpisodicToSemantic) still writes raw fragments to memory-worker, bypassing the wiki SoT

[stackbilt-admin]

Context

decisions/memory-unification (aegis#457, 2026-04-11) made the wiki at cms.stackbilt.dev the canonical store for durable AEGIS knowledge, with memory-worker (stackbilt-memory) reduced to an index-only role. Phases 3 and 5 of that epic shipped: wiki_* MCP tools are live, aegis_memory/aegis_record_memory/aegis_forget_memory are removed, and PRISM's dreaming-cycle synthesis (synthesis.ts) now writes to wiki pages (scope: dreams) instead of memory fragments.

The April decision doc explicitly flagged one piece as unresolved: "Consolidation logic needs a new shape under the unified model — wiki pages don't consolidate the same way fragments do. This is where Phase 5 will spend design time." That design work never happened.

The gap

consolidateEpisodicToSemantic (src/kernel/memory/consolidation.ts) still calls memoryBinding.store() directly against memory-worker's fragment store on every run. It does an LLM pass over recent episodes and ADD/UPDATE/DELETE's fragments — completely independent of the wiki. These fragments:

• Get no sources[] provenance, no lint, no contradiction detection
• Are invisible to wiki_search/wiki_read/wiki_list
• Are NOT invisible to chat — recall.ts Stage 3 still queries memory-worker directly and RRF-fuses the results into grounding context, so this isn't silent data loss, but it is permanent fragmentation outside the documented canonical model

Important wrinkle: this function is not invoked anywhere in the aegis-daemon repo's src/index.ts. It runs via @stackbilt/aegis-core's own scheduled-task registration (src/kernel/scheduled/consolidation.ts in this repo calls consolidateEpisodicToSemantic(env.db, ..., env.memoryBinding) directly). The daemon repo has its own local copy of consolidation.ts that is not executed — a dead shadow fork of this file, same pattern as the drift incidents that motivated the memory-adapter re-export pattern (aegis#436/#437).

This means the fix has to ship as a core change, published as a new @stackbilt/aegis-core version and bumped in the daemon's package.json — editing the daemon's local consolidation.ts is a no-op.

Ask

Design the wiki-shaped equivalent of episodic→semantic consolidation. Options worth considering:

1. Have consolidation call wiki_write against the relevant topic-scoped page (append/update body) instead of memoryBinding.store() — requires resolving how an LLM-driven append interacts with the wiki lint pass and sources[] requirements.
2. Retarget consolidation through the same MindSpring-probe pattern PRISM's synthesis.ts now uses, if the two pipelines should converge.
3. Explicitly decide consolidation stays fragment-based as a deliberate "fast/cheap episodic signal" layer distinct from the wiki's "curated knowledge" layer — if so, document that as an intentional two-tier design rather than leaving it as an unmigrated leftover, and update decisions/memory-unification + the aegis/memory-system wiki page to reflect the decision.

Either way, the current state (silently writing to a store the architecture says is index-only, via a file that isn't even the one actually running) should not persist undocumented.

References

• decisions/memory-unification (wiki, cms.stackbilt.dev)
• aegis/memory-system (wiki, cms.stackbilt.dev) — updated 2026-06-30 with this finding
• aegis#457 (memory unification epic)
• aegis-daemon/wiki-drafts/_infra/memory-consumers-audit.md (Phase 1 audit — now stale, see related issue)

[stackbilt-admin]

Redesign implemented and committed locally: consolidateEpisodicToSemantic now writes through a new writeDreamFact() helper (web/src/kernel/memory/dream-write.ts) into scope: dreams wiki pages, matching the pattern the daemon's synthesis.ts (PRISM) proves in production — option 1 from the original ask. Went with pure-additive writes (no ADD/UPDATE/DELETE-by-id) since dream pages don't support patch-by-id; the dreams lifecycle (promote on corroboration, archive if stale) is the intended mechanism for staleness under the unified model, same tradeoff PRISM already makes.

Also found and fixed something adjacent while in this file: publishInsightsFromMemory() (called every consolidation cycle from the same runMemoryConsolidation()) was calling publishInsight()/validateInsight() against a D1 table literally named memory — not memory_entries (the daemon's table) and not created by any migration in either repo. Every invocation was silently failing, caught and logged as a warning, since the function was written. Removed the dead call site; insights.ts's public API is untouched (still exported for downstream OSS consumers), only the broken internal wiring is gone.

Status: v0.8.7 committed on auto/feature/issue-72 (commit aef2e7c), tests green (82/82 files), typecheck clean. npm publish is blocked — NPM_TOKEN was accepted by the registry but the publish PUT returned 404, indicating the token lacks write access to @stackbilt/aegis-core, not a transient failure. Needs a token check before this actually ships to consumers (including aegis-daemon, tracked in aegis#684 which is otherwise complete).

Leaving open until published + daemon's package.json dependency is bumped.

[stackbilt-admin]

Fixed by PR #79 (merged), released as v0.8.7 — published to npm and verified via npm view @stackbilt/aegis-core version. aegis-daemon bumped to 0.8.7 in web/package.json (aegis-daemon@7678f18, v2.36.1).