Loft

Was macht Loft?

Schneide keinen Stahl, bis die Form stimmt. Schiffbauer zeichnen die Rumpflinien im Originalmaßstab und gleichen sie aus, bevor eine einzige Platte geschnitten wird. Loft wendet dieselbe Ordnung auf Designfragen an: Wenn Worte keine Lösung bringen – zwei plausible Antworten, keine durch Diskussion falsifizierbar – baue ein billiges, lauffähiges Artefakt, lass den Kapitän darauf reagieren und nimm diese Reaktion in die Entscheidung auf.

Der Rollenvertrag. Das Team baut das Artefakt; der Kapitän hat nur die Aufgabe zu reagieren – und diese Reaktion ist die Entscheidung. Das Artefakt ist ein Werkzeug zum Sehen, nie ein Vorsprung auf das Lieferbare.

Wann loft verwendet werden sollte

• eine Designfrage steckt in Prosa fest: wiederholt umformuliert, immer noch nicht entscheidbar („Wie soll die Pfadseite aussehen?“, „Fühlt sich dieses Zustandsmodell richtig an?“)
• eine Navigatorkarte enthält ein loft-Ticket
• eine Spezifikationsdiskussion erreicht den Punkt: „Das müsste man sich erstmal ansehen“

Nicht loft verwenden, wenn:

• die Frage anhand von Repository-Beweisen oder durch Befragen des Kapitäns beantwortbar ist (das ist Interviewen, nicht Loft)
• das Ziel selbst unklar ist (das ist Nebel – /oh-my-claudecode:ask-navigator)
• die Antwort bereits in einem ADR existiert (keine bereits getroffenen Entscheidungen erneut loften)
• die „Designfrage“ eigentlich ein Bug ist (das fällt in den Zuständigkeitsbereich des Debuggers)

Die Gabelung wählen

Wähle danach, wonach die Frage fragt. Eine falsche Gabelung verschwendet das gesamte Artefakt.

Logikgabelung – ist das Modell richtig?

Für Fragen zu Zustand, Geschäftslogik, Datenstruktur oder Algorithmen („Führt Entsperren bei einer Wiederholung zu Regression?“, „Hält dieser Reducer auch an den Rändern?“):

1. Isoliere den entscheidungstragenden Kern – den Zustandsautomaten, Reducer, das Schema oder den Algorithmus – als reines Modul: kein DOM, keine Ein-/Ausgabe, kein Framework. So geschrieben, dass er nach Bestätigung der Form unverändert in die echte Codebasis übernommen werden kann.
2. Verpacke ihn in eine einzelne klickbare HTML-Hülle: ein Button pro Szenario, die kniffligen Randfälle in Reihenfolge durchgegangen, nach jedem Klick der vollständige Zustand sichtbar.
3. Nach Bestätigung, dass das Modul übernahmefähig ist – es kehrt als echte Arbeit durch Launch zurück. Während des Lofts selbst bleibt main unberührt und die Hülle bleibt auf dem Branch zurück.

UI-Gabelung – wie soll es aussehen?

Für Fragen zu Form und Anordnung („Schritte oder Karten?“, „Wo lebt der Fortschritt?“):

1. Eine Route, drei Varianten, die sich strukturell unterscheiden – Informationsarchitektur, Navigationsmodell, Dichte. Varianten, die sich nur im Styling unterscheiden, beantworten nichts: drei Neulackierungen sind Tapetenwechsel.
2. Ein Schalter auf der Seite wechselt die Varianten durch; wo möglich in das bestehende Produkt einbetten, sodass echte Datendichte das Design stresst statt drei ordentlicher Dummy-Zeilen.
3. Nach Bestätigung wird die Entscheidung übertragen und die Varianten bleiben auf dem Branch als Aufzeichnung, warum es so aussieht.

Die Disziplin

• Ein einziger Befehl zum Ausführen – der einfachste bestehende Serve-Befehl des Repos; das Modul bei Bedarf in die Hülle einbetten, falls file://-Modul-CORS beißen würde. Lädt in Sekunden; kein Build-Schritt über das hinaus, was das Repo bereits hat.
• Keine Persistenz, keine Tests, keine Abstraktionen, keine Fehlerbehandlung jenseits des Happy Paths. Das Artefakt sollte etwas sein, das du nicht ausliefern möchtest – die Regeln existieren, um es so zu halten.
• Erwarte, dass die erste Form angefochten wird: überarbeite auf dem Branch innerhalb derselben Session. Der Kapitän, der die endgültige Form bestätigt, ist die Entscheidung; ein Artefakt, das niemand anficht, hat meist eine Frage beantwortet, die niemand hatte.
• Die gesamte Lebensdauer des Artefakts beträgt Minuten zum Bauen und eine Session zum Entscheiden. Wenn es anfängt, in Produktionscode hineinzuwachsen, stoppe: Diese Arbeit ist ein Launch-Aufwand, kein Loft. Sunk Cost ist der Fehlermodus, den dieses Skill verhindern soll.
• Ein Loft beantwortet eine Frage. Zwei Fragen sind zwei Lofts – oder eine Frage, die eigentlich zwei waren.

Die Antwort einordnen

Das Artefakt ist Beweis, keine Landung. Wenn der Kapitän reagiert:

1. Halte die Entscheidung dort fest, wo sie hingehört – im Issue-Kommentar, in den Implementierungsentscheidungen der Spezifikation oder in der anstehenden Entscheidungsnotiz – in den eigenen Worten des Kapitäns plus einer Zeile Begründung. Ein Fragment, das präziser als Prosa ist (der Reducer, der Zustandsautomat, das Schema), kann dort inline eingefügt werden, markiert als geloftet.
2. Schiebe das Artefakt auf einen loft/<name>-Branch. Es wird niemals gemerged: Es bleibt als primäre Quelle, die ein zukünftiger Leser öffnen kann, wenn das „Warum“ der Entscheidung wichtig wird.
3. Nichts aus dem Artefakt landet in main – bei der Logikgabelung kehrt das bestätigte Modul als echte Arbeit durch Launch zurück, bei der UI-Gabelung wird die echte Seite frisch aus der Entscheidung heraus gebaut.

Umfang und Nicht-Ziele

• Loft produziert Antworten, keine Auslieferungsgegenstände: keine Laufzeit, keine Zustandsdateien, nichts, was immer läuft.
• Es diagnostiziert nicht (Debugger), kartiert keinen Nebel (/oh-my-claudecode:ask-navigator), genehmigt nicht seine eigene Antwort (die Reaktion des Kapitäns ist die einzige Abnahme).
• Es ersetzt keine Naht-Abnahme: Eine geloftete UI zeigt die Form; die Testnähte dafür werden weiterhin bei C2 abgenommen.

Abschlussdefinition

Der Kapitän reagierte, die Antwort sitzt dort, wo die Entscheidung lebt, das Artefakt sitzt auf seinem Branch – und keine Zeile des Artefakts befindet sich in main.