Detaillierter Projektplan mit Teilplänen und Fragenliste
- docs/projektplan.md neu gegliedert: Arbeitsweise mit Freigaben, Zuständigkeiten, Meilensteine mit Abnahmekriterien, Arbeitspakete mit Status, Zeitplan, Entscheidungen - docs/plaene/: Teilplan je Arbeitspaket (detailliert für AP0, AP1, AP2, AP3, AP5, AP11, AP13; grob für AP4, AP6–AP10, AP12, Optionen) und Vorlage - docs/fragen.md: alle offenen Fragen mit Status, Empfänger und betroffenem Teilplan - CLAUDE.md: Umsetzung nur nach freigegebenem Teilplan Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Christoph
co-authored by
Claude Opus 5.5
Claude Opus 5.5
parent
6aac8b0a16
commit
2143f4e955
+411
@@ -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.)
|
||||
@@ -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.
|
||||
@@ -0,0 +1,126 @@
|
||||
# AP1 – Fundament: CI, Rechte, Benutzer, Projekte, Upload, Protokoll
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| Status | in Arbeit; Schritte ab 1.5 detailliert, warten auf Freigabe |
|
||||
| Aufwand | 1,25 PW offen (mit Claude Code) |
|
||||
| Zeitraum | KW 40–43 |
|
||||
| Meilenstein | M1 (30.10.) |
|
||||
| Freigabe | offen |
|
||||
|
||||
## Ziel
|
||||
|
||||
Benutzer melden sich an, sehen nur die Projekte, in denen sie Mitglied sind, legen Projekte mit
|
||||
PFA und Verträgen an und laden LV-Pakete hoch. Jede wichtige Aktion wird protokolliert.
|
||||
|
||||
## Umfang
|
||||
|
||||
**Enthalten:**
|
||||
- CI
|
||||
- Rechtekonzept und Policies
|
||||
- Benutzerverwaltung
|
||||
- Projektverwaltung (Projekt, PFA, Verträge, Auftragnehmer, Mitglieder)
|
||||
- Upload und Download im privaten Speicher, auch als ZIP
|
||||
- Protokoll
|
||||
- Länderstruktur
|
||||
|
||||
**Nicht enthalten:**
|
||||
- GAEB-Import (AP5)
|
||||
- Anmeldung mit dem Microsoft-Konto (erst nach Antwort B1, eigener Schritt)
|
||||
- Endgültiges Design (AP13): Die Oberflächen entstehen zuerst mit TallStackUI-Standard und
|
||||
werden in AP13 angepasst.
|
||||
|
||||
## Voraussetzungen
|
||||
|
||||
- Fragen: A1 (Gliederung), A25 (Rollen), B1 (Anmeldung), B4 (Ordnerstruktur für ZIP)
|
||||
- D5 (Actions-Runner auf dem Synology-Gitea)
|
||||
|
||||
## Entscheidungen
|
||||
|
||||
| Nr. | Frage | Vorschlag | Entschieden |
|
||||
|---|---|---|---|
|
||||
| E1.1 | Projektrollen über eigene Tabelle oder Spatie-Teams? | Eigene Tabelle `projekt_mitglieder` (umgesetzt); globale Rollen über Spatie | offen |
|
||||
| E1.2 | Protokoll: Paket oder eigene Tabelle? | `spatie/laravel-activitylog` (MIT, verbreitet) | offen |
|
||||
| E1.3 | Neue Benutzer: Einladung per E-Mail mit Link zum Passwort setzen, oder Admin vergibt Startpasswort? | Einladung per E-Mail (Mailpit in der Entwicklung) | offen |
|
||||
| E1.4 | Benutzer löschen oder nur deaktivieren? | Nur deaktivieren, damit Protokoll und Zuordnungen erhalten bleiben | offen |
|
||||
| E1.5 | Darf der Administrator Projektinhalte sehen? | Nein, nur wenn er Projektmitglied ist | offen (A25) |
|
||||
|
||||
## Schritte
|
||||
|
||||
- [x] **1.1** Entwicklungsumgebung, Repository, gitleaks-Hook
|
||||
- [x] **1.2** Laravel 13, Livewire 4, TallStackUI 4, Fortify (2FA, Passkeys), Spatie,
|
||||
Mehrsprachigkeit
|
||||
- [x] **1.3** Nicht-funktionale Grundlagen: keine externen Ressourcen (Test), `CLAUDE.md`, Tech-Stack-Doku
|
||||
- [x] **1.4** Datenmodell Kern (`docs/datenmodell.md`). Umgesetzt vor Freigabe.
|
||||
- [ ] **1.4a** Review mit dir: Erklärung der Tabellen, Entscheidung E1.1
|
||||
- [ ] **1.4b** Anpassen nach den Antworten A1, A4, A8 und A10
|
||||
- [ ] **1.5** CI in Gitea Actions:
|
||||
- Runner auf dem Synology prüfen bzw. einrichten (Skript von Claude Code, du führst es aus).
|
||||
- Workflow mit `composer install`, `npm run build`, Tests gegen MySQL, Pint (`--test`),
|
||||
PHPStan, Proxy-Tests und gitleaks.
|
||||
|
||||
→ Ergebnis: Jeder Push zeigt grün oder rot.
|
||||
- [ ] **1.6** Rechtekonzept `docs/rechte.md` → Ergebnis: Rechte-Matrix zur Freigabe durch dich (vorläufig bis A25):
|
||||
- Rollen: global Administrator (optional Regelverantwortlicher); je Projekt Projektleiter,
|
||||
Bearbeiter, Leser
|
||||
- Matrix Aktion × Rolle: Projekt sehen, anlegen, bearbeiten, archivieren; Mitglieder verwalten;
|
||||
Dokumente hochladen, sehen, herunterladen; vertrauliche Dokumente; Nachträge anlegen,
|
||||
zuweisen, prüfen; Export; Regeln vorschlagen und freigeben; Verwaltung
|
||||
- Mandantentrennung und Regeln für archivierte Projekte (nur lesen)
|
||||
- [ ] **1.7** Policies und Gates nach dem Rechtekonzept:
|
||||
- zentrale Abfrage „Projekte des Benutzers“
|
||||
- Mandanten-Scope
|
||||
- vertrauliche Dokumente nur für freigegebene Personen
|
||||
|
||||
→ Ergebnis: Je Aktion ein Test mit und einer ohne Berechtigung.
|
||||
- [ ] **1.8** Benutzerverwaltung (Administrator):
|
||||
- Liste mit Suche
|
||||
- Anlegen (Einladung nach E1.3), Bearbeiten, Deaktivieren (E1.4)
|
||||
- Globale Rolle, Mandant, 2FA-Status
|
||||
|
||||
→ Ergebnis: Verwaltung → Benutzer.
|
||||
- [ ] **1.9** Projektverwaltung:
|
||||
- Projektliste
|
||||
- Projekt anlegen in drei Schritten wie im Claude-Design-Entwurf: Projektdaten, PFA und Verträge
|
||||
mit Auftragnehmern, Mitglieder
|
||||
- Bearbeiten, Archivieren (schreibgeschützt)
|
||||
|
||||
→ Ergebnis: Projekte → Neues Projekt.
|
||||
- [ ] **1.10** Upload und Download:
|
||||
- Speicher `storage/app/private/<mandant>/<projekt>/…`
|
||||
- Einzel- und ZIP-Upload bis 200 MB
|
||||
- Paarbildung PDF, X86, D86 nach Dateinamen; Zuordnung zu PFA und Vertrag zum Bestätigen
|
||||
- Prüfung von Dateityp und Größe, Erkennung von Duplikaten (sha256)
|
||||
- Download nur über eine Route mit Rechteprüfung
|
||||
|
||||
→ Ergebnis: LV-Paket hochladen, LVs als Datensätze mit Dokumenten.
|
||||
- [ ] **1.11** Protokoll (E1.2):
|
||||
- Anmeldung (Erfolg und Fehlschlag)
|
||||
- Benutzer- und Rechteänderungen
|
||||
- Projektänderungen
|
||||
- Upload, Löschen, Herunterladen vertraulicher Dokumente
|
||||
- Einstellungen und Exporte
|
||||
|
||||
→ Ergebnis: Verwaltung → Protokoll mit Filter.
|
||||
- [ ] **1.12** Länderstruktur:
|
||||
- Schnittstelle für länderspezifische Begriffe und Auswahllisten
|
||||
- Umsetzung für DE, AT nur als Platzhalter
|
||||
- Länderwahl nur bei mehr als einem freigeschalteten Land
|
||||
|
||||
## Abnahmekriterien
|
||||
|
||||
- Die Kriterien von M1 zu Benutzern, Projekten, Upload, Rechten und Protokoll sind erfüllt
|
||||
(`docs/projektplan.md`, Abschnitt 5).
|
||||
- Ein Benutzer ohne Mitgliedschaft erhält auf jeder Projekt-, Dokument- und Download-URL 403 oder 404.
|
||||
- CI ist grün.
|
||||
|
||||
## Tests
|
||||
|
||||
- Feature-Tests je Aktion mit und ohne Berechtigung, auch für andere Mandanten.
|
||||
- Upload: Paarbildung, zu große Datei, falscher Typ, Duplikat, ZIP mit Ordnern.
|
||||
- Protokolleinträge für die genannten Ereignisse.
|
||||
|
||||
## Risiken
|
||||
|
||||
- Die Rollen ändern sich nach A25. Deshalb das Konzept zuerst schriftlich und die Policies zentral halten.
|
||||
- Große ZIPs: Upload-Grenzen in PHP, Nginx und Livewire abstimmen und testen.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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).
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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
|
||||
@@ -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
|
||||
|
||||
- …
|
||||
+236
-211
@@ -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` |
|
||||
|
||||
Reference in New Issue
Block a user