feat(workplan): close CUST-WP-0067 T04 and T05, open T09

rmgr repo-onboard is the missing managed_repos write path. 33 of 44 cache-only
repositories onboarded to central (78 -> 111); the other 11 carry written
dispositions rather than guessed classifications.

T04 uncovered why onboarding only worked from a workstation: the hub resolved
its classification allowed-values file from hardcoded developer checkouts, so
every classification write 500'd in the container. T09 delivers that file.

The local cache database must not be discarded yet — 11 records live only there.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/recovery/onboarding-disposition-2026-08-24.md

@@ -0,0 +1,54 @@
+# Disposition — repositories not onboarded to central
+
+CUST-WP-0067-T05, 2026-08-24. Of the 44 cache-only repository records, 33 were
+onboarded to central via `rmgr repo-onboard`. Central went from 78 to 111
+repositories. These 11 did not, each for a reason that needs a decision rather
+than a retry.
+
+| Repository | Reason | Needed |
+|---|---|---|
+| `agent-harness` | no working copy on this machine | restore from remote, or drop |
+| `binky-control` | no `.repo-classification.yaml` | author with the repo owner |
+| `clay-borg` | no `.repo-classification.yaml` | author with the repo owner |
+| `direkt-vermittlung-de` | no `.repo-classification.yaml` | author with the repo owner |
+| `polycode-sim` | no `.repo-classification.yaml` | author with the repo owner |
+| `railiance-telemetry` | no `.repo-classification.yaml` | author with the repo owner |
+| `ralph-workplan` | no `.repo-classification.yaml` | author with the repo owner |
+| `rein-openweights` | no `.repo-classification.yaml` | author with the repo owner |
+| `soul-frame` | commits not pushed | owner decides whether to publish |
+| `testdrive-jsui` | no `.repo-classification.yaml` | author with the repo owner |
+| `timeline-svg` | no `.repo-classification.yaml` | author with the repo owner |
+
+## Why these were not forced
+
+Classification is not mechanical (`CUST-WP-0065-T01`): the sector domain
+describes intended users, and guessing it produces a confident wrong answer
+that is harder to correct than a missing one. Nine repositories need a
+classification file authored with their owner.
+
+`soul-frame` has three unpushed commits carrying research content. Onboarding
+correctly refused — a hub record whose backing file is only local cannot be
+re-derived — but publishing someone's unpublished work is an owner decision,
+not a side effect of onboarding. Once pushed:
+
+```bash
+uv run --project ~/repo-manager rmgr repo-onboard \
+  --path ~/soul-frame --api-base http://127.0.0.1:8000
+```
+
+`agent-harness` has no working copy here at all and must be restored from its
+remote or explicitly dropped. Do not preserve it as a hub-only record — that is
+the `ADR-001` violation `ADR-010` calls out.
+
+## Classification is deferred for all 33
+
+Every onboarded record carries its domain but no classification fields. The
+hub returned 500 on each classification write because `api/classification.py`
+resolved its allowed-values file only from developer workstation checkouts, so
+in the container none exist. Fixed by `REPO_CLASSIFICATION_ALLOWED_PATH`
+(state-hub `05dda8d`), which still needs the canon file delivered into the pod
+and the variable set — tracked as `CUST-WP-0067-T09`.
+
+The records are correct and re-derivable in the meantime: the classification
+files are committed and pushed, so re-running onboarding projects them once the
+hub can validate.

workplans/CUST-WP-0067-hub-authority-target-resolution.md

@@ -188,7 +188,7 @@ the API base.
 
 ```task
 id: CUST-WP-0067-T04
-status: todo
+status: done
 priority: high
 state_hub_task_id: "ffa141d5-331d-543d-8b87-516f27973a22"
 ```
@@ -207,11 +207,25 @@ onboarding path must be able to introduce a repository central has not seen.
 Acceptance: onboarding a fresh repository from the workstation produces a central
 record with no manual step; re-running is idempotent.
 
+**Done (2026-08-24):** `rmgr repo-onboard` (repo-manager `1be6d85`). Validates
+the classification file, then refuses to proceed if it has uncommitted changes,
+no upstream, or unpushed commits — a hub record whose backing file is only local
+cannot be re-derived by anyone. `--api-base` has no default on purpose; a silent
+localhost default is the original defect, not a convenience. Six guard tests;
+full suite 122 passed.
+
+This uncovered why onboarding only ever worked from a workstation, which is
+deeper than the tunnel: `api/classification.py` resolved its allowed-values file
+from three hardcoded developer checkout paths and nothing else, so inside the
+container every classification write returned 500. Fixed with
+`REPO_CLASSIFICATION_ALLOWED_PATH` (state-hub `05dda8d`); delivering the canon
+file into the pod is `T09`.
+
 ## Onboard the 44 cache-only repositories to central
 
 ```task
 id: CUST-WP-0067-T05
-status: todo
+status: done
 priority: medium
 state_hub_task_id: "078159e6-5ecd-5f9d-b3ec-1fabf60955f7"
 ```
@@ -230,6 +244,23 @@ record it. Do not preserve it as a hub-only record.
 Acceptance: every record in the recovery export exists on central or carries a
 written disposition; only then may the local cache database be discarded.
 
+**Done (2026-08-24):** 33 of 44 onboarded to central, which went from 78 to 111
+repositories. The remaining 11 each carry a written disposition in
+`docs/recovery/onboarding-disposition-2026-08-24.md`: nine need a classification
+file authored with their owner, `soul-frame` has unpushed research commits that
+are the owner's to publish, and `agent-harness` has no working copy and must be
+restored or explicitly dropped.
+
+None were forced. Classification is not mechanical (`CUST-WP-0065-T01`), and a
+confident wrong domain is harder to correct than a missing one.
+
+All 33 landed with their domain but no classification fields, pending `T09`.
+They are re-derivable: the classification files are committed and pushed, so
+re-running onboarding projects them once the hub can validate.
+
+**The local cache database may not be discarded yet** — 11 records still exist
+only there.
+
 ## Correct the ADR-010 framing and record the retirement
 
 ```task
@@ -399,3 +430,30 @@ the remote port map lists no tunnel for either service.
 
 `state-hub-mcp-railiance01` is now unblocked for removal — the last thing
 depending on it is the documented registration, which has been repointed.
+
+
+## Deliver the classification allowed-values file to central
+
+```task
+id: CUST-WP-0067-T09
+status: todo
+priority: high
+```
+
+`api/classification.py` resolved its allowed-values file from three hardcoded
+developer workstation checkouts, so in the container none exist and every
+classification write returned 500. This is why repository classification could
+only ever be written from a workstation, and why all 33 repositories onboarded
+under `T05` carry a domain but no classification fields.
+
+`REPO_CLASSIFICATION_ALLOWED_PATH` now overrides the search (state-hub
+`05dda8d`), but the file still has to reach the pod. Canon lives in
+`the-custodian`, and the hub must not grow a second copy that silently drifts
+from it — mount it from a ConfigMap generated from the canon file, and make the
+generation step part of the release rather than a manual copy.
+
+Once it serves, re-run onboarding across the 33 to project their classification.
+
+Acceptance: a classification PATCH succeeds against central; the 33 records
+carry their categories; the allowed-values source in the cluster is traceable
+to `the-custodian/canon/standards/repo-classification.allowed.yaml`.