AP0 Schritte 0.4 und 0.6: Antworten vom 05.10. und Claude Design 0.3 eingearbeitet

- Fragenliste: erste Antworten von BauIn und ITM eingetragen, übrige Fragen auf „gestellt“ - Anmeldung mit eigenem Passwort, 2FA später Pflicht; keine E-Mails; Mehrfach-Upload ohne ZIP - Nur Produktionsschlüssel: Tests rufen die echte API nie auf - Stellungnahme BÜW und Österreich in Phase 2; „Vor dem Livegang zu klären“ in AP11 - Claude Design Stand 0.3 abgeglichen (AP13), Prüfmaske v4 in AP6 - Gitea von ITM als Push-Mirror eingetragen Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-05 15:54:18 +02:00
parent 2143f4e955
commit f62541ff13
14 changed files with 288 additions and 159 deletions
@@ -33,7 +33,8 @@ Keine.
 - [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):
+- [x] **0.4** Fragen verschicken (du), erledigt am 05.10. Erste Antworten (B1–B6, C1–C3, C10–C13,
+  A13, A15, A16, A19, A26–A28) sind in `docs/fragen.md` und den Teilplänen eingearbeitet.
  - Teil A an die Nachtragsbearbeitung von BauIn
  - Teil B an die IT von BauIn
  - Teil C an die ITM-Projektleitung
@@ -41,8 +42,10 @@ Keine.
  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
+- [x] **0.6** Rückmeldung an Claude Design geben (du); den neuen Stand ablegen, sobald er da ist
+  → Stand 0.3 vom 05.10. in `claude-design/2026-10-05_Stand-0.3/` im Planungsordner, Abgleich in AP13
+- [ ] **0.6a** Push-Mirror zum Gitea von ITM einrichten (du, Weboberfläche des lokalen Gitea)
+  → `https://gitea.itm-technologies.de/ChristophGraf/BauIN`, erster Abgleich geprüft
 - [ ] **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
@@ -20,19 +20,21 @@ PFA und Verträgen an und laden LV-Pakete hoch. Jede wichtige Aktion wird protok
 - Rechtekonzept und Policies
 - Benutzerverwaltung
 - Projektverwaltung (Projekt, PFA, Verträge, Auftragnehmer, Mitglieder)
- Upload und Download im privaten Speicher, auch als ZIP
+- Upload (mehrere Dateien auf einmal, kein ZIP) und Download im privaten Speicher
 - Protokoll
 - Länderstruktur

 **Nicht enthalten:**
 - GAEB-Import (AP5)
- Anmeldung mit dem Microsoft-Konto (erst nach Antwort B1, eigener Schritt)
+- Anmeldung mit dem Microsoft-Konto (entfällt, B1)
+- E-Mails jeder Art, auch Einladung und „Passwort vergessen“ (B3)
 - 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)
+- Fragen: A1 (Gliederung), A25 (Rollen). Beantwortet am 05.10.: B1 (eigenes Passwort, 2FA später
+  Pflicht), B3 (keine E-Mails), B4 (Mehrfach-Upload, kein ZIP, Ordner von Hand)
 - D5 (Actions-Runner auf dem Synology-Gitea)

 ## Entscheidungen
@@ -41,9 +43,10 @@ PFA und Verträgen an und laden LV-Pakete hoch. Jede wichtige Aktion wird protok
 |---|---|---|---|
 | 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.3 | Neue Benutzer und vergessene Passwörter ohne E-Mail (B3) | Administrator vergibt ein Startpasswort, das bei der ersten Anmeldung geändert werden muss; er setzt auch vergessene Passwörter so zurück. „Passwort vergessen“ zeigt nur den Hinweis auf den Administrator | 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) |
+| E1.6 | 2FA-Pflicht (B1) | Schalter unter Verwaltung → Einstellungen, zunächst aus. Eingeschaltet muss jeder Benutzer 2FA einrichten, bevor er weiterarbeitet; der Administrator kann 2FA eines Benutzers zurücksetzen | offen |

 ## Schritte

@@ -53,7 +56,9 @@ PFA und Verträgen an und laden LV-Pakete hoch. Jede wichtige Aktion wird protok
 - [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.4b** Anpassen nach den Antworten A1, A4, A8 und A10 und an den Prototyp 0.3
+    (AP13, Abgleich): Projekt ohne Vertragsgrundlage im Formular, Suchbereich nur ein Schalter
+    „Andere Verträge im selben PFA einbeziehen“, Vertrag mit Gewerk und „Vertrag vom“
 - [ ] **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`),
@@ -75,21 +80,23 @@ PFA und Verträgen an und laden LV-Pakete hoch. Jede wichtige Aktion wird protok
  → 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
+  - Anlegen mit Startpasswort (E1.3), Bearbeiten, Passwort zurücksetzen, Deaktivieren (E1.4)
+  - Globale Rolle, Mandant, 2FA-Status; Schalter 2FA-Pflicht (E1.6)

  → 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
+  - Projekt anlegen in drei Schritten wie im Prototyp „Projekt anlegen v3“: Projektdaten mit PFA
+    und Verträgen, Vertragsunterlagen (Upload aus 1.10), Prüfen und anlegen
+  - Mitglieder im Reiter „Berechtigungen“ des Projektdetails
  - 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
+  - Mehrere Dateien auf einmal hochladen (Auswahl oder Ziehen), kein ZIP (B4); bis 200 MB je Datei
+  - Paarbildung PDF, X86, D86 nach Dateinamen. Die Ordner bei BauIn haben keine feste Struktur
+    (B4), deshalb werden PFA und Vertrag in der Anwendung gewählt bzw. je LV bestätigt
  - Prüfung von Dateityp und Größe, Erkennung von Duplikaten (sha256)
  - Download nur über eine Route mit Rechteprüfung

@@ -117,10 +124,13 @@ PFA und Verträgen an und laden LV-Pakete hoch. Jede wichtige Aktion wird protok
 ## 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.
+- Upload: Paarbildung, zu große Datei, falscher Typ, Duplikat, viele Dateien auf einmal.
+- Anmeldung: Startpasswort muss geändert werden; mit eingeschalteter 2FA-Pflicht kein Zugriff
+  ohne eingerichtete 2FA.
 - 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.
+- Große Dateien und viele Dateien auf einmal: Upload-Grenzen in PHP, Nginx und Livewire
+  abstimmen und testen.
@@ -26,7 +26,13 @@ liegen verschlüsselt in der Datenbank.

 ## Voraussetzungen

- C1 (Schlüssel), C4–C8 (Modelle, Grenzen); Schlüssel im Windows-Tresor, Proxy läuft (du)
+- C4–C8 (Modelle, Grenzen); Schlüssel im Windows-Tresor, Proxy läuft (du)
+- C1 (05.10.): Es gibt nur Schlüssel für die Produktion. Entwicklung, Staging und Produktion
+  teilen sich Zählung, Kosten und das Limit von 120 Anfragen/min. Deshalb:
+  - Automatische Tests und CI rufen die echte API nie auf (`Http::fake`).
+  - Live-Aufrufe nur im Schnelltest (3.2) und gezielt, mit kleinen Testtexten.
+  - Getrennte Schlüssel für Vorrang (C8) sind nicht zu erwarten; der Ratenbegrenzer (E3.1) muss
+    das allein leisten.
 - AP1 Schritt 1.7 (Rechte für Verwaltung)

 ## Entscheidungen
@@ -19,7 +19,7 @@ und setzt das Prüfergebnis.
 **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)
+- Nachtragsliste, Prüfmaske v4 (ohne Sprachmodell-Teile)
 - Feedback je Aspekt, Korrektur der Fundstelle, Prüfergebnis, Verlauf

 **Nicht enthalten:**
@@ -29,7 +29,7 @@ und setzt das Prüfergebnis.
 ## Voraussetzungen

 - AP4, AP5 (Nachtrags-Import), AP13
- Prüfmaske v3 von Claude Design
+- Prüfmaske v4 von Claude Design (Stand 0.3, liegt vor)
 - A9 (Werte des Prüfergebnisses)

 ## Schritte (grob)
@@ -37,13 +37,17 @@ und setzt das Prüfergebnis.
 - [ ] **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
+  - `feedback`: Aspekt, Antwort, Korrektur. Laut Prototyp 0.3: Fundstelle als Auswahl mit
+    „Auswahl bestätigen“ (gewählt: Kandidat, „keine“ oder „suche“); Prüfergebnis und Begründung
+    mit Ja / Nein. Jede Antwort wird sofort als Entwurf gespeichert. Ändert sich die bestätigte
+    Fundstelle, werden Prüfergebnis und Begründung neu angefordert und ihre Antworten
+    zurückgesetzt.
 - [ ] **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:
+- [ ] **6.5** Prüfmaske v4 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
@@ -26,13 +26,17 @@ werden je nach Einstellung freigegeben. Bestätigte Fälle dienen als Referenzf

 - AP6, AP7
 - A23 (projektübergreifende Regeln?), A24 (Freigabe-Variante)
+- Prototyp 0.3 (Regeldialog v3) weicht ab: Freigabe immer durch den Projektleiter, keine
+  Freigabe-Einstellung; Geltungsbereich nur Vertrag, PFA, Projekt. Unser Vorschlag an BauIn (A24)
+  war „ohne Freigabe“, später umstellbar. **E8.1 offen:** Prototyp übernehmen oder Einstellung
+  behalten?

 ## Schritte (grob)

- [ ] **8.1** Datenmodell Regeln und Versionen; Geltungsbereich Vertrag → PFA → Projekt →
-  Auftraggeber → Land; nie löschen
+- [ ] **8.1** Datenmodell Regeln und Versionen; Geltungsbereich Vertrag → PFA → Projekt
+  (Auftraggeber und Land erst nach A23); nie löschen
 - [ ] **8.2** Regeldialog aus der Prüfmaske: Vorformulierung, ähnliche Regeln
- [ ] **8.3** Freigabe-Einstellungen und Warteschlange „Zur Freigabe“
+- [ ] **8.3** Freigabe nach E8.1 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

@@ -18,7 +18,9 @@ und in die Bewertungsmatrix übertragen lässt.
 **Enthalten:** Bearbeitungsstand des Nachtrags, Ergebnisliste, Excel-Export (PhpSpreadsheet),
 Liste der Exporte, „Nachtrag abschließen“.

-**Nicht enthalten:** Bewertungsmatrix in der DB-Vorlage und Stellungnahme (Optionen).
+**Nicht enthalten:** Bewertungsmatrix in der DB-Vorlage (Option OP1) und Stellungnahme BÜW
+(Phase 2, A15). In der Ergebnisliste erscheint deshalb nur der Button für die Bewertungsmatrix,
+deaktiviert mit „Vorlage folgt“.

 ## Voraussetzungen

@@ -16,14 +16,14 @@ 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
+- Dashboard nach Prototyp „Dashboard v3“ (2a, 2b Benachrichtigungen, 2c leer, 2e Hilfe)
+- Benachrichtigungen nur in der Anwendung (Glocke in der Topbar); keine E-Mails (B3)
 - Auswertungen: Trefferquote, Treffsicherheit je KI-Sicherheit, überstimmte Regeln, Prüfzeit
 - Allgemeine Dokumente in den Einstellungen

 ## Voraussetzungen

-AP6; B3 (E-Mail-Absender).
+AP6. B3 ist beantwortet: keine E-Mails.

 ## Schritte (grob)

@@ -32,8 +32,29 @@ gesichert und überwacht. Ein Ausfall fällt auf, bevor BauIn ihn bemerkt.

 ## Voraussetzungen

-C10 (Ausstattung, Root-Zugang), B2 (Zugriff Internet/VPN), B3 (Domain, Mail), B5 und C10 (Backups),
-C12 (wer deployt).
+- C10 (05.10.): Ausstattung, Zugang, Verschlüsselung und Sicherung der Server sind Sache von ITM.
+  Wir liefern die Server-Anforderungen und die Vorlagen (11a).
+- B3 (05.10.): Die Anwendung verschickt keine E-Mails. Die Adresse wird vor dem Livegang geplant.
+- C12 ist beantwortet, offen blieb: Wer deployt im Betrieb, und wie viel Zeit hat der
+  ITM-Entwickler?
+- B2, B5 und B6 werden vor dem Livegang geklärt (Abschnitt unten).
+
+## Vor dem Livegang zu klären
+
+Für die Entwicklung des Prototyps nicht nötig, vor dem Livegang aber Pflicht. Stand 05.10.:
+
+| Thema | Frage | Mit wem |
+|---|---|---|
+| Zugriff (B2) | Aus dem Internet mit Login, oder nur über VPN bzw. feste IP-Adressen? | BauIn IT, ITM |
+| Adresse (B3) | Domain und Zertifikat | BauIn IT, ITM |
+| 2FA (B1) | Pflicht einschalten (Schalter aus AP1, E1.6) und Benutzer vorher informieren | BauIn |
+| Backups (B5) | Speicherort, Aufbewahrung, Zuständigkeit | BauIn IT, ITM |
+| Datenschutz und Informationssicherheit (B6) | Vorgaben von BauIn oder der DB, z. B. Sicherheitsanforderungen an Auftragnehmer der DB, ISO 27001, Geheimhaltung. Wer muss der Verarbeitung über die KI-API zustimmen? | BauIn IT |
+| Datenverarbeitung bei API-Werk (C2) | Standort, Speicherdauer, Auftragsverarbeitung, kein Training. Klärt ITM; wir brauchen nur das Ergebnis für die Doku | ITM |
+| Alarmierung (E11.3) | Ohne E-Mail aus der Anwendung: über die Überwachung von ITM? | ITM |
+
+Nach dem Livegang von Phase 1: Aufbewahrung nach Projektende (A27), Nutzung der DB-Richtlinien in
+einem KI-System (A28).

 ## Entscheidungen

@@ -41,7 +62,7 @@ C12 (wer deployt).
 |---|---|---|---|
 | 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 |
+| E11.3 | Alarmierung | Die Anwendung verschickt keine E-Mails (B3). Vorschlag: Lebenszeichen und Prüfbefehle, die die Überwachung von ITM abfragt | offen (mit ITM) |

 ## Schritte

@@ -55,7 +76,7 @@ C12 (wer deployt).
  - Lebenszeichen für Worker und Scheduler
  - Zählung fehlgeschlagener Jobs
  - Statusprüfung der KI-API (aus AP3)
-  - Mail bei Problemen (E11.3)
+  - Meldung bei Problemen nach 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
@@ -65,7 +86,7 @@ C12 (wer deployt).
 ## 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.
+- Ein absichtlich gestoppter Worker löst innerhalb von 10 Minuten einen Alarm aus (Weg nach E11.3).
 - Der Restore-Test war erfolgreich und ist dokumentiert.

 ## Risiken
@@ -28,22 +28,30 @@ 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.
+Erfüllt am 05.10.: **Stand 0.3** von Claude Design mit unseren Änderungen 1–26 und einer
+UX-Überarbeitung. Er liegt im Planungsordner unter `claude-design/2026-10-05_Stand-0.3/`:
+- `Uebergabe.md`: maßgebliche Spezifikation, Abschnitte 0–9
+- `README.md`: Zusammenfassung mit Design-Tokens
+- `prototyp/`: `.dc.html`-Dateien mit `support.js`, im Browser zu öffnen
+- `screenshots/`: 27 PNG, ein Bild je Zustand, 1440 px breit, für den Abgleich
+- `icons/`: Phosphor 2.1.1 als SVG
+- `logo/`: Logo-SVGs
+
+Der Stand ist **verbindlich** (High-Fidelity): Farben, Schriften, Abstände, Texte und Zustände
+werden genau übernommen. Bei Widerspruch gilt der Prototyp vor den Screenshots.

 ## 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 |
+| E13.1 | Schriften | League Spartan und IBM Plex über `@fontsource`-Pakete, lokal gebündelt. Sie sind nicht im Übergabepaket | offen |
+| E13.2 | Icons | Die gelieferten SVGs (Phosphor 2.1.1, MIT) als lokales Icon-Set; TallStackUI erlaubt eigene SVG-Komponenten. Alternative: Blade-Paket `codeat3/blade-phosphor-icons`, dann Version gegen 2.1.1 prüfen | offen |
+| E13.3 | Ablage der Entwürfe im Repository | Stand 0.3 vollständig nach `docs/design/` (nur erfundene Daten, rund 5 MB), damit Claude Code bei jeder Seite nachsehen kann | offen |

 ## Schritte

- [ ] **13.1** Stand von Claude Design in `docs/design/` ablegen (E13.3), Unterschiede zur
-  Rückmeldung notieren
+- [ ] **13.1** Stand 0.3 in `docs/design/` ablegen (E13.3). Unterschiede zur Rückmeldung und zu
+  den Antworten sind schon notiert (Abschnitt „Abgleich Stand 0.3“)
 - [ ] **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,
@@ -60,6 +68,41 @@ Benötigt werden die Übergabe (Abschnitte 1–9) und die `.dc.html`-Dateien. Bi
 - [ ] **13.7** Musterseite „Designsystem“ (nur in der Entwicklung) und Abgleich mit dem Prototyp
  per Screenshot; bestehende Seiten (Login, Einstellungen, AP1-Seiten) umstellen

+## Abgleich Stand 0.3 (05.10.)
+
+**Passt zu Plan und Entscheidungen:**
+- TallStackUI 4 mit Präfix `ts-`, eigene Komponenten ohne Präfix (`x-confidence`,
+  `x-review-question`, `x-source-choice`, `x-contract-coverage`, `x-coachmark`)
+- Schriften und Icons in der Anwendung lokal; der Prototyp lädt sie nur zur Ansicht von fremden Servern
+- Gliederung Projekt → PFA → Vertrag → LVs, Nachträge am Vertrag, MKA nur als Verweis (A8)
+- Nur „dem Grunde nach“: keine Mengen, Preise oder Anspruchsgrundlage. Höhe und Regelwerk sind
+  nicht entworfen; die Quellenanzeige in Spalte 3 ist für den späteren Chat wiederverwendbar.
+- Suchbereiche: Vertrag, andere Verträge im PFA per Schalter, andere PFA nur als Hinweis mit EP,
+  nie projektübergreifend (A10, A11)
+- Rollen Administrator, Projektleiter, Bearbeiter, Leser. „Kein Zugriff“ verrät nicht, ob es das
+  Objekt gibt (A25, AP1).
+- Länderwahl nur bei mehreren Ländern (A26: Österreich in Phase 2)
+- Benachrichtigungen nur in der Anwendung (B3)
+- Ergebnisliste mit Excel-Export; Bewertungsmatrix deaktiviert, bis die Vorlage da ist (OP1)
+
+**Abweichungen und wie wir sie behandeln** (Vorschlag, bitte bestätigen):
+
+| Stelle im Prototyp | Widerspricht | Umgang |
+|---|---|---|
+| Projekt anlegen v3 · 2b „Ablage für Dateien oder ZIP mit Ordnern“; Übergabe 6.8 „Upload allgemein … ZIP“ | B4: kein ZIP | Nur Mehrfach-Upload, Text ohne „ZIP“ |
+| Ergebnisliste v2: Export „Stellungnahme (Word)“, deaktiviert; Übergabe 6.8: Export-Vorlage Stellungnahme | A15: Phase 2 | Weglassen |
+| Regeldialog v3: „Freigabe immer durch den Projektleiter“, keine Einstellung | A24-Vorschlag „ohne Freigabe“, Gesamtplan „einstellbare Freigaben“ | Entscheidung E8.1 in AP8 |
+| Projektdetail v2: Reiter nur PFA & Verträge · Nachträge · Berechtigungen · Einstellungen; Übersicht, Dokumente und Protokoll aus Rückmeldung 19 fehlen | – | Prototyp gilt; Protokoll unter Verwaltung (AP1, 1.11). Falls A2 weitere Vertragsunterlagen bringt, braucht es dafür einen Ort |
+| Projektdetail v2 · Einstellungen: nur „Andere Verträge im selben PFA einbeziehen“; „Andere PFAs“ und „Nur gleicher Auftragnehmer“ entfallen | A10 noch offen | Prototyp gilt, bis A10 etwas anderes ergibt; Datenmodell in AP1, 1.4b |
+| Projekt anlegen v3 ohne Vertragsgrundlage | `projekte.vertragsgrundlage` im Datenmodell | Feld bleibt mit Standardwert, nicht im Formular (AP1, 1.4b) |
+| Zielgruppe „nur deutschsprachig“ | Oberfläche Deutsch und Englisch | Kein Widerspruch: Die deutschen Texte werden wörtlich übernommen, Englisch bleibt als Übersetzung |
+| Logo: Wortmarke als Text, „ein finales Logo gibt es noch nicht“ | – | Vorläufig verwenden, vor dem Einsatz in Pfade umwandeln |
+| „Passt / Passt nicht“ aus unserer Rückmeldung (7, 9, 11) | – | In 0.3 ersetzt durch Auswahl der Fundstelle und Ja / Nein; AP6 angepasst |
+
+Nicht im Paket und auch nicht nötig: die Archivordner „Stand 0.1/0.2“ und die Schriftdateien.
+Wenn die Abweichungen bestätigt sind, geht eine kurze Rückmeldung im Format von Abschnitt 9 an
+Claude Design (ZIP und Stellungnahme entfernen, E8.1).
+
 ## Abnahmekriterien

 - Die Musterseite entspricht dem Designsystem des Prototyps in Hell und Dunkel.
@@ -74,5 +117,5 @@ Benötigt werden die Übergabe (Abschnitte 1–9) und die `.dc.html`-Dateien. Bi

 ## Risiken

- Claude Design liefert spät. Dann mit dem bisherigen Stand beginnen; die Prüfmaske kommt ohnehin
-  erst in AP6.
+- Weitere Stände von Claude Design während der Umsetzung: Nur übernehmen, was im
+  Änderungsprotokoll der Übergabe (Abschnitt 8) steht, und Tokens zentral halten.
@@ -4,7 +4,7 @@
 |---|---|
 | 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 |
+| Zeitraum | OP1 KW 51 (bei 35–40 h pro Woche), sonst nach M4. OP2 erst in Phase 2 (A15, 05.10.) |
 | Freigabe | offen |

 ## OP1 – Bewertungsmatrix in der Excel-Vorlage der DB
@@ -21,6 +21,8 @@

 ## OP2 – Stellungnahme BÜW als Word-Datei

+**Vertagt auf Phase 2** (A15, 05.10.). Die Schritte bleiben als Merkposten stehen.
+
 **Ziel:** Das Deckblatt zur Bewertungsmatrix (Ansprechpartner, Bearbeiter, Nachtrag, Sachverhalt)
 wird aus der Vorlage erzeugt.