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](vergabe-demo-company-binding.md). 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.

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


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