Herunterbrechung des Grundkonzepts in baubare, verifizierbare Bausteine. Risiken zuerst, in durchgängigen Schnitten.
Bau-Backlog FK-01 ff. Erster Durchstich
1
Methodik
Risiko-first, vertikale Schnitte
vertikale Schnitte statt Schichten
Konfig vs. Code je Baustein trennen
§14-Beispiele als Akzeptanzkriterien
Wiederverwendung vor Neubau (Build-Gap)
Spike vor Vollausbau (bei hohem Risiko)
Referenz im Bestand lesen, keine API raten
Fundamente zuerst: FK-01 und FK-02 (sie tragen fast alles andere). Danach FK-03, dann FK-04/FK-05. FK-06 ist überwiegend Komposition vorhandener Bausteine.
Priorität je Effekt ← FieldRuleEngine (Tri-State-Slots)
Neu (Rahmen)
Befund-Block-Container: mehrere Aspekte unter einer Bedingung (heute nicht vorhanden)
Entwurfszeit-Konfliktanzeige (Engine überschreibt heute still)
bedingte Abschnitte/Reiter (kein Tab-/Section-Modell im Bestand)
Stufen-Ableitung f(Kategorie, Befund) als reine Ausgabe
Konfiguriert wird immer gegen den Befund, nie gegen die Stufe. Werkzeuge: Governance-Matrix (Entwurfszeit) und inhaltsgetriebener Simulator. interaktiver Prototyp
00b
FK-00 · Datenarchitektur
Datenarchitektur und Dynamik
Wohin geschrieben wird und wie sich alles gegenseitig beeinflusst. Speicher-Seite code-verifiziert.
Speicher (code-verifiziert)
Spalten zur Laufzeit auto-provisioniert (kein EAV)
Kern + Kategorie-Detail (1:1) je Top-Kategorie
Maßnahme = Kern + Detail je Typ
Nachricht: DtoMessage-Reuse, Folge via Self-Ref
Dynamik
Re-Evaluation bei jeder Änderung (Felder, Maßnahmenfelder, Zeit, Ort)
einpassig und zyklenfrei (Stufe als reine Ausgabe ist der Schutz)
Höchststufe als Ratchet für Bericht und Accountability
Irreversibilität
begonnene Maßnahmen und versendete Nachrichten bleiben (nie entfernt)
zwei Zonen: Vorschlag (reaktiv) vs. begonnen (monoton, append-only)
nicht mehr passende nur als „nicht mehr zutreffend" markiert
Umsetzung via ImmutableAfterState; Basis des Chrono-Berichts (§5)
Alles ist ein großer, datengetriebener Container sich gegenseitig beeinflussender Faktoren. Maßnahmen sind dabei selbst Mini-Container mit eigenen Feldern.
3
Absicherung
Erster Durchstich (Walking Skeleton)
Ein dünner durchgängiger Pfad durch die echten Mechanismen, bevor die Engines vollständig ausgebaut werden.
WS-1 · S0
Defekter Automat
Spine auf vorhandenen Bausteinen, ohne neue Engine: Datenobjekt, Maske, Versand, Erledigung.
WS-2 · S1
Türstörung
Kleinste Ausprägung der neuen Drehbuch-Engine: ein Befund-Block aktiviert eine MCL mit einem Schritt (Save-only Re-Evaluation).
Per-Aktion-Live-Status im Sofort-Bereich (Doppelanruf-Schutz)
Kein Neubau: Das Fundament (Field-Rules, Ableitungen, Live-Change) steht; neu ist nur die Umordnungs-Schicht der Oberfläche und der deklarative Reiter-Aufsatz.
10
FK-07 · code-verifiziert
Zuständigkeits-Resolver (Ort + Zeit)
Bestimmt zu einem Ereignis die zuständige Stelle und die Bereitschaft. Zwei Modi: Attribut-Kette (ohne Karte) und Geometrie (Punkt-in-Fläche, später).
Resolver-Klasse (rund 80% nach Vorbild PermissionSetResolver)
Punkt-in-Fläche (Karten-Modus) erst später: benötigt NetTopologySuite
Die Attribut-Variante ist ohne neue Geometrie-Abhängigkeit baubar; der Karten-Modus (Punkt-in-Fläche) bleibt ein später zuschaltbarer Modus.
11
FK-08 bis 12 · Ausbau
Ausbau: Vorstufen und Komposition
Bausteine mit niedrigem bis mittlerem Risiko, größtenteils Erweiterung oder Zusammenstellung vorhandener Mechanismen. Folgen nach dem kritischen Kern (FK-01 bis FK-07).
FK-11 Lage-Cockpit: offene Ereignisse im Überblick
FK-12 chronologischer, systemübergreifender Bericht (§5; baut auf FK-02)
Kein eigener kritischer Pfad: Diese Bausteine setzen auf dem Kern auf und lassen sich schrittweise nachziehen; FK-12 benötigt den Meldungscontainer aus FK-02.