Baustein 10b: Anleitung mit Screenshots, Abnahmelauf, Fassung 1.0.0

docs/ANLEITUNG.md: 20 Abschnitte, 27 Bildschirmfotos, getrennt fuer
Ausbilder und Azubi, dazu "Wenn etwas nicht geht". Die Bilder entstehen
automatisiert ueber npm run screenshots - was dort steht, ist gemessen
und nicht gemalt.

scripts/pruefungen/abnahme.mjs (npm run abnahme) laeuft gegen eine
frische, leere Datenbank in einem Wegwerfverzeichnis: aufsetzen, Konten
anlegen, arbeiten, abnehmen, sichern, beschaedigen, zurueckspielen. Eine
Sicherung, die nie zurueckgespielt wurde, ist keine Sicherung. 33 von 33
Pruefungen erfuellt, Protokoll in docs/ABNAHME.md.

Dabei drei echte Fehler gefunden, alle in Wegen, die nie ausgefuehrt
worden waren:

- Die Sicherungsskripte liefen nicht in Git Bash, obwohl das in ihrem
  Kopf stand: tar deutet den Doppelpunkt in "C:\..." als Rechnernamen.
  Beide wechseln jetzt erst ins Verzeichnis und uebergeben einen blossen
  Dateinamen.
- Auf einer frischen Datenbank gibt es noch kein Wochenblatt; der Weg
  jedes neuen Azubis war nie durchlaufen worden.
- Der Abnahmelauf selbst liess unter Windows seinen Server ueberleben
  (kill() beendet nur die cmd.exe) und prueft deshalb jetzt vorher, ob
  der Port frei ist - sonst haette er gegen fremde Daten geprueft.

Fassung 1.0.0: package.json stand noch auf 0.1.0, waehrend das
Aenderungsprotokoll bei 0.9.0 war.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

ENTSCHEIDUNGEN.md

@@ -410,3 +410,64 @@ sondern die Stellen, an denen sie auseinandergehen.
 Bestätigen können beide einzeln; erst wenn **beide** bestätigt haben, ist das
 Gespräch unveränderlich. Solange nur eine Seite bestätigt hat, lässt sich die
 Bestätigung zurücknehmen.
+
+## E38 · Was offline liegen darf – und was niemals
+
+Die Regel steht in `public/sw.js`, in einer einzigen Funktion:
+`darfOfflineLiegen()`.
+
+**Offline liegt nur Lernmaterial:** Handouts, Merkkarten, Glossar, die eigene
+Woche. **Nicht** Lernzielkontrollen, Berichtsheft, Bewertungen,
+Feedbackgespräche, Anhänge und kein PDF.
+
+Der Grund ist keine Sparsamkeit, sondern eine Zusage aus dem Pflichtenheft:
+Musterlösungen und Bewertungsdaten stehen hinter einer eigenen Prüfung. Diese
+Prüfung findet auf dem Server statt. Was im Browserspeicher liegt, wird beim
+nächsten Zugriff nicht mehr geprüft – es wird ausgeliefert. Ein Dienstarbeiter,
+der „alles" zwischenspeichert, hebelt damit genau die Zusage aus, die am
+schwersten wiegt.
+
+Seiten werden nach dem Muster **erst das Netz, dann der Speicher** geholt:
+Nach einer Aktualisierung sieht man sofort die neue Fassung, und nur bei
+fehlendem Netz die alte. Dateien unter `/_next/static/` tragen eine Prüfsumme
+im Namen und werden zuerst aus dem Speicher bedient.
+
+Beim Abmelden wird alles Persönliche weggeräumt – ein Werkstattgerät wird
+geteilt.
+
+## E39 · Die Warteschlange gehört zur Anmeldung, nicht zum Gerät
+
+Offline entstandene Bewertungen liegen unter
+`lernbar-warteschlange-<benutzerId>` im `localStorage`.
+
+Unter einem festen Schlüssel bekäme auf einem geteilten Gerät der Zweite die
+offenen Bewertungen des Ersten auf sein Konto geschrieben – und der Erste hätte
+sie nie. Beim Abmelden wird die Schlange deshalb auch **nicht** gelöscht: Sie
+gehört zur Anmeldung und wird beim nächsten Mal nachgereicht. Verworfen würde
+sonst eine Lernleistung, die jemand erbracht hat.
+
+`localStorage` und nicht IndexedDB: Es geht um eine Handvoll Einträge zwischen
+zwei Verbindungen. Geht der Speicher verloren, ist eine Karte falsch
+terminiert – dafür lohnt kein zweites Datenmodell.
+
+## E40 · Der Tag einer nachgereichten Bewertung
+
+`tagDerBewertung()` in `src/lib/offline/nachtrag.ts`, mit eigenen Tests.
+
+Der Tag kommt vom **Gerät**, weil nur dort bekannt ist, wann tatsächlich
+gelernt wurde: Wer freitags im Keller lernt und sich montags wieder verbindet,
+soll seinen Freitag angerechnet bekommen.
+
+Er wird auf **heute gedeckelt**. Sonst ließe sich das Wiederholen wegstellen,
+indem man die Uhr des Geräts vordatiert – die Karte käme dann erst in ferner
+Zukunft wieder. Unlesbares gilt als heute.
+
+## E41 · Im Druck gilt immer die helle Fassung
+
+Die vollständige helle Palette wird unter `@media print` noch einmal gesetzt,
+und zwar auch für `:root[data-thema="dunkel"]`.
+
+Der Grund ist banal und war ein echter Fehler: Wer die dunkle Fassung
+eingestellt hatte, druckte schwarze Flächen. Eine einzelne Regel für `body`
+genügt nicht, weil die Karten, Ränder und Marken ihre Farben aus Merkmalen
+beziehen.