Sprint 3 is closed.
The goal was to persist CEM entities, relations, and evidence locally — so project understanding survives between sessions. The new @meronq/memory package, CLI commands, and an upgraded handshake now read and write engineering memory in SQLite.
What Sprint 3 delivered
Every item on the roadmap is checked off:
- SQLite schema — entities, relations, evidence, access/reinforcement events
-
Full CEM sync from scanner output into
.meronq/local/memory.db - Access and reinforcement events — lifecycle signals per ADR-0005
- Handshake from memory — scan refreshes DB; CEM returned from the store
Local MCP is now v1.12.0 with memory_sync and a memory block in handshake.
New package: @meronq/memory
| Module | Role |
|---|---|
MemoryStore.open() |
Open .meronq/local/memory.db
|
syncFromSnapshot() |
Full CEM replace from live scan |
loadSnapshot() |
Read CEM back from SQLite |
recordAccess() / recordReinforcement()
|
Lifecycle events |
Uses Node built-in node:sqlite — Node ≥ 22.5 required.
Handshake pipeline
scanProject → indexToCemSnapshot → syncFromSnapshot → loadSnapshot → handshake.cem
Handshake still scans for freshness; CEM is served from SQLite with access events recorded.
CLI
meronq memory sync # scan + sync CEM to SQLite
meronq memory stats # row counts
Stable entity IDs
Project ids canonicalize across Windows and WSL (project:c:/...). Components use paths: component:apps/cli, component:packages/memory.
Sprint 4 — GitHub Integration
Connect Meronq to GitHub: issues, PRs, and metadata translated into CEM. Memory becomes the merge target for external data.
Follow along
- Roadmap
- Development blog
- GitHub: Meronq-dev/meronq
Read the full post on meronq.pages.dev · Source on GitHub
Top comments (0)