Memory Bank v0 — Backend (den-db + den-api + agent prompt + eval)

[joi-fairshare]

Memory Bank v0 — Backend (den-db + den-api + agent prompt + eval)

The per-user Memory Bank server side: schema, owner-scoped REST routes surfaced through the existing meta-MCP, the agent prompt that primes search-first save/recall, a save→recall eval, and a general meta-MCP robustness fix. Frontend (desktop UI) is a separate PR.

Authoritative design: docs/memory-bank-architecture.md.

What's here

Schema (den-db) [TASK-1] — memory + memory_context tables; memory/memctx typeids registered in packages/utils; migration 0028. FULLTEXT index on memory.content created idempotently on all apply paths (bootstrap, db:push, db:migrate chain) via ensureMemoryFulltextIndex — because drizzle-kit push + baseline silently drop a migration-only FULLTEXT index on fresh installs [B2]. No DB-level FK (PlanetScale/Vitess convention); the memory→context cascade is app-enforced.

Routes (den-api) [TASK-2/3] — postMemory / getMemorySearch / getMemory / deleteMemoryById. Reads (search/list) and delete are owner-scoped on user_id (not the org pattern) with non-leaking 404 [B4] — v0 recalls a user's memories across all of their orgs. Save uses orgMemberRoute(): the memory is only written to an org the caller is verified to be a member of (resolveOrganizationContextMiddleware → getOrganizationContextForUser, 404 otherwise, on both the cookie/bearer and MCP-principal paths); org_id comes from the verified organizationContext.organization.id, never a raw/forgeable session.activeOrganizationId. Also: flattened, mostly-optional save payload with the shape in the OpenAPI summary, server-set source, forced scope='user', one-transaction save, input bounds [B3]; bound MATCH … AGAINST NL search (never sql.raw), empty→200; structured save/search/delete events. "Memory" added to SAFE_INCLUDED_TAGS so the four capabilities surface via search_capabilities/execute_capability.

Agent prompt (apps/server) [TASK-4] — static, search-first ## Memory Bank section (never names memory_save); draft→human-confirm→execute save, explicit lexical recall, no-secrets guidance (the only v0 plaintext-at-rest mitigation). Also corrects the capabilities-knowledge plugin that previously said there was "no separate memory store."

Eval (evals) [TASK-9] — memory-save-recall.flow.mjs: discover→save→recall in a fresh session via the live meta-MCP.

Meta-MCP fix (den-api) — execute_capability now accepts path/query passed as a JSON string (LLMs stringify args), mirroring the existing normalizeToolBody. Fixes a real -32602 "expected record, received string" and unblocks getMemorySearch recall. General — applies to every capability.

Tests run — all pass

# den-api (bun, against MySQL 8.4 openwork_test)
bun test test/memory-routes.test.ts        → 5 pass   (operationIds, MCP allow+scopes, payload bounds, scope/source not client-settable)
bun test test/memory-ownership.test.ts     → 5 pass   (IDOR merge gate: member save → Bob 404 → recall → cascade delete → empty→200 → bounds → NON-MEMBER save 404)
bun test test/mcp-invoke-body.test.ts      → 8 pass   (query fix — no regression)
bun test test/route-access-policy.test.ts  → 1 pass
tsc --noEmit (den-api)                      → 0 errors
# den-db
db:verify-memory (bootstrap + db:push paths) → 10/10 checks (FULLTEXT present on both paths, NL MATCH, cascade, idempotency)
tsc/DTS (den-db, utils)                     → build OK
# apps/server
bun test src/openwork-runtime-config.test.ts → 4 pass   (## Memory Bank present, distinct, no memory_save/search, no-secrets)
tsc --noEmit (server)                       → 0 errors

fraimz / end-to-end proof

The save→recall flow was proven live end-to-end against the running stack (den-api + MySQL + a real MCP token):

✓ /mcp/agent exposes exactly execute_capability, search_capabilities (no memory_save/search)
✓ discovered save capability search-first: postMemory (hasBody:true)
✓ saved mem_… (scope forced 'user') → recalled via NL "Acme account renewal" (FULLTEXT score 0.18)
✓ stringified query param accepted (the execute_capability fix) → cleaned up via delete capability

evals/flows/memory-save-recall.flow.mjs drives this via the eval runner (pnpm fraimz --flow memory-save-recall, needs a signed-in app + --stack den). Backend-only PR — no desktop UI surface here.

Review

Every stage driven to zero findings at every severity via multi-lens reviews (security/IDOR · data-migration · data-integrity · TypeScript · architecture · performance), each with an address-and-re-review round. Accepted-in-writing LOWs documented in code/§9.

Coding guidelines

No any/as/typecasts (only required as const on enum tuples + one satisfies); pnpm/bun; additive; smallest diff.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
openwork-landing	Ready	Preview, Comment, Open in v0	Jul 3, 2026 2:20am

[vercel]

@jthorare is attempting to deploy a commit to the Different AI Team on Vercel.

A member of the Team first needs to authorize it.

[benjaminshafii]

Validated end-to-end on a combined worktree (pr-2436 + pr-2437 merged into dev — clean merge, no conflicts).

Tests run (all pass)

• bun test test/memory-routes.test.ts test/memory-ownership.test.ts test/mcp-invoke-body.test.ts test/route-access-policy.test.ts → 19 pass, 0 fail (against real MySQL 8.4 openwork_test, incl. the cross-user IDOR suite)
• pnpm run db:verify-memory → 10/10 checks (FULLTEXT present, NL MATCH, cascade, idempotent ensure)
• apps/server bun test src/openwork-runtime-config.test.ts → 4 pass; tsc clean
• Live e2e via pnpm fraimz --flow memory-save-recall --stack den → PASSED, all 10 steps (search-first discovery, save via execute_capability with scope forced to user, cross-session NL recall, desktop panel shows the memory, cleanup via delete capability). fraimz.html + validated screenshot produced.

One real finding — the committed eval flow fails as-is:
evals/flows/memory-save-recall.flow.mjs mints its MCP token with body: JSON.stringify({}). Since #2280 (already in this branch's merge-base), default token scopes are read-only, so the save step deterministically fails with insufficient_mcp_scope: mcp:write. The product path is unaffected (the desktop mints with ["mcp:read","mcp:write"], apps/app/src/app/lib/den.ts:2009). One-line fix:

body: JSON.stringify({ scopes: ["mcp:read", "mcp:write"] }),

With that fix the whole flow passes. Please apply before merge.

Code review — real production code is ~850 lines (82% of the diff is the generated drizzle 0028 snapshot); follows existing den-api/den-db route + schema conventions (routes/org/ layout, orgMemberRoute, no DB FKs per Vitess convention); no any/as; owner scoping on user_id everywhere, membership-gated save, non-leaking 404s, parameterized MATCH…AGAINST. The mcp/invoke.ts stringified-args fix mirrors the existing normalizeToolBody guard and fails safe. Two trivial nits: the unrelated .gitignore .playwright-mcp/ line, and verify-memory-schema.ts isn't referenced by CI (wire it in or drop it eventually).