# Roadmap — Web-UI für Ansible-TUI (Minimal-Profil)

## Überblick
- Ziel: Bereitstellung einer schlanken Web-UI, die Ansible-Playbooks per CLI startet.
- Authentifizierung erfolgt ausschließlich via extern gepflegter .htpasswd.
- SSH-Keys werden nur abgelegt und referenziert; Berechtigungen bleiben bei Ops.
- Keine Reverse-Proxy/TLS-Komponente im MVP; Service lauscht direkt auf Port 8000.
- Hochgeladene Artefakte: ZIP/TAR.
- Geplante Erweiterung: Automatisches Host-Onboarding (Strict Ops-First Policy) nach MVP-Release, abgestimmt mit [`webapp/entwicklung/architektur.md`](webapp/entwicklung/architektur.md:1) und [`webapp/entwicklung/api_endpoints.md`](webapp/entwicklung/api_endpoints.md:1).

## Phase 0 – Vorbereitung (Woche 1)
- Container-Basisimage finalisieren, Port 8000 exponieren.
- Ordnerstruktur für Uploads, temporäre Runs und SSH-Key-Ablage anlegen.
- Integration der Webserver-Basic-Auth (Übernahme REMOTE_USER, Fehlermeldungen).
- Dokumentation für Ops zur Pflege der .htpasswd erstellen.

## Phase 1 – Implementierung Kernfunktionen (Woche 2–3)
- Datei-Uploads (ZIP/TAR) inkl. Validierung implementieren.
- Playbook-Metadaten persistieren laut [`schema.sql`](webapp/entwicklung/schema.sql:1).
- CLI-Executor: Wrapper für ansible-playbook inkl. Parameteraufbereitung.
- Run-Verwaltung (Status, Logpfade) bauen.
- Read-only-API zur SSH-Key-Liste implementieren.
- API-Endpunkte gemäß [`api_endpoints.md`](webapp/entwicklung/api_endpoints.md:1) fertigstellen.

## Phase 2 – Tests & Härtung (Woche 4)
- Funktionale Tests für Upload, Run-Start, Statuspolling.
- CLI-Aufruf unter verschiedenen Inventaren/Variablen validieren.
- Security-Checks: Keine Speicherung sensitiver Daten, Log-Redaktion.
- Belastungstest der Upload/Polling-Flows (einfacher Load-Test).
- Container-Image Review (kein TLS, nur HTTP).

## Phase 3 – Release & Ops Handover (Woche 5)
- Build-/Release-Pipeline konfigurieren (Container Registry).
- Deployment-Checkliste erstellen (Port 8000, externe TLS-Schicht durch Ops).
- Monitoring-Anbindung (Basis: Health Endpoint, Log-Verfügbarkeit).
- Go-Live-Freigabe und Übergabe an Ops inkl. Betriebsdokumentation.

## Phase 4 – Automatisches Host-Onboarding (Woche 6–9)
- Architektur- und Security-Review abschließen; Spezifikation finalisieren (Strict Ops-First Policy, siehe [`webapp/entwicklung/architektur.md`](webapp/entwicklung/architektur.md:1)).
- Datenbankmigrationen und Service-Layer implementieren (Hosts, Onboard-Jobs, Key-Metadaten) gemäß [`webapp/entwicklung/schema.sql`](webapp/entwicklung/schema.sql:1).
- Backend: Onboarding-Service & Job-Runner (Key-Erzeugung, Fingerprint-Prüfung, sudo-Tasks) plus API-Endpunkte & Rate-Limits laut [`webapp/entwicklung/api_endpoints.md`](webapp/entwicklung/api_endpoints.md:1).
- UI/UX: Onboarding-Formular, Status-Detailansicht, Ops-Approval-Dashboard inkl. Log-Viewer.
- QA & Security: Integrationstests, Sudo-/SSH-Härtung, Pen-Test light, Memory-Handling-Checks (keine Persistenz von Passwort/Secret).
- Ops Enablement: Prozesse für known_hosts-Sync, Runbooks, Alerting, Eskalationspfade; Schulung der Ops-Gruppe.
- Staging-Dryrun mit realistischem Host; Post-Mortem + Go/No-Go Entscheidung.
- Abhängigkeiten: Abschluss Phase 1–3, verfügbare Ops-Ressourcen für Fingerprint-Freigaben und Sicherheitstests.

## Post-MVP Backlog
- Integrierter Reverse-Proxy/TLS-Termination.
- Erweiterter Credential-Store oder Secrets-Management.
- Rollenbasierte Zugriffssteuerung jenseits .htpasswd.
- UI-Verbesserungen für Run-Output (Streaming, Filter).
- Automatisierte Key-Rotation inklusive Berechtigungsupdates.
- Self-Service Ops Workflow für Re-Onboarding/Key-Rotation (Erweiterung der Onboarding-Plattform).

## Offene Fragen
- Keine; Onboarding-Policy (Strict Ops-First) und Sicherheitsvorgaben abgestimmt.