@sigloch/contracts 10.14.0 → 11.0.0

package/dist/se/readiness.d.ts

@@ -1,32 +1,29 @@
 /**
  * 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.
+ * 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.
  */
 import { z } from 'zod/v4';
 export declare const ReadinessDimension: z.ZodEnum<{
-    schema: "schema";
     req: "req";
     uc: "uc";
     arch: "arch";
     alloc: "alloc";
     ver: "ver";
+    schema: "schema";
     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";
+        schema: "schema";
         cr: "cr";
         ms: "ms";
     }>;
@@ -93,12 +90,12 @@ 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";
+            schema: "schema";
             cr: "cr";
             ms: "ms";
         }>;
@@ -141,7 +138,7 @@ export type ReadinessReportType = z.infer<typeof ReadinessReport>;
  * +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,
+ * Deshalb steht keine RC-ID in `RULE_TO_DIMENSION`. 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
@@ -155,62 +152,63 @@ export declare const READINESS_SCORED_PROFILES: readonly ["se", "coding"];
  * since its core concern is test verification coverage.
  */
 export declare const RULE_TO_DIMENSION: Record<string, ReadinessDimensionType>;
-/** INCOSE technical-review gates, in lifecycle order. */
-export declare const PhaseGate: z.ZodEnum<{
+/** 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';
+/**
+ * `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 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>;
-/**
- * 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>;
+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;
 /**
- * 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.
+ *   - Variantenvergleich und Annahmen-Review (TR-01, IR-01): melden erst, wenn die Analyse
+ *     gestempelt ist.
+ *   - 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,11 +1,8 @@
 /**
  * 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.
+ * 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.
  */
 import { z } from 'zod/v4';
 export const ReadinessDimension = z.enum([
@@ -21,8 +18,9 @@ export const ReadinessDimension = z.enum([
 export const ReadinessScore = z.object({
     dimension: ReadinessDimension,
     /**
-     * `1 - (violations / applicable)` — oder **`null`**, wenn die Dimension nicht messbar ist
-     * (CR-SM-270).
+     * `1 - (violations / applicable)` — oder **`null`**, wenn die Dimension nicht messbar ist:
+     * nichts wurde geprueft (`applicable === 0`, CR-SM-395 — vorher 0,0) oder die Kernmenge ist
+     * leer (`coreApplicable === 0`, 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
@@ -134,7 +132,7 @@ export const ReadinessReport = z.object({
  * +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,
+ * Deshalb steht keine RC-ID in `RULE_TO_DIMENSION`. 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
@@ -152,9 +150,6 @@ export const RULE_TO_DIMENSION = {
     '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
@@ -164,7 +159,10 @@ export const RULE_TO_DIMENSION = {
     // 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
+    'R-22': 'alloc', 'R-23': 'alloc', 'R-26': 'schema', 'R-32': 'ver',
+    // CR-SM-395: die Existenz-Regel des Systems. R-33 prueft den Graphen (kein Gruppen-Score).
+    'R-33': 'uc',
+    // 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.
@@ -209,7 +207,7 @@ export const RULE_TO_DIMENSION = {
     '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
+    'IR-01': 'req', // CR-SM-355/397: die Anforderungen des Annahmen-Reviews existieren — 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
@@ -224,120 +222,60 @@ export const RULE_TO_DIMENSION = {
     '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.
+ *   - Variantenvergleich und Annahmen-Review (TR-01, IR-01): melden erst, wenn die Analyse
+ *     gestempelt ist.
+ *   - 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 +284,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';
@@ -359,7 +296,7 @@ export function taskOf(ruleId) {
 // ---------------------------------------------------------------------------
 /** 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,35 @@
+import type { OntologyGraph } from './ontology.js';
+import type { RuleStage } from './readiness.js';
+import type { RuleViolation } from './rules.js';
+/**
+ * Gibt es einen offenen BAUAUFTRAG — einen CR mit `status: open`, aus dem Code entsteht? Er muss
+ * nicht auf die Elemente zeigen.
+ *
+ * CR-SM-396 (Entscheidung des Autors 2026-10-06): ein reiner ENTSCHEIDUNGS-CR zaehlt nicht. Der
+ * Variantenvergleich haelt sein Ergebnis als CR fest; solange nur solche offen sind, ist nichts
+ * beauftragt — der Entwurf bliebe sonst mit dem ersten Variantenvergleich „im Bau" und truege die
+ * ganze Bindung als Arbeitsliste. Die uebrigen Analysen hinterlassen gar keinen CR, sondern
+ * Anforderungen mit Test (CR-SM-397); Bauauftraege entstehen nur im Bauplan.
+ *
+ * Das Merkmal ist die Kante, die den CR zur Entscheidung macht: eine ausgehende
+ * `relation [label: decides]` (SP-1; TR-01 verlangt sie an jedem CR eines Variantenvergleichs).
+ * Kein neues Attribut. Nicht `architectureOnly`: das traegt heute kein offener CR, nur die
+ * verworfenen Optionen. Nicht „Umfang auf FUNC/MOD/SCHEMA": ein Entscheidungs-CR zeigt daneben
+ * mit gewoehnlichen Kanten auf das, was er betrifft, und ein Bauauftrag fuer eine Anforderung am
+ * Modul traegt seine Kante an der REQ (CR-SM-343).
+ */
+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[];

package/dist/se/rule-due.js

@@ -0,0 +1,83 @@
+/**
+ * FAELLIGKEIT (CR-SM-395) — der EINE Mechanismus, mit dem eine Regel auf ihren Zeitpunkt wartet.
+ *
+ * Jede Regel hat eine Menge: die Elemente, die sie prueft. Faellig ist sie, sobald die Menge nicht
+ * leer ist. Fuer die Stufen 1 bis 10 ist die Menge die `domain` der Regel — eine Regel ueber eine
+ * leere Menge schweigt von selbst, dort ist nichts zu bauen. Fuer die Stufen 11 (Bindung) und 12
+ * (Abgleich Modell gegen Code) ist die Menge der BAU: er ist eroeffnet, sobald es einen offenen
+ * BAUAUFTRAG gibt (`hasOpenOrder` — ein offener Entscheidungs-CR ist keiner) oder irgendeine
+ * Bindung. Vorher ist die Regel NICHT AUSGEWERTET — nicht bestanden.
+ *
+ * Zwei Leser, eine Funktion:
+ *   - AUSWERTUNG: `whenDue` wickelt das `evaluate` der Regeln der Stufen 11 und 12 am Katalog
+ *     (`V3_RULES`, `VIEW_RULES`, `CODE_CONFORMANCE_RULES`). Wer immer die Regel ruft, bekommt das
+ *     Schweigen — auch ein direkter `rule.evaluate`-Aufruf.
+ *   - READINESS: wer einen Anteil bildet, fragt `isDue` und laesst eine nicht faellige Regel aus
+ *     Zaehler UND Nenner — sonst liest sich ihr Schweigen als Erfolg.
+ *
+ * Ersetzt `RULE_PRECONDITION` / `ruleApplies` / `withPrecondition` / `realizationBegun`
+ * (CR-SM-392): dort war „der Bau hat begonnen" eine benannte Vorbedingung an vier Regeln, mit dem
+ * Bauplan-Stempel als Ausloeser. Der Stempel wird nicht mehr gelesen; die Fuehrung uebernimmt
+ * AF-05 („es gibt Ungebautes, aber keinen offenen Auftrag").
+ */
+import { readRealRef, readTestRefs } from './ontology.js';
+import { toEvaluableGraph } from './flat-graph.js';
+/**
+ * Gibt es einen offenen BAUAUFTRAG — einen CR mit `status: open`, aus dem Code entsteht? Er muss
+ * nicht auf die Elemente zeigen.
+ *
+ * CR-SM-396 (Entscheidung des Autors 2026-10-06): ein reiner ENTSCHEIDUNGS-CR zaehlt nicht. Der
+ * Variantenvergleich haelt sein Ergebnis als CR fest; solange nur solche offen sind, ist nichts
+ * beauftragt — der Entwurf bliebe sonst mit dem ersten Variantenvergleich „im Bau" und truege die
+ * ganze Bindung als Arbeitsliste. Die uebrigen Analysen hinterlassen gar keinen CR, sondern
+ * Anforderungen mit Test (CR-SM-397); Bauauftraege entstehen nur im Bauplan.
+ *
+ * Das Merkmal ist die Kante, die den CR zur Entscheidung macht: eine ausgehende
+ * `relation [label: decides]` (SP-1; TR-01 verlangt sie an jedem CR eines Variantenvergleichs).
+ * Kein neues Attribut. Nicht `architectureOnly`: das traegt heute kein offener CR, nur die
+ * verworfenen Optionen. Nicht „Umfang auf FUNC/MOD/SCHEMA": ein Entscheidungs-CR zeigt daneben
+ * mit gewoehnlichen Kanten auf das, was er betrifft, und ein Bauauftrag fuer eine Anforderung am
+ * Modul traegt seine Kante an der REQ (CR-SM-343).
+ */
+export function hasOpenOrder(graph) {
+    const g = toEvaluableGraph(graph);
+    const decisions = new Set(g.traces.filter((t) => t.type === 'relation' && t.label === 'decides').map((t) => t.source));
+    return g.elements.some((e) => e.type === 'CR' && e.attributes?.status === 'open' && !decisions.has(e.id));
+}
+const BUILD_OPEN = new WeakMap();
+/**
+ * Ist der Bau eroeffnet? Ein offener Auftrag ODER eine Bindung — ein `realRef` an irgendeinem
+ * Element oder `testRefs` an einem TEST. Eine Bindung von Hand, ohne Bauplan, zaehlt genauso.
+ * Gezaehlt wird die ANWESENHEIT des Attributs, nicht seine Gueltigkeit: eine ungueltige Bindung
+ * (leere Liste, alte Objektform) ist ein Bindungsversuch, und R-19/R-20/R-26 sind die einzigen
+ * Regeln, die sie melden — an „gueltig" gebunden schwiegen sie genau dort.
+ *
+ * Nimmt die flache wie die genestete Form; das Ergebnis haengt an der Graph-Identitaet wie `indexOf`.
+ */
+function buildOpen(graph) {
+    const cached = BUILD_OPEN.get(graph);
+    if (cached !== undefined)
+        return cached;
+    const open = hasOpenOrder(graph) ||
+        toEvaluableGraph(graph).elements.some((e) => readRealRef(e.attributes).state !== 'absent' ||
+            (e.type === 'TEST' && readTestRefs(e.attributes).state !== 'absent'));
+    BUILD_OPEN.set(graph, open);
+    return open;
+}
+/** Ist die Regel an diesem Graphen faellig — ist ihre Menge nicht leer? */
+export function isDue(rule, graph) {
+    if (rule.stage === 11 || rule.stage === 12)
+        return buildOpen(graph);
+    if (rule.domain.includes('graph'))
+        return true;
+    return graph.elements.some((e) => rule.domain.includes('all') || rule.domain.includes(e.type));
+}
+/**
+ * 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 function whenDue(rules) {
+    return rules.map((rule) => rule.stage === 11 || rule.stage === 12
+        ? { ...rule, evaluate: (graph, ...rest) => (isDue(rule, graph) ? rule.evaluate(graph, ...rest) : []) }
+        : rule);
+}

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

@@ -56,6 +56,8 @@ export interface RuleHelpEntry {
      * Fix-Vorlage — der Nutzer entscheidet, der Agent fuehrt aus (graphcode CR-GC-729/730). Genau an den
      * Regeln, die den Kern-Fokus stellen koennen: Task `kern`, Schwere nicht `info`, kein Eintrittspunkt
      * einer Analyse (die haben ihren eigenen Satz beim Konsumenten). Beidseitig erzwungen im Test.
+     * CR-SM-395: seit die Arbeitsschritt-Zuordnung auf die Anforderungsqualitaet gekuerzt ist, sind das
+     * auch die Regeln ueber Risiken, Auftraege, Meilensteine, Bindung und Abgleich.
      */
     readonly vorschlag?: string;
 }