UI-Lab

UI-Lab: UX-Vorschläge

Ein UX-Vorschlag durchläuft drei Phasen:

1. Mocken – Nur Lab-Code ändert sich, auf der Plattform, die die Lab-Notizen des Projekts angeben. Der Eigentümer tippt durch die Optionen.
2. Runde abschließen – Die Runde wird getaggt und in docs/ux-history/ dokumentiert, ihre Lab-Dateien werden gelöscht.
3. Überführen – Nachdem der Eigentümer eine Option ausgewählt und einen Plan genehmigt hat, wird sie zum echten Bildschirm, mit ihrer gemeinsamen Logik und der anderen Plattform, falls die App eine hat.

Die Lab-Notizen des Projekts

Dieses Skill ist der Prozess; die Details jedes Projekts stehen in seiner .claude/ui-lab.md. Lese sie vor allem anderen. Sie enthält:

• Plattform: Welche Lab-App auf diesem Rechner verwendet wird (uname -s), ihre ID, wo der Lab-Code liegt und der Befehl, der einen Bildschirm öffnet;
• Optionsordner: Der Ordner und das Paket pro Plattform, und wo Strings abgelegt werden;
• Dateien: Das Theme oder die Farben, die ein Optionsbildschirm verwendet, und wohin sein State bei der Überführung wandert;
• Beispieldaten: Woraus die Optionen ihre Daten aufbauen;
• Fakes und Randfälle: Welche erfundenen Daten in dieser App nicht gezeigt werden können, und die zu prüfenden Fälle;
• Screenshots: Wie man einen pro Plattform erstellt;
• Überführen: Zielpfade, die Handhabung der anderen Plattform, zu aktualisierende Dokumente und die Release-Build-Befehle;
• wie das Lab selbst funktioniert (ein Dokument-Link).

Die Notizen haben Vorrang, wenn sie von diesem Skill abweichen. Wenn das Projekt keine .claude/ui-lab.md hat oder ihr etwas fehlt, was unten benötigt wird, frage den Eigentümer, anstatt zu raten, und füge die Antwort in die Notizen ein.

Phase 1: Mocken

Arbeite auf einem ux/<screen>-Branch, ausgehend vom aktuellen Branch, damit ein anderer Rechner die Runde pullen kann. Wenn der Baum nicht deine eigenen uncommitteten Änderungen enthält, frage vor dem Wechsel.

Ein Ordner pro Option

Jede Option lebt in einem eigenen Ordner (die Notizen sagen wo), damit sie einzeln gelöscht, wiederbelebt oder überführt werden kann. Sie liegt im Paket der Bildschirme, sodass die Überführung ein reiner Dateiverschiebung ist.

Datei	Enthält	Bei Überführung
<Screen>Option<B>	den Bildschirm, <Screen>Screen<B>(state, actions): Produktionsqualität (die Strings und das Theme der App, gemäß den Notizen) und frei von Lab-Typen	wandert in die App
<Screen>Option<B>State	State, den die App-Logik noch nicht erzeugt, geformt wie sie es tun würde	wandert dorthin, wo die Notizen es sagen
<Screen>Option<B>Lab	seine Beispieldaten, Fake-Verhalten, No-op-Aktionen und seinen LabOption-Wert mit dem, was es darüber faked	gelöscht
die Strings der Option, wenn die App String-Ressourcen verwendet (Namen und Ort gemäß den Notizen)	den neuen Text der Option	wandert in die App-Strings

• Neben dem Ordner (und den String-Dateien, wo Ressourcen nicht darin sitzen können) fügt eine Option eine Zeile hinzu: ihren Eintrag in der Liste ihres Bildschirms in LabScreens (<screen>OptionB,).
• Alles im Ordner ist private, außer dem Bildschirm, seinem State und dem LabOption-Wert, deren Namen die Option tragen, sodass Optionen nie kollidieren.
• Eine Option, die eine geänderte Version einer vorhandenen App-Komponente benötigt, verwendet eine eigene Kopie in ihrem Ordner.
• Beispieldaten stammen aus den Quellen, die die Notizen nennen, so wie sie sind, plus dem, was die Option in ihrer Lab-Datei hinzufügt. Erfinde keinen Text, wo die Notizen sagen, dass die Daten echt sind.

Schritte

1. Öffne den Bildschirm im Lab und betrachte current, den Bildschirm so, wie die App ihn jetzt hat.
2. Schreibe 2–3 unterschiedliche Richtungen als Optionen a, b, c nach current, jede mit einem einzeiligen Hinweis, was sie ändert.
3. Liste über jedem LabOption-Wert auf, was die Option faked: Daten, die der App-Logik fehlen, Verhalten, das nicht gebaut ist, und welche erfundenen Daten nicht gezeigt werden können (die Notizen listen die üblichen dieser App auf).
4. Prüfe die Randfälle, die die Notizen auflisten, sowie alles, was für den Bildschirm ungewöhnlich ist. Ein Fall, der das Design ändert, wird zu einer eigenen Option (a-rtl, a-dark).
5. Baue, öffne jede Option und betrachte einen Screenshot (Befehle in den Notizen; das Android-Emulator-Skill deckt Android-Geräte ab). Ein komplett schwarzer Screenshot von einem Telefon bedeutet, dass es gesperrt ist: bitte den Eigentümer, es zu entsperren.
6. Committe auf dem Branch und teile dem Eigentümer die Options-IDs (<screen> <option>), was jede faked, und das Gerät mit.

Wenn der Eigentümer bittet, eine Option zu ändern, wird die Änderung zu einer neuen Option in einem eigenen Ordner (b2 neben b). Optionen, die der Eigentümer ausschließt, bleiben bis zum Abschluss der Runde erhalten, damit der Tag der Runde sie alle enthält.

Phase 2: Runde abschließen

Wenn der Eigentümer eine Option ausgewählt oder alle abgelehnt hat:

1. Tage den letzten Commit der Runde, während noch jede Option darin ist, und pushe den Tag: git tag ux/<screen>/<yyyy-mm-dd> && git push origin ux/<screen>/<yyyy-mm-dd>. Der Tag hält den Code erreichbar, nachdem der Branch weg ist; eine zweite Runde am selben Tag erhält -2.
2. Schreibe docs/ux-history/<screen>/<yyyy-mm-dd>-<topic>.md im folgenden Format und verlinke es von dort, wo die Notizen es sagen (z. B. im Dokument des Bildschirms).
3. Lösche die Ordner, String-Dateien und LabScreens-Zeilen der anderen Optionen; die gewählte Option bleibt bis Phase 3.
4. Committe. Wenn alle Optionen abgelehnt wurden, endet die Runde hier: merge den Branch (die History-Datei ist seine einzige bleibende Änderung) oder lösche ihn, wie der Eigentümer es bevorzugt.

# <Screen> — <Thema> (<yyyy-mm-dd>, <Plattform>)

Tag: `ux/<screen>/<yyyy-mm-dd>`

## Optionen
- **a — <Name>**: <was sie ändert>. *Ausgewählt*, überführt in <Commit>.
- **b — <Name>**: <was sie ändert>. *Abgelehnt*: <Grund des Eigentümers, falls angegeben>.

## Was sie gefaked haben
- b: <was der Mock gezeigt hat, das die App noch nicht kann>.

## Wiederbeleben einer Option
    git checkout ux/<screen>/<yyyy-mm-dd> -- <Optionsordner> <String-Dateien>
Dann füge `<screen>Option<B>,` zu `LabScreens` hinzu.
Erstellt gegen <Komponenten und verwendete Beispieldaten> zum Stand des Tags. Compiler-Fehler nach der Wiederbelebung befinden sich in den Kopien und Beispieldaten der Option; behebe sie dort.

Wiederbeleben

Wenn der Eigentümer nach einer früheren Option fragt, folge ihrer History-Datei: Checke die Pfade vom Tag auf einen ux/<screen>-Branch aus, füge die LabScreens-Zeile hinzu, repariere, was im Optionsordner nicht mehr kompiliert, und öffne sie. Sie ist dann eine lebendige Option einer neuen Runde.

Phase 3: Überführen

Wenn die Runde mit einer ausgewählten Option abgeschlossen ist, betrete den Planmodus (EnterPlanMode) und präsentiere den Plan mit ExitPlanMode; der Eigentümer genehmigt ihn mit seinem Button. Der Plan umfasst:

• die Dateien, die verschoben werden, und den Bildschirm, den sie ersetzen;
• die Logikarbeit hinter jedem gefakten Element: die vorgeschlagenen State-, View-Model- oder Controller-Änderungen und ihre Tests;
• die andere Plattform, falls die App eine hat, wie die Notizen sagen;
• die Dokumente, die die Notizen zu aktualisieren sagen.

Nach Genehmigung, auf demselben Branch:

1. git mv die Bildschirmdatei der Option in die App (Ziel gemäß den Notizen), ersetze den alten Bildschirm und gib der Funktion oder View den Namen des Bildschirms.
2. Verschiebe ihre Strings in die der App, ohne das Präfix oder die Tabelle der Option.
3. Verschiebe ihren State dorthin, wo die Notizen es sagen, lasse die App-Logik ihn mit Tests erzeugen und verbinde die Aktionen.
4. Führe ihre kopierten Komponenten zurück in die Originale zusammen und lösche den Rest ihres Ordners und ihre LabScreens-Zeile; setze current des Bildschirms in LabScreens auf den überführten Bildschirm.
5. Baue Release mit den Befehlen der Notizen, bei dem jeder Verweis auf Lab-Code nicht kompiliert.
6. Erledige die Teile des Plans für die andere Plattform und die Dokumente und setze den überführenden Commit in die History-Datei der Runde.

Das Mergen des Branches liegt in der Entscheidung des Eigentümers.