perhapsspy/zweckorientiertes-Design

Zweckorientiertes Design

Auftrag und Ausgang

Wähle die kleinste vertretbare Richtung für eine materiell offene Produkt- oder Implementierungsplanungsentscheidung, bevor die Lösungsstruktur festgelegt ist. Der Zweck definiert, was Erfolg bedeutet; festgelegte Benutzerentscheidungen, Autorität sowie erforderliche Sicherheits-, Rollback-, Eigentümer- und Betriebsgrenzen binden die Antwort und sind niemals Alternativen.

Ende mit einer vorläufigen Richtung, der kleinsten Prüfung, die eine tatsächlich offene Wahl ändern könnte, oder einer blockierenden Frage. Wenn keine materielle Richtung mehr offen ist, sag dies kurz und übergib ohne Alternativen zu erfinden.

Entscheidungsvertrag

• Gib nur den Zweck und den beobachtbaren Erfolg an, der zur Unterscheidung der Wahl erforderlich ist.
• Trenne entscheidungsrelevante Eingaben in LOCKED, EVIDENCE, ASSUMPTION und OPEN. Befördere niemals eine gesperrte Entscheidung, explizite Einschränkung, abgelehnten Umfang oder einen durch Beweise geklärten Punkt in OPEN. Eine fehlgeschlagene Prüfung darf nur einen ungelösten Mechanismus ändern, nicht die gesperrte Produktbedeutung.
• Behandle bestehende Implementierung, Präzedenzfälle, Standardeinstellungen und Dringlichkeit als Beweise, es sei denn, sie sind explizit autoritativ. Vergleiche nur Alternativen, die Bedeutung, Verantwortung, persistenten Zustand, Richtlinie, Lebenszyklus, öffentlichen Vertrag, akzeptiertes Risiko oder schwer umkehrbare Kopplung materiell ändern.
• Wähle die kleinste ausreichende Richtung. Füge keine Eigentümer, Prozesse, Rollback-Mechanismen, Plattformen, zukünftige Programme oder offenen Entscheidungen hinzu, es sei denn, die Quelle oder die gewählte Richtung erfordert sie.

Übergabe

Verwende zuerst source-owner-audit, wenn die vorhandene Autorität unbekannt ist. Übergib die geklärte Umsetzung – Codefluss, Zustand, Sequenzierung, Schnittstellen, Fehlerbehandlung und Implementierungsreihenfolge – an structure-first. Übergib die geklärte Ausdrucksweise und Verpackung an tighten-docs.

Gib eine präzise Entscheidungsübergabe zurück: Richtung, entscheidungsändernde Grundlage, gesperrte Grenzen, reale Annahmen oder offene Entscheidungen sowie die nächste entscheidende Prüfung oder den zugehörigen Workflow. Füge eine Grenze nur hinzu, wenn sie die gewählte Richtung einschränkt.

Finale Reduktion

Überprüfe nur den Umfang, die Zusagen, die Annahmen und die offenen Entscheidungen, die durch deine Antwort eingeführt wurden. Entferne alles, was der Zweck, die gesperrten Grenzen, die Autorität, die Beweise oder die gewählte Richtung nicht erfordert. Führe Alternativen nur zusammen, wenn ihre Produktbedeutung und die erforderlichen Grenzen identisch sind.

Dieser Durchlauf kann Umfang, Zusagen, Annahmen, offene Entscheidungen oder Übergaben reduzieren, aber nicht erzeugen, und darf niemals die LOCKED-Bedeutung wieder öffnen. Wenn eine fehlende zwingende Grenze aufgedeckt wird, erkläre diese Grenze als erforderlich statt optional. Bewahre Komplexität, die für Sicherheit, Rollback, Eigentum, Betrieb oder einen nachgewiesenen Fehlermodus notwendig ist.