First deployment: verified on railiance01

RCP-WP-0002 T02-T04 done, readiness_state verified with evidence attached
rather than ahead of it.

rapp-postgres provisioned canned_prompts on platform-pg-2 and sent a
database-owner receipt with 12 checks proven live. creds/canned-prompts-publish
was deliberately not issued, so the service runs read-only and POST /packages
returns 503 explaining why — the intended posture, not a gap.

Four defects surfaced that only a real rollout could expose, two of them
silent:

- SET ROLE opened an implicit transaction that Alembic nested inside rather
  than owning, so every revision logged as applied and was rolled back.
  Alembic reported success against an empty database.
- The egress NetworkPolicy selected app.kubernetes.io/name, which the
  migration Job does not carry. The Job matched only the default-deny and
  succeeded exactly once, because it ran before the policies existed; the next
  migration would have failed on DNS. Now selects part-of, with ingress split
  into its own policy so the Job is never reachable.
- env.py read database_url rather than resolved_database_url, so the migration
  could never run where the credential is a mounted file.
- live-image-digest-match extracted the pin with a line-offset grep, which
  returned empty once comments were added above `version:`. The check degraded
  to reporting "not pinned yet" while a digest was pinned — it could not have
  passed for any pin. Now parsed as YAML. A verification step that cannot fail
  is worth less than none, because it is trusted.

Evidence: docs/evidence/RCP-WP-0002-T04-first-deployment-2026-09-08.md

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bjefh8NUiEiahN4JLwoSKM

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 388925@bnt-lap001
Assistant-Session: 3507023f-e0fd-4a1e-9d90-a0d4217d1502

workplans/RCP-WP-0002-first-deployment.md

@@ -4,7 +4,7 @@ type: workplan
 title: "First deployment of canned-prompts on Railiance"
 domain: agents
 repo: rapp-canned-prompts
-status: active
+status: finished
 owner: codex
 topic_slug: practice
 created: "2026-09-06"
@@ -62,7 +62,7 @@ output. `readiness_state` moved `draft` → `declared`.
 
 ```task
 id: RCP-WP-0002-T02
-status: wait
+status: done
 priority: high
 state_hub_task_id: "61f5cbd7-8fcf-5156-87da-57239ae55d8f"
 ```
@@ -91,13 +91,19 @@ OpenBao credentials — was deliberately **not** run: credential issuance is
 `rapp-postgres`' to perform, and running it from the consuming side would take a
 decision that is not this repo's, however available the script happens to be.
 
-Blocked here until those credentials exist. T03 and T04 are blocked behind it.
+**Received 2026-09-08.** `rapp-postgres` provisioned and sent a database-owner
+receipt with 12 checks proven live: runtime DDL denied (SQLSTATE 42501),
+statement timeouts and `search_path` as declared, and both logins refused
+CONNECT on `sbom_nexus` — the cell is shared, so that last one matters.
+
+`creds/canned-prompts-publish` was **not** created, as asked. The service runs
+read-only, which is the intended posture rather than a gap.
 
 ## Apply and migrate
 
 ```task
 id: RCP-WP-0002-T03
-status: wait
+status: done
 priority: high
 state_hub_task_id: "0b8d206e-bd28-5950-abf7-d824015c09a4"
 ```
@@ -120,11 +126,28 @@ The runtime deliberately does not migrate at start-up. Migrations as a Job keep
 a schema rollback separate from a code rollback and stop replicas racing each
 other.
 
+**Done 2026-09-08, after four defects that only a real rollout could expose.**
+Each is recorded in
+`docs/evidence/RCP-WP-0002-T04-first-deployment-2026-09-08.md`; the two worth
+repeating here failed *silently*:
+
+- `SET ROLE` opened an implicit transaction that Alembic then nested inside
+  rather than owning, so every revision logged as applied and was rolled back.
+  Alembic reported success against an empty database.
+- The egress NetworkPolicy selected `app.kubernetes.io/name`, which the
+  migration Job does not carry. The Job matched only the default-deny and
+  succeeded exactly once — because it ran before the policies existed. The next
+  migration would have failed with a DNS error. Now selects `part-of`, and
+  ingress is a separate policy so the Job is never reachable.
+
+`rapp-postgres` asked to be told when the first revision landed so they can
+re-run ownership reconciliation. Notified.
+
 ## Verify and record evidence
 
 ```task
 id: RCP-WP-0002-T04
-status: wait
+status: done
 priority: high
 state_hub_task_id: "6d9eb97c-57e2-5b74-b6eb-455076713417"
 ```
@@ -138,6 +161,19 @@ second opinion about whether the service is healthy.
 Record the output as evidence, then move `readiness_state` to `deployed`, and to
 `verified` only with that evidence attached.
 
+**Done 2026-09-08.** All six deployment checks and all six service-level checks
+pass; evidence at
+`docs/evidence/RCP-WP-0002-T04-first-deployment-2026-09-08.md`.
+`readiness_state` is `verified`, with the evidence attached rather than ahead of
+it.
+
+**The check that could never have passed.** `live-image-digest-match` read the
+pin with a line-offset `grep`, which returned empty once comments were added
+above `version:` — and the check then degraded to reporting "not pinned yet"
+instead of failing. It reported that while a digest *was* pinned. Now parsed as
+YAML. A verification step that cannot fail is worth less than none, because it
+is trusted.
+
 ## Decide per-publisher identity
 
 ```task