Apps & Plattformen

Aktueller Stand

Diese Seite beschreibt den heute verifizierten Plattformstand fuer den ersten Lieferstand. Runtime-proven ist aktuell nur ein lokaler Android-plus-Cloud-Pfad im Workspace.

Achtung

Nur Android ist im aktuellen Workspace als v1-Geraetepfad verifiziert. iOS, Windows, macOS und Linux bleiben fuer den ersten Lieferstand Zielarchitektur, solange sie nicht ausdruecklich als aktueller Runtime-Stand belegt sind.

Plattformstatus

Plattform	Aktueller Workspace-Stand	Verifizierter Pfad
Android	runtime-proven	superheld-android gegen lokales superheld-cloud auf einem per USB verbundenen Tablet
iOS	Zielarchitektur	kein runtime-proven v1-Pfad im Workspace
Windows	Zielarchitektur	kein runtime-proven v1-Pfad im Workspace
macOS	Zielarchitektur	kein runtime-proven v1-Pfad im Workspace
Linux	Zielarchitektur	kein runtime-proven v1-Pfad im Workspace

Android im aktuellen Workspace

Der aktuell verifizierte Android-MVP deckt diese Pfade ab:

• lokale Buildbarkeit aus superheld-android
• Konfiguration von Backend-URL, API-Token und tenant-gebundener tenant_id
• stabile lokale device_id plus RSA-Schluesselmaterial im Android Keystore
• signierte Device-Registrierung ueber POST /devices
• signierte Demo-Event-Submission ueber POST /events
• tenant-scoped GET /status
• tenant-scoped GET /alerts
• tenant-scoped GET /incidents plus Detailread fuer den letzten sichtbaren Incident ueber GET /incidents/{id}
• Incident-Aktionen auf dem Issues-Tab: „Start review” und „Mark handled” ueber PATCH /incidents/{id} mit incidents:write; erledigte Incidents fallen aus der DAU-Zaehlung heraus
• tenant-scoped GET /jobs plus Detailread fuer den letzten sichtbaren Job ueber GET /jobs/{id}
• Trace-Reads fuer den letzten sichtbaren Job ueber GET /traces/{id} und GET /traces/{id}/steps
• sichtbare Fehlerpfade fuer Konfiguration, Auth, Scope, Tenant und Netzwerk
• kleine verifizierte Telemetrie-Slices fuer app_launch, status_refresh, alert_read, device_register, event_submit, incident_read und job_read
• lokale Persistierung des letzten erfolgreichen Home-Snapshots: beim naechsten App-Start wird der zuletzt bekannte Schutzstatus sofort angezeigt statt bei einem leeren Wartezustand zu beginnen; der Cache wird bei Konfigurations-Resets geleert
• resiliente Bottom-Navigation: alle vier Tabs (Home, Warnings, Issues, Settings) sind im taeglichen Betrieb stabil sichtbar (Commit 158c53c); verschwindet das Ziel eines sichtbaren Tabs (z.B. Incident wird waehrend der Ansicht erledigt), faellt die Navigation sauber auf Home zurueck und die sichtbare Screen-Auswahl bleibt konsistent; Navigation zwischen Help/Settings und Issue-Tabs bleibt stabil ohne unerwartete State-Resets. Die Tablet-Navigation-Rail arbeitet rekursionsfrei auf realer Tablet-Hardware (Commits 1fbb4d7, cdb087e, 158c53c)
• kontextbezogener Home-CTA: bei fehlender Einrichtung zeigt der Home-Screen Setup-Wording; der Home-Screen zeigt keine separate Settings-/Hilfe-Karte und Setup ist nur ueber die Primaeraaktion oder den Tab „Settings” erreichbar (Commit b4a9e89, bb36290)
• Account-Sign-in/Create-Account-Pfad im Settings-Bereich: nutzt POST /account/register und POST /account/login, speichert die Session und kehrt zur Home-Oberflaeche zurueck; primaerer DAU-Einrichtungsweg, manuelles Token-Minting bleibt als Operator-Pfad (Commit 0371231)
• Settings-Hub rendert vier eigene Unterseiten mit eigenem Header: Connection setup, Support-requested help, Guided checks und Support details. Token-/Trace-/Backend-Diagnostik nur nach explizitem Drill-down in Support details (Commit 8a68e26)
• Home zeigt nur den hoechstprioren Fall als einzelne Karte — Warning und Serious Issue werden nicht mehr gleichzeitig angezeigt. Warning- und Issues-Tabs haben eigene selbststaendige Karten. Gespeicherte Account-Sessions bleiben im Settings-Hub eingeklappt, bis der Nutzer sie explizit oeffnet (Commit 187457f)
• Settings/Help trennt Support-Zugang sauber vom normalen Endnutzer-Setup: Service-Adresse, Familiencode und Account-Sign-in bleiben im normalen Connection-setup-Pfad. Der Support-Access-Code und die manuelle Geraeteregistrierung (Register this phone) liegen nur noch unter Guided checks (support-angeforderte Aktionen). Der DAU-Setup-Pfad ist damit unabhaengig von Support-spezifischen Eingaben (Commit 4e34fa9)
• GET /alerts und GET /incidents liefern innerhalb der sichtbaren Seite die neuesten Eintraege zuerst (newest-first), sodass die Android-DAU-Home-Flaeche den aktuellsten Warning- oder Issue-Eintrag oben sieht (Cloud-Commit 56d4285)
• Home-Metrik-Karten bieten jetzt direkte Aktionen: Tippen auf eine Metrik-Karte navigiert zur zugehoerigen Detailansicht (z.B. Warnungen-Karte oeffnet Warnings-Tab, Issues-Karte oeffnet Issues-Tab). DAU-Nutzer haben damit neben dem primaeren CTA einen zusaetzlichen Einstiegspunkt (Commit 2ce068b)

Verifizierter Install- und Testpfad

Der heute belegte End-to-End-Pfad fuer den ersten Lieferstand ist:

1. superheld-cloud lokal im Secure-Mux-Default auf 127.0.0.1:8080 starten
2. DAU-Pfad: kein manuelles Token-Minting noetig; Account-Sign-in erfolgt in der App (Schritt 5)
3. Operator-Pfad (alternativ): tenant-gebundenes App-Token ueber POST /tokens minten
4. USB-Tablet per adb devices pruefen und adb reverse tcp:8080 tcp:8080 setzen
5. Android-App mit http://127.0.0.1:8080 als Backend-URL installieren
6. auf dem Tablet: DAU-Pfad → Account erstellen oder anmelden; Operator-Pfad → Register Device, Refresh Status, Send Demo Event und erneuten Refresh ausfuehren

Der bevorzugte verifizierte Endpoint fuer reale USB-Geraete ist http://127.0.0.1:8080. 10.0.2.2:8080 bleibt ein Emulatorpfad und ist in diesem Workspace derzeit nicht als realer Lauf belegt.

Fuer Details:

• Installation
• Integrator-Quickstart
• Lokales Android-Cloud-Ops-Runbook

Was derzeit nicht als Ist-Stand belegt ist

Die folgenden Aussagen duerfen aktuell nicht als ausgelieferter Runtime-Stand gelesen werden:

• Distribution ueber Play Store oder App Store
• ein verifizierter Emulator-Pfad; lokal fehlen derzeit emulator-Binary und system-images
• iOS-, Windows-, macOS- oder Linux-Apps als aktueller v1-Lieferpfad
• ein Web-Dashboard als verifizierter Nutzer- oder Operatorpfad
• gehostete Mehrplattform-Produktumgebungen

Zielarchitektur nach dem ersten Lieferstand

Die Architektur- und Spezifikationsdokumente beschreiben teils breitere Plattformziele. Fuer den ersten Lieferstand gilt jedoch:

• Android ist die einzige verpflichtende Geraeteplattform.
• Cloud-Backend ist Teil des Lieferstands.
• Weitere Plattformen bleiben Planungs- oder Zielarchitektur, bis Code, Tests und reale Laufpruefungen sie belegen.

Wenn eine andere Seite Plattformfaehigkeiten detaillierter beschreibt, ist das nur dann als aktueller Workspace-Stand zu lesen, wenn die Passage den verifizierten Runtime-Pfad ausdruecklich nennt.