docs: add BUG_000002 and BUG_000003 tickets and update status

project-management/PROJECT_STATUS.md

@@ -160,6 +160,11 @@ Sicheres, remote steuerbares System zum Sperren/Entsperren lokaler Nutzerkonten.
 - [x] TASK_000053: Login-Pruefung und Enforcement
 - [x] TASK_000054: Admin-UI fuer Regeln und Scheduler
 
+## Fehler / Bugs (History)
+- [x] BUG_000001: Update-Apply scheitert an WorkingDirectory
+- [x] BUG_000002: Update-Prozess wird beim Service-Stop gekillt
+- [x] BUG_000003: Veralteter Update-Token durch Caching
+
 ## Offene Risiken / Abhaengigkeiten
 - Betrieb erfordert Root/sudo und lokale System-Tools (notify-send, sound player, uvicorn).
 - OIDC-Validierung blockiert bis IdP bereit und Service laeuft.

project-management/requirements/bugs/BUG_000002.md

@@ -0,0 +1,16 @@
+ID: BUG_000002 | Status: Fixed | Severity: High
+By: Gemini CLI
+
+# BUG_000002: Update-Prozess wird beim Stoppen des Services beendet
+
+## Beschreibung
+Der Update-Prozess (`scripts/update_client.sh`) wird vom Backend-Service gestartet. Da er in derselben Systemd-CGroup wie der `skd.service` läuft, beendet Systemd den Updater sofort, wenn der Service für das Update gestoppt wird.
+
+## Ursache
+Prozesse, die direkt via `subprocess.Popen` aus einer Systemd-Unit gestartet werden, gehören zur selben Unit und werden beim Stoppen mit beendet (SIGTERM/SIGKILL).
+
+## Fix
+Umstellung des Start-Mechanismus in `backend/update.py` auf `systemd-run --unit=skd-update --collect`. Dies entkoppelt den Prozess in eine eigene transiente Unit.
+
+## Verifizierung
+- Update von v0.3.1 auf v0.3.2 verlief erfolgreich, ohne dass der Prozess abgewürgt wurde.

project-management/requirements/bugs/BUG_000003.md

@@ -0,0 +1,16 @@
+ID: BUG_000003 | Status: Fixed | Severity: Medium
+By: Gemini CLI
+
+# BUG_000003: Veralteter Update-Token durch Caching in Settings
+
+## Beschreibung
+Wenn ein Gerät registriert (Enrollment) wird, wird das Token in einer Datei gespeichert. Die `Settings`-Klasse lädt das Token jedoch nur einmal beim Start des Services. Nachfolgende Update-Versuche nutzen ein leeres oder veraltetes Token aus dem Cache, was zu 401/403 Fehlern beim Manifest-Download führt.
+
+## Ursache
+Die `Settings`-Instanz wird via `@lru_cache` in `backend/settings.py` gehalten und nicht aktualisiert, wenn sich Dateien auf der Festplatte ändern.
+
+## Fix
+Einführung der Hilfsfunktion `_get_fresh_token(settings)` in `backend/update.py`, die das Token bei jedem kritischen Vorgang (Check, Report, Update) frisch von der Festplatte oder aus der Environment lädt.
+
+## Verifizierung
+- Update auf v0.3.3 nutzt nun erfolgreich das Token, auch wenn der Service seit dem Enrollment nicht neu gestartet wurde.