BauIN/docs/projektplan.md

# KI-BauIN – Projekt- und Zeitplan (Phase 1)

Stand: 2. Oktober 2026 (KW 40), nach der ersten Besprechung mit BauIN und der API-Dokumentation
von ITM. Sobald die Antworten auf den Fragenkatalog vorliegen (Ziel: Termin am 16.10.), wird
daraus der Detailplan mit Teilplänen je Arbeitspaket.

## Beteiligte

- **ITM:** Anbieter der KI-API (über API-Werk: Dokumentdienst mit OCR, Embeddings, Reranker,
  Sprachmodell), Projektleitung und abrechnende Firma. Stellt auch die Server (Staging,
  Produktion) und den Gitea, auf den das Repository gespiegelt wird.
- **BauIn:** Endkunde. Prüft als Bauüberwachung im Auftrag der DB die Nachträge der
  Auftragnehmer dem Grunde nach. Liefert Fachdaten (LVs, Nachträge, Bewertungsmatrizen),
  stellt den fachlichen Ansprechpartner (Nachtragsbearbeitung) und eine Ansprechpartnerin für IT.
- „Kunde“ meint in diesem Dokument BauIn; wo ITM gemeint ist, steht ITM.

## Ergebnis der Besprechung vom 02.10.2026

Was sich gegenüber dem Stand vom 01.10. ändert:

- **Geprüft werden Nachträge, nicht MKAs.** Aus einer MKA entsteht (oder auch nicht) nach
  einigen Wochen ein Nachtrag; das ist nicht 1:1. Der Nachtrag enthält ein Nachtrags-LV mit
  Positionen (GAEB und PDF), ein Anschreiben, die Kalkulation und Anlagen. Die MKA-Nummer ist nur
  noch ein Bezug am Nachtrag.
- **Die KI beantwortet je Nachtragsposition eine Frage:** Ist die Leistung schon im Vertrag
  enthalten, also in den LVs einschließlich Vorbemerkungen? Wenn ja, ist der Nachtrag dem Grunde
  nach nicht berechtigt. Schwerpunkt sind geänderte Leistungen (§ 2 Abs. 5 VOB/B, mit Rückgriff
  auf eine Hauptvertragsposition) und zusätzliche Leistungen (§ 2 Abs. 6 VOB/B). Mengenänderungen
  (§ 2 Abs. 3) kommen selten vor und bekommen keine eigene Logik.
- **Nicht Aufgabe der KI:** die rechtliche Einordnung (richtiger Paragraf), Fristen und
  Vollständigkeit der Anzeige, Leistungen ohne Auftrag (§ 2 Abs. 8), Behinderungen (§ 6 Abs. 6),
  Anordnungen des Auftraggebers. Das prüft BauIn selbst.
- **Gliederung:** Projekt → PFA (Planfeststellungsabschnitt, im Pilot PFA 1–4) → Vertrag mit
  einem Auftragnehmer (je PFA mehrere, z. B. Gleisbau, Tunnelbau, Oberleitung) → mehrere LVs
  (im PFA 4 z. B. 28). Ein „Los“ im bisherigen Plan entspricht einem Vertrag.
- **Suchreihenfolge:** zuerst die LVs des betroffenen Vertrags, dann als Hinweis die anderen PFAs
  desselben Projekts (Fall: Leistung im PFA 3 beauftragt, im PFA 4 vergessen und dort per
  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

- **Ziel von Phase 1:** Positionsanalyse dem Grunde nach am Pilotprojekt. Vom hochgeladenen
  Nachtrag bis zur Ergebnisliste je Position mit Fundstellen, Begründung und Entscheidung des
  Bearbeiters, mit Rollen und Rechten, Protokoll und Betrieb auf den Servern von ITM.
- **Grundhaltung:** Die KI schlägt vor und belegt mit Fundstellen, der Mensch entscheidet.
  Rückmeldungen fließen in ein Confidence-System mit Referenzfällen und Regeln.
- **Team:**
  - **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,
    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.
  - **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,
    Cron, TLS, Backups).
  - Annahme zur Abgrenzung: Prompts und Prüflogik bauen wir, weil sie eng mit Oberfläche und
    Feedback verzahnt sind; ITM berät zu Modellen und Grenzen. Bestätigung steht aus.
- **Aufwand** in deinen Personenwochen (PW) mit Claude Code: Kern rund 11 PW, mit Puffer 13–14 PW,
  Optionen je 0,5 PW. Ohne KI-Unterstützung wären es rund 23 PW. Dazu kommen beim
  ITM-Entwickler etwa 1–1,5 PW für die Server. Werkzeugkosten (Claude Code) sind nicht enthalten.
- **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
  werden Klärung mit dem Kunden, Warten auf Zulieferungen, das Nachschärfen mit echten Daten
  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.
- **Verfügbarkeit (Annahme):** du arbeitest an 4–5 Tagen pro Woche an KI-BauIN. Bei etwa der
  halben Woche verschiebt sich M4 auf Ende März bis Mitte April 2027.
- **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,
  in die beiden Optionen und in Puffer, nicht in ein früheres Ende.
- **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

| | Termin | Ergebnis | Termin mit dem Kunden |
|---|---|---|---|
| – | Fr 16.10. | Statusbericht mit Screenshots, Plan, Kostenrahmen, offene Fragen | Termin BauIn |
| **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) |
| **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) |
| **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) |
| **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 |
| 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
nach Stichworten durchsucht.

**Laufend:** Termine mit BauIn freitags, etwa alle zwei bis drei Wochen, vorher ein kurzer
Statusbericht mit Screenshots.

## Arbeitspakete und Aufwand

PW ohne KI = klassische Schätzung; PW mit Claude Code = deine Zeit, wenn Claude Code den Code schreibt.

| AP | Inhalt | PW ohne KI | PW mit Claude Code | Wer | Wann | Hängt ab von |
|---|---|---|---|---|---|---|
| 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 | 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 als TallStackUI-Designsystem übernehmen | 1,0 | 0,5 | Du + CC | KW 43 | Designentwurf |
| | **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
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

| 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.) |
| 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 |
| 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.** |
| 43 | 19.–25.10. | Detailplan und Teilpläne; GAEB-Import (LV-Baum, Vorbemerkungen), LV-Ansicht; Designsystem übernehmen | Staging: Meilisearch, Worker, Cron, TLS | – |
| 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.** |
| 45 | 02.–08.11. | Hybride LV-Suche mit Rechtefilter und Suchreihenfolge; Nachtrags-Import; erste Bereitstellung auf Staging | 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 | – | – |
| 47 | 16.–22.11. | Prüfmaske, Feedback, Confidence | – | **M2 Prüftermin 20.11.** |
| 48 | 23.–29.11. | Sprachmodell: „enthalten?“, Bezugsposition, strukturierte Antwort, Prüfung der 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 | – |
| 51 | 14.–20.12. | Option OP1 Bewertungsmatrix (falls Vorlage da); 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 |
| 2 | 11.–17.01. | Nachschärfen; Dashboard, Auswertungen, Benachrichtigungen; Option OP2 Stellungnahme | – | 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)

| Bis | Von | Was | Gebraucht für |
|---|---|---|---|
| ✓ 02.10. | ITM | API-Dokumentation (API-Werk: Dokumentdienst, `chat`, `chat-noreasoning`, `embed`, `rerank`) | 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 | BauIn | Antworten auf die ★-Fragen | Detailplan |
| KW 41 | wir → ITM | Server-Anforderungen (Ausstattung, Software und Versionen, Dienste, Ports, Backups) | AP11b |
| 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 43 | BauIn | Entscheidung Rollenmodell, Freigabe-Variante, Anmeldung (2FA oder Microsoft-Konto) | AP1, AP8 |
| KW 43 | BauIn, ITM | Freigabe Datenschutz für echte Pilotdaten auf den Servern von ITM und über die KI-API | M2 |
| KW 44 | ITM | Staging-Server mit Zugang, Domain und Zertifikat | M2 |
| KW 46 | BauIn | Pilotdaten: alle LVs eines PFA als X86 + PDF (nur auf Staging) | M2 |
| KW 47 | BauIn | 10–20 abgeschlossene Nachträge mit Ergebnis (Referenzfälle) | AP2 Teil 2, AP12 |
| KW 51 | ITM | Produktions-Server mit Zugang, Domain und Zertifikat | AP11 |
| KW 51 | offen | Backups: Speicherort, Aufbewahrungsdauer, Zuständigkeit | AP11 |

## Risiken

| Risiko | Auswirkung | Gegenmaßnahme |
|---|---|---|
| Zulieferungen kommen spät | Pakete verschieben sich | Soll-Termine am 16.10. vereinbaren; vorziehen, was unabhängig ist |
| 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 |
| 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`) |
| 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 |
| 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 |
| 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 |
| 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 |
| Meilisearch mit 4.096 Dimensionen zu langsam | Suche muss umgebaut werden | Test in 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 |
| Excel-Vorlage der DB enthält Makros | Export kann Makros verlieren (OP1) | Vorlage früh testen; notfalls Werte zum Einfügen exportieren |
| Fachexperte wenig verfügbar | Kein Feedback, keine Messung | Feste Freitagstermine; Referenzfälle früh anfordern |

## Aufgabenliste (nächste zwei Wochen)

**Erledigt**
- [x] Entwicklungsumgebung (WSL2, Docker, Sail), Repo mit gitleaks-Hook
- [x] Laravel 13, Livewire 4, TallStackUI 4, Fortify (2FA, Passkeys), Spatie
- [x] Mehrsprachigkeit (Deutsch Standard, Englisch)
- [x] CLAUDE.md, Tech-Stack-Doku, Projektplan
- [x] Besprechung mit BauIn (02.10.), API-Dokumentation von ITM erhalten

**KW 41**
- [ ] Fragenkatalog an BauIn (fachlich, IT) und ITM schicken
- [ ] Übergabe an Claude Design: Prototyp an den neuen Umfang anpassen
- [ ] Server-Anforderungen an den ITM-Entwickler
- [ ] 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
- [ ] Datenmodell Kern: Mandant, Land, Projekt, PFA, Vertrag, LV, Dokument (Kategorie,
  Vertraulichkeit), Nachtrag, Nachtragsposition, Mitgliedschaften
- [ ] 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**
- [ ] 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)**
- [ ] Detailplan mit Teilplänen je Arbeitspaket (KW 43)
- [ ] **Meilisearch-Test Teil 2** (KW 46): Trefferquote mit echten API-Vektoren und Referenzfällen,
  ohne/mit binärer Quantisierung, vor und nach dem Reranker
- [ ] Push-Mirror zum Gitea von ITM einrichten, sobald die Adresse vorliegt
- [ ] 2FA-Pflicht oder Microsoft-Anmeldung umsetzen, je nach Entscheidung des Kunden

## Ausbaustufen nach Phase 1

- **Phase 2 – Prüfung der Höhe nach:** Preis der Nachtragsposition gegen Bezugsposition und
  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.
- **Phase 3 – Regelwerk:** Richtlinien der DB (Auszug, mit dem BauIn zu rund 80 % arbeitet:
  263 PDF-Dateien, 743 MB, z. B. Ril 821, 824, 836) in die Suche aufnehmen, dazu ein interner
  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.