Pack-Lebenszyklus-Status

Jeder Pack in Levy Swap ist immer in genau einem Lebenszyklusstatus. Die Zustandsmaschine wird serverseitig durchgesetzt – illegale Übergänge werden auf Datenbankebene blockiert, nicht nur in der UI, sodass ein fehlerhafter Client die Historie nicht korrumpieren kann.

Die Zustandsmaschine

ordered → received → deployed → in_use → returned → recycled
                       ↓           ↑
                    swap_in     swap_out
                       ↓           ↑
                   in-station ← → charging → charged
                                              ↓
                                          maintenance

Primäre Lebenszyklusstatus

Stations-/Ladestatus

Ein Pack kann zwischen charging, charged und maintenance in einer Station frei wechseln. Es kann nur aus charged heraus wieder deployed werden (kein Pack, der noch lädt oder als Wartung markiert ist, kann installiert werden).

Legale Übergänge

Der CHECK-Trigger auf battery_packs erlaubt nur diese Übergänge:

• ordered → received
• received → deployed (Erstinstallation)
• received → charging oder received → charged (vorher in Station laden)
• deployed → returned (ausbauen)
• returned → charging oder returned → maintenance (nach Tausch)
• charging → charged
• charged → deployed (auf Fahrzeug installieren)
• maintenance → charging, maintenance → returned, maintenance → recycled
• returned → recycled (Zwangsausmusterung)
• charged → maintenance (Defekt nach Aufladen festgestellt)

Endzustand: recycled. Sobald in recycled, sind keine weiteren Übergänge erlaubt; die Zeile bleibt für Garantie-/Audit-Nachvollziehbarkeit erhalten.

Das Audit-Log

Jeder Statuswechsel schreibt eine Zeile in battery_pack_history. Der Trigger erfasst:

• from_status und to_status
• actor_type – system, team_member oder juicer
• actor_id – Benutzer-UUID
• swap_event_id – wenn Teil eines Tauschs
• station_id – wenn Teil einer Slot-Bewegung
• Zeitstempel

Das Log ist append-only und wird für immer aufbewahrt. Es macht Garantieansprüche möglich – wenn Sie einen Defekt bei OKAI oder Segway melden, enthält der Export die vollständige Statushistorie des Packs mit Zeitstempeln.

Was "in_use" praktisch bedeutet

in_use und deployed liegen sehr nah beieinander. Beide bedeuten, dass der Pack auf einem Fahrzeug installiert ist. Der Unterschied ist an zwei Stellen wichtig:

1. Konkurrenzprüfung beim Tausch-Ausbau – wir lesen das aktuelle in_use-Flag des Packs, um Doppeltauschen zu verhindern. Scannen zwei Techniker denselben Pack aus zwei Fahrzeugen, erhält einer eine Ablehnung.
2. Juicer-Berechtigung – die Prämien-Engine erzeugt keine Prämie für ein Fahrzeug, dessen installierter Pack als maintenance markiert ist. Die Prüfung erfolgt auf Pack-Ebene, nicht Fahrzeug-Ebene.

In den meisten Dashboard-Ansichten können Sie beide als gleichwertig betrachten.

Die Historie lesen

Auf jeder Pack-Detailseite zeigt das Verlauf-Tab das vollständige Übergangsprotokoll. Sie sehen:

• Initiales Mint-Ereignis (ordered)
• Empfangsscan (received)
• Jede Installation/Deinstallation (deployed/returned)
• Jeden Ladezyklus (charging/charged)
• Wartungs- oder Garantieereignisse
• Endgültiges Recycling-Ereignis

Bei vielfach getauschten Packs (100+ Tausche) paginiert die Historie monatsweise.

Häufige statusbezogene Probleme

• "Pack is in use" beim Tausch – der gescannte Pack ist bereits auf einem anderen Fahrzeug installiert. Überprüfen Sie physisch, welchen Pack Sie in der Hand haben.
• Pack steckt wochenlang in received – der Pack wurde gemintet und empfangen, aber nie installiert. Entweder auf ein Fahrzeug installieren oder in einen Stationsslot legen (received → charging).
• Pack, den Sie erwarten, fehlt im Stationsinventar – prüfen Sie das Audit-Log; er könnte zu maintenance gewechselt sein oder zu returned, wenn jemand ihn versehentlich ausgescannt hat.

Siehe Fehlerbehebung für die vollständige Liste.