the-custodian/docs/decisions/2026-10-21-cust-wp-0071-delivery-interview.md

CUST-WP-0071 delivery interview — 2026-10-21

Decided by Bernd Worsch in this interactive Claude Code session. Scope: how CUST-WP-0071 is driven to completion. These answers do not claim acceptance of any task and do not change the human recovery/workflow gate RAPPS-WP-0014-T03.

Target-hardware replay (RAPPS-WP-0014-T04)

Selected: "Isolated replay on node (recommended)". A throwaway namespace on railiance01 runs the pinned release image against its own synthetic PostgreSQL, using the existing phased profile from vergabe-teilnahme (config/synthetic-pilot-phases.json) for about ten minutes, then is torn down. No customer data is read or written. Read-only capture of the deployed release metadata (image digest, chart revision, workers, requests/limits, node CPU model) is part of the same task.

Credential use in this session

Selected: "Read + benchmark ns". The workstation's system:admin kubeconfig may be used for cluster reads and for creating/deleting only the throwaway benchmark namespace and its contents. It must not modify existing workloads, quotas, policies or nodes. Allocation changes (CUST-WP-0071-T04) need a separate founder approval. This is a bounded exception for this task; the CUST-WP-0073 isolation target for interactive agents is unchanged.

Worker agents

Selected: "Subagents now (recommended)". The Custodian session spawns subagents working in the owner repositories (railiance-apps with vergabe-teilnahme, resource-control, and the executor owner) with precise briefs. They commit in their own repositories; the Custodian integrates the results and syncs.

Weekly assessment executor (CUST-WP-0071-T05)

Selected: "In-cluster CronJob". A Kubernetes CronJob on railiance01, Monday 08:00 Europe/Berlin, with a scoped read-only ServiceAccount and persisted weekly aggregates. For T05 this supersedes the 2026-10-19 "existing Activity Core worker" placement. Source is prepared now; deployment follows review and the completion of T04.

T05 follow-up answers (same session)

• Telemetry: prepare Prometheus retention of at least 8 days in rapp-telemetry (source only, disk checked first). No pod-label allowlist for now; reports stay at namespace level.
• Delivery: "Hub message + repo tasks". The job posts a State Hub message per weekly report. The next Custodian session reviews it and writes recommendations as tasks in the owner repos (ADR-001). A failed or missing weekly receipt is flagged by a daily check, in the same style as the security flow.
• Placement: keep the new custodian-assessment namespace, owned by railiance-platform. Widen the platform-addons ArgoCD project to allow NetworkPolicy and add default-deny egress, allowing only DNS, kube-apiserver, Prometheus and the State Hub API.
• Packaging: keep the sha-locked vendored scripts; re-vendor and review when the source scripts change.

T03/T04 rollout (after resource-control review e72c5de)

• Rollout: "Waves". Wave 1 covers the high-impact owners, each with a receiving workplan prepared now: rail-knative (HPA caps and requests), railiance-forge (gitea and runner), state-hub (API, DB and the preflight surge constant) and rapp-telemetry (Prometheus and Grafana). The remaining small adjustments get one receiving task per owner repo and are applied later in a batched wave 2.
• Apply: "I may apply wave 1". The Claude session may push the reviewed wave-1 owner changes to Forgejo and sync them through ArgoCD (or the owner's existing deploy path) itself, one owner at a time, keeping before/after evidence and a rollback receipt for each. This extends the earlier credential bound for wave 1 only. Wave 2 and anything outside the reviewed wave-1 diffs need a new approval.
• ihp-railiance-probe: "Find owner first". Trace the owner from the repos; make no change until the owner is confirmed.

Wave-1 apply path and probe (same session)

• Apply path: "Local kubectl allowed". The ssh-based installers can't read the k3s kubeconfig on railiance01, so this session applies the reviewed wave-1 changes with kubectl/helm from the workstation, using its kubeconfig, one owner at a time.
• ihp-railiance-probe: "Approve uninstall" (CORE-WP-0012-T02). Run helm uninstall ihp-railiance-probe -n coulomb; delete namespace coulomb only if it is empty.
• flex-auth: its receiving task goes to access-engine, next to charts/flex-auth.

Wave 2 (later the same evening)

• Authority: "Like wave 1". Workers prepare each owner change and diff the full render against live. This session applies batch by batch through the owner deploy paths, but only when the diff shows nothing beyond resource fields (plus the approved policy items). Any drift, or a render that needs secret values, stops and comes to the founder.
• Database restarts: tonight, one single-instance CNPG cluster at a time, with a health check in between.
• Policy: raise the CPU limits of the throttled sso and playwright workloads, and remove the retired inter-hub release. rein-aharness is NOT scaled to zero; it only gets the lower request.

Wave 2 apply scope (after worker preparation)

• Drift approved to go in together with resources:
  • the Vergabe railiance.io/release-unit label;
  • the email-connect annotation and volume reordering;
  • the rein-aharness labels (Deployment only, no smoke Job);
  • the cert-manager --acme-http01-solver-nameservers=1.1.1.1:53 flag, now written into the values.
• activity-core: infrastructure (including its already-declared 1Gi DB memory limits), relay and llm-connect now. Its ArgoCD part (api, worker, event-router) waits, because the promotion check admits image changes only.
• flex-auth: only flex-auth-ops-warden now. The other 8 releases wait for owner review of the --caller-audience auth change and the image change.
• target-revenue: allowed tonight; its sync re-runs the migrate and bootstrap hooks.