Brain

Project outline for a self-hosted AI memory and context platform with a web UI, MCP server access for Codex/Gemini/Claude, and a relational database backend. Core goal: Build a self-hosted platform that can store memories, notes, prompt templates, and project context; let humans manage them through a clean web UI; let AI tools access them through MCP; use PostgreSQL as the system of record; and support future expansion into search, relationships, and automations. Primary use cases: - store reusable prompt templates - store project notes and decisions - store homelab documentation and known fixes - let Codex retrieve and update memory during sessions - let other AI tools use the same memory base - search memories by title, tags, content, and later semantic meaning - manage memory records from a browser instead of raw files Non-goals for MVP: - multi-tenant SaaS - internet-facing public service - complex RBAC - billing - advanced vector search on day one - mobile app - polished collaboration features High-level architecture: 1. Frontend - React web app - memory list/search page - memory detail/edit page - template library page - settings/admin page 2. Backend API - REST or JSON API - CRUD for memories - CRUD for tags - CRUD for templates - search/filter endpoints - health/status endpoints 3. MCP Server - list memories - retrieve memory - search memories - store/update memory - list templates - retrieve template - maybe create/update templates 4. Database - PostgreSQL - normalized schema for memories, tags, templates, revisions, and relationships 5. Deployment - Docker Compose first - reverse proxy optional - local-only or VPN-only exposure - regular DB backups MVP feature set: Memories - create memory - update memory - delete/archive memory - title - key - body/content - tags - created/updated timestamps Templates - create prompt templates - store by title/key/category - render as reusable text blocks - separate template records from normal memories Search - keyword search - filter by tags - filter by type - sort by updated date MCP tools - list_memories - get_memory - search_memories - store_memory - list_templates - get_template Web UI - search bar - memory table/list - tag filters - create/edit forms - template browser - memory detail page Suggested data model: memories - id - key unique - title - content - type (memory, template, maybe note) - status (active, archived) - created_at - updated_at tags - id - name memory_tags - memory_id - tag_id memory_links - id - source_memory_id - target_memory_id - relationship_type revisions - id - memory_id - content - created_at - change_note Optional later: - collections - workspaces - attachments - embeddings API outline: - GET /health - GET /memories - POST /memories - GET /memories/{key} - PUT /memories/{key} - DELETE /memories/{key} - GET /templates - GET /templates/{key} - POST /templates - PUT /templates/{key} - GET /tags MCP tool outline: - list_memories() - retrieve_memory(key) - search_memories(query) - store_memory(key, title, content, tags) - list_templates() - retrieve_template(key) Later: - update_template - link_memories - get_related_memories Frontend pages: - Dashboard - Memory Library - Memory Detail - Template Library - Admin / Settings Tech stack recommendation: - backend: FastAPI - frontend: React - database: PostgreSQL - ORM: SQLAlchemy + Alembic - auth: none for MVP or simple local auth if needed - deployment: Docker Compose Phased build plan: Phase 1: Foundation - choose project name - create repo - define schema - stand up PostgreSQL - build backend skeleton - add health endpoint - add migrations Phase 2: Core Memory API - create memory model - CRUD endpoints - tag support - basic search - archive support Phase 3: MCP Server - expose core memory tools - test with Codex - test with other MCP clients Phase 4: Basic Web UI - memory list - search - create/edit form - template list Phase 5: Templates - separate template type/category - template management in UI - MCP template retrieval Phase 6: Hardening - backup strategy - audit logging - revision history - input validation - deployment cleanup Phase 7: Nice-to-Haves - semantic search - relationships/graph view - import/export - markdown rendering - attachments Operational requirements: - local or VPN-only access - daily PostgreSQL backups - .env-based config - health checks - logs - migration support - restore procedure Key risks: - overbuilding the MVP - weak search relevance - unclear separation between memories and templates - MCP layer drifting from API behavior - turning the data model into a dumping ground Success criteria: - Codex can retrieve and store memories reliably - templates can be managed from UI and retrieved by MCP - PostgreSQL is the single source of truth - searching is fast and useful - the UI is good enough that you actually use it - backup/restore is straightforward Recommended first deliverable: Build the smallest usable slice: - PostgreSQL schema - backend CRUD for memories - MCP tools for list/get/search/store - minimal web UI for viewing and editing memories That is enough to prove the system. --- **2026-03-19 22:32:43 UTC | Created via MCP**