Fix #46: Wo die Daten liegen, und drei Fallen aus dem Betrieb #53

2026-09-01T14:37:17Z

florian.wilde commented

2026-09-01 14:37:17 +00:00

Closes #46

Neuer Abschnitt „Wo deine Daten liegen"

Zwischen Schritt 11 und Aktualisieren. Nennt die drei Orte, zeigt den Pfad auf der Platte, sagt ausdrücklich, dass dort keine anklickbaren PDFs liegen — und beschreibt den Abgleich zwischen Akte und Speicher.

Dieser Abgleich ist der eigentliche Wert: Zu jedem Akteneintrag muss eine Datei gehören, sonst belegt eine Prüfsumme ein Dokument, das es nicht mehr gibt.

Dazu eine Tabelle der drei Schlüssel, ohne die nichts mehr lesbar ist.

Drei Fallen, alle aus der Praxis

Der mc-Alias überlebt kein Neuerstellen. Er liegt in /root/.mc im Behälter und ist nach jedem docker compose up -d minio weg. mc ls lokal liefert dann kommentarlos nichts — man hält seine Dokumente für verschwunden. Genau das ist passiert. Jeder Aufruf setzt den Alias jetzt selbst, aus $MINIO_ROOT_USER/$MINIO_ROOT_PASSWORD des Behälters.

Der Bucket-Name war fest verdrahtet, die Anwendung liest ihn aus S3_BUCKET. Weichen sie ab, zeigen beide aneinander vorbei.

set -a && source .env wurde empfohlen, ohne zu sagen, dass die exportierten Werte danach jedes docker compose up überstimmen. Wer später die .env ändert und neu startet, sieht keine Wirkung. Der Kniff ist nicht mehr nötig — der neue Befehl kommt ohne ihn aus — und die Falle steht als Erklärung daneben.

Nebenbei

docker-compose.override.yml in der .gitignore und in der Anleitung als vorgesehener Ort für Anpassungen, die ein Update überleben sollen. update.sh prüft nur versionierte Dateien (--untracked-files=no) und lässt sie in Ruhe.

Die Aussage zur Sicherung ist mitgezogen — sie stimmt seit #41 nicht mehr.

Geprüft

769 Unit-Tests, tsc und Lint sauber.

tests/anleitung.test.ts prüft die Anleitung wie Code: kein mc-Aufruf ohne Alias im selben Block, kein fester Bucket-Name, kein source .env, der Abschnitt vorhanden, die Schlüssel genannt. Gegen vier Mutationen — jede wird rot.

Closes #46 ## Neuer Abschnitt „Wo deine Daten liegen" Zwischen Schritt 11 und *Aktualisieren*. Nennt die drei Orte, zeigt den Pfad auf der Platte, sagt ausdrücklich, dass dort **keine** anklickbaren PDFs liegen — und beschreibt den Abgleich zwischen Akte und Speicher. Dieser Abgleich ist der eigentliche Wert: Zu jedem Akteneintrag muss eine Datei gehören, sonst belegt eine Prüfsumme ein Dokument, das es nicht mehr gibt. Dazu eine Tabelle der drei Schlüssel, ohne die nichts mehr lesbar ist. ## Drei Fallen, alle aus der Praxis **Der `mc`-Alias überlebt kein Neuerstellen.** Er liegt in `/root/.mc` **im Behälter** und ist nach jedem `docker compose up -d minio` weg. `mc ls lokal` liefert dann kommentarlos nichts — man hält seine Dokumente für verschwunden. Genau das ist passiert. Jeder Aufruf setzt den Alias jetzt selbst, aus `$MINIO_ROOT_USER`/`$MINIO_ROOT_PASSWORD` des Behälters. **Der Bucket-Name war fest verdrahtet**, die Anwendung liest ihn aus `S3_BUCKET`. Weichen sie ab, zeigen beide aneinander vorbei. **`set -a && source .env` wurde empfohlen**, ohne zu sagen, dass die exportierten Werte danach *jedes* `docker compose up` überstimmen. Wer später die `.env` ändert und neu startet, sieht keine Wirkung. Der Kniff ist nicht mehr nötig — der neue Befehl kommt ohne ihn aus — und die Falle steht als Erklärung daneben. ## Nebenbei `docker-compose.override.yml` in der `.gitignore` und in der Anleitung als vorgesehener Ort für Anpassungen, die ein Update überleben sollen. `update.sh` prüft nur versionierte Dateien (`--untracked-files=no`) und lässt sie in Ruhe. Die Aussage zur Sicherung ist mitgezogen — sie stimmt seit #41 nicht mehr. ## Geprüft **769 Unit-Tests**, `tsc` und Lint sauber. `tests/anleitung.test.ts` prüft die Anleitung wie Code: kein `mc`-Aufruf ohne Alias im selben Block, kein fester Bucket-Name, kein `source .env`, der Abschnitt vorhanden, die Schlüssel genannt. Gegen vier Mutationen — jede wird rot.

florian.wilde added 1 commit 2026-09-01 14:37:18 +00:00

Anleitung: wo die Daten liegen, und drei Fallen aus dem Betrieb 042e63812b

Aus einer Fehlersuche am 31.08.2026 sind vier Luecken in der Anleitung
uebriggeblieben. Keine davon war falsch formuliert - alle vier waren
schlicht nicht durchdacht.

1. Es stand nirgends, wo die Daten liegen. Der neue Abschnitt nennt die
   drei Orte, zeigt den Pfad auf der Platte, sagt ausdruecklich, dass dort
   keine anklickbaren PDFs liegen, und beschreibt den Abgleich zwischen
   Akte und Speicher: Zu jedem Eintrag muss eine Datei gehoeren, sonst
   belegt eine Pruefsumme ein Dokument, das es nicht mehr gibt.

2. Der mc-Alias wurde einmalig gesetzt. Er liegt in /root/.mc IM
   Behaelter und ist nach jedem "docker compose up -d minio" weg -
   "mc ls lokal" liefert dann kommentarlos nichts, und man haelt seine
   Dokumente fuer verschwunden. Genau das ist passiert. Jeder Aufruf setzt
   den Alias jetzt selbst, aus den Variablen des Behaelters.

3. Der Bucket-Name stand fest im Befehl, die Anwendung liest ihn aus
   S3_BUCKET. Weichen sie ab, zeigen beide aneinander vorbei.

4. "set -a && source .env" wurde empfohlen, ohne zu sagen, dass die
   exportierten Werte danach jedes "docker compose up" ueberstimmen. Wer
   spaeter die .env aendert und neu startet, sieht keine Wirkung und sucht
   den Fehler ueberall, nur nicht in der eigenen Shell. Der Kniff ist
   nicht mehr noetig - der neue Befehl kommt ohne ihn aus - und die Falle
   steht als Erklaerung daneben.

Dazu docker-compose.override.yml in der .gitignore und in der Anleitung
als vorgesehener Ort fuer Anpassungen, die ein Update ueberleben sollen:
update.sh prueft nur versionierte Dateien und laesst sie in Ruhe.

Die Aussage zur Sicherung ist mitgezogen - sie stimmt seit #41 nicht mehr,
die Dokumente sind jetzt enthalten.

Neun Pruefungen in tests/anleitung.test.ts, gegen vier Mutationen
geprueft: Name fest verdrahtet, Alias nicht gesetzt, source .env zurueck,
Abschnitt entfernt - jede wird rot.

Refs #46

florian.wilde merged commit 890e00fb5c into main

2026-09-01 14:37:26 +00:00

florian.wilde deleted branch fix/46-doku-datenorte

2026-09-01 14:37:26 +00:00

florian.wilde referenced this pull request

2026-09-01 14:37:41 +00:00

Doku: Wo die Daten liegen, wie man sie prüft, und drei Fallen im Betrieb #46

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: florian.wilde/betreuungs-cockpit#53