T-XD9A-introduce-entitykind-and-composekinds-so-every-kind
State: planning/proposed · Impact: medium · Complexity: large
Five files enumerate all eleven kinds by hand. The package split needs each kind to carry its own registration record so the rosters can be derived from a list of packs.
Proposed
Section titled “Proposed”A kind.ts in the model spine defines EntityKind and defineEntityKind, which checks the
invariants now living in corpus/satisfied.test.ts. Each <type>/schema.ts exports a kind.
composeKinds(packs) derives ENTITY_SCHEMAS, CONTRACTS, PREFIXES, and SATISFIED_BY_TYPE.
The hand-written rosters are deleted.
Acceptance criteria
Section titled “Acceptance criteria”- AC-1:
_registry.ts,_contracts.ts,identifier.ts, andcorpus/satisfied.tsno longer list kinds by name. - AC-2:
defineEntityKindrejects a record whose prefix or plural collides with another pack at compose time, with a test. - AC-3: The full corpus validates and
docs generate --checkreports no drift.
Out of scope
Section titled “Out of scope”- Report, commit, site, index, setup, and op-discovery collectors (later tasks).
- Moving any file into a package.
Dependencies
Section titled “Dependencies”- none