docs: start update client stories

project-management/PROJECT_STATUS.md

@@ -10,9 +10,9 @@ Sicheres, remote steuerbares System zum Sperren/Entsperren lokaler Nutzerkonten.
 ✅ Stabilization
 
 ## Aktueller Fokus
-1. Dokumentierter Ist-Zustand der Module.
-2. Pflege der Anforderungen bei neuen Features.
-3. Doku und Ops-Automation aktuell halten.
+1. Client-Update-Mechanik planen (EPIC_000008).
+2. Dokumentierter Ist-Zustand der Module.
+3. Pflege der Anforderungen bei neuen Features.
 
 ## Projekt-Tagebuch (Kurz, optional)
 | Datum | Typ | Beschreibung |

project-management/requirements/stories/US_000026.md

@@ -3,7 +3,7 @@ By: Codex (GPT-5)
 
 # US_000026: Client bezieht Updates (Pull)
 
-Status: Draft
+Status: In Progress
 
 Als Betreiber moechte ich, dass der Client Updates per Pull von einem Update-Service bezieht, damit Deployments ohne SSH moeglich sind.
 

project-management/requirements/stories/US_000027.md

@@ -3,7 +3,7 @@ By: Codex (GPT-5)
 
 # US_000027: Client verifiziert und wendet Updates an
 
-Status: Draft
+Status: In Progress
 
 Als Betreiber moechte ich, dass der Client Updates verifiziert und sicher anwendet, damit fehlerhafte Pakete keine Ausfaelle verursachen.
 

project-management/requirements/stories/US_000028.md

@@ -3,7 +3,7 @@ By: Codex (GPT-5)
 
 # US_000028: Client meldet Update-Status
 
-Status: Draft
+Status: In Progress
 
 Als Betreiber moechte ich Statusmeldungen vom Client erhalten, damit Update-Ergebnisse nachvollziehbar sind.
 

project-management/requirements/tasks/TASK_000027.md

@@ -0,0 +1,20 @@
+ID: TASK_000027 | Version: 0.1.0 | Status: Draft
+By: Codex (GPT-5)
+
+# TASK_000027: Update endpoint config
+
+## Outcome
+Client kennt Update-Endpoint, Auth und Polling-Konfiguration.
+
+## Story-Bezug
+US_000026
+
+## Beschreibung
+- Konfigurationskeys definieren (z.B. `SKD_UPDATE_URL`, `SKD_UPDATE_TOKEN`, `SKD_UPDATE_INTERVAL`).
+- Default auf `https://update.wlkns.org` festlegen.
+- Lesen der Config in Settings/ENV beschreiben.
+
+## Definition of Done (DoD)
+- Konfigurations-Keys dokumentiert.
+- Default-URL ist festgelegt.
+- Client kann Update-Endpoint ueber Konfiguration aufloesen.

project-management/requirements/tasks/TASK_000028.md

@@ -0,0 +1,21 @@
+ID: TASK_000028 | Version: 0.1.0 | Status: Draft
+By: Codex (GPT-5)
+
+# TASK_000028: Verify and apply update
+
+## Outcome
+Update-Artefakt wird verifiziert und atomar angewendet.
+
+## Story-Bezug
+US_000027
+
+## Beschreibung
+- JSON-Manifest lesen (Version, `artifact_url`, `sha256`, optional `sig_url`).
+- `tar.gz` herunterladen und SHA256 pruefen.
+- Update atomar anwenden (staging, swap, rollback).
+- Fehlerfall dokumentieren (Rollback, Status).
+
+## Definition of Done (DoD)
+- Verifikation (Checksum/Signatur) ist beschrieben.
+- Atomare Anwendung und Rollback-Strategie sind definiert.
+- Fehlerbilder sind erfasst.

project-management/requirements/tasks/TASK_000029.md

@@ -0,0 +1,20 @@
+ID: TASK_000029 | Version: 0.1.0 | Status: Draft
+By: Codex (GPT-5)
+
+# TASK_000029: Report update status
+
+## Outcome
+Client meldet Update-Status mit Version und Fehlerbild.
+
+## Story-Bezug
+US_000028
+
+## Beschreibung
+- Status-Schema definieren (Version, Ergebnis, Fehler, Zeitpunkt).
+- Transportweg festlegen (z.B. HTTP POST oder Log-Export).
+- Erfolg/Fehler konsistent dokumentieren.
+
+## Definition of Done (DoD)
+- Status-Schema dokumentiert.
+- Uebertragungspfad beschrieben.
+- Erfolg/Fehler werden eindeutig gemeldet.