docs: update issue-core deployment closeout

workplans/ISSUE-WP-0003-railiance01-deployment.md

@@ -4,11 +4,11 @@ type: workplan
 title: "Deploy issue-core as a service on railiance01 (ArgoCD GitOps pilot)"
 domain: infotech
 repo: issue-core
-status: active
+status: blocked
 owner: claude
 topic_slug: custodian
 created: "2026-06-19"
-updated: "2026-06-25"
+updated: "2026-06-30"
 state_hub_workstream_id: "896ace77-21b3-450b-8fb7-254aefc8c570"
 ---
 
@@ -73,6 +73,23 @@ declarative Application and turning on the idle GitOps capability.
   `/healthz` returns 200; authenticated `POST /issues/` returned 201 and Gitea
   issue id `175`.
 
+## Closeout recheck (2026-06-30)
+
+- issue-core-owned deployment work remains complete: manifests, runtime secret
+  contract, backend config, runbook, and direct authenticated ingestion smoke are
+  done for image `0.2.1`.
+- The remaining completion gate is the activity-core producer handoff. A
+  non-secret source recheck of `/home/worsch/activity-core/k8s/railiance/20-runtime.yaml`
+  still shows `ISSUE_CORE_URL` on port `8010` and `ISSUE_SINK_TYPE: "null"`.
+- `ops-warden` routing catalog entry `activity-core-issue-sink` confirms the
+  lane is owned by activity-core + issue-core and that ops-warden does not vend
+  `ISSUE_CORE_API_KEY`.
+- This WSL session does not have `kubectl` on PATH, so live ArgoCD/Kubernetes
+  state could not be re-polled from the workstation. Keep T06/T07 at `wait`
+  until the activity-core runtime is switched to the service on port `8765`,
+  receives the shared key through OpenBao, and an activity-core emission returns
+  issue-core HTTP 201 with a created Gitea issue.
+
 ## Decisions
 
 - **Deployment method = ArgoCD GitOps** (operator decision 2026-06-19).
@@ -218,7 +235,7 @@ the cluster Gitea (markitect) backend.
 
 ```task
 id: ISSUE-WP-0003-T06
-status: progress
+status: wait
 priority: high
 state_hub_task_id: "96b14cdb-364f-4eab-a80e-dd8b3859c694"
 ```
@@ -234,6 +251,10 @@ state_hub_task_id: "96b14cdb-364f-4eab-a80e-dd8b3859c694"
   accepts `triggering_event_id` as a non-empty traceability string, so
   event-driven paths can send UUIDs and cron paths can send stable keys such as
   `"scheduled"`.
+- [ ] activity-core runtime source still needs the live flip:
+  `ISSUE_CORE_URL` `8010 -> 8765` and `ISSUE_SINK_TYPE` `"null" -> "rest"`.
+- [ ] activity-core worker still needs the shared `ISSUE_CORE_API_KEY` from the
+  approved OpenBao lane; never write the value to Git, State Hub, logs, or chat.
 - Verify: an activity-core run emits a task that lands in cluster Gitea via
   issue-core.
 
@@ -241,7 +262,7 @@ state_hub_task_id: "96b14cdb-364f-4eab-a80e-dd8b3859c694"
 
 ```task
 id: ISSUE-WP-0003-T07
-status: progress
+status: wait
 priority: medium
 state_hub_task_id: "8d853b8e-cfca-441d-b817-0a29e37bd66e"
 ```
@@ -254,7 +275,8 @@ state_hub_task_id: "8d853b8e-cfca-441d-b817-0a29e37bd66e"
   (remaining T06 handoff).
 - [x] Document the GitOps runbook (image build/push, ArgoCD sync, secret
   contract, smoke, activity-core handoff) in `docs/argocd-gitops.md`.
-- Emit an `add_progress_event` milestone to the hub on completion.
+- Emit an `add_progress_event` milestone to the hub when the activity-core
+  emission proof exists and this workplan can move from `blocked` to `finished`.
 
 ---