# RPF-WP-0036 implementation — 2026-09-05

Implemented the ready plan's repository work and performed bounded live status
inspection using the existing SSH route to the pinned railiance01 cluster.
No credentials were fetched, no backup/restore or infrastructure mutation ran,
and no scheduler, external notification or owner acceptance was created.

## Delivered

- ADR-0004 and service records disclose unsupported availability/RPO/RTO
  commitments, existing evidence, retention and accountable decision owners.
  Local freshness/headroom thresholds are diagnostic, not SLAs.
- An admission checker reuses the apps-pg and rapp-postgres validators, verifies
  effective retention and placement ownership, and refuses a changed source
  hash/disclosure baseline. Five-consumer and mismatched-retention fixtures fail.
- A cluster-pinned collector supplies selected CNPG status, aggregate connection
  counts, metrics and unauthenticated OpenBao seal status. It reads no Secret,
  application data, session SQL text or logs. SSH argv are quoted; failures
  suppress raw output; successful observation files publish atomically at 0600.
- A closed observation evaluator distinguishes healthy, stale, missing, failed
  and unavailable samples, rejects wrong clusters/future/unknown payloads, and
  makes missing emission detectable through capture expiry. Transport remains
  explicitly unmonitored pending Q2 acceptance.
- Corrected placement/interface disclosures: tenant-engine's PostgreSQL cutover
  completed; platform-pg is 4/4 and the deployed platform-pg-2 holds sbom-nexus.
- Exact compatibility path/hash/caller inventories and a dated retention
  decision are ready for owner review. No functioning entry point was removed.
- ADR-0005 defers unrequested cache/general storage/broker deployments with
  explicit review triggers and prefers existing storage interfaces for demand.

## Live findings

The default workstation kube context and the misleading config-railiance01
file reached a different host; config-hosteurope depended on a down local
forwarder. The collector therefore uses existing SSH to railiance01 and checks
kube-system UID `a553c742-0115-43d4-99a4-a5ca56fe0786` before service reads.
No context was rewritten or tunnel deployed.

All three deployed database cells matched one instance, 1Gi memory limit,
100 aggregate connections and 30-day retention. Each was Ready, had a completed
backup from 02:15 UTC that morning and reported continuous archiving. Aggregate
connection/memory occupancy passed the local 80% diagnostic threshold. OpenBao
was unsealed. These are point-in-time observations, not new guarantees.

The checker also exposed three failed ESO resources (`SecretSyncedError`):
forgejo/forgejo-mailer, reuse/reuse-surface-runtime and
target-revenue/target-revenue-runtime. The earliest successful refresh was
2026-08-06. Their active/obsolete status and exact cause need consumer/platform
review before a lane repair or retirement; no credential diagnosis is inferred
from this condition alone.

Evidence: `docs/evidence/RPF-WP-0036-assurance-2026-09-05.json` includes capture,
evaluation time, live limits and sanitized failing-resource metadata. It does
not manufacture isolated-restore receipts from historical prose. Missing
restore/snapshot/offsite inputs and failed/stale ESO keep overall assurance
non-green, which is the expected correct result.

## Validation

Full repository unittest discovery: 176 passed. Focused assurance tests after
collector output hardening: 14 passed. Admission baseline check passed; fresh
live capture completed and its specification limits matched the source.
Cases cover wrong clusters, future/naive times, stale/replayed captures, missing
and failed signals, unexpected payloads/value-safe errors, unavailable native
reads, memory units, missing ownership/overflow, fifth consumer admission,
and unhonoured retention. This is not a restore or alert-delivery test.

## Remaining acceptance

T02/T05/T07 are done. T03 waits on fresh owner-validated recovery/offsite
receipts, independent recovery access and approved recurring execution.
T04 waits on the Q2 receiving contract and controlled failure/absence delivery;
ESO findings remain visible for exact owner disposition. T06 waits on accepted
handoffs and scoped alias cleanup. The installed brief generator still reads
legacy open aliases; generating the brief alone would reproduce those rows.

The prepared owner request content is in `docs/platform-ownership-handoffs.md`.
Its transmission is not claimed. The plan remains blocked on these explicit
acceptance gates; source implementation is not substituted for owner/live proof.