forked from molecule-ai/molecule-core
bc82fa4e0e
Three changes to stop ferrying sensitive content through our public monorepo. All content already imported to Molecule-AI/internal (private) — see linked PRs below. ## docs/incidents/INCIDENT_LOG.md — replaced with stub Contained full security audit cycle records with CWE references, file:line pointers to historical vulnerabilities, and severity ratings. None of that belongs in a public repo. → Moved to Molecule-AI/internal/security/incident-log.md (PR #20). Monorepo file becomes a 17-line stub pointing at the internal location. Future incidents land in the internal file only. ## docs/architecture/canary-release.md — redacted identifiers Had AWS account ID `004947743811` and IAM role name `MoleculeStagingProvisioner` embedded. Even though the fleet described isn't actually running (see state note), these identifiers are account-specific and don't belong in public git. → Removed both values, replaced with generic references + a pointer to Molecule-AI/internal/runbooks/canary-fleet.md (PR #21) where the actual identifiers live. Any future rotation touches the internal file, no public-git-history rewrite needed. ## docs/infra/workspace-terminal.md — reduced to public summary Contained the full ops runbook: bootstrap script output, per-tenant SG backfill loop with live SG IDs, customer slug names (hongmingwang). Useful content but too specific for a public repo. → Moved to Molecule-AI/internal/runbooks/workspace-terminal.md (PR #22). Monorepo file becomes a 30-line public summary of what the feature does + pointers to code, so external readers / self-hosters still get the design story. ## What's NOT in this PR (follow-up) Marketing briefs, SEO plans, campaign copy, research dossiers, and internal product designs (hermes-adapter-plan, medo-integration, cognee-*) are the next batches. See docs policy doc coming next to set team expectations. Net removal: ~820 lines from public git going forward. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| adapters | ||
| adr | ||
| agent-runtime | ||
| api-protocol | ||
| architecture | ||
| assets/branding | ||
| blog | ||
| development | ||
| frontend | ||
| guides | ||
| incidents | ||
| infra | ||
| integrations | ||
| marketing | ||
| pages/api | ||
| plugins | ||
| research | ||
| tutorials | ||
| .gitignore | ||
| api-reference.md | ||
| glossary.md | ||
| index.md | ||
| quickstart.md | ||
| README.md | ||
| workspace-runtime-package.md | ||
docs/
This directory serves two purposes:
- Markdown content — everything under
architecture/,agent-runtime/,api-protocol/,development/,frontend/,plugins/,product/, etc. This is what agents and humans read. - 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, andCLAUDE.md— otherwise agents can't find them (see.claude/memoryfeedback_cross_reference_docs.md). edit-history/YYYY-MM-DD.mdis 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.