Advance RPF-WP-0021 platform onboarding

docs/evidence/core-hub-postgres-capacity-admission-2026-08-20.md

@@ -0,0 +1,67 @@
+# Core Hub PostgreSQL capacity admission — 2026-08-20
+
+Workplan: `RPF-WP-0021-T02`
+
+Target: railiance01 `databases/platform-pg`
+
+Mode: bounded live occupancy probe; no application data or credential value
+was read or recorded.
+
+## Question
+
+Can Core Hub occupy the fourth and final declaration slot on `platform-pg`
+without raising the current 1Gi pod limit or exceeding the explicit
+100-connection aggregate?
+
+The four declarations are `audit-core`, `tenant-engine`, `core-hub`, and the
+counted isolation probe. Each workload declaration reserves 12 runtime plus
+two migration connections; the probe's smaller allowance is deliberately
+overstated here, making 56 a conservative declared-pool occupancy.
+
+## Method
+
+A temporary namespace labeled as a `platform-pg` client received the existing
+bootstrap Secret by namespace-to-namespace projection without printing its
+values. A separate client pod opened 56 sessions in four named groups of 14.
+This kept client-process memory outside the database pod. The run then repeated
+the same 56-session occupancy with 13 idle and one bounded active sort query
+per group. The namespace and copied Secret were deleted after the run.
+
+The active query materialized and sorted 100,000 generated integers, then held
+the backend briefly for observation. It did not access an application table.
+
+## Observations
+
+| Signal | Before | Declared occupancy / observed peak |
+| --- | ---: | ---: |
+| Probe sessions | 0 | 56 (14 in each named group) |
+| All PostgreSQL sessions | 9 | 65 |
+| Active / idle sessions | 1 / 2 | 5 / 54 in the mixed run |
+| PostgreSQL pod memory | 89Mi | **174Mi maximum observed** |
+| PostgreSQL pod CPU | 7m | 82m during connection startup |
+| Node memory | 6,210Mi / 16Gi | 6,342Mi / 16Gi (39%) |
+| Node CPU | 470m | 2,002m transient startup peak |
+
+The 85Mi database-pod increase across 56 opened backends is approximately
+1.52Mi per connection at declared pool occupancy. That replaces ADR-0004's
+unmeasured 10Mi literature estimate for idle/backend occupancy on this live
+instance; it does not claim every query operator is limited to that figure.
+
+The earlier quiet preflight observed 362Mi. Conservatively adding the entire
+measured connection delta to that higher historical sample gives 447Mi, under
+44% of the 1Gi limit. The four bounded active queries did not exceed the
+174Mi maximum already observed during connection startup.
+
+## Decision
+
+Core Hub is accepted as the fourth declaration on `platform-pg` without a
+memory-limit increase. It reaches the declared ceiling and does not authorize
+a fifth declaration. The renderer must continue to reject any additional
+consumer on this cell; the named overflow remains `platform-pg-2`.
+
+This is capacity admission evidence, not a latency or workload-peak guarantee.
+Core Hub is latency-critical beside batch `audit-core`, and community
+PostgreSQL provides no service-class priority. The private shadow run must
+therefore capture application health, query latency, pod memory, and backend
+counts; material regression is a placement trigger, not a reason to reinterpret
+this probe as stronger evidence.

docs/evidence/core-hub-shadow-preflight-2026-08-20.md

@@ -0,0 +1,42 @@
+# Core Hub private-shadow preflight — 2026-08-20
+
+This records non-secret source/target metadata gathered for
+`RPF-WP-0021-T05`. It is preparation only: no source data was dumped or
+restored because the governed credential projections under T04 are not yet
+live.
+
+## Target admission
+
+At `2026-08-20T21:31:13Z` on railiance01:
+
+- namespace `core-hub` was Active and carried
+  `railiance.io/postgres-client=platform-pg` plus the package identity labels;
+- CNPG `Database/core-hub` reported `status.applied=true` against
+  `platform-pg`, with reclaim policy `retain` and owner `core_hub_owner`;
+- the `core_hub` database existed but intentionally contained no application
+  tables before the rehearsal restore; and
+- the KV store, database store and three ExternalSecret manifests all passed
+  Kubernetes server-side dry-run after namespace creation.
+
+## Source snapshot inventory
+
+A read-only query ran through the existing `coulombcore` SSH route against
+`apps-pg/core_hub`. No Secret or connection value was read. The live source
+writer remained enabled, so these counts are a rehearsal baseline and must be
+captured again with the eventual consistent dump.
+
+| Object | Rows |
+| --- | ---: |
+| `public.alembic_version` | 1 |
+| `public.api_consumers` | 3 |
+| `public.api_keys` | 10 |
+| `public.hub_capability_manifests` | 2 |
+| `public.hubs` | 2 |
+| `public.interaction_events` | 3 |
+| `public.migration_runs` | 2 |
+| `public.widgets` | 16 |
+
+The source Alembic revision was `20260627_0002`. No user-defined sequence was
+reported. The table set and counts are small enough for a bounded logical-copy
+rehearsal, but the restore remains gated on T04 so that migration and runtime
+checks use the intended distinct dynamic leases rather than a bootstrap login.