feat(mandant): Betriebsmodus, Kundenverwaltung und Einstellungen (#22)
Prüfung / pruefung (push) Canceled after 0s
Prüfung / e2e (push) Canceled after 0s

Zwei Betriebsmodi, ein Codepfad. src/server/mandant.ts ist die eine Stelle,
an der die Mandantenregel steht.

Der Review fand drei Blocker: die Lesemodelle wandten die Mandantensicht nicht
an, der Protokolleintrag des Moduswechsels stand außerhalb der Transaktion, und
Prüfung und Vollzug lagen so weit auseinander, dass zwei gleichzeitige Wechsel
beide durchliefen. Alle drei geschlossen, der letzte mit einem Advisory Lock.

336 Tests.

Closes #8

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit was merged in pull request #22.
This commit is contained in:
2026-09-25 05:03:11 +00:00
co-authored by Claude Opus 5
parent 40e95dbe5f
commit ecc3c579df
43 changed files with 2729 additions and 53 deletions
+50 -2
View File
@@ -10,11 +10,12 @@ als Unterpunkte mit Aufgabe und Dauer.
| #005 | M0 – Gerüst, Prozess, Design-Token | 1 h 25 min |
| #006 | M1 – Datenmodell | 1 h 10 min |
| #007 | M2 – Auth, Rollen, Benutzer | 1 h 35 min |
| | **Summe** | **4 h 10 min** |
| #008 | M3 – Betriebsmodus und Kunden | 1 h 20 min |
| | **Summe** | **5 h 30 min** |
| Meilenstein | Tatsächlich | Status |
|---|---|---|
| v0.1.0 | 4 h 10 min | in Arbeit |
| v0.1.0 | 5 h 30 min | in Arbeit |
---
@@ -223,3 +224,50 @@ als Unterpunkte mit Aufgabe und Dauer.
- #008 Betriebsmodus und Kunden: `betriebsmodus()`, `kundeErmitteln()`, Moduswechsel in beiden
Richtungen, Kundenverwaltung, Admin-Einstellungen.
---
## 2026-09-25 · Sitzung 4 · 05:35–07:00
**Issue:** #008 (M3)
**Version:** 0.1.0
### Erledigt
- `src/server/mandant.ts` als die eine Stelle für die Mandantenregel
- Moduswechsel in beiden Richtungen, Kundenverwaltung (Sub-Agent, 25 Tests), Admin-Einstellungen
- Wechsel per Playwright **durch die Oberfläche** gefahren, nicht nur im Service: Navigation
wechselt sofort, `/kunden` wird erreichbar
- Unabhängiger Review: drei Blocker, sechs weitere Befunde, alle abgearbeitet
- **336 Tests** grün (vorher 274)
### Entscheidungen
- **Die Sichtbarkeit gehört in `kundeErmitteln`,** nicht in eine zweite Funktion daneben. Sonst
müsste jeder künftige Service daran denken — und #009 ff. übernehmen diese Signatur.
- **Lesemodelle filtern selbst.** Sie verlangen den Benutzer, statt sich auf den Aufrufer zu
verlassen. `undefined` heißt „keine Einschränkung", `[]` heißt „sieht nichts"; die Umsetzung
steht an einer Stelle, und beide Fälle haben einen Test.
- **`pg_advisory_xact_lock` statt Serializable.** Der Wechsel ist selten und kurz; ein Schloss auf
Transaktionsebene ist verständlicher als eine Isolationsstufe, die man beim Lesen übersieht, und
wird auch bei einem Abbruch freigegeben.
- **Die Prüfung läuft zweimal** — einmal für den Dialog, einmal innerhalb der Transaktion. Beide
Male derselbe Code, damit es keine nachgebaute zweite Wahrheit gibt.
- **ASCII-Faltung gilt für Bezeichner, nicht für Fließtext.** Steht jetzt ausdrücklich in
`CLAUDE.md`; Protokoll-Aktionen sind entsprechend nachgezogen.
### Probleme
- **Ich habe in einem Kommentar etwas behauptet, das nicht stimmte** („Alles in einer
Transaktion"), während der Protokolleintrag dahinter stand. Ein Kommentar, der eine Zusage
macht, gehört genauso geprüft wie der Code darunter.
- **`sichtbareKundenIds` hatte keinen einzigen Aufrufer.** Eine Funktion zu schreiben, die eine
Regel durchsetzt, und sie dann nirgends zu rufen, sieht im Review aus wie Absicht und ist es
nicht. Der Volltextlauf über `src` hätte das in zehn Sekunden gezeigt.
- **Der Wettlauf war reproduzierbar**, nicht theoretisch: zwei gleichzeitige Wechsel liefen beide
durch.
### Nächster Schritt
- #009 Vorlagen-Versionierung: Veröffentlichen, tiefe Kopie als Entwurf, höchstens ein Entwurf,
Unveränderlichkeit, JSON-Export und -Import.