AP0 Schritte 0.4 und 0.6: Antworten vom 05.10. und Claude Design 0.3 eingearbeitet

- Fragenliste: erste Antworten von BauIn und ITM eingetragen, übrige Fragen auf „gestellt“ - Anmeldung mit eigenem Passwort, 2FA später Pflicht; keine E-Mails; Mehrfach-Upload ohne ZIP - Nur Produktionsschlüssel: Tests rufen die echte API nie auf - Stellungnahme BÜW und Österreich in Phase 2; „Vor dem Livegang zu klären“ in AP11 - Claude Design Stand 0.3 abgeglichen (AP13), Prüfmaske v4 in AP6 - Gitea von ITM als Push-Mirror eingetragen Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-05 15:54:18 +02:00
parent 2143f4e955
commit f62541ff13
14 changed files with 288 additions and 159 deletions
@@ -46,6 +46,9 @@ Die Ports 80 und 3306 sind auf dem Entwicklungsrechner belegt, daher `APP_PORT`
 ## Festlegungen
 - Keine Selbstregistrierung: Benutzer legt ein Administrator an.
- 2FA (Authenticator-App) und Passkeys sind verfügbar, 2FA ist noch nicht verpflichtend.
+- 2FA (Authenticator-App) und Passkeys sind verfügbar. 2FA ist zunächst freiwillig und wird
  später per Schalter Pflicht.
 - Die Anwendung verschickt keine E-Mails.
 - Meilisearch: Version fest eingestellt, Telemetrie aus (`MEILISEARCH_NO_ANALYTICS=true`).
- Git: führend ist der lokale Gitea; der Gitea von ITM folgt als Push-Mirror.
+- Git: führend ist der lokale Gitea; der Gitea von ITM
  (`https://gitea.itm-technologies.de/ChristophGraf/BauIN`) folgt als Push-Mirror.
@@ -13,58 +13,58 @@ Planungsordner und werden aus dieser Liste erzeugt.
 | ID | Thema | ★ | an | betrifft | Status |
 |---|---|---|---|---|---|
-| A1 | Gliederung Projekt → PFA → Vertrag → LVs | ★ | BauIn fachlich | AP1, Datenmodell | offen |
+| A1 | Gliederung Projekt → PFA → Vertrag → LVs | ★ | BauIn fachlich | AP1, Datenmodell | gestellt (05.10.) |
-| A2 | Weitere Vertragsunterlagen im „Topf“ | ★ | BauIn fachlich | AP4, AP5 | offen |
+| A2 | Weitere Vertragsunterlagen im „Topf“ | ★ | BauIn fachlich | AP4, AP5 | gestellt (05.10.) |
-| A3 | Vorbemerkungen in X86 oder eigene PDFs | ★ | BauIn fachlich | AP5 | offen |
+| A3 | Vorbemerkungen in X86 oder eigene PDFs | ★ | BauIn fachlich | AP5 | gestellt (05.10.) |
-| A4 | Beauftragte Nachträge mit durchsuchen | ★ | BauIn fachlich | AP4, Datenmodell | offen |
+| A4 | Beauftragte Nachträge mit durchsuchen | ★ | BauIn fachlich | AP4, Datenmodell | gestellt (05.10.) |
-| A5 | Nachtrags-LV immer als X86/D86 | ★ | BauIn fachlich | AP5 | offen |
+| A5 | Nachtrags-LV immer als X86/D86 | ★ | BauIn fachlich | AP5 | gestellt (05.10.) |
-| A6 | Bezugsposition im Nachtrag genannt | | BauIn fachlich | AP7 | offen |
+| A6 | Bezugsposition im Nachtrag genannt | | BauIn fachlich | AP7 | gestellt (05.10.) |
-| A7 | Benötigte Teile eines Nachtrags | | BauIn fachlich | AP5 | offen |
+| A7 | Benötigte Teile eines Nachtrags | | BauIn fachlich | AP5 | gestellt (05.10.) |
-| A8 | MKA nur als Bezugsnummer | | BauIn fachlich | Datenmodell | offen |
+| A8 | MKA nur als Bezugsnummer | | BauIn fachlich | Datenmodell | gestellt (05.10.) |
-| A9 | Ergebnis je Nachtragsposition, Werte | ★ | BauIn fachlich | AP6, AP9 | offen |
+| A9 | Ergebnis je Nachtragsposition, Werte | ★ | BauIn fachlich | AP6, AP9 | gestellt (05.10.) |
-| A10 | Suchreihenfolge | ★ | BauIn fachlich | AP4 | offen |
+| A10 | Suchreihenfolge | ★ | BauIn fachlich | AP4 | gestellt (05.10.) |
-| A11 | Treffer in anderem PFA mit EP anzeigen | | BauIn fachlich | AP6 | offen |
+| A11 | Treffer in anderem PFA mit EP anzeigen | | BauIn fachlich | AP6 | gestellt (05.10.) |
-| A12 | Geändert/zusätzlich vorschlagen | | BauIn fachlich | AP7 | offen |
+| A12 | Geändert/zusätzlich vorschlagen | | BauIn fachlich | AP7 | gestellt (05.10.) |
-| A13 | Anordnungen außen vor | | BauIn fachlich | – | offen |
+| A13 | Anordnungen außen vor | | BauIn fachlich | – | beantwortet (05.10.): außen vor |
-| A14 | Bewertungsmatrix (Vorlage, Spalten, Makros) | ★ | BauIn fachlich | AP9, OP1 | offen |
+| A14 | Bewertungsmatrix (Vorlage, Spalten, Makros) | ★ | BauIn fachlich | AP9, OP1 | gestellt (05.10.) |
-| A15 | Stellungnahme BÜW (Vorlage) | | BauIn fachlich | OP2 | offen |
+| A15 | Stellungnahme BÜW (Vorlage) | | BauIn fachlich | OP2 | vertagt: Phase 2 |
-| A16 | DOXIS bleibt Handarbeit | | BauIn fachlich | – | offen |
+| A16 | DOXIS bleibt Handarbeit | | BauIn fachlich | – | beantwortet (05.10.): von Hand |
-| A17 | Mengengerüst Pilot | ★ | BauIn fachlich | AP2, AP11 | offen |
+| A17 | Mengengerüst Pilot | ★ | BauIn fachlich | AP2, AP11 | gestellt (05.10.) |
-| A18 | Anonymisierter Beispielablauf | ★ | BauIn fachlich | AP5 | offen |
+| A18 | Anonymisierter Beispielablauf | ★ | BauIn fachlich | AP5 | gestellt (05.10.) |
-| A19 | Echte Pilotdaten bei ITM und über die KI-API | ★ | BauIn fachlich | M2 | offen |
+| A19 | Echte Pilotdaten bei ITM und über die KI-API | ★ | BauIn fachlich | M2 | beantwortet (05.10.): ja, alles bei ITM; ab wann offen |
-| A20 | Referenzfälle | | BauIn fachlich | AP2, AP12 | offen |
+| A20 | Referenzfälle | | BauIn fachlich | AP2, AP12 | gestellt (05.10.) |
-| A21 | Erfolgskriterium | | BauIn fachlich | AP12 | offen |
+| A21 | Erfolgskriterium | | BauIn fachlich | AP12 | gestellt (05.10.) |
-| A22 | Anzahl Nutzer | | BauIn fachlich | AP1 | offen |
+| A22 | Anzahl Nutzer | | BauIn fachlich | AP1 | gestellt (05.10.) |
-| A23 | Regeln projektübergreifend | | BauIn fachlich | AP8 | offen |
+| A23 | Regeln projektübergreifend | | BauIn fachlich | AP8 | gestellt (05.10.) |
-| A24 | Freigabe von Regeln | | BauIn fachlich | AP8 | offen |
+| A24 | Freigabe von Regeln | | BauIn fachlich | AP8 | gestellt (05.10.) |
-| A25 | Rollen und Rechtevergabe | ★ | BauIn fachlich | AP1 | offen |
+| A25 | Rollen und Rechtevergabe | ★ | BauIn fachlich | AP1 | gestellt (05.10.) |
-| A26 | Österreich | | BauIn fachlich | – | offen |
+| A26 | Österreich | | BauIn fachlich | – | vertagt: Phase 2 |
-| A27 | Aufbewahrung nach Projektende | | BauIn fachlich | AP11 | offen |
+| A27 | Aufbewahrung nach Projektende | | BauIn fachlich | AP11 | vertagt: nach Livegang Phase 1 |
-| A28 | DB-Richtlinien in KI-System (Phase 3) | | BauIn fachlich | Phase 3 | offen |
+| A28 | DB-Richtlinien in KI-System (Phase 3) | | BauIn fachlich | Phase 3 | vertagt: nach Livegang Phase 1 |
-| B1 | Anmeldung: Microsoft-Konto oder Passwort + 2FA | ★ | BauIn IT | AP1 | offen |
+| B1 | Anmeldung: Microsoft-Konto oder Passwort + 2FA | ★ | BauIn IT | AP1 | beantwortet (05.10.): Passwort, 2FA später Pflicht |
-| B2 | Zugriff: Internet oder VPN | ★ | BauIn IT | AP11 | offen |
+| B2 | Zugriff: Internet oder VPN | ★ | BauIn IT | AP11 | vertagt: vor Livegang |
-| B3 | Domain und E-Mail | | BauIn IT | AP10, AP11 | offen |
+| B3 | Domain und E-Mail | | BauIn IT | AP10, AP11 | beantwortet (05.10.): keine E-Mails; Adresse vor Livegang |
-| B4 | Ordnerstruktur für ZIP-Upload | | BauIn IT | AP1 | offen |
+| B4 | Ordnerstruktur für ZIP-Upload | | BauIn IT | AP1 | beantwortet (05.10.): Mehrfach-Upload, kein ZIP |
-| B5 | Backups | | BauIn IT | AP11 | offen |
+| B5 | Backups | | BauIn IT | AP11 | vertagt: später |
-| B6 | Datenschutz und Informationssicherheit | ★ | BauIn IT | M2 | offen |
+| B6 | Datenschutz und Informationssicherheit | ★ | BauIn IT | M2 | vertagt: vor Livegang (Doku in AP11) |
-| C1 | Schlüssel je Umgebung, Termin | ★ | ITM | AP3 | offen |
+| C1 | Schlüssel je Umgebung, Termin | ★ | ITM | AP3 | beantwortet (05.10.): nur Produktion |
-| C2 | Datenverarbeitung bei API-Werk | ★ | ITM | M2 | offen |
+| C2 | Datenverarbeitung bei API-Werk | ★ | ITM | M2 | beantwortet (05.10.): Sache von ITM |
-| C3 | Preise für den Kostenrahmen | ★ | ITM | AP0 | offen |
+| C3 | Preise für den Kostenrahmen | ★ | ITM | AP0 | beantwortet (05.10.): Sache von ITM |
-| C4 | `embed`: Modell, Dimension, Grenzen | | ITM | AP3, AP4 | offen |
+| C4 | `embed`: Modell, Dimension, Grenzen | | ITM | AP3, AP4 | gestellt (05.10.) |
-| C5 | `rerank`: Modell, Grenzen | | ITM | AP3, AP4 | offen |
+| C5 | `rerank`: Modell, Grenzen | | ITM | AP3, AP4 | gestellt (05.10.) |
-| C6 | `chat`: Modell, Kontext, JSON-Ausgabe | | ITM | AP7 | offen |
+| C6 | `chat`: Modell, Kontext, JSON-Ausgabe | | ITM | AP7 | gestellt (05.10.) |
-| C7 | Dokumentdienst: JSON, Dateitypen | | ITM | AP3, AP5 | offen |
+| C7 | Dokumentdienst: JSON, Dateitypen | | ITM | AP3, AP5 | gestellt (05.10.) |
-| C8 | Last und Vorrang | | ITM | AP3 | offen |
+| C8 | Last und Vorrang | | ITM | AP3 | gestellt (05.10.) |
-| C9 | Verfügbarkeit | | ITM | AP11 | offen |
+| C9 | Verfügbarkeit | | ITM | AP11 | gestellt (05.10.) |
-| C10 | Server: Ausstattung, Zugang | | ITM | AP11 | offen |
+| C10 | Server: Ausstattung, Zugang | | ITM | AP11 | beantwortet (05.10.): Sache von ITM |
-| C11 | Gitea und Rechte am Code | | ITM | AP0 | offen |
+| C11 | Gitea und Rechte am Code | | ITM | AP0 | beantwortet (05.10.): URL da; Rechte nicht unsere Sache |
-| C12 | Abgrenzung mit dem ITM-Entwickler | ★ | ITM | AP3, AP7, AP11 | offen |
+| C12 | Abgrenzung mit dem ITM-Entwickler | ★ | ITM | AP3, AP7, AP11 | beantwortet (05.10.): passt |
-| C13 | „Datentresor“ bestätigen | | ITM | AP3 | offen |
+| C13 | „Datentresor“ bestätigen | | ITM | AP3 | beantwortet (05.10.): passt |
 | D2 | Aufwand an ITM für Kostenrahmen | ★ | intern | AP0 | offen |
 | D3 | Stand datenschleuse | | intern | AP5 | offen |
 | D4 | Freitagstermine | | intern | AP0 | offen |
 | D5 | Actions-Runner auf dem Synology-Gitea | ★ | intern | AP1 | offen |
-| D6 | Rückmeldung an Claude Design gegeben? | ★ | intern | AP13 | offen |
+| D6 | Rückmeldung an Claude Design gegeben? | ★ | intern | AP13 | beantwortet (05.10.): Stand 0.3 da |
 ---
@@ -147,7 +147,7 @@ geändert. Die rechtliche Einordnung macht aber BauIn. Also weglassen oder als H
 ### A13 Anordnungen des Auftraggebers
 Gemeint ist z. B. eine E-Mail der DB-Projektleitung zu besohlten Schwellen. Vorschlag: Anordnungen
 bleiben in Phase 1 außen vor. Einverstanden?
-*Antwort:* –
+*Antwort:* beantwortet (05.10.): Passt. Anordnungen bleiben in Phase 1 außen vor.
 ### A14 ★ Bewertungsmatrix
 Bitte die leere Vorlage und 2–3 ausgefüllte Matrizen schicken.
@@ -161,12 +161,12 @@ Bitte die leere Vorlage und 2–3 ausgefüllte Matrizen schicken.
 Bitte die Vorlage schicken. Ist sie .doc oder .docx? Wir können nur .docx automatisch füllen; eine
 einmalige Umwandlung reicht. Welche Felder ändern sich, z. B. Ansprechpartner DB, Bearbeiter,
 Nachtrag-Nr., Betreff, Angebotssumme, Sachverhalt?
-*Antwort:* –
+*Antwort:* vertagt (05.10.): Die Stellungnahme BÜW kommt erst in Phase 2. OP2 entfällt in Phase 1.
 ### A16 DOXIS
 Vorschlag: Ergebnis und Stellungnahme lädt der Bearbeiter weiter von Hand in DOXIS hoch, ohne
 Anbindung in Phase 1. Einverstanden?
-*Antwort:* –
+*Antwort:* beantwortet (05.10.): Passt. Der Bearbeiter lädt Ergebnis und Stellungnahme weiter von Hand in DOXIS hoch.
 ### A17 ★ Mengengerüst Pilot
 - Anzahl Verträge und LVs je PFA
@@ -189,7 +189,8 @@ sowie die ausgefüllte Matrix. Firmen, Namen und Bankdaten dürfen ersetzt oder
 - Muss die DB zustimmen, z. B. wegen Geheimhaltungspflichten aus eurem Vertrag mit der DB?
 - Ab wann ginge das?
-*Antwort:* –
+*Antwort:* beantwortet (05.10.): Ja. Alle Daten liegen final bei ITM; BauIn hat keine eigene
 Serverstruktur. Offen: ab wann. Für Claude Code gilt weiter: keine echten Daten.
 ### A20 Referenzfälle
 Bitte 10–20 abgeschlossene Nachträge mit eurem Ergebnis, damit wir die Trefferquote messen können.
@@ -227,17 +228,17 @@ Passt das? Wer vergibt die Rechte?
 ### A26 Österreich
 Ist Österreich noch ein Thema, und wenn ja, wann?
-*Antwort:* –
+*Antwort:* vertagt (05.10.): Österreich kommt in Phase 2.
 ### A27 Aufbewahrung
 Das Pilotprojekt läuft bis etwa 2032. Was passiert danach mit den Daten (archivieren, löschen,
 Fristen)?
-*Antwort:* –
+*Antwort:* vertagt (05.10.): wird nach dem Livegang von Phase 1 geklärt.
 ### A28 Phase 3, nicht eilig
 Dürfen die Richtlinien der DB nach den Nutzungsbedingungen eures Regelwerk-Bezugs in ein
 KI-System übernommen werden?
-*Antwort:* –
+*Antwort:* vertagt (05.10.): wird nach dem Livegang von Phase 1 geklärt.
 ---
@@ -246,32 +247,35 @@ KI-System übernommen werden?
 ### B1 ★ Anmeldung
 BauIn arbeitet mit Teams. Soll die Anmeldung über das Microsoft-Konto (Entra ID) laufen, oder mit
 eigenem Passwort und 2FA? Soll 2FA Pflicht sein?
-*Antwort:* –
+*Antwort:* beantwortet (05.10.): Eigenes Passwort, zunächst ohne 2FA. 2FA wird später
 eingeschaltet und ist dann Pflicht. Keine Anmeldung über das Microsoft-Konto.
 ### B2 ★ Zugriff
 Die Anwendung läuft auf Servern von ITM. Soll sie aus dem Internet mit Login und 2FA erreichbar
 sein, oder nur über VPN bzw. von festen IP-Adressen?
-*Antwort:* –
+*Antwort:* vertagt (05.10.): wird kurz vor dem Livegang geklärt, für die Entwicklung nicht relevant.
 ### B3 Domain und E-Mail
 Unter welcher Adresse soll die Anwendung laufen? Sollen Benachrichtigungen per E-Mail kommen, und
 von welchem Absender?
-*Antwort:* –
+*Antwort:* beantwortet (05.10.): Keine E-Mails. Die Adresse wird kurz vor dem Livegang geplant.
 ### B4 Dateien ins System bringen
 Vorschlag: Massen-Upload als ZIP mit eurer Ordnerstruktur (PFA → Vertrag → LVs); das System ordnet
 PDF und X86 paarweise zu. Wie sind die Ordner auf eurem Server benannt? Gibt es eine feste
 Struktur?
-*Antwort:* –
+*Antwort:* beantwortet (05.10.): Massen-Upload mehrerer Dateien, aber kein ZIP. Die Ordner werden
 manuell angelegt, eine feste Struktur gibt es nicht.
 ### B5 Backups
 Welche Anforderungen gibt es an Aufbewahrung und Speicherort? Wer ist zuständig (mit ITM klären)?
-*Antwort:* –
+*Antwort:* vertagt (05.10.): wird später geklärt.
 ### B6 ★ Datenschutz und Informationssicherheit
 Gibt es Vorgaben von BauIn oder von der DB, z. B. Sicherheitsanforderungen an Auftragnehmer der
 DB, ISO 27001 oder Geheimhaltung? Wer muss der Verarbeitung über die KI-API zustimmen?
-*Antwort:* –
+*Antwort:* vertagt (05.10.): Wichtig, aber für die jetzige Entwicklung (Prototyp) noch nicht relevant.
 In die Doku aufgenommen: AP11, „Vor dem Livegang zu klären“.
 ---
@@ -280,7 +284,8 @@ DB, ISO 27001 oder Geheimhaltung? Wer muss der Verarbeitung über die KI-API zus
 ### C1 ★ Schlüssel
 Gibt es getrennte Schlüssel für Entwicklung, Staging und Produktion, mit eigener Zählung und
 eigenem Limit? Wann bekommen wir die Schlüssel für die Entwicklung?
-*Antwort:* –
+*Antwort:* beantwortet (05.10.): Es gibt nur Schlüssel für die Produktion. Entwicklung, Staging und
 Produktion teilen sich damit Zählung, Kosten und Limit.
 ### C2 ★ Datenverarbeitung
 - Wo laufen api-werk.de, der Extractor und der KI-Server (Land, Rechenzentrum, eigene Hardware)?
@@ -289,13 +294,13 @@ eigenem Limit? Wann bekommen wir die Schlüssel für die Entwicklung?
  Auftrag löschen?
 - Gibt es einen Vertrag zur Auftragsverarbeitung? Werden Daten zum Training genutzt?
-*Antwort:* –
+*Antwort:* beantwortet (05.10.): Darum kümmert sich ITM, nicht unser Teil.
 ### C3 ★ Preise
 Wie hoch sind die Preise je Seite (Dokumentdienst) und je Anfrage bzw. Token (KI)? Wir brauchen
 sie für den Kostenrahmen an BauIn bis 16.10. Wer erstellt den Kostenrahmen, und welche Zahlen
 braucht ihr von uns bis wann?
-*Antwort:* –
+*Antwort:* beantwortet (05.10.): Preise und Kostenrahmen der KI-API sind Sache von ITM, nicht unser Teil.
 ### C4 `embed`
 - Welches Modell steckt dahinter (Qwen3-Embedding-8B?), mit welcher Dimension (4.096?)?
@@ -343,12 +348,14 @@ Gibt es Wartungsfenster und eine Statusseite? Wer ist Ansprechpartner bei Störu
 - Wer hat Root-Zugang? Ist die Festplatte verschlüsselt? Wie läuft die Verbindung zu api-werk.de?
 - Wie werden die Server gesichert?
-*Antwort:* –
+*Antwort:* beantwortet (05.10.): Sache von ITM (Ausstattung nach unseren Server-Anforderungen,
 Zugang, Verschlüsselung, Sicherung).
 ### C11 Gitea
 Wie lautet die Adresse für den Push-Mirror? Wem gehört der Code, und wer hat welche
 Nutzungsrechte?
-*Antwort:* –
+*Antwort:* beantwortet (05.10.): Push-Mirror nach https://gitea.itm-technologies.de/ChristophGraf/BauIN.
 Rechte am Code: nicht unsere Sache.
 ### C12 ★ Abgrenzung mit dem ITM-Entwickler
 Vorschlag:
@@ -359,13 +366,14 @@ Vorschlag:
 Passt das? Wie viel Zeit hat er für das Projekt, und wer übernimmt Deployment und Updates im
 Betrieb?
-*Antwort:* –
+*Antwort:* beantwortet (05.10.): Passt. Nicht beantwortet: Zeit des ITM-Entwicklers und wer im Betrieb
 deployt (AP11, E11.1).
 ### C13 „Datentresor“
 Wir haben den Wunsch so umgesetzt: Die Schlüssel liegen in der Windows-Anmeldeinformationsverwaltung,
 ein lokaler Proxy setzt sie ein, und in der Anwendung stehen sie verschlüsselt in der Datenbank,
 nie in der `.env`. War das so gemeint?
-*Antwort:* –
+*Antwort:* beantwortet (05.10.): Passt, so war es gemeint.
 ---
@@ -392,7 +400,8 @@ Einrichtungsskript.
 ### D6 ★ Claude Design
 Hast du die Rückmeldung (`Rueckmeldung_an_ClaudeDesign_2026-10-02.md`) schon an Claude Design
 gegeben? Den neuen Stand (Übergabe und `.dc.html`-Dateien) brauchen wir bis KW 42 für AP13.
-*Antwort:* –
+*Antwort:* beantwortet (05.10.): Rückmeldung gegeben. Stand 0.3 vom 05.10. mit den Änderungen 1–26 liegt
 im Planungsordner unter `claude-design/2026-10-05_Stand-0.3/`; Abgleich in AP13.
 ---
@@ -33,7 +33,8 @@ Keine.
 - [x] **0.2** Gesamtplan neu gegliedert, Teilpläne angelegt, Fragenliste mit Status
  (`docs/fragen.md`) → dieser Stand
 - [ ] **0.3** Du gibst Gesamtplan und Teilpläne frei (oder korrigierst sie) → Status in den Teilplänen
- [ ] **0.4** Fragen verschicken (du):
+- [x] **0.4** Fragen verschicken (du), erledigt am 05.10. Erste Antworten (B1–B6, C1–C3, C10–C13,
  A13, A15, A16, A19, A26–A28) sind in `docs/fragen.md` und den Teilplänen eingearbeitet.
  - Teil A an die Nachtragsbearbeitung von BauIn
  - Teil B an die IT von BauIn
  - Teil C an die ITM-Projektleitung
@@ -41,8 +42,10 @@ Keine.
  Die Dateien zum Verschicken liegen im Planungsordner. Danach steht der Status in
  `docs/fragen.md` auf „gestellt“.
 - [ ] **0.5** Server-Anforderungen an den ITM-Entwickler schicken (du) → Bestätigung oder Rückfragen
- [ ] **0.6** Rückmeldung an Claude Design geben (du); den neuen Stand ablegen, sobald er da ist
+- [x] **0.6** Rückmeldung an Claude Design geben (du); den neuen Stand ablegen, sobald er da ist
-  → Ordner `claude-design/` im Planungsordner
+  → Stand 0.3 vom 05.10. in `claude-design/2026-10-05_Stand-0.3/` im Planungsordner, Abgleich in AP13
 - [ ] **0.6a** Push-Mirror zum Gitea von ITM einrichten (du, Weboberfläche des lokalen Gitea)
  → `https://gitea.itm-technologies.de/ChristophGraf/BauIN`, erster Abgleich geprüft
 - [ ] **0.7** Aufwand für den Kostenrahmen an die ITM-Projektleitung (du, bis 14.10.)
  → Zahlen aus Abschnitt 4 des Gesamtplans
 - [ ] **0.8** Statusbericht für den 16.10.: Claude Code entwirft bis 14.10., du ergänzt Screenshots
@@ -20,19 +20,21 @@ PFA und Verträgen an und laden LV-Pakete hoch. Jede wichtige Aktion wird protok
 - Rechtekonzept und Policies
 - Benutzerverwaltung
 - Projektverwaltung (Projekt, PFA, Verträge, Auftragnehmer, Mitglieder)
- Upload und Download im privaten Speicher, auch als ZIP
+- Upload (mehrere Dateien auf einmal, kein ZIP) und Download im privaten Speicher
 - Protokoll
 - Länderstruktur
 **Nicht enthalten:**
 - GAEB-Import (AP5)
- Anmeldung mit dem Microsoft-Konto (erst nach Antwort B1, eigener Schritt)
+- Anmeldung mit dem Microsoft-Konto (entfällt, B1)
 - E-Mails jeder Art, auch Einladung und „Passwort vergessen“ (B3)
 - Endgültiges Design (AP13): Die Oberflächen entstehen zuerst mit TallStackUI-Standard und
  werden in AP13 angepasst.
 ## Voraussetzungen
- Fragen: A1 (Gliederung), A25 (Rollen), B1 (Anmeldung), B4 (Ordnerstruktur für ZIP)
+- Fragen: A1 (Gliederung), A25 (Rollen). Beantwortet am 05.10.: B1 (eigenes Passwort, 2FA später
  Pflicht), B3 (keine E-Mails), B4 (Mehrfach-Upload, kein ZIP, Ordner von Hand)
 - D5 (Actions-Runner auf dem Synology-Gitea)
 ## Entscheidungen
@@ -41,9 +43,10 @@ PFA und Verträgen an und laden LV-Pakete hoch. Jede wichtige Aktion wird protok
 |---|---|---|---|
 | E1.1 | Projektrollen über eigene Tabelle oder Spatie-Teams? | Eigene Tabelle `projekt_mitglieder` (umgesetzt); globale Rollen über Spatie | offen |
 | E1.2 | Protokoll: Paket oder eigene Tabelle? | `spatie/laravel-activitylog` (MIT, verbreitet) | offen |
-| E1.3 | Neue Benutzer: Einladung per E-Mail mit Link zum Passwort setzen, oder Admin vergibt Startpasswort? | Einladung per E-Mail (Mailpit in der Entwicklung) | offen |
+| E1.3 | Neue Benutzer und vergessene Passwörter ohne E-Mail (B3) | Administrator vergibt ein Startpasswort, das bei der ersten Anmeldung geändert werden muss; er setzt auch vergessene Passwörter so zurück. „Passwort vergessen“ zeigt nur den Hinweis auf den Administrator | offen |
 | E1.4 | Benutzer löschen oder nur deaktivieren? | Nur deaktivieren, damit Protokoll und Zuordnungen erhalten bleiben | offen |
 | E1.5 | Darf der Administrator Projektinhalte sehen? | Nein, nur wenn er Projektmitglied ist | offen (A25) |
 | E1.6 | 2FA-Pflicht (B1) | Schalter unter Verwaltung → Einstellungen, zunächst aus. Eingeschaltet muss jeder Benutzer 2FA einrichten, bevor er weiterarbeitet; der Administrator kann 2FA eines Benutzers zurücksetzen | offen |
 ## Schritte
@@ -53,7 +56,9 @@ PFA und Verträgen an und laden LV-Pakete hoch. Jede wichtige Aktion wird protok
 - [x] **1.3** Nicht-funktionale Grundlagen: keine externen Ressourcen (Test), `CLAUDE.md`, Tech-Stack-Doku
 - [x] **1.4** Datenmodell Kern (`docs/datenmodell.md`). Umgesetzt vor Freigabe.
  - [ ] **1.4a** Review mit dir: Erklärung der Tabellen, Entscheidung E1.1
-  - [ ] **1.4b** Anpassen nach den Antworten A1, A4, A8 und A10
+  - [ ] **1.4b** Anpassen nach den Antworten A1, A4, A8 und A10 und an den Prototyp 0.3
    (AP13, Abgleich): Projekt ohne Vertragsgrundlage im Formular, Suchbereich nur ein Schalter
    „Andere Verträge im selben PFA einbeziehen“, Vertrag mit Gewerk und „Vertrag vom“
 - [ ] **1.5** CI in Gitea Actions:
  - Runner auf dem Synology prüfen bzw. einrichten (Skript von Claude Code, du führst es aus).
  - Workflow mit `composer install`, `npm run build`, Tests gegen MySQL, Pint (`--test`),
@@ -75,21 +80,23 @@ PFA und Verträgen an und laden LV-Pakete hoch. Jede wichtige Aktion wird protok
  → Ergebnis: Je Aktion ein Test mit und einer ohne Berechtigung.
 - [ ] **1.8** Benutzerverwaltung (Administrator):
  - Liste mit Suche
-  - Anlegen (Einladung nach E1.3), Bearbeiten, Deaktivieren (E1.4)
+  - Anlegen mit Startpasswort (E1.3), Bearbeiten, Passwort zurücksetzen, Deaktivieren (E1.4)
-  - Globale Rolle, Mandant, 2FA-Status
+  - Globale Rolle, Mandant, 2FA-Status; Schalter 2FA-Pflicht (E1.6)
  → Ergebnis: Verwaltung → Benutzer.
 - [ ] **1.9** Projektverwaltung:
  - Projektliste
-  - Projekt anlegen in drei Schritten wie im Claude-Design-Entwurf: Projektdaten, PFA und Verträge
+  - Projekt anlegen in drei Schritten wie im Prototyp „Projekt anlegen v3“: Projektdaten mit PFA
-    mit Auftragnehmern, Mitglieder
+    und Verträgen, Vertragsunterlagen (Upload aus 1.10), Prüfen und anlegen
  - Mitglieder im Reiter „Berechtigungen“ des Projektdetails
  - Bearbeiten, Archivieren (schreibgeschützt)
  → Ergebnis: Projekte → Neues Projekt.
 - [ ] **1.10** Upload und Download:
  - Speicher `storage/app/private/<mandant>/<projekt>/…`
-  - Einzel- und ZIP-Upload bis 200 MB
+  - Mehrere Dateien auf einmal hochladen (Auswahl oder Ziehen), kein ZIP (B4); bis 200 MB je Datei
-  - Paarbildung PDF, X86, D86 nach Dateinamen; Zuordnung zu PFA und Vertrag zum Bestätigen
+  - Paarbildung PDF, X86, D86 nach Dateinamen. Die Ordner bei BauIn haben keine feste Struktur
    (B4), deshalb werden PFA und Vertrag in der Anwendung gewählt bzw. je LV bestätigt
  - Prüfung von Dateityp und Größe, Erkennung von Duplikaten (sha256)
  - Download nur über eine Route mit Rechteprüfung
@@ -117,10 +124,13 @@ PFA und Verträgen an und laden LV-Pakete hoch. Jede wichtige Aktion wird protok
 ## Tests
 - Feature-Tests je Aktion mit und ohne Berechtigung, auch für andere Mandanten.
- Upload: Paarbildung, zu große Datei, falscher Typ, Duplikat, ZIP mit Ordnern.
+- Upload: Paarbildung, zu große Datei, falscher Typ, Duplikat, viele Dateien auf einmal.
 - Anmeldung: Startpasswort muss geändert werden; mit eingeschalteter 2FA-Pflicht kein Zugriff
  ohne eingerichtete 2FA.
 - Protokolleinträge für die genannten Ereignisse.
 ## Risiken
 - Die Rollen ändern sich nach A25. Deshalb das Konzept zuerst schriftlich und die Policies zentral halten.
- Große ZIPs: Upload-Grenzen in PHP, Nginx und Livewire abstimmen und testen.
+- Große Dateien und viele Dateien auf einmal: Upload-Grenzen in PHP, Nginx und Livewire
  abstimmen und testen.
@@ -26,7 +26,13 @@ liegen verschlüsselt in der Datenbank.
 ## Voraussetzungen
- C1 (Schlüssel), C4–C8 (Modelle, Grenzen); Schlüssel im Windows-Tresor, Proxy läuft (du)
+- C4–C8 (Modelle, Grenzen); Schlüssel im Windows-Tresor, Proxy läuft (du)
 - C1 (05.10.): Es gibt nur Schlüssel für die Produktion. Entwicklung, Staging und Produktion
  teilen sich Zählung, Kosten und das Limit von 120 Anfragen/min. Deshalb:
  - Automatische Tests und CI rufen die echte API nie auf (`Http::fake`).
  - Live-Aufrufe nur im Schnelltest (3.2) und gezielt, mit kleinen Testtexten.
  - Getrennte Schlüssel für Vorrang (C8) sind nicht zu erwarten; der Ratenbegrenzer (E3.1) muss
    das allein leisten.
 - AP1 Schritt 1.7 (Rechte für Verwaltung)
 ## Entscheidungen
@@ -19,7 +19,7 @@ und setzt das Prüfergebnis.
 **Enthalten:**
 - Datenmodell für Prüfung, Fundstellen und Feedback
 - Vorprüfungs-Job je Nachtrag, KI-Sicherheit aus Signalen
- Nachtragsliste, Prüfmaske v3 (ohne Sprachmodell-Teile)
+- Nachtragsliste, Prüfmaske v4 (ohne Sprachmodell-Teile)
 - Feedback je Aspekt, Korrektur der Fundstelle, Prüfergebnis, Verlauf
 **Nicht enthalten:**
@@ -29,7 +29,7 @@ und setzt das Prüfergebnis.
 ## Voraussetzungen
 - AP4, AP5 (Nachtrags-Import), AP13
- Prüfmaske v3 von Claude Design
+- Prüfmaske v4 von Claude Design (Stand 0.3, liegt vor)
 - A9 (Werte des Prüfergebnisses)
 ## Schritte (grob)
@@ -37,13 +37,17 @@ und setzt das Prüfergebnis.
 - [ ] **6.1** Datenmodell:
  - `pruefungen` je Nachtragsposition: Status, KI-Sicherheit, Prüfergebnis, Kommentar, bearbeitet von
  - `fundstellen`: LV-Element, Rang, Wert, Suchbereich
-  - `feedback`: Aspekt, passt / passt nicht, Korrektur
+  - `feedback`: Aspekt, Antwort, Korrektur. Laut Prototyp 0.3: Fundstelle als Auswahl mit
    „Auswahl bestätigen“ (gewählt: Kandidat, „keine“ oder „suche“); Prüfergebnis und Begründung
    mit Ja / Nein. Jede Antwort wird sofort als Entwurf gespeichert. Ändert sich die bestätigte
    Fundstelle, werden Prüfergebnis und Begründung neu angefordert und ihre Antworten
    zurückgesetzt.
 - [ ] **6.2** Vorprüfungs-Job: alle Positionen suchen (AP4), reranken, Fundstellen speichern,
  Nachtrag auf „vorgeprüft“ setzen, Benachrichtigung
 - [ ] **6.3** KI-Sicherheit aus Signalen: Wert der besten Fundstelle, Abstand zur zweiten, Art der
  Fundstelle; „Warum?“-Erklärung
 - [ ] **6.4** Nachtragsliste im Projekt und Positionsspalte mit Filter
- [ ] **6.5** Prüfmaske v3 mit drei Spalten:
+- [ ] **6.5** Prüfmaske v4 mit drei Spalten:
  - Fundstellen, Prüfergebnis, Begründung (Platzhalter bis AP7)
  - Original-Nachtrag, Anschreiben und Quellen als Reiter
 - [ ] **6.6** Feedback und Korrektur: richtige Fundstelle wählen, selbst suchen oder „keine
@@ -26,13 +26,17 @@ werden je nach Einstellung freigegeben. Bestätigte Fälle dienen als Referenzf
 - AP6, AP7
 - A23 (projektübergreifende Regeln?), A24 (Freigabe-Variante)
 - Prototyp 0.3 (Regeldialog v3) weicht ab: Freigabe immer durch den Projektleiter, keine
  Freigabe-Einstellung; Geltungsbereich nur Vertrag, PFA, Projekt. Unser Vorschlag an BauIn (A24)
  war „ohne Freigabe“, später umstellbar. **E8.1 offen:** Prototyp übernehmen oder Einstellung
  behalten?
 ## Schritte (grob)
- [ ] **8.1** Datenmodell Regeln und Versionen; Geltungsbereich Vertrag → PFA → Projekt →
+- [ ] **8.1** Datenmodell Regeln und Versionen; Geltungsbereich Vertrag → PFA → Projekt
-  Auftraggeber → Land; nie löschen
+  (Auftraggeber und Land erst nach A23); nie löschen
 - [ ] **8.2** Regeldialog aus der Prüfmaske: Vorformulierung, ähnliche Regeln
- [ ] **8.3** Freigabe-Einstellungen und Warteschlange „Zur Freigabe“
+- [ ] **8.3** Freigabe nach E8.1 und Warteschlange „Zur Freigabe“
 - [ ] **8.4** Regeln und Referenzfälle in Suche und Prompt einbeziehen; die speziellere Regel gewinnt
 - [ ] **8.5** Wissensbasis: Regeln, Zur Freigabe, Referenzfälle, Allgemeine Dokumente
@@ -18,7 +18,9 @@ und in die Bewertungsmatrix übertragen lässt.
 **Enthalten:** Bearbeitungsstand des Nachtrags, Ergebnisliste, Excel-Export (PhpSpreadsheet),
 Liste der Exporte, „Nachtrag abschließen“.
-**Nicht enthalten:** Bewertungsmatrix in der DB-Vorlage und Stellungnahme (Optionen).
+**Nicht enthalten:** Bewertungsmatrix in der DB-Vorlage (Option OP1) und Stellungnahme BÜW
 (Phase 2, A15). In der Ergebnisliste erscheint deshalb nur der Button für die Bewertungsmatrix,
 deaktiviert mit „Vorlage folgt“.
 ## Voraussetzungen
@@ -16,14 +16,14 @@ Die Auswertungen zeigen, wie gut die Vorschläge sind.
 ## Umfang
 **Enthalten:**
- Dashboard (Variante 1a aus Claude Design)
+- Dashboard nach Prototyp „Dashboard v3“ (2a, 2b Benachrichtigungen, 2c leer, 2e Hilfe)
- Benachrichtigungen in der Anwendung, optional per E-Mail
+- Benachrichtigungen nur in der Anwendung (Glocke in der Topbar); keine E-Mails (B3)
 - Auswertungen: Trefferquote, Treffsicherheit je KI-Sicherheit, überstimmte Regeln, Prüfzeit
 - Allgemeine Dokumente in den Einstellungen
 ## Voraussetzungen
-AP6; B3 (E-Mail-Absender).
+AP6. B3 ist beantwortet: keine E-Mails.
 ## Schritte (grob)
@@ -32,8 +32,29 @@ gesichert und überwacht. Ein Ausfall fällt auf, bevor BauIn ihn bemerkt.
 ## Voraussetzungen
-C10 (Ausstattung, Root-Zugang), B2 (Zugriff Internet/VPN), B3 (Domain, Mail), B5 und C10 (Backups),
+- C10 (05.10.): Ausstattung, Zugang, Verschlüsselung und Sicherung der Server sind Sache von ITM.
-C12 (wer deployt).
+  Wir liefern die Server-Anforderungen und die Vorlagen (11a).
 - B3 (05.10.): Die Anwendung verschickt keine E-Mails. Die Adresse wird vor dem Livegang geplant.
 - C12 ist beantwortet, offen blieb: Wer deployt im Betrieb, und wie viel Zeit hat der
  ITM-Entwickler?
 - B2, B5 und B6 werden vor dem Livegang geklärt (Abschnitt unten).
 ## Vor dem Livegang zu klären
 Für die Entwicklung des Prototyps nicht nötig, vor dem Livegang aber Pflicht. Stand 05.10.:
 | Thema | Frage | Mit wem |
 |---|---|---|
 | Zugriff (B2) | Aus dem Internet mit Login, oder nur über VPN bzw. feste IP-Adressen? | BauIn IT, ITM |
 | Adresse (B3) | Domain und Zertifikat | BauIn IT, ITM |
 | 2FA (B1) | Pflicht einschalten (Schalter aus AP1, E1.6) und Benutzer vorher informieren | BauIn |
 | Backups (B5) | Speicherort, Aufbewahrung, Zuständigkeit | BauIn IT, ITM |
 | Datenschutz und Informationssicherheit (B6) | Vorgaben von BauIn oder der DB, z. B. Sicherheitsanforderungen an Auftragnehmer der DB, ISO 27001, Geheimhaltung. Wer muss der Verarbeitung über die KI-API zustimmen? | BauIn IT |
 | Datenverarbeitung bei API-Werk (C2) | Standort, Speicherdauer, Auftragsverarbeitung, kein Training. Klärt ITM; wir brauchen nur das Ergebnis für die Doku | ITM |
 | Alarmierung (E11.3) | Ohne E-Mail aus der Anwendung: über die Überwachung von ITM? | ITM |
 Nach dem Livegang von Phase 1: Aufbewahrung nach Projektende (A27), Nutzung der DB-Richtlinien in
 einem KI-System (A28).
 ## Entscheidungen
@@ -41,7 +62,7 @@ C12 (wer deployt).
 |---|---|---|---|
 | E11.1 | Deployment | Skript auf dem Server mit Versionsverzeichnissen (`releases/`, `current`), ausgelöst per SSH | offen |
 | E11.2 | Backup-Werkzeug | restic, verschlüsselt, Ziel von ITM | offen (B5) |
-| E11.3 | Alarmierung | E-Mail an dich und den ITM-Entwickler | offen |
+| E11.3 | Alarmierung | Die Anwendung verschickt keine E-Mails (B3). Vorschlag: Lebenszeichen und Prüfbefehle, die die Überwachung von ITM abfragt | offen (mit ITM) |
 ## Schritte
@@ -55,7 +76,7 @@ C12 (wer deployt).
  - Lebenszeichen für Worker und Scheduler
  - Zählung fehlgeschlagener Jobs
  - Statusprüfung der KI-API (aus AP3)
-  - Mail bei Problemen (E11.3)
+  - Meldung bei Problemen nach E11.3
 - [ ] **11b.1** Staging aufsetzen (ITM-Entwickler, KW 42–44), erstes Deployment gemeinsam
 - [ ] **11a.5** Backup-Skript nach E11.2 und Betriebsdoku `docs/betrieb.md`:
  - Deployment, Wiederherstellung, `APP_KEY` sicher aufbewahren
@@ -65,7 +86,7 @@ C12 (wer deployt).
 ## Abnahmekriterien
 - Ein Deployment aus dem Gitea auf Staging klappt mit einem Befehl.
- Ein absichtlich gestoppter Worker löst innerhalb von 10 Minuten eine Mail aus.
+- Ein absichtlich gestoppter Worker löst innerhalb von 10 Minuten einen Alarm aus (Weg nach E11.3).
 - Der Restore-Test war erfolgreich und ist dokumentiert.
 ## Risiken
@@ -28,22 +28,30 @@ gebauten Bausteinen.
 ## Voraussetzungen
-Neuer Stand von Claude Design nach unserer Rückmeldung (`Rueckmeldung_an_ClaudeDesign_2026-10-02.md`).
+Erfüllt am 05.10.: **Stand 0.3** von Claude Design mit unseren Änderungen 1–26 und einer
-Benötigt werden die Übergabe (Abschnitte 1–9) und die `.dc.html`-Dateien. Bisheriger Stand:
+UX-Überarbeitung. Er liegt im Planungsordner unter `claude-design/2026-10-05_Stand-0.3/`:
-`ClaudeDesign_Stand_2026-10-02.md` im Planungsordner.
+- `Uebergabe.md`: maßgebliche Spezifikation, Abschnitte 0–9
 - `README.md`: Zusammenfassung mit Design-Tokens
 - `prototyp/`: `.dc.html`-Dateien mit `support.js`, im Browser zu öffnen
 - `screenshots/`: 27 PNG, ein Bild je Zustand, 1440 px breit, für den Abgleich
 - `icons/`: Phosphor 2.1.1 als SVG
 - `logo/`: Logo-SVGs
 Der Stand ist **verbindlich** (High-Fidelity): Farben, Schriften, Abstände, Texte und Zustände
 werden genau übernommen. Bei Widerspruch gilt der Prototyp vor den Screenshots.
 ## Entscheidungen
 | Nr. | Frage | Vorschlag | Entschieden |
 |---|---|---|---|
-| E13.1 | Schriften | League Spartan und IBM Plex über `@fontsource`-Pakete, lokal gebündelt | offen |
+| E13.1 | Schriften | League Spartan und IBM Plex über `@fontsource`-Pakete, lokal gebündelt. Sie sind nicht im Übergabepaket | offen |
-| E13.2 | Icons | Phosphor über das Blade-Paket `codeat3/blade-phosphor-icons` (MIT), in TallStackUI als Icon-Typ eingebunden | offen |
+| E13.2 | Icons | Die gelieferten SVGs (Phosphor 2.1.1, MIT) als lokales Icon-Set; TallStackUI erlaubt eigene SVG-Komponenten. Alternative: Blade-Paket `codeat3/blade-phosphor-icons`, dann Version gegen 2.1.1 prüfen | offen |
-| E13.3 | Ablage der Entwürfe im Repository | `docs/design/` mit Übergabe und `.dc.html` (nur erfundene Daten) | offen |
+| E13.3 | Ablage der Entwürfe im Repository | Stand 0.3 vollständig nach `docs/design/` (nur erfundene Daten, rund 5 MB), damit Claude Code bei jeder Seite nachsehen kann | offen |
 ## Schritte
- [ ] **13.1** Stand von Claude Design in `docs/design/` ablegen (E13.3), Unterschiede zur
+- [ ] **13.1** Stand 0.3 in `docs/design/` ablegen (E13.3). Unterschiede zur Rückmeldung und zu
-  Rückmeldung notieren
+  den Antworten sind schon notiert (Abschnitt „Abgleich Stand 0.3“)
 - [ ] **13.2** Design-Tokens als CSS-Variablen (hell und dunkel) und Tailwind-Theme
 - [ ] **13.3** Schriften (E13.1) und Icons (E13.2) einbinden; `NoExternalResourcesTest` bleibt grün
 - [ ] **13.4** TallStackUI anpassen: Buttons, Eingabefelder, Select, Karte, Dialog, Tabelle,
@@ -60,6 +68,41 @@ Benötigt werden die Übergabe (Abschnitte 1–9) und die `.dc.html`-Dateien. Bi
 - [ ] **13.7** Musterseite „Designsystem“ (nur in der Entwicklung) und Abgleich mit dem Prototyp
  per Screenshot; bestehende Seiten (Login, Einstellungen, AP1-Seiten) umstellen
 ## Abgleich Stand 0.3 (05.10.)
 **Passt zu Plan und Entscheidungen:**
 - TallStackUI 4 mit Präfix `ts-`, eigene Komponenten ohne Präfix (`x-confidence`,
  `x-review-question`, `x-source-choice`, `x-contract-coverage`, `x-coachmark`)
 - Schriften und Icons in der Anwendung lokal; der Prototyp lädt sie nur zur Ansicht von fremden Servern
 - Gliederung Projekt → PFA → Vertrag → LVs, Nachträge am Vertrag, MKA nur als Verweis (A8)
 - Nur „dem Grunde nach“: keine Mengen, Preise oder Anspruchsgrundlage. Höhe und Regelwerk sind
  nicht entworfen; die Quellenanzeige in Spalte 3 ist für den späteren Chat wiederverwendbar.
 - Suchbereiche: Vertrag, andere Verträge im PFA per Schalter, andere PFA nur als Hinweis mit EP,
  nie projektübergreifend (A10, A11)
 - Rollen Administrator, Projektleiter, Bearbeiter, Leser. „Kein Zugriff“ verrät nicht, ob es das
  Objekt gibt (A25, AP1).
 - Länderwahl nur bei mehreren Ländern (A26: Österreich in Phase 2)
 - Benachrichtigungen nur in der Anwendung (B3)
 - Ergebnisliste mit Excel-Export; Bewertungsmatrix deaktiviert, bis die Vorlage da ist (OP1)
 **Abweichungen und wie wir sie behandeln** (Vorschlag, bitte bestätigen):
 | Stelle im Prototyp | Widerspricht | Umgang |
 |---|---|---|
 | Projekt anlegen v3 · 2b „Ablage für Dateien oder ZIP mit Ordnern“; Übergabe 6.8 „Upload allgemein … ZIP“ | B4: kein ZIP | Nur Mehrfach-Upload, Text ohne „ZIP“ |
 | Ergebnisliste v2: Export „Stellungnahme (Word)“, deaktiviert; Übergabe 6.8: Export-Vorlage Stellungnahme | A15: Phase 2 | Weglassen |
 | Regeldialog v3: „Freigabe immer durch den Projektleiter“, keine Einstellung | A24-Vorschlag „ohne Freigabe“, Gesamtplan „einstellbare Freigaben“ | Entscheidung E8.1 in AP8 |
 | Projektdetail v2: Reiter nur PFA & Verträge · Nachträge · Berechtigungen · Einstellungen; Übersicht, Dokumente und Protokoll aus Rückmeldung 19 fehlen | – | Prototyp gilt; Protokoll unter Verwaltung (AP1, 1.11). Falls A2 weitere Vertragsunterlagen bringt, braucht es dafür einen Ort |
 | Projektdetail v2 · Einstellungen: nur „Andere Verträge im selben PFA einbeziehen“; „Andere PFAs“ und „Nur gleicher Auftragnehmer“ entfallen | A10 noch offen | Prototyp gilt, bis A10 etwas anderes ergibt; Datenmodell in AP1, 1.4b |
 | Projekt anlegen v3 ohne Vertragsgrundlage | `projekte.vertragsgrundlage` im Datenmodell | Feld bleibt mit Standardwert, nicht im Formular (AP1, 1.4b) |
 | Zielgruppe „nur deutschsprachig“ | Oberfläche Deutsch und Englisch | Kein Widerspruch: Die deutschen Texte werden wörtlich übernommen, Englisch bleibt als Übersetzung |
 | Logo: Wortmarke als Text, „ein finales Logo gibt es noch nicht“ | – | Vorläufig verwenden, vor dem Einsatz in Pfade umwandeln |
 | „Passt / Passt nicht“ aus unserer Rückmeldung (7, 9, 11) | – | In 0.3 ersetzt durch Auswahl der Fundstelle und Ja / Nein; AP6 angepasst |
 Nicht im Paket und auch nicht nötig: die Archivordner „Stand 0.1/0.2“ und die Schriftdateien.
 Wenn die Abweichungen bestätigt sind, geht eine kurze Rückmeldung im Format von Abschnitt 9 an
 Claude Design (ZIP und Stellungnahme entfernen, E8.1).
 ## Abnahmekriterien
 - Die Musterseite entspricht dem Designsystem des Prototyps in Hell und Dunkel.
@@ -74,5 +117,5 @@ Benötigt werden die Übergabe (Abschnitte 1–9) und die `.dc.html`-Dateien. Bi
 ## Risiken
- Claude Design liefert spät. Dann mit dem bisherigen Stand beginnen; die Prüfmaske kommt ohnehin
+- Weitere Stände von Claude Design während der Umsetzung: Nur übernehmen, was im
-  erst in AP6.
+  Änderungsprotokoll der Übergabe (Abschnitt 8) steht, und Tokens zentral halten.
@@ -4,7 +4,7 @@
 |---|---|
 | Status | grob geplant; Umsetzung nur nach Beauftragung und mit Vorlage |
 | Aufwand | je 0,5 PW |
-| Zeitraum | OP1 KW 51, OP2 KW 2/2027 (bei 35–40 h pro Woche), sonst nach M4 |
+| Zeitraum | OP1 KW 51 (bei 35–40 h pro Woche), sonst nach M4. OP2 erst in Phase 2 (A15, 05.10.) |
 | Freigabe | offen |
 ## OP1 – Bewertungsmatrix in der Excel-Vorlage der DB
@@ -21,6 +21,8 @@
 ## OP2 – Stellungnahme BÜW als Word-Datei
 **Vertagt auf Phase 2** (A15, 05.10.). Die Schritte bleiben als Merkposten stehen.
 **Ziel:** Das Deckblatt zur Bewertungsmatrix (Ansprechpartner, Bearbeiter, Nachtrag, Sachverhalt)
 wird aus der Vorlage erzeugt.
@@ -57,7 +57,7 @@ in Arbeit → erledigt.
 | **Du** (Entwicklung, Steuerung) | Planung freigeben, entscheiden, im Browser testen, mit BauIn und ITM sprechen, echte Daten auf Staging testen, pushen. Du schreibst selbst keinen Code. |
 | **Claude Code** | Teilpläne ausarbeiten, den gesamten Code mit Tests schreiben, Doku, Statusberichte entwerfen. Sieht keine echten Kundendaten und keine API-Schlüssel. |
 | **ITM-Entwickler** | KI-API (API-Werk, Modelle, Schlüssel, Grenzen), Aufbau von Staging- und Produktionsserver nach `docs/server-anforderungen.md` |
-| **ITM-Projektleitung** | Projektleitung, Abrechnung, Kostenrahmen für BauIn, Server und Gitea |
+| **ITM-Projektleitung** | Projektleitung, Abrechnung, Kostenrahmen für BauIn, Server und Gitea. Allein Sache von ITM: Preise der KI-API, Datenverarbeitung bei API-Werk, Betrieb und Sicherung der Server (C2, C3, C10) |
 | **Claude Design** | Oberflächenentwürfe (Prototyp, Designsystem); Übergaben im Format seiner Übergabe, Abschnitt 9 |
 | **BauIn – Nachtragsbearbeitung** | Fachliche Fragen, Testdaten, Referenzfälle, Vorlagen, Bewertung im Pilot |
 | **BauIn – IT** | Anmeldung, Zugriff, Domain, Datenschutz und Informationssicherheit |
@@ -74,7 +74,8 @@ Bezugsposition. Der Bearbeiter entscheidet; seine Rückmeldungen verbessern die
 **Enthalten:**
 - Projekte mit PFA (Abschnitten), Verträgen und Auftragnehmern
- Upload von LVs als X86 und PDF, Import der Positionen und Vorbemerkungen
+- Upload von LVs als X86 und PDF (mehrere Dateien auf einmal, kein ZIP), Import der Positionen
  und Vorbemerkungen
 - LV-Suche über Vertrag, PFA oder Projekt mit Sprung ins PDF
 - Nachträge anlegen (Nachtrags-LV, Anschreiben, Anlagen) und Vorprüfung aller Positionen
 - Prüfmaske mit Fundstellen, Bezugsposition, Einschätzung, Begründung, KI-Sicherheit, Feedback
@@ -83,14 +84,14 @@ Bezugsposition. Der Bearbeiter entscheidet; seine Rückmeldungen verbessern die
 - Rollen und Rechte, vertrauliche Dokumente, Protokoll, Deutsch und Englisch
 - Betrieb auf den Servern von ITM: Staging und Produktion, Backups, Alarmierung
-**Optional, wenn Zeit und Vorlagen da sind:** Bewertungsmatrix in der Excel-Vorlage der DB (OP1),
+**Optional, wenn Zeit und Vorlage da sind:** Bewertungsmatrix in der Excel-Vorlage der DB (OP1).
 Stellungnahme BÜW als Word-Datei (OP2).
 **Nicht enthalten** (macht BauIn selbst oder kommt später):
- rechtliche Einordnung, Fristen, § 2 Abs. 8, § 6 Abs. 6, Anordnungen
+- rechtliche Einordnung, Fristen, § 2 Abs. 8, § 6 Abs. 6, Anordnungen (A13)
- Prüfung der Höhe nach (Phase 2)
+- Prüfung der Höhe nach, Stellungnahme BÜW als Word-Datei (A15), Österreich (A26): Phase 2
 - Regelwerk mit Chat (Phase 3)
- DOXIS-Anbindung, Österreich
+- DOXIS-Anbindung (A16: Upload bleibt Handarbeit)
 - E-Mails jeder Art (B3), Anmeldung über das Microsoft-Konto (B1)
 ## 4. Rahmen und Annahmen
@@ -102,15 +103,22 @@ Stellungnahme BÜW als Word-Datei (OP2).
  Es gibt keine Webhooks, Ergebnisse werden abgefragt. Grenzen: 120 Anfragen/min je Schlüssel,
  50 MB je Datei. Einzelheiten in `docs/tech-stack.md`.
 - **Schlüssel:** In der Entwicklung über den Schlüssel-Proxy (`tools/ki-proxy`), in der Anwendung
-  verschlüsselt in der Datenbank, nie in `.env`.
+  verschlüsselt in der Datenbank, nie in `.env`. Es gibt nur Schlüssel für die Produktion (C1):
  Entwicklung, Staging und Produktion teilen sich Zählung, Kosten und das Limit. Automatische
  Tests rufen die echte API deshalb nie auf.
 - **Anmeldung:** eigenes Passwort, 2FA zunächst aus; später wird sie eingeschaltet und ist dann
  Pflicht (B1). Die Anwendung verschickt keine E-Mails (B3), Benachrichtigungen gibt es nur in der
  Anwendung.
 - **Echte Daten:** Entwickelt wird mit öffentlichen bzw. erfundenen GAEB-Dateien und einem
-  anonymisierten Beispielablauf von BauIn. Echte Pilotdaten gibt es nur auf den Servern von ITM
+  anonymisierten Beispielablauf von BauIn. Echte Pilotdaten dürfen auf den Servern von ITM liegen
-  und erst nach der Datenschutzfreigabe (Fragen A19, B6, C2).
+  und über die KI-API verarbeitet werden (A19). Sie gehen weiterhin nie an Claude Code.
 - **Vor dem Livegang zu klären:** Zugriff, Adresse, Backups, Datenschutz und
  Informationssicherheit, 2FA-Pflicht. Liste in AP11, Abschnitt „Vor dem Livegang zu klären“.
 - **Aufwand** in deinen Personenwochen (PW, 40 h) mit Claude Code: Kern rund 11 PW, mit Puffer
-  13–14 PW, die Optionen je 0,5 PW. Ohne KI-Unterstützung wären es rund 23 PW. Beim
+  13–14 PW, die Option OP1 0,5 PW. Ohne KI-Unterstützung wären es rund 23 PW. Beim
  ITM-Entwickler kommen 1–1,5 PW für die Server dazu.
 - **Verfügbarkeit:** rund 30 h pro Woche (≈ 0,75 PW). Bis M4 sind das ≈ 11,25 PW, genau der Kern.
-  Empfehlung: in KW 44–51 auf 35–40 h erhöhen, dann passen die Optionen und etwas Reserve.
+  Empfehlung: in KW 44–51 auf 35–40 h erhöhen, dann passen OP1 und etwas Reserve.
 - **Pause:** KW 52–53 (21.12.2026 – 03.01.2027).
 ## 5. Meilensteine mit Abnahmekriterien
@@ -125,16 +133,17 @@ Stellungnahme BÜW als Word-Datei (OP2).
 | Puffer | KW 5–6/2027 | für Verzögerungen bei Zulieferungen oder Import |
 **M1 – Grundgerüst** (Demo 30 min, lokal oder auf Staging):
- Ein Administrator legt Benutzer an; Anmeldung mit 2FA funktioniert.
+- Ein Administrator legt Benutzer an; Anmeldung mit eigenem Passwort funktioniert, 2FA ist
  einrichtbar und lässt sich als Pflicht einschalten (B1).
 - Ein Projekt wird mit PFA, Verträgen und Mitgliedern angelegt.
- Ein LV-Paket (X86 + PDF) wird hochgeladen; die Paare werden erkannt, das LV wird importiert und
+- Mehrere LV-Dateien (X86 + PDF) werden auf einmal hochgeladen; die Paare werden erkannt, das LV
-  als Baum mit Vorbemerkungen angezeigt.
+  wird importiert und als Baum mit Vorbemerkungen angezeigt.
 - Ein Benutzer ohne Projektrecht sieht nichts davon, auch nicht über eine direkte URL (Tests).
 - Das Protokoll zeigt Uploads und Rechteänderungen; CI ist grün.
- Das Designsystem aus Claude Design ist angewendet.
+- Das Designsystem aus Claude Design (Stand 0.3) ist angewendet.
 **M2 – LV-Suche und erste Vorprüfung** (Prüftermin 60 min, auf Staging):
- Staging bei ITM läuft, der Pilot-PFA ist importiert (nach Datenschutzfreigabe).
+- Staging bei ITM läuft, der Pilot-PFA ist importiert (erlaubt laut A19).
 - Die LV-Suche findet über Vertrag, PFA oder Projekt und springt im PDF an die Stelle.
 - Für die ersten Nachträge liefert die Vorprüfung ohne Sprachmodell Fundstellen je Position.
 - Für mindestens 5 Nachträge ist gemeinsam mit BauIn erfasst, ob die richtige Fundstelle unter
@@ -161,7 +170,7 @@ PW = deine Personenwochen mit Claude Code. Status nach Abschnitt 1.
 | AP | Teilplan | PW | Zeitraum | Status | Hängt ab von |
 |---|---|---|---|---|---|
 | AP0 | [Steuerung, Klärung, Doku](plaene/AP00-steuerung.md) | 0,75 | laufend | in Arbeit | – |
-| AP1 | [Fundament: CI, Rechte, Benutzer, Projekte, Upload, Protokoll](plaene/AP01-fundament.md) | 1,25 | KW 40–43 | in Arbeit; Schritte ab 1.5 warten auf Freigabe | A1, A25, B1 |
+| AP1 | [Fundament: CI, Rechte, Benutzer, Projekte, Upload, Protokoll](plaene/AP01-fundament.md) | 1,25 | KW 40–43 | in Arbeit; Schritte ab 1.5 warten auf Freigabe | A1, A25 |
 | AP2 | [Meilisearch-Test](plaene/AP02-meilisearch-test.md) | 0,25 | KW 41 / KW 46 | detailliert, wartet auf Freigabe | Teil 2: Staging, A20 |
 | AP3 | [Anbindung KI-API ITM](plaene/AP03-ki-api.md) | 0,5 | KW 42–44 | in Arbeit; Schritte ab 3.2 warten auf Freigabe | C1, C4–C8 |
 | AP4 | [Indexierung und LV-Suche](plaene/AP04-indexierung-suche.md) | 1,0 | KW 44–46 | grob geplant | AP2, AP3, AP5, A10 |
@@ -173,9 +182,10 @@ PW = deine Personenwochen mit Claude Code. Status nach Abschnitt 1.
 | AP10 | [Dashboard, Benachrichtigungen, Auswertungen](plaene/AP10-dashboard-auswertungen.md) | 0,5 | KW 47, KW 2 | grob geplant | – |
 | AP11 | [Betrieb (unser Teil und ITM)](plaene/AP11-betrieb.md) | 0,5 (+ ITM 1–1,5) | KW 41–44, 50–51, 3 | in Arbeit | C10, B2, B5 |
 | AP12 | [Pilot und Messung](plaene/AP12-pilot.md) | 1,5 | KW 1–2/2027 | grob geplant | A20, A21 |
-| AP13 | [Designsystem aus Claude Design](plaene/AP13-designsystem.md) | 0,5 | KW 43 | detailliert, wartet auf Freigabe | Stand von Claude Design |
+| AP13 | [Designsystem aus Claude Design](plaene/AP13-designsystem.md) | 0,5 | KW 43 | detailliert, wartet auf Freigabe; Stand 0.3 liegt vor | – |
 | | **Summe Kern** | **≈ 11,25** | | | |
-| OP1/OP2 | [Optionen: Bewertungsmatrix, Stellungnahme](plaene/OP-optionen.md) | je 0,5 | KW 51 / KW 2 | grob geplant | A14, A15 |
+| OP1 | [Option: Bewertungsmatrix](plaene/OP-optionen.md) | 0,5 | KW 51 | grob geplant | A14 |
 | OP2 | [Stellungnahme BÜW](plaene/OP-optionen.md) | – | Phase 2 | vertagt (A15) | – |
 Bereits erledigt (KW 40–41):
 - Entwicklungsumgebung, Grundgerüst mit TallStackUI und Mehrsprachigkeit
@@ -187,20 +197,20 @@ Bereits erledigt (KW 40–41):
 | KW | Datum | Du + Claude Code | ITM-Entwickler | Kunde / gemeinsam |
 |---|---|---|---|---|
 | 40 | 28.09.–04.10. | ✓ Umgebung, Grundgerüst, TallStackUI, Mehrsprachigkeit, Doku | – | ✓ Besprechung BauIn (02.10.) |
-| 41 | 05.–11.10. | ✓ Server-Anforderungen, Schlüssel-Proxy, Datenmodell; Plan und Teilpläne; Freigaben; Meilisearch-Test Teil 1; GAEB-Test; CI; Rechtekonzept | Server-Anforderungen erhalten; Schlüssel | Fragen raus; Rückmeldung an Claude Design |
+| 41 | 05.–11.10. | ✓ Server-Anforderungen, Schlüssel-Proxy, Datenmodell; Plan und Teilpläne; Freigaben; Meilisearch-Test Teil 1; GAEB-Test; CI; Rechtekonzept | Server-Anforderungen erhalten; Schlüssel | ✓ Fragen raus, erste Antworten (05.10.); ✓ Stand 0.3 von Claude Design (05.10.) |
 | 42 | 12.–18.10. | Rechte und Policies; Benutzer- und Projektverwaltung; Upload; KI-API Schnelltest und Einstellungen; Statusbericht | Staging aufbauen | Aufwand an ITM (14.10.); **Termin BauIn 16.10.** |
-| 43 | 19.–25.10. | Antworten einarbeiten, Teilpläne AP4/AP6 detaillieren; GAEB-Import, LV-Ansicht; Protokoll; Designsystem | Staging: Dienste, TLS | neuer Stand von Claude Design |
+| 43 | 19.–25.10. | Antworten einarbeiten, Teilpläne AP4/AP6 detaillieren; GAEB-Import, LV-Ansicht; Protokoll; Designsystem | Staging: Dienste, TLS | – |
 | 44 | 26.10.–01.11. | PDF-Anzeige mit Sprung; KI-Clients und Jobs; Deploy-Vorlagen; erste Bereitstellung | Staging fertig | **M1 Demo 30.10.** |
 | 45 | 02.–08.11. | Indexierung, hybride LV-Suche mit Rechtefilter; Nachtrags-Import | Unterstützung | – |
 | 46 | 09.–15.11. | Suchreihenfolge, LV-Suche-Oberfläche; Vorprüfung Stufe 1; Meilisearch-Test Teil 2 | – | Pilotdaten auf Staging (du) |
-| 47 | 16.–22.11. | Prüfmaske v3 ohne Sprachmodell, Feedback; Dashboard (Teil 1) | – | **M2 Prüftermin 20.11.** |
+| 47 | 16.–22.11. | Prüfmaske v4 ohne Sprachmodell, Feedback; Dashboard (Teil 1) | – | **M2 Prüftermin 20.11.** |
 | 48 | 23.–29.11. | Sprachmodell: Einschätzung, Bezugsposition, strukturierte Antwort | – | – |
 | 49 | 30.11.–06.12. | Begründung mit Quellen; Referenzfälle; Regeln beginnen | – | Demo 04.12. |
 | 50 | 07.–13.12. | Regeln und Freigaben; Ergebnisliste, Excel-Export | Produktionsserver | – |
 | 51 | 14.–20.12. | OP1 Bewertungsmatrix (falls Vorlage und Stunden); Feinschliff | Produktion fertig | **M3 Präsentation 18.12.** |
 | 52–53 | 21.12.–03.01. | Pause | Pause | – |
 | 1 | 04.–10.01. | Pilot: alle Nachträge des Pilot-PFA, messen | – | Fachexperte bewertet |
-| 2 | 11.–17.01. | Nachschärfen; Dashboard, Auswertungen; OP2 Stellungnahme (falls Stunden) | – | Demo 15.01. |
+| 2 | 11.–17.01. | Nachschärfen; Dashboard, Auswertungen | – | Demo 15.01. |
 | 3 | 18.–24.01. | Produktion: Inbetriebnahme, Backups, Alarmierung, Restore-Test | Backups, Restore-Test | – |
 | 4 | 25.–31.01. | Auswertung, Übergabe, Doku | – | **M4 Abschluss 29.01.** |
 | 5–6 | 01.–14.02. | Puffer | Puffer | – |
@@ -210,25 +220,26 @@ Bereits erledigt (KW 40–41):
 | Bis | Von | Was | Für |
 |---|---|---|---|
 | ✓ 02.10. | ITM | API-Dokumentation | AP3 |
-| KW 41 | ITM | API-Schlüssel für die Entwicklung, Antworten Teil C, Preise | AP3, Kostenrahmen |
+| KW 41 | ITM | API-Schlüssel (nur Produktion, C1), Antworten C4–C9 | AP3 |
 | KW 41 | BauIn | Antworten auf die ★-Fragen | Teilpläne |
 | ✓ KW 41 | wir → ITM | Server-Anforderungen (noch verschicken) | AP11 |
-| KW 42 | Claude Design | Neuer Stand nach unserer Rückmeldung: Übergabe und `.dc.html`-Dateien | AP13 |
+| ✓ 05.10. | Claude Design | Stand 0.3 nach unserer Rückmeldung (`claude-design/2026-10-05_Stand-0.3/` im Planungsordner) | AP13 |
-| 16.10. | BauIn | Matrix-Vorlage (leer und ausgefüllt), Word-Vorlage, anonymisierter Beispielablauf | AP5, AP9, OP1, OP2 |
+| 16.10. | BauIn | Matrix-Vorlage (leer und ausgefüllt), anonymisierter Beispielablauf | AP5, AP9, OP1 |
-| KW 43 | BauIn | Entscheidung Rollen, Freigabe-Variante, Anmeldung | AP1, AP8 |
+| KW 43 | BauIn | Entscheidung Rollen, Freigabe-Variante | AP1, AP8 |
-| KW 43 | BauIn, ITM | Datenschutzfreigabe für echte Pilotdaten | M2 |
+| ✓ 05.10. | BauIn | Echte Pilotdaten dürfen bei ITM liegen und über die KI-API laufen (A19); ab wann, ist offen | M2 |
 | KW 44 | ITM | Staging-Server mit Zugang, Domain, Zertifikat | M2 |
 | KW 46 | BauIn | Pilotdaten: alle LVs eines PFA (X86 + PDF), nur auf Staging | M2 |
 | KW 47 | BauIn | 10–20 abgeschlossene Nachträge mit Ergebnis | AP2, AP12 |
 | KW 51 | ITM | Produktionsserver | AP11 |
-| KW 51 | offen | Backups: Ziel, Aufbewahrung, Zuständigkeit | AP11 |
+| vor Livegang | BauIn, ITM | Zugriff, Adresse, Backups, Datenschutz (B2, B3, B5, B6) | AP11 |
 ## 9. Risiken
 | Risiko | Auswirkung | Gegenmaßnahme |
 |---|---|---|
 | Zulieferungen kommen spät | Pakete verschieben sich | Termine am 16.10. vereinbaren; Unabhängiges vorziehen |
-| Datenschutz für echte Daten bleibt offen | Kein realistischer Test, M2 gefährdet | Früh fragen (A19, B6, C2); bis dahin anonymisierte Daten |
+| Vorgaben zu Datenschutz und Informationssicherheit (B6) kommen erst vor dem Livegang | Nacharbeit kurz vor dem Livegang | Grundsätze schon jetzt einhalten (Rechte, Protokoll, alles lokal außer KI-API); Liste in AP11 |
 | Nur Produktionsschlüssel (C1) | Entwicklung und Tests verbrauchen Limit und Kosten der Produktion | Tests mit `Http::fake`, Live-Aufrufe sparsam, Ratenbegrenzer (AP3) |
 | Vibe Coding: Fehler in Rechten oder Suchfiltern fallen nicht auf | Unbefugte sehen vertrauliche Inhalte | Tests ohne Berechtigung sind Pflicht; CI; diese Stellen gezielt im Browser prüfen |
 | Claude Code sieht keine echten Daten | Nachschärfen dauert länger | Messskripte mit Kennzahlen; anonymisierte Problemfälle |
 | Nur eine Person kennt die Anwendung | Ausfall stoppt das Projekt | Doku, Teilpläne, Tests aktuell halten |
@@ -249,6 +260,11 @@ Bereits erledigt (KW 40–41):
 | 05.10. | API-Schlüssel im Windows-Tresor mit Schlüssel-Proxy; in der App verschlüsselt in der DB, nie in `.env` | du, ITM |
 | 05.10. | Projektrollen in eigener Tabelle, globale Rollen über Spatie (Review in AP1, Schritt 1.4) | Claude Code, Freigabe offen |
 | 05.10. | Strukturiertes Vorgehen: nur Umsetzung nach freigegebenem Teilplan | du |
 | 05.10. | Anmeldung mit eigenem Passwort, 2FA später Pflicht (B1); keine E-Mails (B3); Mehrfach-Upload ohne ZIP (B4) | BauIn, du |
 | 05.10. | Anordnungen außen vor (A13), DOXIS von Hand (A16), Stellungnahme BÜW und Österreich in Phase 2 (A15, A26) | BauIn, du |
 | 05.10. | Pilotdaten dürfen bei ITM liegen und über die KI-API laufen (A19); Preise, Datenverarbeitung und Server sind Sache von ITM (C2, C3, C10) | du, ITM |
 | 05.10. | Abgrenzung mit dem ITM-Entwickler wie vorgeschlagen (C12); Gitea von ITM: `https://gitea.itm-technologies.de/ChristophGraf/BauIN` (C11) | ITM |
 | 05.10. | Claude Design Stand 0.3 ist verbindlich für die Oberfläche; Abweichungen stehen in AP13 | du |
 Offene Entscheidungen stehen in den Teilplänen unter „Entscheidungen“.
@@ -257,13 +273,16 @@ Offene Entscheidungen stehen in den Teilplänen unter „Entscheidungen“.
 - **Phase 2 – Prüfung der Höhe nach:**
  - Preis gegen Bezugsposition und gleiche Leistung in anderen PFAs vergleichen.
  - Auszüge der Urkalkulation und Nachtragskalkulation einbeziehen.
  - Ebenfalls Phase 2: Stellungnahme BÜW als Word-Datei (A15), Österreich (A26).
 - **Phase 3 – Regelwerk:**
  - Richtlinien der DB (263 PDFs, 743 MB) in die Suche aufnehmen.
  - Interner Chat, der mit PDF, Seite und Stelle zitiert.
 - **Weitere Ideen:**
  - Dokumentenmanagement, E-Mail- und DOXIS-Anbindung
-  - Österreich (ÖNORM B 2110/B 2118, A 2063)
+  - Österreich im Detail: ÖNORM B 2110/B 2118, A 2063
  - Bauzeitenplan-Analyse, weitere Sprachen
 - **Nach dem Livegang von Phase 1 klären:** Aufbewahrung nach Projektende (A27), Nutzung der
  DB-Richtlinien in einem KI-System (A28).
 - **Nebenprojekt datenschleuse:** Phase 1–2 muss fertig sein, bevor echte Kundendateien mit Claude
  bearbeitet werden. Sie hilft beim anonymisierten Beispielablauf.
@@ -274,3 +293,4 @@ Offene Entscheidungen stehen in den Teilplänen unter „Entscheidungen“.
 | 01.10. | Erster Plan (MVP, 2 Entwickler) |
 | 02.10. | Nach Besprechung mit BauIn: Umfang, Gliederung, Optionen, Ausbaustufen; Team du + Claude Code; 30 h/Woche |
 | 05.10. | Neu gegliedert: Arbeitsweise mit Freigaben, Meilensteine mit Abnahmekriterien, Teilpläne je Arbeitspaket, Fragenliste mit Status in `docs/fragen.md` |
 | 05.10. | Erste Antworten eingearbeitet (B1, B3, B4, C1, A15, A19 u. a.); OP2 in Phase 2; Claude Design Stand 0.3 erhalten, Abgleich in AP13 |
@@ -23,14 +23,14 @@ und benennt, wo KI-BauIN bewusst abweicht und warum.
 | Blade | Templates, Layouts, eigene Komponenten | gleich |
 | Tailwind CSS 4 | Gestaltung | gleich |
 | TallStackUI 4 (Präfix `ts-`) | UI-Komponenten | Version abweichend (Referenz: 3) |
-| Laravel Fortify | Login, Passwort-Reset, E-Mail-Bestätigung, 2FA, Passkeys | ergänzt |
+| Laravel Fortify | Login, 2FA, Passkeys; ohne E-Mail-Funktionen (keine E-Mails laut BauIn) | ergänzt |
 | Mehrsprachigkeit | Deutsch (Standard) und Englisch, Sprache je Benutzer; Übersetzungen über Laravel Lang (nur Entwicklung), eigene Texte in `lang/project/` | ergänzt |
 | Vite 8, Node.js/npm | Asset-Build | gleich |
 | Composer | Abhängigkeiten mit Lockfile | gleich |
 | GAEB-Import | LVs und Nachtrags-LVs aus GAEB DA XML (X86); D86 nur als Rückfall | ergänzt |
 | pdf.js (lokal ausgeliefert, kein CDN) | Anzeige der LV- und Nachtrags-PDFs mit Sprung zur Fundstelle | ergänzt |
 | PhpSpreadsheet | Ergebnisliste als Excel; Option: Bewertungsmatrix in der Vorlage der DB | geplant |
-| PHPWord | Option: Stellungnahme aus Word-Vorlage (nur .docx) | Option |
+| PHPWord | Stellungnahme aus Word-Vorlage (nur .docx) | Phase 2 |
 | Dompdf | PDF-Erzeugung | vorerst nicht nötig |
 Aufbau als modularer Laravel-Monolith: Livewire-Komponenten für die Interaktion, Services für
@@ -59,7 +59,7 @@ Redis wird nicht eingesetzt: Warteschlange, Cache und Sessions laufen über die
 |---|---|---|
 | Anmeldung | Fortify, serverseitige Sitzungen; keine Selbstregistrierung | gleich |
 | Rollen und Rechte | Spatie laravel-permission | gleich |
-| 2FA | TOTP über Fortify (intern Google2FA), Wiederherstellungscodes | gleich; Pflicht für alle noch offen |
+| 2FA | TOTP über Fortify (intern Google2FA), Wiederherstellungscodes | gleich; zunächst freiwillig, später Pflicht per Schalter |
 | Passkeys | WebAuthn über Fortify | ergänzt |
 | API-Authentifizierung | – | Sanctum vorerst nicht nötig (keine eigene API) |
 | Verschlüsselung sensibler Werte | Verschlüsselte Casts, u. a. für Zugangsdaten der KI-API | gleich |
@@ -83,7 +83,7 @@ oder Prompts in technischen Logs.
 | Tests | Pest 4 auf PHPUnit 12; Tests im PHPUnit-Klassenstil | gleich (Runner ergänzt) |
 | Code-Stil | Laravel Pint | gleich |
 | Statische Analyse | PHPStan/Larastan Stufe 7 | ergänzt |
-| Versionsverwaltung | Git, Gitea (lokal führend, Gitea von ITM als Push-Mirror) | gleich |
+| Versionsverwaltung | Git, Gitea (lokal führend; Push-Mirror nach `https://gitea.itm-technologies.de/ChristophGraf/BauIN`) | gleich |
 ## 5. Betrieb (Produktion, geplant)
@@ -95,8 +95,9 @@ PHP, MySQL und Meilisearch sind in Entwicklung und Produktion gleich.
 Ergänzt bzw. anders als in der Referenz:
- **Externe Alarmierung von Anfang an** (z. B. Mail), wenn Worker oder Scheduler ausfallen,
+- **Externe Alarmierung von Anfang an**, wenn Worker oder Scheduler ausfallen, Jobs fehlschlagen
-  Jobs fehlschlagen oder die KI-API ITM nicht erreichbar ist.
+  oder die KI-API ITM nicht erreichbar ist. Die Anwendung verschickt keine E-Mails; der Weg wird
  mit ITM abgestimmt (AP11, E11.3).
 - **Backups verschlüsselt**, bevor sie den Server verlassen (z. B. restic). Speicherort,
  Aufbewahrungsdauer und Zuständigkeit sind noch offen. Gesichert werden Datenbank, private Uploads und
  Konfiguration; der Meilisearch-Index nicht, er wird aus MySQL neu aufgebaut.
@@ -115,13 +116,14 @@ Ergänzt bzw. anders als in der Referenz:
 ## 7. Offene Punkte
- Ist 2FA für alle Benutzer Pflicht?
+Vor dem Livegang zu klären (Liste in `docs/plaene/AP11-betrieb.md`): Zugriff, Adresse, Backups,
- Verlangen BauIn oder ITM eine Festplattenverschlüsselung auf den Servern bei ITM?
+Datenschutz und Informationssicherheit, Einschalten der 2FA-Pflicht. Server, Verschlüsselung und
- Backups: Speicherort, Aufbewahrungsdauer und wer dafür zuständig ist.
+Datenverarbeitung bei API-Werk sind Sache von ITM.
 - Weitere Sprachen über Deutsch und Englisch hinaus (technisch vorbereitet, fachlich nicht angefragt).
- Datenschutz der KI-API: Standort von API-Werk und KI-Server, Auftragsverarbeitung, Aufbewahrung
+
-  hochgeladener Dokumente und Ergebnisse.
+Geklärt am 05.10.: eigenes Passwort statt Microsoft-Konto, 2FA zunächst freiwillig und später
- Anmeldung mit eigenem Passwort und 2FA oder mit dem Microsoft-Konto von BauIn.
+Pflicht, keine E-Mails, nur Schlüssel für die Produktion.
 ## Architekturübersicht