generated from coulomb/repo-seed
45 lines
1.8 KiB
Markdown
45 lines
1.8 KiB
Markdown
# Repository Scoping
|
|
|
|
Repository Scoping is the renamed and broadened product identity for the former
|
|
Repository Ability Registry. It helps users register repositories, analyze them,
|
|
curate repository characteristics, and publish a source-linked understanding of
|
|
what each repository is for.
|
|
|
|
## Core Workflow
|
|
|
|
1. Register a Git URL or local checkout.
|
|
2. Run analysis to collect deterministic observed facts.
|
|
3. Review candidate scope graphs produced by deterministic heuristics and,
|
|
optionally, LLM assistance.
|
|
4. Accept, edit, merge, reject, or relink candidates until the approved graph is
|
|
useful.
|
|
5. Use the approved graph for UI orientation, search, comparison, exports, and
|
|
SCOPE.md generation.
|
|
|
|
## Orientation Model
|
|
|
|
The preferred model is:
|
|
|
|
```text
|
|
Scope -> Ability -> Capability -> Feature -> Evidence -> Observed fact
|
|
```
|
|
|
|
Scope is the single root. Abilities, capabilities, and features are repository
|
|
characteristics at decreasing abstraction levels. Evidence explains why a
|
|
characteristic is credible. Observed facts are deterministic scanner records,
|
|
not human interpretation by themselves.
|
|
|
|
## Rename Notes
|
|
|
|
The user-facing name is Repository Scoping and the repo slug is `repo-scoping`.
|
|
The Python package remains `repo_registry`, and local configuration still uses
|
|
`REPO_REGISTRY_` for compatibility. Documentation should use Repository Scoping
|
|
for product references unless it is intentionally discussing historical material.
|
|
|
|
## Current Product Direction
|
|
|
|
The UI should lead with scope, abilities, capabilities, and features, with facts
|
|
available as drilldown evidence rather than as the primary orientation surface.
|
|
Candidates and approved entries are most useful when shown together with filters
|
|
for status, type, and search text so overlap and duplicates can be normalized.
|