Mosin112/build-prototype

Schritt 4 · Klickbarer Prototyp

Der Prototyp ermöglicht es Stakeholdern, die Verhaltensbäume zu fühlen, bevor die Entwicklung beginnt. Es ist eine Demonstration des Vertrags, kein Designspezifikation: Er muss jeden Zweig zeigen, einschließlich Fehler und Randfälle, nicht nur den Happy Path.

Zuerst lesen: die genehmigten Bäume in work/<item>/03-trees/, das Konzept, context/product.md und context/writing-style.md. Verwenden Sie ../../examples/price-alerts/04-prototype/index.html (relativ zu diesem Skill) als Referenzimplementierung der untenstehenden Struktur.

Anforderungen

1. Eine eigenständige Datei: work/<item>/04-prototype/index.html. Alle CSS und JS inline einbinden. Kein Build-Schritt, keine externen Anfragen außer optionalen Webfonts, damit sie von der Festplatte geöffnet, an einen Ticket angehängt oder als Link veröffentlicht werden kann.

2. Bildschirme: jeder eindeutige Zustand ist ein Element mit data-screen="<id>". Nur einer ist sichtbar. Die Navigation erfolgt über die eigenen Schaltflächen des Prototyps, wie im echten Produkt.

3. Szenario-Steuerung: ein Seitenbereich, klar vom Produkt-UI getrennt, mit Umschaltern für jeden while-Zustand und jede if-Bedingung in den Bäumen (verifiziert/unverifiziert, Limit erreicht, Benachrichtigungen aus, eine Preisbewegung simulieren …). Das Ändern eines Umschalters muss ändern, was das Produkt-UI tut, damit jeder Zweig erreichbar ist.

4. Coverage-Map: ein <script type="application/json" id="tree-coverage">-Block, der jede then- und and-Zeile jedes Baumes auf den Bildschirm abbildet, der sie demonstriert:

   {
     "trees": {
       "functional/price-alert-creation": [
         { "line": "then the alert is saved as active", "screen": "alerts" },
         { "line": "and the alert's direction is set to above or below the current price", "screen": "alerts" }
       ],
       "functional/price-alert-trigger": [
         { "line": "then no further notification is sent", "screen": null, "reason": "Not visible: absence of a notification" }
       ]
     }
   }
   

   screen: null ist nur mit einem reason erlaubt (Backend-only oder „nichts passiert“-Ergebnisse).

5. Sichtbares Coverage-Panel: die Coverage-Map im Seitenbereich als Checkliste der Baumzeilen rendern; durch Klicken auf eine Zeile springt man zu ihrem Bildschirm mit dem richtigen Szenario. Das macht den Prototypen zum Überprüfungswerkzeug.

6. Realistischer Text: die exakten Nachrichten aus den Bäumen verwenden. Beispieldaten als Beispieldaten markieren.

7. Branding: Design-Token aus context/product.md befolgen; andernfalls einen neutralen, barrierefreien Stil verwenden. Funktioniert bei Telefonbreite. Tastaturfokus sichtbar.

Überprüfung

Führen Sie python3 .pm-harness/pm_check.py prototype work/<item>/03-trees work/<item>/04-prototype/index.html aus. Es schlägt fehl, wenn eine Baumzeile in der Coverage-Map fehlt oder auf einen nicht existierenden Bildschirm verweist. Korrigieren Sie, bis es bestanden wird.

Gate

Führen Sie den PM durch den Journey-Baum im Prototypen, dann durch jeden von ihnen gewählten Zweig. Sammeln Sie Feedback. Wenn das Feedback das Verhalten ändert, aktualisieren Sie zuerst die Bäume, führen Sie die Baumüberprüfung erneut aus, und aktualisieren Sie dann den Prototypen. Wenn der PM zustimmt, setzen Sie stage: prototype in 01-idea.md und bieten Sie /pm-harness:create-eng-tickets an. Wenn das Team des PM für das endgültige Design Figma verwendet, sagen Sie, welche Bildschirme ein Designer übernehmen sollte.