---
id: VERGABE-WP-0018
type: workplan
title: "Establish verified delivery for the primary customer tender product"
domain: communication
repo: vergabe-teilnahme
status: active
owner: the-custodian
topic_slug: vergabe-teilnahme
created: "2026-09-08"
updated: "2026-09-08"
related: [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

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

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

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