Stand · 22. Oktober 2026

Die Software kommt
in die Hosentasche.

TimeFlow wächst derzeit auf zwei sauber getrennten, eng verzahnten Wegen: Eine produktnahe Flutter-App mit denselben Backend-Verträgen wie die Web-App — und eine belastbare Playwright-Strecke, die Zusammenarbeit im Browser nachweist.

2 ArbeitssträngeFlutter-App & Playwright, getrennt entwickelt und gemeinsam geführt.

3 Rechnungs-SchnitteDaten, Detaildaten und sichtbare Liste sind bereits in der App angekommen.

0 Live-AbkürzungenLokale Gegenproben zuerst; der begleitete Lauf auf #44 ist ein eigener Qualitätsnachweis.

Arbeitsstand dokumentiert, versioniert und pro Schnitt unabhängig geprüft.

Die Landkarte

Ein Ziel.
Zwei Beweisketten.

Die App beweist, dass echte TimeFlow-Daten sicher und verständlich mobil nutzbar werden. Die Teststrecke beweist, dass zentrale Web-Abläufe reproduzierbar bleiben — lokal zuerst, später begleitet auf der eigenen Preview-Umgebung.

Track 01 · Flutter

Von der Sitzung bis zur Rechnung

Die Mobile-App arbeitet gegen dieselben API-Endpunkte wie die Web-App. Kein Demo-Datenpfad, keine parallele Fachlogik.

Sichere Anmeldung & SitzungsführungJWT-Ablage, kontrollierte Erneuerung, 401-Regeln und fail-closed Fehlerpfade.

umgesetzt

Faktura-ÜberblickVier Nettokennzahlen aus dem echten Dashboard-Vertrag, rollenabhängiges Startziel „Übersicht“.

AP 34

Offene Rechnungen · 35A–35CDatenmodell, Detail-Datenbasis, Dashboard-Einstieg und eine lesende, nicht antippbare Liste.

f23905a

Rechnungsdetail · 35DAntippbare Zeile, geschützte Detailroute, Detailseite sowie Menge- und USt-Formatierung.

als Nächstes

Track 02 · Playwright

Zusammenarbeit wird testbar

Die E2E-Strecke modelliert einen echten Admin- und Mitarbeiterkontext — mit strikter Geheimnisgrenze und ohne sich auf historische Matrixdaten zu stützen.

Zwei-Nutzer-BootstrapAdmin A und Mitarbeiter B, getrennte Browserzustände, explizite Orchestrierung.

158132d

Profilbild von Mitarbeiter BAblage, Wiederherstellung im frischen Kontext und Byte-Nachweis gegen das lokale Web-Double.

f236742

Live-Team-SpezifikationPräsenz von B in A ohne Reload, mit klaren Grenzen für Hub-, Sitzungs- und Instanzrisiken.

6f4e410

Live-Team lokal umsetzenVerträge, Web-Double und Gegenproben zuerst; danach ein begleiteter Preview-Lauf als eigener Schritt.

in Arbeit

Nicht nur Oberfläche

Qualität ist
Teil des Produkts.

Jeder fertige Schnitt folgt derselben Logik: belegte Quelle → Spec → rote Gegenprobe → Umsetzung → fokussierte Prüfung → unabhängige Abnahme → sauberer Commit.

⌁

Spec Driven Development

Produktentscheidungen und technische Sicherheitsregeln stehen vor dem Code. Der spätere Stand bleibt nachvollziehbar, nicht nur funktionsfähig.

✓

Fokussierte Gegenproben

Beispiel Flutter 35C: 152 betroffene Tests grün, Analyse ohne Befund, Detailnavigation bewusst ausgeschlossen und getestet.

⌘

Lokale E2E-Beweise

Playwright nutzt Verträge und ein kontrolliertes Web-Double. Die produktive Preview wird erst nach klaren Gates und mit ausdrücklicher Freigabe berührt.

Aktuelle ReferenzenFlutter: feature/flutter-app-next · fff9b37Playwright: feature/playwright-e2e · 6f4e410Kein Merge zwischen den Arbeitssträngen.

Der Weg vor uns

Jetzt wird aus
Breite Tiefe.

Die nächsten Schritte sind bewusst klein geschnitten. So bleibt jeder Fortschritt prüfbar und die App wächst ohne spätere Reparaturwelle.

Nächste produktive Etappen

Flutter 35D spezifizieren und umsetzen
Die Rechnungszeile wird interaktiv, das Detail erhält Route, Zurück-Verhalten und kontrollierte Datenanzeige.
Flutter auf Gerät gegen das eigene Environment prüfen
Login, Dashboard und Rechnungsdaten werden als echter End-to-End-Beleg über die vorhandene API nachvollzogen.
Playwright Live-Team lokal schließen
Admin A sieht den Kontextwechsel von Mitarbeiter B ohne Reload; Verträge sichern Reihenfolge und Geheimnisgrenzen ab.
Begleiteter Lauf auf Preview #44
Erst nach lokalen Gates: mit sauberer Collaboration-Preview, bekannten Ausgangsbedingungen und dokumentierten Befunden.