# RMGR-WP-0005 Repo Manager pilot evidence

**Observed at:** `2026-08-22T07:59:49Z`  
**Fleet namespace:** `helixforge`  
**Scope:** `repo-manager` / `RMGR-WP-0005` only

## Outcome

The first repository cutover completed without rollback. The workstation
projection was migrated in place from minted UUIDs to deterministic UUIDv5
identifiers. The production registrar had no Repo Manager projection, so it was
upgraded and rebuilt from the same authoritative file identifiers. Both now
resolve `RMGR-WP-0005` as
`6dcf854e-9229-569d-90f0-2d9df235a61d`.

The sealed fleet plan remains unchanged and no other repository was migrated.

## Recovery points

| Projection | Backup | SHA-256 | Size |
| --- | --- | --- | --- |
| Workstation | `/tmp/state-hub-rmgr-wp-0005-pilot-preapply.dump` | `8c5a4ef4cddef2d3a1af0303eeccbb6206613fa1a5fe932364262b3623f77950` | 4.4 MiB |
| Production registrar | `/tmp/state-hub-registrar-rmgr-wp-0005-preapply.dump` | `01753744bc844b154900ead916f122946c5414e77f888c3e18016cae6d3d8929` | 4.6 MiB |

Both are PostgreSQL custom-format archives with readable restore catalogs.
The production deployment can also return to Helm revision 9 / image
`main-d8808bf`. Recovery must stop writes first and restore into an isolated or
replacement database before endpoint cutover; no destructive in-place restore
was attempted.

## Workstation projection migration

- Alembic advanced to `b8d4f0a2c6e1`; 20/20 foreign keys into workplan/task
  identities use `ON UPDATE CASCADE`.
- The repository-atomic database executor applied six replacements and no
  assignments. Six durable aliases have status `applied`.
- All old rows are absent and all new rows are present.
- Cascades preserved 12 task-to-workplan links, 12 workplan progress links, one
  decision link, and three task progress links.
- The guarded file executor applied the same six replacements from sealed plan
  `5a2e0d1d4e6e121780a0e66a83e07a718f3050e8f1c6b94328b86b92de290a0c`.
- File migration commit: `5de754a`; final consistency commit: `40ad9e9`.
- The rebuilt local Repo Manager cache is fresh with 73 records.

## Production registrar deployment and rebuild

- Helm dry-run selected `main-697dd49` and rendered no host path, operator-home,
  SSH, or sweep environment entries.
- Helm revision 10 deployed atomically; the live release reports
  `sweep.enabled: false`, no volumes or mounts, and `/state/health` returns 200
  with a connected database.
- Alembic advanced from `f0a1b2c3d4e5` to `b8d4f0a2c6e1`; 20/20 relevant
  foreign keys cascade updates and the alias table exists.
- The logical `repo-manager` repository was absent and was registered as
  `a9d105c6-10fa-4cf9-8bc1-e248476698d3` under topic
  `cee7bedf-2b48-46ef-8601-006474f2ad7a`.
- Governed projection repair created deterministic `RMGR-WP-0005` and 12 tasks.
  The 12 file task UUIDs and 12 production task UUIDs are byte-for-byte equal.
- The new workplan lookup returns 200; old minted UUID
  `7ddb5421-d960-4a3c-94b1-40b6c96abfab` returns 404.
- A second read-only consistency pass reports no issue for `RMGR-WP-0005`.
  Eight legacy/random-ID Repo Manager workplans remain explicit non-fixable
  stale references and were not ingested.
- Production aliases remain empty, as expected for rebuilding an absent
  projection rather than rewriting an existing primary key.

The first classified repository-create request returned 500 because the
contained image does not package `repo-classification.allowed.yaml` and has no
Custodian host mount. No row was created. The minimal logical record then
created successfully. Packaging classification canon is follow-up work; host
mount containment was not weakened.

The scoped registrar child returned the broader consistency exit code 1 because
of the eight intentionally untouched legacy references. It nevertheless created
and returned the exact target UUID and tasks. Repo Manager commit `e656f7f`
adds `--repair-workplan` and exact target verification. In the managed Codex
sandbox the child could not create `.git/index.lock` for its generated brief;
the complete local projection restored the brief and pushed consistency commit
`4b5e48f`. Follow-up `8eff8d3` makes this containment explicit: projection-only
repair restores a generated-brief change but rejects any authoritative-file
mutation. No authoritative identifier file changed during registrar rebuild.

## Published implementation

- State Hub schema/executor: `cb1b028`
- State Hub deterministic rebuild API/consistency: `697dd49`
- State Hub declared production state and pilot record: `52a7d6b`
- Repo Manager sealed plan: `e52ce3e`
- Repo Manager file migration: `5de754a`
- Repo Manager projection-repair wrapper: `e656f7f`
- Repo Manager projection-only writeback containment: `8eff8d3`

## Gate after the pilot

This evidence authorizes no fleet-wide mutation. Before a wider cutover, select
the next repository batch, refresh preflight/source fingerprints, retain a
per-database restore point, and preserve the same database-first/file-second
rollback boundary. The scoped credential/sweep replacement in
`RMGR-WP-0005-T12` remains separate and blocked; production sweeping stays off.