Reviving the PAP-1293 memory service + adding a typed-graph memory provider plugin — guidance?

[monthu56]

Hi @cryppadotta — context first, then questions.

I want to build a typed knowledge-graph memory provider as a first-party plugin under packages/plugins/, sitting on top of the memory control-plane you designed in PAP-1293. I read the full design (doc/memory-landscape.md, doc/plans/2026-03-17-memory-service-surface-api.md, doc/plans/2026-04-12-qmd-memory-plugin.md) and the implementation on that branch — it's exactly the shape a typed-graph provider needs: bindings, scope, provenance, memory_operations, hooks, plugin runtime, WorkMemories UI. The plugin-qmd-memory reference is a clean template.

But PR #3403 is closed (by you, May 9), Greptile-clean, no human-review objections, and master has no memory subsystem yet. Before I commit weeks to a plugin against a contract that may move under me, I'd like to know what you intend.

My questions:

1. What's the status of the memory service? Paused, replaced by a different shape, or actively under different work? PR feat: implement memory service end to end #3403 closing without a "going a different direction" comment leaves it ambiguous.
2. If it's still the intended shape: would you welcome a contribution that (a) rebases PAP-1293 onto current master and reopens it as a fresh PR, and (b) adds packages/plugins/plugin-graph-memory/ on top? I can split into two PRs if reviewability is the concern (PR1 = revived memory service, PR2 = graph plugin).
3. If you're taking a different approach: I'd rather align with your plan than ship something that needs reshaping. What does the new direction look like?
4. Worker isolation: plugin-qmd-memory is shell-out shaped, but a typed-graph plugin needs in-process native bindings (embedded engine — likely SQLite + sqlite-vec, or RyuGraph, or similar; final pick after a spike). Is the plugin worker model compatible with that, or is there a constraint I should know about before designing?

What the graph plugin would add over local_basic:

• 8-type closed ontology (Person / Company / Project / Meeting / Decision / Commitment / Document / Topic) with closed edge vocabulary
• Typed entity & edge extraction from post_run_capture / issue_comment_capture / issue_document_capture via structured LLM output, with MemorySourceRef provenance on every edge
• Multi-hop typed-path queries (e.g. "all open commitments from a Person across the last N meetings on a Project")
• Bi-temporal edges (valid_from / valid_until / SUPERSEDES)
• One embedded DB per (companyId, bindingKey) — physical company isolation
• Cost/usage reported back through MemoryUsage so it flows into memory_operations + cost_events

I'm not proposing to replace local_basic or qmd_memory — sits alongside as a third provider for users who want graph reasoning instead of flat retrieval.

Happy to take this to Discord or a sync call if that's easier. No rush — I'd rather wait a few days for a clear answer than ship code that doesn't fit your plan.

Thanks for the work on the memory design — it's the right architecture.