railiance-apps/docs/vergabe-teilnahme-pilot.md

Invited company pilot

User decision, 2026-09-11: one company, several users, manual onboarding; pricing later. VERGABE-WP-0019 owns product acceptance. RAPPS-WP-0014 owns placement, release and recovery. This is a review and execution contract, not a claim that the historical deployment is still live.

Exact release packet

Before native admission, record the following non-secret values in the company binding. The user selects a fresh demo-company workspace; see its prepared binding. Native tenant/user/password setup is verified; application hostname admission and product placement remain pending.

Binding	Required evidence
Company and data	Named company contact, expected users, empty workspace or explicit import source/owner
Placement	Cluster UID, dedicated namespace/release, admitted operator and resource capacity
Release	Login-protected source commit, live CI result, published OCI digest, chart commit/version
Public route	Assigned HTTPS hostname, TLS receipt, ALLOWED_HOSTS, CSRF_TRUSTED_ORIGINS, edge login abuse control
Custody	Dedicated database/role, runtime Secret reference and platform delivery receipt; no values in the packet
Durable data	Media PVC and distinct issue-facade state PVC, database backup owner, storage class/capacity
Recovery/support	Consistent off-host backup, isolated restore and rollback receipt, cadence/retention, incident contact

Use helm/vergabe-teilnahme-pilot-values.example.yaml as the starting point. It intentionally has no image digest and cannot render until one is supplied. The old published image main-fa9f082 does not contain the new access gate. Do not promote it merely because the older source suite passed.

helm lint charts/vergabe-teilnahme -f path/to/reviewed-company-values.yaml
helm template vergabe-teilnahme charts/vergabe-teilnahme \
  --namespace reviewed-company-namespace -f path/to/reviewed-company-values.yaml
python3 -m unittest discover -s tests -p 'test_vergabe_pilot_chart.py'

The default resource names are intentionally unchanged; company isolation is by separate namespace/database/claims. Do not install two company releases in the same namespace. Resolve the registry digest before setting image.digest. Run the existing owner-approved server dry-run and deployment lane against the reviewed placement after its packet is complete.

Persistence and recovery

Mount media at /app/media and issue state at /app/.issue-facade on distinct claims. Never expose the issue database through MEDIA_ROOT, ingress file serving or an object bucket used for public assets. Production document downloads route through Django authentication. All active users belong to this single company; there is no per-tender ACL or shared-application tenant discriminator in v1.

The chart uses Recreate with persistence to avoid overlapping old/new pods and RWO attachment conflicts. UID/GID/fsGroup 999 match the runtime image. Helm uninstall retains claims; namespace deletion or node loss can still destroy local-path data. Retention annotations are not a backup.

Before customer data is admitted, create a synthetic tender, lot, task, uploaded document and issue-facade record; capture identifiers/content checksums. Replace the application pod and verify all data and both user accounts remain usable. For a coherent backup, quiesce application writes through the operator's maintenance procedure, capture PostgreSQL plus media and a consistent SQLite backup (including any required journal state), and retain the matched recovery point off-host. Restore to an isolated database and new claims; existingClaim can select those restored claims. Repeat login, document checksum and workflow checks there. Record elapsed recovery time, backup age, image/schema revision and operator. Never rehearse by overwriting historical vergabe_db.

Inspect every release's migrations before rollback; reverting an image alone cannot undo an incompatible schema or restore lost data. Record the previously accepted digest and demonstrated data recovery path. Short planned interruption is acceptable for the invited pilot once the operator and company contact agree; HA is not claimed.

Manual onboarding and acceptance

Use the existing Django administration via the admitted operator path to create ordinary active members. Keep staff/superuser access with the designated operator. Supply initial credentials over the existing private human channel; never paste them into Git, State Hub, command arguments or chat. Members can change passwords in the UI; operators handle reset and deactivation manually. Do not run seed_dev on a pilot/customer database.

Before admitting the first users, verify HTTPS login, CSRF failure behavior, anonymous document refusal, two separate user sessions and deactivation of an already logged-in account. Complete the tender → lot → task/document → domain approval → submission workflow and feedback with the company contact. Customer support contact, incident routing and backup responsibility must be recorded. Pricing, automated invitation email, SSO and shared tenancy can be considered later; none is implied by this initial pilot contract.

Current inventory — 2026-09-11

Read-only checks on the connected Railiance cluster found no namespace vergabe-teilnahme and no Deployment whose name/image contains vergabe or teilnahme. The older docs/vergabe-teilnahme.md is historical deployment and recovery evidence, not proof of current placement. Database contents and other hosts have not been inventoried; no data-loss conclusion follows from namespace absence. RAPPS-WP-0014-T02 retains that exact inventory/admission step.

Published invited-pilot candidate — 2026-09-11

Source ccb6d1f8c7abd50f2ef654491bb1aa5861e795cb (implementation b7d7828) passed live application CI 29 and image publication 31. The registry resolves main-ccb6d1f to sha256:963240ef4180a01e5b8af7fbeb88be27e56203a45da8ecd633326b4c6d262005. The published image contains the invited login/private-download gate. Exact company/host/data binding, native deployment, coherent restore and two-user acceptance remain open. See docs/evidence/2026-09-11-invited-pilot-release.json for source, CI and artifact receipts; this candidate has not been deployed.

Accepted prototype allocation — 2026-09-11

The user explicitly accepts a 60m CPU request for this invited prototype with one tenant and very few users. Set resources.requests.cpu: 60m in the company binding, as shown in the pilot example. The chart's inherited 100m was an initial May 19 default, not a measured requirement. CPU limit remains 1000m, memory request 256Mi and memory limit 1Gi; one replica and Recreate remain in effect.

Fresh metadata shows databases/apps-pg healthy (1/1), 4000m allocatable CPU and 3905m requested. The 60m pilot application fits the current 95m reservation headroom with 35m remaining. This is a scheduling snapshot, not a throughput, latency or availability guarantee; database and host demand are separate. Refresh the actual rendered placement and transient migration demand before applying. The user accepts low allocation to exercise deployment and onboarding without first optimizing other infrastructure. Do not change unrelated services.

CUST-WP-0071 (the-custodian/workplans/CUST-WP-0071-measured-workload-sizing-and-weekly-review.md) is registered for later measurement, sizing changes and a final weekly assessment setup. It is not a prerequisite to this prototype. Exact tenant/host/ data binding, protected access and the pilot's existing recovery/onboarding checks continue in RAPPS-WP-0014 and VERGABE-WP-0019. See factory decision decisions/0012-accept-60m-invited-prototype.md.

Read-only CNPG metadata also reports vergabe-db applied for vergabe_db owned by vergabe, two managed consumers with 20-connection limits, and the most recent apps-pg backup successful at 2026-09-11T02:15:11Z. This establishes the declared database/backup metadata; no customer data was read, selected for reuse or modified. The user subsequently selected a new demo-company workspace; the prepared binding explicitly uses a fresh database and leaves historical data untouched.

2026-09-11 update: the selected customer URL is https://vergabe-teilnahme.coulomb.social/demo-company/. Native demo-company creation and first-administrator registration are verified. Identity login provisioning currently fails its LLDAP service authentication, tracked by NK-WP-0036-T04. Tenant-path application source 9345a1b passes 98 tests and seven local browser checks; image publication 44 passed with digest sha256:cebe8ca6218cc89f903e8a69e06ac50d3812526d4119cf4da485cc173f674b68. Live edge/data admission remains open. See the updated demo-company binding for execution status.

2026-09-12 update: directory credential reconciliation succeeded, the operator confirmed portal login/logout and user password setup, and live records show three demo-company memberships with one linked identity. Native provisioning is no longer the current blocker. The product still needs DNS/TLS, fresh data custody, placement and recovery. VERGABE-WP-0019-T06 now explicitly tracks the requested tenant welcome and connection to the new NetKingdom identity. The earlier manually provisioned Django account path remains an interim capability; it does not make the directory password a product credential or implement SSO.

Live demo placement — 2026-09-12

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.