@sigloch/contracts 6.1.0 → 9.1.0

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

@@ -3,24 +3,69 @@
  * Single source of truth for which ElementType pairs are valid for which TraceType.
  * @sigloch/contracts/se
  */
-import type { ElementType, TraceType } from './ontology.js';
+import type { ElementType, ReqKind, TraceType } from './ontology.js';
+/**
+ * Ein Attribut-Praedikat am Pattern (CR-SM-266 B, REQ-X03).
+ *
+ * Bis hierher entschied AUSSCHLIESSLICH das Typ-Paar ueber die Gueltigkeit einer Kante. Das
+ * liess vier satisfy-Patterns ununterscheidbar nebeneinander stehen: ein FUNKTIONALES REQ
+ * konnte von einem MOD oder SYS "erfuellt" werden, ohne dass je eine Wirkkette es trug —
+ * strukturell derselbe billige Zweitweg, den CR-GC-366 fuer `FUNC -satisfy-> UC` entfernt hat,
+ * und er umging dieselben Pruefungen (IO-01, R-21 sehen nur INNERHALB einer Kette).
+ *
+ * Bewusst eng gehalten: `kinds` ist das einzige mehrwertige Enum-Feld am Knoten, und ein
+ * Praedikat ueber freien Text oder abgeleitete Werte waere nicht deterministisch
+ * entscheidbar. Kein generischer Ausdruck, keine Funktion — eine Liste erlaubter Enum-Werte.
+ */
+export interface AttributePredicate {
+    /** An welchem Kantenende das Praedikat haengt. */
+    on: 'source' | 'target';
+    /** Das geprueft Feld — heute nur `kinds` (REQ). */
+    field: 'kinds';
+    /** Die erlaubten Werte. */
+    allowed: readonly ReqKind[];
+}
 export interface TracePattern {
     source: ElementType | '*';
     target: ElementType | '*';
     type: TraceType;
-    category?: 'modeling' | 'audit';
     label?: string;
-    cardinality?: '1' | '1..*' | '0..*';
+    cardinality?: '1' | '0..1' | '1..*' | '0..*';
+    /** Zusatzbedingung am Quell-/Zielknoten. Fehlt sie, entscheidet allein das Typ-Paar. */
+    where?: AttributePredicate;
     description: string;
 }
 export declare const TRACE_PATTERNS: TracePattern[];
 /**
- * Check if a trace matches a valid pattern in the meta-model.
- * Uses element types (not IDs) for validation.
+ * Die Kante, wie `isValidTrace` sie sieht: die beiden Typen, der Kantentyp — und, sobald ein
+ * Pattern ein `where` traegt, die deklarierten Kinds des betroffenen Endes.
+ *
+ * `sourceKinds`/`targetKinds` sind OPTIONAL, und ihr Fehlen bedeutet "nicht deklariert", nicht
+ * "beliebig": ein Pattern mit `where` lehnt dann ab (s. `satisfiesPredicate`). Wer nur das
+ * Typ-Paar kennt — die Vorschlags-Pfade in fix-templates/rule-apply, die eine Kante erst noch
+ * bauen — bekommt fuer die where-Patterns korrekterweise `false` und schlaegt sie nicht vor.
  */
-export declare function isValidTrace(trace: {
+export interface TraceShape {
     source: ElementType;
     target: ElementType;
     type: TraceType;
     label?: string;
-}, patterns?: TracePattern[]): boolean;
+    sourceKinds?: readonly ReqKind[];
+    targetKinds?: readonly ReqKind[];
+}
+/**
+ * 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 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[];
+/**
+ * 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;

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,38 @@ 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.
+    //
+    // 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.
+    { 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' },
     // 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 +87,75 @@ 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);
 /**
  * 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)));
 }

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

@@ -71,6 +71,14 @@ export interface ModuleMetrics {
     instability: number | null;
     /** MT-02 core: connected-component count. null below 2 allocated FUNCs (not measurable). */
     lcom4: number | null;
+    /**
+     * CR-SM-263: JEDE allozierte FUNC ist ein zerlegter Block (Rollup), das MOD also ein
+     * Container statt eines Implementierungsmoduls. Dann ist `lcom4` = Zahl der Bloecke,
+     * garantiert durch CR-SM-256 — eine wahre Zahl ohne Aussage ueber Kohaesion. MT-02
+     * urteilt hier nicht; der Wert steht trotzdem da, damit der Leser ihn deuten kann.
+     * `false` unterhalb von 2 allozierten FUNCs (kein Container, nur zu klein zum Messen).
+     */
+    rollupContainer: boolean;
     /** The CR-SM-223 measurement, deliberately threshold-free. null where contracts omits it. */
     cohesion: {
         internal: number;

package/dist/se/metric-rules.js

@@ -1,3 +1,5 @@
+import { decomposedFuncs } from './rules.js';
+import { indexOf } from './graph-index.js';
 /**
  * MT-01: Module Instability (CR-165: indirect via allocate-path).
  * I = fan_out / (fan_in + fan_out) > `policy.instability` → warning.
@@ -46,6 +48,13 @@ export function mt02Lcom4(graph, policy) {
     for (const m of measureModules(graph)) {
         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
+        // 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)`;
         if (m.lcom4 >= steps.info && m.lcom4 < steps.warning) {
             violations.push({ rule_id: 'MT-02', severity: 'info', element_id: m.moduleId, message });
@@ -120,30 +129,86 @@ function connectionPairs(graph) {
  * Every value that is not measurable is `null`, never 0: a module with one allocated
  * FUNC has no LCOM4, and a 1 there would be an invented statement about cohesion.
  */
+const MEASURE_CACHE = new WeakMap();
+/**
+ * CR-SM-264: die Rechnung EINMAL je Graph.
+ *
+ * `mt01Instability` und `mt02Lcom4` riefen `measureModules` beide auf, also lief die
+ * vollstaendige Modulmessung je Auswertungslauf zweimal — im Profil aus CR-SM-260 stehen sie
+ * mit 7,1 % und 7,0 % nebeneinander, und die zweite Zahl ist reine Wiederholung der ersten.
+ * Schluessel ist das Graph-OBJEKT (dieselbe Begruendung wie in `graph-index.ts`).
+ *
+ * Der Cache gibt seine EIGENE Liste heraus. Wer sie sortieren will, kopiert vorher —
+ * `moduleMetrics` tut das; ein `.sort()` auf dem Cache-Eintrag wuerde ihn dauerhaft umordnen.
+ */
 function measureModules(graph) {
-    const mods = graph.elements.filter(e => e.type === 'MOD');
+    const cached = MEASURE_CACHE.get(graph);
+    if (cached !== undefined)
+        return cached;
+    const rowsForCache = measureModulesUncached(graph);
+    MEASURE_CACHE.set(graph, rowsForCache);
+    return rowsForCache;
+}
+function measureModulesUncached(graph) {
+    const idx = indexOf(graph);
+    const mods = idx.elementsOfType('MOD');
     const pairs = [...connectionPairs(graph)].map(p => p.split('|'));
+    // CR-SM-263: EIN Helper fuer "Blatt" — derselbe, den R-02/R-30/R-31 seit CR-SM-256 lesen.
+    // 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 ---
+    //
+    // 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".
+    //
+    // 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);
+        }
+    }
     for (const mod of mods) {
-        const allocated = graph.traces
-            .filter(t => t.type === 'allocate' && t.target === mod.id)
-            .map(t => t.source);
+        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 = graph.traces.filter(t => t.source === mod.id && (t.type === 'io' || t.type === 'compose') && t.target !== mod.id).length;
-        const directIn = graph.traces.filter(t => t.target === mod.id && (t.type === 'io' || t.type === 'compose' || t.type === 'allocate')).length;
-        let indirectOut = 0;
-        let indirectIn = 0;
-        for (const t of graph.traces) {
-            if (t.type === 'allocate')
-                continue; // allocate itself doesn't count as coupling
-            if (modFuncIds.has(t.source) && !modFuncIds.has(t.target) && t.target !== mod.id)
-                indirectOut++;
-            if (modFuncIds.has(t.target) && !modFuncIds.has(t.source) && t.source !== mod.id)
-                indirectIn++;
-        }
-        const fanOut = directOut + indirectOut;
-        const fanIn = directIn + indirectIn;
+        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);
         const instability = fanIn + fanOut === 0 ? null : fanOut / (fanIn + fanOut);
         rows.push({
             moduleId: mod.id,
@@ -153,6 +218,7 @@ function measureModules(graph) {
             fanOut,
             instability,
             lcom4: lcom4Of(graph, allocated),
+            rollupContainer: allocated.length >= 2 && allocated.every(f => decomposed.has(f)),
             cohesion: cohesionOf(pairs, modFuncIds),
         });
     }
@@ -163,13 +229,19 @@ function lcom4Of(graph, funcIds) {
     if (funcIds.length < 2)
         return null;
     // Two FUNCs are connected if they share a common io/satisfy target.
+    // 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).
+    const idx = indexOf(graph);
     const funcTargets = new Map();
     for (const fid of funcIds) {
         const targets = new Set();
-        for (const t of graph.traces) {
-            if (t.source === fid && (t.type === 'io' || t.type === 'satisfy'))
-                targets.add(t.target);
-        }
+        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();
@@ -262,7 +334,7 @@ function cohesionOf(pairs, funcIds) {
  */
 export function moduleMetrics(graph) {
     const byId = (a, b) => a.moduleId < b.moduleId ? -1 : a.moduleId > b.moduleId ? 1 : 0;
-    return measureModules(graph).sort((a, b) => {
+    return [...measureModules(graph)].sort((a, b) => {
         if (a.cohesion && b.cohesion)
             return a.cohesion.ratio - b.cohesion.ratio || byId(a, b);
         if (a.cohesion)

package/dist/se/ontology.d.ts

@@ -21,7 +21,6 @@ export declare const ElementType: z.ZodEnum<{
     TEST: "TEST";
     MOD: "MOD";
     SCHEMA: "SCHEMA";
-    SESSION: "SESSION";
     CR: "CR";
     MS: "MS";
 }>;
@@ -38,20 +37,48 @@ export declare const TraceType: z.ZodEnum<{
     verify: "verify";
     allocate: "allocate";
     relation: "relation";
-    produces: "produces";
 }>;
 export type TraceType = z.infer<typeof TraceType>;
-/** REQ kind — 7 values aligned with SysML 2.0 + FMEA (CR-180). */
+/**
+ * REQ kind — 6 values aligned with SysML 2.0 + FMEA (CR-180).
+ *
+ * CR-SM-266 B: `negative` ENTFAELLT. Ein Verbots-REQ ("das System tut X nie") ist auch eine
+ * Anforderung — die Implementierung muss Regeln abfragen oder Sicherungen einbauen, und das
+ * ist `functional`. Der Wert hatte NULL Leser (kein Regel-, Gate- oder View-Konsument; anders
+ * als risk/mitigation → FM-01..03, pre/postcondition → UC-05/06, non-functional → NFR-01) und
+ * haette durch die where-Praedikate am satisfy-Pattern per AUSLASSUNG erstmals Wirkung
+ * bekommen: er stand in keiner der vier Listen und waere damit nur noch per FCHAIN erfuellbar
+ * gewesen. Die sechs verbleibenden Werte partitionieren die where-Listen VOLLSTAENDIG — kein
+ * Wert ohne Zuordnung, keine Kante, die durch ein Loch in der Aufzaehlung faellt.
+ */
 export declare const ReqKind: z.ZodEnum<{
     functional: "functional";
     "non-functional": "non-functional";
     risk: "risk";
-    negative: "negative";
     mitigation: "mitigation";
     precondition: "precondition";
     postcondition: "postcondition";
 }>;
 export type ReqKind = z.infer<typeof ReqKind>;
+/**
+ * `kinds` in der Form, die WIRKLICH auf Platte liegt — als Liste.
+ *
+ * Gefunden beim Migrations-Audit zu CR-SM-266 (2026-08-25), nicht von Hand: drei Graphen der
+ * Familie tragen `kinds` als blossen STRING statt als Liste (`graph-view-edit`
+ * `REQ-edit-genesis: 'functional'`, dazu gc_test-graphview und graphify), einer davon mit dem
+ * Wert `'security'`, den das Enum gar nicht kennt. Ursache ist der Format-E-Weg: dort reist
+ * das Feld als `@kinds a,b` und wird erst vom Konsumenten gehoben (graph-api-core, CR-195d).
+ *
+ * Seit die where-Praedikate `kinds` LESEN (CR-SM-266 B), ist diese Drift tragend: ein
+ * `kinds.every(...)` auf einem String wirft, und eine geworfene Exception in `isValidTrace`
+ * reisst den ganzen Regellauf statt einen Befund zu melden. Die SSOT muss auch bei kaputten
+ * Daten ein URTEIL liefern, keinen Absturz.
+ *
+ * Normalisieren heisst hier ausdruecklich NICHT raten: `'a,b'` wird zu `['a','b']`, weil genau
+ * das die Schreibform ist — ein unbekannter Wert wie `'security'` ueberlebt die Normalisierung
+ * und faellt danach am Enum-Vergleich durch. Die Drift wird sichtbar, nicht geheilt.
+ */
+export declare function normalizeReqKinds(raw: unknown): readonly string[];
 export declare const AsilLevel: z.ZodEnum<{
     QM: "QM";
     A: "A";
@@ -222,7 +249,6 @@ export declare const OntologyElement: z.ZodObject<{
         TEST: "TEST";
         MOD: "MOD";
         SCHEMA: "SCHEMA";
-        SESSION: "SESSION";
         CR: "CR";
         MS: "MS";
     }>;
@@ -245,7 +271,6 @@ export declare const OntologyElement: z.ZodObject<{
         functional: "functional";
         "non-functional": "non-functional";
         risk: "risk";
-        negative: "negative";
         mitigation: "mitigation";
         precondition: "precondition";
         postcondition: "postcondition";
@@ -265,12 +290,6 @@ export type OntologyElement = z.infer<typeof OntologyElement>;
  * A trace (edge) in the SE ontology graph.
  * `label` provides semantic context for 'relation' edges (e.g. 'derives', 'depends-on').
  */
-/** Trace category: modeling traces are user-visible, audit traces are internal. */
-export declare const TraceCategory: z.ZodEnum<{
-    modeling: "modeling";
-    audit: "audit";
-}>;
-export type TraceCategory = z.infer<typeof TraceCategory>;
 export declare const Trace: z.ZodObject<{
     source: z.ZodString;
     target: z.ZodString;
@@ -281,12 +300,7 @@ export declare const Trace: z.ZodObject<{
         verify: "verify";
         allocate: "allocate";
         relation: "relation";
-        produces: "produces";
     }>;
-    category: z.ZodOptional<z.ZodEnum<{
-        modeling: "modeling";
-        audit: "audit";
-    }>>;
     label: z.ZodOptional<z.ZodString>;
     weight: z.ZodDefault<z.ZodNumber>;
     attributes: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodUnknown>>;
@@ -308,7 +322,6 @@ export declare const OntologyGraph: z.ZodObject<{
             TEST: "TEST";
             MOD: "MOD";
             SCHEMA: "SCHEMA";
-            SESSION: "SESSION";
             CR: "CR";
             MS: "MS";
         }>;
@@ -331,7 +344,6 @@ export declare const OntologyGraph: z.ZodObject<{
             functional: "functional";
             "non-functional": "non-functional";
             risk: "risk";
-            negative: "negative";
             mitigation: "mitigation";
             precondition: "precondition";
             postcondition: "postcondition";
@@ -356,12 +368,7 @@ export declare const OntologyGraph: z.ZodObject<{
             verify: "verify";
             allocate: "allocate";
             relation: "relation";
-            produces: "produces";
         }>;
-        category: z.ZodOptional<z.ZodEnum<{
-            modeling: "modeling";
-            audit: "audit";
-        }>>;
         label: z.ZodOptional<z.ZodString>;
         weight: z.ZodDefault<z.ZodNumber>;
         attributes: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodUnknown>>;
@@ -372,7 +379,7 @@ export declare const OntologyGraph: z.ZodObject<{
 export type OntologyGraph = z.infer<typeof OntologyGraph>;
 /** Human-readable descriptions for each ElementType. */
 export declare const ELEMENT_DESCRIPTIONS: Record<ElementType, string>;
-/** Element types used in modeling (user-visible). Excludes audit types (SESSION, CR). */
+/** Element types used in modeling (user-visible). Excludes the planning type CR. */
 export declare const MODELING_ELEMENT_TYPES: ElementType[];
 export interface AttributeSpec {
     key: string;