Mission 5: Fehler finden und Zugriff prüfen

Planzeit: 4 Stunden. Achievements: A07 Version gerettet (125 XP, Nachweis ROLLBACK.md), A08 Bugjäger (150 XP) bei 2 von 2 Fehlertests, A09 Zugriff geprüft (150 XP) bei 3 von 3 Zugriffstests.

Ziel

Du findest zwei vorbereitete Fehler, behebst sie so, dass Tests das belegen, stellst eine funktionierende Version wieder her und prüfst, dass Zugriff und Geheimnisse in Ordnung sind.

Teil A: Zwei vorbereitete Fehler (A08)

In src/domain/followUpSchedule.ts stecken zwei Fehler. Das Modul ist vorgegeben; in Mission 3 hat es für die Testdaten funktioniert. Jetzt nicht mehr.

Kriterium	Was geprüft wird
C02-M5-01	`isOverdue` erkennt ein Follow-up vom 10. März als überfällig, wenn heute der 15. März ist. Heute selbst und morgen sind nicht überfällig.
C02-M5-02	`sortByFollowUp` sortiert aufsteigend, Leads ohne Datum zuletzt, bei gleichem Datum bleibt die Reihenfolge stabil, und das übergebene Array wird nicht verändert.

Vorgehen, das du später in jeder Codebasis brauchst:

npm run bic -- check 5 ausführen. Beide Tests sind rot. Lies die Meldungen: "expected false to be true" und eine falsche Reihenfolge.
Lies den Code laut. Frage bei jeder Zeile: Was macht slice(0, 7) mit "2026-03-10"? Was gibt leads.sort(...) zurück, und was passiert mit leads?
Formuliere die Fehler in je einem Satz, bevor du etwas änderst. Schreib sie ins KI-PROTOKOLL.
Behebe sie. Tests grün. Commit: "Mission 5: isOverdue und sortByFollowUp korrigiert".

Teil B: Eine Version retten (A07)

Jetzt machst du absichtlich etwas kaputt und holst es zurück. Das übt den Weg, den du brauchst, wenn ein KI-Vorschlag mehr zerstört als hilft.

Ändere sortByFollowUp so, dass sie wieder direkt auf dem Array sortiert (ohne Kopie). Speichern, npm run bic -- check 5: C02-M5-02 ist rot.
Finde mit git log --oneline -5 und git diff heraus, welcher Commit noch funktioniert hat.
Hole die Datei zurück: git checkout <commit> -- src/domain/followUpSchedule.ts. Tests grün.
Schreib ROLLBACK.md im Projektordner: Was ist passiert, welche Befehle hast du verwendet, welcher Commit war die gute Version, was lernst du daraus. Eine halbe Seite reicht. Die Datei ist der Nachweis für A07.

Teil C: Zugriff und Geheimnisse (A09)

Diese Tests sind vorgegeben und geführt. Du baust keine Sicherheitsprüfung, du machst drei konkrete Dinge richtig.

Kriterium	Was geprüft wird	Was du tun musst
C02-M5-03	Kein Token im Quellcode: `.env.example` existiert, `.env` steht in `.gitignore`, in `src/` steht nirgends `"test-token"` oder `VITE_API_TOKEN=` (ausser im Simulator selbst).	Prüfen, dass du den Token nirgends hart eingetragen hast. `readApiTokenFromEnv()` ist der einzige Weg.
C02-M5-04	Mit einem falschen Token zeigt das Panel `api-unauthorized` mit einem verständlichen Satz, und der Token erscheint nirgends im HTML.	In `FollowUpPanel` den Fall `error.kind === "unauthorized"` behandeln. Nie den Token in eine Meldung schreiben.
C02-M5-05	Zwei Repositories mit verschiedener `workspaceId` auf demselben `localStorage` sehen einander nicht.	Wenn dein Schlüssel aus Mission 3 die `workspaceId` enthält, ist das schon erfüllt.

Warum das wichtig ist: Ein Token im Code landet im Git-Verlauf und bei jedem, der den Code bekommt. Ein Token in einer Fehlermeldung landet in Screenshots und Support-Tickets. Zwei Firmen, die dieselbe App nutzen, dürfen nie die Daten der anderen sehen.

Abschluss

npm run bic -- check 5 zeigt 5 von 5 Kriterien und die Nachweisdatei ROLLBACK.md. Commit, KI-PROTOKOLL, npm run bic -- submit 5.

Erklären

Warum war isOverdue in Mission 3 unauffällig und erst hier rot? Was sagt das über Testdaten?
Was wäre passiert, wenn sortByFollowUp in der Liste und gleichzeitig im Repository dasselbe Array sortiert hätte?
Nenne zwei Orte, an denen ein Token landen kann, obwohl er nie im Code stand.

Hinweise

missions/hints/05-1.md (Fehler lesen), missions/hints/05-2.md (git checkout), missions/hints/05-3.md (Token-Fall im Panel).

Weiter mit missions/06-uebergabe.md.