planning: update-service v1 epic and stories
This commit is contained in:
@ -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_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_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 | 🎨 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
|
## Legende
|
||||||
|
|||||||
45
project-management/requirements/epics/EPIC_000010.md
Normal file
45
project-management/requirements/epics/EPIC_000010.md
Normal file
@ -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
|
||||||
17
project-management/requirements/stories/US_000034.md
Normal file
17
project-management/requirements/stories/US_000034.md
Normal file
@ -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)
|
||||||
22
project-management/requirements/stories/US_000035.md
Normal file
22
project-management/requirements/stories/US_000035.md
Normal file
@ -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)
|
||||||
Reference in New Issue
Block a user