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. Company/host/data selection is pending; do not treat example values as an assigned tenant.

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.

The shared databases/apps-pg cluster is currently healthy (1/1). The node has 4000m allocatable CPU and 3905m in requests, leaving 95m against this pilot's 100m request. This is a reservation constraint, not a utilization measurement. RAPPS-WP-0014-T02 retains capacity admission before deployment; use existing owner observations or add capacity, and retain operating room for factory services. Do not silently reduce the pilot request to make the chart fit.