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

id	type	title	domain	repo	status	flavor	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	implementation	the-custodian	railiance	2026-09-11	2026-10-21	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: done
needs_human: false
intervention_note: "Binding complete: revision 3, immutable image, DNS/TLS, database custody and both PVCs verified. Recipient acceptance remains VERGABE-WP-0019-T04/T06; recovery remains T03."
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.

2026-09-27 closeout: T02 is done. Read-only verification confirms release revision 3, chart 0.2.1 and the recorded a26444f5… image, Ready 1/1, 60m/256Mi requests, both Bound claims, Ready TLS and HTTP 200 health. The September 24 founder sign-in resolves the former issuer-login wait. Exact binding is complete; the invited recipient journey and two-user acceptance remain VERGABE-WP-0019-T04/T06, and recovery remains T03. See docs/evidence/2026-09-27-vergabe-binding-review.md.

Demonstrate restart, isolated restore, rollback and operating ownership

id: RAPPS-WP-0014-T03
status: wait
needs_human: true
decision_id: d06307e5-2737-461a-a2f4-a12c3b492a9a
intervention_note: "Bernd Worsch and the company contact must complete two-user/document acceptance; railiance-platform owns offsite access and storage backup delivery. Then complete the coherent isolated restore and rollback receipt under this task."
priority: high
assignee: the-custodian
blocking_reason: "Await populated two-user/document workflow, coherent PostgreSQL/media/issue-state off-host recovery point, isolated restored workflow, rollback evidence and support ownership. September 25 proves database restore and restart only."
state_hub_task_id: "dd069c6d-fcc1-5bac-b233-976f2f0d5cd1"

2026-10-03: depends_on targets terminal (C-40); re-qualified by CUST-WP-0075: RAPPS-WP-0014-T02 is done, so the wait is solely the human gate — attended two-user/document acceptance by Bernd Worsch and the company contact, railiance-platform offsite/storage backup delivery, then the isolated restore and rollback receipt.

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.

2026-09-25 restore rehearsal. vergabe_demo_company was dumped, restored into scratch database vergabe_demo_restore_20260925 in 2 seconds, and matched on 39 tables and 212 rows (checksum 32ead8ffca3b2f917c7d163bb6948b243b2106690ad39612b68408f5601a6048). The scratch database was dropped. vergabe_db was not restored over. Media and issue-facade claims are mounted and empty; they are local-path and not an off-host backup. The app pod was recreated and /demo-company/health/ returned 200. The age file stayed on the workstation; the Nextcloud upload was not run. Two-user collaboration and a document round-trip remain. Evidence: docs/evidence/2026-09-25-vergabe-demo-company-restore.md.

2026-09-27 loose-end review: T03 now waits and this workplan is blocked. The September 25 database-only drill and empty file claims do not satisfy the three-store recovery contract. Complete the populated synthetic workflow with Bernd Worsch and the company contact, obtain a matched off-host recovery point through railiance-platform, restore into an isolated database and separate claims, verify both users and document checksums, and record schema-compatible rollback plus named incident/support ownership. Credential routing confirms railiance-backup-offsite-lane belongs to railiance-platform; a resolvable route alone is not an authenticated upload or a backup receipt. The safe auth check confirmed OpenBao unsealed but no valid caller token, so the workstation upload path needs Bernd Worsch's attended login. Existing tasks retain all remaining work; no task or workplan was opened.

2026-10-03: human gate routed to hub decision d06307e5-2737-461a-a2f4-a12c3b492a9a (D7: Vergabe pilot: two real users run the invited setup-to-workflow acceptance) by CUST-WP-0075; resolving that decision raises C-40 here.

Validate synthetic sizing against the exact release and shared contention

id: RAPPS-WP-0014-T04
status: done
priority: high
assignee: railiance-apps
state_hub_task_id: "c53fcaa9-859c-5b37-a17b-0a4cd2fb0e26"

Receiving task for CUST-WP-0071-T02 and RESOURCE-WP-0008-T02. The founder selected provisional configurable synthetic sizing on 2026-10-19; it does not replace the separate T03 human/recovery gate. Local application-owner evidence is in vergabe-teilnahme/docs/evidence/2026-10-19-synthetic-sizing/, with tunable workload and runtime profiles in that repository's config/synthetic-pilot*.json. The 1000m/1Gi local container comparison is a local observation, not a finding about the exact deployed release or a guarantee provided by a 60m reservation.

Routine read-only capture and source preparation are authorized work for this task; they do not require another founder decision. Capture fresh exact release metadata (image digest, chart/source revision, Gunicorn worker count, CPU/memory requests and limits, node CPU model/capacity, database binding and observation window). Record drift against the local test image and configuration rather than assuming source HEAD equals the deployed image.

Prepare the smallest isolated synthetic-data replay on the target hardware, using the same named operation/phase profile and a pinned release image. Reuse owner deployment/database custody and admission rules. Do not write workload fixtures or benchmark operations to an existing customer dataset. Any deployment mutation remains within its existing owner-reviewed execution scope; this task is not a blanket production change or credential grant.

Acceptance output must retain a co-timed idle baseline and workload window for application CPU/memory/throttling, per-operation p95/errors and separate document transfer, plus incremental PostgreSQL/shared-service demand and node contention. Record competing workloads/available CPU during the window and distinguish a CPU request from a quota. If shared-load representativeness or isolation cannot be established, preserve that concrete gap rather than promote a local pass to production acceptance. No new general benchmark suite is requested.

Return pinned configuration, hardware/release provenance, raw sampled evidence, coverage/gaps and a bounded recommendation to RESOURCE-WP-0008-T02 for headroom and allocation review and CUST-WP-0071-T02 for sizing acceptance. T03 remains unchanged: operator/customer recovery and human acceptance are not inferred from these synthetic results.

2026-10-21 result: isolated replay run on railiance01 under the founder's 2026-10-21 decision, in throwaway namespace vergabe-sizing-20261021 (deleted 06:36:18Z, PV removed; live deployment unchanged). Deployed digest sha256:a26444f5… (source c067993, chart 0.2.1, 3 Gunicorn workers, 60m/256Mi request, 1000m/1Gi limit) against a fresh PostgreSQL 16 pod, phased profile with in-cluster driver. 3675 ordinary requests p95 0.192s and 814 transfers p95 0.076s, zero errors, restart ready in 19s. App CPU 775m mean under load, 36% of CFS periods throttled (66% in burst), memory peak 483 MiB; isolated DB +~320m mean; node free CPU 1.2 cores mean, ~150m at p5 (largely self-induced). Recommendation: keep 1000m/1Gi limits and the 60m request for the two-user pilot; consider 512Mi memory request at allocation review. Gaps: synthetic settings (no SSO/ingress/TLS), standalone DB rather than shared apps-pg, synthetic closed loop, one run at a quiet hour. Evidence and revisit triggers: docs/evidence/2026-10-21-vergabe-target-replay/README.md. T03 is unchanged.