Skip to content

docs: establish global documentation authority and reconcile driftΒ #737

Description

@dnlrsls

πŸ“– Documentation Improvement

πŸ“‹ Pre-flight Checks

  • I searched existing issues and this is not a duplicate
  • I have links to the specific documentation pages and sections that need improvement

πŸ“„ Which Document?

Other β€” global documentation authority across README.md, DOCS.md, docs/, package guides, generated instructions, and OpenSpec history.

πŸ” What's Wrong or Missing?

Engram has no explicit documentation authority map. Several living documents duplicate technical contracts or disagree with current code, making it easier to add new mechanisms in the wrong package instead of reusing the existing owner.

Confirmed examples:

  • README.md, DOCS.md, docs/ARCHITECTURE.md, docs/AGENT-SETUP.md, and docs/PLUGINS.md report inconsistent MCP inventories; current code exposes 22 tools: 18 agent and 4 admin.
  • mem_pin and mem_unpin are not documented in the public technical reference.
  • DOCS.md has an incomplete or inaccurate SQLite schema reference.
  • Gemini, Cursor, and OpenCode Windows setup instructions contain obsolete behavior or paths.
  • Cloud/dashboard route documentation is incomplete.
  • Memory Protocol links contain broken anchors.
  • Complete MCP, CLI, API, plugin, and setup contracts are duplicated across multiple documents.
  • Canonical sources and generated or embedded copies are not mapped explicitly.
  • There is no focused session-lifecycle contract defining what belongs in host adapters versus Go core.

Affected documentation includes:

πŸ’‘ Suggested Improvement

Establish a global documentation system that makes authority and ownership explicit, then reconcile confirmed drift against current code and tests.

Suggested work units:

  1. Add a concise documentation catalog declaring audience, authority level, owner, living/historical/generated status, canonical source, and documents that must change together.
  2. Correct MCP inventory, pin/unpin behavior, database schema, setup paths, Memory Protocol links, and cloud/dashboard routes.
  3. Document ownership boundaries: internal/store owns durable memory/session semantics; internal/mcp owns agent-facing schemas; internal/server owns the local HTTP boundary; internal/project owns project resolution; internal/setup owns installation and embedded assets; plugin/* translates host-native events and identity without recreating durable policy.
  4. Add a session-lifecycle contract covering host identity, parent/root translation, registration acknowledgement, project/session validation, cardinality, activity finalization, and strict/idempotent end behavior.
  5. Keep complete API, MCP, and CLI tables in one canonical technical reference; replace repeated lists elsewhere with focused summaries and links.
  6. Deliver the tracker through multiple focused documentation PRs within the review budget, not one oversized rewrite.

Acceptance criteria:

  • Every living documentation surface has an explicit audience, authority level, and owner.
  • Canonical and generated sources are documented.
  • Confirmed MCP, schema, setup, cloud, and anchor drift is corrected against current code/tests.
  • Session lifecycle and adapter/core ownership are documented without copying implementation details.
  • Duplicate complete API/CLI/tool inventories are replaced by links to a canonical reference.
  • README.md remains the concise product overview and DOCS.md remains the detailed technical contract.
  • Historical and OpenSpec artifacts are clearly distinguished from shipped behavior.
  • Each implementation PR stays focused and links this approved tracker.

πŸ“Ž Additional Context

This issue is a global tracker and does not defer documentation required by active behavior PRs:

Non-goals: changing runtime behavior, moving host-specific identity translation into Go, rewriting all documentation in one PR, or treating stale documentation as more authoritative than current code and tests.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions