@sigloch/contracts 10.1.0 → 10.3.0

package/dist/se/policy.js

@@ -45,8 +45,20 @@ export const MetricPolicySchema = z.object({
      * graphcode-Selbstmodell 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. Wer doktrin-streng fahren will, setzt 5.
+     *
+     * CR-SM-311: die Breite ist ein BAND. `min` ist die Untergrenze (Z3, ITEM-2026-053): eine Ebene
+     * mit weniger Elementen abstrahiert nichts. Beide Grenzen sind Pflicht, beide exklusiv — `min`
+     * und `warning` selbst liegen im Band.
      */
-    decompositionBreadth: z.object({ warning: z.number().int().min(2) }).nullable(),
+    decompositionBreadth: z
+        .object({
+        /** Unter `min` Kindern ist eine Ebene entartet. */
+        min: z.number().int().min(1),
+        /** Ueber `warning` Kindern ist eine Ebene zu breit. */
+        warning: z.number().int().min(2),
+    })
+        .refine((b) => b.min <= b.warning, { message: 'decompositionBreadth.min must not exceed decompositionBreadth.warning' })
+        .nullable(),
     /**
      * CR-SM-283: Randbreite je Blackbox (BW-02) — verschiedene Vertraege, die den Rand queren.
      * Bewusst OHNE `info`-Stufe: die Verteilung gibt sie nicht her. bok und graph-view-edit enden
@@ -55,6 +67,26 @@ export const MetricPolicySchema = z.object({
      * aus dem MT-03 zur Messung statt zur Regel wurde. `null` -> messen, nicht urteilen.
      */
     boundaryWidth: z.object({ warning: z.number().int().min(1) }).nullable(),
+    /**
+     * CR-SM-314: ab wie vielen Wirkketten gilt eine FUNC als INFRASTRUKTUR.
+     *
+     * Die Zahl selbst (`functionCriticality`) urteilt nie — sie steht in jeder FUNC-Zeile. Diese
+     * Schwelle sagt nur, wo eine Regel sie als Ausnahme lesen darf; erster Abnehmer ist R-21
+     * (CR-SM-313): eine Uebergabe an eine Funktion, die quer durch alle Ketten laeuft, ist kein
+     * fehlender Integrationstest, sondern ein Bus.
+     *
+     * ABGELESEN, nicht gesetzt — aber nicht an der Verteilungsform. Die ist ein duenner Schwanz
+     * (17 Familiengraphen: 224 FUNCs in 1 Kette, 37 in 2, 6 in 3, 8 in 4, je 1 in 5/6/11) und gibt
+     * wie bei `instability` keine Schwelle her (CR-SM-293). Ablesbar ist die WIRKUNG: auf
+     * graphcodes 31 kettenlose Uebergaben stellen die Schwellen 3 und 4 identisch 19 frei, 5 und 6
+     * identisch 6. Ein Plateau von 3 bis 4 — innerhalb dessen die Wahl wirkungsfrei ist. Der
+     * Startwert ist seine Untergrenze.
+     *
+     * `min(2)`, nicht `min(1)`: bei 1 waere JEDE FUNC in einer Kette Infrastruktur, und die
+     * Ausnahme fraesse ihre eigene Regel. `null` -> keine FUNC gilt als Infrastruktur; die Zahl
+     * bleibt trotzdem gemessen.
+     */
+    criticality: z.object({ infrastructure: z.number().int().min(2) }).nullable(),
     /**
      * FM-03: RPN (severity · occurrence · detection), ab dem ein Risiko-REQ eine bestandene
      * Verifikation braucht (exklusiv). null → FM-03 feuert nie.
@@ -75,23 +107,6 @@ export const MetricPolicySchema = z.object({
      * exportierten Graphen steht sie nie** (Zellwerte sind normative Wertung, keine Fakten).
      */
     apTable: ApTableSchema.nullable(),
-    /**
-     * R-04: Modulgröße **gegen** Kreuzungen — die Regel wägt beides ab, ihr alter Name
-     * („Max module size") gab das nicht her. null → R-04 feuert nie.
-     *
-     * Drei Werte, weil die Regel drei Urteile fällt. Ein einzelner Schwellwert hätte zwei davon
-     * im Code gelassen — genau der Zustand, den dieser CR beseitigt.
-     */
-    moduleSize: z
-        .object({
-        /** > `large` FUNCs: mit Kreuzungen warning, ohne Kreuzungen info („kohäsiv, nur groß"). */
-        large: z.number().int().min(1),
-        /** > `coupled` FUNCs ist die Untergrenze, ab der die Regel überhaupt hinsieht. */
-        coupled: z.number().int().min(1),
-        /** Kreuzungen, ab denen ein nur `coupled`-großes Modul warnt (exklusiv). */
-        crossings: z.number().int().min(0),
-    })
-        .nullable(),
 });
 /**
  * Der Startwert, sichtbar als solcher — **kein** Fallback in der Regel.
@@ -133,17 +148,13 @@ export const DEFAULT_METRIC_POLICY = {
     // weil `info` bei 5 den readiness-Nenner verwaessert haette; das Argument traegt fuer die
     // OBERgrenze nicht, denn RD-04 meldet als `warning`. Die Zahl steht jetzt an EINER Stelle und
     // gilt fuer beide Zerlegungsfragen -- Sub-FUNC und Sub-MOD.
-    decompositionBreadth: { warning: 9 },
+    // CR-SM-311: Untergrenze 3 — eine Ebene mit weniger Elementen ist entartet (Z3).
+    decompositionBreadth: { min: 3, warning: 9 },
     // CR-SM-283: aus der Verteilung abgelesen — bok/gve max 3, graphcode 19, moneyflow 17.
     boundaryWidth: { warning: 5 },
+    // CR-SM-314: Untergrenze des gemessenen Plateaus 3..4 (siehe Feldkommentar oben).
+    criticality: { infrastructure: 3 },
     riskRpn: 100,
-    // `large`/`coupled`/`crossings` = die drei Literale aus `maxModuleSize`: vorher
-    // `funcCount <= 8` → skip, `funcCount > 12` → groß, `crossings > 2` → gekoppelt.
-    // CR-SM-296: an dieselbe Doktrin gebunden statt danebengesetzt. R-04 ist seit diesem CR ALLEIN
-    // fuer die Modulgroesse zustaendig (RD-04 hat ihr Allokations-Bein abgegeben), also gilt hier
-    // dieselbe 7+-2: `large` = 9 (Obergrenze), `coupled` = 7 (Untergrenze, ab der die Regel
-    // hinsieht). Vorher 12/8 -- zwei Zahlen fuer dieselbe Frage, unverbunden mit den 11 darueber.
-    moduleSize: { large: 9, coupled: 7, crossings: 2 },
     // CR-SM-229: kein Startwert möglich und keiner gewollt — die Tabelle steht nur im Handbook.
     // `null` heißt hier nicht „aus", sondern „markierter Übergang": bestätigte AP-Invarianten,
     // sonst RPN-Bänder. `apMethod()` macht das für den Leser sichtbar.

package/dist/se/readiness.d.ts

@@ -34,7 +34,6 @@ export declare const ReadinessScore: z.ZodObject<{
     violations: z.ZodNumber;
     applicable: z.ZodNumber;
     coreApplicable: z.ZodNumber;
-    ready: z.ZodBoolean;
 }, z.core.$strip>;
 export type ReadinessScoreType = z.infer<typeof ReadinessScore>;
 /**
@@ -62,7 +61,6 @@ export declare const ReadinessReport: z.ZodObject<{
         violations: z.ZodNumber;
         applicable: z.ZodNumber;
         coreApplicable: z.ZodNumber;
-        ready: z.ZodBoolean;
     }, z.core.$strip>>;
     timestamp: z.ZodISODateTime;
 }, z.core.$strip>;

package/dist/se/readiness.js

@@ -44,10 +44,9 @@ export const ReadinessScore = z.object({
      * Unterscheidung, an der der dokumentierte Ausweg aus CR-SM-237 gescheitert ist.
      */
     coreApplicable: z.number().int(),
-    // CR-SM-235: `score >= readyThreshold`. Die Schwelle steht bewusst NICHT hier — sie ist
-    // Eingabe von `computeReadiness`, und eine Zahl im Kommentar wäre die dritte Meinung dazu.
-    // CR-SM-270: bei `score === null` ist `ready` immer `false` — nicht messbar ist nicht bereit.
-    ready: z.boolean(),
+    // CR-SM-310: kein `ready` mehr. Ob eine Dimension zu schwach ist, urteilt der Konsument mit
+    // SEINER Schwelle (graphcode: generate.ts, focusThreshold aus der Config). Die Messung traegt
+    // kein Urteil — vorher stand es zweimal: hier als `ready` und beim Konsumenten.
 });
 /**
  * CR-SM-237: `overallScore` ist weg. Es war das **ungewichtete** Mittel der acht
@@ -96,12 +95,14 @@ export const RULE_TO_DIMENSION = {
     'RD-01': 'req', 'RD-02': 'req', 'RD-03': 'req',
     // RD-04 is decomposition *breadth* — an architecture concern, not a requirement one
     'RD-04': 'arch',
+    // CR-SM-311: die Untergrenze derselben Breite — ebenfalls Architektur
+    'RD-05': 'arch',
     // trace/realization/allocation completeness rules (CR-228 D: previously unmapped → advisory fall-through)
     'R-18': 'arch', 'R-19': 'ver', 'R-20': 'arch', 'R-21': 'ver',
     // CR-SM-231: R-29 (Testdatei-Exklusivitaet) gehoert zu 'ver' wie R-19 — beide bewerten die
     // Evidenz-Bindung einer Abnahme, R-19 ihre Praesenz, R-29 ihre Eindeutigkeit.
     'R-29': 'ver',
-    'R-22': 'alloc', 'R-23': 'alloc', 'R-26': 'schema', // CR-GC-366: R-30 (Wirkketten-Bindung) und R-31 (io-Verdrahtung) bewerten beide, ob ein
+    'R-22': 'alloc', 'R-23': 'alloc', 'R-26': 'schema', 'R-32': 'ver', // CR-GC-366: R-30 (Wirkketten-Bindung) und R-31 (io-Verdrahtung) bewerten beide, ob ein
     // Funktionsblock ueberhaupt im Bauplan haengt — dieselbe Dimension wie R-20 (realRef).
     // NICHT 'uc': R-14..R-17 fragen, ob ein Behaelter gefuellt ist;
     // diese beiden fragen von der FUNC aus, ob sie angeschlossen ist.
@@ -149,6 +150,7 @@ export const RULE_TO_DIMENSION = {
     'NFR-01': 'arch',
     // cross-module IO (CR-192)
     'IO-01': 'arch',
+    'IO-02': 'arch', // CR-SM-307: Flusstopologie, dieselbe Dimension wie R-10/IO-01.
     // view rules (CR-184)
     'VR-01': 'ver',
     'CL-01': 'uc',
@@ -189,7 +191,7 @@ export const RULE_TO_PHASE = {
     'CR-R01': 'SRR', 'CR-R03': 'SRR',
     'MS-01': 'SRR', 'MS-02': 'SRR', 'MS-03': 'SRR',
     // PDR — architecture/functional completeness.
-    'RD-04': 'PDR',
+    'RD-04': 'PDR', 'RD-05': 'PDR',
     'R-02': 'PDR', 'R-08': 'PDR', 'R-10': 'PDR', 'R-12': 'PDR', 'R-18': 'PDR',
     'R-04': 'PDR', 'R-22': 'PDR', 'R-23': 'PDR',
     'R-15': 'PDR',
@@ -199,13 +201,13 @@ export const RULE_TO_PHASE = {
     'R-30': 'PDR', 'R-31': 'PDR',
     'MT-01': 'PDR', 'MT-02': 'PDR',
     'ND-01': 'PDR',
-    'BW-02': 'PDR', 'CR-01': 'PDR', 'IO-01': 'PDR', // CR-SM-226: extended to all FCHAIN FUNC-pairs, added to the phase axis.
+    'BW-02': 'PDR', 'CR-01': 'PDR', 'IO-01': 'PDR', 'IO-02': 'PDR', // CR-SM-226: extended to all FCHAIN FUNC-pairs, added to the phase axis.
     // CDR — critical design/schema completeness.
     'R-26': 'CDR', 'SC-02': 'CDR', // SC-04 entfiel mit CR-SM-271 — der FLOW-ohne-SCHEMA-Fall haengt an R-18/PDR
     'ND-02': 'CDR',
     'NFR-01': 'CDR',
     // TRR — test readiness.
-    'R-01': 'TRR', 'R-05': 'TRR', 'R-19': 'TRR', 'R-20': 'TRR', 'R-21': 'TRR',
+    'R-01': 'TRR', 'R-05': 'TRR', 'R-32': 'TRR', 'R-19': 'TRR', 'R-20': 'TRR', 'R-21': 'TRR',
     // CR-SM-231: eine doppelt beanspruchte Testdatei laesst den TRR-Gate dieselbe Evidenz
     // doppelt zaehlen — der Befund gehoert genau an dieses Gate.
     'R-29': 'TRR',

package/dist/se/rule-help.js

@@ -147,6 +147,10 @@ export const RULE_HELP = {
         plain: "Two steps in the same sequence have no described data passing between them → add the data one hands to the other.",
         se: "A `FUNC` pair inside one `FCHAIN` with no `io` path (`FUNC -io-> FLOW -io-> FUNC`) connecting them.",
     },
+    'IO-02': {
+        plain: "Two different places write into the same flow, so a reader cannot tell which version arrives \u2192 give each source its own flow; they may keep sharing one contract.",
+        se: "`FLOW` with more than one producer (`FUNC`/`ACTOR -io-> FLOW`). R-10 checks the LOWER bound of the same axis (at least one producer, at least one consumer); the two can never fire on the same FLOW, so there is no double count. Only the producer side is bounded: several consumers are the normal shape of a shared contract \u2014 one source, many readers, which is exactly how a central configuration looks. One finding per FLOW, `value` = number of producers, `threshold` 1. Severity `error` (hygiene) and deliberately NOT in STEER_RULES — a decision, not a measured conflict: a split flow keeps its `SCHEMA`, so BW-02 (distinct contracts per boundary) does not rise. Whether a gate blocks a new finding is the consumer's gating choice, not part of the rule.",
+    },
     'MS-01': {
         plain: "A milestone has no work assigned to it → assign the work items that belong to it.",
         se: "`MS` with no `CR` `relation`.",
@@ -190,13 +194,17 @@ export const RULE_HELP = {
         se: "`FUNC` with no `satisfy` trace to a `REQ` (design→requirement traceability).",
     },
     'R-04': {
-        plain: "A module does too much or is too tangled → open it and split it.",
-        se: "`MOD` with >12 `FUNC`, or 8–12 `FUNC` with >2 flows crossing the module boundary (cohesion/coupling).",
+        plain: "Too many different data formats cross this module's boundary → merge formats, or move the functions that carry them.",
+        se: "`MOD` whose boundary is crossed by `metricPolicy.boundaryWidth.warning` or more DISTINCT contracts (`SCHEMA` on the io path `FUNC` ─io→ `FLOW` ─io→ `FUNC` across the boundary, union over all neighbours — CR-SM-276). Same question and same threshold as BW-02 on the FUNC tree (CR-SM-312); module SIZE is RD-04's question since CR-SM-311.",
         prompt: "se-view:arch",
     },
     'R-05': {
         plain: "A test doesn't check any feature you promised → link it to the feature it tests, or remove it.",
-        se: "`TEST` with no `verify` trace (test→requirement coverage) to a `REQ`.",
+        se: "`TEST` with no `verify` trace at all — neither to a `REQ` (test→requirement coverage) nor to a `SCHEMA` (contract test, CR-SM-317).",
+    },
+    'R-32': {
+        plain: "A data contract exists in code but no test exercises it as a contract → add a test that tries every variant, including the ones it must reject, and link it to the schema.",
+        se: "`SCHEMA` with a symbol `realRef` (a Zod contract) and no `TEST -verify-> SCHEMA`. RC-04 checks the parse at the boundary; this checks the contract test (CR-SM-319).",
     },
     'R-08': {
         plain: "A link points at something that no longer exists → repair or remove the broken link.",
@@ -235,8 +243,8 @@ export const RULE_HELP = {
         se: "Realized `FUNC` with no valid `realRef` `{file, symbol}` (graph↔code binding); else `concept:true` / `external:true`.",
     },
     'R-21': {
-        plain: "You grouped functions into a chain that passes data along, but nothing tests that hand-off → add an integration test that checks the chain works.",
-        se: "FUNC↔FUNC connection (`FUNC` ─io→ `FLOW` ─io→ `FUNC`) whose endpoints DO share an `FCHAIN`, but no shared chain carries a verified integration test (`TEST` ─verify→ `REQ` ←satisfy─ `FCHAIN`). Pairs sharing no `FCHAIN` are silent: co-adjacency at a reused `FLOW` is not an asserted interface.",
+        plain: "Two functions hand data over, but they are not in one chain together — or they are, and nothing tests the hand-off → put both into the same chain, and give that chain an integration test.",
+        se: "FUNC↔FUNC handover (`FUNC` ─io→ `FLOW` ─io→ `FUNC`), two findings. (a) endpoints share NO `FCHAIN` → finding at the PRODUCER: no integration scope is declared. (b) endpoints share one, but no shared chain carries a verified integration test (`TEST` ─verify→ `REQ` ←satisfy─ `FCHAIN`) → finding at the chain. SILENT when either endpoint is in no chain at all (that is R-30's statement) and when either is infrastructure (`chains >= policy.criticality.infrastructure`): a handover into a function that runs through every chain is a bus, not a missing test.",
     },
     'R-22': {
         plain: "A function isn't assigned to any building block, so it has no home in the structure → put it on a module.",
@@ -301,7 +309,11 @@ export const RULE_HELP = {
     },
     'RD-04': {
         plain: "One thing has more than 9 parts directly under it → group them, so each level stays readable.",
-        se: "Decomposition breadth above `metricPolicy.decompositionBreadth.warning` children on one level — `FUNC` `compose` `FUNC`, `SYS`/`MOD` `compose` `MOD`, and the root `FUNC` forest anchored at `SYS` (CR-SM-282). Default 9, the upper end of 7±2 (CR-SM-296). The `FUNC` `allocate` `MOD` leg moved to R-04 in that CR: counting allocated FUNCs is module SIZE, and one question deserves one rule.",
+        se: "Decomposition breadth above `metricPolicy.decompositionBreadth.warning` children on one level — `FUNC` `compose` `FUNC`, `SYS` `compose` `MOD`, a `MOD`'s sub-`MOD`s plus its own leaf `FUNC` (`allocate`), and the root `FUNC` forest anchored at `SYS` (CR-SM-282). Default 9, the upper end of 7±2 (CR-SM-296). CR-SM-311: a module level counts its own functions again — breadth, not size; module coupling is R-04. The lower bound is RD-05.",
+    },
+    'RD-05': {
+        plain: "A level has only one or two parts under it → it groups nothing; fold it into the level above, or gather the parts that belong together under it.",
+        se: "Decomposition breadth below `metricPolicy.decompositionBreadth.min` (default 3, exclusive) on one level, counted exactly like RD-04 (CR-SM-311, Z3). A level abstracts nothing below it. The finding carries no `value`/`threshold` and does not enter the steering score: it is readability, not boundary width. A level with no children at all is not this rule (empty MOD: R-23; FUNC without children is a leaf).",
     },
     'SC-02': {
         plain: "A data format is defined but nothing uses it → connect it to the data it describes, or drop it.",