← Alle Semantic Contracts

Sokratische Code-Theorie-Rekonstruktion

Die 'Theorie' eines Programms aus dem Quellcode durch rekursive Fragenverfeinerung rekonstruieren

Ein Semantic Contract: Vokabular, das dein Projekt selbst mitliefert — zum Einsetzen in deine CLAUDE.md / AGENTS.md.

    Die "Theorie" eines Programms (Naur 1985) aus dem Quellcode durch rekursive Fragenverfeinerung rekonstruieren.

  • Mit 5 Wurzelfragen starten: Q1 Problem/Nutzer, Q2 Spezifikation, Q3 Architektur, Q4 Qualitätsziele, Q5 Risiken.
  • Die zweite Baumebene ist FIX, nicht frei. Jeder Lauf erzeugt genau diese Knoten, in dieser Reihenfolge, auch wenn ein Knoten nur ein [OPEN]- oder [ANSWERED: not applicable]-Blatt hat:
  • - Q1.1-Q1.6: Produktidentität, primäre Nutzer, Kanäle, Warum-gebaut, Erfolgsmetriken, Segmentpriorität

    - Q2.1-Q2.6: Akteure, Use-Case-Katalog, System-Specs pro Schnittstelle, Daten-/Entity-Modell, Akzeptanzkriterien, übergreifende Geschäftsregeln

    - Q3.1-Q3.12: die zwölf arc42-Kapitel, in arc42-Reihenfolge

    - Q4.1-Q4.8: die acht ISO/IEC-25010-Merkmale; plus Q4.9: welches Merkmal Priorität hat

    - Q5.1-Q5.5: technische Schuld, Sicherheitsrisiken, Betriebsrisiken, Abhängigkeits-/Supply-Chain-Risiken, Skalierungs-/Performance-Risiken

  • Unterhalb der fixen zweiten Ebene adaptiv und code-getrieben zerlegen; ein Knoten ist nur dann ein Blatt, wenn er aus einer konkreten file:line-Evidenz beantwortbar ist (ein Verzeichnis ist zu grob — weiter zerlegen) oder definitiv [OPEN] markiert werden kann. Die Tiefe folgt der Code-Dichte: ein kleiner Bounded Context ergibt einen flachen Baum, ein großer einen tiefen, gedeckelt auf vier Ebenen unter einem fixen Knoten. Die Tiefe variiert zwischen Läufen — erwartet.
  • Q-IDs sind stabil: Q3.7 ist in jedem Lauf die Verteilungssicht, sodass Bäume verschiedener Läufe Knoten für Knoten verglichen werden können.
  • Jedes Blatt ist [ANSWERED] (mit file:line-Evidenz) oder [OPEN] (mit Kategorie, zuständiger Rolle und Begründung, warum es aus dem Code nicht beantwortbar ist).
  • Qualität ist nicht vollständig Team-Wissen. Qualitätsszenarien für den Q4-Ast und arc42-Kapitel 10 aus messbarem Code-Verhalten ableiten — literale Schwellwerte, Timeouts, Budgets, den Threat-Katalog und das Test-Konzept aus Q3.8 — als [ANSWERED] mit file:line; Zielwerte nie erfinden. Nur das Qualitätsziel-Ranking (Q4.9) ist [OPEN]. arc42-Kapitel 10 trägt die ableitbaren Szenarien, nie nur einen [OPEN]-Verweis. Kapitel 1.2 nennt nur die obersten 3-5 Qualitätsziele; Kapitel 10 deckt alle acht Merkmale ab — jeden Kapitel-10-Eintrag als Konkretisierung eines Kapitel-1.2-Top-Ziels oder als abgeleitet markieren.
  • Offene Fragen sind das Übergabedokument: immer einen Abschnitt pro Rolle erzeugen (Product Owner, Architekt, Entwickler, Domänenexperte, Operations), auch wenn ein Abschnitt leer ist ("Keine offenen Fragen für diese Rolle").
  • Zwei-Phasen-Workflow: Phase 1 baut den Baum; das Team beantwortet die offenen Fragen; Phase 2 synthetisiert Dokumentation aus dem beantworteten Baum.

Verwandte Anker