Documentation, terminology repo cleanup.

wiki/AbilityExtractionHeuristics.md

@@ -4,7 +4,7 @@ AbilityExtractionHeuristics
 
 # Ability / Capability Extraction Heuristics v0.1
 
-## Repository Ability Registry
+## Repository Scoping
 
 ## 1. Purpose
 

wiki/ArchitectureSketch.md

@@ -1,8 +1,8 @@
 ArchitectureSketch
 
-* Repository Ability Registry — Architecture v0.1*
+* Repository Scoping — Architecture v0.1*
 
-# Repository Ability Registry — Architecture v0.1
+# Repository Scoping — Architecture v0.1
 
 ## 1. Core architectural idea
 

wiki/FunctionalRequirementsSpecV0.1.md

@@ -1,14 +1,14 @@
 FunctionalRequirementsSpecV0.1 
 
-*Repository Ability Registry Functionality*
+*Repository Scoping Functionality*
 
-Here is a **Functional Requirements Specification (FRS)** for the **Repository Ability Registry (v0.1)**—focused strictly on **externally observable system behavior**, aligned with your architecture and PRD.
+Here is a **Functional Requirements Specification (FRS)** for the **Repository Scoping (v0.1)**—focused strictly on **externally observable system behavior**, aligned with your architecture and PRD.
 
 ---
 
 # **Functional Requirements Specification (FRS)**
 
-## **Repository Ability Registry v0.1**
+## **Repository Scoping v0.1**
 
 ---
 

wiki/LandingPage.md

@@ -1,8 +1,8 @@
 LandingPage
 
-*Introducing the Repository Ability Registry*
+*Introducing the Repository Scoping*
 
-# **Repository Ability Registry**
+# **Repository Scoping**
 
 ## **Understand What Code Can Do. Instantly.**
 
@@ -26,7 +26,7 @@ Every day, developers and architects face the same problem:
 
 ## **What if repositories could explain themselves?**
 
-The **Repository Ability Registry** transforms Git repositories into **structured, inspectable knowledge**.
+The **Repository Scoping** transforms Git repositories into **structured, inspectable knowledge**.
 
 It reveals:
 
@@ -95,7 +95,7 @@ The registry provides a shared, machine-readable understanding.
 
 Between raw code and real-world usefulness, there is a gap.
 
-The **Repository Ability Registry** fills it.
+The **Repository Scoping** fills it.
 
 ---
 

wiki/ProductRequirementsSpecificationV0.1.md

@@ -1,16 +1,16 @@
 ProductRequirementsSpecV0.1
 
-*Repository Ability Registry Requirements*
+*Repository Scoping Requirements*
 
 # **Product Requirements Document (PRD)**
 
-## **Repository Ability Registry (v0.1)**
+## **Repository Scoping (v0.1)**
 
 ---
 
 # 1. **Purpose**
 
-The **Repository Ability Registry** provides a structured, inspectable orientation layer for code repositories by mapping them from **abilities → capabilities → features → implementation → evidence**.
+The **Repository Scoping** provides a structured, inspectable orientation layer for code repositories by mapping them from **abilities → capabilities → features → implementation → evidence**.
 
 It enables developers, architects, and agents to:
 
@@ -487,7 +487,7 @@ Evidence:
 
 # 14. **Positioning**
 
-> The Repository Ability Registry is the missing orientation layer between raw code and practical reuse—making repositories understandable, comparable, and actionable.
+> The Repository Scoping is the missing orientation layer between raw code and practical reuse—making repositories understandable, comparable, and actionable.
 
 
 

wiki/RepositoryRegistry.md

@@ -1,3 +1,5 @@
+> Historical note: this page predates the rename to Repository Scoping. See `RepositoryScoping.md` for the current product identity and terminology.
+
 RepositoryRegistry
 
 *Exploring repositories by ability, capability and features*

wiki/RepositoryScoping.md

@@ -0,0 +1,44 @@
+# 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.

wiki/UseCaseCatalog.md

@@ -4,11 +4,11 @@ UseCaseCatalog
 
 # Use Case Catalog
 
-## Repository Ability Registry
+## Repository Scoping
 
 ## 1. Scope
 
-The **Repository Ability Registry** allows users to register Git repositories, analyze their contents, extract or maintain structured descriptions of their **abilities, capabilities, features, evidence, and implementation locations**, and make this information searchable through efficient interfaces and a web UI.
+The **Repository Scoping** allows users to register Git repositories, analyze their contents, extract or maintain structured descriptions of their **abilities, capabilities, features, evidence, and implementation locations**, and make this information searchable through efficient interfaces and a web UI.
 
 Core promise: