issue-core/workplans/ISSUE-WP-0007-rapp-issue-core-railiance01-migration.md

id	type	title	domain	repo	status	owner	topic_slug	priority	created	updated	depends_on	related
ISSUE-WP-0007	workplan	rapp-issue-core: move the runtime off CoulombCore onto railiance01	infotech	issue-core	proposed	unassigned	issue-core	high	2026-08-19	2026-08-19		ISSUE-WP-0003 RMGR-WP-0006 RMGR-WP-0007

ISSUE-WP-0007 — rapp-issue-core: move the runtime onto railiance01

CoulombCore is being decommissioned. issue-core is one of three services still running there, and it is the load-bearing one: the ops-bridge tunnel issue-core-railiance01 is a reverse forward that re-exports this workstation's 18765 to railiance01, so railiance01 reaches issue-core through a laptop that is forwarding to CoulombCore. When CoulombCore goes, issue-core goes with it, and deleting the tunnel is not a migration.

Start here: ISSUE-WP-0003 says this is already done. It is not.

ISSUE-WP-0003 is status: finished and states that "the railiance01 cluster now reconciles issue-core through ArgoCD; External Secrets Operator reads the OpenBao-backed runtime Secret and the Deployment is live on port 8765."

Checked on 2026-08-19 against the railiance01 cluster (~/.kube/config-railiance01, bridge tunnel k3s-api-railiance01, local 16444):

Claim	Observed
Deployment live in issue-core namespace	Namespace exists, empty — No resources found
Reconciled by ArgoCD	No ArgoCD — the cluster has no applications resource type
issue-core serving	Serving from CoulombCore: -L 18765:10.43.103.154:8765, /healthz → {"status":"ok","version":"0.2.1"}

Whatever was stood up under WP-0003 is gone — most plausibly the railiance01 cluster was rebuilt without it, since ArgoCD itself is absent. Task T00 is to establish what actually happened before rebuilding, because if the deployment was lost silently once it will be lost silently again, and a GitOps controller that no longer exists is a different starting point than one that drifted.

Do not treat WP-0003 as prior art to resume. Treat it as a record that needs correcting once this workplan establishes the truth.

Why a rapp- wrapper rather than k8s/railiance/ in this repo

issue-core currently carries its own Dockerfile and k8s/railiance/ Kustomize tree. The estate has since settled on a different split, visible in rapp-postgres, rapp-qonto, rapp-user-engine, rapp-tenant-engine, rapp-openbao, rapp-secrets-engine, rapp-policy-nexus: domain logic stays in the app repo; runtime packaging, bindings, secret references, network policy, placement, and rollout evidence live in a rapp-<app> repo.

rapp-qonto/README.md states the boundary plainly: "Domain logic and financial policy stay in qonto-assistant. This repo owns runtime packaging, the Knative binding, secret references, network policy, and workload-specific rollout evidence."

That split is also what makes the loss above visible next time: rollout evidence is a deliverable of the wrapper, not a side effect of a cluster being up.

repo-manager scaffolds these — do not hand-build one:

rmgr rapp wrap --path ../rapp-issue-core --app issue-core \
  --ownership-repo issue-core --from-app ../issue-core \
  --rail rail-kubernetes \
  --package-type manifest-managed-platform-service
rmgr rapp validate --path ../rapp-issue-core --family-root ..
rmgr rapp place --path ../rapp-issue-core --reef reef-railiance

--rail, --classification, --criticality, and --package-type are decisions, not defaults to accept blindly — settle them in T01. See repo-manager/docs/RailianceAppDeploymentGuide.md (RMGR-WP-0006) and RMGR-WP-0007 (greenfield rapp wrap efficiency).

Consumers to carry across

Migration is not done when a pod is Running. These reach issue-core today:

• activity-core — IssueSink emission. ops-warden routes this need as catalog id activity-core-issue-sink.
• ops-bridge — tunnels issue-core-coulombcore (-L 18765 → 10.43.103.154:8765) and issue-core-railiance01 (reverse re-export). Both are retired by this work; the second one should not be recreated in any form.
• Anything reading http://127.0.0.1:18765 on the workstation.

Tasks

id: ISSUE-WP-0007-T00
status: todo
priority: high

Establish what happened to the WP-0003 deployment. Before rebuilding: was ArgoCD removed deliberately, was the cluster rebuilt, or did the Application drift and get pruned? Check railiance01 cluster history, the issue-core namespace's remaining objects, and the OpenBao-backed ExternalSecret referenced by WP-0003. Record the finding, and correct ISSUE-WP-0003 — a workplan asserting a production deployment that does not exist will mislead the next reader exactly as it misled this one.

Deliverable: a short history/ note. If the cause turns out to be a platform-side defect rather than an issue-core one, route it to risk-nexus as a finding rather than absorbing it here.

id: ISSUE-WP-0007-T01
status: todo
priority: high

Settle the packaging decisions. --rail (rail-kubernetes vs rail-knative), --package-type, --classification, --criticality, and whether issue-core needs --dedicated-postgres or consumes rapp-postgres as a consumer (it has a database; check which pattern the other rapps that need one actually use). Decide against the existing k8s/railiance/ manifests so the wrapper starts from something real.

id: ISSUE-WP-0007-T02
status: todo
priority: high

Scaffold rapp-issue-core via rmgr rapp wrap, then rmgr rapp validate --family-root ... Do not hand-author the layout; the validator encodes the family conventions and will reject a bespoke tree. Register the new repo the normal way (write the files, commit, run the consistency check) rather than by hand.

id: ISSUE-WP-0007-T03
status: todo
priority: high

Port the runtime. Move Dockerfile / image build and the k8s/railiance/ tree into the wrapper's shape: manifests, secret references (OpenBao-backed ExternalSecret — custody stays with the platform, never in this repo), NetworkPolicy, Service. Image 0.2.1 is what is serving today; decide whether to rebuild or promote the existing digest.

issue-core keeps its domain code and loses its deployment artifacts. That deletion is part of the task, not a follow-up — two sources of deployment truth is the failure this split exists to prevent.

id: ISSUE-WP-0007-T04
status: todo
priority: high

Deploy to railiance01 and prove it. rmgr rapp place --reef reef-railiance, then live evidence in the wrapper: cold start, /healthz 200 from inside the cluster (not through a laptop forward), dependency-failure behaviour, and rollback. Follow rapp-qonto/tools/verify_live.sh as the shape — reversible, secret-free.

Evidence that the service answers only via an ops-bridge tunnel does not count. That is the condition being retired.

id: ISSUE-WP-0007-T05
status: todo
priority: high

Cut consumers over, then retire the tunnels. Point activity-core's IssueSink at the in-cluster address; ask ops-warden to update catalog id activity-core-issue-sink if the routing pointer changes. Only once consumers are on the new address, ask ops-bridge to remove issue-core-coulombcore and issue-core-railiance01 from ~/.config/bridge/tunnels.yaml.

Order matters: removing the tunnels first takes issue-core down for everyone still pointed at 127.0.0.1:18765.

id: ISSUE-WP-0007-T06
status: todo
priority: medium

Close out. Update SCOPE.md and WORK-RECORDS.md; correct ISSUE-WP-0003 per T00; tell ops-warden and ops-bridge that CoulombCore has one fewer dependency. Remaining CoulombCore services after this: core-hub-staging and inter-hub.

Notes for whoever picks this up

• ops-bridge tunnel map header (~/.config/bridge/tunnels.yaml) lists what is left on CoulombCore and why.
• railiance01 cluster access: kubectl --kubeconfig ~/.kube/config-railiance01 (tunnel k3s-api-railiance01, local 16444). There is no CoulombCore kubeconfig any more — its k3s-api tunnel was removed on 2026-08-19, so inspecting the current deployment needs that tunnel restored first.
• This workplan was drafted from outside issue-core (during ops-warden's CoulombCore retirement sweep). The tasks are stated as findings and decisions rather than a fixed design, because the owning repo should make the calls.