1.8 KiB
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
- Register a Git URL or local checkout.
- Run analysis to collect deterministic observed facts.
- Review candidate scope graphs produced by deterministic heuristics and, optionally, LLM assistance.
- Accept, edit, merge, reject, or relink candidates until the approved graph is useful.
- Use the approved graph for UI orientation, search, comparison, exports, and SCOPE.md generation.
Orientation Model
The preferred model is:
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.