docs: update issue-core deployment closeout

docs/argocd-gitops.md

@@ -7,7 +7,7 @@ railiance-platform.
 ## Source layout
 
 - Workload bundle: `issue-core/k8s/railiance/`
-- Image: `gitea.coulomb.social/coulomb/issue-core:0.2.0`
+- Image: `gitea.coulomb.social/coulomb/issue-core:0.2.1`
 - Container port and Service port: `8765`
 - Cluster Service URL: `http://issue-core.issue-core.svc.cluster.local:8765`
 - Tenant Application: `railiance-platform/argocd/applications/issue-core.application.yaml`
@@ -18,31 +18,31 @@ therefore intentionally not duplicated in this bundle.
 
 ## Platform gates
 
-The following pieces are owned by railiance-platform before the workload can
-be fully reconciled:
+The following pieces are owned by railiance-platform for the live pilot and for
+any future cluster replay:
 
 - ArgoCD repository credentials and the project/app-of-apps convention.
 - The `issue-core` ArgoCD `Application`.
 - External Secrets Operator and a `ClusterSecretStore` named `openbao`.
 - OpenBao entries for the issue-core runtime Secret.
 
-Until those gates exist, `kubectl kustomize k8s/railiance` can render locally,
-but the live `ExternalSecret` and `Deployment` are expected to wait.
+For the 2026-06-25 live deployment, these gates were satisfied and the
+`issue-core` Application reached Synced/Healthy with image `0.2.1`.
 
 ## Secret contract
 
 Kubernetes Secret name: `issue-core-runtime`
 
-Current issue-core manifest path, pending railiance-platform confirmation:
+Current issue-core manifest path:
 
 ```text
 platform/workloads/issue-core/issue-core/issue-core-runtime
 ```
 
-Credential route catalog id `issue-core-ingestion-api-key` is owned by
-railiance-platform/OpenBao and is still marked draft/path TBD in the local
-ops-warden catalog reviewed 2026-06-18. Confirm the canonical path before
-provisioning the live Secret.
+Credential custody is owned by railiance-platform/OpenBao. For agents, first
+use the non-secret route catalog entry `activity-core-issue-sink` to confirm
+the activity-core + issue-core pairing, and never request the value from
+ops-warden.
 
 Required properties:
 
@@ -56,12 +56,12 @@ HTTP status codes, and created issue URLs.
 
 ## Build and publish
 
-Use the published package as the image input. For a reproducible release image,
-pin the package version to the image tag:
+Build the checked-out source tree and publish a registry tag that ArgoCD can
+pull:
 
 ```bash
-docker build --build-arg ISSUE_CORE_VERSION="==0.2.0" -t gitea.coulomb.social/coulomb/issue-core:0.2.0 .
-docker push gitea.coulomb.social/coulomb/issue-core:0.2.0
+docker build -t gitea.coulomb.social/coulomb/issue-core:0.2.1 .
+docker push gitea.coulomb.social/coulomb/issue-core:0.2.1
 ```
 
 The Coulomb Gitea package is public-pullable for this image, so the workload

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`.
 
 ---