docs: Uebergabe, README und Fahrplan halten Stufe 2 fest

Was neu drinsteht, damit der naechste Agent es nicht selbst herausfinden muss:
die drei Entwurfsentscheidungen der Stufe 2 (Dashboard in einem Abruf,
Nachschlagewerk im AppZustand, Suche erst beim Absenden), die zwei Fallen der
Uebertrags-Paarung, und dass die Modellpruefung jetzt ein Test ist statt
Handarbeit - samt dem Befehl, die Pruefdatei neu zu erzeugen.

Naechster Schritt steht oben: Stufe 3, davor nur noch Backend-Ergaenzung D.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

ios/README.md

@@ -43,9 +43,13 @@ Vollzugang. Wer eine Ausnahme braucht, trägt sie bewusst in `project.yml` ein.
 | `Modelle/` | Codable-Typen, eins zu eins zu den Backend-Schemas |
 | `Bausteine/` | Wiederverwendetes: Geld, Farben, Symbole, Zustandsansichten |
 | `Anmeldung/` | Server-Adresse, Anmeldung, zweiter Faktor, Passwortwechsel |
-| `Konten/` | Kontenliste (die erste Fachansicht) |
-| `Texte/` | Übersetzungen |
-| `Tests/` | Reine Logiktests, ohne Netz |
+| `Dashboard/` | Die Übersicht: vier feste Karten |
+| `Budget/` | Soll gegen Ist, Monat für Monat |
+| `Buchungen/` | Buchungsliste mit Suche und Filtern |
+| `Abos/` | Verträge und Abos |
+| `Konten/` | Kontenliste |
+| `Texte/` | Übersetzungen, Deutsch und Englisch zeilengleich |
+| `Tests/` | Logiktests ohne Netz, plus die Modellprüfung gegen `Fixtures/antworten.json` |
 
 ## Wie die Anmeldung funktioniert
 

ios/UEBERGABE.md

@@ -235,7 +235,9 @@ sie beide Richtungen anbietet. Nötig für Stufe 3.
 
 ---
 
-## 5. Was fertig ist — Stufe 1 ✅ (Commit `6b86a6b`)
+## 5. Was fertig ist — Stufen 1 und 2 ✅
+
+### Stufe 1 (Commit `6b86a6b`)
 
 21 Swift-Dateien, rund 2600 Zeilen, in `ios/`:
 
@@ -287,13 +289,62 @@ die App startet im Simulator bei der Serverabfrage.
 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 für Stufe 3 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.
+
 ---
 
 ## 6. Was als Nächstes dran ist
 
-**Stufe 2 — Lesen.** Dashboard (feste Ansicht: Kontostände, Budget-Fortschritt,
-letzte Buchungen, Einnahmen/Ausgaben), Budget-Monatsansicht, Buchungsliste,
-Abo-Liste. Die Backend-Ergänzungen **B** und **C**, die sie braucht, sind da.
+**Stufe 3 ist dran.** Davor liegt nur noch Backend-Ergänzung **D** (unten),
+die zwei Kopier-Lücken im Budget.
 
 **Stufe 3 — Schreiben.** Buchungen anlegen und ändern, Budget bearbeiten
 (Monat und Vorlage, beide Betriebsarten `fest`/`berechnet`), Abos verwalten
@@ -321,8 +372,12 @@ Vorlagen, Verlauf mit Rücknahme.
 ### Zum Umfang, ehrlich
 
 Die Weboberfläche hat rund 8900 Zeilen JSX. Nativ wird das nicht weniger.
-Stufen 2 bis 6 zusammen sind grob drei bis vier Wochen, Stufe 7 nochmal zwei
-bis drei.
+Stufe 2 hat rund 1800 Zeilen gebraucht; Stufen 3 bis 6 zusammen sind grob
+zwei bis drei Wochen, Stufe 7 nochmal zwei bis drei.
+
+Stufe 3 wird die aufwendigste der verbliebenen: Schreiben heisst Formulare,
+Fehlerbehandlung je Feld und der 409-Fall („nachfragen", oft mit
+`trotzdem=true` wiederholbar). Lesen war dagegen geradeaus.
 
 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