generated from coulomb/repo-seed
44 lines
2.2 KiB
Markdown
44 lines
2.2 KiB
Markdown
# Classification Strategy
|
|
|
|
Repo-scoping needs classification for orientation without pretending repository
|
|
behavior is always cleanly separable. The review UI should therefore support two
|
|
layers of classification:
|
|
|
|
- `primary_class`: the main class-defining attribute used for grouping, filtering,
|
|
and first-glance orientation.
|
|
- `attributes`: additional labels that can overlap, qualify, or challenge the
|
|
primary class.
|
|
|
|
Observed facts already follow this shape informally: `kind` is the primary class
|
|
(`interface`, `framework`, `test`, `documentation`, and so on), while path, name,
|
|
value, and metadata provide secondary attributes.
|
|
|
|
For approved and candidate graph elements, the target model is:
|
|
|
|
- Ability primary classes describe the repository's core domain or operational
|
|
purpose, such as `repository-intelligence`, `workflow-automation`, `content-
|
|
publishing`, or `developer-tooling`.
|
|
- Capability primary classes describe the kind of behavior exposed, such as
|
|
`ingestion`, `analysis`, `review`, `search`, `export`, `coordination`, or
|
|
`deployment`.
|
|
- Feature primary classes describe the delivery surface or user-visible feature
|
|
family, such as `business-usecase`, `ui`, `api`, `cli`, `backend`, `storage`,
|
|
`integration`, or `diagnostic`.
|
|
|
|
Features are the most fluid layer. A single feature can be both `ui` and `review`,
|
|
or both `api` and `ingestion`. The primary class should answer "where should a
|
|
curator first look for this?" Secondary attributes should preserve the overlap:
|
|
surface (`ui`, `api`, `cli`), intent (`review`, `search`, `diagnostic`), and
|
|
domain (`repository-intelligence`, `capability-mapping`) can all be true at once.
|
|
|
|
Current implementation status:
|
|
|
|
- Facts can be searched and filtered by `kind` in the element listing UI.
|
|
- Features can be searched and filtered by their existing single `type`.
|
|
- Abilities and capabilities currently use placeholder classes (`ability`,
|
|
`capability`) until the schema gains `primary_class` and `attributes`.
|
|
|
|
Next schema step: add `primary_class` plus a JSON/list `attributes` field to
|
|
candidate and approved abilities, capabilities, and features. Candidate generation
|
|
can then propose classifications, while review keeps the right to correct them.
|