Zum Inhalt

Produkt und Laufzeit

Basisreferenz

Dieses Kapitel beschreibt das etablierte Produkt- und Laufzeitmodell. Die aktuelle Oberfläche und die native Companion-Grenze stehen auf der letzten Architekturseite.

Produktbild

Wofür Steady gedacht ist

Steady soll Veränderungen sichtbar machen, ohne aus dem Alltag einen Pflichtfragebogen zu machen. Alles ist freiwillig. Nicht ausgefüllte Werte bleiben unbekannt und werden nicht als Null, Fehler oder nicht erledigte Gewohnheit interpretiert.

Hauptbereiche der Oberfläche

flowchart TD
    T[Heute] --> J[Journal]
    T --> R[Recovery]
    T --> P[Muster]
    T --> E[Explorer]
    T --> X[Toolbox / Mehr]

    J:::read -->|chronologischer Rückblick| U[Gespeicherte Daten]
    R:::read -->|Counter, Urges, Trigger| U
    P:::read -->|Zusammenhänge| U
    E:::read -->|Messreihen| U

    classDef read fill:#eaf6f1,stroke:#5b9b82,color:#173d31
Bereich Leitfrage Rolle
Heute Was möchte ich heute festhalten? Eingabe und Autosave
Journal Was ist wann passiert? Chronologischer Rückblick
Recovery Wie entwickelt sich mein Veränderungsbereich? Counter, Urges, Trigger, Strategien
Muster Was bewegt sich möglicherweise gemeinsam? Lebensrad, Personen, Sport, Korrelationen
Explorer Wie entwickelt sich ein einzelner Messwert? Frei konfigurierbare Graphen
Toolbox / Mehr Was brauche ich zusätzlich? Aufgaben, Meilensteine, Export, Einstellungen

Produktgrenzen

  • keine Diagnose und kein Medizinprodukt
  • keine automatische Rückfallentscheidung
  • kein verpflichtendes Konto
  • keine Telemetrie und kein Steady-Backend
  • Korrelationen werden nicht als Ursache bezeichnet
  • der Companion besitzt keinen Schreibzugriff auf Trackingdaten

Quellen im Repository

Systemarchitektur

Laufzeitmodell

Steady ist eine React-Anwendung, wird mit Vite gebaut und über Capacitor als Android-App verpackt. Der Browser dient als Entwicklungs- und Testumgebung; Android ist das eigentliche Produktziel.

Eine Build-Fähigkeitsgrenze in src/product-variant.js erzeugt bei VITE_PRODUCT_VARIANT=general-audience eine allgemeine Produktvariante. Sie entfernt die eingebauten Profile Alkohol und Pornografie/zwanghaftes Sexualverhalten samt Countern und 12-Schritte-Ressourcen aus der effektiven Laufzeitkonfiguration. Inventar, Lieblingstexte und Zwölf Schritte werden auch aus General-Audience-Navigation und Feature-Chunks ausgeschlossen. Passende gespeicherte Datensätze werden in dieser Variante nicht an die Oberfläche weitergereicht, aber auch nicht gelöscht. Das Schema bleibt zwischen beiden Varianten kompatibel.

Die Variantengrenze gilt auch für die Initialkonfiguration: general-audience verwendet den expliziten kanonischen Satz aus src/initial-user-config.js mit sechs allgemeinen Bereichen und 21 aktiven Feldern. Die Recovery-Variante verwendet einen eigenen kanonischen Satz mit sieben Bereichen und 25 aktiven Feldern. Browser und Android-SQLite erhalten jeweils denselben variantenspezifischen Seed. Eine initialConfigurationId-Kennung verhindert, dass die Kompatibilitätsnormalisierung den sauberen Recovery-Start wieder mit fehlenden v5-Feldern auffüllt; tatsächlich vorhandene historische Definitionen bleiben weiter erhalten.

Auch Beispieldaten folgen dieser Grenze. src/data/demo-data.js enthält nur den neutralen General-Audience-Verlauf. src/data/recovery-demo-data.js ergänzt für Recovery Suchtdruck, Trigger, drangfreie Check-ins, Rückfälle und atomar verknüpfte Resets. Beide Varianten besitzen einen 90-Tage- und einen 1.095-Tage-Verlauf. Jeder Datensatz trägt source: "demo", damit die Entfernung keine echten Daten oder Companion-Erinnerungen berührt.

flowchart TB
    UI[React Views und Dialoge]
    APP[App-Zustand und Anwendungslogik]
    SVC[Services: Tracking, Export, Companion]
    DB[db.js – gemeinsame Datenabstraktion]
    IDX[(IndexedDB<br/>Browser/Test)]
    NATIVE[native-database.js]
    CAP[Capacitor-Plugin]
    SQL[(verschlüsselte SQLite-Datenbank)]

    UI --> APP --> SVC --> DB
    DB -->|Browser| IDX
    DB -->|Android| NATIVE --> CAP --> SQL

Schichten und Verantwortlichkeiten

Schicht Verantwortung Beispiele
Views Darstellung und Interaktion TodayView, RecoveryView, AnalysisViews
App-Orchestrierung Navigation, Zustand, Dialoge, Datenübergabe App.jsx
Services atomare Fachoperationen tracking-service.js, Export-Service
Datenabstraktion Lesen, Schreiben, Migration, Browser-/Android-Umschaltung db.js
Native Grenze SQLite, Keystore, Datenschutz, lokale KI Capacitor-Plugins

Warum ein generischer Record-Store?

Die native SQLite-Datenbank verwendet logisch getrennte Stores, speichert die eigentlichen Objekte aber als verschlüsselte JSON-Payloads. Das passt zur konfigurierbaren Feldstruktur: Neue Felder erfordern nicht automatisch eine neue SQL-Spalte.

Atomare Operationen

Ein Urge mit Rückfall kann gleichzeitig ein Ereignis und mehrere Counter-Resets erzeugen. Diese Änderungen werden mit applyBatch in einer Transaktion geschrieben. Dadurch gibt es keinen Zwischenzustand, in dem der Rückfall gespeichert, der Counter aber noch nicht zurückgesetzt wurde.

Die nativen Managed-Device-Tests erzwingen Fehler nach bereits begonnenen Schreibvorgängen für putMany, Store-Ersetzung, applyBatch, vollständigen Store-Import und Klartextmigration. Danach müssen alle ursprünglichen Datensätze unverändert vorhanden sein. Eine manipulierte Daten-Key-Hülle oder ein ersetzter Android-Keystore-Schlüssel wird abgelehnt; Steady überschreibt dabei weder die vorhandene Hülle noch setzt es die Datenbank automatisch zurück.

sequenceDiagram
    participant UI as Urge-Dialog
    participant S as tracking-service.js
    participant DB as db.js / applyBatch
    participant Store as events + resets

    UI->>S: payload speichern
    S->>S: Ereignis und Reset-Datensätze vorbereiten
    S->>DB: eine Batch-Operation
    DB->>Store: alles committen
    Store-->>UI: Erfolg oder vollständiger Fehler

Quellen