Vault + playbook overlap — maintenance checklist
Date: 2026-03-19
Purpose: Keep internal runbooks and standards deduplicated and easy to find. Use this doc for periodic review (quarterly or after big doc moves).
Canonical indexes (bookmark these)
| Need | Canonical location |
|---|---|
| “Where does this deliverable go?” | knowledge/KNOWLEDGE_AND_STANDARDS_GUIDE.md (table) + standards/agents.md repo map |
| Active initiative plans | knowledge/plans/README.md |
| Technical setup (APIs, env, CLIs) | standards/03-knowledge/engineering/setup/ |
| Internal SOP drafts (not yet a standard) | knowledge/ops/internal-sop-drafts/ |
| GTM agent registry / feedback | knowledge/sales/agents/ |
Known overlap / drift to fix over time
1. Monorepo vs legacy repo names
knowledge/KNOWLEDGE_AND_STANDARDS_GUIDE.md sometimes refers to brainforge-vault and brainforge-playbook as separate repositories. In brainforge-platform, the same content usually lives at knowledge/ and standards/.
Maintenance: When editing that guide, prefer paths that match this monorepo (knowledge/..., standards/...) or add one line at the top: “In brainforge-platform, paths are knowledge/ and standards/.”
2. Setup and “how we connect X”
Rule: One setup source of truth per tool — standards/03-knowledge/engineering/setup/.
Vault should store client-specific or one-off context (knowledge/clients/.../resources/, knowledge/engineering/...) and link to the playbook setup doc instead of copying long credential steps.
Red flag: Two long markdown files with the same tool name in both standards/.../setup/ and knowledge/... without cross-links.
3. Plans and retros
- Plans: Index from
knowledge/plans/README.md. Avoid new top-levelknowledge/*plan*.mdfiles unless they are short pointers intoknowledge/plans/. - Retros / scaling harnesses: Prefer living next to the plan they support (e.g. under
knowledge/plans/...) and linked from the README.
4. Personal / experimental KBs
knowledge/sales/content/cc-content-system/ holds personal GPT-style knowledge bases (multiple README.md files). That is intentional separation from client vault and playbook — do not merge into knowledge/clients/; treat as do not dedupe with playbook.
5. Client README.md sprawl
Many knowledge/clients/{client}/README.md files are entry points, not duplicates of playbook. Dedup rule: If two clients need the same process, extract to playbook or knowledge/sales/ and link from client READMEs.
Quarterly checklist (15–30 minutes)
- Open
knowledge/plans/README.md— archive or link done initiatives; remove stale PR links if PRs are merged and descriptions moved. - Search vault for large pasted setup blocks (
API_KEY,op://, step-by-step CLI) that belong instandards/03-knowledge/engineering/setup/instead. - Confirm no second “KNOWLEDGE_AND_STANDARDS_GUIDE”-style tables elsewhere; one table is enough.
- Skim
knowledge/ops/internal-sop-drafts/— promote finished SOPs perKNOWLEDGE_AND_STANDARDS_GUIDE.md(service-line vs playbook template).
Repo hygiene (reference)
2026-03-19: Removed ~206 remote branches that were fully merged into main (git push origin --delete in batches). Ongoing: enable Settings → Pull requests → Automatically delete head branches on GitHub to reduce accumulation.
Local clones: git fetch --prune and git branch --merged origin/main periodically; branches checked out in worktrees (git worktree list) will not delete until the worktree is removed.
Related
knowledge/KNOWLEDGE_AND_STANDARDS_GUIDE.md.cursor/rules/knowledge-standards.mdcstandards/AGENTS.md/standards/agents.md