# 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. One (`agent-harness`) has since been decided: dropped.

| Repository | Reason | Needed |
|---|---|---|
| ~~`agent-harness`~~ | no working copy on this machine | **dropped 2026-08-25** — see below |
| `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` — dropped (2026-08-25)

Decided by Bernd Worsch: the repository is superseded by `glas-harness` and the
`rein` concept, so there is nothing to restore. It is therefore **not** onboarded
to central, and its cache-only record is left to disappear when the local cache
database is discarded. Preserving it as a hub-only record would be the `ADR-001`
violation `ADR-010` calls out — a hub record with no backing file that nothing
can re-derive.

Successors verified present and classified on central before dropping:

| Successor | Domain | Category |
|---|---|---|
| `glas-harness` | infotech | tooling |
| `rein-aharness` | agents | tooling |

`rein-openweights` is part of the same concept but is still awaiting a
classification file, so it remains in the outstanding set below rather than
counting as a landed successor.

This is the one record of the 44 that is deliberately *not* recovered. Nothing
else in the export should be dropped without an equivalent decision.

## 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.