docs: close stale repo manager work

Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a053ff-1d6f-7fe2-ac1c-a6eb40a42a0c

docs/evidence/RMGR-WP-0005-cache-centralization-2026-08-31.md

@@ -0,0 +1,28 @@
+# RMGR-WP-0005 cache and hub-native centralization evidence
+
+Date: 2026-08-31
+
+The workstation no longer runs a State Hub API. `127.0.0.1:8000` is the
+operator's SSH relay to the sole `railliance01` primary, whose health reports
+`instance_role: primary`, `instance_label: railiance01`, and a current schema.
+The retired production sweep remains disabled and has no checkout or SSH
+hostPath mount.
+
+Repo Manager's advisory file cache was rebuilt from the current checkout at
+commit `e8e2747313f1f041062980a962466a7a39daa98d`. It contains 96 records,
+reports `stale: false`, and its indexed/current source fingerprint is
+`b9cee3bce4ca7d1a28cadb5f9204774a0451a6456efbc3d02f9e556a27b8d6b9`.
+
+The earlier workstation database had recorded 35 progress events linked to
+`RMGR-WP-0005` and 13 messages to/from `repo-manager`, while the then-primary
+had 2 and 0. On 2026-08-31 the central primary contains 10 linked progress
+events and one direct Repo Manager message. A read-only query of the remaining
+local PostgreSQL service found an empty replacement database: zero matching
+progress events and zero matching messages. The old local-only rows therefore
+cannot now be migrated; the infrastructure cutover has dispositioned them as
+discarded cache history. Their counts and the material implementation outcomes
+remain in the 2026-08-22 evidence and this workplan.
+
+This is a limitation, not a reconstructed-history claim. New hub-native writes
+have one owner, the central primary; local work remains file-first and the
+advisory cache is disposable/rebuildable.

docs/evidence/RMGR-WP-0011-production-client-proof-2026-08-31.md

@@ -0,0 +1,35 @@
+# RMGR-WP-0011 production SBOM Nexus client proof
+
+Date: 2026-08-31
+
+The owning coordination workplan `CUST-WP-0064` is finished. Production SBOM
+Nexus is healthy on immutable digest
+`sha256:1da0f4f008643a0dec3f00bbad15f287103aa4b469577b78cfe1d67f8b3cbe31`
+with migration `0002`; controlled `forgejo-archive-v1` scans and an unassisted
+scheduled authoritative snapshot are evidenced by that plan.
+
+Against a temporary operator-only port-forward to the internal Nexus Service,
+Repo Manager's own command completed successfully:
+
+```text
+SBOM_NEXUS_URL=http://127.0.0.1:18010 uv run rmgr sbom source-ref \
+  --path . --slug repo-manager --project --confirm-authoritative
+```
+
+It resolved `coulomb/repo-manager` at exact public Forge revision
+`e8e2747313f1f041062980a962466a7a39daa98d`, projected
+`kind: forgejo-archive-v1` with `checkout_path: null`, and Nexus echoed the
+structured source reference unchanged. The response was explicitly
+`mode: authoritative-service`, `authoritative: true`,
+`product_owner: sbom-nexus`, and `writes_state: true`.
+
+The same production client read the latest-snapshot and licence-report routes.
+Both returned the authoritative-service context; the fleet licence report had
+19 groups and 4 direct copyleft production findings. Repo Manager's own
+repository currently has no persisted snapshot (`snapshot_id: null`, zero
+entries), which is truthful Nexus state rather than a local preview.
+
+Source inspection finds SBOM behavior only in the bounded Nexus client,
+controlled source-reference resolver, and deprecated local-preview delegate.
+Repo Manager contains no scanner, snapshot store, freshness/catch-up policy, or
+licence classifier. The temporary port-forward was stopped after the proof.