@sigloch/contracts 10.14.0 → 12.0.0

package/dist/se/readiness.d.ts

@@ -1,50 +1,12 @@
 /**
- * CR-120: Readiness dimension schemas for dynamic phase readiness.
- * Dimensions emerge from graph state — no state machine.
- * CR-SM-226: `emergentPhase`/`phaseScore` (CR-120/146) removed — a third,
- * undocumented phase construct next to RULE_TO_DIMENSION and the (then still
- * ad-hoc) phase-gate grouping. `RULE_TO_PHASE` below is the one replacement:
- * a rule → SRR/PDR/CDR/TRR mapping, same shape and same completeness
- * guarantee as `RULE_TO_DIMENSION`, exported so no consumer reinvents it.
+ * Stufen, Marken und Arbeitsschritte der Steuerung, dazu der Vertrag des Steuerungsraums.
+ * CR-SM-395: the phase axis is no longer a table. Each rule carries its stage; the mark
+ * (SRR/PDR/CDR/TRR/Bau) is derived from it — see "Stufen und Marken" below.
+ * CR-SM-401: die Dimension ist entfallen (Entscheidung des Autors 2026-10-07: „Stufe statt
+ * Dimension, Befunde zaehlen statt Prozent"). Es gibt EINE Einteilung der Regeln, die Stufe; die
+ * Zahl der Befunde je Stufe liefert `countByStage` in @sigloch/graphcode-client.
  */
 import { z } from 'zod/v4';
-export declare const ReadinessDimension: z.ZodEnum<{
-    schema: "schema";
-    req: "req";
-    uc: "uc";
-    arch: "arch";
-    alloc: "alloc";
-    ver: "ver";
-    cr: "cr";
-    ms: "ms";
-}>;
-export type ReadinessDimensionType = z.infer<typeof ReadinessDimension>;
-export declare const ReadinessScore: z.ZodObject<{
-    dimension: z.ZodEnum<{
-        schema: "schema";
-        req: "req";
-        uc: "uc";
-        arch: "arch";
-        alloc: "alloc";
-        ver: "ver";
-        cr: "cr";
-        ms: "ms";
-    }>;
-    score: z.ZodNullable<z.ZodNumber>;
-    violations: z.ZodNumber;
-    applicable: z.ZodNumber;
-    coreApplicable: z.ZodNumber;
-}, z.core.$strip>;
-export type ReadinessScoreType = z.infer<typeof ReadinessScore>;
-/**
- * CR-SM-237: `overallScore` ist weg. Es war das **ungewichtete** Mittel der acht
- * Dimensions-Scores — `ms` (3 Regeln) zählte so viel wie `arch` (~20 Regeln über Hunderte
- * Elemente), die Zahl bewegte sich also mit dem Größenverhältnis der Dimensionen und nicht mit
- * dem Zustand des Modells. Gelesen hat sie ohnehin niemand: der einzige Zugriff in der Familie
- * war eine Formprüfung (`'overallScore' in x`) im inzwischen gelöschten `weight-vector.ts`.
- * Ein interpretierbarer Ersatz (`1 − Σviolations / Σapplicable`) kommt, wenn er einen
- * Konsumenten hat — nicht auf Vorrat.
- */
 /**
  * CR-SM-337 (ITEM-2026-059) — der STEUERUNGSRAUM im Bericht, Stufe 1: der Vertrag.
  *
@@ -90,127 +52,57 @@ export declare const SteerSpace: z.ZodObject<{
     }, z.core.$strip>>;
 }, z.core.$strip>;
 export type SteerSpaceType = z.infer<typeof SteerSpace>;
-export declare const ReadinessReport: z.ZodObject<{
-    scores: z.ZodArray<z.ZodObject<{
-        dimension: z.ZodEnum<{
-            schema: "schema";
-            req: "req";
-            uc: "uc";
-            arch: "arch";
-            alloc: "alloc";
-            ver: "ver";
-            cr: "cr";
-            ms: "ms";
-        }>;
-        score: z.ZodNullable<z.ZodNumber>;
-        violations: z.ZodNumber;
-        applicable: z.ZodNumber;
-        coreApplicable: z.ZodNumber;
-    }, z.core.$strip>>;
-    timestamp: z.ZodISODateTime;
-    steer: z.ZodOptional<z.ZodObject<{
-        worst: z.ZodNumber;
-        worstAt: z.ZodNullable<z.ZodObject<{
-            ruleId: z.ZodString;
-            elementId: z.ZodString;
-        }, z.core.$strip>>;
-        mean: z.ZodNumber;
-        score: z.ZodNumber;
-        measured: z.ZodNumber;
-        terms: z.ZodArray<z.ZodObject<{
-            ruleId: z.ZodString;
-            elementId: z.ZodString;
-            value: z.ZodNumber;
-            threshold: z.ZodNumber;
-            overshoot: z.ZodNumber;
-        }, z.core.$strip>>;
-    }, z.core.$strip>>;
-}, z.core.$strip>;
-export type ReadinessReportType = z.infer<typeof ReadinessReport>;
-/**
- * CR-SM-305 — welche Profile in die readiness-Zahlen eingehen, und warum `conformance` nicht.
- *
- * Der Nenner jeder Dimension ist `Σ (Elemente der Grundgesamtheit)` ueber die Regeln der
- * Dimension (`readiness-compute.ts`). Eine Regel, die DEKLARIERT, aber nicht AUSGEWERTET wird,
- * traegt damit zum Nenner bei und liefert null Verstoesse — der Score STEIGT, weil eine
- * Pruefung nicht gelaufen ist. Dieselbe Fail-open-Klasse wie ND-01/02 vor CR-SM-286, nur an der
- * Stelle, die am lautesten gelesen wird.
- *
- * Gemessen ueber vier Familien-Repos, was die sechs RC-Regeln in `arch`/`ver`/`schema`
- * geschenkt haetten: graph-view-edit `schema` +5,0 Punkte (Nenner 24 → 40), graphify `arch`
- * +2,1 und `ver` +1,8, alles Uebrige ≤ 0,2. Der Ausschlag sitzt genau dort, wo die Zahl am
- * meisten wiegt — in der kleinen Dimension.
- *
- * Deshalb steht keine RC-ID in `RULE_TO_DIMENSION` oder `RULE_TO_PHASE`. Das ist keine Luecke,
- * sondern die Aussage „nicht ausgewertet, also weder Zaehler noch Nenner";
- * `computeApplicable` ueberspringt eine Regel ohne Dimension bereits von selbst
- * (`if (!dim) continue`). Sichtbar wird RC ueber die Ableitung `ALL_RULE_DEFS minus
- * ausgewertet` beim Host: sechs Regeln, die als NICHT GEPRUEFT dastehen, solange kein Lauf
- * `CodeFacts` mitbringt.
- */
-export declare const READINESS_SCORED_PROFILES: readonly ["se", "coding"];
+/** Die Menge je Stufe, Index = Stufe − 1. */
+export declare const STAGE_SETS: readonly ["System", "Anwendungsfall", "Anforderung", "Wirkkette", "Funktion", "Datenfluss", "Modul", "Schema", "Test", "Plan", "Bindung", "Abgleich"];
+/** 1–12, oder `'immer'` fuer die Regeln ueber alle Elemente (R-08, R-18, CR-R03). */
+export type RuleStage = 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 'immer';
 /**
- * Rule → dimension mapping. Some rules belong to multiple dimensions;
- * here we assign primary dimension per rule. R-01 appears in 'ver' (primary)
- * since its core concern is test verification coverage.
+ * `existence` — die Regel verlangt, dass es die Menge ihrer Stufe gibt („kein Anwendungsfall →
+ * lege einen an"). `analysis` — sie verlangt ein Analyse-Artefakt; nur solche Befunde duerfen mit
+ * Begruendung abgenommen werden.
  */
-export declare const RULE_TO_DIMENSION: Record<string, ReadinessDimensionType>;
-/** INCOSE technical-review gates, in lifecycle order. */
-export declare const PhaseGate: z.ZodEnum<{
+export type RuleRole = 'existence' | 'analysis';
+/** Die Marken in Reihenfolge. */
+export declare const Mark: z.ZodEnum<{
     SRR: "SRR";
     PDR: "PDR";
     CDR: "CDR";
     TRR: "TRR";
+    Bau: "Bau";
 }>;
-export type PhaseGateType = z.infer<typeof PhaseGate>;
+export type MarkType = z.infer<typeof Mark>;
+/** Die letzte Stufe VOR jeder Marke. */
+export declare const MARK_STAGE: Readonly<Record<MarkType, number>>;
+/** Die Marke, hinter der eine Stufe liegt. `'immer'` gehoert keiner einzelnen Marke. */
+export declare function markOfStage(stage: RuleStage): MarkType | null;
 /**
- * Rule → phase-gate mapping (CR-SM-226). SRR = requirements/scope clarity,
- * PDR = architecture/functional completeness, CDR = critical design/schema
- * completeness, TRR = test readiness. Primary-gate assignment, same
- * single-owner convention as RULE_TO_DIMENSION.
- */
-export declare const RULE_TO_PHASE: Record<string, PhaseGateType>;
-/**
- * CR-SM-343 — die VORBEDINGUNG einer Regel: der Elementtyp, von dem der Graph mindestens ein
- * Element tragen muss, damit die Regel ueberhaupt ausgewertet ist.
+ * Die Arbeitsschritte (CR-SM-350, gekuerzt CR-SM-395).
  *
- * Der Nenner einer Dimension ist `Σ Grundgesamtheit` ueber ihre Regeln (`domain`). Eine Regel,
- * die mangels Gegenstand schweigt, truege dort ihre ganze Grundgesamtheit bei und liefert null
- * Verstoesse — der Score STIEGE, weil nicht geprueft wurde. CR-R05 fragt nach einem Bauauftrag;
- * ein Graph ohne einen einzigen CR (`cr: docs`) hat keinen Plan im Graphen, also ist die Frage
- * dort NICHT GESTELLT, nicht bestanden. Wer einen Anteil bildet, fragt `ruleApplies` und laesst
- * eine nicht anwendbare Regel aus Zaehler UND Nenner.
- */
-export declare const RULE_PRECONDITION: Readonly<Record<string, string>>;
-/** Ist die Regel an einem Graphen mit diesen Typ-Zaehlungen ausgewertet? (CR-SM-343) */
-export declare function ruleApplies(ruleId: string, countByType: Readonly<Record<string, number>>): boolean;
-/**
- * Die Eigentuemer-Spalte (CR-SM-350, Entscheidung 2026-09-22): welcher TASK eine Regel bearbeitet.
+ * CR-SM-350 fuehrte je Regel einen Eigentuemer: den KERN (die Schleife, die die Spezifikation baut)
+ * oder einen Task (Einsatzkonzept, Fehlerbetrachtung, Plan, Realisierung …), damit der Kern nicht
+ * um Detailregeln fremder Artefakte kreist. Das leistet jetzt die FAELLIGKEIT: eine Regel ueber eine
+ * Menge, die es noch nicht gibt, schweigt von selbst, und die Stufe ordnet den Rest.
  *
- * Eine Regel gehoert entweder dem KERN (der Generierungsschleife, die die Spezifikation baut) oder
- * einem Task, der als abgeschlossene Einheit laeuft: Skill + detailliertes Regelset + Ausgang.
- * Die Schleife sieht von einem Task nur seinen EINTRITTSPUNKT (TASK_ENTRY) — die Blackbox der Regeln.
- * Gefunden am Rig: der Kern-Loop kreiste um Detailregeln fremder Artefakte (FM-01 der FMEA, CR-R03
- * und MS-01 des Bauplans), die er weder erfuellen durfte noch sinnvoll konnte.
+ *   - Risiko-Anforderungen (FM-01..03), Auftraege und Meilensteine (CR-R01..03, MS-01..03): keine
+ *     Elemente, kein Befund.
+ *   - Betriebsarten (CL-01): einzeln geprueft — die Regel laeuft ueber ACTOR, die es im Kern gibt,
+ *     meldet aber erst, wenn ein UC eine `operatingMode` traegt. Die setzt nur das Einsatzkonzept.
+ *   - Bindung und Abgleich (Stufen 11 und 12): nicht faellig, bis der Bau eroeffnet ist (`isDue`).
  *
- * Eine Regel, die hier kein Task beansprucht, gehoert dem Kern. Die Konsumenten (graphcode-Fokus)
- * entscheiden, wie ein Task-Regelset erscheint (zunaechst als Warnung, nie blockierend).
+ * Es bleibt EINE Zuordnung, die die Faelligkeit nicht leistet: die Textqualitaet der Anforderungen
+ * (BQ-*) meldet an jeder REQ, sobald es eine gibt — sie gehoert einem eigenen Arbeitsschritt.
+ * Und es bleibt, welche Regel welche Analyse eroeffnet (`TASK_ENTRY`).
  */
-export declare const RULE_TASKS: readonly ["kern", "conops", "trade", "irr", "fmea", "plan", "anforderungsqualitaet", "realisierung"];
+export declare const RULE_TASKS: readonly ["kern", "conops", "trade", "irr", "fmea", "plan", "anforderungsqualitaet"];
 export type RuleTask = (typeof RULE_TASKS)[number];
-/** Die Regeln je Task (ohne Kern). Jede Regel hoechstens einmal — der Test haelt das fest. */
-export declare const TASK_OWNED_RULES: Readonly<Record<Exclude<RuleTask, 'kern'>, readonly string[]>>;
+/** Die Regeln, die ein Arbeitsschritt dem Kern abnimmt. Jede Regel hoechstens einmal — der Test haelt das fest. */
+export declare const TASK_OWNED_RULES: Readonly<Partial<Record<Exclude<RuleTask, 'kern'>, readonly string[]>>>;
 /**
- * Der Eintrittspunkt eines Tasks im Kern: die Regel, die "dieses Artefakt fehlt" sagt. `null` = der
- * Task wird ausdruecklich gerufen (Anforderungsqualitaet) oder durch einen Zustand ausgeloest
- * (Realisierung: die erste Bindung).
+ * Analyse → die Regel, die „diese Analyse fehlt" sagt (ihr Skill steht an der Regelhilfe,
+ * `RULE_HELP[…].prompt`). `null` = der Arbeitsschritt wird ausdruecklich gerufen.
  */
 export declare const TASK_ENTRY: Readonly<Record<Exclude<RuleTask, 'kern'>, string | null>>;
 /** Der Eigentuemer einer Regel — der Kern, wenn kein Task sie beansprucht. */
 export declare function taskOf(ruleId: string): RuleTask;
-/** The 8 RULE_TO_DIMENSION topic scores (req/uc/arch/alloc/ver/schema/cr/ms). */
-export declare const DIMENSION_READINESS_NAME = "dimension_readiness";
-/** The 4 RULE_TO_PHASE gate scores (SRR/PDR/CDR/TRR). */
+/** The marks derived from the rule stage (SRR/PDR/CDR/TRR/Bau). */
 export declare const PHASE_READINESS_NAME = "phase_readiness";
-/** Best-of-N ranking KPI: candidate dimension_readiness minus baseline. */
-export declare const DIMENSION_READINESS_DELTA_NAME = "dimension_readiness_delta";

package/dist/se/readiness.js

@@ -1,62 +1,12 @@
 /**
- * CR-120: Readiness dimension schemas for dynamic phase readiness.
- * Dimensions emerge from graph state — no state machine.
- * CR-SM-226: `emergentPhase`/`phaseScore` (CR-120/146) removed — a third,
- * undocumented phase construct next to RULE_TO_DIMENSION and the (then still
- * ad-hoc) phase-gate grouping. `RULE_TO_PHASE` below is the one replacement:
- * a rule → SRR/PDR/CDR/TRR mapping, same shape and same completeness
- * guarantee as `RULE_TO_DIMENSION`, exported so no consumer reinvents it.
+ * Stufen, Marken und Arbeitsschritte der Steuerung, dazu der Vertrag des Steuerungsraums.
+ * CR-SM-395: the phase axis is no longer a table. Each rule carries its stage; the mark
+ * (SRR/PDR/CDR/TRR/Bau) is derived from it — see "Stufen und Marken" below.
+ * CR-SM-401: die Dimension ist entfallen (Entscheidung des Autors 2026-10-07: „Stufe statt
+ * Dimension, Befunde zaehlen statt Prozent"). Es gibt EINE Einteilung der Regeln, die Stufe; die
+ * Zahl der Befunde je Stufe liefert `countByStage` in @sigloch/graphcode-client.
  */
 import { z } from 'zod/v4';
-export const ReadinessDimension = z.enum([
-    'req', // Requirements quality (BQ-01..07, RD-01..03)
-    'uc', // UC completeness (UC-01..06, R-14, FC-01..04)
-    'arch', // Functional architecture (R-02, R-03, R-10, R-12)
-    'alloc', // Module allocation (R-04)
-    'ver', // Test coverage (R-01, R-05)
-    'schema', // Interface completeness (R-26 binding, SC-02 usage)
-    'cr', // CR traceability (CR-R01..R03)
-    'ms', // Milestone planning (MS-01..02)
-]);
-export const ReadinessScore = z.object({
-    dimension: ReadinessDimension,
-    /**
-     * `1 - (violations / applicable)` — oder **`null`**, wenn die Dimension nicht messbar ist
-     * (CR-SM-270).
-     *
-     * `null` heisst nie 0 %, so wie schon bei `graph_metrics` (CR-GC-326): "a value that is not
-     * measurable is not zero percent". Der Anlass war die Gegenrichtung — ein Modell ohne einen
-     * einzigen Use Case meldete `uc: 0,997, ready: true`, weil 306 FUNC ueber eine einzige
-     * Fremdtyp-Regel (FC-03) den Nenner fuellten, waehrend die dreizehn Regeln, die wirklich Use
-     * Cases pruefen, nichts zu pruefen hatten und ihr SCHWEIGEN sich als Erfolg las. 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.
-     */
-    score: z.number().min(0).max(1).nullable(),
-    violations: z.number().int(),
-    applicable: z.number().int(),
-    /**
-     * CR-SM-270: die Kernmenge der Dimension — die Elemente der Typen, die die MEHRHEIT ihrer
-     * Regeln prueft (uc → UC/FCHAIN/ACTOR, arch → FUNC/MOD). Ist sie 0, ist `score` `null`.
-     *
-     * Sie steht im Bericht, weil sonst niemand das `null` erklaeren kann: `applicable` allein
-     * unterscheidet "nichts zu pruefen" (0) nicht von "nur Fremdtypen" (307). Genau die
-     * Unterscheidung, an der der dokumentierte Ausweg aus CR-SM-237 gescheitert ist.
-     */
-    coreApplicable: z.number().int(),
-    // 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
- * Dimensions-Scores — `ms` (3 Regeln) zählte so viel wie `arch` (~20 Regeln über Hunderte
- * Elemente), die Zahl bewegte sich also mit dem Größenverhältnis der Dimensionen und nicht mit
- * dem Zustand des Modells. Gelesen hat sie ohnehin niemand: der einzige Zugriff in der Familie
- * war eine Formprüfung (`'overallScore' in x`) im inzwischen gelöschten `weight-vector.ts`.
- * Ein interpretierbarer Ersatz (`1 − Σviolations / Σapplicable`) kommt, wenn er einen
- * Konsumenten hat — nicht auf Vorrat.
- */
 /**
  * CR-SM-337 (ITEM-2026-059) — der STEUERUNGSRAUM im Bericht, Stufe 1: der Vertrag.
  *
@@ -110,234 +60,59 @@ export const SteerSpace = z.object({
     /** Die Terme je Element, aus denen `worst` und `mean` entstehen. */
     terms: z.array(SteerTerm),
 });
-export const ReadinessReport = z.object({
-    scores: z.array(ReadinessScore),
-    timestamp: z.iso.datetime(),
-    /**
-     * CR-SM-337: OPTIONAL, damit ein aelterer Produzent gueltig bleibt — der Vertrag wandert vor
-     * dem Fueller (Stufe 2, graphcode CR-GC-537). Fehlt das Feld, heisst das "dieser Produzent
-     * kennt den Steuerungsraum noch nicht", und das ist etwas anderes als `measured: 0`.
-     */
-    steer: SteerSpace.optional(),
-});
-/**
- * CR-SM-305 — welche Profile in die readiness-Zahlen eingehen, und warum `conformance` nicht.
- *
- * Der Nenner jeder Dimension ist `Σ (Elemente der Grundgesamtheit)` ueber die Regeln der
- * Dimension (`readiness-compute.ts`). Eine Regel, die DEKLARIERT, aber nicht AUSGEWERTET wird,
- * traegt damit zum Nenner bei und liefert null Verstoesse — der Score STEIGT, weil eine
- * Pruefung nicht gelaufen ist. Dieselbe Fail-open-Klasse wie ND-01/02 vor CR-SM-286, nur an der
- * Stelle, die am lautesten gelesen wird.
- *
- * Gemessen ueber vier Familien-Repos, was die sechs RC-Regeln in `arch`/`ver`/`schema`
- * geschenkt haetten: graph-view-edit `schema` +5,0 Punkte (Nenner 24 → 40), graphify `arch`
- * +2,1 und `ver` +1,8, alles Uebrige ≤ 0,2. Der Ausschlag sitzt genau dort, wo die Zahl am
- * meisten wiegt — in der kleinen Dimension.
- *
- * Deshalb steht keine RC-ID in `RULE_TO_DIMENSION` oder `RULE_TO_PHASE`. Das ist keine Luecke,
- * sondern die Aussage „nicht ausgewertet, also weder Zaehler noch Nenner";
- * `computeApplicable` ueberspringt eine Regel ohne Dimension bereits von selbst
- * (`if (!dim) continue`). Sichtbar wird RC ueber die Ableitung `ALL_RULE_DEFS minus
- * ausgewertet` beim Host: sechs Regeln, die als NICHT GEPRUEFT dastehen, solange kein Lauf
- * `CodeFacts` mitbringt.
- */
-export const READINESS_SCORED_PROFILES = ['se', 'coding'];
-/**
- * Rule → dimension mapping. Some rules belong to multiple dimensions;
- * here we assign primary dimension per rule. R-01 appears in 'ver' (primary)
- * since its core concern is test verification coverage.
- */
-export const RULE_TO_DIMENSION = {
-    // req
-    'BQ-01': 'req', 'BQ-02': 'req', 'BQ-04': 'req',
-    'BQ-06': 'req', 'BQ-07': 'req',
-    'RD-01': 'req', 'RD-02': 'req',
-    // CR-SM-343: CR-R05 (Blatt-REQ ohne Bauauftrag) — ein Mangel der Anforderungsdeckung, nicht
-    // der CR-Hygiene; zaehlt nur, wenn der Graph ueberhaupt CR-Knoten traegt (RULE_PRECONDITION).
-    'CR-R05': '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', '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.
-    'R-30': 'arch', 'R-31': 'arch',
-    // uc
-    'UC-01': 'uc', 'UC-02': 'uc', 'UC-03': 'uc', 'UC-04': 'uc',
-    'R-15': 'uc', 'R-16': 'uc', 'R-17': 'uc',
-    // FC-04 (CR-SM-226): FCHAIN actor-bounded (trigger+consumer) — same dimension as FC-01..03.
-    'FC-02': 'uc', 'FC-03': 'uc', 'FC-04': 'uc',
-    'FC-05': 'uc', // CR-SM-363: Zusammenhang der Kette — dieselbe Dimension wie FC-04
-    // arch
-    'R-02': 'arch', 'R-10': 'arch', 'R-12': 'arch',
-    // alloc
-    'R-04': 'alloc',
-    // ver
-    'R-01': 'ver', 'R-05': 'ver',
-    // schema
-    'SC-02': 'schema', // SC-01/SC-03 deleted (BOK-CR-026) — R-26 is the binding rule
-    // SC-04 entfiel mit CR-SM-271: FLOW ohne SCHEMA ist jetzt Grammatik (R-18-Bein, error)
-    // und zaehlt damit unter R-18/'arch' statt als eigene 'schema'-Zeile.
-    // structural rules without primary dimension → assigned by closest concern
-    'R-08': 'arch',
-    // near-duplicate detection
-    'ND-01': 'arch', 'ND-02': 'schema',
-    // architecture metrics
-    // MT-03 is no longer here: it became a measurement (`allocationCohesion`), not a
-    // rule (CR-SM-223) — a per-module advisory would depress this score permanently.
-    'MT-01': 'alloc', 'MT-02': 'alloc',
-    // CR-SM-327: MT-04 misst die FUNC-Whitebox, nicht das Modul — Grundgesamtheit FUNC,
-    // also `arch` (Kern FUNC). In `alloc` waere sie eine Fremdtyp-Regel und wuerde deren
-    // Nenner um jede FUNC des Graphen aufblaehen (Klasse CR-SM-235/270, gemessen im CR).
-    'MT-04': 'arch',
-    // CR traceability
-    'CR-R01': 'cr', 'CR-R02': 'cr', 'CR-R03': 'cr', // architecture optimization
-    // CR-SM-283: BW-02 (Whitebox-Randbreite) ersetzt AO-D03 an dieser Stelle — dieselbe
-    // Dimension, denn beide fragen nach der Struktur des Funktionsschnitts, nicht nach Evidenz.
-    'BW-02': 'arch',
-    // allocation rules (CR-191)
-    'CR-01': 'arch', // milestone planning
-    'MS-01': 'ms', 'MS-02': 'ms', 'MS-03': 'ms',
-    // FMEA / risk
-    'FM-01': 'req', 'FM-02': 'req', 'FM-03': 'ver',
-    // CR-SM-227: analysis-artifact freshness presence — closest topical fit per artifact.
-    'AF-01': 'req', 'AF-03': 'req', // ConOps/Assumption-Review: requirements-adjacent judgment work
-    'IR-01': 'req', // CR-SM-355: Annahmen-Review promoviert zu CR — Task-Ausgang von irr
-    'AF-02': 'arch', // Trade Study: architecture decision record
-    'TR-01': 'arch', // CR-SM-355: Trade-Entscheidung als CR — Task-Ausgang von trade
-    'AF-04': 'ver', // FMEA: risk/verification, same bucket as FM-03
-    'AF-05': 'ms', // Implementation Plan: milestone/planning
-    // NFR budget
-    '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',
-};
 // ---------------------------------------------------------------------------
-// Phase-gate readiness (CR-SM-226) — the INCOSE technical-review axis.
-// Orthogonal to RULE_TO_DIMENSION (8 topic scores): RULE_TO_PHASE groups the
-// SAME rule violations into the 4 lifecycle gates SRR/PDR/CDR/TRR. Both are
-// projections of one rule stream — "three views over the same rule
-// violations" (docs/articles/07-the-scoring-landscape.md), not three
-// independent scoring systems. No advisory fall-through: every rule in
-// ALL_RULE_DEFS must appear here (enforced by a completeness test analogous
-// to the RULE_TO_DIMENSION one).
+// Stufen und Marken (CR-SM-395) — die Reihenfolge der Mengen.
+//
+// Jede Regel traegt an ihrer Definition eine STUFE (`RuleDefinition.stage`): die spaeteste Menge,
+// die sie BRAUCHT — nicht der Typ, ueber den sie laeuft (FM-03 laeuft ueber REQ, verlangt aber
+// einen TEST: Stufe 9). Die Stufen ordnen, sie verbieten nichts.
+//
+// Eine MARKE liegt zwischen zwei Stufen und wird aus der Stufe berechnet (`markOfStage`). Es gibt
+// keine zweite Zuordnung: `RULE_TO_PHASE` (CR-SM-226, 67 Handeintraege) ist entfallen, die Marke je
+// Regel steht abgeleitet in `ALL_RULE_DEFS[].mark`.
 // ---------------------------------------------------------------------------
-/** INCOSE technical-review gates, in lifecycle order. */
-export const PhaseGate = z.enum(['SRR', 'PDR', 'CDR', 'TRR']);
-/**
- * Rule → phase-gate mapping (CR-SM-226). SRR = requirements/scope clarity,
- * PDR = architecture/functional completeness, CDR = critical design/schema
- * completeness, TRR = test readiness. Primary-gate assignment, same
- * single-owner convention as RULE_TO_DIMENSION.
- */
-export const RULE_TO_PHASE = {
-    // CR-SM-227: Analysis-Freshness-Legs (AF-01..05) — Familie-Review 2026-08-05; revidiert durch
-    // CR-SM-354 (2026-09-22) gegen NASA NPR 7123.1D Appendix G: das Operations Concept ist ein
-    // SRR-Eintrittskriterium (AF-01 → SRR), Integrationsplan und Master Schedule werden zur PDR
-    // baselined (AF-05 → PDR). Trade / Assumption Review PDR und FMEA CDR bleiben.
-    'AF-01': 'SRR', // ConOps
-    'AF-02': 'PDR', 'AF-03': 'PDR', // Trade Study, Assumption Review
-    'AF-04': 'CDR', // FMEA
-    'AF-05': 'PDR', // Implementation Plan
-    'TR-01': 'PDR', 'IR-01': 'PDR', // CR-SM-355: Task-Ausgaenge von trade / irr — dasselbe Gate wie ihr Eintritt
-    // SRR — requirements/scope clarity, system+UC boundary definition.
-    'BQ-01': 'SRR', 'BQ-02': 'SRR', 'BQ-04': 'SRR', 'BQ-06': 'SRR', 'BQ-07': 'SRR',
-    'RD-01': 'SRR', 'RD-02': 'SRR',
-    'UC-01': 'SRR', 'UC-02': 'SRR', 'UC-03': 'SRR', 'UC-04': 'SRR',
-    'R-16': 'SRR', 'R-17': 'SRR',
-    'FC-02': 'SRR',
-    'CL-01': 'SRR',
-    'FM-01': 'SRR', 'FM-02': 'SRR',
-    'CR-R01': 'SRR', 'CR-R03': 'SRR',
-    'MS-01': 'SRR', 'MS-02': 'SRR', 'MS-03': 'SRR',
-    // PDR — architecture/functional completeness.
-    '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',
-    'FC-03': 'PDR', 'FC-04': 'PDR', 'FC-05': 'PDR',
-    // CR-GC-366: Anschluss des Funktionsbaus — gehoert an dasselbe Gate wie R-15/IO-01,
-    // die auf derselben Kette aufsetzen.
-    'R-30': 'PDR', 'R-31': 'PDR',
-    'MT-01': 'PDR', 'MT-02': 'PDR', 'MT-04': 'PDR', // CR-SM-327: dieselbe Reifephase wie MT-02
-    'ND-01': 'PDR',
-    '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.
-    '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-32': 'TRR', 'R-19': 'TRR', 'R-20': 'TRR', 'R-21': 'TRR',
-    'R-26': 'TRR', // CR-SM-354: dieselbe Aussage wie R-20 (Praesenz von Code) — as-built ist TRR, nicht CDR
-    // 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',
-    'VR-01': 'TRR',
-    'FM-03': 'TRR',
-    'CR-R02': 'TRR',
-    'CR-R05': 'TRR', // CR-SM-343: dieselbe Phase wie AF-05 (Implementierungsplan)
-};
-/**
- * CR-SM-343 — die VORBEDINGUNG einer Regel: der Elementtyp, von dem der Graph mindestens ein
- * Element tragen muss, damit die Regel ueberhaupt ausgewertet ist.
- *
- * Der Nenner einer Dimension ist `Σ Grundgesamtheit` ueber ihre Regeln (`domain`). Eine Regel,
- * die mangels Gegenstand schweigt, truege dort ihre ganze Grundgesamtheit bei und liefert null
- * Verstoesse — der Score STIEGE, weil nicht geprueft wurde. CR-R05 fragt nach einem Bauauftrag;
- * ein Graph ohne einen einzigen CR (`cr: docs`) hat keinen Plan im Graphen, also ist die Frage
- * dort NICHT GESTELLT, nicht bestanden. Wer einen Anteil bildet, fragt `ruleApplies` und laesst
- * eine nicht anwendbare Regel aus Zaehler UND Nenner.
- */
-export const RULE_PRECONDITION = {
-    'CR-R05': 'CR',
-};
-/** Ist die Regel an einem Graphen mit diesen Typ-Zaehlungen ausgewertet? (CR-SM-343) */
-export function ruleApplies(ruleId, countByType) {
-    const required = RULE_PRECONDITION[ruleId];
-    return required === undefined || (countByType[required] ?? 0) > 0;
+/** Die Menge je Stufe, Index = Stufe − 1. */
+export const STAGE_SETS = [
+    'System', 'Anwendungsfall', 'Anforderung', 'Wirkkette', 'Funktion', 'Datenfluss', 'Modul',
+    'Schema', 'Test', 'Plan', 'Bindung', 'Abgleich',
+];
+/** Die Marken in Reihenfolge. */
+export const Mark = z.enum(['SRR', 'PDR', 'CDR', 'TRR', 'Bau']);
+/** Die letzte Stufe VOR jeder Marke. */
+export const MARK_STAGE = { SRR: 4, PDR: 7, CDR: 8, TRR: 9, Bau: 12 };
+/** Die Marke, hinter der eine Stufe liegt. `'immer'` gehoert keiner einzelnen Marke. */
+export function markOfStage(stage) {
+    if (stage === 'immer')
+        return null;
+    return Mark.options.find((m) => stage <= MARK_STAGE[m]) ?? null;
 }
 /**
- * Die Eigentuemer-Spalte (CR-SM-350, Entscheidung 2026-09-22): welcher TASK eine Regel bearbeitet.
+ * Die Arbeitsschritte (CR-SM-350, gekuerzt CR-SM-395).
+ *
+ * CR-SM-350 fuehrte je Regel einen Eigentuemer: den KERN (die Schleife, die die Spezifikation baut)
+ * oder einen Task (Einsatzkonzept, Fehlerbetrachtung, Plan, Realisierung …), damit der Kern nicht
+ * um Detailregeln fremder Artefakte kreist. Das leistet jetzt die FAELLIGKEIT: eine Regel ueber eine
+ * Menge, die es noch nicht gibt, schweigt von selbst, und die Stufe ordnet den Rest.
  *
- * Eine Regel gehoert entweder dem KERN (der Generierungsschleife, die die Spezifikation baut) oder
- * einem Task, der als abgeschlossene Einheit laeuft: Skill + detailliertes Regelset + Ausgang.
- * Die Schleife sieht von einem Task nur seinen EINTRITTSPUNKT (TASK_ENTRY) — die Blackbox der Regeln.
- * Gefunden am Rig: der Kern-Loop kreiste um Detailregeln fremder Artefakte (FM-01 der FMEA, CR-R03
- * und MS-01 des Bauplans), die er weder erfuellen durfte noch sinnvoll konnte.
+ *   - Risiko-Anforderungen (FM-01..03), Auftraege und Meilensteine (CR-R01..03, MS-01..03): keine
+ *     Elemente, kein Befund.
+ *   - Betriebsarten (CL-01): einzeln geprueft — die Regel laeuft ueber ACTOR, die es im Kern gibt,
+ *     meldet aber erst, wenn ein UC eine `operatingMode` traegt. Die setzt nur das Einsatzkonzept.
+ *   - Bindung und Abgleich (Stufen 11 und 12): nicht faellig, bis der Bau eroeffnet ist (`isDue`).
  *
- * Eine Regel, die hier kein Task beansprucht, gehoert dem Kern. Die Konsumenten (graphcode-Fokus)
- * entscheiden, wie ein Task-Regelset erscheint (zunaechst als Warnung, nie blockierend).
+ * Es bleibt EINE Zuordnung, die die Faelligkeit nicht leistet: die Textqualitaet der Anforderungen
+ * (BQ-*) meldet an jeder REQ, sobald es eine gibt — sie gehoert einem eigenen Arbeitsschritt.
+ * Und es bleibt, welche Regel welche Analyse eroeffnet (`TASK_ENTRY`).
  */
-export const RULE_TASKS = ['kern', 'conops', 'trade', 'irr', 'fmea', 'plan', 'anforderungsqualitaet', 'realisierung'];
-/** Die Regeln je Task (ohne Kern). Jede Regel hoechstens einmal — der Test haelt das fest. */
+export const RULE_TASKS = ['kern', 'conops', 'trade', 'irr', 'fmea', 'plan', 'anforderungsqualitaet'];
+/** Die Regeln, die ein Arbeitsschritt dem Kern abnimmt. Jede Regel hoechstens einmal — der Test haelt das fest. */
 export const TASK_OWNED_RULES = {
-    conops: ['CL-01'],
-    trade: ['TR-01'], // CR-SM-355: Trade-Entscheidung als CR
-    irr: ['IR-01'], // CR-SM-355: Annahmen-Review promoviert zu CR
-    fmea: ['FM-01', 'FM-02', 'FM-03'],
-    // CR-SM-377: CR-R05 (Blatt-REQ ohne Bauauftrag, CR-SM-343) fragt nach einem CR — die Antwort
-    // schreibt der Plan-Task (se-plan), nicht die Generierungsschleife. FC-05 bleibt Kern: die
-    // Kette zu schliessen ist Spezifikationsarbeit wie FC-04.
-    plan: ['MS-01', 'MS-02', 'MS-03', 'CR-R01', 'CR-R02', 'CR-R03', 'CR-R05'],
-    // Annahme (CR-SM-350): BQ bekommt einen eigenen Task, vorerst ohne automatischen Eintrittspunkt.
+    // Annahme (CR-SM-350): BQ bekommt einen eigenen Task, ohne automatischen Eintrittspunkt.
     anforderungsqualitaet: ['BQ-01', 'BQ-02', 'BQ-04', 'BQ-06', 'BQ-07'],
-    realisierung: ['R-19', 'R-20', 'R-26', 'R-29', 'R-32', 'VR-01', 'RC-01', 'RC-02', 'RC-03', 'RC-04', 'RC-05', 'RC-06', 'RC-07', 'RC-08', 'RC-09', 'RC-10'],
 };
 /**
- * Der Eintrittspunkt eines Tasks im Kern: die Regel, die "dieses Artefakt fehlt" sagt. `null` = der
- * Task wird ausdruecklich gerufen (Anforderungsqualitaet) oder durch einen Zustand ausgeloest
- * (Realisierung: die erste Bindung).
+ * Analyse → die Regel, die „diese Analyse fehlt" sagt (ihr Skill steht an der Regelhilfe,
+ * `RULE_HELP[…].prompt`). `null` = der Arbeitsschritt wird ausdruecklich gerufen.
  */
 export const TASK_ENTRY = {
     conops: 'AF-01',
@@ -346,9 +121,8 @@ export const TASK_ENTRY = {
     fmea: 'AF-04',
     plan: 'AF-05',
     anforderungsqualitaet: null,
-    realisierung: null,
 };
-const OWNER = new Map(Object.entries(TASK_OWNED_RULES).flatMap(([task, ids]) => ids.map((id) => [id, task])));
+const OWNER = new Map(Object.entries(TASK_OWNED_RULES).flatMap(([task, ids]) => (ids ?? []).map((id) => [id, task])));
 /** Der Eigentuemer einer Regel — der Kern, wenn kein Task sie beansprucht. */
 export function taskOf(ruleId) {
     return OWNER.get(ruleId) ?? 'kern';
@@ -357,9 +131,5 @@ export function taskOf(ruleId) {
 // Sprachregelung (CR-SM-226) — naming SSOT so graphcode/graph-view-edit/
 // article render the same terms instead of re-inventing string literals.
 // ---------------------------------------------------------------------------
-/** The 8 RULE_TO_DIMENSION topic scores (req/uc/arch/alloc/ver/schema/cr/ms). */
-export const DIMENSION_READINESS_NAME = 'dimension_readiness';
-/** The 4 RULE_TO_PHASE gate scores (SRR/PDR/CDR/TRR). */
+/** The marks derived from the rule stage (SRR/PDR/CDR/TRR/Bau). */
 export const PHASE_READINESS_NAME = 'phase_readiness';
-/** Best-of-N ranking KPI: candidate dimension_readiness minus baseline. */
-export const DIMENSION_READINESS_DELTA_NAME = 'dimension_readiness_delta';

package/dist/se/rule-due.d.ts

@@ -0,0 +1,26 @@
+import type { OntologyGraph } from './ontology.js';
+import type { RuleStage } from './readiness.js';
+import type { RuleViolation } from './rules.js';
+/**
+ * Gibt es einen offenen Auftrag — einen CR mit `status: open`? Er muss nicht auf die Elemente zeigen.
+ *
+ * CR-SM-400 (Entscheidung des Autors 2026-10-07): ein offener CR IST ein Bauauftrag. Eine
+ * Entscheidung — das Ergebnis einer Analyse oder Optimierung — ist ein ERLEDIGTER Auftrag und
+ * eroeffnet deshalb keinen Bau. Der Filter auf `relation [label: decides]` (CR-SM-396) ist ohne
+ * Ersatz entfallen.
+ */
+export declare function hasOpenOrder(graph: OntologyGraph): boolean;
+/** Ist die Regel an diesem Graphen faellig — ist ihre Menge nicht leer? */
+export declare function isDue(rule: {
+    stage: RuleStage;
+    domain: readonly string[];
+}, graph: OntologyGraph): boolean;
+/**
+ * Wickelt das `evaluate` der Regeln, deren Menge nicht ihre `domain` ist (Stufen 11 und 12) — am
+ * Katalog, einmal. Die uebrigen Regeln kommen unveraendert (dieselbe Referenz) zurueck.
+ */
+export declare function whenDue<A extends unknown[], R extends {
+    stage: RuleStage;
+    domain: readonly string[];
+    evaluate: (graph: OntologyGraph, ...rest: A) => RuleViolation[];
+}>(rules: readonly R[]): R[];