From 2143f4e955623fe7b6241047a99996b2c9734f1f Mon Sep 17 00:00:00 2001 From: Christoph Date: Mon, 5 Oct 2026 08:47:05 +0200 Subject: [PATCH] =?UTF-8?q?Detaillierter=20Projektplan=20mit=20Teilpl?= =?UTF-8?q?=C3=A4nen=20und=20Fragenliste?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - 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 --- CLAUDE.md | 11 +- docs/fragen.md | 411 +++++++++++++++++++ docs/plaene/AP00-steuerung.md | 65 +++ docs/plaene/AP01-fundament.md | 126 ++++++ docs/plaene/AP02-meilisearch-test.md | 67 +++ docs/plaene/AP03-ki-api.md | 86 ++++ docs/plaene/AP04-indexierung-suche.md | 70 ++++ docs/plaene/AP05-gaeb-pdf.md | 85 ++++ docs/plaene/AP06-vorpruefung-stufe1.md | 57 +++ docs/plaene/AP07-vorpruefung-stufe2.md | 54 +++ docs/plaene/AP08-regeln.md | 42 ++ docs/plaene/AP09-ergebnis-export.md | 36 ++ docs/plaene/AP10-dashboard-auswertungen.md | 38 ++ docs/plaene/AP11-betrieb.md | 74 ++++ docs/plaene/AP12-pilot.md | 40 ++ docs/plaene/AP13-designsystem.md | 78 ++++ docs/plaene/OP-optionen.md | 31 ++ docs/plaene/_vorlage.md | 47 +++ docs/projektplan.md | 447 +++++++++++---------- 19 files changed, 1653 insertions(+), 212 deletions(-) create mode 100644 docs/fragen.md create mode 100644 docs/plaene/AP00-steuerung.md create mode 100644 docs/plaene/AP01-fundament.md create mode 100644 docs/plaene/AP02-meilisearch-test.md create mode 100644 docs/plaene/AP03-ki-api.md create mode 100644 docs/plaene/AP04-indexierung-suche.md create mode 100644 docs/plaene/AP05-gaeb-pdf.md create mode 100644 docs/plaene/AP06-vorpruefung-stufe1.md create mode 100644 docs/plaene/AP07-vorpruefung-stufe2.md create mode 100644 docs/plaene/AP08-regeln.md create mode 100644 docs/plaene/AP09-ergebnis-export.md create mode 100644 docs/plaene/AP10-dashboard-auswertungen.md create mode 100644 docs/plaene/AP11-betrieb.md create mode 100644 docs/plaene/AP12-pilot.md create mode 100644 docs/plaene/AP13-designsystem.md create mode 100644 docs/plaene/OP-optionen.md create mode 100644 docs/plaene/_vorlage.md diff --git a/CLAUDE.md b/CLAUDE.md index e562022..9a2b911 100644 --- a/CLAUDE.md +++ b/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 diff --git a/docs/fragen.md b/docs/fragen.md new file mode 100644 index 0000000..f16f75d --- /dev/null +++ b/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.) diff --git a/docs/plaene/AP00-steuerung.md b/docs/plaene/AP00-steuerung.md new file mode 100644 index 0000000..7b7bbfd --- /dev/null +++ b/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. diff --git a/docs/plaene/AP01-fundament.md b/docs/plaene/AP01-fundament.md new file mode 100644 index 0000000..48ab2d3 --- /dev/null +++ b/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///…` + - 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. diff --git a/docs/plaene/AP02-meilisearch-test.md b/docs/plaene/AP02-meilisearch-test.md new file mode 100644 index 0000000..d3b8750 --- /dev/null +++ b/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. diff --git a/docs/plaene/AP03-ki-api.md b/docs/plaene/AP03-ki-api.md new file mode 100644 index 0000000..9abe9ae --- /dev/null +++ b/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. diff --git a/docs/plaene/AP04-indexierung-suche.md b/docs/plaene/AP04-indexierung-suche.md new file mode 100644 index 0000000..6cc79bb --- /dev/null +++ b/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. diff --git a/docs/plaene/AP05-gaeb-pdf.md b/docs/plaene/AP05-gaeb-pdf.md new file mode 100644 index 0000000..9dc53b9 --- /dev/null +++ b/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. diff --git a/docs/plaene/AP06-vorpruefung-stufe1.md b/docs/plaene/AP06-vorpruefung-stufe1.md new file mode 100644 index 0000000..f876174 --- /dev/null +++ b/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. diff --git a/docs/plaene/AP07-vorpruefung-stufe2.md b/docs/plaene/AP07-vorpruefung-stufe2.md new file mode 100644 index 0000000..20fbc05 --- /dev/null +++ b/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). diff --git a/docs/plaene/AP08-regeln.md b/docs/plaene/AP08-regeln.md new file mode 100644 index 0000000..d2fb62d --- /dev/null +++ b/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. diff --git a/docs/plaene/AP09-ergebnis-export.md b/docs/plaene/AP09-ergebnis-export.md new file mode 100644 index 0000000..34bf655 --- /dev/null +++ b/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. diff --git a/docs/plaene/AP10-dashboard-auswertungen.md b/docs/plaene/AP10-dashboard-auswertungen.md new file mode 100644 index 0000000..0f42901 --- /dev/null +++ b/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. diff --git a/docs/plaene/AP11-betrieb.md b/docs/plaene/AP11-betrieb.md new file mode 100644 index 0000000..6181c8a --- /dev/null +++ b/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. diff --git a/docs/plaene/AP12-pilot.md b/docs/plaene/AP12-pilot.md new file mode 100644 index 0000000..5192c96 --- /dev/null +++ b/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. diff --git a/docs/plaene/AP13-designsystem.md b/docs/plaene/AP13-designsystem.md new file mode 100644 index 0000000..d7fe130 --- /dev/null +++ b/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. diff --git a/docs/plaene/OP-optionen.md b/docs/plaene/OP-optionen.md new file mode 100644 index 0000000..2c140be --- /dev/null +++ b/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 diff --git a/docs/plaene/_vorlage.md b/docs/plaene/_vorlage.md new file mode 100644 index 0000000..00c36c7 --- /dev/null +++ b/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 + +- … diff --git a/docs/projektplan.md b/docs/projektplan.md index b58cd53..8ba4e2c 100644 --- a/docs/projektplan.md +++ b/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 -von ITM. Sobald die Antworten auf den Fragenkatalog vorliegen (Ziel: Termin am 16.10.), wird -daraus der Detailplan mit Teilplänen je Arbeitspaket. +Stand: 5. Oktober 2026 (KW 41). Dieses Dokument ist der Gesamtplan. Die Einzelheiten stehen in +den Teilplänen unter `docs/plaene/`, offene Fragen mit Status in `docs/fragen.md`. -## Beteiligte +## Inhalt -- **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. +1. [Arbeitsweise](#1-arbeitsweise) +2. [Beteiligte und Zuständigkeiten](#2-beteiligte-und-zuständigkeiten) +3. [Ziel und Umfang](#3-ziel-und-umfang) +4. [Rahmen und Annahmen](#4-rahmen-und-annahmen) +5. [Meilensteine mit Abnahmekriterien](#5-meilensteine-mit-abnahmekriterien) +6. [Arbeitspakete](#6-arbeitspakete) +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 - 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. +1. **Teilplan detaillieren:** Vor Beginn eines Arbeitspakets beschreibt Claude Code den Teilplan + in `docs/plaene/`. Er enthält Ziel, Umfang, Schritte (je höchstens ein Tag), offene Fragen, + Entscheidungen und Abnahmekriterien. +2. **Freigabe:** Du liest den Teilplan, triffst die offenen Entscheidungen und setzt den Status + auf „freigegeben“. +3. **Umsetzung in Schritten:** Jeder Schritt endet mit grünen Tests, Pint und PHPStan und einem + Commit, der den Schritt nennt (z. B. „AP1 Schritt 1.7: …“). Änderungen an Rechten, + Dateizugriff, Suchfiltern oder KI-Aufrufen nennt Claude Code ausdrücklich. +4. **Abnahme:** Am Ende eines Arbeitspakets prüfst du die Abnahmekriterien im Browser. Danach + steht der Status auf „erledigt“, und Plan und Fragenliste werden nachgezogen. +5. **Neue Erkenntnisse zuerst in den Plan:** Antworten, neue Wünsche und Probleme kommen zuerst + in `docs/fragen.md` oder den Teilplan, dann in den Code. Ideen außerhalb des Plans kommen in + den Abschnitt [Nach Phase 1](#11-nach-phase-1). +6. **Rollierend:** Die nächsten zwei bis drei Wochen sind im Detail geplant, alles Weitere grob. + Ein Teilplan wird spätestens eine Woche vor seinem Start detailliert. +7. **Rhythmus:** Vor jedem Freitagstermin mit BauIn gibt es einen Statusbericht mit Screenshots. + Danach werden Antworten und Termine eingepflegt. -## 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 - 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:** 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 - das ≈ 11,25 PW, also genau der Kern ohne Reserve; der Puffer in KW 5–6 bringt ≈ 1,5 PW. - **Empfehlung:** in KW 44–51 (vor M2 und M3) auf 35–40 Stunden erhöhen. Das deckt die beiden - Optionen und etwas Reserve. Sonst rücken die Optionen hinter M4. -- **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. +**Definition of Done, für jeden Schritt:** +- Tests sind vorhanden und grün, bei geschützten Aktionen auch ohne Berechtigung. +- Pint und PHPStan Stufe 7 laufen ohne Fehler. +- Sichtbare Texte stehen in `__()` und sind übersetzt. +- Keine externen Ressourcen, keine Geheimnisse, keine echten Kundendaten. +- Doku und Teilplan sind aktualisiert, der Commit ist auf Deutsch. + +## 2. Beteiligte und Zuständigkeiten + +| Wer | Aufgabe im Projekt | +|---|---| +| **Du** (Entwicklung, Steuerung) | Planung freigeben, entscheiden, im Browser testen, mit BauIn und ITM sprechen, echte Daten auf Staging testen, pushen. Du schreibst selbst keinen Code. | +| **Claude Code** | Teilpläne ausarbeiten, den gesamten Code mit Tests schreiben, Doku, Statusberichte entwerfen. Sieht keine echten Kundendaten und keine API-Schlüssel. | +| **ITM-Entwickler** | KI-API (API-Werk, Modelle, Schlüssel, Grenzen), Aufbau von Staging- und Produktionsserver nach `docs/server-anforderungen.md` | +| **ITM-Projektleitung** | Projektleitung, Abrechnung, Kostenrahmen für BauIn, Server und Gitea | +| **Claude Design** | Oberflächenentwürfe (Prototyp, Designsystem); Übergaben im Format seiner Übergabe, Abschnitt 9 | +| **BauIn – Nachtragsbearbeitung** | Fachliche Fragen, Testdaten, Referenzfälle, Vorlagen, Bewertung im Pilot | +| **BauIn – IT** | Anmeldung, Zugriff, Domain, Datenschutz und Informationssicherheit | + +BauIn ist der Endkunde und prüft als Bauüberwachung im Auftrag der DB die Nachträge der +Auftragnehmer dem Grunde nach. Kontakt läuft über Teams, Termine sind freitags. + +## 3. Ziel und Umfang + +**Ziel von Phase 1:** Für jede Position eines eingereichten Nachtrags zeigt KI-BauIN, ob die +Leistung schon im Vertrag enthalten ist, also in den LVs einschließlich Vorbemerkungen. Dazu +gehören Fundstellen mit Sprung ins PDF, eine Begründung und bei geänderter Leistung die +Bezugsposition. Der Bearbeiter entscheidet; seine Rückmeldungen verbessern die Vorschläge. + +**Enthalten:** +- 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 | -|---|---|---|---| -| – | 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 | – | +| | Termin | Abnahmekriterien | +|---|---|---| +| – | Fr 16.10. (KW 42) | Termin BauIn: Statusbericht, Plan, Kostenrahmen (ITM), ★-Fragen besprochen, Liefertermine vereinbart | +| **M1** | Fr 30.10. (KW 44) | Siehe unten | +| **M2** | Fr 20.11. (KW 47) | Siehe unten | +| **M3** | Fr 18.12. (KW 51) | Siehe unten | +| **M4** | Fr 29.01.2027 (KW 4) | Siehe unten | +| 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. +**M1 – Grundgerüst** (Demo 30 min, lokal oder auf Staging): +- 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 -Statusbericht mit Screenshots. +**M2 – LV-Suche und erste Vorprüfung** (Prüftermin 60 min, auf Staging): +- Staging bei ITM läuft, der Pilot-PFA ist importiert (nach Datenschutzfreigabe). +- 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 | -|---|---|---|---|---|---|---| -| 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) | +## 6. Arbeitspakete -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. +PW = deine Personenwochen mit Claude Code. Status nach Abschnitt 1. -## 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.) | -| 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 | – | – | +| 40 | 28.09.–04.10. | ✓ Umgebung, Grundgerüst, TallStackUI, Mehrsprachigkeit, Doku | – | ✓ Besprechung BauIn (02.10.) | +| 41 | 05.–11.10. | ✓ Server-Anforderungen, Schlüssel-Proxy, Datenmodell; Plan und Teilpläne; Freigaben; Meilisearch-Test Teil 1; GAEB-Test; CI; Rechtekonzept | Server-Anforderungen erhalten; Schlüssel | Fragen raus; Rückmeldung an Claude Design | +| 42 | 12.–18.10. | Rechte und Policies; Benutzer- und Projektverwaltung; Upload; KI-API Schnelltest und Einstellungen; Statusbericht | Staging aufbauen | Aufwand an ITM (14.10.); **Termin BauIn 16.10.** | +| 43 | 19.–25.10. | Antworten einarbeiten, Teilpläne AP4/AP6 detaillieren; GAEB-Import, LV-Ansicht; Protokoll; Designsystem | Staging: Dienste, TLS | neuer Stand von Claude Design | +| 44 | 26.10.–01.11. | PDF-Anzeige mit Sprung; KI-Clients und Jobs; Deploy-Vorlagen; erste Bereitstellung | Staging fertig | **M1 Demo 30.10.** | +| 45 | 02.–08.11. | Indexierung, hybride LV-Suche mit Rechtefilter; Nachtrags-Import | Unterstützung | – | +| 46 | 09.–15.11. | Suchreihenfolge, LV-Suche-Oberfläche; Vorprüfung Stufe 1; Meilisearch-Test Teil 2 | – | Pilotdaten auf Staging (du) | +| 47 | 16.–22.11. | Prüfmaske v3 ohne Sprachmodell, Feedback; Dashboard (Teil 1) | – | **M2 Prüftermin 20.11.** | +| 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 | – | -| 51 | 14.–20.12. | Option OP1 Bewertungsmatrix (falls Vorlage da und Stunden erhöht); Feinschliff | Produktion fertig | **M3 Präsentation 18.12.** | +| 50 | 07.–13.12. | Regeln und Freigaben; Ergebnisliste, Excel-Export | Produktionsserver | – | +| 51 | 14.–20.12. | OP1 Bewertungsmatrix (falls Vorlage und Stunden); Feinschliff | Produktion fertig | **M3 Präsentation 18.12.** | | 52–53 | 21.12.–03.01. | Pause | Pause | – | -| 1 | 04.–10.01. | Pilot: alle Nachträge des Pilot-PFA durchlaufen, messen | – | Fachexperte bewertet | -| 2 | 11.–17.01. | Nachschärfen; Dashboard, Auswertungen, Benachrichtigungen; Option OP2 Stellungnahme (falls Stunden erhöht) | – | Demo 15.01. | +| 1 | 04.–10.01. | Pilot: alle Nachträge des Pilot-PFA, messen | – | Fachexperte bewertet | +| 2 | 11.–17.01. | Nachschärfen; Dashboard, Auswertungen; OP2 Stellungnahme (falls Stunden) | – | Demo 15.01. | | 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 | -| 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 | +| ✓ 02.10. | ITM | API-Dokumentation | AP3 | +| KW 41 | ITM | API-Schlüssel für die Entwicklung, Antworten Teil C, Preise | AP3, Kostenrahmen | +| KW 41 | BauIn | Antworten auf die ★-Fragen | Teilpläne | +| ✓ KW 41 | wir → ITM | Server-Anforderungen (noch verschicken) | AP11 | +| KW 42 | Claude Design | Neuer Stand nach unserer Rückmeldung: Übergabe und `.dc.html`-Dateien | AP13 | +| 16.10. | BauIn | Matrix-Vorlage (leer und ausgefüllt), Word-Vorlage, anonymisierter Beispielablauf | AP5, AP9, OP1, OP2 | +| KW 43 | BauIn | Entscheidung Rollen, Freigabe-Variante, Anmeldung | AP1, AP8 | +| KW 43 | BauIn, ITM | Datenschutzfreigabe für echte Pilotdaten | M2 | +| KW 44 | ITM | Staging-Server mit Zugang, Domain, Zertifikat | M2 | +| KW 46 | BauIn | Pilotdaten: alle LVs eines PFA (X86 + PDF), nur auf Staging | M2 | +| KW 47 | BauIn | 10–20 abgeschlossene Nachträge mit Ergebnis | AP2, AP12 | +| KW 51 | ITM | Produktionsserver | AP11 | +| KW 51 | offen | Backups: Ziel, Aufbewahrung, Zuständigkeit | AP11 | -## 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 | -| 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 | +| Zulieferungen kommen spät | Pakete verschieben sich | Termine am 16.10. vereinbaren; Unabhängiges vorziehen | +| Datenschutz für echte Daten bleibt offen | Kein realistischer Test, M2 gefährdet | Früh fragen (A19, B6, C2); bis dahin anonymisierte Daten | +| Vibe Coding: Fehler in Rechten oder Suchfiltern fallen nicht auf | Unbefugte sehen vertrauliche Inhalte | Tests ohne Berechtigung sind Pflicht; CI; diese Stellen gezielt im Browser prüfen | +| Claude Code sieht keine echten Daten | Nachschärfen dauert länger | Messskripte mit Kennzahlen; anonymisierte Problemfälle | +| Nur eine Person kennt die Anwendung | Ausfall stoppt das Projekt | Doku, Teilpläne, Tests aktuell halten | +| X86 weicht vom Standard ab | GAEB-Import aufwendiger | Beispieldatei früh (A18); D86 als Rückfall | +| 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 KW 41; Plan B Qdrant | +| KI-API ausgelastet (120/min gemeinsam) | Wartezeiten | Asynchron, Stapel, Vorrang für Suchanfragen (C8) | +| Excel-Vorlage der DB mit Makros | OP1 schwieriger | Vorlage früh testen | +| Fachexperte wenig verfügbar | Keine Messung | Feste Freitagstermine, Referenzfälle früh | -## Aufgabenliste (nächste zwei Wochen) +## 10. Entscheidungen -**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 +| Datum | Entscheidung | Wer | +|---|---|---| +| 01.10. | Laravel 13, Livewire 4, TallStackUI 4, PHP 8.5, MySQL + Meilisearch, kein Redis | du | +| 02.10. | Phase 1 nur „dem Grunde nach“, Nachträge statt MKA, Höhe Phase 2, Regelwerk Phase 3 | BauIn, du | +| 02.10. | Team: du + Claude Code (Vibe Coding), ITM-Entwickler für KI-API und Server | du | +| 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** -- [ ] 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 +Offene Entscheidungen stehen in den Teilplänen unter „Entscheidungen“. -**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 +## 11. Nach Phase 1 -**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 +- **Phase 2 – Prüfung der Höhe nach:** + - Preis gegen Bezugsposition und gleiche Leistung in anderen PFAs vergleichen. + - Auszüge der Urkalkulation und Nachtragskalkulation einbeziehen. +- **Phase 3 – Regelwerk:** + - Richtlinien der DB (263 PDFs, 743 MB) in die Suche aufnehmen. + - Interner Chat, der mit PDF, Seite und Stelle zitiert. +- **Weitere Ideen:** + - Dokumentenmanagement, E-Mail- und DOXIS-Anbindung + - Österreich (ÖNORM B 2110/B 2118, A 2063) + - 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 - 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. +| Datum | Änderung | +|---|---| +| 01.10. | Erster Plan (MVP, 2 Entwickler) | +| 02.10. | Nach Besprechung mit BauIn: Umfang, Gliederung, Optionen, Ausbaustufen; Team du + Claude Code; 30 h/Woche | +| 05.10. | Neu gegliedert: Arbeitsweise mit Freigaben, Meilensteine mit Abnahmekriterien, Teilpläne je Arbeitspaket, Fragenliste mit Status in `docs/fragen.md` |