Reference Directory
Type: kb/types/index.md
← Parent
Subdirectories
Files
- Agent memory coverage (note) - How Commonplace's shipped surfaces realize agent-memory requirements: control plane, contracts, storage roles, validation, review, activation, promotion, lifecycle, and current gaps
- Available types (note) - Catalog of the types shipped by Commonplace — global base and utility types plus directory-scoped specialised types delivered with the framework scaffold
- Collections and types (note) - Explains how collection-level text and link contracts combine with path-referenced structural type contracts, including the COLLECTION.md surface consumed by write and connect workflows
- Commonplace agent memory gap plan (note) - Plan for closing Commonplace's current agent-memory gaps: session traces, candidates, cue activation, behavioral evaluation, lifecycle, source alignment, import, ranking, and authority
- Commonplace architecture (note) - Shipped Commonplace architecture — installed project layout, packaged runtime, scaffolded library under kb/commonplace/, empty user collections, promoted skills, and the library/user boundary
- Commonplace as a reflective self-improving system (note) - Classifies Commonplace as a human-inclusive reflective self-improving system and locates which functions in one observed pathway are human, joint, or computational
- Commonplace as an instrument (note) - What the KB application is for in Commonplace's design program — composition test, two worked provenance instances, and the transfer evidence the repository does not have
- Commonplace CLI commands (note) - Reference for the commonplace-* CLI commands shipped by llm-commonplace - project setup, validation, indexing, snapshots, note operations, and the review system
- Commonplace library (
commonplace.lib) (note) - Internal API reference for commonplace.lib parsing, indexing, type resolution, validation, and relocation modules used by CLI commands and review - Control-plane goals (note) - How Commonplace ships KB goals in always-loaded context — the AGENTS.md layout, the scaffolded AGENTS.md.template, and the install-time fill-in contract
- Design rationale management in Commonplace (note) - How Commonplace distributes design-rationale records across proposals, ADRs, contracts, and enforcement, without enforcing end-to-end continuity
- Documentation site (note) - How the ProperDocs site renders kb/ — the README-vs-index rule, the nav-generation hook, and the full inventory of reader landing pages (GitHub repo page, site home, per-collection landings) that positioning copy must keep consistent
- Freshness architecture (
commonplace.store+commonplace.freshness) (note) - Code architecture of the general freshness substrate: commonplace store, file-text versioning, target baselines, transitions, global status, and the review adapter - Freshness JSON contracts (v1) (note) - Canonical JSON shapes for commonplace-freshness-status, accept, ack, and retire (v1: review-pair targets, file-text inputs)
- Full improvement pass closure (note) - How the shipped full-improvement workflow reassays final note bytes, routes residual findings, and stops without claiming convergence
- Harness sub-agent model selection regression (note) - Observed Codex multi-agent regression that removed per-worker model selection and allowed Sol review executions to be persisted as Luna
- Instruction generation (note) - Commonplace's shipped build-time instruction generation flow — scaffold trees, template substitution, the
commonplace-initentry point, and the specific generated artifacts - Link vocabulary and linking approach (note) - Commonplace's linking approach: collection-owned outbound rules, reader-need labels, articulation tests, connect reports, and the shared label catalogue for COLLECTION.md authors
- Navigation (note) - How agents navigate a Commonplace KB using control-plane pointers, rg, titles/descriptions, indexes, links, connect reports, and possible future search layers
- Review system (note) - How to use the Commonplace review system — concepts, freshness, the review-batch workflow, and command surface
- Review system architecture (
commonplace.review+commonplace.cli.review) (note) - Code architecture of the Commonplace review subsystem: package layout, storage schema, canonical state vs derived output, freshness mechanism, module map, and finalization invariants - Scenario architecture (note) - Scenario-derived shipped architecture — single KB root with a library/user split under kb/commonplace/, package-provided commands, promoted skills, and a measurable scenario decomposition
- Storage (note) - Where Commonplace stores data — authored markdown under kb/, derived indexes rebuilt from those files, and the review subsystem's local SQLite database
- Text contract profiles (note) - Catalogue of Commonplace's text-contract profiles — proven, named bundles of quality goal, title conventions, attribution, and link grammar a COLLECTION.md may adopt, extend, or start from
- The collection–type split is asymmetric: collections never own frontmatter semantics (note) - Why the collection/type split is asymmetric: a type spec fully owns frontmatter semantics, COLLECTION.md owns only text-level features, plus the sanctioned moves when a field would vary by collection
- The declared Commonplace frame (note) - The declared boundary under which Commonplace's self-improvement, reflectivity, and allocation attributions are assessed — what is inside, what is outside, and how to cite or depart from it
- The tag-readme change as an observed causal-connection trace (note) - The ADR-026 tag-readme change traced commit by commit as one observed instance of causal connection between Commonplace and its self-representation, in both directions
- The tag-readme trace read as a self-improving loop (note) - Maps the ADR-026 tag-readme trace onto the search/evaluation/retention loop, showing which half of each step runs in code and which stays human
- The validation contract (note) - The base, type-rule, and schema sources of deterministic findings, their dereferencing limits, and the run-scoped execution model
- Type loading (note) - How Commonplace resolves a note's type contract at authoring and validation time - collection-scoped lookup, collection conventions, and skill-driven on-demand loading
- Where change candidates come from in Commonplace (note) - Surveys how problem-noticing and candidate-drafting happen in Commonplace beyond a maintainer's own judgment — skills, ephemeral reports, mechanical checks, freshness tracking, agent initiative
- Writing conventions for kb/reference/ (descriptive profile)