Detaillierter Projektplan mit Teilplänen und Fragenliste

- docs/projektplan.md neu gegliedert: Arbeitsweise mit Freigaben, Zuständigkeiten,
  Meilensteine mit Abnahmekriterien, Arbeitspakete mit Status, Zeitplan, Entscheidungen
- docs/plaene/: Teilplan je Arbeitspaket (detailliert für AP0, AP1, AP2, AP3, AP5, AP11,
  AP13; grob für AP4, AP6–AP10, AP12, Optionen) und Vorlage
- docs/fragen.md: alle offenen Fragen mit Status, Empfänger und betroffenem Teilplan
- CLAUDE.md: Umsetzung nur nach freigegebenem Teilplan

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

CLAUDE.md

@@ -21,6 +21,15 @@ wird nicht umgangen.
 
 ## Arbeitsweise
 
+**Erst Plan, dann Umsetzung.** Umgesetzt wird nur, was in einem freigegebenen Teilplan unter
+`docs/plaene/` steht (Status „freigegeben“ oder „in Arbeit“). Ablauf und Definition of Done stehen
+in `docs/projektplan.md`, Abschnitt 1.
+- Vor Beginn eines Arbeitspakets den Teilplan detaillieren und die Freigabe abwarten.
+- Commits nennen den Schritt, z. B. „AP1 Schritt 1.7: …“, und der Teilplan wird abgehakt.
+- Neue Erkenntnisse, Antworten und Wünsche zuerst in `docs/fragen.md` bzw. den Teilplan, dann in
+  den Code. Ideen außerhalb des Plans nicht umsetzen, sondern im Gesamtplan unter „Nach Phase 1“
+  notieren.
+
 Das Projekt entsteht per Vibe Coding: Claude Code schreibt den Code, der Entwickler steuert,
 testet im Browser und liest nicht jede Zeile. Deshalb:
 
@@ -31,7 +40,7 @@ testet im Browser und liest nicht jede Zeile. Deshalb:
 - Kleine Schritte, je ein Commit mit verständlicher Nachricht.
 - Änderungen an Rechten, Dateizugriff, Suchfilter oder KI-Aufrufen in der Antwort ausdrücklich
   benennen, damit sie gezielt geprüft werden.
-- Bei fachlichen Unklarheiten nachfragen statt raten; offene Punkte stehen in `docs/projektplan.md`.
+- Bei fachlichen Unklarheiten nachfragen statt raten; offene Fragen stehen in `docs/fragen.md`.
 
 ## Harte Vorgaben
 

docs/fragen.md

@@ -0,0 +1,411 @@
+# KI-BauIN – Offene Fragen
+
+Hauptliste aller offenen Fragen mit Status. Die Dateien zum Verschicken (je Empfänger) liegen im
+Planungsordner und werden aus dieser Liste erzeugt.
+
+- **Status:** offen → gestellt (Datum) → beantwortet (Datum, Antwort) oder vertagt (Grund)
+- **★** = vor dem Termin am 16.10. bzw. vor Beginn des betroffenen Arbeitspakets nötig
+- **betrifft** = Teilplan unter `docs/plaene/`
+- Kommt eine Antwort, wird sie hier eingetragen. Danach werden die betroffenen Teilpläne angepasst
+  (Teilplan AP0, Schritt 0.9).
+
+## Übersicht
+
+| ID | Thema | ★ | an | betrifft | Status |
+|---|---|---|---|---|---|
+| A1 | Gliederung Projekt → PFA → Vertrag → LVs | ★ | BauIn fachlich | AP1, Datenmodell | offen |
+| A2 | Weitere Vertragsunterlagen im „Topf“ | ★ | BauIn fachlich | AP4, AP5 | offen |
+| A3 | Vorbemerkungen in X86 oder eigene PDFs | ★ | BauIn fachlich | AP5 | offen |
+| A4 | Beauftragte Nachträge mit durchsuchen | ★ | BauIn fachlich | AP4, Datenmodell | offen |
+| A5 | Nachtrags-LV immer als X86/D86 | ★ | BauIn fachlich | AP5 | offen |
+| A6 | Bezugsposition im Nachtrag genannt | | BauIn fachlich | AP7 | offen |
+| A7 | Benötigte Teile eines Nachtrags | | BauIn fachlich | AP5 | offen |
+| A8 | MKA nur als Bezugsnummer | | BauIn fachlich | Datenmodell | offen |
+| A9 | Ergebnis je Nachtragsposition, Werte | ★ | BauIn fachlich | AP6, AP9 | offen |
+| A10 | Suchreihenfolge | ★ | BauIn fachlich | AP4 | offen |
+| A11 | Treffer in anderem PFA mit EP anzeigen | | BauIn fachlich | AP6 | offen |
+| A12 | Geändert/zusätzlich vorschlagen | | BauIn fachlich | AP7 | offen |
+| A13 | Anordnungen außen vor | | BauIn fachlich | – | offen |
+| A14 | Bewertungsmatrix (Vorlage, Spalten, Makros) | ★ | BauIn fachlich | AP9, OP1 | offen |
+| A15 | Stellungnahme BÜW (Vorlage) | | BauIn fachlich | OP2 | offen |
+| A16 | DOXIS bleibt Handarbeit | | BauIn fachlich | – | offen |
+| A17 | Mengengerüst Pilot | ★ | BauIn fachlich | AP2, AP11 | offen |
+| A18 | Anonymisierter Beispielablauf | ★ | BauIn fachlich | AP5 | offen |
+| A19 | Echte Pilotdaten bei ITM und über die KI-API | ★ | BauIn fachlich | M2 | offen |
+| A20 | Referenzfälle | | BauIn fachlich | AP2, AP12 | offen |
+| A21 | Erfolgskriterium | | BauIn fachlich | AP12 | offen |
+| A22 | Anzahl Nutzer | | BauIn fachlich | AP1 | offen |
+| A23 | Regeln projektübergreifend | | BauIn fachlich | AP8 | offen |
+| A24 | Freigabe von Regeln | | BauIn fachlich | AP8 | offen |
+| A25 | Rollen und Rechtevergabe | ★ | BauIn fachlich | AP1 | offen |
+| A26 | Österreich | | BauIn fachlich | – | offen |
+| A27 | Aufbewahrung nach Projektende | | BauIn fachlich | AP11 | offen |
+| A28 | DB-Richtlinien in KI-System (Phase 3) | | BauIn fachlich | Phase 3 | offen |
+| B1 | Anmeldung: Microsoft-Konto oder Passwort + 2FA | ★ | BauIn IT | AP1 | offen |
+| B2 | Zugriff: Internet oder VPN | ★ | BauIn IT | AP11 | offen |
+| B3 | Domain und E-Mail | | BauIn IT | AP10, AP11 | offen |
+| B4 | Ordnerstruktur für ZIP-Upload | | BauIn IT | AP1 | offen |
+| B5 | Backups | | BauIn IT | AP11 | offen |
+| B6 | Datenschutz und Informationssicherheit | ★ | BauIn IT | M2 | offen |
+| C1 | Schlüssel je Umgebung, Termin | ★ | ITM | AP3 | offen |
+| C2 | Datenverarbeitung bei API-Werk | ★ | ITM | M2 | offen |
+| C3 | Preise für den Kostenrahmen | ★ | ITM | AP0 | offen |
+| C4 | `embed`: Modell, Dimension, Grenzen | | ITM | AP3, AP4 | offen |
+| C5 | `rerank`: Modell, Grenzen | | ITM | AP3, AP4 | offen |
+| C6 | `chat`: Modell, Kontext, JSON-Ausgabe | | ITM | AP7 | offen |
+| C7 | Dokumentdienst: JSON, Dateitypen | | ITM | AP3, AP5 | offen |
+| C8 | Last und Vorrang | | ITM | AP3 | offen |
+| C9 | Verfügbarkeit | | ITM | AP11 | offen |
+| C10 | Server: Ausstattung, Zugang | | ITM | AP11 | offen |
+| C11 | Gitea und Rechte am Code | | ITM | AP0 | offen |
+| C12 | Abgrenzung mit dem ITM-Entwickler | ★ | ITM | AP3, AP7, AP11 | offen |
+| C13 | „Datentresor“ bestätigen | | ITM | AP3 | offen |
+| 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 |
+
+---
+
+## Teil A – BauIn, Nachtragsbearbeitung (fachlich)
+
+### A1 ★ Gliederung
+Wir haben verstanden: Projekt → PFA (Planfeststellungsabschnitt) → Vertrag mit einem
+Auftragnehmer (je PFA mehrere, z. B. ARGE, Tunnelbau, Oberleitung) → mehrere LVs (im PFA 4 z. B.
+28). Stimmt das? Ist ein Vertrag das, was ihr „Los“ nennt? Gibt es Projekte ohne PFA?
+*Antwort:* –
+
+### A2 ★ Was gehört in den „Topf“ eines Vertrags?
+Nur die LVs mit Vorbemerkungen, oder auch weitere Vertragsunterlagen? Gemeint sind z. B.
+Besondere oder Zusätzliche Vertragsbedingungen, technische Vertragsbedingungen, Baubeschreibung,
+Pläne und Verhandlungsprotokolle. Wenn ja: in welcher Form (digitales PDF, Scan)?
+*Antwort:* –
+
+### A3 ★ Vorbemerkungen
+Stehen sie in den X86-Dateien mit drin, oder liegen sie als eigene PDFs vor?
+*Antwort:* –
+
+### A4 ★ Bereits beauftragte Nachträge
+Gehören sie zum Bau-Soll und sollen mit durchsucht werden? Sonst würde nicht auffallen, wenn ein
+neuer Nachtrag eine Leistung verlangt, die schon über einen früheren Nachtrag beauftragt ist.
+*Antwort:* –
+
+### A5 ★ Nachtrags-LV
+Gibt es das immer als X86/D86, oder manchmal nur als PDF?
+*Antwort:* –
+
+### A6 Bezug auf die Hauptvertragsposition
+Nennt der Auftragnehmer bei geänderten Leistungen die Hauptvertragsposition, auf die er sich
+bezieht? Das könnte z. B. eine OZ im Langtext, in der Kalkulation oder im Anschreiben sein. Dann
+prüft das System diesen Bezug, statt ihn nur zu suchen.
+*Antwort:* –
+
+### A7 Benötigte Teile eines Nachtrags
+Vorschlag: Für die Prüfung dem Grunde nach liest das System das Nachtrags-LV und das Anschreiben
+(Sachverhalt). Kalkulation und Preisnachweise werden nur abgelegt und erst in Phase 2 ausgewertet.
+Passt das?
+*Antwort:* –
+
+### A8 MKA
+Vorschlag: Am Nachtrag wird nur die MKA-Nummer vermerkt (auch mehrere), die MKA selbst wird nicht
+geprüft. Passt das, oder sollen MKAs mit Dokument im System liegen?
+*Antwort:* –
+
+### A9 ★ Ergebnis je Nachtragsposition
+Vorschlag: Die KI liefert:
+- „Im Vertrag enthalten: ja / teilweise / nein / unklar“
+- die Fundstellen (LV, OZ oder Vorbemerkung, mit Sprung ins PDF)
+- eine kurze Begründung
+- bei geänderter Leistung die Bezugsposition und den Unterschied, z. B. „Schwelle B70“ im LV,
+  „Schwelle B70 besohlt“ im Nachtrag
+
+Das Prüfergebnis (dem Grunde nach berechtigt / nicht berechtigt / teilweise) setzt der Bearbeiter.
+Passt das? Welche Werte verwendet ihr in der Matrix?
+*Antwort:* –
+
+### A10 ★ Suchreihenfolge
+1. LVs des betroffenen Vertrags.
+2. Übrige Verträge im selben PFA? Etwa wenn die Leistung schon an einen anderen Auftragnehmer
+   vergeben ist.
+3. Andere PFAs desselben Projekts als Hinweis. Nur beim selben Auftragnehmer oder bei allen?
+
+Andere Projekte nie. Richtig so?
+*Antwort:* –
+
+### A11 Treffer in einem anderen PFA (Beispiel PFA 3/4)
+Vorschlag: Das System zeigt die Fundstelle mit Auftragnehmer und Einheitspreis als Hinweis an,
+ohne den Preis zu bewerten. Die Preisprüfung kommt in Phase 2. Gewünscht?
+*Antwort:* –
+
+### A12 Geändert oder zusätzlich
+Soll die KI vorschlagen, ob eine geänderte (§ 2 Abs. 5) oder eine zusätzliche Leistung (§ 2 Abs. 6)
+vorliegt? Das ergibt sich fast von selbst: Ist eine Bezugsposition gefunden, ist die Leistung
+geändert. Die rechtliche Einordnung macht aber BauIn. Also weglassen oder als Hinweis zeigen?
+*Antwort:* –
+
+### 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:* –
+
+### A14 ★ Bewertungsmatrix
+Bitte die leere Vorlage und 2–3 ausgefüllte Matrizen schicken.
+- Welche Spalten und Reiter füllt ihr bei der Prüfung dem Grunde nach aus?
+- Ist es eine Vorlage der DB mit Makro (D86-Import, Datei .xlsm)?
+- Ändert die DB die Vorlage gelegentlich?
+
+*Antwort:* –
+
+### A15 Stellungnahme BÜW
+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:* –
+
+### A16 DOXIS
+Vorschlag: Ergebnis und Stellungnahme lädt der Bearbeiter weiter von Hand in DOXIS hoch, ohne
+Anbindung in Phase 1. Einverstanden?
+*Antwort:* –
+
+### A17 ★ Mengengerüst Pilot
+- Anzahl Verträge und LVs je PFA
+- Ungefähre Zahl der Positionen je LV, Größe der X86- und PDF-Dateien
+- Wie viele Nachträge kommen pro Monat, mit wie vielen Positionen?
+
+Wir brauchen das für Server, API-Kosten und den Kostenrahmen.
+*Antwort:* –
+
+### A18 ★ Anonymisierter Beispielablauf
+Gewünscht sind ein Vertrag mit 2–3 LVs (X86 + PDF), 2–3 Nachträge mit Nachtrags-LV und Anschreiben
+sowie die ausgefüllte Matrix. Firmen, Namen und Bankdaten dürfen ersetzt oder geschwärzt sein.
+- Bis wann geht das?
+- Was darf auf keinen Fall in Entwicklungswerkzeuge gelangen?
+
+*Antwort:* –
+
+### A19 ★ Echte Pilotdaten
+- Dürfen die Pilotdaten auf den Servern von ITM liegen und über die KI-API von ITM verarbeitet werden?
+- Muss die DB zustimmen, z. B. wegen Geheimhaltungspflichten aus eurem Vertrag mit der DB?
+- Ab wann ginge das?
+
+*Antwort:* –
+
+### A20 Referenzfälle
+Bitte 10–20 abgeschlossene Nachträge mit eurem Ergebnis, damit wir die Trefferquote messen können.
+*Antwort:* –
+
+### A21 Erfolg
+Vorschlag: Bei mindestens 80 % der Nachtragspositionen steht die richtige Fundstelle unter den
+ersten drei Treffern, und die Prüfzeit je Nachtrag halbiert sich. Wie lange dauert ein Nachtrag
+heute, LV-Suche und Matrix zusammen?
+*Antwort:* –
+
+### A22 Nutzer
+Wie viele Bearbeiter arbeiten mit dem System? Wer gibt Rückmeldung zu den KI-Vorschlägen?
+*Antwort:* –
+
+### A23 Regeln aus Korrekturen
+Sollen Regeln aus Korrekturen auch projektübergreifend gelten dürfen? Ein Beispiel wäre
+„Besohlung ist in einer Standard-Schwellenposition nicht enthalten“. Oder strikt je Projekt?
+Für LVs habt ihr gesagt: nie projektübergreifend.
+*Antwort:* –
+
+### A24 Freigabe von Regeln
+Vorschlag bei wenigen Nutzern: „Ohne Freigabe“, alles wird protokolliert. Später lässt sich auf
+„Abgestuft“ oder „Streng“ umstellen. Einverstanden?
+*Antwort:* –
+
+### A25 ★ Rollen
+Vorschlag:
+- Rollen: Administrator, Projektleiter, Bearbeiter, Leser, dazu optional ein Regelverantwortlicher
+- Rechte je Projekt; vertrauliche Einzeldokumente nur für benannte Personen
+- Der Administrator sieht Projektinhalte nur, wenn er Projektmitglied ist
+
+Passt das? Wer vergibt die Rechte?
+*Antwort:* –
+
+### A26 Österreich
+Ist Österreich noch ein Thema, und wenn ja, wann?
+*Antwort:* –
+
+### A27 Aufbewahrung
+Das Pilotprojekt läuft bis etwa 2032. Was passiert danach mit den Daten (archivieren, löschen,
+Fristen)?
+*Antwort:* –
+
+### A28 Phase 3, nicht eilig
+Dürfen die Richtlinien der DB nach den Nutzungsbedingungen eures Regelwerk-Bezugs in ein
+KI-System übernommen werden?
+*Antwort:* –
+
+---
+
+## Teil B – BauIn, IT
+
+### 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:* –
+
+### 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:* –
+
+### B3 Domain und E-Mail
+Unter welcher Adresse soll die Anwendung laufen? Sollen Benachrichtigungen per E-Mail kommen, und
+von welchem Absender?
+*Antwort:* –
+
+### 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:* –
+
+### B5 Backups
+Welche Anforderungen gibt es an Aufbewahrung und Speicherort? Wer ist zuständig (mit ITM klären)?
+*Antwort:* –
+
+### 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:* –
+
+---
+
+## Teil C – ITM / API-Werk
+
+### 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:* –
+
+### C2 ★ Datenverarbeitung
+- Wo laufen api-werk.de, der Extractor und der KI-Server (Land, Rechenzentrum, eigene Hardware)?
+- Die Doku erwähnt zettellos.ai: Sieht ein Dritter die Dokumente?
+- Wie lange werden hochgeladene PDFs, Ergebnisse, Prompts und Logs gespeichert? Lässt sich ein
+  Auftrag löschen?
+- Gibt es einen Vertrag zur Auftragsverarbeitung? Werden Daten zum Training genutzt?
+
+*Antwort:* –
+
+### 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:* –
+
+### C4 `embed`
+- Welches Modell steckt dahinter (Qwen3-Embedding-8B?), mit welcher Dimension (4.096?)?
+  Sind die Vektoren normalisiert?
+- Wie viele Tokens je Text und wie viele Texte je Anfrage sind möglich?
+- Ergänzt die API bei Suchanfragen die Anweisung („Instruct: …“), oder machen wir das?
+- Wie erfahren wir, wenn sich das Modell hinter dem Alias ändert?
+
+*Antwort:* –
+
+### C5 `rerank`
+Welches Modell steckt dahinter? Wie viele Dokumente je Anfrage sind möglich, und wie lang darf ein
+Dokument sein?
+*Antwort:* –
+
+### C6 `chat` und `chat-noreasoning`
+- Welche Modelle stecken dahinter?
+- Wie lang ist der Kontext (128K?) einschließlich Ausgabe, und wie lang darf die Ausgabe sein?
+- Gibt es strukturierte Ausgabe (`response_format` mit JSON-Schema) oder Tool-Aufrufe?
+- Lassen sich `temperature` und `seed` setzen?
+- Was ist mit „Ziel 1 Milliarde“ aus der Besprechung gemeint, und ab wann?
+
+*Antwort:* –
+
+### C7 Dokumentdienst
+- Wie sieht die JSON-Ausgabe aus (Seitenzahlen, Tabellen, Koordinaten)?
+- Welche Dateitypen gehen außer PDF?
+- Gibt es eine maximale Seitenzahl?
+- Wie lange bleiben Aufträge abrufbar?
+
+*Antwort:* –
+
+### C8 Last und Vorrang
+Die 120 Anfragen pro Minute je Schlüssel gelten für alle Nutzer gemeinsam. Können interaktive
+Suchanfragen Vorrang vor dem Einlesen großer Mengen bekommen, z. B. über getrennte Schlüssel?
+Lässt sich das Limit für die Erstindexierung zeitweise erhöhen?
+*Antwort:* –
+
+### C9 Verfügbarkeit
+Gibt es Wartungsfenster und eine Statusseite? Wer ist Ansprechpartner bei Störungen?
+*Antwort:* –
+
+### C10 Server für Staging und Produktion
+- Ausstattung und Betriebssystem, siehe `docs/server-anforderungen.md`
+- Wer hat Root-Zugang? Ist die Festplatte verschlüsselt? Wie läuft die Verbindung zu api-werk.de?
+- Wie werden die Server gesichert?
+
+*Antwort:* –
+
+### C11 Gitea
+Wie lautet die Adresse für den Push-Mirror? Wem gehört der Code, und wer hat welche
+Nutzungsrechte?
+*Antwort:* –
+
+### C12 ★ Abgrenzung mit dem ITM-Entwickler
+Vorschlag:
+- Er betreut die KI-API und baut die Server für Staging und Produktion nach unseren Vorgaben.
+- Wir bauen die gesamte Anwendung, einschließlich API-Anbindung, Indexierung, Suche, Prompts und
+  Prüflogik.
+- Er berät zu Modellen, Grenzen und Prompts.
+
+Passt das? Wie viel Zeit hat er für das Projekt, und wer übernimmt Deployment und Updates im
+Betrieb?
+*Antwort:* –
+
+### 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:* –
+
+---
+
+## Teil D – intern (du)
+
+### D2 ★ Aufwand für den Kostenrahmen
+Ist der Aufwand an die ITM-Projektleitung gegangen? Zahlen: Kern etwa 11 PW mit Claude Code,
+mit Puffer 13–14 PW, Optionen je 0,5 PW, dazu 1–1,5 PW des ITM-Entwicklers.
+*Antwort:* –
+
+### D3 datenschleuse
+Wie ist der Stand? Sie hilft beim anonymisierten Beispielablauf.
+*Antwort:* –
+
+### D4 Freitagstermine
+Vorschlag: 16.10., 30.10. (M1), 20.11. (M2), 04.12., 18.12. (M3), 15.01., 29.01. (M4). Passt das?
+*Antwort:* –
+
+### D5 ★ Actions-Runner
+Läuft auf dem Synology-Gitea schon ein Actions-Runner? Wenn nicht, schreibt Claude Code ein
+Einrichtungsskript.
+*Antwort:* –
+
+### 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:* –
+
+---
+
+## Bereits beantwortet
+
+- **Format der LVs:** X86, D86 und PDF, immer alle drei, aus dem Kalkulationsprogramm (02.10.)
+- **Ablauf bei BauIn:** in der Besprechung am Bildschirm gezeigt (02.10.)
+- **Sprachmodell:** vorhanden (`chat`, `chat-noreasoning`), Kontext laut ITM 128K (02.10.)
+- **API-Dokumentation:** liegt vor. Keine Webhooks, 120 Anfragen/min, 50 MB je Datei (02.10.)
+- **Ansprechpartner:** fachlich die Nachtragsbearbeitung, IT eine eigene Ansprechpartnerin;
+  Teams, Termine freitags (02.10.)
+- **Prüfung der Höhe nach:** Phase 2; bei der DB prüft der Einkauf mit der versiegelten
+  Urkalkulation (02.10.)
+- **Server:** stellt ITM (02.10.)
+- **D1 Team:** du + Claude Code (Vibe Coding), ITM-Entwickler für KI-API und Server; du arbeitest
+  rund 30 h pro Woche, erhöhbar (02.10.)

docs/plaene/AP00-steuerung.md

@@ -0,0 +1,65 @@
+# AP0 – Steuerung, Klärung, Doku
+
+| | |
+|---|---|
+| Status | in Arbeit |
+| Aufwand | 0,75 PW, laufend |
+| Zeitraum | KW 40 – KW 4/2027 |
+| Meilenstein | alle |
+| Freigabe | – (laufende Aufgabe) |
+
+## Ziel
+
+Offene Fragen werden geklärt, Plan und Doku sind aktuell, und BauIn und ITM wissen zu jedem
+Termin, wo das Projekt steht.
+
+## Umfang
+
+**Enthalten:**
+- Fragen stellen und Antworten einpflegen
+- Statusberichte und Termine mit BauIn
+- Gesamtplan, Teilpläne und Doku pflegen
+- Abstimmung mit ITM und Claude Design
+
+**Nicht enthalten:** Umsetzung, die steht in den übrigen Arbeitspaketen.
+
+## Voraussetzungen
+
+Keine.
+
+## Schritte
+
+- [x] **0.1** Besprechung mit BauIn ausgewertet, API-Doku gelesen → Plan vom 02.10.
+- [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):
+  - Teil A an die Nachtragsbearbeitung von BauIn
+  - Teil B an die IT von BauIn
+  - Teil C an die ITM-Projektleitung
+
+  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
+  → Ordner `claude-design/` im Planungsordner
+- [ ] **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
+  → `docs/status/2026-10-16.md`
+- [ ] **0.9** Termin 16.10. durchführen (du); Antworten in `docs/fragen.md` eintragen, betroffene
+  Teilpläne und Datenmodell anpassen (Claude Code, KW 42–43) → aktualisierte Pläne zur Freigabe
+- [ ] **0.10** Laufend:
+  - Teilplan spätestens eine Woche vor Start detaillieren
+  - Statusbericht vor jedem Freitagstermin
+  - Änderungsprotokoll des Gesamtplans pflegen
+
+## Abnahmekriterien
+
+- Alle ★-Fragen sind beantwortet oder bewusst vertagt.
+- Der Plan entspricht vor jedem Termin dem tatsächlichen Stand.
+
+## Risiken
+
+- Antworten kommen spät. Dann mit dem Vorschlag aus der Frage weiterarbeiten und das im Plan
+  vermerken.

docs/plaene/AP01-fundament.md

@@ -0,0 +1,126 @@
+# AP1 – Fundament: CI, Rechte, Benutzer, Projekte, Upload, Protokoll
+
+| | |
+|---|---|
+| Status | in Arbeit; Schritte ab 1.5 detailliert, warten auf Freigabe |
+| Aufwand | 1,25 PW offen (mit Claude Code) |
+| Zeitraum | KW 40–43 |
+| Meilenstein | M1 (30.10.) |
+| Freigabe | offen |
+
+## Ziel
+
+Benutzer melden sich an, sehen nur die Projekte, in denen sie Mitglied sind, legen Projekte mit
+PFA und Verträgen an und laden LV-Pakete hoch. Jede wichtige Aktion wird protokolliert.
+
+## Umfang
+
+**Enthalten:**
+- CI
+- Rechtekonzept und Policies
+- Benutzerverwaltung
+- Projektverwaltung (Projekt, PFA, Verträge, Auftragnehmer, Mitglieder)
+- Upload und Download im privaten Speicher, auch als ZIP
+- Protokoll
+- Länderstruktur
+
+**Nicht enthalten:**
+- GAEB-Import (AP5)
+- Anmeldung mit dem Microsoft-Konto (erst nach Antwort B1, eigener Schritt)
+- 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)
+- D5 (Actions-Runner auf dem Synology-Gitea)
+
+## Entscheidungen
+
+| Nr. | Frage | Vorschlag | Entschieden |
+|---|---|---|---|
+| 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.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) |
+
+## Schritte
+
+- [x] **1.1** Entwicklungsumgebung, Repository, gitleaks-Hook
+- [x] **1.2** Laravel 13, Livewire 4, TallStackUI 4, Fortify (2FA, Passkeys), Spatie,
+  Mehrsprachigkeit
+- [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.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`),
+    PHPStan, Proxy-Tests und gitleaks.
+
+  → Ergebnis: Jeder Push zeigt grün oder rot.
+- [ ] **1.6** Rechtekonzept `docs/rechte.md` → Ergebnis: Rechte-Matrix zur Freigabe durch dich (vorläufig bis A25):
+  - Rollen: global Administrator (optional Regelverantwortlicher); je Projekt Projektleiter,
+    Bearbeiter, Leser
+  - Matrix Aktion × Rolle: Projekt sehen, anlegen, bearbeiten, archivieren; Mitglieder verwalten;
+    Dokumente hochladen, sehen, herunterladen; vertrauliche Dokumente; Nachträge anlegen,
+    zuweisen, prüfen; Export; Regeln vorschlagen und freigeben; Verwaltung
+  - Mandantentrennung und Regeln für archivierte Projekte (nur lesen)
+- [ ] **1.7** Policies und Gates nach dem Rechtekonzept:
+  - zentrale Abfrage „Projekte des Benutzers“
+  - Mandanten-Scope
+  - vertrauliche Dokumente nur für freigegebene Personen
+
+  → 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)
+  - Globale Rolle, Mandant, 2FA-Status
+
+  → Ergebnis: Verwaltung → Benutzer.
+- [ ] **1.9** Projektverwaltung:
+  - Projektliste
+  - Projekt anlegen in drei Schritten wie im Claude-Design-Entwurf: Projektdaten, PFA und Verträge
+    mit Auftragnehmern, Mitglieder
+  - 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
+  - Paarbildung PDF, X86, D86 nach Dateinamen; Zuordnung zu PFA und Vertrag zum Bestätigen
+  - Prüfung von Dateityp und Größe, Erkennung von Duplikaten (sha256)
+  - Download nur über eine Route mit Rechteprüfung
+
+  → Ergebnis: LV-Paket hochladen, LVs als Datensätze mit Dokumenten.
+- [ ] **1.11** Protokoll (E1.2):
+  - Anmeldung (Erfolg und Fehlschlag)
+  - Benutzer- und Rechteänderungen
+  - Projektänderungen
+  - Upload, Löschen, Herunterladen vertraulicher Dokumente
+  - Einstellungen und Exporte
+
+  → Ergebnis: Verwaltung → Protokoll mit Filter.
+- [ ] **1.12** Länderstruktur:
+  - Schnittstelle für länderspezifische Begriffe und Auswahllisten
+  - Umsetzung für DE, AT nur als Platzhalter
+  - Länderwahl nur bei mehr als einem freigeschalteten Land
+
+## Abnahmekriterien
+
+- Die Kriterien von M1 zu Benutzern, Projekten, Upload, Rechten und Protokoll sind erfüllt
+  (`docs/projektplan.md`, Abschnitt 5).
+- Ein Benutzer ohne Mitgliedschaft erhält auf jeder Projekt-, Dokument- und Download-URL 403 oder 404.
+- CI ist grün.
+
+## 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.
+- 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.

docs/plaene/AP02-meilisearch-test.md

@@ -0,0 +1,67 @@
+# AP2 – Meilisearch-Test
+
+| | |
+|---|---|
+| Status | detailliert, wartet auf Freigabe |
+| Aufwand | 0,25 PW |
+| Zeitraum | Teil 1 KW 41, Teil 2 KW 46 |
+| Meilenstein | M2 |
+| Freigabe | offen |
+
+## Ziel
+
+Belegen, ob Meilisearch v1.54.2 Vektoren mit 4.096 Dimensionen schnell genug durchsucht. Danach
+steht fest, wie viel RAM der Server braucht und ob die binäre Quantisierung nötig ist. Teil 2
+misst die Trefferqualität mit echten Embeddings.
+
+## Umfang
+
+**Enthalten:**
+- Teil 1: Leistung mit erzeugten Zufallsvektoren
+- Teil 2: Trefferquote mit echten Vektoren und Referenzfällen
+
+**Nicht enthalten:** Aufbau der echten Indexierung (AP4).
+
+## Voraussetzungen
+
+- Teil 1: keine
+- Teil 2: Staging, Pilotdaten, Referenzfälle (A20), KI-API (AP3)
+
+## Entscheidungen
+
+| Nr. | Frage | Vorschlag | Entschieden |
+|---|---|---|---|
+| E2.1 | Grenzwerte für „bestanden“ | Bei 50.000 Abschnitten mit Filter auf Vertrag: Antwortzeit p95 < 300 ms, Indexierung < 30 min, RAM von Meilisearch < 8 GB | offen |
+
+## Schritte
+
+**Teil 1 (KW 41):**
+- [ ] **2.1** Messskript (`tools/meili-test/`, nur Entwicklung):
+  - erzeugt N Abschnitte mit normalisierten Zufallsvektoren (4.096 Dimensionen)
+  - mit Filterfeldern: Mandant, Land, Projekt, Abschnitt, Vertrag, Art
+  - mit kurzen Texten
+- [ ] **2.2** Messung ohne Quantisierung für N = 10.000 und 50.000:
+  - Indexierungszeit, Plattenbedarf, RAM
+  - Antwortzeit p50/p95 über je 100 Anfragen für reine Vektorsuche, hybride Suche, hybride
+    Suche mit Filter auf Vertrag bzw. Projekt
+- [ ] **2.3** Dieselbe Messung mit `binaryQuantized` in einem eigenen Index
+- [ ] **2.4** Bericht `docs/tests/meilisearch-teil1.md` → Ergebnis: Empfehlung zu RAM für die
+  Server-Anforderungen und vorläufig zur Quantisierung; bei Nichtbestehen Plan B (Qdrant) bewerten
+
+**Teil 2 (KW 46):**
+- [ ] **2.5** Messskript für Staging. Es gibt nur Kennzahlen aus, keine Inhalte:
+  - Recall@10 und Recall@40 der richtigen Fundstelle
+  - jeweils vor und nach dem Reranker
+  - mit und ohne Quantisierung
+- [ ] **2.6** Du führst es auf Staging aus. Bericht `docs/tests/meilisearch-teil2.md` →
+  Ergebnis: Entscheidung zur Quantisierung und Kandidatenzahl für AP4
+
+## Abnahmekriterien
+
+- Beide Berichte liegen vor und enthalten eine Empfehlung.
+- Die Server-Anforderungen sind bei Bedarf angepasst.
+
+## Risiken
+
+- Zufallsvektoren sagen nichts über die Trefferqualität. Dafür gibt es Teil 2.
+- Große JSON-Mengen beim Indexieren: in Stapeln senden.

docs/plaene/AP03-ki-api.md

@@ -0,0 +1,86 @@
+# AP3 – Anbindung KI-API ITM
+
+| | |
+|---|---|
+| Status | in Arbeit; Schritte ab 3.2 detailliert, warten auf Freigabe |
+| Aufwand | 0,5 PW offen |
+| Zeitraum | KW 42 (Schnelltest, Einstellungen), KW 44 (Clients, Jobs) |
+| Meilenstein | M1/M2 |
+| Freigabe | offen |
+
+## Ziel
+
+Die Anwendung nutzt Dokumentdienst, `embed`, `rerank` und `chat` zuverlässig. Sie beachtet die
+Grenzen der API und protokolliert jeden Aufruf ohne Inhalte und ohne Schlüssel. Die Schlüssel
+liegen verschlüsselt in der Datenbank.
+
+## Umfang
+
+**Enthalten:**
+- Schlüsselverwaltung, Clients, Hintergrund-Jobs, Ratenbegrenzung, Wiederholungen,
+  Verbrauchsprotokoll, Statusprüfung
+
+**Nicht enthalten:**
+- Indexierung (AP4)
+- Prompts für die Beurteilung (AP7)
+
+## Voraussetzungen
+
+- C1 (Schlüssel), C4–C8 (Modelle, Grenzen); Schlüssel im Windows-Tresor, Proxy läuft (du)
+- AP1 Schritt 1.7 (Rechte für Verwaltung)
+
+## Entscheidungen
+
+| Nr. | Frage | Vorschlag | Entschieden |
+|---|---|---|---|
+| E3.1 | Anteil der 120 Anfragen/min für interaktive Suche | 40/min reserviert, Rest für Hintergrund-Jobs; nach C8 anpassen | offen |
+| E3.2 | Standardmodell für einfache Aufgaben | `chat-noreasoning`, `chat` nur für die Beurteilung (AP7) | offen |
+
+## Schritte
+
+- [x] **3.1** Schlüssel-Proxy (`tools/ki-proxy`), Sperr-Hook für Claude Code, gitleaks-Regel
+- [ ] **3.2** Schnelltest über den Proxy, wenn du ihn gestartet hast. Nur Testtexte:
+  - Modellverzeichnis
+  - Dimension und Normalisierung von `embed` messen
+  - `rerank`
+  - `chat` mit Streaming
+
+  → `docs/tests/ki-api-schnelltest.md`
+- [ ] **3.3** Einstellungen KI-Schnittstelle:
+  - Tabelle mit verschlüsselten Feldern
+  - Verwaltungsmaske: Basis-URL, drei Schlüsselfelder (nur beschreibbar, Anzeige `zki_…a1b2`),
+    Modellnamen, „Verbindung prüfen“
+  - Protokolleintrag bei Änderung (ohne Wert)
+  - In der Entwicklung zeigt die Basis-URL auf den Proxy, die Schlüssel bleiben leer.
+- [ ] **3.4** Clients:
+  - `Dokumentdienst` (einreichen, Status, Ergebnis Markdown/JSON)
+  - `Embeddings` (Stapel; Instruct-Präfix für Suchanfragen nach C4)
+  - `Rerank`
+  - `Chat` (normal und Streaming)
+- [ ] **3.5** Jobs und Ausfallsicherheit:
+  - Ergebnisse abfragen im Abstand von 2 bis 10 s
+  - Job-ID gleich nach dem Einreichen speichern, keine Doppel-Einreichung nach Timeout
+  - Wiederholung bei 429 (Retry-After) und 5xx mit Backoff
+  - Ratenbegrenzer nach E3.1
+- [ ] **3.6** Verbrauchsprotokoll `ki_aufrufe`: Dienst, Modell, Dauer, Status, Tokens, Bezug.
+  Keine Inhalte, keine Header.
+- [ ] **3.7** Statusprüfung: Artisan-Befehl und Anzeige im Systemstatus (erreichbar, Antwortzeit,
+  Auslastung); Alarm über AP11
+
+## Abnahmekriterien
+
+- „Verbindung prüfen“ zeigt alle Dienste grün.
+- Die Schlüssel stehen nirgends im Klartext: nicht in der DB, nicht im Log, nicht in der Antwort
+  der Maske.
+- Ein Ausfall der API stoppt keine Seite; die Jobs laufen später weiter.
+
+## Tests
+
+- `Http::fake` für 200, 202, 409, 410, 404, 429, 5xx, Timeout und Streaming
+- Ratenbegrenzer greift
+- Log und Protokoll enthalten keinen Schlüssel
+- Verwaltungsmaske nur für Administratoren
+
+## Risiken
+
+- Antworten von ITM fehlen (C4–C8): Werte messen (3.2) und Standardwerte konfigurierbar halten.

docs/plaene/AP04-indexierung-suche.md

@@ -0,0 +1,70 @@
+# AP4 – Indexierung und LV-Suche
+
+| | |
+|---|---|
+| Status | grob geplant, Detaillierung bis KW 43 |
+| Aufwand | 1,0 PW |
+| Zeitraum | KW 44–46 |
+| Meilenstein | M2 |
+| Freigabe | offen |
+
+## Ziel
+
+Alle LV-Positionen und Vorbemerkungen eines Projekts sind über Stichwort und Bedeutung
+durchsuchbar. Jeder sieht nur, was er sehen darf, und springt vom Treffer ins PDF. Das ist auch
+die Grundlage der Vorprüfung.
+
+## Umfang
+
+**Enthalten:**
+- Abschnitte bilden, Embeddings erzeugen
+- Rohvektoren in MySQL, Index in Meilisearch, Neuaufbau aus MySQL
+- Zentraler Suchdienst mit Pflichtfilter für Rechte und Suchreihenfolge
+- Hybride Suche mit Reranking
+- Oberfläche der LV-Suche
+
+**Nicht enthalten:**
+- Vorschläge zur Prüfung (AP6)
+- Regelwerk (Phase 3)
+
+## Voraussetzungen
+
+- AP2 Teil 1 (Ausstattung, Quantisierung), AP3 (Clients), AP5 (LV-Elemente)
+- A2 (weitere Vertragsunterlagen?), A4 (beauftragte Nachträge mit durchsuchen?), A10 (Suchreihenfolge)
+
+## Entscheidungen (vorläufig)
+
+| Nr. | Frage | Vorschlag |
+|---|---|---|
+| E4.1 | Einheit eines Abschnitts | Je Position: OZ, Kurztext und Langtext. Vorbemerkungen nach Absätzen. PDFs ohne GAEB in Abschnitten von etwa 500–1.000 Tokens |
+| E4.2 | Kandidaten vor dem Reranking | 40, danach die besten 10 (nach AP2 Teil 2 anpassen) |
+| E4.3 | Gewichtung Stichwort/Bedeutung | `semanticRatio` 0,6, einstellbar |
+
+## Schritte (grob)
+
+- [ ] **4.1** Abschnittsbildung aus `lv_elemente` und PDF-Texten
+- [ ] **4.2** Embedding-Jobs:
+  - Stapel, Vorrang für Suchanfragen
+  - Rohvektor als float32-BLOB mit Modell, Dimension und Vorverarbeitungsstand
+- [ ] **4.3** Meilisearch-Index:
+  - Filterfelder Mandant, Land, Projekt, Abschnitt, Vertrag, Auftragnehmer, LV, Art, vertraulich
+  - Embedder `userProvided`
+- [ ] **4.4** Zentraler Suchdienst:
+  - Pflichtfilter aus den Rechten des Benutzers
+  - Suchreihenfolge Vertrag → Abschnitt → Projekt nach den Projekteinstellungen
+  - Reranking
+- [ ] **4.5** Neuaufbau des Index aus MySQL (Artisan-Befehl)
+- [ ] **4.6** Oberfläche LV-Suche:
+  - Bereich wählbar: Vertrag, PFA oder Projekt
+  - Treffer nach LV gruppiert, „Im PDF zeigen“
+- [ ] **4.7** Pilot-PFA auf Staging indexieren (du); Kennzahlen zu Dauer und Kosten
+
+## Abnahmekriterien
+
+- Die Kriterien von M2 zur LV-Suche sind erfüllt.
+- Ein Benutzer ohne Recht erhält keinen Treffer und keine Trefferzahl aus fremden Projekten oder
+  vertraulichen Dokumenten (Tests).
+
+## Risiken
+
+- Last auf der KI-API bei der Erstindexierung (C8): nachts in Stapeln laufen lassen.

docs/plaene/AP05-gaeb-pdf.md

@@ -0,0 +1,85 @@
+# AP5 – GAEB-Import und PDF-Anzeige
+
+| | |
+|---|---|
+| Status | detailliert, wartet auf Freigabe |
+| Aufwand | 1,25 PW |
+| Zeitraum | KW 41 (Test), KW 43–45 |
+| Meilenstein | M1 (LV-Baum), M2 (PDF, Nachträge) |
+| Freigabe | offen |
+
+## Ziel
+
+LVs und Nachtrags-LVs werden aus X86-Dateien eingelesen: Positionen, Vorbemerkungen und Gliederung.
+Jede Position lässt sich im zugehörigen PDF an der richtigen Stelle anzeigen.
+
+## Umfang
+
+**Enthalten:**
+- GAEB DA XML (X86) für Vertrags-LVs und Nachtrags-LVs
+- LV-Baum, PDF-Anzeige mit Markierung, Zuordnung von OZ zur PDF-Seite
+- Nachtrag ohne X86 über Texterkennung mit Bestätigung durch den Bearbeiter
+
+**Nicht enthalten:**
+- D86 (GAEB 90), nur falls A5 es erfordert
+- Kalkulationen und Preisnachweise (Phase 2)
+
+## Voraussetzungen
+
+- AP1 Schritt 1.10 (Upload)
+- A3 (Vorbemerkungen in X86?), A5 (Nachtrags-LV immer als X86?), A18 (anonymisierte Beispiele)
+
+## Entscheidungen
+
+| Nr. | Frage | Vorschlag | Entschieden |
+|---|---|---|---|
+| E5.1 | Parser: eigene Umsetzung oder Bibliothek? | Nach Schritt 5.1; voraussichtlich eigene Umsetzung mit `XMLReader` (wenige gepflegte PHP-Bibliotheken) | offen |
+| E5.2 | PDF-Anzeige | pdf.js (`pdfjs-dist`) lokal über Vite gebündelt, kein CDN | offen |
+| E5.3 | Seitenzuordnung | PDF-Text je Seite lokal mit poppler (`pdftotext`), OZ suchen; Sail-Image um poppler-utils ergänzen | offen |
+
+## Schritte
+
+- [ ] **5.1** GAEB-Test (KW 41):
+  - Öffentliche Beispieldateien suchen und deren Lizenz prüfen; dazu eine selbst erzeugte
+    X86-Datei nach DA XML 3.3 mit Titeln, Positionen und Vorbemerkungen
+  - Struktur auswerten, Bibliotheken prüfen
+
+  → `docs/tests/gaeb-test.md` mit Vorschlag zu E5.1
+- [ ] **5.2** Datenmodell `lv_elemente`:
+  - Felder: LV, übergeordnetes Element, Typ (Bereich, Titel, Position, Vorbemerkung, Hinweistext),
+    OZ, Kurztext, Langtext, Menge, Einheit, EP, GP, Sortierung, PDF-Seite
+  - Migration und Tests
+- [ ] **5.3** Parser und Import-Job X86 → `lv_elemente`:
+  - Importstatus und Fehlerbericht
+  - Erneuter Import ersetzt den alten Stand nachvollziehbar
+- [ ] **5.4** LV-Ansicht:
+  - Baum mit Titeln, Positionen und Vorbemerkungen
+  - Langtext aufklappbar, Suche im LV
+- [ ] **5.5** Seitenzuordnung (E5.3): je Element die PDF-Seite ermitteln, Abweichungen protokollieren
+- [ ] **5.6** PDF-Anzeige (E5.2):
+  - Seite, Zoom, Sprung zur Position, Markierung der Stelle
+  - Auslieferung nur über die Rechteprüfung
+- [ ] **5.7** Nachtrags-Import:
+  - Nachtrags-LV als X86 → `nachtragspositionen`
+  - Nur PDF → Dokumentdienst (AP3) → erkannte Positionen; der Bearbeiter bestätigt sie
+- [ ] **5.8** Anpassen nach den echten Beispielen (A18), sobald sie da sind
+
+## Abnahmekriterien
+
+- Ein Beispiel-LV wird vollständig eingelesen: Anzahl der Positionen und Summen stimmen mit der Datei überein.
+- Ein Klick auf eine Position zeigt im PDF die richtige Seite mit Markierung.
+- Ein Nachtrags-LV ergibt die Nachtragspositionen.
+
+## Tests
+
+- Parser mit erfundenen Beispieldateien: Gliederung, Langtexte, Sonderfälle wie fehlende Menge
+  oder Pauschalposition
+- Import-Job mit Fehlerfall
+- Seitenzuordnung
+- Rechteprüfung der PDF-Auslieferung
+
+## Risiken
+
+- Erweiterungen des Kalkulationsprogramms in der X86. Echte Beispiele früh anfordern (A18);
+  unbekannte Elemente protokollieren statt abbrechen.
+- Gescannte PDFs ohne Textebene: dann keine Seitenzuordnung, Hinweis anzeigen.

docs/plaene/AP06-vorpruefung-stufe1.md

@@ -0,0 +1,57 @@
+# AP6 – Vorprüfung Stufe 1 und Prüfmaske
+
+| | |
+|---|---|
+| Status | grob geplant, Detaillierung bis KW 45 |
+| Aufwand | 1,25 PW |
+| Zeitraum | KW 46–47 |
+| Meilenstein | M2 |
+| Freigabe | offen |
+
+## Ziel
+
+Für jede Position eines neuen Nachtrags stehen nach kurzer Zeit die wahrscheinlichsten Fundstellen
+im Vertrag fest, noch ohne Sprachmodell. Der Bearbeiter prüft sie in der Prüfmaske, korrigiert sie
+und setzt das Prüfergebnis.
+
+## Umfang
+
+**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)
+- Feedback je Aspekt, Korrektur der Fundstelle, Prüfergebnis, Verlauf
+
+**Nicht enthalten:**
+- Einschätzung, Begründung und Bezugsposition durch das Sprachmodell (AP7)
+- Regeln (AP8)
+
+## Voraussetzungen
+
+- AP4, AP5 (Nachtrags-Import), AP13
+- Prüfmaske v3 von Claude Design
+- A9 (Werte des Prüfergebnisses)
+
+## Schritte (grob)
+
+- [ ] **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
+- [ ] **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:
+  - 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
+  Fundstelle“; Prüfergebnis; Verlauf
+- [ ] **6.7** Erste Messung: richtige Fundstelle unter den ersten drei (synthetische Fälle, auf
+  Staging mit echten Fällen)
+
+## Abnahmekriterien
+
+- Die Kriterien von M2 zur Vorprüfung sind erfüllt.
+- „Speichern, weiter“ funktioniert erst, wenn alle drei Aspekte bewertet sind.

docs/plaene/AP07-vorpruefung-stufe2.md

@@ -0,0 +1,54 @@
+# AP7 – Vorprüfung Stufe 2 mit Sprachmodell
+
+| | |
+|---|---|
+| Status | grob geplant, Detaillierung bis KW 47 |
+| Aufwand | 1,0 PW |
+| Zeitraum | KW 48–49 |
+| Meilenstein | M3 |
+| Freigabe | offen |
+
+## Ziel
+
+Das Sprachmodell beurteilt je Nachtragsposition, ob die Leistung im Vertrag enthalten ist. Bei
+geänderter Leistung benennt es die Bezugsposition und den Unterschied. Die Begründung verweist nur
+auf Quellen, die es wirklich gibt.
+
+## Umfang
+
+**Enthalten:**
+- Prompt-Konzept, Kontextaufbau, strukturierte Antwort mit Prüfung im Code
+- Bezugsposition mit Textvergleich, Begründung mit Quellen
+- Verbrauchs- und Kostenprotokoll, Bewertung mit Testfällen
+
+**Nicht enthalten:**
+- Rechtliche Einordnung (A12)
+- Preisbewertung (Phase 2)
+
+## Voraussetzungen
+
+- AP6
+- C6 (Modell, Kontext, strukturierte Ausgabe)
+- A6 (Bezugsposition im Nachtrag genannt?), A12
+
+## Schritte (grob)
+
+- [ ] **7.1** Prompt-Konzept `docs/prompts.md`:
+  - Rolle und Aufgabe, Ausgabe-Schema
+  - Regel „nur aus den gelieferten Quellen“
+  - Dokumentinhalte als Daten, nicht als Anweisungen
+- [ ] **7.2** Kontextaufbau: Position, beste Fundstellen, passende Vorbemerkungen, später Regeln
+  und Referenzfälle; Grenze der Kontextlänge
+- [ ] **7.3** Aufruf und Prüfung der Antwort:
+  - JSON-Schema, gültige Werte, zitierte Quellen müssen existieren
+  - eine Wiederholung bei ungültiger Antwort, sonst Rückfall auf Stufe 1
+- [ ] **7.4** Bezugsposition und Unterschied: Textvergleich im Code, Anzeige als Abweichung
+- [ ] **7.5** Anzeige in der Prüfmaske:
+  - Einschätzung „Im Vertrag“ und Vorschlag zum Prüfergebnis
+  - Begründung mit anklickbaren Quellen
+- [ ] **7.6** Bewertung: synthetische Testfälle lokal; echte Fälle als Kennzahlen auf Staging
+
+## Abnahmekriterien
+
+- Die Kriterien von M3 zur Prüfmaske sind erfüllt.
+- Keine Begründung verweist auf eine Quelle, die es nicht gibt (Test).

docs/plaene/AP08-regeln.md

@@ -0,0 +1,42 @@
+# AP8 – Regeln, Referenzfälle, Freigaben
+
+| | |
+|---|---|
+| Status | grob geplant, Detaillierung bis KW 48 |
+| Aufwand | 0,75 PW |
+| Zeitraum | KW 49–50 |
+| Meilenstein | M3 |
+| Freigabe | offen |
+
+## Ziel
+
+Aus Korrekturen werden Regeln. Sie verbessern künftige Vorschläge im passenden Geltungsbereich und
+werden je nach Einstellung freigegeben. Bestätigte Fälle dienen als Referenzfälle.
+
+## Umfang
+
+**Enthalten:**
+- Regeln mit Situation, Regel, Geltungsbereich, Status und Versionen
+- Regeldialog, Freigabe-Einstellungen (Voreinstellungen), Wissensbasis-Reiter
+- Referenzfälle; Kennzeichnung „zur Überprüfung“ bei mehrfacher Überstimmung
+
+**Nicht enthalten:** Training von Modellen.
+
+## Voraussetzungen
+
+- AP6, AP7
+- A23 (projektübergreifende Regeln?), A24 (Freigabe-Variante)
+
+## Schritte (grob)
+
+- [ ] **8.1** Datenmodell Regeln und Versionen; Geltungsbereich Vertrag → PFA → Projekt →
+  Auftraggeber → Land; nie löschen
+- [ ] **8.2** Regeldialog aus der Prüfmaske: Vorformulierung, ähnliche Regeln
+- [ ] **8.3** Freigabe-Einstellungen 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
+
+## Abnahmekriterien
+
+- Eine Regel aus einer Korrektur wirkt nach der Freigabe beim nächsten passenden Fall und wird dort
+  als Quelle angezeigt.

docs/plaene/AP09-ergebnis-export.md

@@ -0,0 +1,36 @@
+# AP9 – Ergebnisliste und Export
+
+| | |
+|---|---|
+| Status | grob geplant, Detaillierung bis KW 49 |
+| Aufwand | 0,25 PW |
+| Zeitraum | KW 50 |
+| Meilenstein | M3 |
+| Freigabe | offen |
+
+## Ziel
+
+Für jeden Nachtrag gibt es eine Ergebnisliste aller Positionen, die sich als Excel exportieren
+und in die Bewertungsmatrix übertragen lässt.
+
+## Umfang
+
+**Enthalten:** Bearbeitungsstand des Nachtrags, Ergebnisliste, Excel-Export (PhpSpreadsheet),
+Liste der Exporte, „Nachtrag abschließen“.
+
+**Nicht enthalten:** Bewertungsmatrix in der DB-Vorlage und Stellungnahme (Optionen).
+
+## Voraussetzungen
+
+AP6, AP7; A9 (Werte), A14 (Spalten der Matrix als Orientierung).
+
+## Schritte (grob)
+
+- [ ] **9.1** Bearbeitungsstand eingegangen → vorgeprüft → in Prüfung → geprüft → exportiert
+- [ ] **9.2** Ergebnisliste: OZ, Kurztext, Menge/Einheit, Im Vertrag, beste Fundstelle,
+  Prüfergebnis, Kommentar
+- [ ] **9.3** Excel-Export und Exportprotokoll
+
+## Abnahmekriterien
+
+- Der Export eines Nachtrags enthält alle Positionen mit Prüfergebnis und Fundstelle.

docs/plaene/AP10-dashboard-auswertungen.md

@@ -0,0 +1,38 @@
+# AP10 – Dashboard, Benachrichtigungen, Auswertungen
+
+| | |
+|---|---|
+| Status | grob geplant, Detaillierung bis KW 46 |
+| Aufwand | 0,5 PW |
+| Zeitraum | KW 47 (Dashboard), KW 2/2027 (Auswertungen) |
+| Meilenstein | M2, M4 |
+| Freigabe | offen |
+
+## Ziel
+
+Jeder sieht beim Einstieg seine offenen Nachträge und wird benachrichtigt, wenn etwas fertig ist.
+Die Auswertungen zeigen, wie gut die Vorschläge sind.
+
+## Umfang
+
+**Enthalten:**
+- Dashboard (Variante 1a aus Claude Design)
+- Benachrichtigungen in der Anwendung, optional per E-Mail
+- Auswertungen: Trefferquote, Treffsicherheit je KI-Sicherheit, überstimmte Regeln, Prüfzeit
+- Allgemeine Dokumente in den Einstellungen
+
+## Voraussetzungen
+
+AP6; B3 (E-Mail-Absender).
+
+## Schritte (grob)
+
+- [ ] **10.1** Dashboard: offene Nachträge, „vorgeprüft – bereit“, Verarbeitung, Freigaben
+- [ ] **10.2** Benachrichtigungen: Vorprüfung fertig oder fehlgeschlagen, Nachtrag zugewiesen,
+  Regel zur Freigabe
+- [ ] **10.3** Auswertungen (KW 2)
+- [ ] **10.4** Allgemeine Dokumente (Einstellungen, projektübergreifend)
+
+## Abnahmekriterien
+
+- Die Kennzahlen der Auswertungen stimmen mit einer Nachzählung auf Testdaten überein.

docs/plaene/AP11-betrieb.md

@@ -0,0 +1,74 @@
+# AP11 – Betrieb
+
+| | |
+|---|---|
+| Status | in Arbeit (11a.1 erledigt); Schritte ab 11a.2 detailliert, warten auf Freigabe |
+| Aufwand | 0,5 PW (wir) + 1–1,5 PW (ITM-Entwickler) |
+| Zeitraum | KW 41–44 (Staging), KW 50–51 (Produktion), KW 3/2027 (Restore-Test) |
+| Meilenstein | M2 (Staging), M3 (Produktion), M4 (abgesichert) |
+| Freigabe | offen |
+
+## Ziel
+
+Staging und Produktion laufen auf den Servern von ITM, werden reproduzierbar bereitgestellt,
+gesichert und überwacht. Ein Ausfall fällt auf, bevor BauIn ihn bemerkt.
+
+## Umfang
+
+**Enthalten:**
+- **11a, wir:**
+  - Server-Anforderungen
+  - Vorlagen für Nginx, systemd und Cron
+  - Deploy-Skript
+  - Lebenszeichen- und Prüfbefehle
+  - Backup-Skript
+  - Betriebsdoku
+- **11b, ITM-Entwickler:**
+  - Server aufsetzen, Domain und Zertifikat
+  - Backup-Ziel, Überwachung
+  - Restore-Test gemeinsam mit uns
+
+**Nicht enthalten:** Hochverfügbarkeit, mehrere Server.
+
+## Voraussetzungen
+
+C10 (Ausstattung, Root-Zugang), B2 (Zugriff Internet/VPN), B3 (Domain, Mail), B5 und C10 (Backups),
+C12 (wer deployt).
+
+## Entscheidungen
+
+| Nr. | Frage | Vorschlag | Entschieden |
+|---|---|---|---|
+| 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 |
+
+## Schritte
+
+- [x] **11a.1** Server-Anforderungen `docs/server-anforderungen.md`
+- [ ] **11a.2** Vorlagen in `deploy/`:
+  - Nginx-Server-Block, systemd-Units (Worker, Meilisearch), Cron-Zeile
+  - Beispiel für `.env` ohne Werte
+- [ ] **11a.3** Deploy-Skript nach E11.1 mit Prüfungen (Migration, Caches, Neustart der Worker),
+  zuerst gegen eine lokale Test-VM oder direkt auf Staging
+- [ ] **11a.4** Betriebsbefehle:
+  - Lebenszeichen für Worker und Scheduler
+  - Zählung fehlgeschlagener Jobs
+  - Statusprüfung der KI-API (aus AP3)
+  - Mail bei Problemen (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
+- [ ] **11b.2** Produktion aufsetzen (KW 50–51)
+- [ ] **11a.6 / 11b.3** Restore-Test auf einem Ersatzsystem (KW 3), Protokoll in `docs/betrieb.md`
+
+## 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.
+- Der Restore-Test war erfolgreich und ist dokumentiert.
+
+## Risiken
+
+- Antworten von ITM zu Zugang und Ausstattung kommen spät. Dann Staging per Bildschirmfreigabe
+  gemeinsam aufsetzen.

docs/plaene/AP12-pilot.md

@@ -0,0 +1,40 @@
+# AP12 – Pilot und Messung
+
+| | |
+|---|---|
+| Status | grob geplant, Detaillierung bis KW 51 |
+| Aufwand | 1,5 PW |
+| Zeitraum | KW 1–2/2027 |
+| Meilenstein | M4 |
+| Freigabe | offen |
+
+## Ziel
+
+Alle Nachträge des Pilot-PFA laufen durch das System. Trefferquote und Zeitersparnis sind
+gemessen, und die Vorschläge sind anhand der Ergebnisse nachgeschärft.
+
+## Umfang
+
+**Enthalten:**
+- Messplan, Messskripte (nur Kennzahlen), Durchlauf mit BauIn
+- Nachschärfen: Prompts, Gewichtung, Quantisierung, Kandidatenzahl
+- Abschlussbericht
+
+## Voraussetzungen
+
+AP6–AP9; A20 (Referenzfälle), A21 (Erfolgskriterium); Fachexperte verfügbar.
+
+## Schritte (grob)
+
+- [ ] **12.1** Messplan (KW 51):
+  - Kennzahlen: richtige Fundstelle unter den ersten drei, Übereinstimmung des Prüfergebnisses,
+    Prüfzeit je Nachtrag
+  - Vergleich mit dem Stand vorher
+- [ ] **12.2** Messskripte für Staging bzw. Produktion, ohne Inhalte
+- [ ] **12.3** Durchlauf (KW 1) mit Bewertung durch den Fachexperten
+- [ ] **12.4** Nachschärfen (KW 2) und erneute Messung
+- [ ] **12.5** Abschlussbericht `docs/pilot-bericht.md` für M4
+
+## Abnahmekriterien
+
+- Die Kriterien von M4 zu den Kennzahlen sind erfüllt bzw. dokumentiert.

docs/plaene/AP13-designsystem.md

@@ -0,0 +1,78 @@
+# AP13 – Designsystem aus Claude Design
+
+| | |
+|---|---|
+| Status | detailliert, wartet auf Freigabe |
+| Aufwand | 0,5 PW |
+| Zeitraum | KW 43 |
+| Meilenstein | M1 |
+| Freigabe | offen |
+
+## Ziel
+
+Die Anwendung sieht aus wie der Prototyp von Claude Design: Farben, Schriften, Abstände,
+Statussysteme, App-Rahmen. Bestehende und künftige Seiten nutzen dieselben Bausteine.
+
+## Umfang
+
+**Enthalten:**
+- Design-Tokens mit Hell- und Dunkelmodus
+- Schriften und Icons lokal
+- TallStackUI anpassen
+- Eigene Komponenten für die Statussysteme
+- Sidebar und Topbar
+- Musterseite zum Abgleich
+
+**Nicht enthalten:** Einzelne Fachseiten; diese entstehen in ihren Arbeitspaketen mit den hier
+gebauten Bausteinen.
+
+## Voraussetzungen
+
+Neuer Stand von Claude Design nach unserer Rückmeldung (`Rueckmeldung_an_ClaudeDesign_2026-10-02.md`).
+Benötigt werden die Übergabe (Abschnitte 1–9) und die `.dc.html`-Dateien. Bisheriger Stand:
+`ClaudeDesign_Stand_2026-10-02.md` im Planungsordner.
+
+## Entscheidungen
+
+| Nr. | Frage | Vorschlag | Entschieden |
+|---|---|---|---|
+| E13.1 | Schriften | League Spartan und IBM Plex über `@fontsource`-Pakete, lokal gebündelt | offen |
+| E13.2 | Icons | Phosphor über das Blade-Paket `codeat3/blade-phosphor-icons` (MIT), in TallStackUI als Icon-Typ eingebunden | offen |
+| E13.3 | Ablage der Entwürfe im Repository | `docs/design/` mit Übergabe und `.dc.html` (nur erfundene Daten) | offen |
+
+## Schritte
+
+- [ ] **13.1** Stand von Claude Design in `docs/design/` ablegen (E13.3), Unterschiede zur
+  Rückmeldung notieren
+- [ ] **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,
+  Toast, Badge (Radien, Farben, Größen)
+- [ ] **13.5** Eigene Komponenten:
+  - KI-Sicherheit (`x-confidence`)
+  - Prüfergebnis-Plakette
+  - Regelstatus-Etikett
+  - Bearbeitungsstand mit 5 Punkten
+  - KI-Vorschlag-Pille
+  - Zustände leer, lädt, Fehler, kein Zugriff
+- [ ] **13.6** App-Rahmen: Sidebar mit Gruppen Arbeit, Wissen, System; Topbar mit Suche,
+  Benachrichtigungen, Benutzer; Länderwahl nur bei mehreren Ländern
+- [ ] **13.7** Musterseite „Designsystem“ (nur in der Entwicklung) und Abgleich mit dem Prototyp
+  per Screenshot; bestehende Seiten (Login, Einstellungen, AP1-Seiten) umstellen
+
+## Abnahmekriterien
+
+- Die Musterseite entspricht dem Designsystem des Prototyps in Hell und Dunkel.
+- Alle Statussysteme sind ohne Farbe unterscheidbar (Symbol und Text).
+- Es werden keine externen Ressourcen geladen.
+
+## Tests
+
+- `NoExternalResourcesTest` auf allen Seiten
+- Blade-Komponenten-Tests für Status und Zustände
+- Übersetzungsabdeckung
+
+## Risiken
+
+- Claude Design liefert spät. Dann mit dem bisherigen Stand beginnen; die Prüfmaske kommt ohnehin
+  erst in AP6.

docs/plaene/OP-optionen.md

@@ -0,0 +1,31 @@
+# Optionen OP1 und OP2
+
+| | |
+|---|---|
+| 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 |
+| Freigabe | offen |
+
+## OP1 – Bewertungsmatrix in der Excel-Vorlage der DB
+
+**Ziel:** Die Ergebnisse eines Nachtrags werden direkt in die Bewertungsmatrix der DB geschrieben.
+
+**Voraussetzungen:** A14 (Vorlage leer und ausgefüllt, Spalten und Reiter, Makros?).
+
+**Schritte (grob):**
+- [ ] **OP1.1** Vorlage untersuchen. Bleiben die Makros erhalten, wenn PhpSpreadsheet die Datei
+  schreibt? Falls nicht: Werte so exportieren, dass sie sich in die Vorlage einfügen lassen.
+- [ ] **OP1.2** Zuordnung Spalten ↔ Daten mit dir und BauIn abstimmen
+- [ ] **OP1.3** Export und Test mit einem Beispielnachtrag
+
+## OP2 – Stellungnahme BÜW als Word-Datei
+
+**Ziel:** Das Deckblatt zur Bewertungsmatrix (Ansprechpartner, Bearbeiter, Nachtrag, Sachverhalt)
+wird aus der Vorlage erzeugt.
+
+**Voraussetzungen:** A15 (Vorlage, `.docx`, variable Felder).
+
+**Schritte (grob):**
+- [ ] **OP2.1** Vorlage in `.docx` mit Platzhaltern (einmalige Umwandlung)
+- [ ] **OP2.2** Felder befüllen (PHPWord-TemplateProcessor), Test

docs/plaene/_vorlage.md

@@ -0,0 +1,47 @@
+# APx – Titel
+
+| | |
+|---|---|
+| Status | grob geplant / detailliert (wartet auf Freigabe) / freigegeben / in Arbeit / erledigt |
+| Aufwand | x PW (mit Claude Code) |
+| Zeitraum | KW … |
+| Meilenstein | M… |
+| Freigabe | Datum, durch wen |
+
+## Ziel
+
+Ein bis drei Sätze: Was kann man danach, das vorher nicht ging?
+
+## Umfang
+
+**Enthalten:** …
+
+**Nicht enthalten:** …
+
+## Voraussetzungen
+
+Andere Arbeitspakete, Zulieferungen, Fragen aus `docs/fragen.md` (mit ID).
+
+## Entscheidungen
+
+| Nr. | Frage | Vorschlag | Entschieden |
+|---|---|---|---|
+| Ex.1 | … | … | offen |
+
+## Schritte
+
+Je Schritt höchstens ein Tag, mit prüfbarem Ergebnis.
+
+- [ ] **x.1** … → Ergebnis: …
+
+## Abnahmekriterien
+
+- …
+
+## Tests
+
+- …
+
+## Risiken
+
+- …

docs/projektplan.md

@@ -1,251 +1,276 @@
-# KI-BauIN – Projekt- und Zeitplan (Phase 1)
+# KI-BauIN – Projektplan Phase 1
 
-Stand: 2. Oktober 2026 (KW 40), nach der ersten Besprechung mit BauIN und der API-Dokumentation
+Stand: 5. Oktober 2026 (KW 41). Dieses Dokument ist der Gesamtplan. Die Einzelheiten stehen in
-von ITM. Sobald die Antworten auf den Fragenkatalog vorliegen (Ziel: Termin am 16.10.), wird
+den Teilplänen unter `docs/plaene/`, offene Fragen mit Status in `docs/fragen.md`.
-daraus der Detailplan mit Teilplänen je Arbeitspaket.
 
-## Beteiligte
+## Inhalt
 
-- **ITM:** Anbieter der KI-API (über API-Werk: Dokumentdienst mit OCR, Embeddings, Reranker,
+1. [Arbeitsweise](#1-arbeitsweise)
-  Sprachmodell), Projektleitung und abrechnende Firma. Stellt auch die Server (Staging,
+2. [Beteiligte und Zuständigkeiten](#2-beteiligte-und-zuständigkeiten)
-  Produktion) und den Gitea, auf den das Repository gespiegelt wird.
+3. [Ziel und Umfang](#3-ziel-und-umfang)
-- **BauIn:** Endkunde. Prüft als Bauüberwachung im Auftrag der DB die Nachträge der
+4. [Rahmen und Annahmen](#4-rahmen-und-annahmen)
-  Auftragnehmer dem Grunde nach. Liefert Fachdaten (LVs, Nachträge, Bewertungsmatrizen),
+5. [Meilensteine mit Abnahmekriterien](#5-meilensteine-mit-abnahmekriterien)
-  stellt den fachlichen Ansprechpartner (Nachtragsbearbeitung) und eine Ansprechpartnerin für IT.
+6. [Arbeitspakete](#6-arbeitspakete)
-- „Kunde“ meint in diesem Dokument BauIn; wo ITM gemeint ist, steht ITM.
+7. [Zeitplan nach Kalenderwochen](#7-zeitplan-nach-kalenderwochen)
+8. [Zulieferungen](#8-zulieferungen)
+9. [Risiken](#9-risiken)
+10. [Entscheidungen](#10-entscheidungen)
+11. [Nach Phase 1](#11-nach-phase-1)
+12. [Änderungen an diesem Plan](#12-änderungen-an-diesem-plan)
 
-## Ergebnis der Besprechung vom 02.10.2026
+## 1. Arbeitsweise
 
-Was sich gegenüber dem Stand vom 01.10. ändert:
+Es wird nur umgesetzt, was in einem freigegebenen Teilplan steht.
 
-- **Geprüft werden Nachträge, nicht MKAs.** Aus einer MKA entsteht (oder auch nicht) nach
+1. **Teilplan detaillieren:** Vor Beginn eines Arbeitspakets beschreibt Claude Code den Teilplan
-  einigen Wochen ein Nachtrag; das ist nicht 1:1. Der Nachtrag enthält ein Nachtrags-LV mit
+   in `docs/plaene/`. Er enthält Ziel, Umfang, Schritte (je höchstens ein Tag), offene Fragen,
-  Positionen (GAEB und PDF), ein Anschreiben, die Kalkulation und Anlagen. Die MKA-Nummer ist nur
+   Entscheidungen und Abnahmekriterien.
-  noch ein Bezug am Nachtrag.
+2. **Freigabe:** Du liest den Teilplan, triffst die offenen Entscheidungen und setzt den Status
-- **Die KI beantwortet je Nachtragsposition eine Frage:** Ist die Leistung schon im Vertrag
+   auf „freigegeben“.
-  enthalten, also in den LVs einschließlich Vorbemerkungen? Wenn ja, ist der Nachtrag dem Grunde
+3. **Umsetzung in Schritten:** Jeder Schritt endet mit grünen Tests, Pint und PHPStan und einem
-  nach nicht berechtigt. Schwerpunkt sind geänderte Leistungen (§ 2 Abs. 5 VOB/B, mit Rückgriff
+   Commit, der den Schritt nennt (z. B. „AP1 Schritt 1.7: …“). Änderungen an Rechten,
-  auf eine Hauptvertragsposition) und zusätzliche Leistungen (§ 2 Abs. 6 VOB/B). Mengenänderungen
+   Dateizugriff, Suchfiltern oder KI-Aufrufen nennt Claude Code ausdrücklich.
-  (§ 2 Abs. 3) kommen selten vor und bekommen keine eigene Logik.
+4. **Abnahme:** Am Ende eines Arbeitspakets prüfst du die Abnahmekriterien im Browser. Danach
-- **Nicht Aufgabe der KI:** die rechtliche Einordnung (richtiger Paragraf), Fristen und
+   steht der Status auf „erledigt“, und Plan und Fragenliste werden nachgezogen.
-  Vollständigkeit der Anzeige, Leistungen ohne Auftrag (§ 2 Abs. 8), Behinderungen (§ 6 Abs. 6),
+5. **Neue Erkenntnisse zuerst in den Plan:** Antworten, neue Wünsche und Probleme kommen zuerst
-  Anordnungen des Auftraggebers. Das prüft BauIn selbst.
+   in `docs/fragen.md` oder den Teilplan, dann in den Code. Ideen außerhalb des Plans kommen in
-- **Gliederung:** Projekt → PFA (Planfeststellungsabschnitt, im Pilot PFA 1–4) → Vertrag mit
+   den Abschnitt [Nach Phase 1](#11-nach-phase-1).
-  einem Auftragnehmer (je PFA mehrere, z. B. Gleisbau, Tunnelbau, Oberleitung) → mehrere LVs
+6. **Rollierend:** Die nächsten zwei bis drei Wochen sind im Detail geplant, alles Weitere grob.
-  (im PFA 4 z. B. 28). Ein „Los“ im bisherigen Plan entspricht einem Vertrag.
+   Ein Teilplan wird spätestens eine Woche vor seinem Start detailliert.
-- **Suchreihenfolge:** zuerst die LVs des betroffenen Vertrags, dann als Hinweis die anderen PFAs
+7. **Rhythmus:** Vor jedem Freitagstermin mit BauIn gibt es einen Statusbericht mit Screenshots.
-  desselben Projekts (Fall: Leistung im PFA 3 beauftragt, im PFA 4 vergessen und dort per
+   Danach werden Antworten und Termine eingepflegt.
-  Nachtrag zum doppelten Preis angeboten). Nie projektübergreifend. Ob auch die übrigen Verträge
-  im selben PFA durchsucht werden, ist offen.
-- **Daten:** Jedes LV liegt als GAEB (X86 und D86) und als PDF vor, erzeugt aus dem
-  Kalkulationsprogramm. Grundlage ist die X86-Datei (strukturiert, ohne Texterkennung); das PDF
-  dient der Anzeige mit Sprung zur Fundstelle. OCR über die KI-API braucht es nur noch für
-  PDFs ohne GAEB-Datei (Anschreiben, Scans).
-- **Sprachmodell ist vorhanden** (`chat`, `chat-noreasoning`, Kontext laut ITM 128K). Damit ist
-  die KI-Beurteilung (Stufe 2) fest eingeplant.
-- **Bewertungsmatrix (Excel der DB) und Stellungnahme (Word) sind Optionen**, nicht Kern von
-  Phase 1. Vorlagen kommen von BauIn.
-- **Die Prüfung der Höhe nach ist Phase 2**, das Regelwerk mit Chat Phase 3 (siehe unten).
-- **Zusammenarbeit:** Termine freitags über Teams; nächster Termin am **16.10.2026** mit
-  Statusbericht und Kostenrahmen für Phase 1.
 
-## Rahmen und Annahmen
+**Status eines Teilplans:** grob geplant → detailliert (wartet auf Freigabe) → freigegeben →
+in Arbeit → erledigt.
 
-- **Ziel von Phase 1:** Positionsanalyse dem Grunde nach am Pilotprojekt. Vom hochgeladenen
+**Definition of Done, für jeden Schritt:**
-  Nachtrag bis zur Ergebnisliste je Position mit Fundstellen, Begründung und Entscheidung des
+- Tests sind vorhanden und grün, bei geschützten Aktionen auch ohne Berechtigung.
-  Bearbeiters, mit Rollen und Rechten, Protokoll und Betrieb auf den Servern von ITM.
+- Pint und PHPStan Stufe 7 laufen ohne Fehler.
-- **Grundhaltung:** Die KI schlägt vor und belegt mit Fundstellen, der Mensch entscheidet.
+- Sichtbare Texte stehen in `__()` und sind übersetzt.
-  Rückmeldungen fließen in ein Confidence-System mit Referenzfällen und Regeln.
+- Keine externen Ressourcen, keine Geheimnisse, keine echten Kundendaten.
-- **Team:**
+- Doku und Teilplan sind aktualisiert, der Commit ist auf Deutsch.
-  - **Du + Claude Code:** die gesamte Anwendung (Backoffice), also Oberfläche, Datenmodell,
+
-    Rechte, GAEB-Import, Anbindung der KI-API, Indexierung und Suche, Prüflogik mit Prompts,
+## 2. Beteiligte und Zuständigkeiten
-    Export, Tests, Deployment-Skripte und Doku. Arbeitsweise: Vibe Coding, Claude Code schreibt
+
-    den Code, du steuerst, testest im Browser, entscheidest und hältst den Kontakt zu BauIn.
+| Wer | Aufgabe im Projekt |
-  - **ITM-Entwickler:** KI-API (API-Werk, Modelle, Schlüssel, Grenzen) und der Aufbau der Server
+|---|---|
-    für Staging und Produktion nach unseren Vorgaben (PHP, MySQL, Meilisearch, Nginx, Worker,
+| **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. |
-    Cron, TLS, Backups).
+| **Claude Code** | Teilpläne ausarbeiten, den gesamten Code mit Tests schreiben, Doku, Statusberichte entwerfen. Sieht keine echten Kundendaten und keine API-Schlüssel. |
-  - Annahme zur Abgrenzung: Prompts und Prüflogik bauen wir, weil sie eng mit Oberfläche und
+| **ITM-Entwickler** | KI-API (API-Werk, Modelle, Schlüssel, Grenzen), Aufbau von Staging- und Produktionsserver nach `docs/server-anforderungen.md` |
-    Feedback verzahnt sind; ITM berät zu Modellen und Grenzen. Bestätigung steht aus.
+| **ITM-Projektleitung** | Projektleitung, Abrechnung, Kostenrahmen für BauIn, Server und Gitea |
-- **Aufwand** in deinen Personenwochen (PW) mit Claude Code: Kern rund 11 PW, mit Puffer 13–14 PW,
+| **Claude Design** | Oberflächenentwürfe (Prototyp, Designsystem); Übergaben im Format seiner Übergabe, Abschnitt 9 |
-  Optionen je 0,5 PW. Ohne KI-Unterstützung wären es rund 23 PW. Dazu kommen beim
+| **BauIn – Nachtragsbearbeitung** | Fachliche Fragen, Testdaten, Referenzfälle, Vorlagen, Bewertung im Pilot |
-  ITM-Entwickler etwa 1–1,5 PW für die Server. Werkzeugkosten (Claude Code) sind nicht enthalten.
+| **BauIn – IT** | Anmeldung, Zugriff, Domain, Datenschutz und Informationssicherheit |
-- **Wo Claude Code Zeit spart und wo nicht:** Oberfläche, Datenmodell, Tests und Parser gehen
+
-  etwa dreimal so schnell, die Anbindung von API und Dateiformaten etwa doppelt. Kaum schneller
+BauIn ist der Endkunde und prüft als Bauüberwachung im Auftrag der DB die Nachträge der
-  werden Klärung mit dem Kunden, Warten auf Zulieferungen, das Nachschärfen mit echten Daten
+Auftragnehmer dem Grunde nach. Kontakt läuft über Teams, Termine sind freitags.
-  und Abnahmen. Claude Code sieht keine echten Kundendaten; Messungen mit echten Nachträgen
+
-  machst du auf Staging und gibst Kennzahlen oder anonymisierte Beispiele zurück.
+## 3. Ziel und Umfang
-- **Verfügbarkeit:** rund 30 Stunden pro Woche (≈ 0,75 PW), erhöhbar. Du schreibst selbst keinen
+
-  Code; deine Zeit geht in Steuern, Testen, Entscheiden und Kundenkontakt. Bis M4 (KW 41–4) sind
+**Ziel von Phase 1:** Für jede Position eines eingereichten Nachtrags zeigt KI-BauIN, ob die
-  das ≈ 11,25 PW, also genau der Kern ohne Reserve; der Puffer in KW 5–6 bringt ≈ 1,5 PW.
+Leistung schon im Vertrag enthalten ist, also in den LVs einschließlich Vorbemerkungen. Dazu
-  **Empfehlung:** in KW 44–51 (vor M2 und M3) auf 35–40 Stunden erhöhen. Das deckt die beiden
+gehören Fundstellen mit Sprung ins PDF, eine Begründung und bei geänderter Leistung die
-  Optionen und etwas Reserve. Sonst rücken die Optionen hinter M4.
+Bezugsposition. Der Bearbeiter entscheidet; seine Rückmeldungen verbessern die Vorschläge.
-- **Kalender:** Bestimmt wird er von Kundenterminen, Zulieferungen und dem Pilot mit BauIn,
+
-  weniger vom Programmieren. Die Zeitersparnis fließt deshalb in mehr Inhalt je Meilenstein,
+**Enthalten:**
-  in die beiden Optionen und in Puffer, nicht in ein früheres Ende.
+- Projekte mit PFA (Abschnitten), Verträgen und Auftragnehmern
+- Upload von LVs als X86 und PDF, 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
+- Regeln, Referenzfälle, einstellbare Freigaben
+- Ergebnisliste mit Excel-Export
+- 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),
+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
+- Prüfung der Höhe nach (Phase 2)
+- Regelwerk mit Chat (Phase 3)
+- DOXIS-Anbindung, Österreich
+
+## 4. Rahmen und Annahmen
+
+- **Gliederung:** Projekt → PFA (Planfeststellungsabschnitt) → Vertrag mit einem Auftragnehmer →
+  viele LVs; Nachträge gehören zu einem Vertrag. Datenmodell in `docs/datenmodell.md`.
+- **Daten:** LVs liegen immer als X86, D86 und PDF vor. Grundlage ist die X86-Datei, das PDF dient
+  der Anzeige. Texterkennung über die KI-API braucht es nur für PDFs ohne GAEB-Datei.
+- **KI-API ITM** über API-Werk: Dokumentdienst, `embed`, `rerank`, `chat`, `chat-noreasoning`.
+  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`.
+- **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
+  und erst nach der Datenschutzfreigabe (Fragen A19, B6, C2).
+- **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
+  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.
 - **Pause:** KW 52–53 (21.12.2026 – 03.01.2027).
-- **Echte Daten:** Entwickelt wird mit öffentlichen GAEB-Beispieldateien und einem
-  anonymisierten Beispielablauf von BauIn. Echte Pilotdaten nur auf den Servern von ITM und
-  erst nach Klärung des Datenschutzes.
-- **Abhängigkeit:** Viele Pakete brauchen Zulieferungen von ITM und BauIn. Kommen sie später als
-  unten geplant, verschiebt sich der Plan entsprechend.
 
-## Meilensteine
+## 5. Meilensteine mit Abnahmekriterien
 
-| | Termin | Ergebnis | Termin mit dem Kunden |
+| | Termin | Abnahmekriterien |
-|---|---|---|---|
+|---|---|---|
-| – | Fr 16.10. | Statusbericht mit Screenshots, Plan, Kostenrahmen, offene Fragen | Termin BauIn |
+| – | Fr 16.10. (KW 42) | Termin BauIn: Statusbericht, Plan, Kostenrahmen (ITM), ★-Fragen besprochen, Liefertermine vereinbart |
-| **M1** | Fr 30.10. (KW 44) | Grundgerüst: Login/2FA, Benutzer und Rollen, Projekte mit PFA und Verträgen, Upload, Protokoll; erste LVs aus X86 importiert und als Baum mit Vorbemerkungen sichtbar; Detailplan steht | Demo (30 min) |
+| **M1** | Fr 30.10. (KW 44) | Siehe unten |
-| **M2** | Fr 20.11. (KW 47) | Pilot-PFA auf Staging bei ITM; **LV-Suche** über alle LVs eines Vertrags, PFA oder Projekts mit Sprung ins PDF; **Vorprüfung Stufe 1** (Fundstellen je Nachtragsposition) für die ersten Nachträge | Prüftermin (60 min) |
+| **M2** | Fr 20.11. (KW 47) | Siehe unten |
-| **M3** | Fr 18.12. (KW 51) | Nachträge durchgängig: Vorprüfung mit Sprachmodell (enthalten?, Bezugsposition, Begründung mit Quellen), Prüfmaske, Feedback, Regeln, Ergebnisliste; Bewertungsmatrix, falls die Vorlage da ist | Präsentation (60–90 min) |
+| **M3** | Fr 18.12. (KW 51) | Siehe unten |
-| **M4** | Fr 29.01.2027 (KW 4) | Alle Nachträge des Pilot-PFA durchlaufen, Trefferquote und Zeitersparnis gemessen; Produktion abgesichert; Stellungnahme als Option | Abschluss, Entscheidung über Phase 2 |
+| **M4** | Fr 29.01.2027 (KW 4) | Siehe unten |
-| Puffer | KW 5–6/2027 | für Verzögerungen bei Zulieferungen oder Import | – |
+| Puffer | KW 5–6/2027 | für Verzögerungen bei Zulieferungen oder Import |
 
-Die LV-Suche (M2) nützt BauIn schon vor der KI-Beurteilung: Heute werden bis zu 28 LVs einzeln
+**M1 – Grundgerüst** (Demo 30 min, lokal oder auf Staging):
-nach Stichworten durchsucht.
+- Ein Administrator legt Benutzer an; Anmeldung mit 2FA funktioniert.
+- 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
+  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.
 
-**Laufend:** Termine mit BauIn freitags, etwa alle zwei bis drei Wochen, vorher ein kurzer
+**M2 – LV-Suche und erste Vorprüfung** (Prüftermin 60 min, auf Staging):
-Statusbericht mit Screenshots.
+- Staging bei ITM läuft, der Pilot-PFA ist importiert (nach Datenschutzfreigabe).
+- 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
+  den ersten drei ist.
 
-## Arbeitspakete und Aufwand
+**M3 – Nachträge durchgängig** (Präsentation 60–90 min):
+- Prüfmaske mit Einschätzung „im Vertrag enthalten?“, Bezugsposition und Begründung mit
+  anklickbaren Quellen.
+- Feedback und Korrektur, Regeln mit Freigabe, Ergebnisliste mit Excel-Export.
+- Bewertungsmatrix (OP1), falls die Vorlage rechtzeitig da war.
+- Produktionsserver steht.
 
-PW ohne KI = klassische Schätzung; PW mit Claude Code = deine Zeit, wenn Claude Code den Code schreibt.
+**M4 – Pilot abgeschlossen** (Abschluss):
+- Alle Nachträge des Pilot-PFA sind durchlaufen.
+- Kennzahlen liegen vor: richtige Fundstelle unter den ersten drei in X % (Ziel aus Frage A21),
+  Prüfzeit je Nachtrag vorher und nachher.
+- Produktion mit Backups, Alarmierung und erfolgreichem Restore-Test, Betriebsdoku.
+- Entscheidung über Phase 2.
 
-| AP | Inhalt | PW ohne KI | PW mit Claude Code | Wer | Wann | Hängt ab von |
+## 6. Arbeitspakete
-|---|---|---|---|---|---|---|
-| AP0 | Klärung, Kundentermine, Statusberichte, Dokumentation | 1,0 | 0,75 | Du | laufend | – |
-| AP1 | Fundament: Umgebung ✓, Laravel/TallStackUI ✓, Mehrsprachigkeit ✓; offen: CI, Datenmodell (Mandant, Land, Projekt, PFA, Vertrag, LV, Dokument, Nachtrag, Nachtragsposition), Rollen/Rechte mit Benutzerverwaltung, privater Upload und Download inkl. Massen-Upload, Protokoll, Länderstruktur | 3,0 (+1,0 ✓) | 1,25 | Du + CC | KW 41–42 | Rollenmodell (Kunde) |
-| AP2 | Meilisearch-Test: Teil 1 mit erzeugten Vektoren, Teil 2 mit echten Vektoren und Referenzfällen | 0,5 | 0,25 | Du + CC | KW 41 / KW 46 | Teil 2: Staging, Referenzfälle |
-| AP3 | Anbindung KI-API ITM (API-Werk): Dokumentdienst mit Polling, `embed`, `rerank`, `chat` mit Streaming; Ratenbegrenzung (120/min je Schlüssel), begrenzte Wiederholung ohne Doppel-Einreichung, Verbrauchsprotokoll, Überwachung; Schlüssel verschlüsselt in der Datenbank (Verwaltung, nur beschreibbar), in der Entwicklung über den Schlüssel-Proxy ✓ | 1,5 | 0,5 | Du + CC | KW 42 | API-Schlüssel (ITM) |
-| AP4 | Indexierung und Suche: LV-Positionen und Vorbemerkungen aus GAEB, Texte aus PDFs ohne GAEB → Embeddings → MySQL + Meilisearch; hybride LV-Suche mit Pflichtfilter für Rechte und Suchreihenfolge (Vertrag → PFA → Projekt); Neuaufbau des Index | 2,0 | 1,0 | Du + CC | KW 44–45 | AP3, AP5 |
-| AP5 | GAEB-Import (X86): Parser, LV-Baum, Vorbemerkungen, LV-Ansicht; PDF-Anzeige (pdf.js lokal) mit Sprung zur Position; Nachtrags-Import (Nachtrags-LV als X86, sonst PDF über OCR) | 2,5 | 1,25 | Du + CC | KW 41 (Test), KW 43–45 | Beispieldateien |
-| AP6 | Vorprüfung Stufe 1 (ohne Sprachmodell): je Nachtragsposition Fundstellen mit Reranker, Nachtragsübersicht, Prüfmaske, Feedback je Aspekt, Confidence | 2,5 | 1,25 | Du + CC | KW 46–47 | AP4, AP5 |
-| AP7 | Vorprüfung Stufe 2 (mit Sprachmodell): „im Vertrag enthalten?“, Bezugsposition und Unterschied bei geänderter Leistung, Begründung mit Quellen, Prüfung der Antwort | 2,0 | 1,0 | Du + CC | KW 48–49 | AP6 |
-| AP8 | Regeln, Referenzfälle, einstellbare Freigaben, Versionen | 2,0 | 0,75 | Du + CC | KW 49–50 | Freigabe-Variante (Kunde) |
-| AP9 | Nachtragsstatus, Ergebnisliste je Nachtrag, einfacher Excel-Export | 0,5 | 0,25 | Du + CC | KW 50 | – |
-| AP10 | Dashboard, Benachrichtigungen, Auswertungen, allgemeine Dokumente (Einstellungen) | 0,75 | 0,5 | Du + CC | KW 2 | – |
-| AP11a | Betrieb, unser Teil: Server-Anforderungen, Deploy-Skript, Vorlagen für Nginx/systemd/Cron, Backup- und Alarm-Skripte, Betriebsdoku | 1,5 | 0,5 | Du + CC | KW 41, KW 44, KW 3 | – |
-| AP11b | Betrieb, ITM: Staging- und Produktionsserver aufbauen, TLS, Backup-Ziel, Überwachung, Restore-Test | (in AP11a) | ITM 1–1,5 | ITM | KW 42–44, KW 50–51, KW 3 | Server-Anforderungen |
-| AP12 | Pilot: alle Nachträge des Pilot-PFA durchlaufen, messen, nachschärfen (Prompts, Gewichtung, Quantisierung) | 2,0 | 1,5 | Du + CC | KW 1–2/2027 | Referenzfälle, Fachexperte |
-| AP13 | Design aus Claude Design (Prototyp, Stand in `ClaudeDesign_Stand_2026-10-02.md`) als TallStackUI-Designsystem übernehmen: Tokens, Schriften lokal, Phosphor-Icons über Blade-Paket | 1,0 | 0,5 | Du + CC | KW 43 | Prüfmaske v3 und Grundlagen von Claude Design |
-| | **Summe Kern (offen)** | **≈ 22,75** | **≈ 11,25** (+ ITM 1–1,5) | | | |
-| OP1 | Option: Bewertungsmatrix in der Excel-Vorlage der DB füllen | 1,0 | 0,5 | Du + CC | KW 51 | Vorlage (BauIn) |
-| OP2 | Option: Stellungnahme BÜW als Word-Datei aus Vorlage | 1,0 | 0,5 | Du + CC | KW 2 | Vorlage (BauIn) |
 
-Gegenüber dem Stand vom 01.10. entfallen der GAEB-90-Import (D86), der Webhook-Eingang, der
+PW = deine Personenwochen mit Claude Code. Status nach Abschnitt 1.
-Vorschlag einer Anspruchsgrundlage und die kuratierte Wissensbasis (wird Phase 3). Dazu kommen
-PDF-Anzeige mit Sprung zur Position, Massen-Upload, Suchreihenfolge über PFAs und die Bezugsposition.
 
-## Zeitplan nach Kalenderwochen
+| 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 |
+| 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 |
+| AP5 | [GAEB-Import und PDF-Anzeige](plaene/AP05-gaeb-pdf.md) | 1,25 | KW 41 / KW 43–45 | detailliert, wartet auf Freigabe | A3, A5, A18 |
+| AP6 | [Vorprüfung Stufe 1 und Prüfmaske](plaene/AP06-vorpruefung-stufe1.md) | 1,25 | KW 46–47 | grob geplant | AP4, AP5, AP13 |
+| AP7 | [Vorprüfung Stufe 2 mit Sprachmodell](plaene/AP07-vorpruefung-stufe2.md) | 1,0 | KW 48–49 | grob geplant | AP6, C6 |
+| AP8 | [Regeln, Referenzfälle, Freigaben](plaene/AP08-regeln.md) | 0,75 | KW 49–50 | grob geplant | A23, A24 |
+| AP9 | [Ergebnisliste und Export](plaene/AP09-ergebnis-export.md) | 0,25 | KW 50 | grob geplant | A9 |
+| 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 |
+| | **Summe Kern** | **≈ 11,25** | | | |
+| OP1/OP2 | [Optionen: Bewertungsmatrix, Stellungnahme](plaene/OP-optionen.md) | je 0,5 | KW 51 / KW 2 | grob geplant | A14, A15 |
+
+Bereits erledigt (KW 40–41):
+- Entwicklungsumgebung, Grundgerüst mit TallStackUI und Mehrsprachigkeit
+- Server-Anforderungen, Schlüssel-Proxy mit Sperren, gitleaks-Regel
+- Datenmodell Kern. Es wurde vor dem Teilplan umgesetzt; das Review steht in AP1, Schritt 1.4.
+
+## 7. Zeitplan nach Kalenderwochen
 
 | KW | Datum | Du + Claude Code | ITM-Entwickler | Kunde / gemeinsam |
 |---|---|---|---|---|
-| 40 | 28.09.–04.10. | ✓ Umgebung, Grundgerüst, TallStackUI, Mehrsprachigkeit, Doku, Plan | – | ✓ Besprechung BauIn (02.10.) |
+| 40 | 28.09.–04.10. | ✓ Umgebung, Grundgerüst, TallStackUI, Mehrsprachigkeit, Doku | – | ✓ Besprechung BauIn (02.10.) |
-| 41 | 05.–11.10. | Datenmodell Kern; Benutzer, Rollen, Rechte; CI; Meilisearch-Test Teil 1; GAEB-X86-Test mit öffentlichen Beispielen; Server-Anforderungen an ITM | API-Schlüssel für die Entwicklung, Antworten auf Teil C, Preise | Fragenkatalog raus; Übergabe 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; Rückmeldung an Claude Design |
-| 42 | 12.–18.10. | Projekte, PFA, Verträge; Upload und Massen-Upload; Protokoll; API-Client und Schnelltest; Statusbericht; Aufwand an ITM (14.10.) | Staging-Server aufbauen | **Termin BauIn 16.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. | Detailplan und Teilpläne; GAEB-Import (LV-Baum, Vorbemerkungen), LV-Ansicht; Designsystem übernehmen | Staging: Meilisearch, Worker, Cron, TLS | – |
+| 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 |
-| 44 | 26.10.–01.11. | PDF-Anzeige mit Sprung zur Position; Indexierung → Embeddings → MySQL + Meilisearch; Deploy-Skript | Staging fertig, Deployment aus Gitea | **M1 Demo 30.10.** |
+| 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. | Hybride LV-Suche mit Rechtefilter und Suchreihenfolge; Nachtrags-Import; erste Bereitstellung auf Staging | Unterstützung | – |
+| 45 | 02.–08.11. | Indexierung, hybride LV-Suche mit Rechtefilter; Nachtrags-Import | Unterstützung | – |
-| 46 | 09.–15.11. | Vorprüfung Stufe 1: Fundstellen + Reranker; Nachtragsübersicht; Pilot-PFA auf Staging importieren (du, echte Daten); Meilisearch-Test Teil 2 | – | – |
+| 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, Feedback, Confidence | – | **M2 Prüftermin 20.11.** |
+| 47 | 16.–22.11. | Prüfmaske v3 ohne Sprachmodell, Feedback; Dashboard (Teil 1) | – | **M2 Prüftermin 20.11.** |
-| 48 | 23.–29.11. | Sprachmodell: „enthalten?“, Bezugsposition, strukturierte Antwort, Prüfung der Antwort | – | – |
+| 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, Freigaben, Versionen; Ergebnisliste und Excel-Export | Produktionsserver aufbauen | – |
+| 50 | 07.–13.12. | Regeln und Freigaben; Ergebnisliste, Excel-Export | Produktionsserver | – |
-| 51 | 14.–20.12. | Option OP1 Bewertungsmatrix (falls Vorlage da und Stunden erhöht); Feinschliff | Produktion fertig | **M3 Präsentation 18.12.** |
+| 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 durchlaufen, messen | – | Fachexperte bewertet |
+| 1 | 04.–10.01. | Pilot: alle Nachträge des Pilot-PFA, messen | – | Fachexperte bewertet |
-| 2 | 11.–17.01. | Nachschärfen; Dashboard, Auswertungen, Benachrichtigungen; Option OP2 Stellungnahme (falls Stunden erhöht) | – | Demo 15.01. |
+| 2 | 11.–17.01. | Nachschärfen; Dashboard, Auswertungen; OP2 Stellungnahme (falls Stunden) | – | 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 | – |
 
-## Zulieferungen von ITM und BauIn (Soll-Termine)
+## 8. Zulieferungen
 
-| Bis | Von | Was | Gebraucht für |
+| Bis | Von | Was | Für |
 |---|---|---|---|
-| ✓ 02.10. | ITM | API-Dokumentation (API-Werk: Dokumentdienst, `chat`, `chat-noreasoning`, `embed`, `rerank`) | AP3 |
+| ✓ 02.10. | ITM | API-Dokumentation | AP3 |
-| KW 41 | ITM | API-Schlüssel für die Entwicklung; Antworten auf die ITM-Fragen; Preise der API für den Kostenrahmen | AP3, Kostenrahmen |
+| KW 41 | ITM | API-Schlüssel für die Entwicklung, Antworten Teil C, Preise | AP3, Kostenrahmen |
-| KW 41 | BauIn | Antworten auf die ★-Fragen | Detailplan |
+| KW 41 | BauIn | Antworten auf die ★-Fragen | Teilpläne |
-| KW 41 | wir → ITM | Server-Anforderungen (Ausstattung, Software und Versionen, Dienste, Ports, Backups) | AP11b |
+| ✓ KW 41 | wir → ITM | Server-Anforderungen (noch verschicken) | AP11 |
-| 16.10. | BauIn | Matrix-Vorlage (leer + 2–3 ausgefüllt), Word-Vorlage Stellungnahme, anonymisierter Beispielablauf (LVs als X86 + PDF, Nachträge mit Nachtrags-LV und Anschreiben) | AP5, AP9, OP1, OP2 |
+| KW 42 | Claude Design | Neuer Stand nach unserer Rückmeldung: Übergabe und `.dc.html`-Dateien | AP13 |
-| KW 43 | BauIn | Entscheidung Rollenmodell, Freigabe-Variante, Anmeldung (2FA oder Microsoft-Konto) | AP1, AP8 |
+| 16.10. | BauIn | Matrix-Vorlage (leer und ausgefüllt), Word-Vorlage, anonymisierter Beispielablauf | AP5, AP9, OP1, OP2 |
-| KW 43 | BauIn, ITM | Freigabe Datenschutz für echte Pilotdaten auf den Servern von ITM und über die KI-API | M2 |
+| KW 43 | BauIn | Entscheidung Rollen, Freigabe-Variante, Anmeldung | AP1, AP8 |
-| KW 44 | ITM | Staging-Server mit Zugang, Domain und Zertifikat | M2 |
+| KW 43 | BauIn, ITM | Datenschutzfreigabe für echte Pilotdaten | M2 |
-| KW 46 | BauIn | Pilotdaten: alle LVs eines PFA als X86 + PDF (nur auf Staging) | M2 |
+| KW 44 | ITM | Staging-Server mit Zugang, Domain, Zertifikat | M2 |
-| KW 47 | BauIn | 10–20 abgeschlossene Nachträge mit Ergebnis (Referenzfälle) | AP2 Teil 2, AP12 |
+| KW 46 | BauIn | Pilotdaten: alle LVs eines PFA (X86 + PDF), nur auf Staging | M2 |
-| KW 51 | ITM | Produktions-Server mit Zugang, Domain und Zertifikat | AP11 |
+| KW 47 | BauIn | 10–20 abgeschlossene Nachträge mit Ergebnis | AP2, AP12 |
-| KW 51 | offen | Backups: Speicherort, Aufbewahrungsdauer, Zuständigkeit | AP11 |
+| KW 51 | ITM | Produktionsserver | AP11 |
+| KW 51 | offen | Backups: Ziel, Aufbewahrung, Zuständigkeit | AP11 |
 
-## Risiken
+## 9. Risiken
 
 | Risiko | Auswirkung | Gegenmaßnahme |
 |---|---|---|
-| Zulieferungen kommen spät | Pakete verschieben sich | Soll-Termine am 16.10. vereinbaren; vorziehen, was unabhängig ist |
+| Zulieferungen kommen spät | Pakete verschieben sich | Termine am 16.10. vereinbaren; Unabhängiges vorziehen |
-| Kein anonymisierter Beispielablauf, Datenschutz für echte Daten ungeklärt | Kein realistischer Test vor M2 | Öffentliche GAEB-Beispiele; früh anfragen; echte Daten nur auf Staging |
+| Datenschutz für echte Daten bleibt offen | Kein realistischer Test, M2 gefährdet | Früh fragen (A19, B6, C2); bis dahin anonymisierte Daten |
-| Vibe Coding: Fehler in sicherheitskritischen Teilen (Rechte, Dateizugriff, Suchfilter) fallen nicht auf | Unbefugte sehen vertrauliche Inhalte | Rechte-Tests für jede geschützte Aktion Pflicht; CI blockiert; diese Stellen sieht sich jemand gezielt an (Regeln in `CLAUDE.md`) |
+| 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 mit echten Nachträgen dauert länger | Messskript auf Staging liefert Kennzahlen; anonymisierte Problemfälle zurückgeben |
+| Claude Code sieht keine echten Daten | Nachschärfen dauert länger | Messskripte mit Kennzahlen; anonymisierte Problemfälle |
-| Nur eine Person kennt die Anwendung | Krankheit oder Urlaub stoppt das Projekt | Doku, `CLAUDE.md`, Tests und Teilpläne aktuell halten; ITM-Entwickler kennt den Betrieb |
+| Nur eine Person kennt die Anwendung | Ausfall stoppt das Projekt | Doku, Teilpläne, Tests aktuell halten |
-| X86-Dateien weichen vom Standard ab (Version, Erweiterungen des Kalkulationsprogramms) | GAEB-Import aufwendiger | Beispieldatei früh anfordern; fertige Bibliothek prüfen; D86 als Rückfall |
+| X86 weicht vom Standard ab | GAEB-Import aufwendiger | Beispieldatei früh (A18); D86 als Rückfall |
-| Sprachmodell liefert keine verlässliche strukturierte Antwort | Stufe 2 schwächer | Antwort im Code prüfen; Stufe 1 (Suche + Reranker) ist allein schon nützlich |
+| Sprachmodell antwortet unzuverlässig strukturiert | Stufe 2 schwächer | Prüfung im Code; Stufe 1 allein schon nützlich |
-| Meilisearch mit 4.096 Dimensionen zu langsam | Suche muss umgebaut werden | Test in KW 41; Plan B Qdrant |
+| Meilisearch mit 4.096 Dimensionen zu langsam | Suche muss umgebaut werden | Test KW 41; Plan B Qdrant |
-| KI-API ausgelastet (120 Anfragen/min je Schlüssel, für alle Nutzer gemeinsam) | Lange Wartezeiten bei Erstindexierung und Suche | Alles asynchron; Stapel-Embeddings; Suchanfragen bevorzugen; ggf. getrennte Schlüssel |
+| KI-API ausgelastet (120/min gemeinsam) | Wartezeiten | Asynchron, Stapel, Vorrang für Suchanfragen (C8) |
-| Excel-Vorlage der DB enthält Makros | Export kann Makros verlieren (OP1) | Vorlage früh testen; notfalls Werte zum Einfügen exportieren |
+| Excel-Vorlage der DB mit Makros | OP1 schwieriger | Vorlage früh testen |
-| Fachexperte wenig verfügbar | Kein Feedback, keine Messung | Feste Freitagstermine; Referenzfälle früh anfordern |
+| Fachexperte wenig verfügbar | Keine Messung | Feste Freitagstermine, Referenzfälle früh |
 
-## Aufgabenliste (nächste zwei Wochen)
+## 10. Entscheidungen
 
-**Erledigt**
+| Datum | Entscheidung | Wer |
-- [x] Entwicklungsumgebung (WSL2, Docker, Sail), Repo mit gitleaks-Hook
+|---|---|---|
-- [x] Laravel 13, Livewire 4, TallStackUI 4, Fortify (2FA, Passkeys), Spatie
+| 01.10. | Laravel 13, Livewire 4, TallStackUI 4, PHP 8.5, MySQL + Meilisearch, kein Redis | du |
-- [x] Mehrsprachigkeit (Deutsch Standard, Englisch)
+| 02.10. | Phase 1 nur „dem Grunde nach“, Nachträge statt MKA, Höhe Phase 2, Regelwerk Phase 3 | BauIn, du |
-- [x] CLAUDE.md, Tech-Stack-Doku, Projektplan
+| 02.10. | Team: du + Claude Code (Vibe Coding), ITM-Entwickler für KI-API und Server | du |
-- [x] Besprechung mit BauIn (02.10.), API-Dokumentation von ITM erhalten
+| 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 |
 
-**KW 41**
+Offene Entscheidungen stehen in den Teilplänen unter „Entscheidungen“.
-- [ ] Fragenkatalog an BauIn (fachlich, IT) und ITM schicken
-- [ ] Rückmeldung an Claude Design geben (`Rueckmeldung_an_ClaudeDesign_2026-10-02.md`): Prüfmaske v3, Projekt, Nachtrag anlegen, Suche
-- [x] Server-Anforderungen an den ITM-Entwickler (`docs/server-anforderungen.md`, noch verschicken)
-- [x] Schlüssel-Proxy für die Entwicklung (`tools/ki-proxy`), Sperr-Hook für Claude Code, gitleaks-Regel für API-Werk-Schlüssel
-- [ ] API-Schlüssel in die Windows-Anmeldeinformationsverwaltung eintragen (du), Proxy starten
-- [ ] API-Schlüssel für die Entwicklung bei ITM anfordern
-- [ ] **Meilisearch-Test Teil 1** (erzeugte 4.096-dim. Vektoren, z. B. 50.000 Stück):
-  Indexierungszeit, Antwortzeit mit Filtern, RAM und Platte; jeweils ohne und mit binärer Quantisierung
-- [x] Datenmodell Kern: Mandant, Land, Projekt, PFA, Vertrag, LV, Dokument (Kategorie,
-  Vertraulichkeit), Nachtrag, Nachtragsposition, Mitgliedschaften (`docs/datenmodell.md`, Demodaten)
-- [ ] Benutzerverwaltung, Rollen und Rechte (Spatie, ggf. Teams je Projekt)
-- [ ] GAEB-X86-Test mit öffentlichen Beispieldateien, Bibliothek auswählen
-- [ ] CI in Gitea Actions: Tests, Pint, PHPStan
-- [ ] Commits nach Gitea pushen
 
-**KW 42**
+## 11. Nach Phase 1
-- [ ] Aufwand für den Kostenrahmen an ITM (bis 14.10.)
-- [ ] Projekte, PFA und Verträge; Upload, privater Speicher, Download mit Rechteprüfung, Massen-Upload; Protokoll
-- [ ] API-Client und Schnelltest (Modellverzeichnis, Dimension von `embed`, `rerank`, `chat` mit Streaming)
-- [ ] Statusbericht mit Screenshots für den 16.10.
-- [ ] **Termin BauIn 16.10.:** Antworten in Plan und Doku übernehmen, Soll-Termine vereinbaren
-- [ ] Design-Feedback an Claude Design
 
-**Später im Plan (bereits vorgemerkt)**
+- **Phase 2 – Prüfung der Höhe nach:**
-- [ ] Detailplan mit Teilplänen je Arbeitspaket (KW 43)
+  - Preis gegen Bezugsposition und gleiche Leistung in anderen PFAs vergleichen.
-- [ ] **Meilisearch-Test Teil 2** (KW 46): Trefferquote mit echten API-Vektoren und Referenzfällen,
+  - Auszüge der Urkalkulation und Nachtragskalkulation einbeziehen.
-  ohne/mit binärer Quantisierung, vor und nach dem Reranker
+- **Phase 3 – Regelwerk:**
-- [ ] Push-Mirror zum Gitea von ITM einrichten, sobald die Adresse vorliegt
+  - Richtlinien der DB (263 PDFs, 743 MB) in die Suche aufnehmen.
-- [ ] 2FA-Pflicht oder Microsoft-Anmeldung umsetzen, je nach Entscheidung des Kunden
+  - 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)
+  - Bauzeitenplan-Analyse, weitere Sprachen
+- **Nebenprojekt datenschleuse:** Phase 1–2 muss fertig sein, bevor echte Kundendateien mit Claude
+  bearbeitet werden. Sie hilft beim anonymisierten Beispielablauf.
 
-## Ausbaustufen nach Phase 1
+## 12. Änderungen an diesem Plan
 
-- **Phase 2 – Prüfung der Höhe nach:** Preis der Nachtragsposition gegen Bezugsposition und
+| Datum | Änderung |
-  gleiche Leistung in anderen PFAs, Auszüge aus der Urkalkulation, Nachtragskalkulation. Die
+|---|---|
-  vollständige Urkalkulation liegt versiegelt bei der DB; dort prüft der Einkauf die Höhe.
+| 01.10. | Erster Plan (MVP, 2 Entwickler) |
-- **Phase 3 – Regelwerk:** Richtlinien der DB (Auszug, mit dem BauIn zu rund 80 % arbeitet:
+| 02.10. | Nach Besprechung mit BauIn: Umfang, Gliederung, Optionen, Ausbaustufen; Team du + Claude Code; 30 h/Woche |
-  263 PDF-Dateien, 743 MB, z. B. Ril 821, 824, 836) in die Suche aufnehmen, dazu ein interner
+| 05.10. | Neu gegliedert: Arbeitsweise mit Freigaben, Meilensteine mit Abnahmekriterien, Teilpläne je Arbeitspaket, Fragenliste mit Status in `docs/fragen.md` |
-  Chat, der mit PDF, Seite und Stelle zitiert. Phase 1 legt die Grundlagen: Dokumentspeicher,
-  Abschnitte mit Seitenbezug, Quellenanzeige im PDF.
-- **Weitere Ideen:** Dokumentenmanagement, E-Mail-Anbindung, Anbindung an das
-  Dokumentensystem der DB, Österreich (ÖNORM B 2110/B 2118, ÖNORM A 2063),
-  Bauzeitenplan-Analyse, weitere Sprachen.
-
-## Nebenprojekt außerhalb des Budgets
-
-- **datenschleuse** (lokaler Scanner/Bereiniger, Prompt in `Prompt_Datenschleuse.md`):
-  mindestens Phase 1–2 fertig, bevor echte Kundendateien mit Claude bearbeitet werden. Bis dahin
-  gehen echte Kundendateien nicht an Claude. Hilft auch beim anonymisierten Beispielablauf.