molecule-ai/molecule-core
36
0
Fork 2
Code Issues 24 Pull Requests 21 Actions 65 Packages Projects Releases Wiki Activity
3886e8fb9f
molecule-core/docs
History
Hongming Wang 8417bce50d Memory v2 PR-10: operator docs for writing a custom memory plugin 
Builds on merged PR-1..7 (PR-8 in queue). Pure docs; no code.

What ships:
  * docs/memory-plugins/README.md — contract overview, capability
    negotiation, deployment models, replacement workflow
  * docs/memory-plugins/testing-your-plugin.md — using the contract
    test harness to validate wire compatibility, what the harness
    DOES NOT cover (capability accuracy, TTL eviction, concurrency)
  * docs/memory-plugins/pinecone-example/README.md — worked example
    of a Pinecone-backed plugin: capability mapping (only embedding,
    no FTS), wire mapping (memory → vector + metadata), production-
    hardening checklist

Documentation strategy:
  * Lead with what workspace-server takes care of (security perimeter,
    redaction, ACL, GLOBAL audit, prompt-injection wrap) so plugin
    authors don't reimplement those layers
  * Show three deployment models (same machine / separate container /
    self-managed) so operators see their topology
  * Capability table makes it explicit what each capability gates so
    a plugin that supports only one (e.g. semantic search) is still
    a useful plugin
  * Pinecone example is honest: shows the skeleton, the wire mapping,
    and explicitly calls out what's MISSING from the sketch (batch
    commits, TTL janitor, circuit breaker, metrics)
2026-05-04 08:17:03 -07:00
..
adapters
adr
agent-runtime docs(skills): document SKILL.md runtime field + AST coverage gate (#119 PR-4) 2026-05-03 01:22:34 -07:00
api-protocol Memory v2 PR-1: OpenAPI plugin contract + Go bindings 2026-05-04 06:45:52 -07:00
architecture docs(internal): refresh runtime-package mirror policy + parity matrix + dead-link fix 2026-05-01 20:06:06 -07:00
assets
blog
development
devrel/demos/tool-trace-platform-instructions
engineering
frontend
guides
incidents
infra docs(internal): refresh runtime-package mirror policy + parity matrix + dead-link fix 2026-05-01 20:06:06 -07:00
integrations docs(integrations): update hermes plugin path status to post-merge 2026-05-02 04:42:00 -07:00
memory-plugins Memory v2 PR-10: operator docs for writing a custom memory plugin 2026-05-04 08:17:03 -07:00
pages/api
plugins
tutorials
.gitignore
api-reference.md
ecosystem-watch.md
glossary.md
index.md
internal-content-policy.md
quickstart.md feat(dev-start): true single-command spinup — infra + templates + auth posture 2026-04-27 16:29:37 -07:00
README.md
workspace-runtime-package.md docs(internal): refresh runtime-package mirror policy + parity matrix + dead-link fix 2026-05-01 20:06:06 -07:00

README.md

docs/

This directory serves two purposes:

  1. Markdown content — everything under architecture/, agent-runtime/, api-protocol/, development/, frontend/, plugins/, product/, etc. This is what agents and humans read.
  2. VitePress site — .vitepress/config.ts, package.json, package-lock.json. These drive the rendered documentation site.

Local preview

cd docs
npm install
npm run dev      # preview on http://localhost:5173
npm run build    # static build to docs/.vitepress/dist/

Conventions

  • New top-level docs must be linked from PLAN.md, README.md, and CLAUDE.md — otherwise agents can't find them (see .claude/ memory feedback_cross_reference_docs.md).
  • edit-history/YYYY-MM-DD.md is append-only log of significant changes; don't rewrite history.
  • archive/ holds one-shot analyses and retired docs — kept for context but not maintained.

Why site tooling lives here (not in docs-site/)

VitePress expects its config at <root>/.vitepress/config.ts where <root> is also the content directory. Splitting tooling into a sibling docs-site/ would require a non-trivial srcDir shim and break relative links in .vitepress/config.ts. Keeping both together is the pragmatic choice; this README is the tradeoff ledger.