# Delivery checks

Before implementing a workplan, use the hosted reuse registry:

```sh
make plan-check WORKPLAN=workplans/VERGABE-WP-0018-customer-factory-delivery.md
```

Install a reuse-surface revision containing REUSE-WP-0022. The initially tested
provider revision is recorded in
[evidence/2026-09-08-hosted-plan-check.json](evidence/2026-09-08-hosted-plan-check.json).
`REUSE_SURFACE_BIN` can select an explicit installed executable;
`REUSE_SURFACE_URL` defaults to `https://reuse.coulomb.social`.

This reads current hosted capabilities with `--no-llm`. It sends no tender intent
or mutation token to the registry. A failed/stale/partial source exits nonzero
without a recommendation. Preserve JSON output with the source revision in the
workplan evidence; a lexical `new` result still requires review of existing
capability owners. For this delivery we reuse reuse-surface, Railiance CI tooling
and the existing Railiance Apps deployment rather than establish new equivalents.

## Application and release gate

```sh
make test-image
```

The `application-tests` Docker target installs the locked Python dependencies,
builds Vite/Tailwind assets, collects static files, runs the complete Django
application suite against disposable SQLite data, and checks migration drift.
It includes the existing tender → lot → approval and submission workflow tests.
The target carries no production database connection or release credential.
SQLite proves this application acceptance suite; target PostgreSQL and live
storage/recovery behavior remain release admission checks.

The Forgejo application workflow checks proposed changes. The shared
`scripts/ci-docker.sh` installs Docker 27.3.1 and a checksum-pinned Buildx 0.19.3
plugin into temporary per-job state and enables BuildKit. The Railiance runner
otherwise falls back to the legacy builder, which rejects this Dockerfile’s
existing secret mounts. Temporary tool and registry-login state is cleaned at exit.
See [Docker’s BuildKit documentation](https://docs.docker.com/build/buildkit/).

The workflow runs once per PR update; it does not duplicate that run on the
feature-branch push. The image workflow
runs the same target on the same archive revision **before** registry login and
publication. Test dependencies and test settings are isolated from the runtime
image. The existing optional BuildKit package secrets remain supported, but the
current issue-core package is anonymously readable; no new secret is required.

The corrected Dockerfile consumes application templates under
`vergabe_teilnahme/templates/`. A fresh archive does not contain a root
`templates/` directory; attempting to copy it previously broke clean builds.

## Customer release acceptance

VERGABE-WP-0018-T03 owns the first admitted Railiance customer pilot: exact image
digest and chart revision, tenant/host and login binding, database and media
ownership, backup/restore and rollback, UI smoke and named operating owner.
Existing production tender data is never disposable test data. A passing source
build does not establish customer availability or the governed factory worker.


## Invited pilot — 2026-09-11

[VERGABE-WP-0019](../workplans/VERGABE-WP-0019-invited-company-pilot.md)
advances one manually onboarded company alongside factory admission. Billing
and a shared tenancy implementation are not pilot gates. All application routes
and media downloads require an active Django account; health and login remain
public. Members can change passwords; administrators create/reset/deactivate
accounts using the existing Django administration through the admitted operator
path. There is no public sign-up or email invitation delivery in this milestone.

Use the Railiance Apps pilot contract in `docs/vergabe-teilnahme-pilot.md` and
RAPPS-WP-0014. Record the newly tested image digest; the older published image
has no global access gate. Persist PostgreSQL, uploads and issue-facade SQLite
separately, and prove coherent restore before admitting customer data. Serve
`/media/` through Django, never directly through an unauthenticated ingress or
static file server. The image's `/app/.issue-facade` directory is operational
state and must never be placed below MEDIA_ROOT.

Application tests use the standard anonymous `client` for access tests and the
explicit `admitted_client` fixture for company workflows. Existing end-to-end
tests retain their explicit login. Container acceptance remains the release
gate; native two-user workflow, restored data, support and rollout evidence
remain open until performed on the admitted deployment.