@sigloch/graphcode-client 0.7.0 → 0.8.0

package/dist/readiness.d.ts

@@ -68,9 +68,32 @@ export type IncoseScope = 'lean' | 'full';
 /** graphcode's declared scope — see the module header for the rationale. */
 export declare const GRAPHCODE_INCOSE_SCOPE: IncoseScope;
 /**
- * Phase-Readiness gates (INCOSE technical reviews) → the element-level V3_RULES
- * each gate owns. DISJOINT + EXHAUSTIVE over the 15 element rules; verified by
- * TEST-readiness-model against SE_DESCRIPTOR at runtime (never hardcoded count).
+ * Which rules the impl gates own: the milestone- and change-level family. The impl
+ * gates ARE the milestone/CR burndown (SAR/FCA/SVR/FRR ↔ MS-1..MS-4), so a rule about
+ * a milestone or a change request belongs there and not on a design review.
+ *
+ * Derived from the prefix over the contracts catalog (CR-GC-312) — a new `MS-`/`CR-R`
+ * rule lands here without an edit. Before, this was `['MS-01','MS-02']` written out,
+ * frozen at the two rules that existed when it was authored.
+ */
+export declare const IMPL_GATE_RULES: readonly string[];
+/**
+ * Phase-Readiness gates (INCOSE technical reviews) → the rules each gate owns.
+ * DISJOINT + EXHAUSTIVE over the rule catalog; asserted by TEST-readiness-model
+ * against SE_DESCRIPTOR at runtime, never a hardcoded count.
+ *
+ * DERIVED from `RULE_TO_PHASE` (CR-GC-312). This used to be a hand-written literal —
+ * and contracts had already replaced it: CR-SM-226 removed `emergentPhase`/`phaseScore`
+ * as "a third, undocumented phase construct next to RULE_TO_DIMENSION and the (then
+ * still ad-hoc) phase-gate grouping", introducing `RULE_TO_PHASE` as the one
+ * replacement, "exported so no consumer reinvents it". That ad-hoc grouping was THIS
+ * object, and the replacement was never carried through here.
+ *
+ * The cost of leaving it: the literal and `RULE_TO_PHASE` had drifted apart on 21 of
+ * 33 shared rules — R-01 SRR vs TRR, R-08 TRR vs PDR, RD-01..03 CDR vs SRR, and so on.
+ * Two live gate assignments for the same rules, and readiness was scored against the
+ * frozen one. Deriving moves those rules onto the assignment contracts declares; gate
+ * scores change accordingly, which is the correction, not a side effect.
  */
 export declare const PHASE_GATE_RULES: Record<string, readonly string[]>;
 /** Human labels for the phase gates. */
@@ -108,12 +131,6 @@ export declare const IMPL_GATE_MILESTONES: Record<string, {
     ms: string;
     label: string;
 }>;
-/**
- * The 2 milestone-level V3_RULES the impl gates embody (MS-01 empty scope,
- * MS-02 dangling dependency). Together with the phase-gate rules these span
- * V3_RULES exhaustively — so the model covers it with nothing left over.
- */
-export declare const IMPL_GATE_RULES: readonly string[];
 /**
  * A single readiness gate outcome.
  * `passed` is the hard verdict (no blocking/error item); `score` ∈ [0,1] is a

package/dist/readiness.js

@@ -1,39 +1,81 @@
 import { SE_DESCRIPTOR } from '@sigloch/graph-api-core';
-import { CODE_CONFORMANCE_RULES } from '@sigloch/contracts/se';
+import { CODE_CONFORMANCE_RULES, RULE_TO_PHASE } from '@sigloch/contracts/se';
 import { scoreCompleteness, NEUTRAL_COMPLETENESS, } from './readiness-completeness.js';
 /** graphcode's declared scope — see the module header for the rationale. */
 export const GRAPHCODE_INCOSE_SCOPE = 'lean';
 /**
- * Phase-Readiness gates (INCOSE technical reviews) → the element-level V3_RULES
- * each gate owns. DISJOINT + EXHAUSTIVE over the 15 element rules; verified by
- * TEST-readiness-model against SE_DESCRIPTOR at runtime (never hardcoded count).
+ * Which rules the impl gates own: the milestone- and change-level family. The impl
+ * gates ARE the milestone/CR burndown (SAR/FCA/SVR/FRR ↔ MS-1..MS-4), so a rule about
+ * a milestone or a change request belongs there and not on a design review.
+ *
+ * Derived from the prefix over the contracts catalog (CR-GC-312) — a new `MS-`/`CR-R`
+ * rule lands here without an edit. Before, this was `['MS-01','MS-02']` written out,
+ * frozen at the two rules that existed when it was authored.
+ */
+export const IMPL_GATE_RULES = Object.keys(RULE_TO_PHASE)
+    .filter((id) => /^(MS-|CR-R)/.test(id))
+    .sort();
+/**
+ * `RULE_TO_PHASE` covers the whole catalog including the CODING profile (`BQ-` and
+ * `ND-` prefixes). The readiness model is the SE profile only — `SE_DESCRIPTOR.rules`
+ * deliberately excludes those, so a gate must not claim one and then never see it fire.
  */
-export const PHASE_GATE_RULES = {
-    // System + use-case structure exists; every requirement is verifiable.
-    SRR: ['R-17', 'R-14', 'R-01'],
-    // Functional architecture: chains, actors, flows; functions trace to REQs.
-    PDR: ['R-15', 'R-16', 'R-10', 'R-02'],
-    // Detailed design: ASIL isolation, module size, no cycles, sound decomposition,
-    // valid trace patterns (R-18: every trace's element-type pair is legal — now also
-    // flags any residual REQ→MOD allocate edge, CR-228), module allocation (R-22
-    // FUNC→MOD, R-23 MOD→FUNC — CR-202/208), and FUNC→code binding — presence (R-20: every non-concept
-    // FUNC carries a realRef, CR-GC-205 Item 5) AND resolution (RC-01: the realRef
-    // points at a declared symbol on disk — CR-GC-253 conformance, with CodeFacts).
-    // SCHEMA realRef binding (R-26 presence, RC-03 resolution, RC-04 parsed-at-interface —
-    // CR-211) and physical-MOD realRef presence (R-27, CR-228) join the realRef family
-    // (R-20/RC-01) here: interfaces + parts are detailed design.
-    // RC-05 (cross-module import drift — CR-212) is module-coupling: also detailed design.
-    // RD-04 (decomposition breadth > 11 children per level, CR-SM-221) is a structural
-    // property of the detailed design, next to RD-01..03.
-    // MT-01/MT-02 (instability, LCOM4 — CR-SM-222) are architecture metrics over the
-    // module structure: detailed design too. Their severities are warning/info, so they
-    // surface the gate as 'open', never 'blocked'. MT-03 is NOT here — allocation
-    // cohesion became a measurement rather than a rule (CR-SM-223).
-    CDR: ['R-03', 'R-04', 'R-12', 'R-18', 'R-20', 'R-22', 'R-23', 'R-26', 'R-27', 'RC-01', 'RC-03', 'RC-04', 'RC-05', 'RD-01', 'RD-02', 'RD-03', 'RD-04', 'MT-01', 'MT-02'],
-    // Verification wired (TEST→REQ) + referential trace consistency + runnable test
-    // bindings — presence (R-19) AND resolution (RC-02: file + case exist, CR-GC-253).
-    TRR: ['R-05', 'R-08', 'R-19', 'R-21', 'RC-02'],
+const isCodingProfile = (id) => /^(BQ-|ND-)/.test(id);
+/**
+ * Which conformance rule sits on which gate. RC-* are deliberately outside
+ * `ALL_RULE_DEFS` (they need `CodeFacts` from a repo checkout, which contracts has no
+ * access to), so `RULE_TO_PHASE` cannot carry them and this is the one legitimate
+ * local addition.
+ *
+ * Still not hand-picked: each RC rule inherits the gate of the PRESENCE rule it
+ * resolves — the Presence/Resolution split contracts documents (R-19/R-20/R-26 declare
+ * a binding, RC-01/02/03/04 check it actually resolves on disk). RC-05 (cross-module
+ * import drift) has no presence partner; it is module coupling, so it follows R-23.
+ */
+const RC_PRESENCE_PARTNER = {
+    'RC-01': 'R-20', // FUNC realRef → declared symbol
+    'RC-02': 'R-19', // testRef → runnable test case
+    'RC-03': 'R-26', // SCHEMA realRef → declared export
+    'RC-04': 'R-26', // SCHEMA realRef parsed at its interface
+    'RC-05': 'R-23', // cross-module import the graph does not document
 };
+/**
+ * Phase-Readiness gates (INCOSE technical reviews) → the rules each gate owns.
+ * DISJOINT + EXHAUSTIVE over the rule catalog; asserted by TEST-readiness-model
+ * against SE_DESCRIPTOR at runtime, never a hardcoded count.
+ *
+ * DERIVED from `RULE_TO_PHASE` (CR-GC-312). This used to be a hand-written literal —
+ * and contracts had already replaced it: CR-SM-226 removed `emergentPhase`/`phaseScore`
+ * as "a third, undocumented phase construct next to RULE_TO_DIMENSION and the (then
+ * still ad-hoc) phase-gate grouping", introducing `RULE_TO_PHASE` as the one
+ * replacement, "exported so no consumer reinvents it". That ad-hoc grouping was THIS
+ * object, and the replacement was never carried through here.
+ *
+ * The cost of leaving it: the literal and `RULE_TO_PHASE` had drifted apart on 21 of
+ * 33 shared rules — R-01 SRR vs TRR, R-08 TRR vs PDR, RD-01..03 CDR vs SRR, and so on.
+ * Two live gate assignments for the same rules, and readiness was scored against the
+ * frozen one. Deriving moves those rules onto the assignment contracts declares; gate
+ * scores change accordingly, which is the correction, not a side effect.
+ */
+export const PHASE_GATE_RULES = (() => {
+    const implOwned = new Set(IMPL_GATE_RULES);
+    const gates = { SRR: [], PDR: [], CDR: [], TRR: [] };
+    for (const [ruleId, gate] of Object.entries(RULE_TO_PHASE)) {
+        if (implOwned.has(ruleId))
+            continue; // the impl axis owns these
+        if (isCodingProfile(ruleId))
+            continue; // not part of the SE readiness model
+        gates[gate]?.push(ruleId);
+    }
+    for (const [rcId, partner] of Object.entries(RC_PRESENCE_PARTNER)) {
+        const gate = RULE_TO_PHASE[partner];
+        if (gate)
+            gates[gate].push(rcId);
+    }
+    for (const ids of Object.values(gates))
+        ids.sort();
+    return gates;
+})();
 /** Human labels for the phase gates. */
 export const PHASE_GATE_LABELS = {
     SRR: 'System Requirements Review',
@@ -86,12 +128,6 @@ export const IMPL_GATE_MILESTONES = {
     SVR: { ms: 'MS-3-mvp-readiness', label: 'System Verification Review' },
     FRR: { ms: 'MS-4-mvp2', label: 'Functional Readiness Review' },
 };
-/**
- * The 2 milestone-level V3_RULES the impl gates embody (MS-01 empty scope,
- * MS-02 dangling dependency). Together with the phase-gate rules these span
- * V3_RULES exhaustively — so the model covers it with nothing left over.
- */
-export const IMPL_GATE_RULES = ['MS-01', 'MS-02'];
 /**
  * Summary projection of a ReadinessReport (CR-GC-203 item 2): drops the heavy
  * per-element lists — `violations` and every gate's `blocking`/`open` — while

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sigloch/graphcode-client",
-  "version": "0.7.0",
+  "version": "0.8.0",
   "type": "module",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",
@@ -17,8 +17,8 @@
     "prepublishOnly": "npm run build && npm run test"
   },
   "dependencies": {
-    "@sigloch/contracts": "^3.0.0",
-    "@sigloch/graph-api-core": "^2.0.0"
+    "@sigloch/contracts": "^3.2.0",
+    "@sigloch/graph-api-core": "^2.1.0"
   },
   "license": "MIT",
   "description": "Read-side client for a running @sigloch/graphcode host — host-socket calls, dashboard panels, readiness projection and the markdown view catalog. Deliberately free of Kuzu and the MCP SDK so a viewer can depend on it without pulling an embedded graph database.",