Erste Erfahrungen mit Fable 5 .. Coding Projekt

Für alle die mal einen Einblick in den Fable 5 Maschinenraum benötigen ... Ich habe gerade ein sehr ausgeprägtes Entwicklungsprojekt (mit insgesamt drei Sessions und 3 Millionen verbrauchter Tokens) .. durch Fable 5 mit diesem Prompt analysieren lassen

❓ PS: Wie sind eure Erfahrungen .. schreibt es gerne mal in die Kommentare .. übrigens .. auch Texterstellung ist eine ganz neue Schraube .. unfassbar.

🔥 — PROMPT —

hey .. danke bis hier hin .. super .. ich habe jetzt gerade mal auf Fable 5 umgestellt .. überprüfe alles was wir hier entwickelt haben .. und mach konkrete Vorschläge, die es zu optimieren und umzusetzen gilt .. da wo wir fehler gemacht haben .. da wo wir noch nicht zu ende gedacht haben .. da wo wir im Coding haetten ergaenzend oder anders denken müssen ..

schau dir alles genau an .. und dann lass uns eine plan.md oder optimierung.md schreiben die wir dann gemeinsam, ggf in einer neuen Session, umsetzen werden ..

oder was meinst du ?

gehe voran und nutze dein volles potential .. keine grenzen.

🔥 — ANTWORT —

Sehr gute Idee — genau der richtige Zeitpunkt für einen Schritt zurück. Ich mache das gründlich: Ich lasse zwei Review-Agenten parallel über Security/Korrektheit und UI/API-Robustheit laufen, verifiziere parallel selbst ein paar Verdachtsmomente, die ich aus dem Bauen im Hinterkopf habe (einer davon riecht nach echtem P0-Bug), und destilliere alles in eine priorisierte OPTIMIERUNG.md.

🔥 —

und 2 Agenten sind losgelaufen .. nach 4 Minunten waren 150.000 Toekens verbraucht ..

unfassbare Analysen sind entstanden

🔥 — AUSFÜHRLICHE ANTWORT 1 ——

P0-Bug empirisch bestätigt: 100 KB-Upload → 200, 2 MB-Upload → 413 „request entity too large". Das globale express.json({limit:'1mb'}) in server.js läuft vor dem Router und gewinnt — das heutige Datei-Upload-Feature scheitert also an realen Transkripten/Workbooks über ~750 KB. Kommt als verifizierter P0 in die Optimierungsliste.

Die beiden Review-Agenten (Security/Korrektheit über src/ + server.js, UI/API-Contract über die Admin-SPA) laufen noch im Hintergrund. Sobald ihre Findings da sind, merge ich sie mit meiner eigenen Liste — ich habe aus dem Bauen heraus bereits ~20 konkrete Punkte notiert, u. a.:

Sales-Stats-Risiko: listLaunchSales zählt Stripe-Sessions ohne lp_slug-Metadata mit (z. B. Payment-Link-Käufe, andere Produkte im Zeitfenster) → Debrief-Zahlen können zu hoch sein.

mailRenderer ungehärtet: Die Parse-Härtung (rohe Zeilenumbrüche in JSON-Strings, Harvest, stop_reason-Logging), die wir für Café/iPad bauen mussten, fehlt im Mail-Renderer — gleiche Bug-Klasse, nur noch nicht getroffen. Plus 4000-Token-Limit.

Gewählter Betreff fehlt: Der Walker-Debrief nimmt still Betreff-Option 1 — es gibt keine Möglichkeit, den tatsächlich gesendeten Betreff zu markieren.

Drift-Gefahr durch Duplikate: klicktippName/SEELE doppelt (Routes ↔ DebriefEngine — bricht bei Drift die OPEN::-Tags), Kadenz-Offsets (S−10/S−3, Cart-Close) dreifach hartkodiert statt aus der Sequenz gelesen.

Weggeworfene Tests: ~100 Asserts aus dieser Session existieren nur als gelöschte Temp-Skripte — die gehören als tests/ + npm test ins Repo.

Sobald die Agenten fertig sind, schreibe ich die priorisierte docs/OPTIMIERUNG.md (P0/P1/P2, je mit Problem, Fix-Skizze, Aufwand, Akzeptanzkriterien) und committe sie. Mein Vorschlag dazu: Die 2–3 verifizierten P0-Bugs fixen wir direkt danach noch in dieser Session (sind klein), den Rest strukturiert in einer frischen Session.

🔥 —

nach 8 Minuten bereits 300.000 Tokens .. und ich wette, das ding ist jeden Cent wert.

🔥 — ANTWORT TEIL 2 ——

Der UI/API-Review-Agent ist fertig — 14 substanzielle Findings, darunter richtig gute Catches, die ich selbst nicht auf dem Zettel hatte:

„generiert ✓" trotz Fehlschlag — generateLaunch liefert bei Render-Fehlern HTTP 200 mit skipped: [{reason: 'error: …'}], die UI wertet nur den HTTP-Status → alter Stand bleibt, Toast lügt. Das erklärt möglicherweise auch verwirrende Momente beim Testen.

Popup-Blocker schluckt das iPad-Deck — window.open nach 30–90 s Claude-Call hat keine User-Activation mehr → Chrome/Safari blocken den Tab still.

Getippter Impuls geht verloren, wenn man im Regen-Dialog direkt auf „Neu generieren" klickt ohne vorher „Text hinzufügen" — klassische Zwei-Schritt-Falle.

Cross-Launch-Races: verspätete Fetches schreiben beim Launch-Wechsel in den State des falschen Launches.

Regen-Dialog umgeht den Edit-Schutz (force:true immer) — handeditierte/freigegebene Mails werden kommentarlos überschrieben.

Plus: mein 413-Fund bestätigt (inkl. dem Detail, dass Production die Meldung zu „Interner Fehler" maskiert), Debrief-Panel klappt nach Generierung zu, Fill-Report überlebt keinen Reload, Duplikat-Launches pro Slug möglich.

Erfreulich: XSS-Hygiene und Listener-Delegation sind sauber — durchgehend escaped, sandboxed iframes, stabile Delegation.

Ich warte jetzt auf den zweiten Agenten (Security/Korrektheit über src/ + server.js) — sobald der reportet, schreibe ich die konsolidierte, priorisierte docs/OPTIMIERUNG.md und committe sie.

🔥 —

12 Minuten .. 308.000 Tokens

🔥 — ANTWORT TEIL 03 —

Beide Reviews sind durch — der Security-Agent hat weitere harte Treffer geliefert (u. a. unbezahlte SEPA-Sessions zählen als Sale, Path-Traversal über format_code, resolveTagId-Substring-Match kann falsche Tags zählen). Zusammen mit meiner eigenen Liste und dem verifizierten 413-Bug konsolidiere ich jetzt alles in die priorisierte docs/OPTIMIERUNG.md:

🔥 —

er fokussiert voll auf Sicherheitsthemen und Transnationale Prozessschritte ..

🔥 —

Erste Optimierungen bereits vollautomatisch umgesetzt und in Produktion ‚durchgepusht‘  —— ERSTE PLANREFLEKTION ——

Der Plan steht in 5 Wellen am Ende der Datei. Meine klare Empfehlung:

* Welle 1 (Sofort-Bugfixes, ~½ Tag) würde ich nicht auf eine neue Session verschieben — alles kleine S-Items, aber zwei davon betreffen dich praktisch: Das Upload-Feature von heute klemmt bei großen Dateien, und die Debrief-Zahlen wären beim nächsten Launch falsch. Sag „go" und ich ziehe Welle 1 jetzt durch (v0.28.1).

* Welle 2 (Debrief-Zahlen-Korrektheit) vor deinem nächsten echten Launch-Debrief.

* Welle 3 (KlickTipp live) terminieren wir, wenn du die Keys hast.

* Wellen 4–5 (Härtung, Tests, Admin-Split) sind ideal für eine frische Session — die Datei ist so geschrieben, dass eine neue Session sie als Arbeitsauftrag direkt abarbeiten kann.

🔥 —

350.000 Token Verbrauch .. und der Plan steht und wird jetzt ausgeführt

🔥 —

❓ PS: Wie sind eure Erfahrungen .. schreibt es gerne mal in die Kommentare .. übrigens .. auch Texterstellung ist eine ganz neue Schraube .. unfassbar.

35 comments