---
id: RMGR-EVIDENCE-0005-ISOLATED-REBUILD
type: evidence
title: "RMGR-WP-0005 isolated repository projection rebuild"
status: accepted
created: "2026-08-22"
updated: "2026-08-22"
workplan_task: RMGR-WP-0005-T07
observed_at: "2026-08-22T10:27:59Z"
---

# RMGR-WP-0005 isolated repository projection rebuild

## Result

The file-derived half of the cache-replacement gate passes for `repo-manager`.
The hub-native centralization half does not yet pass, so neither the workstation
database nor the remaining production projection may be discarded on this
evidence.

## Disposable proof environment

- PostgreSQL 16 container: `state-hub-rmgr-t07-20260822`
- database endpoint: `127.0.0.1:55439`
- State Hub API: `127.0.0.1:58005`
- schema head: `b8d4f0a2c6e1`
- fresh repository projection UUID: `f5632ed0-ef39-444a-a9bd-232eff9d6221`
- Repo Manager implementation: `707fb85`, `6e9c93e`
- State Hub implementation: `03c7924`, `059de93`

The database was recreated from an empty PostgreSQL database, migrated to head,
and seeded. Before the governed bootstrap, the target repository had zero
workplans. The bootstrap was invoked with:

```bash
rmgr registrar-reconcile \
  --path /home/worsch/repo-manager \
  --api-base http://127.0.0.1:58005 \
  --confirm-primary \
  --bootstrap-empty-projection
```

The command returned `applied`, correlation ID
`c98c37d4-5ad0-4090-a216-325e4ebaa5c9`, and verified no missing identifiers.

| Authoritative record | Files | Rebuilt projection | Missing |
| --- | ---: | ---: | ---: |
| Workplans | 9 | 9 | 0 |
| Tasks | 62 | 62 | 0 |
| Intakes | 2 | 2 | 0 |
| Decisions | 0 | 0 | 0 |

A second read-only consistency pass reported no issues, `9/9` source bindings,
zero failures, zero warnings, and result `pass`. The checkout remained clean and
synchronized with `origin/main`. This proves that an empty projection can retain
the repository's existing authoritative UUIDs rather than mint database-local
replacements.

## Hub-native centralization gate

The disposable projection correctly contained zero progress events, token
events, and agent messages: none of those records is reconstructed from files.
A read-only database comparison found:

| Record set | Workstation hub | Production central hub |
| --- | ---: | ---: |
| Repo-linked progress events | 35 | 2 |
| Repo-linked token events | 0 | 0 |
| Messages to/from `repo-manager` | 13 | 0 |

The workstation also still contains ten Repo Manager workplan rows: the nine
file-backed records plus one closed, unbound legacy duplicate of
`RMGR-WP-0001`. Production currently holds only the governed `RMGR-WP-0005`
pilot and its 12 tasks. These counts are observations, not a claim that every
row can be copied directly: progress events need stable idempotent replay, while
mutable message state requires its owner-specific ordered command contract.

Therefore T07 remains `progress`. The exact remaining gate is to migrate or
otherwise disposition the 35 workstation progress events and 13 message records
at their declared central owner, then repeat the comparison before replacing
the legacy workstation database. The isolated rebuild performs no such transfer
and authorizes no production mutation.

## Cleanup

The API and disposable database container were removed after capturing this
evidence. The environment contained projections only and is intentionally not a
recoverable source of work.