vergabe-teilnahme/workplans/VERGABE-WP-0018-customer-factory-delivery.md

id	type	title	domain	repo	status	owner	topic_slug	created	updated	related
VERGABE-WP-0018	workplan	Establish verified delivery for the primary customer tender product	communication	vergabe-teilnahme	active	the-custodian	vergabe-teilnahme	2026-09-08	2026-09-08	HFACT-WP-0001 REUSE-WP-0022

Customer product delivery

Core Idea

Make the existing tender-participation UI a repeatably tested customer product. Use hosted capability discovery for planning, exercise the existing useful tender/lot/approval workflow, and prevent image publication when application acceptance fails. Preserve single-company scope until a separate tenancy design.

Establish product authority and reuse discovery

id: VERGABE-WP-0018-T01
status: done
priority: high
assignee: the-custodian

Update product entry points and classification to reflect the user's explicit customer-product selection. Add a reproducible make plan-check WORKPLAN=... consumer of REUSE-WP-0022, with no model call or mutation credential. Pin and record the tested provider revision and hosted snapshot receipt. A low lexical score requires owner review; it does not authorize a duplicate capability.

Gate releases with useful application acceptance

id: VERGABE-WP-0018-T02
status: progress
priority: high
assignee: the-custodian

Run existing application tests against disposable data, including tender create, lot create, approval and submission. Add a reproducible container acceptance target with locked dependencies, built assets and migration drift checks. Run it on proposed changes and before the existing image publication step. Record immutable reviewed source, CI outcome and resulting artifact separately.

Accept the first Railiance customer pilot release

id: VERGABE-WP-0018-T03
status: wait
priority: high
assignee: the-custodian
depends_on: [VERGABE-WP-0018-T02, HFACT-WP-0001-T05]
blocking_reason: "Await tested/reviewed image and exact Railiance tenant, deployment, database, storage, access and recovery owner acceptance."

Coordinator: the-custodian; product acceptance: Bernd Worsch; deployment owner: railiance-apps and admitted Railiance placement owner. Prepare exact chart/image, host, tenant, credential binding, existing-data disposition, backup/restore, rollback and UI acceptance evidence before release. Use an isolated internal pilot first; existing vergabe_db is not test data and must not be relocated or overwritten implicitly. No customer-ready claim until admitted release passes. Return the release and consumer evidence to HFACT-WP-0001-T06/T07.

Source acceptance — 2026-09-08

• Full application suite: 82 passed locally with SQLite and again with a disposable PostgreSQL 16 container; no production data used.
• Clean container application target: 82 passed, Vite/Tailwind built, 139 static files collected, no migration drift. One pre-existing naive-datetime warning.
• Runtime image built successfully; loopback health HTTP 200 as UID 999; pytest absent from runtime. See docs/evidence/2026-09-08-runtime-smoke.json.
• Clean-build defect fixed: root templates/ does not exist in published source; application templates already reside under vergabe_teilnahme/templates/.
• Hosted discovery consumed from reuse-surface implementation 2621cf2; 65-capability provenance and review disposition are in docs/evidence/2026-09-08-hosted-plan-check.json.

T02 remains in progress until the published exact revision has its CI return. T03 retains the concrete deployment/data/access/recovery gates. Attended Codex source work is not a natural governed worker claim/heartbeat/close trace.

Live CI runs 15/16 exposed the runner's missing Buildx/BuildKit support, despite local acceptance. Added pinned temporary CLI setup shared by application and image workflows, and removed duplicate feature-push test scheduling. The next exact PR revision must pass on the actual runner before T02 closes.