vergabe-teilnahme/docs/delivery.md

Delivery checks

Before implementing a workplan, use the hosted reuse registry:

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

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.

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