Reference Directory

Type: kb/types/generated-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
  • Collection prototypes (note) - Catalogue of optional Commonplace collection prototypes: creation-time contract text that may be copied and then becomes an independently owned COLLECTION.md
  • Collections and types (note) - How Commonplace composes collection and type contracts, uses path-valued type pointers, and locates global and collection-local type specs
  • 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) - Architecture boundaries of an installed Commonplace project: user KB, shipped library, command runtime, skill projections, and path invariance
  • 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
  • Content routing (note) - Routing table from content kind to destination — instructions and contracts, reference, ADRs, notes, commit messages, log, workshop — with the regeneration source and consuming operation that justify each row
  • 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 (note) - Architecture boundaries of Commonplace freshness: target identity, accepted-input applicability, review adaptation, transitions, and concurrency guards
  • 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 July Codex regression that let 268 Sol review results be persisted as Luna, plus the August partial restoration of per-worker model overrides
  • Instruction generation (note) - Commonplace's shipped build-time instruction generation flow — scaffold trees, template substitution, the commonplace-init entry 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) - Architecture boundaries of the Commonplace review subsystem: parent-owned dispatch, canonical state, derived artifacts, atomic finalization, and freshness hashing
  • 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
  • Source-adoption policy (note) - How Commonplace decides which borrowed ideas to adopt — a fast pass for programming patterns on the software-mechanism bet, first-principles or target-side warrant for other sources, and direct observation as a separate evidence path
  • Storage (note) - Authority and lifecycle boundaries among Commonplace's authored files, local source copies, derived artifacts, and operational state
  • 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 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
  • 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/