Semantic concept catalogue

File-level coordination misses the conflicts that matter. The semantic concept catalogue is the layer that makes concept-level matching possible: a registry of what your codebase means, not just what files it contains.

A concept is a domain-tagged abstraction in the codebase. It carries a canonical name, the files and symbols that realize it, and a current contract checksum.

auth.session-store-contract
auth.middleware-chain
billing.invoice-finalizer
ingestion.rate-limiter

The registry stores names, contracts, file metadata, and the links between them. It does not store your source code. That keeps the catalogue navigable for lookup and keeps the data boundary honest.

Every concept has a domain: a flat tag for where it lives, like auth, billing, or ingestion. Domains are organizational tags, not search partitions. Lookup is global. The intent's apparent domain biases ranking but never bounds the search.

A cross-domain plan such as migrate billing to use the new auth contract is first-class, not an edge case. Domains seed from the repo's top-level directories, so the catalogue needs no manual configuration to start.

The registry is master-owned and master-evolved. Every accepted intent feeds the matching loop, which adds realizations, refines names, and records modifications. The catalogue is a living artifact that drifts under the master's control.

Every mutation is an event on an append-only log, so the registry's state at any prior point is reconstructable. When the matching loop finds no strong candidate, the master proposes a new concept and asks the developer to confirm it through the normal agent conversation.

The dashboard exposes the registry as a browsable surface: concepts, their realizing files, and the edges between them. realizes, depends_on, modifies, and breaks edges show how a change ripples before anyone runs it.

See how the catalogue powers onboarding in the living shared world model, or how it drives matching in intent-level conflict detection.