BauIN/docs/projektplan.md

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

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

Beteiligte

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

Ergebnis der Besprechung vom 02.10.2026

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

• Geprüft werden Nachträge, nicht MKAs. Aus einer MKA entsteht (oder auch nicht) nach einigen Wochen ein Nachtrag; das ist nicht 1:1. Der Nachtrag enthält ein Nachtrags-LV mit Positionen (GAEB und PDF), ein Anschreiben, die Kalkulation und Anlagen. Die MKA-Nummer ist nur noch ein Bezug am Nachtrag.
• Die KI beantwortet je Nachtragsposition eine Frage: Ist die Leistung schon im Vertrag enthalten, also in den LVs einschließlich Vorbemerkungen? Wenn ja, ist der Nachtrag dem Grunde nach nicht berechtigt. Schwerpunkt sind geänderte Leistungen (§ 2 Abs. 5 VOB/B, mit Rückgriff auf eine Hauptvertragsposition) und zusätzliche Leistungen (§ 2 Abs. 6 VOB/B). Mengenänderungen (§ 2 Abs. 3) kommen selten vor und bekommen keine eigene Logik.
• Nicht Aufgabe der KI: die rechtliche Einordnung (richtiger Paragraf), Fristen und Vollständigkeit der Anzeige, Leistungen ohne Auftrag (§ 2 Abs. 8), Behinderungen (§ 6 Abs. 6), Anordnungen des Auftraggebers. Das prüft BauIn selbst.
• Gliederung: Projekt → PFA (Planfeststellungsabschnitt, im Pilot PFA 1–4) → Vertrag mit einem Auftragnehmer (je PFA mehrere, z. B. Gleisbau, Tunnelbau, Oberleitung) → mehrere LVs (im PFA 4 z. B. 28). Ein „Los“ im bisherigen Plan entspricht einem Vertrag.
• Suchreihenfolge: zuerst die LVs des betroffenen Vertrags, dann als Hinweis die anderen PFAs desselben Projekts (Fall: Leistung im PFA 3 beauftragt, im PFA 4 vergessen und dort per Nachtrag zum doppelten Preis angeboten). Nie projektübergreifend. Ob auch die übrigen Verträge im selben PFA durchsucht werden, ist offen.
• Daten: Jedes LV liegt als GAEB (X86 und D86) und als PDF vor, erzeugt aus dem Kalkulationsprogramm. Grundlage ist die X86-Datei (strukturiert, ohne Texterkennung); das PDF dient der Anzeige mit Sprung zur Fundstelle. OCR über die KI-API braucht es nur noch für PDFs ohne GAEB-Datei (Anschreiben, Scans).
• Sprachmodell ist vorhanden (chat, chat-noreasoning, Kontext laut ITM 128K). Damit ist die KI-Beurteilung (Stufe 2) fest eingeplant.
• Bewertungsmatrix (Excel der DB) und Stellungnahme (Word) sind Optionen, nicht Kern von Phase 1. Vorlagen kommen von BauIn.
• Die Prüfung der Höhe nach ist Phase 2, das Regelwerk mit Chat Phase 3 (siehe unten).
• Zusammenarbeit: Termine freitags über Teams; nächster Termin am 16.10.2026 mit Statusbericht und Kostenrahmen für Phase 1.

Rahmen und Annahmen

• Ziel von Phase 1: Positionsanalyse dem Grunde nach am Pilotprojekt. Vom hochgeladenen Nachtrag bis zur Ergebnisliste je Position mit Fundstellen, Begründung und Entscheidung des Bearbeiters, mit Rollen und Rechten, Protokoll und Betrieb auf den Servern von ITM.
• Grundhaltung: Die KI schlägt vor und belegt mit Fundstellen, der Mensch entscheidet. Rückmeldungen fließen in ein Confidence-System mit Referenzfällen und Regeln.
• Team:
  • Du + Claude Code: die gesamte Anwendung (Backoffice), also Oberfläche, Datenmodell, Rechte, GAEB-Import, Anbindung der KI-API, Indexierung und Suche, Prüflogik mit Prompts, Export, Tests, Deployment-Skripte und Doku. Arbeitsweise: Vibe Coding, Claude Code schreibt den Code, du steuerst, testest im Browser, entscheidest und hältst den Kontakt zu BauIn.
  • ITM-Entwickler: KI-API (API-Werk, Modelle, Schlüssel, Grenzen) und der Aufbau der Server für Staging und Produktion nach unseren Vorgaben (PHP, MySQL, Meilisearch, Nginx, Worker, Cron, TLS, Backups).
  • Annahme zur Abgrenzung: Prompts und Prüflogik bauen wir, weil sie eng mit Oberfläche und Feedback verzahnt sind; ITM berät zu Modellen und Grenzen. Bestätigung steht aus.
• Aufwand in deinen Personenwochen (PW) mit Claude Code: Kern rund 11 PW, mit Puffer 13–14 PW, Optionen je 0,5 PW. Ohne KI-Unterstützung wären es rund 23 PW. Dazu kommen beim ITM-Entwickler etwa 1–1,5 PW für die Server. Werkzeugkosten (Claude Code) sind nicht enthalten.
• Wo Claude Code Zeit spart und wo nicht: Oberfläche, Datenmodell, Tests und Parser gehen etwa dreimal so schnell, die Anbindung von API und Dateiformaten etwa doppelt. Kaum schneller werden Klärung mit dem Kunden, Warten auf Zulieferungen, das Nachschärfen mit echten Daten und Abnahmen. Claude Code sieht keine echten Kundendaten; Messungen mit echten Nachträgen machst du auf Staging und gibst Kennzahlen oder anonymisierte Beispiele zurück.
• Verfügbarkeit: 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.
• Pause: KW 52–53 (21.12.2026 – 03.01.2027).
• Echte Daten: Entwickelt wird mit öffentlichen GAEB-Beispieldateien und einem anonymisierten Beispielablauf von BauIn. Echte Pilotdaten nur auf den Servern von ITM und erst nach Klärung des Datenschutzes.
• Abhängigkeit: Viele Pakete brauchen Zulieferungen von ITM und BauIn. Kommen sie später als unten geplant, verschiebt sich der Plan entsprechend.

Meilensteine

	Termin	Ergebnis	Termin mit dem Kunden
–	Fr 16.10.	Statusbericht mit Screenshots, Plan, Kostenrahmen, offene Fragen	Termin BauIn
M1	Fr 30.10. (KW 44)	Grundgerüst: Login/2FA, Benutzer und Rollen, Projekte mit PFA und Verträgen, Upload, Protokoll; erste LVs aus X86 importiert und als Baum mit Vorbemerkungen sichtbar; Detailplan steht	Demo (30 min)
M2	Fr 20.11. (KW 47)	Pilot-PFA auf Staging bei ITM; LV-Suche über alle LVs eines Vertrags, PFA oder Projekts mit Sprung ins PDF; Vorprüfung Stufe 1 (Fundstellen je Nachtragsposition) für die ersten Nachträge	Prüftermin (60 min)
M3	Fr 18.12. (KW 51)	Nachträge durchgängig: Vorprüfung mit Sprachmodell (enthalten?, Bezugsposition, Begründung mit Quellen), Prüfmaske, Feedback, Regeln, Ergebnisliste; Bewertungsmatrix, falls die Vorlage da ist	Präsentation (60–90 min)
M4	Fr 29.01.2027 (KW 4)	Alle Nachträge des Pilot-PFA durchlaufen, Trefferquote und Zeitersparnis gemessen; Produktion abgesichert; Stellungnahme als Option	Abschluss, Entscheidung über Phase 2
Puffer	KW 5–6/2027	für Verzögerungen bei Zulieferungen oder Import	–

Die LV-Suche (M2) nützt BauIn schon vor der KI-Beurteilung: Heute werden bis zu 28 LVs einzeln nach Stichworten durchsucht.

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

Arbeitspakete und Aufwand

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

AP	Inhalt	PW ohne KI	PW mit Claude Code	Wer	Wann	Hängt ab von
AP0	Klärung, Kundentermine, Statusberichte, Dokumentation	1,0	0,75	Du	laufend	–
AP1	Fundament: Umgebung ✓, Laravel/TallStackUI ✓, Mehrsprachigkeit ✓; offen: CI, Datenmodell (Mandant, Land, Projekt, PFA, Vertrag, LV, Dokument, Nachtrag, Nachtragsposition), Rollen/Rechte mit Benutzerverwaltung, privater Upload und Download inkl. Massen-Upload, Protokoll, Länderstruktur	3,0 (+1,0 ✓)	1,25	Du + CC	KW 41–42	Rollenmodell (Kunde)
AP2	Meilisearch-Test: Teil 1 mit erzeugten Vektoren, Teil 2 mit echten Vektoren und Referenzfällen	0,5	0,25	Du + CC	KW 41 / KW 46	Teil 2: Staging, Referenzfälle
AP3	Anbindung KI-API ITM (API-Werk): Dokumentdienst mit Polling, embed, rerank, chat mit Streaming; Ratenbegrenzung (120/min je Schlüssel), begrenzte Wiederholung ohne Doppel-Einreichung, Verbrauchsprotokoll, Überwachung	1,5	0,5	Du + CC	KW 42	API-Schlüssel (ITM)
AP4	Indexierung und Suche: LV-Positionen und Vorbemerkungen aus GAEB, Texte aus PDFs ohne GAEB → Embeddings → MySQL + Meilisearch; hybride LV-Suche mit Pflichtfilter für Rechte und Suchreihenfolge (Vertrag → PFA → Projekt); Neuaufbau des Index	2,0	1,0	Du + CC	KW 44–45	AP3, AP5
AP5	GAEB-Import (X86): Parser, LV-Baum, Vorbemerkungen, LV-Ansicht; PDF-Anzeige (pdf.js lokal) mit Sprung zur Position; Nachtrags-Import (Nachtrags-LV als X86, sonst PDF über OCR)	2,5	1,25	Du + CC	KW 41 (Test), KW 43–45	Beispieldateien
AP6	Vorprüfung Stufe 1 (ohne Sprachmodell): je Nachtragsposition Fundstellen mit Reranker, Nachtragsübersicht, Prüfmaske, Feedback je Aspekt, Confidence	2,5	1,25	Du + CC	KW 46–47	AP4, AP5
AP7	Vorprüfung Stufe 2 (mit Sprachmodell): „im Vertrag enthalten?“, Bezugsposition und Unterschied bei geänderter Leistung, Begründung mit Quellen, Prüfung der Antwort	2,0	1,0	Du + CC	KW 48–49	AP6
AP8	Regeln, Referenzfälle, einstellbare Freigaben, Versionen	2,0	0,75	Du + CC	KW 49–50	Freigabe-Variante (Kunde)
AP9	Nachtragsstatus, Ergebnisliste je Nachtrag, einfacher Excel-Export	0,5	0,25	Du + CC	KW 50	–
AP10	Dashboard, Benachrichtigungen, Auswertungen, allgemeine Dokumente (Einstellungen)	0,75	0,5	Du + CC	KW 2	–
AP11a	Betrieb, unser Teil: Server-Anforderungen, Deploy-Skript, Vorlagen für Nginx/systemd/Cron, Backup- und Alarm-Skripte, Betriebsdoku	1,5	0,5	Du + CC	KW 41, KW 44, KW 3	–
AP11b	Betrieb, ITM: Staging- und Produktionsserver aufbauen, TLS, Backup-Ziel, Überwachung, Restore-Test	(in AP11a)	ITM 1–1,5	ITM	KW 42–44, KW 50–51, KW 3	Server-Anforderungen
AP12	Pilot: alle Nachträge des Pilot-PFA durchlaufen, messen, nachschärfen (Prompts, Gewichtung, Quantisierung)	2,0	1,5	Du + CC	KW 1–2/2027	Referenzfälle, Fachexperte
AP13	Design aus Claude Design (Prototyp, Stand in ClaudeDesign_Stand_2026-10-02.md) als TallStackUI-Designsystem übernehmen: Tokens, Schriften lokal, Phosphor-Icons über Blade-Paket	1,0	0,5	Du + CC	KW 43	Prüfmaske v3 und Grundlagen von Claude Design
	Summe Kern (offen)	≈ 22,75	≈ 11,25 (+ ITM 1–1,5)
OP1	Option: Bewertungsmatrix in der Excel-Vorlage der DB füllen	1,0	0,5	Du + CC	KW 51	Vorlage (BauIn)
OP2	Option: Stellungnahme BÜW als Word-Datei aus Vorlage	1,0	0,5	Du + CC	KW 2	Vorlage (BauIn)

Gegenüber dem Stand vom 01.10. entfallen der GAEB-90-Import (D86), der Webhook-Eingang, der Vorschlag einer Anspruchsgrundlage und die kuratierte Wissensbasis (wird Phase 3). Dazu kommen PDF-Anzeige mit Sprung zur Position, Massen-Upload, Suchreihenfolge über PFAs und die Bezugsposition.

Zeitplan nach Kalenderwochen

KW	Datum	Du + Claude Code	ITM-Entwickler	Kunde / gemeinsam
40	28.09.–04.10.	✓ Umgebung, Grundgerüst, TallStackUI, Mehrsprachigkeit, Doku, Plan	–	✓ Besprechung BauIn (02.10.)
41	05.–11.10.	Datenmodell Kern; Benutzer, Rollen, Rechte; CI; Meilisearch-Test Teil 1; GAEB-X86-Test mit öffentlichen Beispielen; Server-Anforderungen an ITM	API-Schlüssel für die Entwicklung, Antworten auf Teil C, Preise	Fragenkatalog raus; Übergabe an Claude Design
42	12.–18.10.	Projekte, PFA, Verträge; Upload und Massen-Upload; Protokoll; API-Client und Schnelltest; Statusbericht; Aufwand an ITM (14.10.)	Staging-Server aufbauen	Termin BauIn 16.10.
43	19.–25.10.	Detailplan und Teilpläne; GAEB-Import (LV-Baum, Vorbemerkungen), LV-Ansicht; Designsystem übernehmen	Staging: Meilisearch, Worker, Cron, TLS	–
44	26.10.–01.11.	PDF-Anzeige mit Sprung zur Position; Indexierung → Embeddings → MySQL + Meilisearch; Deploy-Skript	Staging fertig, Deployment aus Gitea	M1 Demo 30.10.
45	02.–08.11.	Hybride LV-Suche mit Rechtefilter und Suchreihenfolge; Nachtrags-Import; erste Bereitstellung auf Staging	Unterstützung	–
46	09.–15.11.	Vorprüfung Stufe 1: Fundstellen + Reranker; Nachtragsübersicht; Pilot-PFA auf Staging importieren (du, echte Daten); Meilisearch-Test Teil 2	–	–
47	16.–22.11.	Prüfmaske, Feedback, Confidence	–	M2 Prüftermin 20.11.
48	23.–29.11.	Sprachmodell: „enthalten?“, Bezugsposition, strukturierte Antwort, Prüfung der Antwort	–	–
49	30.11.–06.12.	Begründung mit Quellen; Referenzfälle; Regeln beginnen	–	Demo 04.12.
50	07.–13.12.	Regeln, Freigaben, Versionen; Ergebnisliste und Excel-Export	Produktionsserver aufbauen	–
51	14.–20.12.	Option OP1 Bewertungsmatrix (falls Vorlage da und Stunden erhöht); 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.
3	18.–24.01.	Produktion: Inbetriebnahme, Backups, Alarmierung, Restore-Test	Backups, Restore-Test	–
4	25.–31.01.	Auswertung, Übergabe, Doku	–	M4 Abschluss 29.01.
5–6	01.–14.02.	Puffer	Puffer	–

Zulieferungen von ITM und BauIn (Soll-Termine)

Bis	Von	Was	Gebraucht für
✓ 02.10.	ITM	API-Dokumentation (API-Werk: Dokumentdienst, chat, chat-noreasoning, embed, rerank)	AP3
KW 41	ITM	API-Schlüssel für die Entwicklung; Antworten auf die ITM-Fragen; Preise der API für den Kostenrahmen	AP3, Kostenrahmen
KW 41	BauIn	Antworten auf die ★-Fragen	Detailplan
KW 41	wir → ITM	Server-Anforderungen (Ausstattung, Software und Versionen, Dienste, Ports, Backups)	AP11b
16.10.	BauIn	Matrix-Vorlage (leer + 2–3 ausgefüllt), Word-Vorlage Stellungnahme, anonymisierter Beispielablauf (LVs als X86 + PDF, Nachträge mit Nachtrags-LV und Anschreiben)	AP5, AP9, OP1, OP2
KW 43	BauIn	Entscheidung Rollenmodell, Freigabe-Variante, Anmeldung (2FA oder Microsoft-Konto)	AP1, AP8
KW 43	BauIn, ITM	Freigabe Datenschutz für echte Pilotdaten auf den Servern von ITM und über die KI-API	M2
KW 44	ITM	Staging-Server mit Zugang, Domain und Zertifikat	M2
KW 46	BauIn	Pilotdaten: alle LVs eines PFA als X86 + PDF (nur auf Staging)	M2
KW 47	BauIn	10–20 abgeschlossene Nachträge mit Ergebnis (Referenzfälle)	AP2 Teil 2, AP12
KW 51	ITM	Produktions-Server mit Zugang, Domain und Zertifikat	AP11
KW 51	offen	Backups: Speicherort, Aufbewahrungsdauer, Zuständigkeit	AP11

Risiken

Risiko	Auswirkung	Gegenmaßnahme
Zulieferungen kommen spät	Pakete verschieben sich	Soll-Termine am 16.10. vereinbaren; vorziehen, was unabhängig ist
Kein anonymisierter Beispielablauf, Datenschutz für echte Daten ungeklärt	Kein realistischer Test vor M2	Öffentliche GAEB-Beispiele; früh anfragen; echte Daten nur auf Staging
Vibe Coding: Fehler in sicherheitskritischen Teilen (Rechte, Dateizugriff, Suchfilter) fallen nicht auf	Unbefugte sehen vertrauliche Inhalte	Rechte-Tests für jede geschützte Aktion Pflicht; CI blockiert; diese Stellen sieht sich jemand gezielt an (Regeln in CLAUDE.md)
Claude Code sieht keine echten Daten	Nachschärfen mit echten Nachträgen dauert länger	Messskript auf Staging liefert Kennzahlen; anonymisierte Problemfälle zurückgeben
Nur eine Person kennt die Anwendung	Krankheit oder Urlaub stoppt das Projekt	Doku, CLAUDE.md, Tests und Teilpläne aktuell halten; ITM-Entwickler kennt den Betrieb
X86-Dateien weichen vom Standard ab (Version, Erweiterungen des Kalkulationsprogramms)	GAEB-Import aufwendiger	Beispieldatei früh anfordern; fertige Bibliothek prüfen; D86 als Rückfall
Sprachmodell liefert keine verlässliche strukturierte Antwort	Stufe 2 schwächer	Antwort im Code prüfen; Stufe 1 (Suche + Reranker) ist allein schon nützlich
Meilisearch mit 4.096 Dimensionen zu langsam	Suche muss umgebaut werden	Test in KW 41; Plan B Qdrant
KI-API ausgelastet (120 Anfragen/min je Schlüssel, für alle Nutzer gemeinsam)	Lange Wartezeiten bei Erstindexierung und Suche	Alles asynchron; Stapel-Embeddings; Suchanfragen bevorzugen; ggf. getrennte Schlüssel
Excel-Vorlage der DB enthält Makros	Export kann Makros verlieren (OP1)	Vorlage früh testen; notfalls Werte zum Einfügen exportieren
Fachexperte wenig verfügbar	Kein Feedback, keine Messung	Feste Freitagstermine; Referenzfälle früh anfordern

Aufgabenliste (nächste zwei Wochen)

Erledigt

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

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
• Server-Anforderungen an den ITM-Entwickler
• API-Schlüssel für die Entwicklung bei ITM anfordern
• Meilisearch-Test Teil 1 (erzeugte 4.096-dim. Vektoren, z. B. 50.000 Stück): Indexierungszeit, Antwortzeit mit Filtern, RAM und Platte; jeweils ohne und mit binärer Quantisierung
• Datenmodell Kern: Mandant, Land, Projekt, PFA, Vertrag, LV, Dokument (Kategorie, Vertraulichkeit), Nachtrag, Nachtragsposition, Mitgliedschaften
• Benutzerverwaltung, Rollen und Rechte (Spatie, ggf. Teams je Projekt)
• GAEB-X86-Test mit öffentlichen Beispieldateien, Bibliothek auswählen
• CI in Gitea Actions: Tests, Pint, PHPStan
• Commits nach Gitea pushen

KW 42

• Aufwand für den Kostenrahmen an ITM (bis 14.10.)
• Projekte, PFA und Verträge; Upload, privater Speicher, Download mit Rechteprüfung, Massen-Upload; Protokoll
• API-Client und Schnelltest (Modellverzeichnis, Dimension von embed, rerank, chat mit Streaming)
• Statusbericht mit Screenshots für den 16.10.
• Termin BauIn 16.10.: Antworten in Plan und Doku übernehmen, Soll-Termine vereinbaren
• Design-Feedback an Claude Design

Später im Plan (bereits vorgemerkt)

• Detailplan mit Teilplänen je Arbeitspaket (KW 43)
• Meilisearch-Test Teil 2 (KW 46): Trefferquote mit echten API-Vektoren und Referenzfällen, ohne/mit binärer Quantisierung, vor und nach dem Reranker
• Push-Mirror zum Gitea von ITM einrichten, sobald die Adresse vorliegt
• 2FA-Pflicht oder Microsoft-Anmeldung umsetzen, je nach Entscheidung des Kunden

Ausbaustufen nach Phase 1

• Phase 2 – Prüfung der Höhe nach: Preis der Nachtragsposition gegen Bezugsposition und gleiche Leistung in anderen PFAs, Auszüge aus der Urkalkulation, Nachtragskalkulation. Die vollständige Urkalkulation liegt versiegelt bei der DB; dort prüft der Einkauf die Höhe.
• Phase 3 – Regelwerk: Richtlinien der DB (Auszug, mit dem BauIn zu rund 80 % arbeitet: 263 PDF-Dateien, 743 MB, z. B. Ril 821, 824, 836) in die Suche aufnehmen, dazu ein interner Chat, der mit PDF, Seite und Stelle zitiert. Phase 1 legt die Grundlagen: Dokumentspeicher, Abschnitte mit Seitenbezug, Quellenanzeige im PDF.
• Weitere Ideen: Dokumentenmanagement, E-Mail-Anbindung, Anbindung an das Dokumentensystem der DB, Österreich (ÖNORM B 2110/B 2118, ÖNORM A 2063), Bauzeitenplan-Analyse, weitere Sprachen.

Nebenprojekt außerhalb des Budgets

• datenschleuse (lokaler Scanner/Bereiniger, Prompt in Prompt_Datenschleuse.md): mindestens Phase 1–2 fertig, bevor echte Kundendateien mit Claude bearbeitet werden. Bis dahin gehen echte Kundendateien nicht an Claude. Hilft auch beim anonymisierten Beispielablauf.