Architecture
Type: index · Status: current
How commonplace is structured and installed. Repo layout, the two-tree split between user content and framework, control-plane design, and the file-based storage decision.
Notes
- commonplace-architecture — the commonplace repo structure: kb/, scripts/, and how they compose
- 006-two-tree-installation-layout — how commonplace installs into projects: two-tree layout, copy-vs-reference boundary, design rationale
- kb-goals-in-always-loaded-context-guide-inclusion-decisions — installed KBs need explicit domain goals in the control-plane file
- files-not-database — files with git beat a database: universal interface, free versioning, zero infrastructure
- agents-md-should-be-organized-as-a-control-plane — theory for AGENTS.md as a control plane: invariants, routing, escalation boundaries
- instruction-specificity-should-match-loading-frequency — CLAUDE.md should be a slim router; match instruction specificity to loading frequency
- generate-instructions-at-build-time — generate CLAUDE.md and routing tables at build time rather than maintaining them by hand
- scenario-decomposition-drives-architecture — concrete use cases decomposed into step-by-step context needs
Other tagged notes
- 007-reports-directory-for-generated-snapshots — Decision to create kb/reports/ for generated, regenerable analytical snapshots — distinct from workshop (temporal work-in-flight) and notes (durable claims)
- 008-Stdlib-only core scripts — Core scripts use only Python stdlib by defining a strict frontmatter grammar that a regex parser handles completely
- Agent runtimes decompose into scheduler context engine and execution substrate — Practitioner runtime taxonomies converge on three separable components — scheduler, context engine, and execution substrate — because each solves a different class of model limitation