Fluory · Fluory · Sep 28, 2026 · Sep 28, 2026 · Sep 28, 2026
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -25,7 +25,7 @@ This file records what changes **in the product** – process and session state
   on the showcase usually the cold start of the scaled-to-zero container; after 30 s without an answer it
   reads `failed` again, so a real outage is not hidden (#81).
 
-## [0.1.0] – 2026-09-27
+## [0.1.0] – 2026-09-28
 
 First release: the pilot scope – intake of e-mail and PDF/Excel/Word, AI extraction with sources and
 uncertainty, review with corrections, exactly-once ERP export, multi-tenancy, audit trail and the public

diff --git a/PROJECT-START.md b/PROJECT-START.md
@@ -14,7 +14,8 @@
 4. Halte Antworten kurz, strukturiert und entscheidungsorientiert.
 5. Wenn eine Entscheidung sicherheits-, kosten-, daten- oder architekturrelevant ist: Optionen mit Folgen nennen und `decision-needed` markieren.
 
-**Aktueller Status:** `setup-in-progress` (Freigabe 2026-09-22)
+**Aktueller Status:** `foundation-ready` (Freigabe 2026-09-22) – Stand 2026-09-28: Der Pilotumfang (Epics #2, #17, #18) ist
+gemergt und als Release v0.1.0 (#86) veröffentlicht; die Abnahme (Meilenstein M2) steht aus.
 Mögliche Werte: `discovery` | `approved-for-setup` | `setup-in-progress` | `foundation-ready` | `paused`
 
 **Orchestrator:** Fluory

diff --git a/README.md b/README.md
@@ -4,7 +4,9 @@ AI-assisted intake of quote requests for industrial sales teams: extract structu
 e-mails and PDF/Excel/Word attachments, review every value **beside its source**, and export each
 approved request **exactly once** to an ERP.
 
-> **Status:** app skeleton – the stack runs and is checked in CI; product features follow issue by issue.
+> **Status:** pilot scope built and released as [v0.1.0](https://github.com/Fluory/RequestFlow/releases/tag/v0.1.0)
+> (2026-09-28); acceptance pending ([roadmap](docs/product/roadmap.md), M2). A synthetic showcase runs on Vercel
+> for invited visitors.
 > **Reference project:** built like a real customer engagement for a mid-sized machine-building
 > company; the customer is fictional and **all data in this repository is synthetic**.
 
@@ -22,10 +24,26 @@ upload (.eml/.msg/PDF/XLSX/DOCX) → parse → extract with evidence → verify
 - **Tenant isolation:** repository scoping plus forced PostgreSQL row-level security per company.
 - **Measurable AI quality:** an eval set with per-field metrics gates prompt and model changes.
 
+## What runs today
+
+Each line is a merged PR; details in the [CHANGELOG](CHANGELOG.md).
+
+- Invite-only login, companies, user and role management for admins; forced row-level security on every
+  company-data table (schema `app`), guarded by a test (#31, #37, #38)
+- Upload of `.eml`, `.msg`, PDF (scanned pages via OCR when `AI_PDF_OCR=auto`, marked as such), XLSX and DOCX,
+  several files per request; duplicates flagged and decided in the UI (#32, #40, #44)
+- AI extraction of the header fields and line items with a grounding verifier (#33, #39)
+- Review beside the source with a status per value, audited corrections, approve or reject (#35, #42)
+- Exactly-once export of the reviewed values and positions to the ERP mock (#36, #54)
+- Request list led by the next action, with diagnosis, retries and reprocessing, paged (#43, #58, #95)
+- Eval set of 15 synthetic cases as a CI gate (#41); correlated structured logs and health (#45, #56, #88)
+- Showcase: prepared sample requests replayed from recorded AI answers (#83)
+
 ## Architecture
 
 TypeScript modular monolith (Next.js, Node 24, Drizzle, PostgreSQL 17, pg-boss, Better Auth,
-S3 API) plus a stateless Python AI service (FastAPI, docling, Gemini on Vertex AI in the EU).
+S3 API) plus a stateless Python AI service (FastAPI, docling, Gemini on Vertex AI in the EU; the showcase
+uses the Gemini API free tier with synthetic data only – a dated exception, ADR-0001 D11).
 Rationale, alternatives and trade-offs: [ADR-0001](docs/decisions/ADR-0001-pilot-architecture.md).
 
 ## Documentation map

diff --git a/docs/product/roadmap.md b/docs/product/roadmap.md
@@ -5,11 +5,12 @@
 
 | Milestone | Content | Acceptance | Status |
 |---|---|---|---|
-| **M0 – Problem confirmed** | Discovery, proposal, architecture (ADR-0001), foundation | Proposal sent; §7 approval; foundation PR merged | in progress |
-| **M1 – Secure core** | Epic 1 vertical slice: one request end to end (login, tenant isolation, upload, AI extraction with grounding, review, idempotent export) | Slice demo on local Docker; cross-tenant and idempotency tests green | open |
-| **M2 – Internal beta (pilot)** | Epic 2 full extraction + eval gate, Epic 3 robustness | Pilot acceptance criteria (proposal §7) met with 3–5 test users | open |
+| **M0 – Problem confirmed** | Discovery, proposal, architecture (ADR-0001), foundation | Proposal sent; §7 approval; foundation PR merged | done – approval 2026-09-22 (`PROJECT-START.md`), ADR-0001 accepted, foundation #20 |
+| **M1 – Secure core** | Epic 1 vertical slice: one request end to end (login, tenant isolation, upload, AI extraction with grounding, review, idempotent export) | Slice demo on local Docker; cross-tenant and idempotency tests green | done – epic #2 closed (#21, #31–#36); cross-tenant and exactly-once integration tests run in every `verify`. The slice demo ran on native PostgreSQL + SeaweedFS (Docker Hub answered 429 locally); `docker compose up` is proven by the CI job `compose-smoke`, the flow by the Playwright smoke |
+| **M2 – Internal beta (pilot)** | Epic 2 full extraction + eval gate, Epic 3 robustness | Pilot acceptance criteria (proposal §7) met with 3–5 test users | built – acceptance pending: epics #17 and #18 closed (#37–#45, follow-ups #53–#63), release v0.1.0 (#86). A reference project has no real test users: acceptance here means the orchestrator walks the §7 criteria on the showcase with the synthetic samples and records the result |
 | **M3 – Acceptance-ready** | Findings from the pilot, security review, stage change P1 → P2 prepared | Customer acceptance against agreed thresholds | open |
 | **M4 – Production** | Real mailbox + ERP, Entra SSO, monitoring, backup + rehearsed restore, rollback | Release approval by the orchestrator | open |
 | **M5 – Expansion** | Further subsidiaries, near-duplicate hints, ops page | Per new brief | open |
 
-The public showcase (Vercel) follows M2 acceptance (ADR-0001 D11).
+The public showcase (Vercel, epic #19) runs ahead of M2 acceptance as a temporary, invite-only exception
+(ADR-0001 D11 amendment 2026-09-26, #67).
diff --git a/docs/technical/architecture.md b/docs/technical/architecture.md
@@ -12,10 +12,9 @@ approve them, and exports each approved request exactly once to an ERP (mock in
 It is a TypeScript modular monolith (`web` + `worker` from one codebase) on PostgreSQL, plus the
 AI service. Decisions and rationale: [ADR-0001](../decisions/ADR-0001-pilot-architecture.md).
 
-**Current state (2026-09-23): #3 skeleton, #4 identity/tenancy, #5 intake** – runnable stack, health
-endpoint, invite-only login, companies, `withTenant()` with forced RLS, upload with atomic enqueue
-and duplicate flags, module boundaries enforced. Tables: [data-model.md](data-model.md). Status per module below (`skeleton` = public
-`index.ts` only).
+**Current state (2026-09-28): pilot scope built** – epics #2, #17 and #18 merged, release v0.1.0 (#86): every
+module below except `audit` and `app` (partial) is built; module boundaries are enforced in `verify`. The showcase runs on Vercel + Supabase with
+the AI service as a Vercel container (epic #19). Tables: [data-model.md](data-model.md). Status per module below.
 
 ## Modules