@sigloch/contracts 6.3.0 → 10.0.0

package/dist/se/meta-model.js

@@ -1,3 +1,8 @@
+import { normalizeReqKinds } from './ontology.js';
+/** Die Kinds, die eine Wirkkette bzw. ein Verhalten traegt. */
+const BEHAVIOURAL_KINDS = ['functional', 'precondition', 'postcondition'];
+/** Die Kinds, die eine Struktur (Modul/System) traegt. */
+const STRUCTURAL_KINDS = ['non-functional', 'risk', 'mitigation'];
 export const TRACE_PATTERNS = [
     // ── compose (parent → child) ──
     { source: 'SYS', target: 'SYS', type: 'compose', cardinality: '0..*', description: 'System decomposes into subsystems' },
@@ -15,11 +20,25 @@ export const TRACE_PATTERNS = [
     { source: 'FLOW', target: 'ACTOR', type: 'io', description: 'Flow delivers to actor' },
     { source: 'FUNC', target: 'FLOW', type: 'io', description: 'Function outputs to flow' },
     { source: 'FLOW', target: 'FUNC', type: 'io', description: 'Flow feeds into function' },
-    { source: 'ACTOR', target: 'UC', type: 'io', description: 'Actor triggers use case' },
-    { source: 'FLOW', target: 'UC', type: 'io', description: 'Flow feeds use case' },
-    { source: 'MOD', target: 'MOD', type: 'io', description: 'Module communicates with module (ACL)' },
+    // CR-SM-266 D1: `ACTOR -io-> UC` ENTFAELLT (BREAKING). Der tragende Pfad existiert und ist
+    // typisiert: `ACTOR -io-> FLOW -io-> FUNC`, FUNC in der FCHAIN des UC. Die Direktkante war
+    // die TYPLOSE Abkuerzung daneben — ein Actor-Beitrag ohne FLOW traegt kein SCHEMA und
+    // entzieht sich damit derselben Typgarantie, die fuer jeden anderen Fluss gilt. Migration
+    // je Bestandskante: FLOW einfuehren oder Kante loeschen (70 Kanten ueber 6 Graphen).
+    // CR-SM-266 D2: `MOD -io-> MOD` ENTFAELLT (BREAKING). Modul-Kopplung ist vollstaendig
+    // ABLEITBAR: `FUNC -allocate-> MOD` x `FUNC -io-> FLOW -io-> FUNC` ergibt die
+    // Modul-Ebenen-Projektion. Eine BEHAUPTETE Kopplungskante kann von der tatsaechlichen
+    // driften, eine berechnete nicht — und die behauptete gewann, weil sie billiger war.
+    // Soll-Architektur wird als REQ (non-functional) modelliert, nicht als Kante.
+    // CR-SM-266 D4: `FLOW -io-> UC` ENTFAELLT (BREAKING). Zweitweg neben `FLOW -io-> FUNC` mit
+    // FUNC in der FCHAIN des UC. Die UC-Grenze ERGIBT SICH aus den FLOWs der Kettenglieder; eine
+    // direkte FLOW-UC-Kante umgeht die Kettenzuordnung und damit IO-01 und R-21.
     // ── satisfy (implementation) ──
-    { source: 'FUNC', target: 'REQ', type: 'satisfy', description: 'Function implements requirement' },
+    {
+        source: 'FUNC', target: 'REQ', type: 'satisfy',
+        where: { on: 'target', field: 'kinds', allowed: BEHAVIOURAL_KINDS },
+        description: 'Function implements requirement — behavioural kinds only',
+    },
     // CR-GC-366: `FUNC -satisfy-> UC` ENTFAELLT (BREAKING). Es war ein zweiter, redundanter Weg
     // vom Verhalten zum Use Case neben dem einzig tragenden `UC -compose-> FCHAIN -compose-> FUNC`.
     // Zwei Wege = zwei Wahrheiten: eine FUNC konnte einen UC bedienen, ohne in dessen Wirkkette zu
@@ -29,14 +48,42 @@ export const TRACE_PATTERNS = [
     // stand ohnehin in einer FCHAIN); die restlichen 13 sind der Migrationsanlass, nicht ein
     // Argument fuer das Pattern. Ersatz: die FUNC in die FCHAIN des UC aufnehmen (R-30).
     // CR-154: NFR satisfy — non-functional REQs can be satisfied by chains, modules, or the system
+    //
+    // CR-SM-266 B: die drei strukturellen satisfy-Patterns tragen jetzt ein `where`. Ohne es
+    // konnte ein MOD oder SYS ein FUNKTIONALES REQ erfuellen, ohne dass eine Wirkkette es traegt
+    // — der Zweitweg aus CR-GC-366, eine Ebene hoeher. Die FCHAIN behaelt bewusst ALLE Kinds:
+    // sie IST die Wirkkette, an ihr haengen IO-01 und R-21, sie ist also nie die Abkuerzung.
     { source: 'FCHAIN', target: 'REQ', type: 'satisfy', description: 'Function chain satisfies end-to-end NFR (e.g. latency)' },
-    { source: 'MOD', target: 'REQ', type: 'satisfy', description: 'Module satisfies budget NFR (e.g. uptime, memory)' },
-    { source: 'SYS', target: 'REQ', type: 'satisfy', description: 'System satisfies system-level NFR (e.g. availability)' },
+    {
+        source: 'MOD', target: 'REQ', type: 'satisfy',
+        where: { on: 'target', field: 'kinds', allowed: STRUCTURAL_KINDS },
+        description: 'Module satisfies budget NFR (e.g. uptime, memory) — structural kinds only',
+    },
+    {
+        source: 'SYS', target: 'REQ', type: 'satisfy',
+        where: { on: 'target', field: 'kinds', allowed: STRUCTURAL_KINDS },
+        description: 'System satisfies system-level NFR (e.g. availability) — structural kinds only',
+    },
     // ── verify (INCOSE: test verifies requirement) ──
     { source: 'TEST', target: 'REQ', type: 'verify', description: 'Test verifies requirement' },
     // ── allocate (deployment/assignment) ──
-    { source: 'FUNC', target: 'MOD', type: 'allocate', description: 'Function deployed in module' },
-    { source: 'FLOW', target: 'SCHEMA', type: 'relation', description: 'Flow data format defined by schema' },
+    // CR-SM-266b A/C: OBERGRENZEN als Grammatik. Beide Kanten sind Besitz-Aussagen, und Besitz
+    // ist nicht mehrfach vergebbar — eine FUNC wohnt in EINEM Modul, ein FLOW traegt EINEN
+    // Datenvertrag. Zwei Allokationen sind kein "staerkeres" Modell, sondern eine Frage ohne
+    // Antwort ("in welchem Modul liegt der Code?"), und zwei SCHEMA an einem FLOW heben genau
+    // die Typgarantie auf, fuer die der geteilte SCHEMA-Knoten existiert (CR-SM-266 C): zwei
+    // Vertraege koennen divergieren, einer kann es nicht.
+    //
+    // `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: '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.
@@ -44,24 +91,118 @@ export const TRACE_PATTERNS = [
     { source: 'MS', target: 'FUNC', type: 'compose', description: 'Milestone includes function' },
     { source: 'MS', target: 'REQ', type: 'compose', description: 'Milestone includes requirement' },
     { source: 'MS', target: 'UC', type: 'compose', description: 'Milestone includes use case' },
-    { source: 'MS', target: 'MS', type: 'compose', description: 'Sub-milestone' },
-    { source: 'MS', target: 'MS', type: 'relation', label: 'depends-on', description: 'Milestone dependency' },
+    // CR-SM-266 D3: `MS -compose-> MS` ENTFAELLT (BREAKING). Zwei Kantenarten zwischen denselben
+    // zwei Meilensteinen sagten dasselbe auf zwei Arten — Schachtelung und Abfolge sind an einem
+    // Meilenstein nicht unterscheidbar, MS-01 zaehlte den Scope einmal ueber `CR -relation-> MS`
+    // (seit CR-SM-245 der einzige Weg) und die compose-Kante trug nichts mehr bei. `relation`
+    // bleibt als EINZIGE MS-MS-Kante, Semantik: Ordnung/Abfolge (Vorgaenger → Nachfolger).
+    // Migration: keine — 0 solche Kanten in allen 9 aktiven Familie-Graphen (gemessen 2026-08-25).
+    { source: 'MS', target: 'MS', type: 'relation', label: 'depends-on', description: 'Milestone order: predecessor → successor' },
     { source: 'CR', target: 'MS', type: 'relation', description: 'CR assigned to milestone' },
     // ── CR traceability (CR-155: CR tracks mutated elements) ──
     { source: 'CR', target: 'UC', type: 'relation', description: 'CR affects use case' },
     { source: 'CR', target: 'REQ', type: 'relation', description: 'CR affects requirement' },
     { source: 'CR', target: 'FUNC', type: 'relation', description: 'CR affects function' },
     { source: 'CR', target: 'MOD', type: 'relation', description: 'CR affects module' },
-    // ── produces (audit lineage) ──
-    { source: 'SESSION', target: '*', type: 'produces', category: 'audit', description: 'Session produced/modified element' },
+    // CR-SM-266 D5: `SESSION -produces-> *` ENTFAELLT ersatzlos, mit ihm der TraceType `produces`
+    // und der ElementType `SESSION`. Der urspruengliche Entwurf hielt das Pattern fuer die
+    // Provenance-Kante und wollte es behalten; die MESSUNG hat das 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.
+    // Nicht auf `relation` umgebogen: eine Kante ohne Schreiber UND ohne Leser wird gestrichen,
+    // nicht umbenannt.
 ];
+/**
+ * Erfuellt das betroffene Kantenende das Praedikat?
+ *
+ * TEILMENGEN-Semantik, nicht Schnittmenge: JEDER deklarierte Kind muss in der erlaubten Liste
+ * liegen. Die schwaechere Lesart ("mindestens einer passt") waere das Loch, das der ganze
+ * Abschnitt schliessen will — ein funktionales REQ zusaetzlich als `non-functional` zu
+ * deklarieren haette gereicht, damit ein MOD es wieder erfuellen darf, und der billige
+ * Zweitweg waere ueber ein Attribut zurueck.
+ *
+ * Der leere Fall LEHNT AB (`kinds.length === 0`): ohne Deklaration ist nicht entscheidbar, ob
+ * die Kante zulaessig ist, und "unentscheidbar" darf nicht "erlaubt" heissen — sonst wird das
+ * WEGLASSEN des Attributs zum Umgehungsweg. Das ist die durchsetzende Haelfte von REQ-X06
+ * (`kinds` ist Pflicht am REQ); die meldende Haelfte haengt an BQ-07.
+ */
+function satisfiesPredicate(where, trace) {
+    // `normalizeReqKinds` statt direktem Zugriff: drei Familie-Graphen tragen `kinds` als String
+    // statt als Liste, und ein `.every()` darauf WIRFT — mitten im Regellauf, statt einen Befund
+    // zu melden. Die Normalisierung heilt die Drift nicht, sie macht sie nur urteilsfaehig.
+    const kinds = normalizeReqKinds(where.on === 'source' ? trace.sourceKinds : trace.targetKinds);
+    if (kinds.length === 0)
+        return false;
+    return kinds.every(k => where.allowed.includes(k));
+}
+/**
+ * Die Obergrenze eines Kardinalitaets-Ausdrucks — `Infinity`, wo keine gilt.
+ *
+ * Getrennt von `isValidTrace`, weil es eine andere ART von Bedingung ist: `isValidTrace`
+ * urteilt ueber EINE Kante und braucht nur deren Enden, eine Kardinalitaet urteilt ueber die
+ * MENGE der Kanten eines Knotens. Der urspruengliche CR-Entwurf wollte beides in
+ * `isValidTrace` erledigen; das geht nicht, und die Korrektur steht im Impact-Audit.
+ */
+export function maxOccurs(cardinality) {
+    if (cardinality === undefined)
+        return Infinity;
+    return cardinality === '1' || cardinality === '0..1' ? 1 : Infinity;
+}
+/** 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) for validation.
+ * Uses element types (not IDs) plus — where a pattern declares one — an attribute predicate.
  */
 export function isValidTrace(trace, patterns = TRACE_PATTERNS) {
     return patterns.some(p => (p.source === '*' || p.source === trace.source) &&
         (p.target === '*' || p.target === trace.target) &&
         p.type === trace.type &&
-        (!p.label || p.label === trace.label));
+        (!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();

package/dist/se/module-crossings.d.ts

@@ -0,0 +1,102 @@
+/**
+ * CR-SM-276 — EIN Begriff „kreuzender Fluss", EINE Berechnung.
+ *
+ * Zwei Katalogeintraege messen Modulrand-Kopplung: **CR-01** je Modul*paar* und **R-04** je
+ * Modul (Groesse GEGEN Kreuzungen). Bis CR-SM-274/276 hatte jeder seine eigene, jeweils
+ * falsche Vorstellung davon, was eine Kreuzung ist:
+ *
+ * - CR-01 suchte `FUNC -io-> FUNC` — ein Paar, das `TRACE_PATTERNS` nicht kennt (R-18 lehnt es
+ *   ab). Die Regel konnte strukturell nicht feuern (CR-SM-274).
+ * - R-04 zaehlte „jede io-Kante einer Modul-FUNC mit einem Endpunkt ausserhalb der FUNC-Menge".
+ *   FLOWs liegen NIE in der FUNC-Menge — also zaehlte jede io-Kante zu jedem FLOW, auch dem
+ *   modul*internen*. Das war der io-Grad des Moduls, nicht seine Randkopplung: fuer jedes Modul
+ *   mit irgendeinem Datenfluss trivial > 2, womit R-04 faktisch wieder „max module size" war —
+ *   genau der Name, den CR-SM-236 verworfen hat.
+ *
+ * Hier steht der Pfad, den beide Regelkoepfe meinen: **`FUNC -io-> FLOW -io-> FUNC` ueber eine
+ * Modulgrenze**. MOD-Zugehoerigkeit einer FUNC = **direkte** `allocate`-Kante (`FUNC -allocate->
+ * MOD` ist `0..1`) — dieselbe Aufloesung wie `moduleMetrics` und die RC-05-Adjazenz.
+ *
+ * ## CR-SM-282: `byModule` rollt auf, `pairs` nicht
+ *
+ * Bis hierher las AUCH `byModule` nur die direkte Zuordnung. Ein Eltern-MOD (`MOD -compose-> MOD`)
+ * hat keine direkt allozierten FUNCs — es kam in `byModule` also gar nicht vor, und R-04 sah an ihm
+ * **null Kreuzungen**. Genau die Whitebox, in die der Leser hineinklickt, war unsichtbar. Jetzt ist
+ * die Zugehoerigkeit die **Besitzkette**: das direkt allozierte MOD plus seine compose-Vorfahren.
+ * Ein Vertrag quert den Rand von `m`, wenn ein Endpunkt in `m`s Teilbaum liegt und einer nicht.
+ *
+ * `pairs` (CR-01) bleibt bewusst auf der direkten Zuordnung: „wie stark haengen DIESE zwei Module
+ * aneinander" ist eine Frage der Blattebene; ein Elternpaar meldete dieselbe Kopplung ein zweites
+ * Mal. Ohne `MOD -compose-> MOD` im Graphen ist das Ergebnis Zeichen fuer Zeichen das bisherige.
+ *
+ * ## Zaehlbasis: verschiedene SCHEMA, nicht Einzelquerungen
+ *
+ * Begruendung in CR-SM-274 (dort familienweit gemessen): Kopplung ist die Zahl der **Vertraege**,
+ * auf die sich zwei Module einigen muessen — ein FLOW mit 3 Produzenten und 3 Konsumenten ist
+ * EIN Vertrag, nicht 9. Roh ist hub-empfindlich und durch FLOW-Splitting manipulierbar;
+ * `FLOW -relation-> SCHEMA` ist seit CR-SM-271 Teil 2 `1..1` und per R-18 erzwungen, die
+ * Zaehlbasis also garantiert vorhanden. Ein FLOW ohne SCHEMA zaehlt als eigener, untypisierter
+ * Vertrag (`UNBOUND:<flow>`) — er darf nicht stillschweigend mit anderen verschmelzen.
+ *
+ * ## Warum `byModule` die VEREINIGUNG ist und nicht die Summe ueber die Paare
+ *
+ * R-04 meldet an EINEM MOD. Quert derselbe Vertrag zu drei Nachbarn, besitzt das Modul trotzdem
+ * einen Vertrag — die Summe ueber die Paare brächte die Hub-Empfindlichkeit zurueck, die die
+ * distinct-Zaehlung gerade beseitigt, und zaehlte doppelt, was CR-01 je Paar ohnehin meldet.
+ * `byModule` ist damit die **Vertragsflaeche** des Modulrandes.
+ */
+import type { OntologyGraph } from './ontology.js';
+export interface ModulePairCrossing {
+    readonly modA: string;
+    readonly modB: string;
+    /** SCHEMA-ids bzw. `UNBOUND:<flow>` — die verschiedenen Vertraege an dieser Grenze. */
+    readonly contracts: ReadonlySet<string>;
+}
+export interface ModuleCrossings {
+    /** Je sortiertem Modulpaar (Schluessel `modA::modB`) die querenden Vertraege. */
+    readonly pairs: ReadonlyMap<string, ModulePairCrossing>;
+    /** Je MOD die Vereinigung aller Vertraege, die seine Grenze queren. */
+    readonly byModule: ReadonlyMap<string, ReadonlySet<string>>;
+    /**
+     * CR-SM-283: je ZERLEGTER FUNC die Vertraege, die den Rand seiner Whitebox queren —
+     * dieselbe Definition und derselbe Durchlauf wie `byModule`, nur ist die Innen-Menge der
+     * `compose`-Teilbaum statt des Modul-Teilbaums. Ein Blatt-FUNC steht NICHT drin: es ist
+     * keine Whitebox, seine io-Kanten sind kein Rand.
+     *
+     * 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 (Spike CR-SM-282).
+     */
+    readonly byFunc: ReadonlyMap<string, ReadonlySet<string>>;
+    /**
+     * CR-SM-282: je MOD die FUNCs seines TEILBAUMS — direkt alloziert plus die seiner
+     * compose-Sub-MODs. Fuer ein Blatt-MOD identisch zur direkten Allokation; fuer ein
+     * Eltern-MOD ist es die Groesse, die R-04 gegen die Kreuzungen abwaegt. Ohne diese
+     * Zahl war ein Eltern-MOD fuer R-04 leer und die Regel schwieg per `funcCount <= coupled`.
+     */
+    readonly funcsByModule: ReadonlyMap<string, ReadonlySet<string>>;
+    /**
+     * CR-SM-293: dieselbe Grenze, jetzt mit RICHTUNG — Martins Ca/Ce, gerechnet im selben
+     * Durchlauf und auf derselben Zaehlbasis (verschiedene Vertraege) wie `pairs`/`byModule`.
+     *
+     * `afferentContracts` = Vertraege, die dieses Modul ueber seinen Rand LIEFERT: andere
+     * haengen von ihm ab. `efferentContracts` = Vertraege, die es von draussen BEZIEHT: es
+     * haengt von anderen ab. Ein Vertrag, dessen Produzent und Konsument beide im Teilbaum
+     * liegen, steht in keiner der beiden Mengen — er quert den Rand nicht.
+     *
+     * Die Richtung ist die Entscheidung, die bis hierher nirgends im Repo stand: der
+     * KONSUMENT haengt vom Vertrag des Produzenten ab, nicht umgekehrt. `moduleMetrics`
+     * las vorher „Kante zeigt weg = Abhaengigkeit" und drehte damit jedes reine
+     * Verbrauchermodul auf `I = 0` (maximal stabil), wo es `1` sein muss.
+     */
+    readonly afferentContracts: ReadonlyMap<string, ReadonlySet<string>>;
+    readonly efferentContracts: ReadonlyMap<string, ReadonlySet<string>>;
+}
+/** Die querenden Vertraege dieses Graphen — einmal je Graph-Objekt berechnet. */
+export declare function moduleCrossings(graph: OntologyGraph): ModuleCrossings;
+/** Zahl der verschiedenen Vertraege, die den Rand dieses Moduls queren. */
+export declare function crossingContractCount(graph: OntologyGraph, modId: string): number;
+/** Zahl der verschiedenen Vertraege, die den Rand dieser FUNC-Whitebox queren — CR-SM-283. */
+export declare function whiteboxContractCount(graph: OntologyGraph, funcId: string): number;
+/** Die FUNCs im Teilbaum dieses Moduls (direkt alloziert + die seiner Sub-MODs) — CR-SM-282. */
+export declare function subtreeFuncs(graph: OntologyGraph, modId: string): ReadonlySet<string>;