planning: update-service v1 epic and stories

project-management/requirements/epics/EPIC_000010.md

@@ -0,0 +1,45 @@
+ID: EPIC_000010 | Version: 0.1.5 | Status: Draft
+By: Codex (GPT-5)
+
+# EPIC_000010: Update-Service v1 Migration (Major Release)
+
+## Beschreibung
+Migration des Update-Clients auf den neuen v1 Update-Service mit verpflichtender Authentifizierung
+und Enrollment-Flow fuer Langzeit-Tokens. Diese Umstellung ist ein Major Release.
+
+## Ziel / Business Value
+Sicheres, standardisiertes Update-Management mit verpflichtender Auth und nachvollziehbarem Status-Reporting.
+
+## Mission Statement
+Stelle sicher, dass der Client die v1 Endpunkte nutzen kann, inkl. Enrollment und
+neuem Status-Schema.
+
+## Business Value & Metriken
+- Security: Auth ist obligatorisch fuer alle Requests.
+- Erfolgsmetrik: 100% der Clients koennen per v1 manifest/artifact/status arbeiten.
+
+## In-Scope (Kiddo Team)
+- Enrollment-Flow fuer Langzeit-Token (mit Pre-Shared Token).
+- Update-Client auf v1 Endpunkte umstellen.
+- Status-Payload auf v1 Schema umstellen.
+- Migration-Notiz/Docs fuer Client-Dev.
+
+## Out-of-Scope
+- Betrieb/Hosting des Update-Services.
+- Ausgabe/Verwaltung von Pre-Shared Tokens auf Server-Seite.
+
+## High-Level Akzeptanzkriterien
+- Auth ist Pflicht (Bearer Token) fuer Manifest, Artifact und Status.
+- Enrollment liefert Langzeit-Token, der lokal gespeichert wird.
+- v1 Endpunkte werden genutzt:
+  - GET /v1/projects/{project_id}/manifest
+  - GET /v1/projects/{project_id}/releases/{version}/artifact
+  - POST /v1/projects/{project_id}/status
+
+## Technische Constraints & Risiken
+- Major Release: Rollout-Strategie und Backward Compatibility klaeren.
+- Token-Handling und sichere lokale Speicherung.
+
+## Zugeordnete User Stories
+- US_000034: Enrollment fuer Langzeit-Token
+- US_000035: v1 Update-Endpoints und Status-Schema

project-management/requirements/stories/US_000034.md

@@ -0,0 +1,17 @@
+ID: US_000034 | Version: 0.1.5 | Status: Draft
+By: Codex (GPT-5)
+
+# US_000034: Enrollment fuer Langzeit-Token
+
+Als Betreiber moechte ich, dass der Client einmalig einen Langzeit-Token per Enrollment bezieht,
+damit alle Update-Requests verpflichtend authentifiziert sind.
+
+## Akzeptanzkriterien
+- Given ein Pre-Shared Token (von Admin bereitgestellt)
+- When der Client einen Enrollment-Request stellt
+- Then erhaelt er einen Langzeit-Token
+- And der Client speichert den Token lokal und nutzt ihn fuer alle Update-Requests
+- And Enrollment-Endpoint/Details werden per Spezifikation festgelegt
+
+## Task-Platzhalter
+- TASK_000040: Enrollment-Flow implementieren (Details bei Story-Start)

project-management/requirements/stories/US_000035.md

@@ -0,0 +1,22 @@
+ID: US_000035 | Version: 0.1.5 | Status: Draft
+By: Codex (GPT-5)
+
+# US_000035: v1 Update-Endpoints und Status-Schema
+
+Als Betreiber moechte ich, dass der Client die neuen v1 Endpunkte fuer Manifest, Artefakt-Download
+und Status-Reporting nutzt, damit der Update-Service konsistent und sicher angesprochen wird.
+
+## Akzeptanzkriterien
+- Given ein konfiguriertes project_id und Bearer Token
+- When der Client Updates prueft
+- Then nutzt er GET /v1/projects/{project_id}/manifest
+- And das Manifest enthaelt version, artifact_url, sha256, optional sig_url
+- When der Client ein Artefakt herunterlaedt
+- Then nutzt er GET /v1/projects/{project_id}/releases/{version}/artifact
+- When der Client Status meldet
+- Then nutzt er POST /v1/projects/{project_id}/status
+- And die Payload enthaelt project_id, version (SemVer), status (definierte Werte),
+  optional client_id, duration_ms, error_code
+
+## Task-Platzhalter
+- TASK_000041: v1 Endpunkte im Update-Client umstellen (Details bei Story-Start)