# 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.

```sh
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.