diff --git a/CHANGELOG.md b/CHANGELOG.md index bbc2c98..567dbec 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -47,6 +47,7 @@ By: Codex (GPT-5) | 30.12.2025 | 🎨 UI | ID: TASK_000037 OIDC-Button neben Anmelden und nur aktiv bei erreichbarem Server. By: Codex (GPT-5) | | 30.12.2025 | 🎨 UI | ID: TASK_000038 Logo im Header und Favicon eingebunden. By: Codex (GPT-5) | | 30.12.2025 | 🎨 UI | ID: TASK_000039 Login-Text reduziert, Buttons symmetrisch, Panels/Metrics harmonisiert. By: Codex (GPT-5) | +| 30.12.2025 | 🏗️ Planning | ID: EPIC_000010/US_000034/US_000035 Update-Service v1 Migration dokumentiert. By: Codex (GPT-5) | --- ## Legende diff --git a/project-management/requirements/epics/EPIC_000010.md b/project-management/requirements/epics/EPIC_000010.md new file mode 100644 index 0000000..5db910f --- /dev/null +++ b/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 diff --git a/project-management/requirements/stories/US_000034.md b/project-management/requirements/stories/US_000034.md new file mode 100644 index 0000000..ec4373f --- /dev/null +++ b/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) diff --git a/project-management/requirements/stories/US_000035.md b/project-management/requirements/stories/US_000035.md new file mode 100644 index 0000000..9ad8fdb --- /dev/null +++ b/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)