--- id: RREG-WP-0006 type: workplan title: "Rename to repo-scoping and Full Custodian Integration" domain: capabilities repo: repo-scoping status: done owner: codex topic_slug: foerster-capabilities created: "2026-04-30" updated: "2026-04-30" depends_on: - CUST-WP-0034 - RREG-WP-0005 state_hub_workstream_id: "9daccfee-bcfc-49c5-bf68-36ea8c205a09" --- # RREG-WP-0006 — Rename to repo-scoping + Full Custodian Integration ## Goal Complete the identity shift from "repository ability registry" to "repository scoping service". The name `repo-registry` describes internal mechanics (registering repos); `repo-scoping` describes the utility value (establishing and maintaining repository scope). This rename follows naturally from the SCOPE.md generation feature (RREG-WP-0005) becoming the primary output. After the rename: run the first full ecosystem SCOPE.md refresh using the new capability, validate all attached repos pass the updated DOI C5 checks, and clean up all references to the old name across the custodian ecosystem. Depends on: CUST-WP-0034 (delegation infrastructure), RREG-WP-0005 (SCOPE.md generation feature must exist before the rename makes sense) ## T01: Rename the Gitea repository ```task id: RREG-WP-0006-T01 status: done priority: high state_hub_task_id: "55341e24-f936-4c74-86e4-fa084ab4a25c" ``` In Gitea: Settings → Rename repository from `repo-registry` to `repo-scoping`. Gitea will set up a redirect from the old name automatically. Then update the local checkout: ```bash git -C /home/worsch/repo-registry remote set-url origin gitea-remote:coulomb/repo-scoping.git ``` Verify the push path works: ```bash git -C /home/worsch/repo-registry push --dry-run ``` Acceptance: `git -C /home/worsch/repo-registry remote -v` shows the new URL; a dry-run push succeeds. Implementation note 2026-04-30: The server-side Gitea repository was renamed, the local `origin` remote now points to `gitea-remote:coulomb/repo-scoping.git`, and `git push --dry-run` succeeds. ## T02: Update state-hub registration and repo path ```task id: RREG-WP-0006-T02 status: done priority: high state_hub_task_id: "8a803b12-d991-48c7-8640-8876320815b1" ``` Update the managed_repo record in the state-hub: 1. Call `update_repo_path()` or PATCH `/repos/repo-registry/` to set the new slug `repo-scoping` and update `git_url` to the new Gitea URL. 2. Run `make fix-consistency-here REPO_PATH=/home/worsch/repo-registry` so the consistency checker re-registers the host path under the new slug. 3. Rename the local directory (optional — the directory name is not canonical, only the git remote URL matters): ```bash mv /home/worsch/repo-registry /home/worsch/repo-scoping ``` If the directory is renamed, also update any absolute paths that reference `/home/worsch/repo-registry` in CLAUDE.md files, settings, and scripts. Acceptance: `GET /repos/repo-scoping/` returns the managed repo record; `GET /repos/repo-registry/` returns 404; `make fix-consistency` reports no slug-mismatch issues. Implementation note 2026-04-30: The State Hub managed repo record now uses slug/name `repo-scoping`, remote URL `gitea-remote:coulomb/repo-scoping.git`, and the existing local path `/home/worsch/repo-registry`. `GET /repos/repo-scoping/` returns the record, `GET /repos/repo-registry/` returns 404, and the consistency checker passes via the State Hub virtualenv. ## T03: Update all references in the-custodian ```task id: RREG-WP-0006-T03 status: done priority: high state_hub_task_id: "4b630593-cfd7-4313-b774-5f7eeed819ec" ``` Search the-custodian for every occurrence of `repo-registry` that refers to this repository (not the generic concept) and update to `repo-scoping`: - `canon/` — project charter files, full_circle_map, concept seeds - `workplans/` — any workplan that names `repo-registry` as a dependency or provider repo in capability registrations - `state-hub/dashboard/src/docs/scope.md` — update cross-references or replace with a redirect note pointing to `repo-scoping/docs/scope-md-spec.md` - `agents/agent-scope-analyst.md` — provider repo reference updated in CUST-WP-0034-T04; verify it reflects the new name here - `~/.claude/projects/…/memory/MEMORY.md` and memory files — update entries that name `repo-registry` as the capabilities domain repo - `CLAUDE.md` (global and project) — if `repo-registry` appears as an example or reference Update the capability registrations (registered in CUST-WP-0034-T03): PATCH `/capabilities/scope.generate` and `/capabilities/scope.update` to set `provider_repo: repo-scoping`. Acceptance: `grep -r "repo-registry" /home/worsch/the-custodian/` returns no hits that refer to this repository (hits inside this workplan file are acceptable as historical references). Implementation note 2026-04-30: Updated Custodian workplan references in `CUST-WP-0034` and `CUST-WP-0033` from `repo-registry` to `repo-scoping`, and verified `/home/worsch/the-custodian` has no remaining `repo-registry` hits outside excluded generated/dependency directories. The State Hub capability catalog entries for `scope.generate` and `scope.update` now have provider `repo-scoping`. ## T04: Run first full ecosystem SCOPE.md refresh ```task id: RREG-WP-0006-T04 status: done priority: high state_hub_task_id: "3f25317f-5d4e-464c-8c76-80f61d6724d3" ``` For every registered repo that has a local path available on this host: 1. `GET /repos/{slug}/scope/diff` — inspect whether SCOPE.md is absent, stub-only, or genuinely stale 2. For repos where `needs_update: true` or SCOPE.md is absent: issue `POST /repos/{slug}/scope/write` to generate and write the file 3. For repos where the SCOPE.md is curator-owned text that should not be overwritten wholesale: review the diff and apply only the sections flagged as `stale` or `missing`, leaving curator-owned sections untouched Priority order for the refresh: 1. Repos with no SCOPE.md at all (C5a fail) 2. Repos with a stub SCOPE.md and no approved characteristics (flag for analysis in repo-scoping first) 3. Repos with approved characteristics but stale SCOPE.md (C5b/C5c warn) Log each write as a progress event on the custodian workstream. Acceptance: `make check-doi` across all reachable repos reports no C5a failures; C5b/C5c warns are reduced to repos genuinely awaiting curator input. Implementation note 2026-04-30: Blocked for a full ecosystem refresh. The State Hub DoI engine still reports C5 only as file presence, so the required C5b/C5c structure baseline from CUST-WP-0034 is not available yet. Also, repo-scoping currently has approved-characteristic data for only three repos, so most State Hub managed repos cannot yet be generated without first being registered and analyzed in repo-scoping. Diff checks confirmed reachable curator-owned SCOPE.md files should not be overwritten wholesale. Follow-up 2026-05-01: Submitted State Hub extension request `EP-CUST-SCOPE-C5-STRUCTURE` (`4d4457bd-3c20-4cb0-8d0e-5e52f2cb1d9b`) and Custodian task `b5d5a1f2-4148-4a1e-86e0-2249f6d633cc` under `CUST-WP-0034` to provide the structured C5a/C5b/C5c and dispatch signals needed to unblock this refresh. Implementation note 2026-05-01: After State Hub exposed structured C5a/C5b/C5c and dispatch scope details, refreshed reachable SCOPE.md files without overwriting curator-owned content. Most repos needed heading-only compatibility updates (`Related / Overlapping`, and Railiance `Out of Scope` headings); `llm-connect` was upgraded from the older SCOPE format to canonical sections with capability blocks. Dispatch now reports `scope_needs_review: false` for all reachable repos. ## T05: Validate full DoI C5 pass and run consistency sync ```task id: RREG-WP-0006-T05 status: done priority: medium state_hub_task_id: "860bbc02-c7f4-46cd-9898-41d3454c3ea5" ``` After T04: 1. Run `make ingest-capabilities-all` to refresh the capability catalog from all updated SCOPE.md files. 2. Run `make fix-consistency REPO=repo-scoping` to sync workplan task statuses to the DB. 3. Run `make check-doi` for the custodian and repo-scoping and confirm both pass C5a/b/c. 4. Verify the dashboard "Repo DoI" page reflects the updated scores. Acceptance: no C5a failures ecosystem-wide; the DoI summary endpoint at `GET /repos/doi/summary` shows improved aggregate C5 scores compared to pre-workplan baseline. Implementation note 2026-05-01: Refreshed the capability catalog from updated SCOPE.md files with the State Hub ingestion script; four new ecosystem entries were created, then the `llm-connect` host path was corrected and three llm-connect capability entries were ingested. Ran the repo-scoping consistency checker with `--fix`; it reported 0 fail / 0 warn / 0 info. Dispatch checks for repo-scoping, the-custodian, llm-connect, and markitect-project report `scope_needs_review: false` and C5a/C5b/C5c all pass. ## T06: Update SCOPE.md for repo-scoping itself ```task id: RREG-WP-0006-T06 status: done priority: medium state_hub_task_id: "1f5ecca9-1c73-4f30-b0e7-4a065146deeb" ``` After the rename, regenerate `SCOPE.md` for repo-scoping to reflect: - New name in the one-liner and core idea - Updated "In Scope" to lead with SCOPE.md generation as the primary output - Updated "Provided Capabilities" blocks (scope.generate, scope.update added in RREG-WP-0005-T05 now appear) - "Related / Overlapping" referencing the-custodian as the coordination layer Run the generator against itself: ```bash POST /repos/repo-scoping/scope/write ``` Then review and apply any curator-owned sections manually. Acceptance: `SCOPE.md` at repo root passes all three C5a/b/c checks; the one-liner accurately describes the repo-scoping utility. Implementation note 2026-04-30: Rewrote root `SCOPE.md` in the canonical section structure for `repo-scoping`, preserving the curated utility story, State Hub relationship, and `scope.generate` / `scope.update` capability blocks. The local `ScopeValidator` reports the file as valid.