railiance-apps/workplans/RAPPS-WP-0014-vergabe-invited-pilot.md

id	type	title	domain	repo	status	owner	topic_slug	created	updated	related	state_hub_workstream_id
RAPPS-WP-0014	workplan	Deploy and recover the first invited Vergabe company pilot	financials	railiance-apps	active	the-custodian	railiance	2026-09-11	2026-09-12	VERGABE-WP-0019 VERGABE-WP-0018 HFACT-WP-0001 CUST-WP-0071	c7fdaa7e-cab8-5d1d-86c2-f1aad7927c57

Invited Vergabe pilot on Railiance

Prepare a durable and immutable single-company chart

id: RAPPS-WP-0014-T01
status: done
priority: high
assignee: the-custodian
state_hub_task_id: "378e1f1a-701f-531e-aa92-95a09e7a32d3"

Extend the existing media PVC support with a distinct issue-facade state PVC, optional existing claims for restore, retained claims on Helm uninstall and Recreate rollout when persistent local state is mounted. Pilot mode requires one replica, both durable stores, distinct claims and a valid OCI image digest. The legacy opt-in behavior remains available for non-pilot installations. Seven render regression tests and Helm lint pass. Chart 0.2.0 and the review-only values template prepare the deployment; no live resources were changed.

Bind the exact company, release, placement, data and access

id: RAPPS-WP-0014-T02
status: progress
needs_human: false
intervention_note: "DNS, TLS and application placement are verified. Product SSO/welcome and pilot/recovery acceptance remain in the existing owner tasks."
priority: high
assignee: the-custodian
state_hub_task_id: "b00958c8-1401-5ebf-bc22-c0252618d897"

Consume VERGABE-WP-0019-T02's login-protected release after live CI/publication. Record exact image/chart revision, company, user count, host/TLS, dedicated namespace, database/role, both PVCs and admitted runtime Secret custody. The user now selects a fresh demo-company workspace (2026-09-11). Existing vergabe_db is not test data. Resolve target inventory before using historical runbook names: the checked Railiance cluster has no vergabe-teilnahme namespace or matching Deployment on 2026-09-11. Do not infer data loss or authorization to recreate it.

The user explicitly accepts a 60m CPU request for one tenant with very few users on 2026-09-11. This prototype prioritizes the deployment/onboarding path; 60m is not a measured minimum or a production sizing claim. The pilot values now override the inherited 100m request; CPU limit and memory remain unchanged. Fresh metadata still shows databases/apps-pg healthy (1/1), 3905m requested against 4000m allocatable and 95m available. A 60m application pod fits that CPU snapshot with 35m remaining; refresh exact placement and any transient migration/rollout demand before applying. This supersedes the earlier demand- measurement prerequisite for this specific prototype, not unrelated allocations.

CUST-WP-0071 is persisted/registered for later measured sizing and a final weekly assessment setup. STATE-WP-0091 retains release preflight and shared-headroom work. Neither is a new prerequisite for this accepted pilot. Fresh CNPG metadata reports vergabe-db applied for vergabe_db/vergabe, two managed consumer roles with 20-connection limits, and a successful apps-pg backup at 2026-09-11T02:15:11Z. Database contents have not been inspected or modified; metadata does not select reuse or grant access to that data. See the dated inventory and pilot allocation receipt.

Use docs/vergabe-teilnahme-pilot.md for the review packet. Secret creation, operator access and placement consume existing platform lanes; they do not create a parallel identity framework. The public edge needs an admitted login abuse-control policy and TLS; Django's authentication gate alone is not a rate limiter. Keep /media/ behind the app gate.

The user requests a new demo-company tenant with demo-user1, etc. Apply NetKingdom ADR-0013 as tenant:trial:demo-company and start with two ordinary demo users. Fresh data is selected; no historical customer import is authorized. The prepared namespace/database/release and current execution status are in docs/vergabe-demo-company-binding.md and helm/vergabe-demo-company-values.proposed.yaml. The user chose https://vergabe-teilnahme.coulomb.social/demo-company. DNS/TLS is per product host; the exact company prefix selects its isolated application instance. The chosen hostname currently resolves to 80.158.43.29 and needs the admitted Railiance01 route (92.205.62.239) through the edge owner.

Native operator authentication as platform-root succeeded. At 19:03:18 UTC the operator created demo-company through the native User Engine form; Tenant Engine readback confirms active, version 1. The chosen first administrator is present with invited status. A subsequent user was created, but Create login fails in identity-provisioner at the LLDAP admin authentication step, before directory mutation. Reloading the existing credential reference preserves this 401. The operator subsequently completed NK-WP-0036-T04's attended repair. Both the helper receipt and independent consumer verification confirm directory authentication and read access. Secret resourceVersion is now 60026132; the provider password and provisioner image are unchanged. Native Create login and password setup for the existing user remain pending. T05 retains the functional dependency preflight/error-reporting improvement.

Vergabe source 9345a1b supports APP_BASE_PATH=/demo-company, prefix-aware URL reversing and cookie scope. All 98 application tests, Vite build and seven local Chromium path/edge checks pass. CI smoke 43 and publication 44 passed; the proposed values now pin sha256:cebe8ca6218cc89f903e8a69e06ac50d3812526d4119cf4da485cc173f674b68 and APP_BASE_PATH=/demo-company. The previous root-path image is superseded. Ordinary demo memberships and Django accounts remain separate from platform tenant existence. No product SSO is claimed. The selected URL and successful tenant creation are resolved inputs.

2026-09-12 native milestone:the operator confirms portal login/logout and user password setup (Password set). Read-only User Engine evidence shows three demo-company memberships and one linked directory identity; private names, addresses, passwords and setup links are excluded. USER-WP-0025 deployed visible operator navigation, protected portal logout and tenant-name selection. Product identity linkage and a tenant welcome handoff are explicitly VERGABE-WP-0019-T06. This supersedes the preceding pending-Create-login state; the app itself is not yet deployed and native identity success does not establish a Django session.

2026-09-12 deployment evidence: the operator added A records for vergabe-teilnahme.coulomb.social and users.coulomb.social. Authoritative IONOS and recursive readback both return 92.205.62.239. Both cert-manager certificates are Ready. The portal now uses https://users.coulomb.social/login; its legacy nip.io address redirects to the canonical hostname. The exact new callback is registered alongside the rollback callback; scopes, public client type and PKCE remain unchanged. Canonical authorization succeeds; unapproved callback and missing PKCE fail. This supersedes earlier DNS and portal-hostname blockers.

Helm release vergabe-teilnahme revision 1 is deployed in vergabe-demo-company, chart 0.2.1, pinned product digest cebe8ca6218cc89f903e8a69e06ac50d3812526d4119cf4da485cc173f674b68. Deployment UID 2152014d-a020-4c5e-a3b0-9575e9f21c44 is Ready 1/1. Its init migration completed before the web process; both phases share the same 60m CPU / 256Mi memory request. Node requests now total 3965m of 4000m; the 35m remainder matches the accepted prototype allocation. No unrelated resource requests changed.

RPF-WP-0039 delivered fresh vergabe_demo_company database/role on apps-pg and runtime Secret vergabe-demo-company/vergabe-demo-env. The app's own connection confirms that exact database/role. The role is non-superuser, cannot create roles or databases, has a 20-connection ceiling and 15-second timeouts, and cannot CONNECT to historical vergabe_db, coulomb_social_db or apps_meta. Both dedicated PVCs are Bound: 5Gi media and 1Gi issue state. Historical data was not selected or overwritten; no credentials are recorded here.

Thirteen live Chromium/HTTP checks pass: page and assets, secure tenant-scoped CSRF cookie, anonymous login gate and media refusal, private operational path refusal, neighboring/root path refusal, canonical slash, HTTPS redirect and missing-CSRF POST denial. Migration/app initialization also proves consumer connectivity. The empty product has zero accounts, including zero staff accounts. The current login is still the interim Django login, not NetKingdom SSO. Native recipient login, company welcome and account mapping remain VERGABE-WP-0019-T06. RAPPS-WP-0014-T03 retains restart and coherent off-host backup/isolated restore; the latest existing apps-pg base backup predates this new database. No pilot-user acceptance, shared tenancy, MFA completion or natural factory-worker trace is claimed.

2026-09-12 SSO release preparation: docs/vergabe-demo-company-sso-rollout.md contains the exact published app/issuer/provisioner digests, server dry runs, attended sequence and rollback. The new helm/vergabe-demo-company-sso.proposed.yaml layers over the admitted values and retains the 60m/256Mi allocation. The narrow issuer-egress policy is also proposed, not applied. The shared KeyCape upgrade requires the attended window described in its operations document. Native recipient/MFA and product acceptance stay with VERGABE-WP-0019-T06; recovery remains T03 here. No live runtime changes were made in this continuation.

2026-09-12 attended rollout executed after explicit operator approval. KeyCape and password setup are Ready on the prepared digests; exact public client registration was CAS-applied (config resourceVersion 60123977) with unrelated config bytes/Secret data preserved. Existing portal and product client both pass fresh-login forwarding, wrong-callback and missing-PKCE checks (6 checks). Vergabe Helm revision 2 is Ready; identity migration completed, both PVCs remain, and requests remain 60m CPU/256Mi memory. Eleven live product checks pass: company welcome, anonymous gate, no-store, secure scoped CSRF, POST/CSRF-only login start, native issuer redirect, private company/media protection and invalid callback/confirmation rejection. Initial readback showed zero accounts, identity mappings and staff accounts. Native invited-user sign-in/MFA and confirmation are now requested from the operator; no user credential was used by the agent. Recovery and two-user acceptance remain their existing tasks. Evidence: railiance-apps/docs/evidence/2026-09-12-demo-company-sso-live.md.

Demonstrate restart, isolated restore, rollback and operating ownership

id: RAPPS-WP-0014-T03
status: wait
priority: high
assignee: the-custodian
depends_on: [RAPPS-WP-0014-T02]
blocking_reason: "Placement and data binding are live; verify product account onboarding and run the coherent restart/restore rehearsal before pilot admission."
state_hub_task_id: "dd069c6d-fcc1-5bac-b233-976f2f0d5cd1"

With synthetic fixture data on the admitted deployment, prove login and health, two-user collaboration, document upload/download and issue state across pod replacement. Establish a consistent recovery point for PostgreSQL, media and issue-facade SQLite; rehearse recovery into a separate database and separate claims, repeat the workflow, and record recovery time and checksums without customer content. Record backup owner/cadence/retention/off-host destination, restore command revision and monitoring/incident owner. Retained local-path PVCs are neither off-host backup nor node-failure protection.

Review upgrade/migration effects and exact rollback image/data handling. A single-writer Recreate release has a short service interruption; do not promise HA. Return evidence to VERGABE-WP-0019-T03/T04 before customer invitations. Native factory-produced delivery remains VERGABE-WP-0018/HFACT-WP-0001's separate claim. Pricing and shared-app tenancy are outside this invited-pilot milestone.