chore(release): v0.1.0 – pilot scope

[Fluory]

Warum

Fixes #85 · erstes Release des Pilotumfangs

Arbeitsstand

• Ziel: Release v0.1.0 des Pilotumfangs, geprüft nach /release.
• Nicht-Ziele: neue Funktionen, Versionssprung über 0.x hinaus.
• Erledigt: CHANGELOG-Abschnitt [0.1.0] – 2026-09-27, leerer [Unreleased]; Skill release installiert und im Skill-Register der AGENTS.md eingetragen; Bereitschaftsprüfung unten.
• Offen: Merge, Tag v0.1.0 auf dem Merge-Commit, GitHub-Release mit dem CHANGELOG-Abschnitt.
• Annahmen: keine.
• Nächster kleinster Schritt: Merge.

Was ist passiert (Klartext)

Seit Projektbeginn wurden alle Änderungen unter „noch nicht veröffentlicht“ gesammelt – inzwischen über 100 Zeilen. Dieser PR fasst den bisherigen Stand als erste Version 0.1.0 zusammen: alles, was der Pilot kann, vom Einlesen der Mail bis zum Export ins ERP. Bevor die Version einen festen Namen (Tag) bekommt, prüft eine Checkliste, ob sie auslieferbar ist. Drei Punkte sind dabei offen und brauchen eine bewusste Entscheidung (siehe Bereitschaftsprüfung).

Plan-Pflicht (SYSTEM.md §4)

• Kein Auslöser – keine Modulgrenze, öffentliche API, Migration, Auth/Rechte, kein Zahlungs-/Daten-/Infrapfad, höchstens zwei Module, keine Architekturvarianten, umkehrbar
• Auslöser zutreffend – Impact Manifest ausgefüllt (Plan vor Code)

Bereitschaftsprüfung (/release)

Version: v0.1.0 · Status: ready – Freigabe des Orchestrators 2026-09-28 (Option A: offene Punkte 1–3 als bekannte Grenzen angenommen, Bedingung verify:full grün – erfüllt)
Bestanden: SemVer (package.json und services/ai 0.1.0, noch kein Tag) · CHANGELOG vollständig (je PR ein Eintrag) ·
  CI auf dem Release-Stand: main@8177c3a = geprüfter Stand von #83 (check, compose-smoke, beide Vercel-Builds grün) ·
  Migrationen: 0001–0019 in CI auf frischer DB, 0019 im Showcase per setup:deploy angewendet (CHECK per SQL bestätigt) ·
  Staging-Smoke: Showcase 2026-09-27 im Browser (Upload → Prüfung, Freigabe → Exportiert, Beispiele mit Kennzeichnung) ·
  keine offenen decision-needed-Issues
Offen: 1. Rollback-Weg dokumentiert (Runbook §9, Vercel Instant Rollback; Migrationen forward-only), aber nicht geprobt ·
  2. Monitoring: strukturierte Logs und /api/health, aber keine Alarme; /api/health meldet beim Kaltstart fälschlich „failed“ (#81) ·
  3. offene security-Issues #10 (Security-Baseline-Checkliste) und #11 (DSGVO-Checkliste) – Checklisten-Audits, keine bekannten Schwachstellen ·
  Hinweis: der Skill /database-migration ist nicht installiert; Migrationen wurden nach der Bereichsregel geprüft (frische DB, additiv)
Freigabe benötigt: Orchestrator (immer)

Geändert

• CHANGELOG.md: [0.1.0] – 2026-09-27, neuer leerer [Unreleased]
• .claude/skills/release/SKILL.md: aus Entwicklungsplan/templates/skills/release installiert
• AGENTS.md: Skill-Register nennt release

Nachweis (SYSTEM.md §11)

• verify:changed: grün – nur Doku; scripts/doku-check.sh grün (0 WARN, vorher 1 WARN: CHANGELOG > 100 Zeilen)
• verify: grün – CI am PR, voller Lauf mit Label verify-full nach ci: the verify-full label forces the full run, also for doc-only PRs #90 (5 min 2 s)
• verify:full / E2E-Spec: grün – erstmals für einen reinen Doku-PR in der Linux-CI (möglich durch ci: the verify-full label forces the full run, also for doc-only PRs #90): pnpm verify, pnpm verify:full (Unit, Integration, E2E, Eval-Gate), AI verify (ruff, pyright, pytest), Eval-Gate. Die zwei lokalen Anläufe vom 2026-09-28 00:1x scheiterten an Ressourcenmangel durch fremde Prozesse (belegt), nicht am Code.
• Manueller Prüfnachweis: Showcase-Smoke 2026-09-27 (siehe Bereitschaftsprüfung)
• Frischer Review (P1 vor Ready-for-review; Architektur/API/DB immer): nicht nötig – nur Doku und eine Skill-Vorlage aus dem Framework; die Bereitschaftsprüfung ersetzt ihn für das Release

Doku-Entscheidung (genau eine)

• Keine langlebige Doku betroffen – Begründung: –
• Doku betroffen und im selben PR aktualisiert:
  • Produktdoku (P0: README): –
  • Technische Doku: –
  • Architekturkarte: –
  • ADR: –
  • CHANGELOG [Unreleased] (sichtbares Feature oder Verhalten – im selben PR, nie „später"): Abschnitt [0.1.0]

Entferntes oder Umbenanntes: docs/ + README gegrept, Treffer bereinigt: nichts entfernt

Dateigrößen und neue Bausteine (SYSTEM.md §7)

Dateien über 500 Zeilen im Diff (Ausnahmen: generierter Code, Lockfiles, Fixtures, Migrationen, Schemas, Ressourcen, Doku, Konfiguration):

• keine
• bewusst belassen – Begründung: –
• im selben PR nach fachlicher Verantwortung geteilt
• Folge-Issue –

Über 800 Zeilen mit neuer Fachlogik oder über 1000 Zeilen (P1/P2): nicht betroffen

Neue Shared-Komponente, Utility-Datei, Adapter oder fachlicher Service:

• nein
• ja – gesucht nach: –

Subagent-Einsätze

Keine.

Risiken / offene Punkte

• Die drei offenen Punkte der Bereitschaftsprüfung; ohne Annahme durch den Orchestrator kein Tag.

---

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
requestflow	Ready	Preview	Sep 28, 2026 11:38am UTC
requestflow-ai	Ready	Preview	Sep 28, 2026 11:38am UTC

[Fluory]

Übergabe (2026-09-28, Sitzungsende)

• Erledigt: CHANGELOG [0.1.0] – 2026-09-27, Skill release installiert, Bereitschaftsprüfung im PR; main inkl. fix(tests): run the architecture test on Windows #87 (Windows-Architekturtest) eingemergt; CI check grün.
• Offen: (1) ein sauberer lokaler pnpm verify:full – zweimal an Ressourcenmangel durch fremde Prozesse gescheitert (zuletzt 0,4 GB RAM frei), in der CI läuft er für diesen Doku-PR nicht; (2) Entscheidung des Orchestrators zu den offenen Release-Punkten: Rollback nicht geprobt, keine Alarme, add-on: Security baseline checklist #10/add-on: Data protection (GDPR) checklist #11 offen.
• Nächster Schritt: Rechner entlasten → PW_CHROMIUM_PATH=… pnpm verify:full auf diesem Branch; bei Grün und Annahme der Punkte: Merge, Tag v0.1.0 auf dem Merge-Commit, GitHub-Release mit dem CHANGELOG-Abschnitt.
• Risiko: gering – der Release-Code ist in der CI geprüft; offen ist nur der gebündelte lokale Nachweis.

[Fluory]

Freigabe des Orchestrators (2026-09-28, Option A): Die offenen Release-Punkte werden als bekannte Grenzen des Pilot-Releases v0.1.0 angenommen – (1) Rollback dokumentiert, nicht geprobt; (2) keine Alarme, nur Logs und /api/health; (3) Checklisten #10/#11 offen. Bedingung: ein sauberer verify:full-Lauf vor dem Tag. Da der lokale Rechner weiterhin ausgelastet ist (0,8 GB RAM frei, Docker aus), läuft verify:full in der Linux-CI: dafür erzwingt #90 die volle Prüfung auch für Doku-PRs mit Label verify-full.

[Fluory]

Merge auf Freigabe des Orchestrators (2026-09-28, Option A) – verify:full in der CI grün (5 min 11 s).