@sigloch/contracts 9.1.0 → 10.0.0

package/dist/se/index.js

@@ -3,11 +3,11 @@
  * Single source of truth for SE ontology schemas across all projects.
  */
 /** Ontology schema version (element types + trace types). */
-export const ONTOLOGY_VERSION = '8.0.0'; // BREAKING (CR-SM-266a): drei Enums schrumpfen, und alle drei sind ENTFERNUNGEN. (1) ElementType 13 -> 12: `SESSION` entfaellt. (2) TraceType 7 -> 6: `produces` entfaellt. Beide trugen genau EIN Pattern (`SESSION -produces-> *`), und die Messung hat es widerlegt: 0 produces-Kanten und 0 SESSION-Knoten in ALLEN 9 aktiven Familie-Graphen, auch im graphcode-Selbstmodell nach 195 gegateten Versionen. Die reale Provenance lebt seit CR-GC-347 in `.graphcode/audit.jsonl` -- audit_trail/audit_stats lesen die DATEI, nie den Graphen; einziger Schreiber war ein toter Pfad (CR-195d in graph-api-core), Leser mit Wirkung keiner. Der urspruengliche CR-Entwurf hielt das Pattern fuer die Provenance-Kante und wollte es BEHALTEN ('Nicht-Befund'); die Zaehlung hat den Nicht-Befund kassiert -- Gate 1 verlangt fuer das Wiederaufmachen einer Entscheidung eine Messung, und hier war sie es. (3) Mit `produces` faellt `TraceCategory` und `Trace.category`. Das ist die wichtigste Haelfte: R-08 und R-18 haben `category === 'audit'` UEBERSPRUNGEN, also haette nach D5 jede Kante mit diesem selbstgesetzten Attribut die komplette Pattern-Matrix UND die Referenzintegritaet umgangen. Ein Attribut, das eine Strukturpruefung abschaltet, ist die Klasse aus CR-SM-263/-257; hier zusaetzlich der billige Zweitweg aus CR-GC-366, nur ohne Kante. Gemessen: 0 von 0 Traces aller 9 Graphen tragen `category` -- die Entfernung nimmt niemandem etwas weg. (4) ReqKind 7 -> 6: `negative` entfaellt. Ein Verbots-REQ ist auch eine Anforderung -- die Implementierung muss Regeln abfragen oder Sicherungen einbauen, das ist `functional`. Der Wert hatte NULL Leser (anders als risk/mitigation -> FM-01..03, pre/postcondition -> UC-05/06, non-functional -> NFR-01) und haette durch die neuen where-Praedikate per AUSLASSUNG erstmals Wirkung bekommen: er stand in keiner der vier Listen und waere nur noch per FCHAIN erfuellbar gewesen. Die sechs verbleibenden Werte partitionieren die where-Listen VOLLSTAENDIG. Migration `negative`: 3 REQs, alle graphcode, Ziel-kind je REQ statt pauschal -- REQ-dashboard-readonly und REQ-readonly-bridge nach `non-functional` (Architektur-Constraint an der Modulgrenze, konsistent mit D2), REQ-no-extraction nach `functional`. Rest-Reject dabei: genau 1 (`FUNC-serve-sse -satisfy-> REQ-readonly-bridge`), aufzuloesen durch Loeschen oder Heben auf die FCHAIN. Prior: BREAKING (CR-GC-366): das Trace-Pattern `FUNC -satisfy-> UC` entfaellt ersatzlos. Es war ein zweiter Weg vom Verhalten zum Use Case neben dem einzig tragenden `UC -compose-> FCHAIN -compose-> FUNC` — und der billigere: eine FUNC konnte einen UC bedienen, ohne in dessen Wirkkette zu stehen, womit IO-01 (FLOW-Pfade je Kettenpaar) und R-21 (Integrationstest je Kette) sie nie sahen. Die Abkuerzung umging genau die Pruefungen, die die Anbindung belastbar machen. Am graphcode-Selbstmodell waren 10 der 26 solchen Kanten reine Dopplung (die FUNC stand ohnehin in der FCHAIN), die restlichen 13 sind der Migrationsanlass. Jeder Graph mit solchen Kanten faellt jetzt R-18 (error) zur Last und muss migriert werden: FUNC in die FCHAIN des UC aufnehmen, satisfy-Kante loeschen. Prior: BREAKING (CR-SM-231b): das knotenweite `testResult` entfaellt — das Ergebnis haengt PRO `testRefs`-Eintrag (`result`, `ranAt`, `evidence`), aus demselben Grund wie `tool`. Ein einzelnes Ergebnis am Knoten konnte bei n Laeufen nicht sagen, welcher gemeint ist, und "einer rot, einer gruen" war gar nicht darstellbar — genau der Zustand, den ein Gate wissen muss. FM-03 liest jetzt "jeder Eintrag passed": "irgendeiner gruen" haette einen gruenen Unit-Lauf einen roten Visual-Lauf verdecken lassen. Ein Eintrag ohne Ergebnis ist nicht bestanden. VR-01 meldet die Dateien ohne Ergebnis statt nur den Knoten. Prior: BREAKING (CR-SM-231): `testRef` (Objekt) entfaellt ersatzlos zugunsten von `testRefs` (Array, min 1) — eine Abnahme, n Testdateien. Kein Union, kein Alias: ein Graph mit dem alten Attribut faellt R-19 zur Last und muss migriert werden. Anlass war ein Zaehl-Audit (537 laufende Tests in 67 Dateien, 14 TEST-Knoten mit je genau einer Datei, 53 Dateien an keine Abnahme gebunden) plus ein belegter Ausweichweg: dieselbe Spec-Datei stand im testRef ZWEIER TEST-Knoten, womit die Relation faktisch n:m war — ein roter Lauf keiner Abnahme mehr eindeutig zuordenbar, der TRR-Gate zaehlte dieselbe Evidenz doppelt. `tool` bleibt PRO EINTRAG: eine Abnahme mischt real die Runner (vitest + playwright). +AttributeSpec.type 'array' (testRefs ist das erste Listen-Attribut). Prior: BREAKING: `SemanticId` (`Name.TypeAbbr.Counter`) deleted, `ElementUid` (`<TYPE>-<slug>`) is the family canon — the old canon was used by no production graph of the family while 626 of 1145 elements already carried TYPE-slug (CR-SM-217); realRef unifies codeRef+schemaRef (+physical-MOD CAD ref), symbol optional; testRef stays separate (CR-228 C); +RepoRelativePathSchema on testRef/realRef .file — no absolute/`..` paths (CR-GC-255)
+export const ONTOLOGY_VERSION = '9.0.0'; // BREAKING (CR-SM-294): das Feld `asil` entfaellt ersatzlos, zusammen mit dem Enum `AsilLevel`. Sein einziger Leser war R-03 (ASIL isolation), und die Messung ueber 19 Familiengraphen (4540 Elemente) zeigt: 0 von 305 MOD tragen `asil` ueberhaupt. Ein Feld ohne Schreiber ist eine Regel, die nie feuert -- Gate 3 der Grammatik-Review. Mit R-03 fallen im selben Zug RT-01, PH-01, R-27 (alle drei lesen `attributes.kind === 'physical'`, 0 von 305 MOD tragen es) und CA-01 (`attributes.requires` / `attributes.capability`, 0/0). Die physische Ebene der Ontologie war nie in Gebrauch: kein Mitglied der Familie modelliert Hardware oder funktionale Sicherheit. `kind`, `requires` und `capability` brauchen KEINEN Schema-Eingriff -- sie lagen im freien `attributes`-Sack und sind nach der Streichung ihrer Leser schlicht unbenutzte Schluessel. Migration: ein Graph, der `asil` traegt, verliert das Feld beim naechsten Reseed; kein Element und keine Kante faellt (0 -> 0 Befunde ueber alle 19 Graphen). Prior: BREAKING (CR-SM-266a): drei Enums schrumpfen, und alle drei sind ENTFERNUNGEN. (1) ElementType 13 -> 12: `SESSION` entfaellt. (2) TraceType 7 -> 6: `produces` entfaellt. Beide trugen genau EIN Pattern (`SESSION -produces-> *`), und die Messung hat es widerlegt: 0 produces-Kanten und 0 SESSION-Knoten in ALLEN 9 aktiven Familie-Graphen, auch im graphcode-Selbstmodell nach 195 gegateten Versionen. Die reale Provenance lebt seit CR-GC-347 in `.graphcode/audit.jsonl` -- audit_trail/audit_stats lesen die DATEI, nie den Graphen; einziger Schreiber war ein toter Pfad (CR-195d in graph-api-core), Leser mit Wirkung keiner. Der urspruengliche CR-Entwurf hielt das Pattern fuer die Provenance-Kante und wollte es BEHALTEN ('Nicht-Befund'); die Zaehlung hat den Nicht-Befund kassiert -- Gate 1 verlangt fuer das Wiederaufmachen einer Entscheidung eine Messung, und hier war sie es. (3) Mit `produces` faellt `TraceCategory` und `Trace.category`. Das ist die wichtigste Haelfte: R-08 und R-18 haben `category === 'audit'` UEBERSPRUNGEN, also haette nach D5 jede Kante mit diesem selbstgesetzten Attribut die komplette Pattern-Matrix UND die Referenzintegritaet umgangen. Ein Attribut, das eine Strukturpruefung abschaltet, ist die Klasse aus CR-SM-263/-257; hier zusaetzlich der billige Zweitweg aus CR-GC-366, nur ohne Kante. Gemessen: 0 von 0 Traces aller 9 Graphen tragen `category` -- die Entfernung nimmt niemandem etwas weg. (4) ReqKind 7 -> 6: `negative` entfaellt. Ein Verbots-REQ ist auch eine Anforderung -- die Implementierung muss Regeln abfragen oder Sicherungen einbauen, das ist `functional`. Der Wert hatte NULL Leser (anders als risk/mitigation -> FM-01..03, pre/postcondition -> UC-05/06, non-functional -> NFR-01) und haette durch die neuen where-Praedikate per AUSLASSUNG erstmals Wirkung bekommen: er stand in keiner der vier Listen und waere nur noch per FCHAIN erfuellbar gewesen. Die sechs verbleibenden Werte partitionieren die where-Listen VOLLSTAENDIG. Migration `negative`: 3 REQs, alle graphcode, Ziel-kind je REQ statt pauschal -- REQ-dashboard-readonly und REQ-readonly-bridge nach `non-functional` (Architektur-Constraint an der Modulgrenze, konsistent mit D2), REQ-no-extraction nach `functional`. Rest-Reject dabei: genau 1 (`FUNC-serve-sse -satisfy-> REQ-readonly-bridge`), aufzuloesen durch Loeschen oder Heben auf die FCHAIN. Prior: BREAKING (CR-GC-366): das Trace-Pattern `FUNC -satisfy-> UC` entfaellt ersatzlos. Es war ein zweiter Weg vom Verhalten zum Use Case neben dem einzig tragenden `UC -compose-> FCHAIN -compose-> FUNC` — und der billigere: eine FUNC konnte einen UC bedienen, ohne in dessen Wirkkette zu stehen, womit IO-01 (FLOW-Pfade je Kettenpaar) und R-21 (Integrationstest je Kette) sie nie sahen. Die Abkuerzung umging genau die Pruefungen, die die Anbindung belastbar machen. Am graphcode-Selbstmodell waren 10 der 26 solchen Kanten reine Dopplung (die FUNC stand ohnehin in der FCHAIN), die restlichen 13 sind der Migrationsanlass. Jeder Graph mit solchen Kanten faellt jetzt R-18 (error) zur Last und muss migriert werden: FUNC in die FCHAIN des UC aufnehmen, satisfy-Kante loeschen. Prior: BREAKING (CR-SM-231b): das knotenweite `testResult` entfaellt — das Ergebnis haengt PRO `testRefs`-Eintrag (`result`, `ranAt`, `evidence`), aus demselben Grund wie `tool`. Ein einzelnes Ergebnis am Knoten konnte bei n Laeufen nicht sagen, welcher gemeint ist, und "einer rot, einer gruen" war gar nicht darstellbar — genau der Zustand, den ein Gate wissen muss. FM-03 liest jetzt "jeder Eintrag passed": "irgendeiner gruen" haette einen gruenen Unit-Lauf einen roten Visual-Lauf verdecken lassen. Ein Eintrag ohne Ergebnis ist nicht bestanden. VR-01 meldet die Dateien ohne Ergebnis statt nur den Knoten. Prior: BREAKING (CR-SM-231): `testRef` (Objekt) entfaellt ersatzlos zugunsten von `testRefs` (Array, min 1) — eine Abnahme, n Testdateien. Kein Union, kein Alias: ein Graph mit dem alten Attribut faellt R-19 zur Last und muss migriert werden. Anlass war ein Zaehl-Audit (537 laufende Tests in 67 Dateien, 14 TEST-Knoten mit je genau einer Datei, 53 Dateien an keine Abnahme gebunden) plus ein belegter Ausweichweg: dieselbe Spec-Datei stand im testRef ZWEIER TEST-Knoten, womit die Relation faktisch n:m war — ein roter Lauf keiner Abnahme mehr eindeutig zuordenbar, der TRR-Gate zaehlte dieselbe Evidenz doppelt. `tool` bleibt PRO EINTRAG: eine Abnahme mischt real die Runner (vitest + playwright). +AttributeSpec.type 'array' (testRefs ist das erste Listen-Attribut). Prior: BREAKING: `SemanticId` (`Name.TypeAbbr.Counter`) deleted, `ElementUid` (`<TYPE>-<slug>`) is the family canon — the old canon was used by no production graph of the family while 626 of 1145 elements already carried TYPE-slug (CR-SM-217); realRef unifies codeRef+schemaRef (+physical-MOD CAD ref), symbol optional; testRef stays separate (CR-228 C); +RepoRelativePathSchema on testRef/realRef .file — no absolute/`..` paths (CR-GC-255)
 /** Rules engine version (validation rules incl. RC conformance). */
-export const RULES_VERSION = '9.1.0'; // MINOR (CR-SM-268 Teil 2): +`importCoverage(graph, facts)` — die Abdeckung des Import-Graphen als MESSUNG neben den Regeln, nicht als Befund im Regelstrom. 'X von Y Import-Endpunkten nicht zugeordnet' sagt nichts ueber den Graphen aus; es sagt, wie belastbar die Zahl daneben ist. Defekte gehoeren in den Regelstrom, Messungen auf die Auswertungsflaeche — und die gibt es bereits: CR-GC-398 hat `rules_evaluate` um `skipped` erweitert, mit exakt derselben Begruendung ('an empty skipped is what makes the count interpretable'). Ein eigener info-Befund waere ein ZWEITER Mechanismus fuer dieselbe Aussage gewesen, eine eigene Regel-ID (RC-07) haette dauerhaft Katalogzeile, readiness-Zuordnung und Golden-File-Eintrag gekostet (Gate 6) — fuer eine Zahl, die gar kein Urteil ist. GESCHWISTER von `skipped`, nicht dasselbe: `skipped` heisst 'diese Quelle wurde GAR NICHT ausgewertet' (kein lesbarer repoRoot), hier ist sie ausgewertet worden und ein Teil faellt trotzdem durch; zusammengelegt waeren 'nicht gelaufen' und 'gelaufen, aber blind' wieder ununterscheidbar. Der Anlass ist ein realer Verlust: die Liste der nicht zugeordneten Dateien hing als TEXTANHANG an der Meldung eines ANDEREN Befundes (`unassignedNote`) und verschwand mit ihm — CR-GC-423 hat die drei RC-05-Drift-Befunde von graphcode geschlossen, und mit ihnen war die Liste weg; sie musste in CR-GC-424/425 von Hand rekonstruiert werden. Der Anhang entfaellt jetzt ersatzlos. EIN geteilter Resolver (`buildModResolver`) fuer Regel UND Messung, bewusst herausgezogen statt zweimal geschrieben: eine Abdeckungszahl, die anders aufloest als die Regel, misst etwas anderes als das, was geprueft wird — und das waere schlimmer als keine Zahl. Additiv: `evaluateConformanceRules` behaelt seine Signatur `RuleViolation[]`, kein Aufrufer bricht. Golden-File unberuehrt (die `conformanceRules`-Oberflaeche fuehrt Regeln, und dies ist keine). Gemessen am graphcode-Checkout (2026-08-26): 14 von 73 Import-Endpunkten unzugeordnet. CR-GC-425 nannte 12 von 178 — die Zahlen sind NICHT dieselbe Groesse und duerfen nicht gleichgesetzt werden: hier sind Endpunkte VERSCHIEDENE Dateien (Kanten-Enden dedupliziert), und der Graph steht inzwischen mehrere Versionen weiter. Was den Mechanismus belegt, ist die Deckung im Inhalt: alle fuenf in CR-GC-425 benannten reinen Zod-Vertragsdateien (gve-session-, schema-fingerprint-, target-profile-, lock-owner-contract, test-selection) stehen in der Liste, ebenso die beiden dort als modellierungswuerdig genannten (src/evaluation.ts, src/testreport.ts). Die Angabe ist damit abfragbar statt rekonstruiert. Die graphcode-Haelfte (Feld in `rules_evaluate` neben `skipped`) folgt nach dem Release. Prior: BREAKING (CR-SM-270): `ReadinessScore.score` ist `number | null`, +`coreApplicable`. `null` heisst NIE 0 %, dieselbe Zusage wie bei graph_metrics seit CR-GC-326 ('a value that is not measurable is not zero percent'). Der Anlass war die Gegenrichtung, gemessen an moneyflow (reiner Code-Import: 0 UC, 0 FCHAIN, 0 ACTOR, 1 SYS, 306 FUNC): die Dimension `uc` meldete score 0,997 und ready TRUE. Ein Modell ohne einen einzigen Use Case war zu 99,7 % use-case-bereit. Ursache: von den 15 uc-Regeln haben dreizehn eine leere Grundgesamtheit und SCHWEIGEN mangels Gegenstand, R-17 traegt 1 (SYS) und FC-03 traegt 306 (FUNC) — 99,7 % des Nenners aus EINER Fremdtyp-Regel, und das Schweigen der dreizehn las sich als Erfolg. Der Score zeigte damit in die falsche Richtung: je mehr importierte FUNCs ein Repo ohne Wozu-Ebene hat, desto reifer sah seine uc-Readiness aus — und `dimension_readiness` steuert `graph_next_step`. Die KERNMENGE ist ABGELEITET, nicht deklariert: die Elementtypen, die die MEHRHEIT der Dimensionsregeln prueft (uc->UC, arch->FUNC, ver->TEST, ...). Eine zweite Tabelle neben RULE_TO_DIMENSION waere ein zweiter Speicher derselben Wahrheit und liefe auseinander, sobald jemand nur eine von beiden pflegt — genau der Defekt, den CR-SM-235 hier schon einmal beseitigt hat (RULE_ELEMENT_TYPE, 18 von 71 Regeln fehlten); ein Attribut waere zusaetzlich eine Selbstauskunft (abgelehnt in CR-SM-263). Laesst sich keine Mehrheit ableiten, ist der Kern ALLES was die Dimension prueft — der Waechter greift dann nie, lieber gar nicht als am falschen Ort. KEIN Neuschnitt von `applicable`: wo die Kernmenge da ist, zaehlen die Fremdtyp-Beitraege unveraendert mit, und `applicable === 0` behaelt ausdruecklich seine 0,0 (Akzeptanzkriterium 3 des CR; derselbe Einwand liesse sich dort erheben, aber ein stiller Mitnahmeeffekt waere die schlechtere Wahl als eine eigene Entscheidung). `ready` ist bei `null` immer false. Gemessen: moneyflow uc 0,997/ready -> null; ausserdem neu gefangen moneyflow `cr` (0 CR, Nenner 1229), graphcodedemo `cr` (0 CR, Nenner 219), sirail `ms` (0 MS, Nenner 2). graphcode ist auf allen acht Dimensionen unveraendert messbar — der Regressionsnachweis. Beim Testen gefunden und mitentschieden: ein Graph GANZ ohne TEST-Knoten meldet `ver` jetzt `null` statt einer niedrigen Zahl. Das ist gewollt ('es gibt keine Abnahmen' ist ein anderer Zustand als 'die Abnahme greift nicht'), verlangt aber vom Konsumenten die null-sichere Rangfolge: nicht messbar rankt OBEN, nicht unten (Entscheidung 3 des CR). Ein naiver `a.score - b.score`-Komparator ergibt mit null NaN und sortiert dann gar nicht. Prior: BREAKING (CR-SM-266b): R-18 bekommt ein ZWEITES BEIN — die Kardinalitaets-Obergrenzen. Bewusst dieselbe rule_id nach dem Muster von R-10 und R-15 (CR-SM-249): die Aussage ist dieselbe ('diese Kante ist nach dem Meta-Modell nicht zulaessig'), nur ist die Bedingung eine ueber die MENGE der Kanten eines Knotens statt ueber das Typ-Paar. Eine eigene ID kostete dauerhaft Nenner-Anteil, Katalogzeile, readiness-Zuordnung und Golden-File-Eintrag (Gate 6), und der naechste Schritt des Lesers waere derselbe: Kante weg. EIN Befund je Quellknoten, nicht je ueberzaehliger Kante — bei n Allokationen sind nicht n-1 Kanten falsch, es ist EINE Entscheidung offen, und n-1 Befunde trieben den Zaehler ueber den Nenner-Beitrag (die Fehlmessung aus CR-SM-242). Die Zaehlung ist pattern-scharf (Zieltyp muss passen), sonst meldete eine ohnehin pattern-ungueltige Kante zweimal. Migration, gemessen an den 9 aktiven Familie-Graphen: 9 Faelle, ALLE in sirail (1x FUNC mit zwei allocate, 8x FLOW mit zwei SCHEMA). Alle anderen acht Graphen sind bereits konform — die Obergrenze kostet sie nichts. Prior: BREAKING (CR-SM-266a): drei Regeln ziehen mit der Matrix nach, keine neue Regel-ID. UC-02 prueft ERREICHBARKEIT statt Adjazenz: sie suchte einen io-Ziel-Treffer direkt am UC oder an dessen compose-Kind -- also genau die mit D1/D4 entfallenen Kanten -- und waere damit UNERFUELLBAR geworden, haette also einen Zustand verlangt, den R-18 im selben Lauf als ungueltige Kante ablehnt. Das ist der gegenlaeufige Fall aus Gate 4 des Grammatik-Reviews und fuer den Nutzer eine Sackgasse statt eines Fehlers; genau deshalb ist der Umbau Teil DIESES Bumps und nicht eines Folge-CR. Neu: ACTOR -io-> FLOW -io-> FUNC, FUNC in einer FCHAIN des UC, in BEIDE Richtungen -- ein UC ist auch dann angebunden, wenn die Kette dem Actor etwas LIEFERT; die alte Fassung sah nur die Trigger-Richtung, weil `ACTOR -io-> UC` nur so herum existierte. Die CR-SM-261-Optimierung bleibt erhalten (zwei Mengen vorab, dann Mitgliedschaft je UC, alles ueber den Index aus CR-SM-264; kein Scan je UC), und die aeussere Schleife bleibt `elementsOfType('UC')`, also ist die Befundreihenfolge weiter die Graph-Reihenfolge (Gate 5). R-10 bietet UC nicht mehr als FLOW-Konsument an -- der fix_hint haette nach D4 in eine R-18-Ablehnung geschickt. R-08/R-18 verlieren den `category !== 'audit'`-Filter (das Attribut existiert nicht mehr, s. ONTOLOGY_VERSION). BQ-07 'Complete' bekommt einen DRITTEN Grund: `kinds` nicht deklariert (REQ-X06). Bewusst KEINE neue Regel-ID -- Gate 6: eine ID kostet dauerhaft einen Nenner-Anteil, eine Katalogzeile, eine readiness-Zuordnung und einen Golden-File-Eintrag; BQ-07 sammelt bereits mehrere Unvollstaendigkeits-Gruende in EINEN Befund, und ein REQ ohne Klassifikation ist genau das. Severity-Trennung wie CR-SM-262 fuer RC-06: das blosse FEHLEN ist ein Vollstaendigkeitssignal (warning, hier), eine satisfy-Kante auf ein REQ ohne kinds ist eine FEHLMESSUNG (error, via R-18/where). Migrationsbestand kinds: 420 REQs familienweit -- kadjar 305 (Doc-Import), sirail 61, graphcode 23, siconizer 17, sigloch-modules 10, Rest <=3; an den beiden Selbstmodellen 33. Delta-Semantik: unberuehrter Bestand blockiert keine Mutation. Prior: MINOR (CR-SM-262): +RC-06 'external realRef names a declared dependency' (severity warning) und +`CodeFacts.declaredDependencies`. RC-01..03 ueberspringen `external === true` zu Recht — der Pfad eines fremden Pakets ist im Konsumenten-Repo nicht aufloesbar. Die Folge war, dass externe Bindungen NIE geprueft wurden und still verrotteten. Gefunden von Hand am graphcode-Selbstmodell (2026-08-22), nicht von einer Regel: `SCHEMA-metric-vector` trug `realRef.file = packages/se-optimizer/src/metrics.ts`, und `@sigloch/se-optimizer` existiert seit CR-SM-248 nicht mehr (MetricVector liegt in se-engine). Der Pfad ist hier nicht entscheidbar, der PAKETNAME schon: `packages/<name>/…` behauptet ein Workspace-Paket, also muss `@sigloch/<name>` in dependencies oder devDependencies stehen. Andere Pfadformen bleiben UNGEPRUEFT statt geraten. Severity warning, nicht error: der Pfad darf aus ehrlichen Gruenden von der Konvention abweichen (Monorepo-Umbau, verlinkte Arbeitskopie), und ein error wuerde ueber die Delta-Semantik jede weitere Mutation blockieren — eine verrottete Bindung ist ein Vollstaendigkeitssignal, keine Fehlmessung (anders als R-29, wo die Zahl selbst falsch wird). `declaredDependencies` ist OPTIONAL und der fehlende Fall ist SCHWEIGEN, nicht ein Befund — die bewusste Umkehrung des `files`-Vertrags, wo ein fehlender Schluessel laut scheitern muss: ein fehlender Datei-Eintrag heisst 'nachgesehen und nichts gefunden', eine fehlende Dependency-Liste heisst 'gar nicht nachgesehen', und das als 'deklariert nichts' zu lesen wuerde jede externe Bindung des Graphen auf einmal melden. Der Extraktor liegt in graphcode (`src/conformance.ts`, `extractDeclaredDependencies`) — vorher las `extractCodeFacts` die package.json NIE, die urspruengliche Kostenschaetzung des CR war insofern falsch. Gemessen an den drei Selbstmodellen: 0 Befunde (graphcode 9 externe Knoten mit realRef, davon 7 in der Pfadform, alle deklariert; sigloch-modules und graphcodedemo tragen keine externen realRefs). Die Null ist der REPARIERTE Zustand — vor der Reparatur am selben Tag waere es genau 1 gewesen, der reale Drift-Fall. ACHTUNG, Gate-Luecke, hier groesser als sonst: RC-Regeln stehen UEBERHAUPT NICHT im Golden-File. `ALL_RULE_DEFS` (die Quelle der `rules`-Oberflaeche in `grammar-snapshot.ts`) enthaelt nur die Familien, die `evaluateAllRules` faehrt; die sechs RC-Regeln laufen ueber `evaluateConformanceRules` mit CodeFacts und sind damit von `check-grammar-version.mjs` gar nicht erfasst — auch eine ENTFERNUNG wuerde dort nicht auffallen. Der Bump hier ist von Hand; die Luecke selbst ist ein eigener Befund. Prior: MINOR (CR-SM-263): MT-02 ueberspringt ROLLUP-CONTAINER — MODs, deren allozierte FUNCs AUSNAHMSLOS zerlegte Bloecke sind. `lcom4Of` verbindet zwei FUNCs ueber ein geteiltes io/satisfy-ZIEL, und CR-SM-256 hat festgehalten, dass ein Rollup genau die nicht traegt (12 der 13 Bloecke am graphcode-Selbstmodell tragen keine einzige io/satisfy-Ausgangskante). Daraus folgt LCOM4 = Zahl der Bloecke, IMMER: die Regel war dort nicht streng, sondern unerfuellbar — gruen wird sie erst mit der Kante, die CR-SM-256 fuer falsch erklaert hat. Zwei Regeln desselben Katalogs forderten Gegensaetzliches, der gegenlaeufige Fall aus Gate 4. Gemessen an allen drei Selbstmodellen (graphVersion 181): es existiert genau EIN Container, `MOD-repo-root` (5/5 Bloecke) — MT-02 7 -> 6 Befunde, die Differenz ist eine info; sigloch-modules und graphcodedemo tragen keinen. Lockerung, kein heute gruener Graph wird rot, keine Migration. Die MESSUNG bleibt: `moduleMetrics()` liefert `lcom4` unveraendert weiter und markiert den Container mit `rollupContainer` — nur das URTEIL entfaellt, denn die Zahl ist wahr und die Schwelle an dieser Stelle bedeutungslos. EIN geteilter Helper: `decomposedFuncs` ist jetzt exportiert und hat mit MT-02 seinen vierten Nutzer, damit keine zweite Definition von 'Blatt' entsteht (Gate 2). ABGELEHNT im selben Durchlauf, hier festgehalten damit es nicht wiederkommt: die FASSADEN-Ausnahme ueber `MOD.kind` (Option A und B des CR). Fachlich ist der Einwand richtig — fuer eine Registry wie `MOD-mcp-tools` (9 orthogonale Werkzeuge, KEIN Block darunter) ist hoher LCOM4 das gewuenschte Ergebnis, und geteilte Ziele hinter einer API waeren der Verdachtsfall. Aber `kind` ist an 30 von 30 MODs aller drei Selbstmodelle unset: ein Attribut mit Leser (R-27) und ohne Schreiber, und eine Selbstauskunft, die eine Strukturregel abschaltet — genau die Klasse, die CR-SM-257 am selben Tag abgelehnt hat. Der Container ist aus dem Graphen ABLEITBAR, die Fassade ist es nicht (Gate 3); deshalb nur die eine Haelfte. Fuer die Fassade bleibt Option C: die Zahl steht da und wird gelesen. ACHTUNG, Gate-Luecke (wie CR-SM-249 und CR-SM-256): `check-grammar-version.mjs` sieht die Aenderung NICHT — der Snapshot erfasst id/severity/domain, alle drei bleiben gleich. Der Bump hier ist von Hand. Prior: MINOR (CR-SM-255 + CR-SM-256): zwei Grundgesamtheiten verengt, beide Lockerungen — kein heute gruener Graph wird rot, keine Migration, keine Kante aendert sich. CR-SM-255: CR-R04 fragt nur noch CRs mit status open/in-progress (und CRs ganz ohne status — ein fehlendes Attribut darf keine Regel stumm schalten); die Statusmenge ist woertlich die von CR-R03 zwoelf Zeilen darueber. 'Welche FUNC fasst dieser CR an' ist eine PLANUNGSfrage; am geschlossenen CR ist sie Archaeologie (Umfang steht im Commit und im Diff), und wer die Kanten nachtraeglich zieht, raet. Gemessen am graphcode-Selbstmodell (graphVersion 171): 41 meldende CRs, davon 40 done und 1 dropped, KEIN einziger offener — 41 unbearbeitbare Befunde. Nach der Aenderung 0, und die Grundgesamtheit ist nicht leer: die 7 offenen CRs tragen ihre FUNC-Kanten bereits, die Regel ist erfuellt statt gegenstandslos. CR-R01 ('ein CR trackt ueberhaupt etwas') bleibt fuer ALLE CRs gueltig. Regelname 'CR must have FUNC' -> 'Open CR must have FUNC'. CR-SM-256: R-02 und R-31 bekommen dieselbe Grundgesamtheit wie R-30 seit CR-SM-249 und R-20 seit CR-210 — ausschliesslich BLAETTER (FUNC ohne FUNC-Kind). Ein zerlegter FUNC ist ein Rollup: durch einen Blackbox-Block fliesst nichts, und er erfuellt keine REQ, die nicht schon ein Blatt erfuellt; wer die beiden Regeln an ihm befriedigen will, muss eine io-Kante an einem Knoten erfinden, an dem nichts anliegt, oder eine satisfy-Kante, die dieselbe REQ ein zweites Mal beansprucht. CR-GC-375 hatte das fuer R-31 ausdruecklich offengelassen ('ein Block ohne io ist auch als Rollup ein Befund … eine eigene Frage, hier bewusst nicht'); die Messung, die Gate 1 zum Wiederaufmachen verlangt, liegt vor: 12 der 13 Bloecke am graphcode-Selbstmodell melden R-02 UND R-31, keiner aus einem anderen Grund — dieselbe Ursache zweimal gezaehlt, die Klasse CR-SM-235/-242. R-02 22->10, R-31 29->17. R-30 unveraendert. EIN geteilter Helper `decomposedFuncs` fuer alle drei Regeln, damit keine zweite Definition von 'Blatt' entsteht (Gate 2). ABGELEHNT im selben Durchlauf, hier festgehalten damit es nicht wiederkommt (CR-SM-257): R-02/R-30/R-31 sollten zusaetzlich `attributes.external === true` ueberspringen. `external` ist ein REALISIERUNGS-Marker — genau so steht es in ELEMENT_ATTRIBUTES ('exempt from the R-20 realRef-binding requirement') und genau so nutzen es R-27 und RC-01..03. Struktur schuldet der Konsument trotzdem: 5 der 12 externen FUNC am graphcode-Selbstmodell haengen vollstaendig in einer lokalen Wirkkette und sind beidseitig verdrahtet. Entscheidend ist die Reihenschaltung am System-Rand: R-31 erzwingt den Grenz-FLOW, SC-04 erzwingt dessen SCHEMA, und `external` am SCHEMA sagt 'der Vertrag wird drueben veroeffentlicht' (33 von 33 Grenz-FLOWs in graphcode tragen so ein SCHEMA, 12 davon external). Eine Ausnahme in R-31 kappt das erste Glied: ohne geforderten FLOW feuert SC-04 nie, und am externen Interface wird NIE ein Schema-Vertrag verlangt. Die 21 Befunde, die der Vorschlag entfernt haette, sind der Hebel, der genau diese Vertraege entstehen laesst. ACHTUNG, Gate-Luecke (wie CR-SM-249): `check-grammar-version.mjs` sieht beide Aenderungen NICHT — der Snapshot erfasst id/severity/domain, und alle drei bleiben gleich. Der Bump hier ist von Hand. Prior: BREAKING (CR-SM-247): R-28 (Ebenen-Praesenz) entfaellt ersatzlos. Sie schloss das Vacuous-Complete-Loch — mit 0/1 FUNC feuert keine Pro-Element-Regel und jede Vollstaendigkeitsfrage liest 'fertig' —, ist seit CR-GC-366 aber doppelt: die FLOW-Haelfte traegt R-31 (je FUNC statt einmal je Graph) plus IO-01, die SCHEMA-Haelfte SC-04 (je FLOW). Probe (SYS+UC+FCHAIN+3 FUNC, ohne FLOW/SCHEMA): 28 Befunde aus 18 Regeln, ohne R-28 bleiben 17 — das Loch bleibt zu. Gemessen feuerte sie 1x/0x an den Selbstmodellen, dort neben 14x IO-01 und 10x R-31. Dimension und Gate bleiben besetzt (R-30/R-31 sind ebenfalls arch/PDR). Bewusst in Kauf genommen: die SCHEMA-Absenz rutscht von PDR nach CDR, weil SC-04 erst feuert, wenn FLOWs existieren. Als domain:['graph']-Regel trug sie keinen Nenner bei — kein Dimensions-Score verschiebt sich. Prior: MINOR (CR-SM-250): IO-01 prueft ERREICHBARKEIT im io-Teilgraphen der Kette statt Adjazenz jedes Paares. Die Regel forderte einen vollstaendigen Graphen (n·(n−1)/2 Paarungen), obwohl eine Wirkkette eine Sequenz ist — der Zaehler wuchs quadratisch mit der Kettenlaenge, der Nenner-Beitrag linear, und wer sie befriedigen wollte, erfand einen fachlich falschen FLOW oder baute einen Ketten-Bus. Dieselbe Korrektur wie CR-GC-315 fuer R-21, eine Ebene hoeher. Zwei Praezisierungen aus dem Grammar-Review: ein Befund je abgehaengtem Glied statt je Paar (sonst waeren zwei Komponenten der Groesse n/2 wieder n²/4 Befunde, Zaehler > Nenner-Beitrag), und gar nicht verdrahtete Glieder gehoeren R-31 — am sigloch-modules-Selbstmodell waren 6 der 7 IO-01-Elemente zugleich R-31-Elemente, also Doppelzaehlung derselben Ursache. Lockerung, kein heute gruener Graph wird rot. Prior: BREAKING (CR-SM-249): R-15 wird VERSCHAERFT und heisst jetzt 'FCHAIN completeness' — eine Kette braucht Funktionen UNTER sich UND einen UC UEBER sich. Zweites Bein unter derselben rule_id nach dem R-10-Muster (bis zu zwei Meldungen je FCHAIN), bewusst keine neue Regel-ID: eine ID kostet dauerhaft einen Nenner-Anteil, eine Katalogzeile, eine readiness-Zuordnung und einen Golden-File-Eintrag — fuer einen einzigen Befund ueber beide Selbstmodelle (Gate 6 des Grammatik-Reviews). Major, weil ein heute gruener Graph rot werden kann: seit Ontologie 7.0.0 ist `UC -compose-> FCHAIN -compose-> FUNC` der EINZIGE Pfad vom Verhalten zum Zweck, und geprueft war nur sein unteres Bein. Migration: eine Kette ohne UC unterstellen oder loeschen (graphcode: `FCHAIN-doc-export`, 1 Befund). Zweitens R-30: die Grundgesamtheit sind ab jetzt AUSSCHLIESSLICH Blaetter (FUNC ohne FUNC-Kinder), und die Aufwaerts-Vererbung aus CR-GC-366 entfaellt ersatzlos. Ein zerlegter FUNC ist ein Rollup seiner Kinder und DARF gar kein Kettenglied sein — FC-03 ('FCHAIN is flat') verbietet es; die erste Fassung forderte einen Zustand, den eine andere Regel untersagt (am graphcode-Gate quittiert: graphVersion 111, zurueckgenommen in 112). Die Vererbung konnte nur greifen, wenn ein Block Kettenglied ist, und haette sonst ein unverbundenes Blatt stumm geschaltet. R-30 allein waere ein Minor (es meldet weniger: 56 -> 43 am graphcode-Selbstmodell, die 13 Differenz sind exakt die Bloecke). ACHTUNG, Gate-Luecke: `check-grammar-version.mjs` sieht diese Aenderung NICHT — der Snapshot erfasst id/severity/domain, und alle drei bleiben gleich. Eine semantische Verschaerfung ist mit einem Oberflaechen-Abzug nicht greifbar; der Bump hier ist von Hand. Prior: BREAKING (CR-SM-245): MS-01 verliert den Legacy-Fallback `MS -compose-> *` ersatzlos — Scope ist ausschliesslich `CR -relation-> MS`. Der Fallback war ein zweiter Weg zu derselben Aussage: ein Meilenstein galt als befuellt, ohne dass ein CR auf ihn zeigte, womit MS-03 und jede Scope-Auswertung ihn nie sahen. Verschaerfung, deshalb major — gemessen faellt an den Selbstmodellen aber kein einziger Meilenstein (alle 7 in graphcode haben CR-Relationen, vier zusaetzlich compose; MS-01 bleibt 0 Befunde). Zweitens: '+MS-' in SE_PREFIXES — MS-01/02/03 lagen in KEINEM Profil (weder se noch coding) und liefen nur im default-Lauf. Die Dimension `ms` haengt an genau vier Regeln (MS-01/02/03 + AF-05), und AF-05 traegt als `domain: ['graph']`-Regel keinen Nenner bei — im se-Profil war `ms` damit ein strukturell leerer Topic-Score und das SRR-Gate um drei Legs aermer. Zweiter Fall der 'RD-'-Klasse (CR-SM-221), gefunden vom Profil-Test aus CR-SM-244. Prior: BREAKING (CR-GC-366): +R-30 Wirkketten-Bindung, +R-31 io-Verdrahtung, R-02 zieltyp-scharf. Die vier Pflichten einer FUNC (ein REQ erfuellen, verdrahtet sein, in einer Wirkkette haengen, in einem MOD wohnen) waren nur zu zweit geprueft: R-02 und R-22. R-30 schliesst die Kette — R-15 verlangte, dass eine FCHAIN Funktionen hat, niemand verlangte, dass eine Funktion zu einer FCHAIN gehoert; daran haengen aber IO-01 und R-21, die beide nur INNERHALB einer Kette pruefen. R-31 schliesst die Verdrahtung: R-10 stellt dieselbe Frage vom FLOW aus und sieht eine FUNC ohne jede io-Kante deshalb nie (sie kommt in der FLOW-Schleife nicht vor); nur ACTOR darf terminieren. Ein Befund je FUNC statt je fehlender Seite, sonst uebersteigt der Zaehler den Nenner-Beitrag (die Fehlmessung aus CR-SM-242). BREAKING ist R-02: der Filter war zieltyp-blind, ein `FUNC -satisfy-> UC` schaltete ihn stumm, obwohl kein Requirement erfuellt war — am Selbstmodell 6 von 33 Faellen verdeckt (gemeldet: 27). Messung am graphcode-Selbstmodell (82 FUNC): R-30 60, R-31 54 (52 ohne Eingang, 50 ohne Ausgang, 48 ohne beides), R-02 27->33, R-22 3, R-18 26 (die Migrationsschuld aus dem gestrichenen Pattern). Prior: CR-SM-242: R-10 (`['FUNC']`→`['FLOW']`), SC-04 (`['SCHEMA']`→`['FLOW']`) und IO-01 (`['MOD']`→`['FUNC']`) deklarieren jetzt den Typ, an dem sie WIRKLICH melden. Alle drei iterierten ueber einen anderen Typ als den deklarierten: ihre Verstoesse erhoehten den Zaehler einer Grundgesamtheit, zu der sie nicht gehoerten. Gemessen am graphcode-Graphen (46 FLOW / 55 FUNC / 20 SCHEMA / 10 MOD) hob das `schema` von 0.713 auf 0.783 — SC-04 zog 46 FLOW-Verstoesse gegen 20 SCHEMA; bei IO-01 uebertraf der Zaehler (21) den eigenen Nenner-Beitrag (10) schon, nur der Clamp verhinderte einen negativen Score. Kein Evaluator, keine Regel-Semantik und kein Gate-Urteil geaendert — nur die deklarierte Grundgesamtheit, wie bei CR-SM-239. Neu erzwungen durch `se-rule-domain-invariant.test.ts`: der Typ jedes gemeldeten Elements liegt in der `domain` der Regel (stumm fuer 29 der 72 Regeln, die auf den Fixtures nicht feuern). CR-SM-243 (dieselbe Auslieferung): genau dieser Test hat vier weitere Faelle gefunden, die von Hand nie auffielen — R-03 (`['FUNC']`→`['MOD']`, meldet am Modul, das ASIL-D und QM mischt), FC-03 (`['FCHAIN']`→`['FUNC']`, meldet am FUNC mit der verschachtelten Zerlegung), NFR-01 (`['FUNC']`→`['MOD','FUNC','FCHAIN']`, Budgets liegen physisch am MOD und verhaltensseitig an FUNC/FCHAIN) und CR-R03 (`['CR']`→`['all']`, meldet am getrackten Zielknoten beliebigen Typs — nach R-08/R-18 die dritte und bewusst begruendete `all`-Regel). Prior: CR-SM-239: AF-01..05 und R-28 deklarieren `domain: ['graph']` statt `['SYS']` — sie pruefen EINMAL den Graphen, nicht die SYS-Elemente. Als Ein-Element-Gruppe waren sie ein Nenner-Beitrag mit fast sicherem Verstoss und zogen jede sonst leere Dimension auf 0 %: ein Graph ohne eine einzige REQ las `req` = 0 % (1 - 2/2 aus AF-01/AF-03) statt „nichts zu messen", und die Fokuswahl schickte den Executor dorthin. Kein Regelverhalten geaendert — nur die deklarierte Grundgesamtheit. Prior: CR-SM-231: +R-29 Testdatei-Exklusivitaet (severity **error**) — jede Testdatei erscheint in hoechstens einem `testRefs`. Das ist die Haelfte, die 1:n ERZWINGT statt es nur zu erlauben; ohne sie driftet das Attribut zurueck nach n:m. Bewusst schaerfer als R-19/R-20 (beide warning): eine doppelt beanspruchte Datei macht Gate-Zahlen nachweislich falsch, das ist eine Fehlmessung und kein Vollstaendigkeits-Signal. Rein graph-strukturell, kein I/O. R-19 und RC-02 lesen `testRefs`; RC-02 iteriert die Eintraege und nennt den konkreten Pfad statt nur der Knoten-ID. Prior: CR-SM-236: die letzten drei Urteilsschwellen sind Policy-Parameter statt Literal — CR-01 (`crossingFlows`, erstmals mit Aus-Zustand: `null` unterdrueckt auch die info je Modulpaar, die bisher die arch-Dimension verduennte), FM-03 (`riskRpn`, vorher inline 100) und R-04 (`moduleSize.{large,coupled,crossings}`, vorher inline 12/8/2 — drei Urteile, nicht eins). R-04 heisst jetzt 'Module size relative to crossing flows': die Regel waegt Groesse GEGEN Kreuzungen ab, der alte Name 'Max module size' verschwieg die zweite Haelfte der Bedingung. `RuleDefinition.evaluate` nimmt die Policy als zweiten Parameter, damit keine Familie einen Sonderweg braucht; einstellige Regelfunktionen bleiben zuweisbar. Bewertung unter DEFAULT_METRIC_POLICY unveraendert. Prior: CR-GC-315: R-12 + R-21 no longer tax FLOW reuse. R-12 restricted to dependency-carrying traces (compose/allocate/relation) — on `io` the only reachable shape was FUNC ─io→ FLOW ─io→ the SAME FUNC, i.e. read-modify-write on a shared FLOW, so the check was pure false-positive there (real io-cycles span ≥2 FUNCs and a 2-cycle test cannot see them); satisfy/verify/produces 2-cycles are pattern-illegal and belong to R-18. Its dedup key is now direction-independent (`type|sorted pair`) — keying on the message never collapsed anything, so every cycle was reported twice. R-21 no longer derives FUNC↔FUNC connections from FLOW co-adjacency alone: a producer/consumer pair with NO shared FCHAIN is silent. One hub FLOW with P producers and C consumers manufactured P·C findings, each demanding its own FCHAIN+integration test including pairs that never interact — reuse was penalised quadratically. The FCHAIN is the declared integration scope; the test is owed on that declared claim only. Rule intent (CR-GC-240 gap: unit/UC tests do not cover FUNC↔FUNC wiring) unchanged. Prior: CR-SM-227: +AF-01..05 Analysis-Freshness-Legs (analysis-freshness-rules.ts) — the third leg-kind a review gate checks (rule legs, layer-presence legs [R-28], now analysis-freshness legs, docs/articles/07-the-scoring-landscape.md); presence-only rules (Presence/Resolution-Split like R-19/R-20/R-26/R-27 vs. RC-01..05) checking a `graphVersion` freshness stamp exists under SYS.attributes.analysisFreshness.<AnalysisArtifactId> for each of the 5 CR-GC-221 judgment artifacts (conops/trade/assumption-review/fmea/implplan) — staleness (stamp vs live graphVersion) stays a consumer/I-O concern (`CreationCurrencyProvider`, @sigloch/graphcode-client), NOT evaluated here; Familie-Review 2026-08-05 gate assignment → RULE_TO_PHASE: ConOps/Trade/Assumption-Review → PDR, FMEA → CDR, Implementation Plan → TRR (SRR gets none); +AnalysisArtifactId enum + AnalysisFreshnessStampSchema (ontology.ts) as the SSOT graphcode-client's ARTIFACT_CATALOG analysis ids must match; grober Graph-Versions-Stempel only, no scope-hash in this first cut (conscious CR-SM-227 limitation).
+export const RULES_VERSION = '19.0.0'; // BREAKING (CR-SM-293): MT-01 zaehlt KOPPLUNG statt aller Kanten, dreht die Richtung um und urteilt per Default nicht mehr. (1) fan_in/fan_out lasen bis hierher JEDE Kante, deren eines Ende einem Modul gehoerte. Gemessen ueber 19 Familiengraphen: von 3281 gezaehlten Kanten sind nur 1117 (34 %) Kopplung. fan_in 2164 = 674 `allocate` -- das ist die MODULGROESSE, ein Modul wurde also stabiler, indem es Funktionen bekam -- plus 610 `FLOW -io-> FUNC`, 348 `FCHAIN -compose-> FUNC`, 255 `CR -relation-> FUNC`, 277 Rest. fan_out 1117 = 507 `FUNC -io-> FLOW` plus 501 `FUNC -satisfy-> REQ`; fast die halbe fan_out war SPEZIFIKATION, dieselbe Begruendung, mit der CR-SM-297 `satisfy` aus LCOM4 genommen hat. Dazu 70 Kanten ueber `MOD -io-> MOD`, ein Muster, das CR-SM-266 D2 aus TRACE_PATTERNS geloescht hat. MT-01 liest jetzt `moduleCrossings` -- DIESELBE Definition von Rand und dieselbe Zaehlbasis (verschiedene Vertraege), die CR-01, R-04 und BW-02 seit CR-SM-274/276 benutzen; MT-01 hatte bis hierher noch eine dritte. (2) RICHTUNG: der KONSUMENT haengt ab. Wer nach draussen liefert, wird gebraucht (afferent, fan_in); wer von draussen bezieht, haengt ab (efferent, fan_out). Das ist Martins Ca/Ce; die alte Lesart 'Kante zeigt weg = Abhaengigkeit' drehte jedes reine Verbrauchermodul auf I = 0 (maximal stabil), wo es 1 sein muss. Die Konvention stand vorher NIRGENDS im Repo -- sie war nie entschieden, nur codiert. (3) `DEFAULT_METRIC_POLICY.instability` 0.7 -> null, messen statt urteilen. Die Verteilung ist zweigipflig -- 44 von 149 messbaren Modulen exakt auf 0.00, 45 exakt auf 1.00, und 45 der 51 Befunde bei 0.7 sind genau diese 1.00 -- aus ihr laesst sich keine Schwelle ABLESEN (Praezedenz CR-SM-283/BW-02). Tiefer: I ist eine KOORDINATE, kein Defekt; Martins Satz lautet 'in Richtung Stabilitaet abhaengen', nicht 'I klein halten'. Damit fehlt MT-01 die Eigenschaft, die CR-SM-287 §2 von einer Steuerdimension verlangt (gerichtet, 'weniger ist besser, ohne Diskussion'), und (4) `STEER_RULES` schrumpft auf VIER. Praktisch war die Dimension ohnehin still: `steerScore` liest Verstoesse, und graphcodes Config setzt `instability: null` seit CR-GC-329 -- auf dem einzigen Repo, das taeglich steuert, lief der R5 laengst als R4. Der Nachfolger ist gemessen und angelegt (CR-SM-298): Martins Stable Dependencies Principle als gerichtete Groesse, Abhaengigkeiten 'bergauf' je Modul -- 34 von 305 (11 %), 132 von 146 Modulen bei null, Schwanz bis 6; lokal, gerichtet, budgetierbar, nicht entartet. Die Zahl `instability` bleibt vollstaendig erhalten: graph_metrics, Export und das gve-Dashboard rendern sie weiter, letzteres samt Hinweis 'Instabilitaet wird hier nur gemessen'. Prior: BREAKING (CR-SM-297, Teil 1): `satisfy` faellt aus der LCOM4-Verbindung von MT-02. Die Regel misst KOHAESION, und Kohaesion ist Datenkopplung -- geteilte `io`-Ziele und geteilte FLOW. `satisfy` ist dagegen eine SPEZIFIKATIONS-Beziehung: zwei FUNCs, die dasselbe REQ erfuellen, koennen zur Laufzeit vollstaendig entkoppelt sein. Die Wirkung ging dabei nur in EINE Richtung -- `satisfy` verbindet Gruppen, senkte also LCOM4 und liess Module kohaesiver aussehen, als ihr Datenfluss hergibt. Der Modellierungsgrund wiegt schwerer als der Messgrund: teilen sich zwei Funktionen ein Requirement, ist das REQUIREMENT zu zerlegen, nicht die Kohaesionsmessung zu beschoenigen; RD-02 sagt bereits das Verwandte. Gemessen ueber 19 Familiengraphen: MT-02 23 -> 24 Befunde. `satisfy` hat also fast nie zwei Gruppen verbunden -- die Aenderung ist prinzipiell richtig und praktisch billig. Golden neu verankert OHNE Zahlenaenderung: Totals und Reihenfolge bleiben an allen drei Eingaengen gleich (ssot 99, n700 1475, n3500 17495), nur die MT-02-shas wandern, weil die Meldung den gemessenen LCOM4-Wert woertlich nennt. NOCH OFFEN aus CR-SM-297: die beiden Container-Masse fuer den zerlegten FUNC (Kohaesion analog MT-02, Paar-Kopplung analog CR-01) -- ihre Schwellen sind aus der Verteilung ABZULESEN, nicht zu setzen (Praezedenz CR-SM-283/BW-02). Prior: BREAKING (CR-SM-296): je Frage eine Regel, je Schwelle ein Wert. (1) RD-04 gibt das Bein `FUNC -allocate-> MOD` an R-04 ab. Es zaehlte die allozierten FUNCs je Modul -- also die MODULGROESSE, und die misst R-04 auch. Beide feuerten am selben Modul im selben Batch, mit zwei Schwellen aus zwei Policy-Feldern (RD-04 > 11 gegen R-04 > 12), und welche recht hat, stand nirgends; dieselbe Ursache ging doppelt in den readiness-Nenner. R-04 ist die reichere Aussage -- Groesse GEGEN Kreuzungen, drei Urteile -- und liest ueber moduleCrossings ohnehin dieselben Daten. RD-04 bleibt fuer ZERLEGUNGSBREITE zustaendig: FUNC compose FUNC, SYS/MOD compose MOD und der FUNC-Wurzelwald am SYS (CR-SM-282). (2) Beide Schwellen sind an die Doktrin 7+-2 gebunden statt danebengesetzt: decompositionBreadth.warning 11 -> 9 (die Obergrenze der Doktrin) und moduleSize large 12 -> 9, coupled 8 -> 7. CR-SM-282 hatte gegen die Doktrin-Zahl 5 entschieden, weil `info` bei 5 den readiness-Nenner verwaessert haette -- das Argument traegt fuer die OBERgrenze nicht, denn RD-04 meldet als warning. Wirkung ueber 19 Familiengraphen, gemessen: RD-04 17 -> 15, R-04 9 -> 11, Summe 26 -> 26. Die Zahl bleibt, die Zustaendigkeit wird eindeutig. Prior: BREAKING (CR-SM-295): drei Regeln entfallen, eine wird neu gefasst -- Katalog 66 -> 63. (1) R-14 (UC must have compose) kann NIE ALLEIN feuern: sie prueft nur, ob ein UC irgendeine ausgehende compose-Kante hat, ohne den Zieltyp anzusehen, waehrend UC-01 den REQ und UC-03 die FCHAIN einzeln verlangen. Auf ELEMENTEBENE ueber 19 Familiengraphen gemessen, nicht auf Summen: R-14 (2 Befunde) ist eine echte Teilmenge von UC-01 vereinigt UC-03 (23 Befunde). Ihr Fixhinweis ('Add FCHAIN or REQ') versprach zudem eine Pruefung, die der Code nicht macht. (2) FC-01 (FCHAIN has actor boundary) ist von FC-04 gedeckt -- gemessen FC-01 (5) Teilmenge von FC-04 (27); FC-04 verlangt Eingang UND Ausgang, FC-01 nur eine Beruehrung. Dazu trug FC-01 einen TOTEN Ersatzweg: `hasDirectActorIO` prueft, ob der Eltern-UC actor-adjazent ist, und `ACTOR -io-> UC` hat CR-SM-266 (D1/D4) aus TRACE_PATTERNS entfernt -- der Zweig konnte seit drei Versionen nicht mehr wahr werden. (3) CR-R04 entfaellt und CR-R01 wird NEU GEFASST. Beide zielten daneben: CR-R01 akzeptierte jede relation-Kante, also auch einen CR, der nur an einem Meilenstein haengt (Termin, kein Umfang) -- 5 Befunde bei 49 CRs, die ausschliesslich auf ein MS zeigen. CR-R04 verlangte einen FUNC und war damit zu eng: 21 Befunde, darunter Daten-, Doku- und Konfigurationsaenderungen, die zu Recht keine Funktion beruehren. Die neue Fassung fragt nach dem UMFANG: mindestens eine relation auf FUNC, MOD, SCHEMA, REQ oder UC. Grundgesamtheit woertlich die von CR-R04 (CR-SM-255, nur offene CRs) -- an einem geschlossenen CR ist die Frage Archaeologie. Gemessen an 514 CR-Knoten: 54 ohne Umfangsbezug, davon 0 OFFEN, 52 done, 2 ohne Status. Die Verschaerfung laesst die Historie damit unangetastet und wirkt ab dem naechsten CR. MS-03 (CR ohne MS) bleibt unberuehrt -- sie stellt die komplementaere Frage. (4) R-17 behaelt ihre Pruefung und verliert ihren falschen Fixhinweis, der drei Zieltypen nannte, die sie nie angesehen hat. Prior: BREAKING (CR-SM-294): sechs Regeln entfallen ersatzlos, Katalog 72 -> 66. AO-D01 (RelayNodeDetection) ist STRUKTURELL unmoeglich -- sie verlangt `>= 2` ausgehende `io`-Kanten auf andere FUNC, und `FUNC -io-> FUNC` steht nicht in TRACE_PATTERNS; R-18 lehnt es als error ab. Das ist zeichengleich der Fall, fuer den CR-SM-283 AO-D03 geloescht hat -- AO-D03 fiel, AO-D01 blieb stehen. CA-01, RT-01, PH-01, R-27 und R-03 sind GEGENSTANDSLOS: sie lesen `asil`, `attributes.kind === 'physical'`, `attributes.requires` und `attributes.capability`, und ueber 19 Familiengraphen ist jedes dieser Attribute 0-mal gesetzt (305 MOD, 696 FUNC). Beleg beidseitig: `report:silence` meldet alle sechs mit 0 Befunden ueber den gesamten Bestand, UND keine von ihnen hat eine Ausloese-Fixture in se-rule-trigger-proof.test.ts (CR-SM-285) -- also weder feuert sie irgendwo, noch ist belegt, dass sie ueberhaupt feuern KANN. Genau die Doppelbedingung, die Gate 7 fuer eine Streichung verlangt. NICHT gestrichen wurde CL-01, obwohl derselbe Verdacht bestand: sie feuert 2x in 1 von 19 Graphen. Ihre Aussage waere anderswo besser aufgehoben -- jeder UC muss hinreichend distinct sein, und das saehe man an der FCHAIN -- aber diese Regel EXISTIERT NICHT: CR-SM-283 hat AO-D03 geloescht und dabei festgehalten, dass ihre Aufgabe ('zwei Wirkketten, die auf einer Ebene mitgliedsgleich werden') ungeloest bleibt. CL-01 zu streichen hiesse, eine feuernde Pruefung gegen eine nicht existierende zu tauschen. Wirkung auf die Bestandsgraphen: 0 -> 0 Befunde, kein Graph faellt. Die einzige messbare Folge ist der kleinere NENNER jeder readiness-Dimension -- sechs stumme Regeln hoben bisher jeden Score. Prior: BREAKING (CR-SM-286): ND-01/ND-02 rechnen ihre Aehnlichkeit SELBST; setND01SimilarityMatrix/setND02SimilarityMatrix/getND02SimilarityMatrix entfallen ersatzlos. Die Formel stand als Prosa in contracts und als Code in graphcode/src/kernel/measure/nd-similarity.ts, verbunden durch eine Injektionsnaht. Vier gemessene Kosten: (1) FAIL-OPEN -- ohne Injektion gaben zwei `error`-Regeln [] zurueck, ununterscheidbar von 'keine Duplikate'; moneyflow trug 16 ND-01-Befunde, die ausserhalb graphcodes NIEMAND sah (report:silence, die Spike-Skripte, jedes kuenftige Werkzeug). Die Familie hat fuer 'kann nicht urteilen' eine Konvention (policy.X = null, moduleMetrics.instability = null); ND fiel statt dessen nach gruen. (2) PROZESSWEITER MODULZUSTAND -- `let _nd01Matrix` ist global, graphcode brauchte die Klammer withNDMatrices mit finally-Reset, jeder andere Aufrufer nicht: Graph A urteilte ueber Graph B. (3) AO-D01 liegt IM Gate-Katalog und uebersprang seine Overlap-Pruefung ohne Matrix ('no matrix -> assume pass') -- eine Gate-Regel, die sich stillschweigend abschwaecht. (4) BQ-04 haengt am selben Muster und ist komplett tot. Jetzt: similarity.ts, je Graph WeakMap-gecacht, Formeln und Schwelle 0,85 zeichengleich uebernommen -- dasselbe Urteil an der richtigen Stelle, Praezedenz CR-SM-276 (moduleCrossings). DABEI GEFUNDEN UND BEHOBEN: die portierte Formel las Partner ueber ALLE Traces; se-rule-pair-legality (Pruefung A, CR-SM-278) meldete 35 Faelle, in denen ND-02 erst durch eine grammatikwidrige Kante auf SCHEMA anschlug (ACTOR -compose-> SCHEMA und Verwandte). `partners()` filtert jetzt ueber isValidTrace -- eine Regel darf ihr Verdikt nicht an einer Kante haengen, die R-18 als error ablehnt. Golden bewusst neu verankert und im Test-Header aufgeschluesselt: ssot 98 -> 98 UNVERAENDERT, n700 1038 -> 1478, n3500 5176 -> 17496, der gesamte Zuwachs ist ND-01 auf den synthetischen Eingaengen -- buildFixedSizeGraph KOPIERT den Basisgraphen 11x bzw. 56x, dort hat jedes Element 10 bzw. 55 exakte Duplikate; eine Duplikatsregel MUSS das melden. ND-02 bleibt ueberall 0. BQ-04 ausdruecklich NICHT angeschlossen: es verlangt 'pre-computed EMBEDDING similarity', und Embeddings kann ein reines Vertragspaket nicht rechnen; ein Ersatzmass haette ich erfinden muessen, und der Versuch (0.7*Beschreibung + 0.3*Name) lieferte 0 Befunde an allen neun Familiengraphen und 4950 an einer templatierten Fixture -- beide Gate-7-Ausreisser zugleich. BQ-04 ist damit der naechste AO-D03-Fall und ein eigener se-grammar-review-Vorgang. Prior: BREAKING (CR-SM-285): R-12 findet Zyklen JEDER Laenge statt nur Rueckkanten. Die Regel heisst 'No circular dependencies' und prueft bis hierher nur, ob eine Kante DIREKT zurueckliuft (A->B und B->A). Ein Dreierzyklus A->B->C->A ging vollstaendig durch das Gate, mit null Fehlern. Das ist die gefaehrlichere Haelfte der Fehlerklasse dieser Session: ein Absturz meldet sich, eine Pruefung die ihren Gegenstand nicht erreicht BESTAETIGT. Warum es zaehlt: jeder Rollup der Familie setzt Azyklizitaet voraus -- chainOf/funcChainOf (CR-SM-282/-283) tragen seen-Guards gegen genau diese Endlosschleife, moduleMetrics, die RD-04-Breitenzaehlung und gves Container-Sicht ebenso; unter einem Zyklus ist ein Rollup nicht falsch sondern UNDEFINIERT. Das R-18-Bein aus CR-SM-283 deckt es NICHT: bei A->B->C->A hat jeder Knoten genau EINEN compose-Elternteil, die Baum-Eigenschaft ist formal erfuellt und die Struktur trotzdem kein Baum. Gemessen ueber NEUN Familiengraphen: 0 Zyklen jeder Laenge, also 0 -> 0 Befunde -- die Schaerfung laesst keinen bestehenden Graphen fallen. Major nach Gate 8 trotzdem, weil eine verschaerfte Regel fremde Graphen fallen lassen KANN. EIN Befund je Zyklus statt je Kante (Klasse CR-SM-242), verankert am kleinsten Knoten des Rings und damit unabhaengig vom DFS-Einstieg (Gate 5); die Zweierring-Meldung ist woertlich unveraendert. Dazu zwei Haertungen OHNE Regelwirkung: descriptionOf() gab `el.description ?? ''` und starb an jedem Nicht-String (42/{}/[]/true -> '.trim is not a function', vier von fuenf Typen) -- am Gate hiess das Stacktrace statt block-Verdict; jetzt zaehlt nur ein echter String, alles andere ist 'keine Beschreibung'. Und tests/unit/se-rule-trigger-proof.test.ts ist die Umkehrung von report:silence: je Regel ein Graph der sie feuern LASSEN MUSS, 22 belegt, 50 als unbelegt ausgewiesen mit einer Zahl die nur sinken darf. Beim ersten Lauf fand er sofort einen Fall: ND-01/ND-02 sind `error` und beginnen mit `if (!_nd01Matrix) return []` -- ohne injizierte Aehnlichkeitsmatrix fallen sie nach GRUEN, ununterscheidbar von 'keine Duplikate'. Dokumentiert und eingefroren, nicht behoben: die Severity-/Signalfrage ist ein eigener se-grammar-review-Vorgang. Prior: BREAKING (CR-SM-283): AO-D03 entfaellt ERSATZLOS, BW-02 kommt -- Katalog 74 -> 74, kein Wachstum im Komplexitaetsbudget. (1) AO-D03 (`DuplicatePathDetection`) suchte `FUNC -io-> FUNC`, ein Paar das TRACE_PATTERNS nicht kennt und das R-18 als error ablehnt: die Regel konnte STRUKTURELL nicht feuern und hat es an keinem der fuenf Familiengraphen je getan. Eine Regel die nie feuert kostet trotzdem Nenner-Anteil, Katalogzeile, readiness-Zuordnung, Golden-File-Eintrag und einen Leser der sie unterscheiden muss. Die Aufgabe die sie tragen SOLLTE -- zwei Wirkketten die auf einer Ebene mitgliedsgleich werden -- bleibt ungeloest und ist ein eigener CR; BW-02 ersetzt sie nicht. (2) BW-02 misst die Randbreite der FUNC-WHITEBOX: verschiedene SCHEMA-Vertraege auf `FUNC -io-> FLOW -io-> FUNC` mit einem Endpunkt im compose-Teilbaum und einem ausserhalb. Gerechnet im selben Durchlauf wie `byModule` (module-crossings.ts), damit es EINE Definition von Rand gibt. Der Rollup ist hier nicht Genauigkeit sondern Existenz: ein zerlegter FUNC traegt selbst keine io-Kanten (die liegen an seinen Blaettern), ohne Teilbaum-Aufloesung waere die Zahl strukturell immer 0 -- gemessen FUNC-block-grounding 0 -> 19. Gate 6 des Grammatik-Reviews: 12 Befunde an graphcode, davon 0 in Ueberlappung mit irgendeiner FUNC-Regel (AO-D01 misst Relay-Knoten, IO-01 Kettenkohaerenz, R-31 blosse Verdrahtung). Schwelle 5 aus der Verteilung ABGELESEN, nicht gewaehlt: bok und graph-view-edit enden beide bei 3, graphcode geht bis 19, moneyflow bis 17. Kein info-Level -- bei Schwelle 3 truege bok 4 Befunde auf 9 Blackboxes, und readiness zaehlt info ungefiltert in den Nenner (MT-03-Praezedenz). (3) VIERTES BEIN von R-18: ein Element hat hoechstens einen compose-Elternteil (FUNC/FUNC und MOD/MOD), error. TRACE_PATTERNS begrenzt heute nur die KINDER einer Kante, nie die ELTERN -- graph_mutate legt eine zweite compose-Kante anstandslos an. 0 Verstoesse ueber fuenf Graphen, und trotzdem hart, weil jeder Rollup der Familie unter Verletzung nicht falsch sondern UNDEFINIERT ist (byModule/byFunc, RD-04-Breite, die Container-Sicht von gve). Keine eigene Regel-ID, Praezedenz CR-SM-271 Teil 2: dieselbe Aussage, derselbe naechste Schritt. EIN Befund je KIND, nicht je ueberzaehliger Kante. (4) `policy.boundaryWidth` neu (nullable, Default {warning: 5}) -- fuer Konstruierer einer MetricPolicy breaking. Prior: BREAKING (CR-SM-282): zwei Blackbox-Luecken geschlossen, und beide lassen bestehende Graphen fallen. (1) RD-04 zaehlt den FUNC-WURZELWALD, verankert am SYS-Knoten. Die Regel zaehlt Kinder je Parent; die Wurzeln des `FUNC -compose-> FUNC`-Waldes haben keinen, also war die oberste Funktionsebene unsichtbar -- gemessen: moneyflow hat 306 Wurzel-FUNCs und RD-04 meldete 0. Die MOD-Seite hatte das Problem nie, weil `SYS -compose-> MOD` eine echte Kante ist; die FUNC-Seite hat keine (`se:top-level`: der obere FUNC-Satz ist eine PROJEKTION, keine Kante). Anker ist der einzige SYS-Knoten; gibt es nicht genau einen, schweigt der Zweig statt zu raten (R-17 deckt den Fall). (2) `moduleCrossings.byModule` und die Groesse in R-04 lesen jetzt die BESITZKETTE (direkt alloziertes MOD + compose-Vorfahren) statt nur der direkten Allokation. Ein Eltern-MOD hat keine direkt allozierten FUNCs -- es kam in `byModule` nicht vor, `funcCount` war 0, und R-04 schwieg per `funcCount <= coupled` an genau der Whitebox, in die der Leser hineinklickt. `pairs` (CR-01) bleibt BEWUSST auf der direkten Zuordnung: 'wie stark haengen DIESE zwei Module aneinander' ist eine Blattebenen-Frage, ein Elternpaar meldete dieselbe Kopplung ein zweites Mal -- CR-01 ist an allen fuenf Familiengraphen zeichengleich geblieben (5/3/15/0/63). Delta gesamt: moneyflow RD-04 +1, sirail R-04 +1, bok/gve/graphcode unveraendert. (3) Die Schwelle steht in `policy.decompositionBreadth` statt als `DECOMPOSITION_BREADTH_MAX = 11` inline in rules.ts -- dieselbe Klasse, die CR-SM-236 fuer R-04 aufgeloest hat; `null` schaltet die Regel ab, Default 11 = verhaltensgleich. Das neue Pflichtfeld in MetricPolicy ist fuer Konstruierer breaking. Die Doktrin-Zahl 5 (`se:top-level`) ist bewusst NICHT der Default: `info` bei 5 haette an graphcode 20 zusaetzliche Befunde erzeugt, und readiness zaehlt `info` ungefiltert in den Nenner (`score = 1 - Verstoesse / applicable`) -- genau der Grund, aus dem MT-03 zur Messung statt zur Regel wurde (readiness.ts). Wer doktrin-streng fahren will, setzt 5. Prior: BREAKING (CR-SM-271 Teil 2): SC-04 entfaellt ersatzlos. Ein FLOW ohne SCHEMA ist kein schwaecherer Typ, sondern untypisiert — die Untergrenze ist Grammatik geworden (`FLOW -relation-> SCHEMA [1..1]`, META_MODEL 5.0.0) und meldet als drittes Bein von R-18 (error, mit candidate_targets im Kontext wie zuvor SC-04). Kein Regel-Loch: derselbe Sachverhalt, EIN Befund, nur haerter und am Gate durchgesetzt statt nur gemeldet. Der Katalog schrumpft um eine Zeile (Nenner, readiness-Zuordnung 'schema'/CDR und Golden-File-Eintrag fallen mit); der Fall zaehlt jetzt unter R-18/'arch'/PDR.
 /** Meta-model version (trace pattern constraints + format-e parser). */
-export const META_MODEL_VERSION = '4.0.0'; // BREAKING (CR-SM-266b): `cardinality` wird zum ersten Mal DURCHGESETZT statt nur angezeigt. Die Angabe stand seit Jahren an der Matrix (`FCHAIN -compose-> FUNC [1..*]`) und hatte genau zwei Leser, beide in graphcode und beide nur zum Rendern (executor-prompt, tools/report) — ein Vertrag ohne Durchsetzung. Zwei Kanten bekommen eine echte Obergrenze, beide BESITZ-Aussagen: `FUNC -allocate-> MOD [0..1]` und `FLOW -relation-> SCHEMA [0..1]`. Zwei Allokationen sind kein staerkeres Modell, sondern eine Frage ohne Antwort ('in welchem Modul liegt der Code?'); zwei SCHEMA an einem FLOW heben genau die Typgarantie auf, fuer die der GETEILTE SCHEMA-Knoten existiert — zwei Vertraege koennen divergieren, einer kann es nicht. Bewusst `0..1` und nicht `1..1`: die UNTERE Grenze haben R-22 (FUNC muss alloziert sein) und SC-04 (FLOW hat SCHEMA) laengst, und sie hier zu wiederholen waere die Doppelzaehlung aus Gate 4 — eine Ursache, zwei Befunde, ein Nenner doppelt belastet. Beide Haelften zusammen ergeben das `[1..1]` aus dem CR. Deshalb bleibt SC-04 vorerst bestehen statt 'ersatzlos zu entfallen': das Entfallen setzt die 54 FLOWs ohne SCHEMA voraus, und deren Migration haengt am selben Fenster wie moneyflow/GVE (266c). +`maxOccurs`, +`BOUNDED_PATTERNS`. Neue Kardinalitaeten stehen in der Golden-File-Oberflaeche, `check:grammar` erzwingt den Bump. Prior: BREAKING (CR-SM-266a): Pattern-Matrix 34 -> 29 und ein neuer Bedingungstyp. FUENF Patterns entfallen, jedes nach dem 366-Kriterium 'zweiter Weg neben dem einzig tragenden Pfad': D1 `ACTOR -io-> UC` (tragend: ACTOR -io-> FLOW -io-> FUNC in der FCHAIN; die Direktkante war die TYPLOSE Abkuerzung -- ein Actor-Beitrag ohne FLOW traegt kein SCHEMA. 70 Kanten ueber 6 Graphen, der groesste Migrationsposten). D2 `MOD -io-> MOD` (Modul-Kopplung ist ABLEITBAR aus FUNC-allocate-MOD x FUNC-io-FLOW-io-FUNC; eine behauptete Kante driftet, eine berechnete nicht. 12 Kanten, alle graphcodedemo). D3 `MS -compose-> MS` (Schachtelung und Abfolge sind am Meilenstein nicht unterscheidbar; MS-01 zaehlt Scope seit CR-SM-245 ausschliesslich ueber `CR -relation-> MS`. 0 Kanten familienweit -- migrationsfrei). D4 `FLOW -io-> UC` (Zweitweg neben FLOW -io-> FUNC; die UC-Grenze ERGIBT SICH aus den FLOWs der Kettenglieder, die Direktkante umgeht die Kettenzuordnung und damit IO-01 und R-21. 3 Kanten, alle graph-view-edit). D5 `SESSION -produces-> *` samt Typen, s. ONTOLOGY_VERSION. NEU: `TracePattern.where` -- ein Attribut-Praedikat am Pattern (REQ-X03). Bis hier entschied ausschliesslich das TYP-PAAR, womit ein MOD oder SYS ein FUNKTIONALES REQ 'erfuellen' konnte, ohne dass je eine Wirkkette es trug: derselbe Zweitweg wie CR-GC-366, eine Ebene hoeher, und er umging dieselben Pruefungen (IO-01/R-21 pruefen nur INNERHALB einer Kette). Jetzt: FUNC-satisfy-REQ nur auf functional/precondition/postcondition, MOD- und SYS-satisfy-REQ nur auf non-functional/risk/mitigation, FCHAIN-satisfy-REQ bewusst auf ALLE (sie IST die Wirkkette, an ihr haengen IO-01 und R-21 -- sie ist nie die Abkuerzung). TEILMENGEN-Semantik, nicht Schnittmenge: JEDER deklarierte Kind muss erlaubt sein. Die schwaechere Lesart waere das Loch gewesen, das der Abschnitt schliesst -- ein funktionales REQ zusaetzlich als non-functional zu deklarieren haette gereicht, damit ein MOD es wieder erfuellen darf, und der Zweitweg waere ueber ein Attribut zurueck. Der LEERE Fall lehnt AB: ohne Deklaration ist nicht entscheidbar, ob die Kante zulaessig ist, und 'unentscheidbar' darf nicht 'erlaubt' heissen, sonst wird das WEGLASSEN des Attributs zum Umgehungsweg (die durchsetzende Haelfte von REQ-X06; die meldende haengt an BQ-07, s. RULES_VERSION). Format-E-Parser mit im Bump (Zustaendigkeit nach CR-SM-244): +`resolveKinds`-Option, weil das Typ-Paar nicht mehr reicht; `kinds` wird zuerst aus DIESEM Text gelesen (`@kinds` steht in `op.attributes`, gehoben wird es erst vom Konsumenten), damit eine Mutation, die REQ und satisfy-Kante in EINEM Block anlegt, die eigenen Kinds sieht. Fehlt der Resolver fuer einen BESTEHENDEN Knoten, schlaegt die Kante fehl statt geraten zu werden -- dieselbe Entscheidung wie bei `resolveType`. Ausserdem: `VALID_TRACE_TYPES` ist jetzt aus `TraceType.options` ABGELEITET statt abgeschrieben -- die Kopie trug `produces` noch, als das Enum es schon verloren hatte. Migration D1/D2/D4 je Bestandskante: FLOW einfuehren bzw. auf das Kettenglied umhaengen, sonst loeschen. D3/D5: keine. Prior: BREAKING, zwei Anlaesse in einer Zahl. (1) Nachtrag zu CR-GC-366: dort entfiel das Trace-Pattern `FUNC -satisfy-> UC`, gebumpt wurde aber nur ONTOLOGY_VERSION — nach der in CR-SM-244 festgeschriebenen Zustaendigkeit (meta-model.ts + format-e-Parser -> META_MODEL_VERSION) fehlte der Bump hier. Eine Entfernung ist major; dass kein Konsument semver-maessig auf diese Konstante verzweigt (schema-guard.ts keyt bewusst auf einen DDL-Fingerprint), macht sie nicht kleiner, nur folgenlos fuer die Bump-Kette. (2) CR-SM-251: `hydrateAttrValue` hydriert typ-geleitet ueber ELEMENT_ATTRIBUTES — boolean/number-Attribute kamen ueber BEIDE Format-E-Pfade als String an, womit die elf `=== true`-Vergleiche in den Regeln jede Ausnahme (concept/external/safety_relevant/spike) ins Leere laufen liessen und ein Export-Reimport bestehende Ausnahmen still entwertete. Verhaltensaenderung am Parser, also hier verbucht. Prior: -REQ→MOD allocate pattern removed (CR-228 A); +FUNC→FUNC compose (blackbox function decomposition)
+export const META_MODEL_VERSION = '5.0.0'; // BREAKING (CR-SM-271 Teil 2): `FLOW -relation-> SCHEMA` wird `1..1` — die erste DURCHGESETZTE Untergrenze (minOccurs/REQUIRED_PATTERNS; nur exakt-`1`, die `1..*`-compose-Untergrenzen bleiben Vollstaendigkeits-Warnungen ihrer Regeln). Migrationsbestand vorab abgetragen: graphcode 2, sigloch-modules 4, graph-view-edit 5 (je durchs Gate), urbanmobility-Fixture geloescht (39, Spike ohne Referenzen); sirail 4 offen (EXPORT_PENDING-Divergenz seit 2026-08-18).
 export * from './ontology.js';
 export * from './rules.js';
 export * from './conformance-rules.js';
@@ -21,6 +21,7 @@ export * from './fmea-rules.js';
 export * from './view-rules.js';
 export * from './cr-quality-rules.js';
 export * from './near-duplicate-rules.js';
+export * from './similarity.js';
 export * from './ao-rules.js';
 export * from './quality-rules.js';
 export * from './analysis-freshness-rules.js';

package/dist/se/meta-model.d.ts

@@ -64,8 +64,55 @@ export interface TraceShape {
 export declare function maxOccurs(cardinality: TracePattern['cardinality']): number;
 /** Die Patterns mit einer echten Obergrenze — die Arbeitsliste des Kardinalitaets-Beins. */
 export declare const BOUNDED_PATTERNS: readonly TracePattern[];
+/**
+ * Die Untergrenze eines Kardinalitaets-Ausdrucks — `0`, wo keine gilt.
+ * Gegenstueck zu `maxOccurs` (CR-SM-271 Teil 2).
+ */
+export declare function minOccurs(cardinality: TracePattern['cardinality']): number;
+/**
+ * Die Patterns, deren Untergrenze DURCHGESETZT wird — nur exakt-`1` (CR-SM-271 Teil 2).
+ *
+ * Bewusst NICHT `minOccurs(p.cardinality) >= 1`: die `1..*`-compose-Patterns (SYS→UC,
+ * UC→FCHAIN, UC→REQ, FCHAIN→FUNC) tragen ihre Untergrenze seit jeher als
+ * Vollstaendigkeits-WARNUNG (UC-01, R-15, …) — ein SYS existiert legitim, BEVOR sein erster
+ * UC modelliert ist, und ein error-Bein wuerde jeden Kaltstart per Delta-Semantik blockieren.
+ * Sie hier mitzunehmen waere zudem die Doppelzaehlung aus Gate 4: eine Ursache, zwei Befunde.
+ * Exakt-`1` dagegen ist eine Grammatik-Aussage ohne legitimen Zwischenzustand: ein FLOW ohne
+ * SCHEMA ist untypisiert, nicht unfertig — sein SCHEMA gehoert in DENSELBEN Batch.
+ */
+export declare const REQUIRED_PATTERNS: readonly TracePattern[];
 /**
  * Check if a trace matches a valid pattern in the meta-model.
  * Uses element types (not IDs) plus — where a pattern declares one — an attribute predicate.
  */
 export declare function isValidTrace(trace: TraceShape, patterns?: TracePattern[]): boolean;
+/**
+ * Warum eine Kante abgelehnt wurde — das Diagnose-Gegenstueck zu `isValidTrace` (CR-SM-280).
+ *
+ * `isValidTrace` bleibt die URTEILENDE Funktion; dieser Helfer beschreibt nur, was dort
+ * ohnehin passiert ist. Kein zweiter Entscheidungspfad: `traceRejection(t) === undefined`
+ * gilt genau dann, wenn `isValidTrace(t)` — die Invariante steht als Test.
+ *
+ * Der Anlass: seit CR-SM-266 B tragen drei satisfy-Patterns ein `where` auf den `kinds` des
+ * Ziels. Fuer die faellt `isValidTrace` auf `false` zurueck, und R-18 formulierte daraus
+ * "FUNC -> REQ is not a valid satisfy pattern" — sachlich falsch, das Pattern existiert.
+ * Wer die Meldung las, suchte einen Grammatikbruch statt eines Kind-Mismatches.
+ */
+export type TraceRejection = 
+/** Kein Pattern kennt dieses Typ-Paar (+ Kantentyp, + Label). Die Grammatik verbietet es. */
+{
+    reason: 'no-pattern';
+}
+/** Ein Pattern passt, aber sein Praedikat-Ende deklariert keine Kinds — unentscheidbar. */
+ | {
+    reason: 'kinds-undeclared';
+    pattern: TracePattern;
+}
+/** Ein Pattern passt, aber die deklarierten Kinds liegen nicht in der erlaubten Liste. */
+ | {
+    reason: 'kinds-mismatch';
+    pattern: TracePattern;
+    declared: readonly string[];
+};
+/** `undefined`, wenn die Kante gueltig ist — sonst der Grund. */
+export declare function traceRejection(trace: TraceShape, patterns?: TracePattern[]): TraceRejection | undefined;

package/dist/se/meta-model.js

@@ -74,12 +74,16 @@ export const TRACE_PATTERNS = [
     // die Typgarantie auf, fuer die der geteilte SCHEMA-Knoten existiert (CR-SM-266 C): zwei
     // Vertraege koennen divergieren, einer kann es nicht.
     //
-    // Nur die OBERE Grenze steht hier, bewusst als `0..1` und nicht `1..1`. Die untere haben
-    // R-22 (FUNC muss alloziert sein) und SC-04 (FLOW hat SCHEMA) laengst — sie hier zu
-    // wiederholen waere die Doppelzaehlung aus Gate 4: eine Ursache, zwei Befunde, ein Nenner
-    // doppelt belastet. Die beiden Haelften ergeben zusammen das `[1..1]` des CR.
+    // `FUNC -allocate-> MOD` traegt nur die OBERE Grenze (`0..1`): seine Untergrenze bleibt
+    // R-22 (warning) — eine frisch angelegte FUNC ist legitim noch unalloziert, und ein
+    // error-Bein wuerde jedes schrittweise Authoring per Delta-Semantik blockieren.
+    //
+    // CR-SM-271 Teil 2: `FLOW -relation-> SCHEMA` ist `1..1` — beide Grenzen Grammatik. Ein
+    // FLOW ohne SCHEMA ist kein schwaecherer Typ, sondern untypisiert; die fruehere Untergrenze
+    // SC-04 (warning) ist damit ersatzlos entfallen (Grammatik ersetzt Regel, das urspruengliche
+    // Ziel von CR-SM-266 C). Durchgesetzt als drittes Bein von R-18 (s. REQUIRED_PATTERNS).
     { source: 'FUNC', target: 'MOD', type: 'allocate', cardinality: '0..1', description: 'Function deployed in exactly one module' },
-    { source: 'FLOW', target: 'SCHEMA', type: 'relation', cardinality: '0..1', description: 'Flow data format defined by exactly one schema' },
+    { source: 'FLOW', target: 'SCHEMA', type: 'relation', cardinality: '1', description: 'Flow data format defined by exactly one schema' },
     // CR-228: REQ→MOD allocate removed — a MOD does not own a REQ. Physical NFRs use
     // MOD→satisfy→REQ, behavioral NFRs FCHAIN→satisfy→REQ; structural constraints are
     // rules, not REQs. R-18 now flags any REQ→MOD allocate edge as invalid.
@@ -148,6 +152,27 @@ export function maxOccurs(cardinality) {
 }
 /** Die Patterns mit einer echten Obergrenze — die Arbeitsliste des Kardinalitaets-Beins. */
 export const BOUNDED_PATTERNS = TRACE_PATTERNS.filter(p => maxOccurs(p.cardinality) < Infinity);
+/**
+ * Die Untergrenze eines Kardinalitaets-Ausdrucks — `0`, wo keine gilt.
+ * Gegenstueck zu `maxOccurs` (CR-SM-271 Teil 2).
+ */
+export function minOccurs(cardinality) {
+    if (cardinality === undefined)
+        return 0;
+    return cardinality === '1' || cardinality === '1..*' ? 1 : 0;
+}
+/**
+ * Die Patterns, deren Untergrenze DURCHGESETZT wird — nur exakt-`1` (CR-SM-271 Teil 2).
+ *
+ * Bewusst NICHT `minOccurs(p.cardinality) >= 1`: die `1..*`-compose-Patterns (SYS→UC,
+ * UC→FCHAIN, UC→REQ, FCHAIN→FUNC) tragen ihre Untergrenze seit jeher als
+ * Vollstaendigkeits-WARNUNG (UC-01, R-15, …) — ein SYS existiert legitim, BEVOR sein erster
+ * UC modelliert ist, und ein error-Bein wuerde jeden Kaltstart per Delta-Semantik blockieren.
+ * Sie hier mitzunehmen waere zudem die Doppelzaehlung aus Gate 4: eine Ursache, zwei Befunde.
+ * Exakt-`1` dagegen ist eine Grammatik-Aussage ohne legitimen Zwischenzustand: ein FLOW ohne
+ * SCHEMA ist untypisiert, nicht unfertig — sein SCHEMA gehoert in DENSELBEN Batch.
+ */
+export const REQUIRED_PATTERNS = TRACE_PATTERNS.filter(p => p.cardinality === '1');
 /**
  * Check if a trace matches a valid pattern in the meta-model.
  * Uses element types (not IDs) plus — where a pattern declares one — an attribute predicate.
@@ -159,3 +184,25 @@ export function isValidTrace(trace, patterns = TRACE_PATTERNS) {
         (!p.label || p.label === trace.label) &&
         (!p.where || satisfiesPredicate(p.where, trace)));
 }
+/** Passt das Pattern auf das Typ-Paar (Kantentyp, Label) — OHNE das `where` zu befragen? */
+function matchesShape(p, trace) {
+    return (p.source === '*' || p.source === trace.source) &&
+        (p.target === '*' || p.target === trace.target) &&
+        p.type === trace.type &&
+        (!p.label || p.label === trace.label);
+}
+/** `undefined`, wenn die Kante gueltig ist — sonst der Grund. */
+export function traceRejection(trace, patterns = TRACE_PATTERNS) {
+    if (isValidTrace(trace, patterns))
+        return undefined;
+    // Nur die Patterns, die am Typ-Paar ueberhaupt greifen. Gibt es keins, war es die Matrix.
+    // Gibt es mehrere (kaeme durch ein zweites `where` am selben Paar), entscheidet das erste —
+    // sie haben es alle abgelehnt, und der erste Grund ist so wahr wie jeder andere.
+    const candidate = patterns.find(p => matchesShape(p, trace) && p.where);
+    if (!candidate?.where)
+        return { reason: 'no-pattern' };
+    const declared = normalizeReqKinds(candidate.where.on === 'source' ? trace.sourceKinds : trace.targetKinds);
+    return declared.length === 0
+        ? { reason: 'kinds-undeclared', pattern: candidate }
+        : { reason: 'kinds-mismatch', pattern: candidate, declared };
+}

package/dist/se/metric-rules.d.ts

@@ -18,7 +18,7 @@ import type { MetricPolicy } from './policy.js';
 export declare function mt01Instability(graph: OntologyGraph, policy: MetricPolicy): RuleViolation[];
 /**
  * MT-02: LCOM4 (Lack of Cohesion — component count).
- * MOD with allocated FUNCs that share no common io/satisfy targets → cohesion problem.
+ * MOD with allocated FUNCs that share no common io targets → cohesion problem.
  * `policy.lcom4.info` ≤ LCOM4 < `policy.lcom4.warning` → info, darüber warning.
  *
  * CR-SM-233: die Stufen sind Eingabe, `null` heißt messen statt urteilen.
@@ -85,6 +85,25 @@ export interface ModuleMetrics {
         external: number;
         ratio: number;
     } | null;
+    /**
+     * CR-SM-301 — Martins *Stable Dependencies Principle*, als MESSUNG und ausdruecklich als
+     * KEINE Regel: die Zahl der Vertraege, die dieses Modul von einem WENIGER stabilen Lieferanten
+     * bezieht (`I_Lieferant > I_Bezieher`). Abhaengigkeiten „bergauf".
+     *
+     * Warum keine Regel: CR-SM-298 hat genau das versucht und ist an Gate 7 gescheitert. Ueber
+     * 19 Familiengraphen laufen 25 von 250 Abhaengigkeiten bergauf, aber der MEDIAN der
+     * Stabilitaetsluecke ist **0.10** — bei einer Vertragsmasse von im Mittel 5 ist das ein
+     * Vertrag Unterschied, also Rauschen. Filtert man auf Luecke > 0.2 und beide Enden >= 3
+     * Vertraege, bleiben 3 von 25, davon zwei in einem Wegwerf-Trial und einer Demo. Eine Regel
+     * haette zwei erfundene Schwellen gebraucht, um EINEN Befund zu produzieren.
+     *
+     * Was bleibt, ist die Zahl. `graph_metrics` traegt sie in jeder Modulzeile, ein Mensch liest
+     * sie neben `instability` und deutet sie — Praezedenz MT-03 (CR-SM-223) und `cohesion` eine
+     * Zeile weiter oben: messen, nicht urteilen, ohne Katalogeintrag und ohne Nenner-Anteil.
+     *
+     * `null`, wo `instability` es auch ist — ohne Kopplung gibt es keine Richtung.
+     */
+    uphillDependencies: number | null;
 }
 /**
  * Per-module architecture metrics as NUMBERS — one row per MOD, threshold or not

package/dist/se/metric-rules.js

@@ -1,5 +1,8 @@
 import { decomposedFuncs } from './rules.js';
 import { indexOf } from './graph-index.js';
+import { moduleCrossings } from './module-crossings.js';
+/** Geteilte leere Menge — spart je Modul zwei Allokationen in `measureModulesUncached`. */
+const EMPTY_SET = new Set();
 /**
  * MT-01: Module Instability (CR-165: indirect via allocate-path).
  * I = fan_out / (fan_in + fan_out) > `policy.instability` → warning.
@@ -27,6 +30,10 @@ export function mt01Instability(graph, policy) {
                 severity: 'warning',
                 element_id: m.moduleId,
                 message: `${m.moduleName} has instability ${Math.round(m.instability * 100)}% (>${threshold * 100}%). fan_in=${m.fanIn}, fan_out=${m.fanOut}`,
+                // CR-SM-288: `> threshold` ist exklusiv, also liegt `threshold` selbst noch im Budget.
+                // Die Masse ist hier ein Bruch, kein Zaehler — sie wird nie mit der einer anderen Stufe
+                // verrechnet (CR-SM-287 vergleicht lexikographisch, nie summierend).
+                context: { value: m.instability, threshold },
             });
         }
     }
@@ -34,7 +41,7 @@ export function mt01Instability(graph, policy) {
 }
 /**
  * MT-02: LCOM4 (Lack of Cohesion — component count).
- * MOD with allocated FUNCs that share no common io/satisfy targets → cohesion problem.
+ * MOD with allocated FUNCs that share no common io targets → cohesion problem.
  * `policy.lcom4.info` ≤ LCOM4 < `policy.lcom4.warning` → info, darüber warning.
  *
  * CR-SM-233: die Stufen sind Eingabe, `null` heißt messen statt urteilen.
@@ -49,18 +56,22 @@ export function mt02Lcom4(graph, policy) {
         if (m.lcom4 === null)
             continue;
         // CR-SM-263: ein MOD aus lauter zerlegten Bloecken ist per Konstruktion zerfallen —
-        // LCOM4 verbindet ueber geteilte io/satisfy-ZIELE, und CR-SM-256 hat festgehalten, dass
+        // LCOM4 verbindet ueber geteilte io-ZIELE, und CR-SM-256 hat festgehalten, dass
         // ein Rollup genau die nicht traegt. Die Regel war dort nicht streng, sondern
         // unerfuellbar: gruen wird sie erst mit der Kante, die CR-SM-256 fuer falsch erklaert.
         // Die MESSUNG bleibt (`moduleMetrics` liefert `lcom4` unveraendert) — nur das Urteil faellt.
         if (m.rollupContainer)
             continue;
         const message = `${m.moduleName} has LCOM4=${m.lcom4} (${m.allocatedFuncs} FUNCs in ${m.lcom4} disconnected groups)`;
+        // CR-SM-288: EIN Budget fuer beide Stufen — `steps.warning - 1` ist der groesste LCOM4,
+        // der noch drin liegt. Die `info`-Stufe meldet frueher, aber sie meldet keine Ueberschreitung;
+        // ihre Masse ist 0.
+        const context = { value: m.lcom4, threshold: steps.warning - 1 };
         if (m.lcom4 >= steps.info && m.lcom4 < steps.warning) {
-            violations.push({ rule_id: 'MT-02', severity: 'info', element_id: m.moduleId, message });
+            violations.push({ rule_id: 'MT-02', severity: 'info', element_id: m.moduleId, message, context });
         }
         else if (m.lcom4 >= steps.warning) {
-            violations.push({ rule_id: 'MT-02', severity: 'warning', element_id: m.moduleId, message });
+            violations.push({ rule_id: 'MT-02', severity: 'warning', element_id: m.moduleId, message, context });
         }
     }
     return violations;
@@ -157,58 +168,37 @@ function measureModulesUncached(graph) {
     // Eine zweite Definition hier waere ein zweiter Weg zu derselben Aussage (Gate 2).
     const decomposed = decomposedFuncs(graph);
     const rows = [];
-    // --- CR-SM-264: die indirekte Kopplung UMGEDREHT ---
+    // --- CR-SM-293: fan_in/fan_out sind KOPPLUNG, und Kopplung ist der Vertrag am Rand ---
     //
-    // Vorher lief je MOD eine Schleife ueber ALLE Traces (`MOD x T`) — nach Teil c die teuerste
-    // verbliebene Form im Katalog, und sie traegt MT-01 UND MT-02, weil beide dieselbe Rechnung
-    // lesen. Der Index loest sie nicht auf: die Frage ist nicht "welche Kanten haengen an diesem
-    // Knoten", sondern "welche Kanten kreuzen diese Modulgrenze".
+    // Bis hierher zaehlte die Rechnung JEDE Kante, deren eines Ende einem Modul gehoerte. Ueber
+    // 19 Familiengraphen waren das 3281 Kanten, von denen nur 1117 (34 %) Kopplung sind:
     //
-    // Also einmal ueber die Traces statt einmal je Modul. Je Kante steht ueber die
-    // allocate-Zuordnung fest, welche Module ihre Enden besitzen; nur die zaehlen mit. Ein
-    // Element allokiert praktisch immer auf hoechstens ein MOD, die innere Schleife ist damit
-    // kurz — und das Ergebnis ist Zaehler fuer Zaehler dasselbe.
-    const modIds = idx.idsOfType('MOD');
-    const ownersOf = new Map(); // alloziertes Element -> seine MODs
-    const membersOf = new Map(); // MOD -> seine allozierten Elemente
-    for (const t of idx.tracesOfType('allocate')) {
-        if (!modIds.has(t.target))
-            continue;
-        const owners = ownersOf.get(t.source);
-        if (owners)
-            owners.push(t.target);
-        else
-            ownersOf.set(t.source, [t.target]);
-        const members = membersOf.get(t.target);
-        if (members)
-            members.add(t.source);
-        else
-            membersOf.set(t.target, new Set([t.source]));
-    }
-    const indirectOutOf = new Map();
-    const indirectInOf = new Map();
-    const bump = (m, key) => { m.set(key, (m.get(key) ?? 0) + 1); };
-    for (const t of graph.traces) {
-        if (t.type === 'allocate')
-            continue; // allocate itself doesn't count as coupling
-        for (const owner of ownersOf.get(t.source) ?? []) {
-            if (!membersOf.get(owner).has(t.target) && t.target !== owner)
-                bump(indirectOutOf, owner);
-        }
-        for (const owner of ownersOf.get(t.target) ?? []) {
-            if (!membersOf.get(owner).has(t.source) && t.source !== owner)
-                bump(indirectInOf, owner);
-        }
-    }
+    //   fan_in  2164 = 674 `allocate` (das ist die MODULGROESSE) + 610 `FLOW -io-> FUNC`
+    //                + 348 `FCHAIN -compose-> FUNC` + 255 `CR -relation-> FUNC` + 277 Rest
+    //   fan_out 1117 = 507 `FUNC -io-> FLOW` + 501 `FUNC -satisfy-> REQ` + 109 Rest
+    //
+    // Drei Befunde, jeder fuer sich hinreichend: ein Modul wurde STABILER, indem es Funktionen
+    // bekam; fast die halbe fan_out war `satisfy`, also Spezifikation und keine Laufzeitkopplung
+    // (dieselbe Begruendung, mit der CR-SM-297 sie aus LCOM4 genommen hat); und 70 Kanten liefen
+    // ueber `MOD -io-> MOD`, ein Muster, das CR-SM-266 D2 aus TRACE_PATTERNS geloescht hat.
+    //
+    // Jetzt liest MT-01 `moduleCrossings` — DIESELBE Definition von Rand und dieselbe Zaehlbasis
+    // (verschiedene Vertraege statt Einzelquerungen), die CR-01, R-04 und BW-02 seit CR-SM-274/276
+    // benutzen. Eine zweite Vorstellung davon, was eine Kreuzung ist, war genau der Defekt, den
+    // jener CR beseitigt hat; MT-01 hatte bis hierher noch eine dritte.
+    //
+    // RICHTUNG (CR-SM-293, Entscheidung des Auftraggebers): der KONSUMENT haengt ab. Wer nach
+    // draussen liefert, wird gebraucht -> `afferentContracts` -> fan_in. Wer von draussen bezieht,
+    // haengt ab -> `efferentContracts` -> fan_out. Das ist Martins Ca/Ce und kehrt das bisherige
+    // Urteil an reinen Verbrauchermodulen um: sie lasen `I = 0` (maximal stabil) und muessen `1`
+    // lesen. Die Konvention stand vorher NIRGENDS im Repo — sie war nie entschieden, nur codiert.
+    const crossings = moduleCrossings(graph);
     for (const mod of mods) {
         const allocated = idx.in(mod.id, 'allocate').map(t => t.source);
         const modFuncIds = new Set(allocated);
-        // --- MT-01: fan-in / fan-out (CR-165, indirect via the allocate path) ---
-        const directOut = idx.out(mod.id, 'io').filter(t => t.target !== mod.id).length +
-            idx.out(mod.id, 'compose').filter(t => t.target !== mod.id).length;
-        const directIn = idx.in(mod.id, 'io').length + idx.in(mod.id, 'compose').length + idx.in(mod.id, 'allocate').length;
-        const fanOut = directOut + (indirectOutOf.get(mod.id) ?? 0);
-        const fanIn = directIn + (indirectInOf.get(mod.id) ?? 0);
+        // --- MT-01: fan-in / fan-out als querende VERTRAEGE je Richtung (CR-SM-293) ---
+        const fanIn = (crossings.afferentContracts.get(mod.id) ?? EMPTY_SET).size;
+        const fanOut = (crossings.efferentContracts.get(mod.id) ?? EMPTY_SET).size;
         const instability = fanIn + fanOut === 0 ? null : fanOut / (fanIn + fanOut);
         rows.push({
             moduleId: mod.id,
@@ -220,28 +210,77 @@ function measureModulesUncached(graph) {
             lcom4: lcom4Of(graph, allocated),
             rollupContainer: allocated.length >= 2 && allocated.every(f => decomposed.has(f)),
             cohesion: cohesionOf(pairs, modFuncIds),
+            // CR-SM-301: braucht die Instabilitaet ALLER Module, also zweiter Durchgang unten.
+            uphillDependencies: null,
         });
     }
+    // --- CR-SM-301: Abhaengigkeiten „bergauf" (Martin, Stable Dependencies Principle) ---
+    //
+    // Ein Vertrag, den `m` von draussen bezieht, laeuft bergauf, wenn sein Lieferant WENIGER
+    // stabil ist als `m` selbst. Lieferant eines Vertrags ist jedes Modul, das ihn ueber seinen
+    // Rand LIEFERT (`afferentContracts`) — dieselbe Menge, aus der oben `fanIn` kommt, also
+    // dieselbe Zaehlbasis und dieselbe Besitzkette. Kein zweiter Kopplungsbegriff.
+    //
+    // Gezaehlt wird JE VERTRAG, nicht je Lieferant-Vertrag-Paar: ein Vertrag mit drei Lieferanten
+    // ist EINE Abhaengigkeit, von denen einer bergauf liegt. Andernfalls waere die Zahl
+    // hub-empfindlich — dieselbe Begruendung, mit der CR-SM-274 die Vertraege statt der
+    // Einzelquerungen zaehlt.
+    const suppliersOf = new Map();
+    for (const [mod, set] of crossings.afferentContracts) {
+        for (const c of set) {
+            const list = suppliersOf.get(c);
+            if (list)
+                list.push(mod);
+            else
+                suppliersOf.set(c, [mod]);
+        }
+    }
+    const instabilityOf = new Map(rows.map(r => [r.moduleId, r.instability]));
+    for (const row of rows) {
+        const mine = row.instability;
+        if (mine === null)
+            continue; // ohne Kopplung keine Richtung — `null` bleibt stehen
+        let uphill = 0;
+        for (const contract of crossings.efferentContracts.get(row.moduleId) ?? EMPTY_SET) {
+            for (const supplier of suppliersOf.get(contract) ?? []) {
+                if (supplier === row.moduleId)
+                    continue;
+                const theirs = instabilityOf.get(supplier);
+                if (theirs !== null && theirs !== undefined && theirs > mine) {
+                    uphill += 1;
+                    break;
+                }
+            }
+        }
+        row.uphillDependencies = uphill;
+    }
     return rows;
 }
 /** MT-02 core: connected components over the allocated FUNCs. null below 2 FUNCs. */
 function lcom4Of(graph, funcIds) {
     if (funcIds.length < 2)
         return null;
-    // Two FUNCs are connected if they share a common io/satisfy target.
+    // Zwei FUNCs sind verbunden, wenn sie ein gemeinsames `io`-Ziel haben — und NUR dann.
+    //
+    // CR-SM-297: `satisfy` ist aus der Verbindung gefallen. LCOM4 misst Datenkopplung; `satisfy`
+    // ist eine SPEZIFIKATIONS-Beziehung, und zwei FUNCs, die dasselbe REQ erfuellen, koennen zur
+    // Laufzeit vollstaendig entkoppelt sein. Die Wirkung ging dabei nur in eine Richtung:
+    // `satisfy` VERBINDET Gruppen, senkte also LCOM4 und liess Module kohaesiver aussehen, als
+    // ihr Datenfluss hergibt.
+    //
+    // Der Modellierungsgrund wiegt schwerer als der Messgrund: teilen sich zwei Funktionen ein
+    // Requirement, ist das REQUIREMENT zu zerlegen — nicht die Kohaesionsmessung zu beschoenigen.
+    // RD-02 sagt bereits das Verwandte (ein Parent-REQ mit direktem FUNC-satisfy; der satisfy
+    // gehoert an die Kinder).
+    //
     // CR-SM-264: die ausgehenden Kanten kommen aus dem Index. Vorher lief je alloziertem FUNC
-    // ein Vollscan ueber alle Traces — MOD x FUNC x T. Die Einfuegereihenfolge in `targets`
-    // bleibt identisch (io vor satisfy war sie nicht; der Index liefert beide Listen in
-    // Graph-Reihenfolge, und `targets` ist ein Set, dessen Inhalt hier nur auf Mitgliedschaft
-    // geprueft wird).
+    // ein Vollscan ueber alle Traces — MOD x FUNC x T.
     const idx = indexOf(graph);
     const funcTargets = new Map();
     for (const fid of funcIds) {
         const targets = new Set();
         for (const t of idx.out(fid, 'io'))
             targets.add(t.target);
-        for (const t of idx.out(fid, 'satisfy'))
-            targets.add(t.target);
         funcTargets.set(fid, targets);
     }
     const parent = new Map();