dense-mem AGENTS.md

Dense-Mem Repository Guidance

Project Context

• Dense-Mem is a standalone MCP Streamable HTTP memory service. The host decides when memory is useful; Dense-Mem owns evidence intake, semantic lifecycle, provenance, retrieval, trace, authorization, and audit.
• For non-trivial architecture work, query the Dense-Mem project-memory MCP first with assemble_context or recall_memory. Treat recalled items as context; explicit user direction and verified repository state still govern.
• Keep project memory current after approved architecture decisions, verified implementation milestones, corrections, or conformance gaps. Store concise entries without credentials or local filesystem paths.
• Do not add repository references to local paths for separately maintained documentation. State the invariant directly in this repository.
• Inspect current code, interfaces, migrations, callers, and tests before changing behavior. Distinguish transitional implementation from the target architecture instead of assuming either one fully describes the other.

Architecture Decision Records

• Accepted repository architecture decisions live in adr/. Before non-trivial design, implementation, or review, enumerate adr/*.md and read every accepted record relevant to the affected behavior.
• Accepted ADRs describe the governing target. A transitional implementation may differ only when the ADR states its bounded rationale and removal condition; do not widen that exception or treat the transition as the completed architecture.
• A new or edited ADR in the current change cannot authorize accompanying code by itself. Explicit maintainer direction governs a new decision, and a later ADR must identify any accepted record that it supersedes.

Current Stack

• Go 1.26 with Echo v4; PostgreSQL access uses GORM/pgx and goose migrations; validation uses go-playground/validator/v10; Redis uses go-redis/v9.
• Configuration is loaded from environment variables through internal/config. Do not introduce a second configuration framework.
• The browser applications use React/Vite with Vitest and Playwright. Follow their existing component and test patterns when changing web/.
• HTTP success responses use internal/http/response and the { "data": ... } envelope. Public errors are typed and bounded through existing error helpers.