Bietet Beweisfragen, Überprüfungskriterien, Fehlersignale und eine praktische Validierungsliste für Produktprinzipien. Es legt Annahmegrenzen und beobachtbare Fehlerinformationen fest und hält gleichzeitig umgebungsspezifische Grenzen konfigurierbar.
Paketstatus: Referenzkontext bereit für menschliche Überprüfung. Der Vertrag und die Testszenarien sind vollständig, es wird jedoch nicht behauptet, dass eine übernehmende Implementierung diese bestanden hat.
Entscheidung
Für Produktprinzipien wird ein versioniertes Produktbrief mit benannten Beweisverantwortlichen übernommen. Behandle den Block als Release- und Regressionsvertrag, der aus repräsentativen positiven, Grenz-, Ablehnungs-, Fehler- und Wiederherstellungsfällen aufgebaut ist. Dieses Paket ist ein Referenzvertrag: Das übernehmende Team muss numerische Grenzen, Anbieter, Rechtsgebiete und operative Verantwortliche aus Beweisen in seiner eigenen Umgebung auswählen.
Umfang
- Die Akteure, Eingaben, Ausgaben, Zustände, Richtlinien- oder Schemaversionen und extern sichtbaren Ergebnisse der Produktprinzipien, die durch diesen Testblock beschrieben werden.
- Primäre und alternative Schnittstellen, Hintergrundarbeiten, Caches, Integrationen, Supportpfade und Beweise, die dieselbe Grenze auslösen können.
- Übernahmespezifische Konfiguration, Rollout, Wiederherstellung und Verifikationsverantwortlichkeiten, die benötigt werden, um die Referenz sicher anzuwenden.
Außerhalb dieses Blocks
- Die Wahl eines universellen Anbieters, Frameworks, Rechtsgebiets, numerischen Schwellenwerts, Aufbewahrungszeitraums oder Service-Level-Objektivs für jeden Übernehmer.
- Die Behauptung, dass verpackte Szenarien gegen eine nachgelagerte Implementierung ausgeführt wurden oder dass diese Referenz eine rechtliche, Sicherheits- oder Barrierefreiheitszertifizierung gewährt.
Vertrag
- Unterscheide beobachtete Beweise, explizite Annahmen, gewählte Einschränkungen und offene Fragen, damit eine Vermutung nicht stillschweigend zur Anforderung wird.
- Benenne Zielakteure, Situationen, Aufgaben, Ausschlüsse, aktuelle Alternativen, erwartetes Ergebnis und messbares Signal.
- Halte MVP-Verpflichtungen, Nicht-Ziele, spätere Optionen und irreversible Entscheidungen in separaten Listen mit Änderungsbegründung.
- Weise Überprüfungsdaten und Ungültigkeitssignale materiellen Annahmen zu, anstatt Entdeckungen als dauerhaft abgeschlossen zu behandeln.
- Dokumentiere Fixture-Version, Umgebung, Konfiguration, beobachtetes Ergebnis und Beweisort für jeden entscheidungsrelevanten Lauf.
- Trenne Produktfehler, Abhängigkeitsfehler, Testinfrastrukturfehler und nicht schlüssige Beweise in Berichten.
- Formuliere jedes Prinzip als konkrete Entscheidungspräferenz mit Umfang, Begründung, Gegenbeispiel, Kompromiss und beobachtbarer Auswirkung statt als unbewerteten Slogan.
- Definiere Prioritäten bei Konflikten zwischen Prinzipien und überprüfe reale Produktentscheidungen daran, sodass Ausnahmen und geänderte Beweise das aufgezeichnete Prinzip bewusst aktualisieren.
Implementierungsleitfaden
- Erstelle den kleinsten deterministischen Fixture-Satz, der Risikoklassen abdeckt, und füge Produktionsfälle erst nach datenschutzsicherer Überprüfung hinzu.
- Modelle Eingaben, Ausgaben, Akteure, Zustände, Invarianten, Nebeneffekte und Beweise der Produktprinzipien, bevor Framework- oder Anbieterdetails ausgewählt werden.
- Speichere die anwendbare Version des Produktprinzipienvertrags oder der Richtlinie mit materiellem Zustand, damit Migrationen, Wiedergabe und Supportentscheidungen nachvollziehbar bleiben.
- Führe den Pfad hinter kontrolliertem Rollout ein, vergleiche erwartete und beobachtete Ergebnisse und halte eine getestete Wiederherstellungsroute bereit, bis Übernahmebeweise vollständig sind.
Fehlerbehandlung und Schutzmaßnahmen
- Wenn Beweise dem Brief widersprechen, markiere die betroffene Entscheidung als ungeklärt und verhindere, dass abhängiger Umfang als genehmigt behandelt wird.
- Ungültiger oder widersprüchlicher Produktprinzipienzustand wird abgelehnt oder isoliert; die Implementierung schätzt niemals einen Wert, der Autorität erweitert oder eine Wirkung dupliziert.
- Wiederholungen sind begrenzt und verwenden dauerhafte Identität; nach Erschöpfung erreicht die Arbeit einen überprüfbaren Endzustand mit verantwortlichem Eigentümer.
Verifikation und Betrieb
- Führe die Suite zweimal aus einem sauberen Zustand aus und bestätige, dass Reihenfolge, Wiederholungen und parallele Ausführung das Urteil nicht verändern.
- Überwache Erfolg, Ablehnung, Validierungsfehler, Abhängigkeitsfehler, Wiederholungsermüdung und Wiederherstellung der Produktprinzipien nach Vertragsversion ohne sensible Nutzlastdimensionen.
- Führe gepaarte positive und negative Fixtures nach Richtlinien-, Schema-, Abhängigkeits-, Migrations- oder Grenzänderungen erneut aus und bewahre die resultierenden Beweise auf.
Übernahmeannahmen
- Namen und Werte im Beispiel sind ein konkretes Fixture, keine universellen Standardwerte; Übernehmer ersetzen sie durch dokumentierte Beweise und Verantwortlichkeiten.
- Das übernehmende System kann authentifizierte Identität, dauerhafte Operationen oder Versionsaufzeichnungen, begrenzte Telemetrie und einen kontrollierten Änderungsweg bereitstellen.
Die ausführungsähnlichen Beispiele in diesem Paket sind Fixtures und Akzeptanzverträge. Führe den Collection Validator aus, um Struktur und Metadaten zu prüfen, übersetze und führe dann die Szenarien im Ziel-Repository aus, bevor Implementierungsbeweise aufgezeichnet werden.