certain/ios/UEBERGABE.md

Übergabe: iOS-App für Certain

Für den nächsten Agenten. Diese Datei ersetzt die Unterhaltung, in der die App geplant wurde. Sie enthält alles, was du brauchst, ohne sie gelesen zu haben: was entschieden ist, was fertig ist, was als Nächstes dran ist, und was ich über das Backend herausgefunden habe. Lies sie ganz, bevor du anfängst — die Abschnitte „Was das Backend vorgibt" und „Fallen" ersparen dir Tage.

Stand: 21.10.2026, Commit 9edf610. Alles committet und gepusht.

---

1. Worum es geht

Certain ist ein Haushaltsbuch: FastAPI-Backend (backend/) plus React-Weboberfläche (web/), die das Backend mit ausliefert. Dazu kommt eine native iOS-App in ios/, die sich über eine eingegebene Server-Adresse (wie budget.scarriffle.com) an dasselbe Backend hängt.

Ziel: alles, was die Weboberfläche kann. Budget, Buchungen, Konten, Abos, Dashboard, Arbeitsliste, Kategorien, Tags, Einstellungen, Bankabruf und der volle CSV-Import.

Die Rahmenbedingung, die es nicht mehr gibt

Bis zum 21.10.2026 stand hier: es gibt kein Xcode, der Swift-Code wird blind geschrieben und nie übersetzt. Das gilt nicht mehr. Auf dieser Maschine liegt Xcode 27 mit Simulatoren für iOS 26.5 und 27, und ios/project.yml erzeugt das Projekt. Übersetzen, Tests und Starten im Simulator gehen hier direkt:

cd ios && xcodegen generate                       # nach jeder neuen Datei
xcodebuild -project Certain.xcodeproj -scheme Certain \
  -destination 'platform=iOS Simulator,name=iPhone 17 Pro' build   # oder test

Übersetze nach jeder Stufe selbst, statt dem Nutzer Fehler zu hinterlassen. Die kleinen Stufen bleiben trotzdem richtig — nicht wegen der Fehlersuche, sondern damit jede Stufe für sich benutzbar ist.

---

2. Entscheidungen des Nutzers

Alle schon gefallen. Nicht erneut fragen.

Frage	Festgelegt
Backend erweitern	Ja, kleine Ergänzungen — jede einzeln vorlegen, bevor du sie schreibst
CSV-Import	Voll, wie im Web (trotz Abraten; steht deshalb als letzte Stufe)
Zusätzlicher Umfang	Arbeitsliste/Eingang, Kategorien und Tags, Einstellungen, Bankabruf anstossen
Dashboard	Feste iOS-Ansicht, kein Raster
iOS-Mindestversion	iOS 26
Ablieferung	Flache Ordner unter ios/; das Projekt entsteht seit dem 21.10. aus project.yml
Anmeldung	App-Token (im Backend ergänzt, siehe unten)
Erweiterungen	Teilen-Menü für Dateien, Kurzbefehle/Siri
Sprachen	Deutsch und Englisch
iPad	Richtig mitgedacht, zweispaltig
Offline	Zuletzt Geladenes mit „Stand von …"

Der Nutzer will jede Entscheidung selbst treffen. Wenn eine Frage auftaucht, die den Zuschnitt ändert: fragen, nicht annehmen.

---

3. Was das Backend vorgibt

Die Befunde aus einer gründlichen Durchsicht. Sie bestimmen den ganzen Entwurf.

Anmeldung

Die Web-API kennt ausschliesslich ein Sitzungs-Cookie (get_current_user in backend/app/deps.py). Kein Bearer, kein Token im Body. Die Sitzung liegt serverseitig in der Tabelle sessions (kein JWT), hält 30 Tage und verlängert sich nicht.

Anmeldung ist ein Formular, kein JSON: POST /api/auth/login mit application/x-www-form-urlencoded, Feldern username und password (OAuth2PasswordRequestForm). JSON gibt 422.

Zwei-Faktor: Login antwortet {"status": "2fa_required"} und setzt ein Pending-Cookie mit 10 Minuten Laufzeit. Dann POST /api/auth/2fa/verify mit {"code": "...", "recovery": false}. Nach fünf Fehlversuchen ist die Zwischensitzung verbraucht.

Offene Pflichten sperren jeden Endpunkt mit 403 und einem maschinenlesbaren detail: password_change_required oder mfa_setup_required. Erreichbar bleiben nur /health, /version, /auth/me, /auth/logout, /auth/login, /auth/change-password, /auth/2fa.

Alles hängt unter /api

GET /api/version → {"name": "Certain Finance", ...}. Das ist die Serverprüfung. Wichtig: Jeder unbekannte Pfad ausserhalb /api liefert mit Status 200 die Weboberfläche aus — nur /api/version kann einen fremden Server sicher ausschliessen.

Fehlerformat

{"detail": "..."} — aber bei 422 ist detail eine Liste von Pydantic-Meldungen statt einer Zeichenkette. Netzwerk/APIFehler.swift fängt beides ab; wer das übersieht, verliert bei jedem Eingabefehler die Meldung.

Statuscodes: 401 nicht angemeldet, 403 verboten oder Pflicht offen, 404 auch für fremde IDs (bewusst, Mandanten-Isolation), 409 heisst „nachfragen" und lässt sich oft mit trotzdem=true wiederholen, 400/422 ungültig.

Beträge

Alles sind Cent-Ganzzahlen. Nirgends Fliesskomma (einzige Ausnahme: QuickBookingIn.amount). Drei Felder an einer Buchung:

• amount_cents — in der Kontowährung
• amount_eur_cents — beim Speichern eingefrorener EUR-Wert
• amount_base_cents — bei jedem Lesen in die Hauptwährung umgerechnet

Der Client rechnet nichts davon selbst. Kontosalden, Budget-Soll/Ist, Vertrags-Monatswerte, Dashboard-Zahlen kommen alle fertig. Der Client formatiert nur — und rechnet Prozente und „Rest", die es in der API nicht gibt.

Achtung: *_base_cents kann still auf den nativen Wert zurückfallen, wenn kein Wechselkurs vorliegt. Die ohne_kurs-Listen in den Antworten sagen, wann das passiert. Wer sie nicht anzeigt, zeigt stillschweigend falsche Summen.

Zeitstempel — die Falle, die mich Zeit gekostet hat

created_at und Konsorten kommen als 2026-10-20T14:18:15.780705 — ohne Zeitzone, mit sechs Stellen Mikrosekunden. Beide Standard-ISO8601-Leser von Foundation scheitern daran, weil sie eine Zone verlangen. Modelle/Zeitangaben.swift hat deshalb einen dritten Leser. Tagesdaten (date, opening_date) sind dagegen reine "2026-07-14". Zwei getrennte Typen statt einer Decoder-Strategie — das ist Absicht, siehe Kommentar dort.

Zwei Dinge, die fachlich im Frontend sitzen

Die App muss sie nachbauen, das Backend hilft nicht:

1. Was ein Übertrag ist. Entweder type == "transfer" oder die Buchung steht in GET /api/transactions/links. Es gibt zwei Mechanismen nebeneinander: ein Übertrag am Stück (eine Buchung mit to_account_id) und die Verknüpfungs-Schicht TransferLink (zwei getrennte Buchungen, wie die Bank sie liefert; keine davon wird verändert). Das Zusammenfassen beider Beine zu einer Anzeigezeile macht heute nur der Browser (web/src/pages/Transactions.jsx, Suche nach paarZu).
2. Welche Verträge in aus_vertraegen_cents stecken. Das Backend liefert nur die Summe; welche Abos dahinterstehen, ermittelt das Frontend selbst aus /subscriptions nach category_id.

Buchungsliste

GET /api/transactions kennt account_id, category_id, uncategorized, type, date_from, date_to, limit (Standard 5000), offset und seit Ergänzung B auch q, tag_id, subscription_id. Keine wählbare Sortierung — immer Datum absteigend, dann ID absteigend.

Die Weboberfläche lädt weiter alles und filtert im Browser; sie wurde nicht umgestellt, weil sie so funktioniert. Die App soll die Filter benutzen.

Was nicht in die App kommt

• Bankkonten verbinden. Die Bank leitet fest auf {base_url}/bank/rueckkehr zurück, registriert bei Enable Banking. Abrufen, Salden holen und Konten zuordnen läuft nativ — nur das Herstellen nicht.
• Postfach einrichten (IMAP-Zugangsdaten) und Sicherung/Wiederherstellung (ersetzt die ganze Datenbank). Gehört an den Rechner.
• Benutzerverwaltung (/users, /policy) — Administration, weggelassen, solange der Nutzer nicht widerspricht.
• Belege als Anhang gibt es nicht. Im Datenmodell existiert nichts dergleichen. POST /api/documents/preview ist eine Einbahnstrasse: Bild rein, erkannter Text und Buchungsvorschläge raus, die Datei wird nicht gespeichert.

---

4. Backend-Ergänzungen

Vier geplant, alle vier sind fertig. Falls du eine fünfte brauchst: einzeln dem Nutzer vorlegen, bevor du sie schreibst.

A — App-Token ✅ (Commit 8a7545b)

TokenScope hat neben quick_add jetzt app. get_current_user akzeptiert den Header X-Certain-Token, wenn die Marke diese Reichweite hat. Kein Migrationsschritt nötig — _enum() legt Enums ohne DB-Bedingung ab.

Die Prüfung sitzt in _session_user (backend/app/deps.py), nicht in get_current_user — damit auch enforce_account_state die Marke sieht und eine App nicht an der Passwortwechsel-Pflicht vorbeikommt.

Zwei Dinge, die die Tests festhalten (backend/tests/test_app_marke.py, 7 Stück):

• Eine quick_add-Marke ist nicht still zum Vollzugang geworden. Sie gilt weiter nur an den drei /quick-Endpunkten.
• Eine App-Marke darf keine weitere ausstellen (require_cookie_session an POST /api/inbox/tokens). Sonst stellte ein Dieb sich Ersatzschlüssel aus und das Widerrufen liefe ins Leere.

B — Suche und Tag-Filter auf /transactions ✅

Drei Query-Parameter: q (Volltext über payee, description, notes), tag_id, subscription_id. Der Tag-Filter arbeitet mit einer Unterabfrage wie der uncategorized-Zweig daneben, nicht mit einem Join — sonst käme eine Buchung so oft zurück, wie sie Tags trägt.

Zwei Dinge, die die Tests festhalten (backend/tests/test_buchungssuche.py, 7 Stück):

• % und _ im Suchtext sind Zeichen, keine Platzhalter. Sonst fände die Eingabe „50%" alles.
• Ein fremder tag_id liefert nichts, nicht etwa alles. Der Filter schlägt auf TransactionTag.owner_id an.

Grenze: SQLite vergleicht bei LIKE nur ASCII ohne Rücksicht auf Gross- und Kleinschreibung. „Müller" findet „müller" nicht. Reicht, bis jemand es meldet.

Der lokale Name q im Router hiess vorher die Abfrage selbst; die heisst jetzt abfrage, damit der Query-Parameter q heissen kann.

C — GET /budget/template liefert modus und zuschlag_cents ✅

Beide fehlten in der Antwort (backend/app/routers/budgets.py), obwohl das Modell sie führt und PUT sie zurückgibt. Jetzt stehen sie in jeder Zeile. Test: test_vorlage_nennt_betriebsart_und_zuschlag in test_budget.py.

Das war der stillere der beiden Fehler: Ein Client, der die Vorlage so liest, zeigt eine berechnete Zeile als feste und schreibt sie beim nächsten Speichern auch als feste zurück. Die Weboberfläche traf es nicht, weil sie die Betriebsart aus der Monatsansicht nimmt.

D — Zwei Kopier-Lücken im Budget ✅

copy_template_to_month und copy_month_to_template in backend/app/services/budget.py übernahmen nur planned_cents. Ein „berechneter" Eintrag fiel beim Kopieren still auf „fest" zurück — mit der Zahl, die zufällig zuletzt in planned_cents stand.

ensure_customized nebenan machte es längst richtig; die zwei Kopierer ziehen jetzt nach. Dabei kam eine Frage auf, die vorher niemand stellen musste: Eine berechnete Zeile gehört auch mit planned_cents == 0 in die Vorlage, ihre Zahl steht ja in den Verträgen. Eine feste Null bleibt draussen, sonst füllte sich die Vorlage mit Nullzeilen für jede je berührte Kategorie.

Drei Tests in test_budget.py halten beide Richtungen und die Null fest.

---

5. Was fertig ist — Stufen 1 bis 4 ✅

Stufe 1 (Commit 6b86a6b)

21 Swift-Dateien, rund 2600 Zeilen, in ios/:

Ordner	Inhalt
App/	CertainApp (Einstieg), AppZustand (zentraler Zustand), RootAnsicht (Navigation)
Netzwerk/	CertainClient (Actor um URLSession), Endpunkte, APIFehler, Ablage (Voreinstellungen + Schlüsselbund), Zwischenspeicher (offline), Lader
Modelle/	Grundmodelle (Benutzer, Marke, Einstellungen, Serverkennung), Konto, Zeitangaben
Bausteine/	Geldbetrag, Darstellung (Farben, Symbolzuordnung, Plakette), Zustandsansichten
Anmeldung/	Server-Adresse, Anmeldung, zweiter Faktor, Passwortwechsel
Konten/	KontenListe — die erste Fachansicht
Einstellungen/	Platzhalter: zeigt den Zugang und lässt abmelden
Texte/	de.lproj und en.lproj, zeilengleich
Tests/	GrundlagenTests — reine Logik, Swift Testing, 28 Stück
project.yml	XcodeGen-Spezifikation, erzeugt Certain.xcodeproj

Wie die Anmeldung abläuft

1. Nutzer gibt die Adresse ein → GET /api/version prüft, ob dort Certain läuft.
2. Nutzer meldet sich an → normales Cookie, inklusive 2FA und Pflicht-Passwortwechsel.
3. Noch in derselben Sitzung legt die App über POST /api/inbox/tokens mit scope: "app" eine Marke an und legt den Klartext in den Schlüsselbund.
4. Danach trägt nur noch der Header. Das Cookie wird weggeworfen (vergissCookies()).

Kein Passwort auf dem Gerät, kein Ablauf nach 30 Tagen, einzeln widerrufbar.

Was geprüft ist

Jedes Modellfeld wurde gegen echte Antworten eines laufenden Backends verglichen (/api/version, /api/auth/me, /api/accounts, /api/settings, /api/inbox/tokens). Alle Namen stimmen. Mach das bei jeder weiteren Stufe genauso — das ist die einzige Prüfung, die beim blinden Schreiben wirklich etwas fängt. Wie: Ein kleines Python-Skript mit TestClient gegen eine Wegwerf-Datenbank, Felder flach ausgeben, mit den CodingKeys vergleichen. (Das Passwort der Dev-Datenbank unter backend/data/app.db ist unbekannt — nicht raten, eine frische Testdatenbank nehmen.)

Dass es übersetzt, ist inzwischen geprüft

Am 21.10.2026 gebaut, getestet und gestartet (Commit ffe1870). Genau ein Übersetzungsfehler in 2600 blind geschriebenen Zeilen: der Vorgabewert [String: String] = [] in CertainClient.schickeDatei musste [:] heissen. Sonst keine Fehler, keine Warnung im eigenen Code. Die 28 Tests laufen durch, die App startet im Simulator bei der Serverabfrage.

Noch nicht geprüft: der Weg gegen ein echtes Backend. Anmelden, zweiter Faktor, Marke anlegen, Kontenliste — das lief bisher nur gegen die Modelle, nicht gegen einen laufenden Server. Siehe „Klartext-HTTP" unten.

Stufe 2 — Lesen ✅ (Commit bf437b3)

Vier neue Reiter, dazu die Modelle und Endpunkte darunter:

Ordner	Inhalt
Dashboard/	DashboardAnsicht — vier feste Karten, ein Abruf
Budget/	BudgetAnsicht — Soll/Ist je Gruppe, blätterbar
Buchungen/	BuchungsListe — Suche und Filter im Server
Abos/	AboListe — Monats- und Jahressumme, Fälligkeit
Modelle/	Buchung, Budget, Abo, Kategorie, Dashboard

Drei Entscheidungen, die man kennen sollte, bevor man daran weiterbaut:

1. Das Dashboard holt alles in einem Wert (Dashboarddaten). Vier getrennte Zwischenspeicher könnten offline aus vier verschiedenen Momenten stammen und sich widersprechen.
2. Das Nachschlagewerk sitzt im AppZustand, nicht in den Ansichten. Nachschlag hält Kategorien, Schlagwörter und Konten; jede Liste braucht zu einer ID den Namen, das Symbol und die Farbe.
3. Die Buchungsliste sucht erst beim Absenden. Je Tastendruck zu fragen hiesse, bei „Supermarkt" zehn Abrufe zu schicken, von denen neun niemanden interessieren.

Die Übertrags-Paarung steckt in Buchungszeile.zeilen (Modelle/Buchung.swift). Zwei Dinge daran sind leicht falsch zu machen, beide durch Tests festgehalten:

• Zusammengefasst wird nur, wenn beide Beine in der Liste stehen. Sonst liesse ein Kontofilter Zeilen verschwinden, die zu diesem Konto gehören.
• Die Richtung kommt aus richtung der Verknüpfung, nicht aus dem Vorzeichen — manche Banken liefern beide Beine positiv.

Die Modellprüfung ist jetzt ein Test

backend/scripts/erzeuge_ios_fixture.py legt eine Wegwerfdatenbank an, befüllt sie so, dass jedes Feld einmal belegt ist, und schreibt 15 echte Antworten nach ios/Tests/Fixtures/antworten.json. Der Swift-Test Serverantworten entschlüsselt daraus jedes Modell.

Das ersetzt die Handarbeit, die hier früher beschrieben stand. Nach jeder Änderung an einem Schema das Skript neu laufen lassen und die Datei mit committen:

cd backend && .venv/bin/python -m scripts.erzeuge_ios_fixture

Wer ein Modell ergänzt, nimmt seinen Endpunkt in PFADE auf und schreibt eine Zeile im Test dazu. Das ist die einzige Prüfung, die einen vertippten Feldnamen fängt — der übersetzt anstandslos.

Stufe 3 — Schreiben ✅ (Commit 82db09e)

Buchungen, Budget-Zeilen, Verträge und Konten lassen sich anlegen, ändern und löschen.

Datei	Inhalt
Modelle/Eingaben.swift	Was zum Server hinausgeht
Bausteine/Formular.swift	Speichervorgang, Betragsfeld, Auswahlfelder
Buchungen/BuchungFormular.swift	Anlegen und Ändern in einer Maske
Budget/BudgetZeileBearbeiten.swift	Monat oder Vorlage, dieselbe Maske
Abos/AboFormular.swift, Konten/KontoFormular.swift	ebenso

Ein Formular je Sache, nicht zwei. Anlegen und Ändern teilen sich die Maske; was sich unterscheidet, steht in einem Zweck-Typ. Zwei Masken nebeneinander wären genau die Stelle, an der sie auseinanderlaufen.

Vier Regeln, die man nicht sieht, aber merkt, wenn sie fehlen

1. Eine Teiländerung schickt nur, was gesetzt ist. Ginge ein nicht angefasstes Feld als null hinaus, löschte jedes Speichern den Empfänger, die Notiz und die Kategorie gleich mit. Swift macht das von selbst (encodeIfPresent für Optionals) — der Test dazu bleibt trotzdem stehen, die Eigenschaft ist zu wichtig für eine ungeprüfte Spracheigenheit.
2. Eine leere Tag-Liste geht sehr wohl mit. Sie heisst „alle abnehmen" und darf nicht mit „nicht angefasst" zusammenfallen.
3. Ein Übertrag bekommt keine Kategorie. Das Geld wechselt nur die Tasche.
4. Bei „berechnet" bleibt planned_cents unberührt. Das Backend liest es dann nicht, und es zu überschreiben verlöre den Wert, auf den ein Zurückschalten auf „fest" zurückfallen soll.

Die Währung eines bestehenden Kontos lässt sich nicht ändern — jeder gespeicherte Betrag würde danach etwas anderes bedeuten. Das Backend erlaubt es; die App nicht.

Fehlende Texte findet dieser Befehl

String(localized:) mit unbekanntem Schlüssel übersetzt anstandslos und zeigt dem Nutzer den Schlüssel. Vor dem Committen:

cd ios && comm -23 \
  <(grep -rhoE 'localized: "[a-zA-Z0-9._]+"' --include="*.swift" . | sed 's/localized: "//; s/"//' | sort -u) \
  <(grep -oE '^"[a-zA-Z0-9._]+"' Texte/de.lproj/Localizable.strings | tr -d '"' | sort -u)

Gibt er nichts aus, ist nichts offen. (Ein Schlüssel, der nur in einem ? : steckt, taucht fälschlich als „fehlend" nicht auf — das ist die eine Lücke des Befehls.) Dass beide Sprachfassungen dieselben Schlüssel tragen, prüft ein diff der beiden grep-Ausgaben.

Stufe 4 — Arbeitsliste ✅ (Commit 9edf610)

Ein Reiter „Eingang" mit vier Abschnitten, jeder mit Anzahl im Kopf: offene Eingangseinträge, Übertragsvorschläge, Gebuchtes ohne Kategorie, Dubletten. Arbeitsliste/ArbeitslisteAnsicht.swift, dazu zwei schmale Auswahlblätter in AuswahlBlaetter.swift.

Alles in einem Abruf (Arbeitsstand), aus demselben Grund wie beim Dashboard: Vier getrennte Zwischenspeicher könnten offline aus vier verschiedenen Momenten stammen.

Der 409-Fall sitzt hier, und nur hier

POST /inbox/{id}/transfer kann mit 409 antworten. Das ist eine Frage, kein Fehler: Die App zeigt den Hinweis und wiederholt den Aufruf auf Wunsch mit trotzdem: true. bucheAlsUebertrag fängt APIFehler.konflikt eigens ab, statt ihn in den allgemeinen Fehlerweg laufen zu lassen. Wer später einen weiteren 409-Endpunkt anbindet, macht es genauso.

Kleinigkeiten, die man sonst zweimal findet

• Ohne Konto lässt sich nichts buchen (400 vom Backend). Der Knopf bleibt grau — und die Zeile sagt „ohne Konto", damit das nicht unerklärt wirkt.
• Ein Übertrag braucht keine Kategorie. Daran erkennt man ihn: transfer_account_id ist gesetzt. Ohne diese Prüfung fragte die Liste ewig nach einer Kategorie, die es nie geben wird.
• Die Dublettenliste zeigt die Kennung der Bank. Verschiedene Kennungen heissen: Die Bank hat sie ausdrücklich als verschiedene Zahlungen gemeldet. Ohne diese Spalte lässt sich die Frage nicht entscheiden.

Ein Backend-Fehler, den die App ans Licht brachte

/uebertraege/vorschlaege lieferte jedes Paar zweimal, einmal je Richtung: Was verknüpft wird, fällt über verbraucht heraus — ein blosser Vorschlag nicht. Die Weboberfläche zeigte den Doppeleintrag genauso. Behoben in services/uebertraege.py (schlage_vor), mit Test.

Prüfdatei-Tests zählen keine Mengen mehr

Die Saat in erzeuge_ios_fixture.py wuchs um Eingangseintrag, Dubletten und ein Übertragspaar — und die älteren Tests wurden rot, weil sie exakte Anzahlen prüften. Sie prüfen jetzt Eigenschaften (>= 2, „enthält einen Übertrag"), damit sie das nächste Wachstum überleben. Daran denken, wenn du die Saat erweiterst.

---

6. Was als Nächstes dran ist

Stufe 5 ist dran. Alle vier Backend-Ergänzungen sind drin; von hier an reicht die API, wie sie ist.

Was bewusst nicht mitkam: das Logo eines Vertrags (Upload und Zuschnitt, POST /subscriptions/{id}/logo), die Reihenfolge der Konten (PUT /accounts/order) und das Lösen einer Übertrags-Verknüpfung (DELETE /uebertraege/{link_id}) — in der Arbeitsliste gibt es nur noch nichts Verknüpftes zu lösen. Alles drei ist am Rechner bequemer und hielt niemanden auf.

Stufe 5 — Nebenräume. Kategorien, Tags, Schlagwörter, Einstellungen, Bankabruf anstossen. Hier gehört auch das Einrichten des zweiten Faktors hin — bisher verweist die App dafür in den Browser.

Stufe 6 — Erweiterungen. Teilen-Menü und Kurzbefehle. Brauchen eigene Ziele im Xcode-Projekt, eine App-Gruppe und eine geteilte Schlüsselbund-Gruppe; Netzwerk/Ablage.swift hat dafür schon die beiden Konstanten gruppe und schluesselbundGruppe (stehen auf nil). Für die Kurzbefehle ist POST /api/quick/booking fertig: Header-Marke, idempotent über external_id, fertig formulierte Antwort-Meldung.

Stufe 7 — Import, voll. Erkennen, Rohansicht, Spaltenzuordnung, Formateinstellungen, Zeilenfilter, editierbare Prüfansicht, Saldo-Abgleich, Vorlagen, Verlauf mit Rücknahme.

Zum Umfang, ehrlich

Die Weboberfläche hat rund 8900 Zeilen JSX. Nativ wird das nicht weniger. Stufe 2 hat rund 1800 Zeilen gebraucht, Stufe 3 rund 1200, Stufe 4 rund 900; Stufen 5 und 6 zusammen sind grob eine Woche, Stufe 7 nochmal zwei bis drei.

Der 409-Fall („nachfragen", mit trotzdem=true wiederholbar) ist in Stufe 4 angekommen und erledigt — siehe dort. In den Stufen 5 bis 7 kommt er nicht mehr vor.

Stufe 7 steht bewusst am Ende. Alles davor ist für sich nutzbar. Der Ablauf hat keinen Server-Zustand zwischen den Schritten: Die Datei wird bei jedem Schritt neu hochgeladen, und beim Buchen gehen die Vorschauzeilen unverändert zurück an den Server. Eine editierbare Prüftabelle mit 300 Zeilen und neun Spaltenzuordnungen ist auf Telefonbreite ein Entwurfsproblem, kein Übersetzungsproblem. Das Backend selbst sagt dazu in backend/app/routers/quick.py: „Ein Auszug hat schnell hunderte Zeilen; die am Telefon durchzusehen wäre keine Erleichterung." Der Nutzer kennt diesen Einwand und will den vollen Import trotzdem.

---

7. Fallen und Arbeitsweise

Klartext-HTTP — der nächste Stolperstein

Das Projekt läuft mit der Voreinstellung von App Transport Security, also nur https. Ein selbstgehosteter Server im Heimnetz unter http://… wird abgewiesen, und http://localhost beim Entwickeln ebenso — obwohl ServerAnsicht http ausdrücklich zulässt und ein Test das festhält („http bleibt http"). Wer gegen ein lokales Backend prüfen will, braucht in project.yml eine ATS-Ausnahme. Das ist eine Sicherheitsentscheidung des Nutzers: über Klartext geht die Gerätemarke, ein Vollzugang, mit jeder Anfrage mit.

Was beim Übersetzen auffiel

Alles, was hier als verdächtig stand, hat gehalten: Lader als generische @Observable-Klasse, der @MainActor/Actor-Übergang zwischen AppZustand und CertainClient, Tab mit .tabViewStyle(.sidebarAdaptable), Swift Testing statt XCTest. Eine Einschränkung: Das Projekt baut in Sprachfassung Swift 5. Unter Swift 6 greift die strikte Nebenläufigkeitsprüfung, und die Übergänge sind darauf nicht geschrieben — wer umstellen will, rechnet mit Arbeit an genau diesen Stellen.

Schreibende Aufrufe mit Query statt Körper

Leicht zu übersehen, das Backend macht es an mehreren Stellen: PUT /budget/template/category/{id}, PUT /budget/{label}/category/{id}, PUT /settings/{key}, POST /subscriptions/{id}/preis.

Konventionen des Projekts

• Alles auf Deutsch: Code-Kommentare, Bezeichner, Testnamen, Commit- Meldungen, Oberflächentexte. Testnamen sind deutsche Aussagesätze, ASCII-transliteriert (test_app_marke_darf_lesen_und_schreiben).
• Commits: typ: Wirkung für den Nutzer, auf Deutsch, eine Wirkung je Commit. Fertige Arbeit wird committet und gepusht, ohne Rückfrage.
• Kommentare erklären das Warum, nicht das Was — und zwar das, was der Code nicht zeigen kann. Das ganze Projekt ist so geschrieben; halte es durch.
• Neue Swift-Datei? Danach cd ios && xcodegen generate. Die Ordner stehen einzeln in project.yml; ein neuer Ordner will dort eine Zeile.
• Tests: cd backend && .venv/bin/python -m pytest tests/ -q (auf Windows ./.venv/Scripts/python.exe). Python 3.12 im venv; das System-Python kann nicht bauen. Dauert hier rund 45 Sekunden.
• Erwartung: alles grün, 438 Tests. Die zwei Ausfälle, die hier früher als „vorbekannt rot" standen, waren ein Windows-Problem der alten Maschine (WinError 10106 im Subprozess) und laufen auf diesem Rechner durch. Wer einen roten Test sieht, hat ihn verursacht.
• Fehlt dem venv ein Modul (ModuleNotFoundError), einmal .venv/bin/python -m pip install -r requirements.txt — es war hier nicht auf dem Stand von requirements.txt.
• Heredocs in Bash scheitern an den deutschen Anführungszeichen („ "). Für Dateien mit solchen Zeichen das Write-Werkzeug nehmen, nicht cat <<EOF.

Offene Punkte, die der Nutzer bestimmt

• Name, Bundle-ID und Signierung — er legt das Projekt an.
• Ob die Benutzerverwaltung doch mit hinein soll.
• Ob eine neu vergebene App-Marke am Rechner bestätigt werden muss, bevor sie gilt. Sicherer, aber umständlich beim Einrichten eines neuen Geräts.