Baustein 2: Inhalte einlesen und pruefen, Handouts, Suche, Glossar

Die fachlichen Inhalte liegen als Dateien unter content/ und werden beim
Start eingelesen, geprueft und in den Speicher geladen.

- Inhaltslader mit Zod-Schemata und Querverweispruefung
- Fehlermeldungen nennen Datei und Zeile, gesammelt statt beim ersten
  Fehler geworfen; die Anwendung startet bei Fehlern nicht
- npm run inhalte:pruefen prueft ohne Start
- Handout-Ansicht mit festem Aufbau, Uebersicht nach Themenbloecken
- Volltextsuche mit Gewichtung und Trefferausschnitt
- Gelesen-Markierung je Handout
- Glossar mit Suche und automatischer Verlinkung in den Handouts
- Beispielinhalte: 4 Wochen, 12 Handouts, 24 Merkkarten, 4 Aufgaben,
  4 Checklisten, 2 Lernzielkontrollen, 24 Glossareintraege
- rahmenplan.yaml aus FIAusbV 2020 und KMK-Rahmenlehrplan, mit Fundstellen
- gray-matter entfernt, YAML-Kopf wird selbst herausgeloest
- npm run screenshots nimmt die Bilder fuer die Anleitung auf
- 39 neue Tests, insgesamt 68

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

content/handouts/A1-ticket-schreiben.md

@@ -0,0 +1,49 @@
+---
+id: A1
+titel: Ein Ticket schreiben, das keine Rückfrage auslöst
+block: arbeitsalltag
+woche: 1
+worum: Ein gutes Ticket beantwortet vorab die drei Fragen, die sonst als Rückfrage zurückkommen.
+rahmenplan: [A1, A2]
+lernfeld: LF6
+merksatz: Wer, was, seit wann – und was schon versucht wurde. Alles andere ist Beiwerk.
+karten:
+  - frage: Welche vier Angaben gehören in jedes Ticket, bevor du es abschickst?
+    antwort: Betroffene Person und Gerät, beobachtetes Verhalten im Wortlaut, Zeitpunkt des ersten Auftretens, und was bereits versucht wurde.
+  - frage: Warum ist „Drucker geht nicht" ein schlechter Betreff?
+    antwort: Er nennt weder Gerät noch Fehlerbild. Besser ist „Kyocera Flur 2 – Druckaufträge bleiben in der Warteschlange, seit heute 08:00".
+---
+
+## Das Wesentliche
+
+- **Ein Ticket pro Problem.** Zwei Störungen in einem Ticket führen dazu, dass eine davon
+  beim Schließen untergeht.
+- **Betreff wie eine Schlagzeile:** Gerät oder Dienst, Fehlerbild, Zeitpunkt. Der Betreff
+  muss für sich allein verständlich sein – in der Übersicht sieht man nichts anderes.
+- **Fehlermeldungen im Wortlaut**, abgetippt oder als Bildschirmfoto, nicht sinngemäß.
+  „Irgendwas mit Netzwerk" kostet später eine halbe Stunde.
+- **Was schon versucht wurde**, gehört hinein. Sonst macht es der Nächste noch einmal.
+- **Erreichbarkeit und Dringlichkeit** notieren: Wann ist die Person am Platz? Blockiert die
+  Störung die Arbeit oder ist sie lästig?
+- **Beim Schließen** schreibst du auf, was die Ursache war und was du getan hast – nicht
+  „erledigt". Das Ticket ist die Dokumentation, und zwar die einzige.
+
+## Übersicht
+
+| Feld | Schlecht | Gut |
+|------|----------|-----|
+| Betreff | Drucker geht nicht | Kyocera Flur 2 – Aufträge bleiben in Warteschlange, seit 08:00 |
+| Beschreibung | Fehler beim Drucken | Meldung „Der Spooler-Dienst wird nicht ausgeführt", betrifft alle Nutzer in Halle 2 |
+| Bereits versucht | *(leer)* | Neustart des Clients, Drucker aus- und eingeschaltet |
+| Abschluss | erledigt | Warteschlange geleert, Spooler-Dienst neu gestartet; Ursache war ein hängender Auftrag von PC-042 |
+
+## Prüfungsfrage
+
+**Frage:** Nennen Sie drei Angaben, die eine Störungsmeldung enthalten muss, damit sie ohne
+Rückfrage bearbeitet werden kann, und begründen Sie jeweils kurz.
+
+**Antwort:** (1) Betroffenes System oder Gerät – sonst ist unklar, wo gesucht werden muss.
+(2) Beobachtetes Verhalten samt Fehlermeldung im Wortlaut – erlaubt die Eingrenzung ohne
+Rückfrage. (3) Zeitpunkt des ersten Auftretens – erlaubt den Abgleich mit Änderungen und
+Protokolldateien. Zusätzlich sinnvoll: bereits durchgeführte Maßnahmen und die
+Erreichbarkeit des Melders.