Aster-mck/product-prd-prototype

Produkt-PRD-Prototyp

Verwenden Sie diesen manuellen Workflow, um Produktabsicht, laufende UI-Beweise, Prototypzustände, kommentierte Screenshots, Quellcode-Landmarken und eine AI-umsetzbare PRD zu verbinden.

Ändern Sie den Quellcode der Benutzeranwendung nicht, es sei denn, sie bitten ausdrücklich um eine Implementierung. Erstellen Sie Prototyp-Artefakte in einem isolierten Arbeitsordner und speichern Sie die endgültigen Ergebnisse unter outputs/.

Erfordert zuerst die Auswahl des Liefermodus

Behandeln Sie die Auswahl des Liefermodus als blockierende erste Hürde. Vor der Seitenentdeckung, dem Quellcode-Lesen, Produktfragen, Prototyp-Arbeiten oder PRD-Arbeiten:

1. erkennen Sie, ob der Benutzer explizit einen der folgenden Modi ausgewählt hat;
2. falls nicht, präsentieren Sie die Modus-Optionen und warten Sie auf die Auswahl des Benutzers;
3. wählen Sie nicht stillschweigend einen Standard und setzen Sie den Workflow erst fort, nachdem ein Modus bestätigt wurde;
4. erfassen Sie den bestätigten Modus in page-map.md, manifest.md und in jedem PRD oder Auditbericht.

Verwenden Sie diese Auswahlaufforderung:

开始前请选择本次交付模式：

A. 原页面交互原型
适合还没有明确新增/修改需求时；先高保真复刻当前页面及边界内的原有交互，不设计新需求。

B. 局部需求原型
适合已经有明确需求；高保真还原完整页面 UI，只完整设计和验证本次新增/修改流程。

C. 全量高保真原型
适合需要原页面及需求相关交互全部按定义边界完整复刻和验证。

D. 仅输出 PRD
完成页面分析、需求规则、连线标注图和 AI 可实施文档，不制作可点击原型。

E. 保真度审计
检查现有实现或原型与运行页面的差异，输出带连线的差异标注图，不主动设计或实现。

Wenn der Benutzer keine neue oder geänderte Anforderung angegeben hat, empfehlen Sie A. Originaler Seiteninteraktionsprototyp, bestehen aber dennoch auf expliziter Bestätigung.

Optionales Produktdesign-Enhancement einbinden

Lesen Sie nach der Bestätigung des Liefermodus und vor der Seitenentdeckung references/product-design-integration.md. Behandeln Sie Produktdesign als optionales, automatisch ausgewähltes Enhancement, niemals als Laufzeitabhängigkeit.

• Erkennen Sie Produktdesign nur anhand der im aktuellen Session verfügbaren Fähigkeiten. Prüfen Sie niemals einen Installationspfad, Plugin-Cache oder eine Version.
• Kündigen Sie ein automatisch ausgewähltes Enhancement kurz im Kommentar an und fahren Sie ohne Bestätigungsaufforderung fort, wenn es den Umfang oder externen Zustand nicht ändert.
• Wenn die anwendbare Produktdesign-Fähigkeit nicht verfügbar oder inkompatibel ist oder fehlschlägt, fahren Sie mit dem nativen Fallback fort. Ihr Fehlen ist kein Fehler und kein Grund, die Lieferhürden zu senken.
• Fragen Sie, bevor eine Aktion den Umfang erweitern, extern veröffentlichen oder teilen, Anwendungsquellcode ändern oder eine wesentlich andere Designrichtung einführen würde. Installieren Sie das Produktdesign-Plugin nicht und schlagen Sie es nicht vor, es sei denn, der Benutzer hat ausdrücklich danach gefragt.
• Behalten Sie die Autorität dieser Fähigkeit für den Liefermodus, die Grenze, stabilen IDs, Anmerkungen, PRD, Ausgabevertrag, Verifikationsstatus und endgültige Validierung.

Originaler Seiteninteraktionsprototyp

• Verwenden Sie, wenn der Benutzer eine Seite identifiziert, aber keine neue oder geänderte Anforderung definiert hat.
• Reproduzieren Sie die aktuelle Seite, ihre sichtbaren Zustände und jede vorhandene Interaktion innerhalb der deklarierten Seitengrenze.
• Erfinden Sie keine Produktziele, vorgeschlagenen Zustände, Änderungsregeln oder Implementierungsanforderungen.
• Liefern Sie die hochpräzise interaktive Basislinien-Prototyp, Interaktionsinventar, Fidelity-Nachweise, mit Linien verbundene kommentierte Screenshots, Anmerkungskarte und Manifest.
• Stoppen Sie, nachdem der Originalseiten-Prototyp geliefert wurde. Beginnen Sie mit dem Design der Anforderungen erst, nachdem der Benutzer später eine Anforderung bereitstellt und einen anforderungsorientierten Modus auswählt.

Eingeschränkter Prototyp

• Reproduzieren Sie die gesamte Zielseiten-UI mit dem gleichen hohen Fidelity-Standard, der von jedem anderen Modus verwendet wird.
• Reproduzieren und verifizieren Sie die neuen oder geänderten Interaktionsabläufe im Umfang vollständig.
• Erfassen Sie vorhandene Interaktionen außerhalb des angeforderten Ablaufs und bewahren Sie deren sichtbare Steuerelemente; simulieren oder dokumentieren Sie deren Grenze, ohne abhängige Seiten zu klonen.
• Liefern Sie einen interaktiven Prototyp, mit Linien verbundene kommentierte Screenshots, PRD und eine AI-Übergabe.

Vollfidelity-Nachbildung

• Nur verwenden, wenn der Benutzer explizit um vollständige Seitenreplikation, alle Interaktionen oder 1:1-Fidelity bittet.
• Reproduzieren und verifizieren Sie jede vorhandene Interaktion innerhalb der definierten Seitengrenze.
• Liefern Sie die gleichen Artefakte wie der Eingeschränkte Prototyp mit vollständigen Abdeckungsnachweisen.

Nur PRD

• Lokalisieren und verstehen Sie die Seite, definieren Sie Änderungen und schreiben Sie eine entscheidungskomplette PRD.
• Erstellen Sie keinen anklickbaren Prototyp, es sei denn, dies ist zur Behebung von Unklarheiten erforderlich.
• Liefern Sie dennoch hochpräzise kommentierte Screenshots mit sichtbaren Verbindungslinien, die auf jeden Anforderungsort oder Ergebniszustand zeigen, der von der PRD verwendet wird.

Fidelity-Audit

• Vergleichen Sie eine vorhandene Implementierung oder einen Prototyp mit der laufenden Seite.
• Melden Sie Beweise, Unterschiede, Interaktionsabdeckung, genaue Blocker und hochpräzise, mit Linien verbundene kommentierte Vergleichs-Screenshots; entwerfen oder implementieren Sie nichts neu, es sei denn, es wird angefordert.

Universelle visuelle Liefer-Gates anwenden

Wenden Sie diese Gates auf jeden Modus an. Der Liefermodus ändert den Interaktionsumfang und den Dokumentumfang; er senkt niemals die UI-Fidelity oder Anmerkungsqualität.

Hochpräzise UI ist obligatorisch

• Verwenden Sie die laufende Seite im exakten Ziel-Viewport als visuelle Quelle der Wahrheit für die vorhandene UI.
• Gleichen Sie die gesamte sichtbare Seitengeometrie, Typografie, Farben, Assets, Abstände, Rahmen, Radien, Overlays, fixierte Bereiche, Scrollen und Textumbruch ab, die für den ausgewählten Modus erforderlich sind.
• Reproduzieren Sie die gesamte Zielseiten-UI in den Modi Originaler Seiteninteraktionsprototyp, Eingeschränkter Prototyp und Vollfidelity-Nachbildung; schneiden Sie den Prototyp nicht auf die geänderte Komponente zu.
• Verwenden Sie im Nur-PRD-Modus die laufende Seite oder eine verifizierte hochpräzise Reproduktion als Basis für kommentierte Anforderungs-Screenshots, auch wenn kein anklickbarer Prototyp erforderlich ist.
• Verwenden Sie im Fidelity-Audit-Modus laufende Seiten- und Implementierungsnachweise im gleichen Viewport; ersetzen Sie Nachweise nicht durch eine ungefähre Neuzeichnung.
• Bewahren Sie nicht kommentierte Referenz- und Differenzerfassungen unter work/<slug>/evidence/ auf; sie sind Verifikationsnachweise, keine endgültigen Übergabe-Screenshots.
• Markieren Sie ein Ergebnis nicht als endgültig, während die Basislinie der vorhandenen Seite nur Quellenabgeleitet, Screenshot-abgeleitet oder Nur-Konzept ist. Melden Sie Hochpräzise Verifizierung blockiert und fordern Sie die fehlende Laufzeit, Daten, Schriftart, Asset oder Plattformvoraussetzung an.

Mit Linien verbundene Anmerkungen sind obligatorisch

• Jeder endgültige Screenshot, der unter outputs/<slug>/ geliefert wird, muss Anmerkungskarten sowie sichtbare Verbindungslinien zum genauen UI-Trigger, geänderten Bereich, Ergebniszustand oder auditierten Unterschied enthalten.
• Eine separate Seitenliste ohne sichtbare Verbindungslinien ist kein kommentierter Screenshot und darf nicht geliefert werden.
• Verwenden Sie eine SVG-line, polyline oder path in einer separaten nicht interaktiven Überlagerung. Jeder Verbinder muss in einem gefüllten oder kontrastreichen Kreismarker enden, der seine sichtbare Sequenznummer enthält. Einfache Punkte, leere Ringe, Pfeile oder nicht nummerierte Endpunkte sind ungültig.
• Nummerieren Sie Anmerkungen beginnend mit 1 in jedem Screenshot. Nummern müssen positive Ganzzahlen, eindeutig und aufeinanderfolgend ohne Lücken oder Duplikate sein.
• Platzieren Sie den nummerierten Kreis auf dem exakten UI-Ziel – nicht neben der Anmerkungskarte, auf halbem Weg entlang des Verbinders oder im nahen Leerraum.
• In den Anforderungsmodi B, C und D muss das Ziel das tatsächliche UI-Steuerelement, der Bereich oder der Ergebniszustand sein, der hinzugefügt oder geändert wird. In Modus A zielen Sie auf den genauen vorhandenen Interaktionsauslöser oder das Ergebnis. In Modus E zielen Sie auf den genauen auditierten Unterschied.
• Wenn eine Anmerkung mehrere verwandte Ziele beschreibt, wiederholen Sie dieselbe Sequenznummer an jedem Verbinder-Endpunkt, der mit dieser Karte verbunden ist, oder teilen Sie unabhängige Ziele in separate nummerierte Anmerkungen auf.
• Wenn eine Überlagerung den ursprünglichen Auslöser verbirgt, verbinden Sie sich mit dem sichtbaren Ergebnis oder der primären Aktion und erklären Sie den Übergang in der Anmerkung.
• Halten Sie die Verbinder im exportierten PNG sichtbar, nicht nur in einer nicht erfassten DOM-Schicht.
• Speichern Sie outputs/<slug>/annotation-map.json, das jeden endgültigen Screenshot und jede Anmerkungs-ID auf ihre Sequenz, den nummerierten Kreispunkt, die Zielrolle und die Zielkoordinaten, den Selektor oder den benannten Bereich abbildet.
• Legen Sie keine obligatorische Anzahl von Anmerkungen, Linien oder Zeichenbeschränkung fest; lösen Sie Dichte durch Layout, Gruppierung, Verbinderführung und zusätzliche Screenshots.

Die Seiten- und Interaktionsgrenze definieren

Verwenden Sie diese Standardgrenze, es sei denn, der Benutzer erweitert sie:

• die Zielseite, ihren scrollbaren Inhalt, fixierte Bereiche, bedingte Zustände und Overlays der ersten Ebene, die direkt von ihr geöffnet werden, einschließen;
• verschachtelte Steuerelemente innerhalb eines Overlays im Umfang einschließen;
• für die Navigation zu einer anderen Geschäftsseite den Auslöser, die Route/Parameter und den sichtbaren Übergang verifizieren, aber das Ziel nicht klonen, es sei denn, es gehört zum angeforderten Ablauf;
• Zahlungen, Karten, Medienauswähler, Tastaturen, Kundenservice, Berechtigungen und andere Plattformfunktionen als explizite Fähigkeitsgrenzen behandeln, wenn sie nicht im eigenständigen Prototyp ausgeführt werden können;
• niemals zulassen, dass eine Navigationskette die Aufgabe stillschweigend auf die Reproduktion des restlichen Produkts erweitert.

Erfassen Sie die Grenze und jeden explizit eingeschlossenen nachgelagerten Ablauf in work/<slug>/page-map.md.

Stabile Anforderungs-IDs verwenden

Weisen Sie stabile Bezeichner zu und verwenden Sie diese in der Seitenkarte, den Prototyp-Zustands-URLs, Anmerkungen, PRD, Implementierungsnotizen und Akzeptanzkriterien wieder:

• REQ-01: Produktanforderung oder -ziel;
• INT-01: Interaktion oder Verhalten;
• STATE-01A: beobachtbarer Zustand einer Interaktion;
• AC-01-01: testbares Akzeptanzkriterium.

Der Modus Originaler Seiteninteraktionsprototyp erfordert INT- und STATE-IDs für das aktuelle Verhalten, erfordert jedoch keine erfundenen REQ- oder AC-IDs. Anforderungsorientierte Modi verwenden alle anwendbaren ID-Typen.

Eine Anmerkung kann eine Interaktion oder mehrere verwandte Interaktionen beschreiben. Legen Sie keine obligatorische Anzahl von Anmerkungen, Linien oder Zeichenbeschränkung fest. Halten Sie Screenshots durch Layout, Gruppierung, Hierarchie und zusätzliche Zustandsbilder lesbar, wenn hilfreich. Legen Sie Implementierungsdetails in die PRD, anstatt zu verlangen, dass jedes Detail in den Screenshot passt.

Verifikationsstatus ehrlich verwenden

Klassifizieren Sie Beweise für jeden relevanten Zustand:

• Verifiziert: gegen das laufende Ziel ausgeführt und im Ziel-Viewport verglichen;
• Quellenabgeleitet: aus Code, Styles und Assets abgeleitet, aber nicht mit der Laufzeit verglichen;
• Screenshot-abgeleitet: aus bereitgestellten Screenshots rekonstruiert; Verhalten stammt aus Code oder Produktentscheidungen;
• Nur-Konzept: ohne ausreichende Laufzeit-, Screenshot- oder Quellennachweise vorgeschlagen.

Nennen Sie einen vorhandenen Zustand nur dann 1:1, wenn er Verifiziert ist und die Fidelity-Gates bestanden werden. Eine fehlende Laufzeit verhindert keinen Entwurf oder eine funktionierende PRD, blockiert jedoch die endgültige Lieferung in jedem Modus, und die Ausgabe muss den korrekten Status tragen.

Kontextbudget-Modus

Wenn das Repository groß ist, eine Zieldatei 800 Zeilen überschreitet oder die Seite viele Komponenten/Interaktionen hat, lesen Sie references/large-project-mode.md und folgen Sie dessen geschichtetem Entdeckungsworkflow. Beginnen Sie mit Routen, Metadaten und rg; laden Sie keine großen Dateien vor der Bestätigung des Ziels.

Workflow

1. Die Modushürde passieren

Bestätigen Sie den Liefermodus, bevor Sie Entdeckungs- oder Produktionsmaßnahmen ergreifen. Wenn der Modus nicht explizit ist, fragen und warten Sie. Wenn der Benutzer keine definierte Anforderung hat, empfehlen Sie den Originalen Seiteninteraktionsprototyp, ohne ihn automatisch auszuwählen.

Wählen Sie nach der Bestätigung die optionale Enhancements-Route mit references/product-design-integration.md aus und erfassen Sie sie. Prüfen Sie die Zielseite vor diesem Punkt nicht.

2. Die Zielseite lokalisieren und bestätigen

Akzeptieren Sie einen Seitentitel, eine Geschäftsbeschreibung, einen Screenshot, einen Browserzustand, eine URL, eine Route, einen Mini-Programm-Pfad oder einen Dateipfad. Durchsuchen Sie Routenmanifeste, Seitenregister, Titel, sichtbaren Text und wahrscheinliche Dateinamen, bevor Sie den Benutzer fragen.

Wenn mehrere Kandidaten übrig bleiben, zeigen Sie eine prägnante Kandidatenkarte mit Pfad, passenden Nachweisen und Empfehlung an. Wenn ein Kandidat überwältigend richtig ist, benennen Sie ihn als Arbeitsziel und fahren Sie fort, es sei denn, er wird korrigiert.

3. Die Seitenkarte erstellen

Lesen Sie die bestätigte Seite, relevante Styles, Routenkonfiguration, importierte Kindkomponenten und teilnehmende Overlays. Erfassen Sie:

• Informationsarchitektur und Geschäftsmodule;
• sichtbare und bedingte Elemente;
• Interaktionsinventar und Seitengrenze;
• aktuelle Handler, Zustandsfelder, Komponenten, APIs und Routenparameter, wenn sichtbar;
• Standard-, Lade-, Erfolgs-, Fehler-, Leer-, Validierungs-, Berechtigungs-, Deaktivierungs-, Entfernungs- und Grenzzustände, wenn anwendbar;
• Verifikationsstatus und ungelöste Fakten.

Erstellen Sie:

work/<slug>/page-map.md
work/<slug>/interaction-matrix.md

Erfassen Sie den ausgewählten Ausführungspfad und die Enhancements-Entscheidung in page-map.md. Halten Sie Produktdesign-Nachweise innerhalb derselben deklarierten Seitengrenze.

Verwechseln Sie nicht einen ungelösten Fakt mit einer vorgeschlagenen Produktentscheidung. Lösen Sie Fakten nach Möglichkeit aus der Laufzeit oder Quelle; fragen Sie nur nach hochwirksamen Produktfragen, die nicht abgeleitet werden können.

4. Produktabsicht, Umfang und Änderungen definieren

Beschreiben Sie im Modus Originaler Seiteninteraktionsprototyp nur das aktuelle Verhalten und leiten Sie keine neue Anforderung ab. Bestätigen oder schließen Sie für anforderungsorientierte Modi das Ziel, den Benutzer, das Szenario, die erforderlichen Aktionen, die erforderlichen Zustände und den ausgewählten Liefermodus. Trennen Sie:

• aktuelles Verhalten;
• Zielverhalten;
• Verhalten, das unverändert bleiben muss;
• nicht umfasste Verhalten;
• Daten/API-Annahmen und Abhängigkeiten.

Weisen Sie REQ-, INT-, STATE- und AC-IDs zu, sobald der Umfang stabil wird. Identifizieren Sie für den Modus Eingeschränkter Prototyp klar, welche Interaktionen eine vollständige Implementierung und Verifikation erfordern.

5. Die UI-Richtung bestätigen

Lesen Sie references/ui-design-guidance.md. Hochpräzise Reproduktion der gesamten vorhandenen Seite ist in jedem Modus obligatorisch. Überspringen Sie im Modus Originaler Seiteninteraktionsprototyp Fragen zur vorgeschlagenen Designrichtung und reproduzieren Sie die aktuelle laufende UI, ohne sie neu zu gestalten.

Verwenden Sie diese Priorität:

1. explizite Produktpräferenz;
2. aktuelles Projekt-UI-Styling;
3. eine geschäftsangemessene moderne Richtung, wenn das Projekt-Styling nicht erforderlich oder nicht verfügbar ist.

Wenn das Styling unbekannt ist, fragen Sie, ob das aktuelle Projekt befolgt werden soll. Wenn der Benutzer nicht antwortet, verwenden Sie standardmäßig das Projekt-Styling und erfassen Sie die Annahme.

6. Den Prototyp erstellen

Lesen Sie vor der Reproduktion einer vorhandenen laufenden Seite references/pixel-pe...