Gateway Module Spec Index

Index of the per-module endpoint specifications for the LisaOS memory gateway. One CS.AK.LISA.Docu.Module.{Name}.md file per directory under memory_gateway/server/, authored during Phase 4 of the LisaOS Full-System Audit Campaign (§5.2).

Ground truth: lisa-os main at 5c9a304. Read-only inventory.

Module count — the correction

23 modules. 22 code-bearing (TypeScript) + dashboard/ (static frontend assets, 0 TS). This is the authoritative count and supersedes both stale figures: the TechSpec's "18" and the campaign plan's "~20". Any document, diagram, or health-card label still asserting 18 or 20 is wrong and must be reconciled to 23 (22 + static).

The "live REST surface" honesty column

Not every directory that Express could route actually serves HTTP. Six modules expose no live REST surface, and one (memory) serves REST from outside its own directory. This is load-bearing for anyone auditing the attack surface or the auth matrix — the mounted-router count is not the module count.

• auth — middleware only (createAuthMatrix); it is the authorisation gate, it does not sit behind one.
• notifications — background Telegram service; no router.
• shared — utilities (search-utils, zod-error); no router.
• dashboard — static frontend; pages + express.static + auth-shim are wired in top-level index.ts, not this directory.
• knowledge-graph + cross-references — internal repositories feeding context assembly (AK-347). routes.ts files exist in both but are never app.use'd — dead, unmounted router code (clone-3 HIGH finding). Their only live surface is via /api/context/* and the MCP KG tools.
• memory — has REST, but it is defined inline in top-level index.ts (L531–731): /api/health, /api/health/detail, GET/POST /api/memory, GET/PUT/DELETE /api/memory/:id. The directory holds db.ts, embeddings, repositories, cache, types — no routes.ts.

Shard 1 — Memory / Cache / Context core

Shard 2 — Dispatch / Sessions / Agents / MCP

Shard 3 — Analytics / Auth / Ops / Frontend

Tally

Change history