@mrciphersmith/keryx 0.2.76 → 0.2.78

package/src/gdgraph/wiki-layer.ts

@@ -0,0 +1,213 @@
+// LWG wiki layer builder (flow 223, phase 0).
+//
+// Turns wiki pages into `WikiPageNode`s and their describe-sets into
+// `DescribesEdge`s, written to `storage/wiki-pages.jsonl` /
+// `storage/describes.jsonl`. Mirrors the tree-sitter symbol layer: an
+// additive pass AFTER the unchanged file-level build, into its own files.
+// `nodes.jsonl` and `edges.jsonl` are never touched (flow 223 AC13) —
+// see the "why a separate layer" note in `types.ts` for the regression that
+// forced this.
+//
+// Also writes `storage/build-manifest.json` (LWG-2): a `FileFingerprint` per
+// source file, for the incremental rebuild in phase 4. Free of extra I/O
+// because `buildGraph` already holds every file's content in memory.
+
+import { createHash } from "node:crypto";
+import { mkdir, stat, writeFile } from "node:fs/promises";
+import path from "node:path";
+import { collectPages } from "../wiki/collect";
+import { computeModuleKeyFiles } from "../wiki/collect";
+import { resolveDescribeSet } from "../wiki/describes";
+import type { DescribesEdge, FileFingerprint, GraphData, WikiLayer, WikiPageNode } from "./types";
+
+export const WIKI_PAGES_FILE = "wiki-pages.jsonl";
+export const DESCRIBES_FILE = "describes.jsonl";
+export const BUILD_MANIFEST_FILE = "build-manifest.json";
+
+function storageDir(projectRoot: string): string {
+  return path.join(projectRoot, ".metaproject", "data", "gdgraph", "storage");
+}
+
+/** Stable id for a page node. */
+export function wikiPageId(relativePath: string): string {
+  return `wiki:${relativePath}`;
+}
+
+export interface BuildWikiLayerInput {
+  projectRoot: string;
+  graph: GraphData;
+  /**
+   * The current module set, from `validModuleNames`. `undefined` means the
+   * graph has not been built — see {@link buildWikiLayer} for why that is not
+   * the same as an empty set.
+   */
+  validModules: Set<string> | undefined;
+  /** Page contents keyed by wiki-relative path. Injected for testability. */
+  pageContents: ReadonlyMap<string, string>;
+  pages: Array<{
+    relativePath: string;
+    title: string;
+    pageType: string;
+    status: string | null;
+    version: string | null;
+  }>;
+}
+
+/**
+ * Build the layer in memory. Pure apart from its inputs.
+ *
+ * **Graph-unavailable posture.** `validModules === undefined` means the graph
+ * has not been built yet, and the layer is skipped entirely — an empty layer
+ * is emitted, not a layer full of "describes nothing" pages. This inherits
+ * the rule `validModuleNames` states in its own doc comment: an empty module
+ * set would make every scoped item look orphaned, so callers must read
+ * "graph unavailable" as *nothing to say yet*, never as *everything is
+ * invalid* (flow 223 AC6).
+ */
+export function buildWikiLayer(input: BuildWikiLayerInput): WikiLayer {
+  if (input.validModules === undefined) {
+    return { pages: [], describes: [] };
+  }
+
+  // Explicitly `=== "file"`, not `!== "asset"`. The negative form is exactly
+  // the over-broad filter that made putting wiki nodes into `nodes.jsonl`
+  // dangerous in the first place (see `types.ts`); repeating it here would
+  // silently admit any future node kind as a describable target.
+  const knownPaths = new Set(
+    input.graph.nodes.filter((node) => node.kind === "file").map((node) => node.path),
+  );
+  const keyFilesIndex = computeModuleKeyFiles(input.graph);
+
+  const pages: WikiPageNode[] = [];
+  const describes: DescribesEdge[] = [];
+
+  for (const page of input.pages) {
+    const content = input.pageContents.get(page.relativePath) ?? "";
+    const resolved = resolveDescribeSet({
+      page: { relativePath: page.relativePath },
+      content,
+      knownPaths,
+      keyFilesIndex,
+    });
+
+    const id = wikiPageId(page.relativePath);
+    pages.push({
+      id,
+      path: page.relativePath,
+      title: page.title,
+      pageType: page.pageType,
+      status: page.status,
+      version: page.version,
+      undecidable: resolved.undecidable,
+    });
+
+    for (const entry of resolved.entries) {
+      for (const target of entry.resolvedPaths) {
+        describes.push({
+          id: `describes:${describes.length + 1}`,
+          from: id,
+          to: target,
+          pattern: entry.pattern,
+          origin: entry.origin,
+        });
+      }
+    }
+  }
+
+  pages.sort((a, b) => a.path.localeCompare(b.path));
+  describes.sort((a, b) => (a.from === b.from ? a.to.localeCompare(b.to) : a.from.localeCompare(b.from)));
+  return { pages, describes };
+}
+
+/** Content fingerprints for the incremental rebuild (LWG-2, phase 4 reader). */
+export function computeFingerprints(
+  fileRecords: ReadonlyArray<{ path: string; content: string }>,
+  mtimes: ReadonlyMap<string, number>,
+): FileFingerprint[] {
+  return fileRecords
+    .map((record) => ({
+      path: record.path,
+      contentHash: createHash("sha256").update(record.content).digest("hex"),
+      mtimeMs: mtimes.get(record.path) ?? 0,
+    }))
+    .sort((a, b) => a.path.localeCompare(b.path));
+}
+
+async function writeJsonl(filePath: string, rows: unknown[]): Promise<void> {
+  const body = rows.map((row) => JSON.stringify(row)).join("\n");
+  await writeFile(filePath, rows.length > 0 ? `${body}\n` : "", "utf8");
+}
+
+/**
+ * Collect pages, build the layer and persist it. Called from `buildGraph`
+ * behind a defensive dynamic import, exactly as the symbol layer is: any
+ * failure here degrades to "no wiki layer", never to a failed graph build.
+ */
+export async function enrichBuildWithWikiLayer(input: {
+  projectRoot: string;
+  graph: GraphData;
+  fileRecords: ReadonlyArray<{ path: string; content: string }>;
+  /** Injected in tests; defaults to the real `validModuleNames`. */
+  validModules?: Set<string> | undefined;
+  loadValidModules?: (projectRoot: string) => Promise<Set<string> | undefined>;
+}): Promise<WikiLayer> {
+  const dir = storageDir(input.projectRoot);
+  await mkdir(dir, { recursive: true });
+
+  const mtimes = new Map<string, number>();
+  for (const record of input.fileRecords) {
+    try {
+      const info = await stat(path.join(input.projectRoot, record.path));
+      mtimes.set(record.path, info.mtimeMs);
+    } catch {
+      // A file readable moments ago can be gone by now; a missing mtime is
+      // recorded as 0 rather than dropping the fingerprint, so the manifest
+      // keeps one row per file it hashed.
+    }
+  }
+  await writeFile(
+    path.join(dir, BUILD_MANIFEST_FILE),
+    `${JSON.stringify({ version: 1, files: computeFingerprints(input.fileRecords, mtimes) }, null, 2)}\n`,
+    "utf8",
+  );
+
+  const validModules =
+    input.validModules !== undefined
+      ? input.validModules
+      : await (input.loadValidModules ?? defaultLoadValidModules)(input.projectRoot);
+
+  const wikiPages = await collectPages(input.projectRoot);
+  const contents = new Map<string, string>();
+  for (const page of wikiPages) {
+    try {
+      contents.set(page.relativePath, await Bun.file(page.absolutePath).text());
+    } catch {
+      contents.set(page.relativePath, "");
+    }
+  }
+
+  const layer = buildWikiLayer({
+    projectRoot: input.projectRoot,
+    graph: input.graph,
+    validModules,
+    pageContents: contents,
+    pages: wikiPages.map((page) => ({
+      relativePath: page.relativePath,
+      title: page.title,
+      pageType: page.pageType,
+      status: page.status,
+      version: page.version,
+    })),
+  });
+
+  await writeJsonl(path.join(dir, WIKI_PAGES_FILE), layer.pages);
+  await writeJsonl(path.join(dir, DESCRIBES_FILE), layer.describes);
+  return layer;
+}
+
+async function defaultLoadValidModules(projectRoot: string): Promise<Set<string> | undefined> {
+  // Dynamic so `gdgraph` keeps no static dependency on `wiki/service`, which
+  // reads the graph itself — the same cycle-avoidance the symbol layer uses.
+  const { validModuleNames } = await import("../wiki/service");
+  return validModuleNames(projectRoot);
+}

package/src/gdskills/bundled/rules/core/api-contracts.mdc

@@ -126,11 +126,13 @@ POST/PUT/PATCH endpoints that create or modify state MUST support idempotency vi
 
 ---
 
-## Iron Laws
+## The three that are not negotiable
 
-**IRON LAW 1: NO breaking change may be deployed without a major version bump and a deprecation period.**
-**IRON LAW 2: The OpenAPI spec is updated BEFORE the implementation — not after as documentation.**
-**IRON LAW 3: Error responses MUST use the standard ApiError envelope — no raw exceptions, no ad-hoc shapes.**
+Of the rules above, three carry consequences that outlive the change: no breaking
+change ships without a major version bump and a deprecation period; the OpenAPI
+spec is updated before the implementation, not after it as documentation; and
+error responses use the standard `ApiError` envelope — never a raw exception or
+an ad-hoc shape.
 
 ---
 

package/src/gdskills/bundled/rules/core/model-selection.mdc

@@ -117,12 +117,11 @@ Two places, and they are not the same shape:
   resolved provider/model, `tier_resolution` and `model_discovery`. `--json`
   prints the block alone.
 
-That second bullet used to say the orchestrator "calls `decideDispatchModel`".
 An orchestrator is an agent following prose and **cannot call a TypeScript
-function**, so what actually happened was a model reading a table of signals and
-doing the arithmetic in its head — the exact mechanical work this programme moves
-out of skills and into the code that consumes them. `keryx review tier` is that
-code's entry point; `decideDispatchModel` is what it calls.
+function**: asked for a tier by hand it reads a table of signals and does the
+arithmetic in its head — the exact mechanical work this programme moves out of
+skills and into the code that consumes them. `keryx review tier` is that code's
+entry point; `decideDispatchModel` is what it calls.
 
 Nothing reads a recorded resolution back and checks it. These fields explain a
 finished run; they do not gate one.

package/src/gdskills/bundled/skills/orchestration/feature-analyzer/SKILL.codex.md

@@ -1,6 +1,6 @@
 ---
 name: feature-analyzer
-description: "Use when analyzing feature branch changes across repos, planning implementation, or understanding backend→frontend contracts. NEVER start without explicit user confirmation of source, target, and branch."
+description: "Use when analyzing feature branch changes across repos, planning implementation, or understanding backend→frontend contracts. Requires the source repository, target repository, and branch as confirmed input; the skill's PRE-STEP validates them before any analysis."
 triggers:
   - "Analyze branch"
   - "Analyze changes"
@@ -25,40 +25,6 @@ Proceed directly with your assigned task.
 
 # Feature Analyzer
 
-## ⚠️ MANDATORY: DO NOT PROCEED WITHOUT CONTEXT
-
-**CRITICAL RULE: You CANNOT start analysis until user explicitly provides:**
-1. ✅ Source repository (local path)
-2. ✅ Target repository (local path)
-3. ✅ Branch to analyze
-4. ✅ Confirmation of analysis scope
-
-**DO NOT assume defaults. DO NOT use current directory. DO NOT proceed without asking.**
-
-**If user says:** "Analyze everything related to variables in pipelines"
-
-**You MUST respond:**
-```
-I'll help you analyze variables in pipelines. First, I need to clarify the context:
-
-**SOURCE Repository** (where the changes exist):
-- Local path: [user must provide, e.g., /Users/.../<PROJECT>]
-- GitHub repo: [owner/repo]
-- Branch to analyze: [branch-name]
-
-**TARGET Repository** (where implementation will happen):
-- Local path: [user must provide, e.g., /Users/.../<PROJECT>]
-- GitHub repo: [owner/repo]
-- Current branch: [branch-name]
-
-**FOCUS** (from your request): "variables in pipelines"
-- Keywords: variable, pipeline, param
-
-Once you provide these details, I'll begin the focused analysis.
-```
-
-**If user doesn't provide all required info → STOP and ask again.**
-
 ---
 
 ## Purpose
@@ -267,7 +233,7 @@ git diff "${BASE_SHA}..HEAD"
 
 ### Priority Levels
 
-**P0 — MUST ANALYZE (Critical)**:
+**P0 — must analyze**:
 - API contracts: DTOs, interfaces, type definitions
 - Public API endpoints (controllers, routes)
 - Database schema changes, auth changes, config changes
@@ -293,7 +259,7 @@ When focus specified: boost files matching focus keywords to P0; select ALL focu
 
 ## Step 5: Deep Dive Protocol
 
-**You CANNOT make conclusions from git diff alone. You MUST:**
+**A git diff alone does not support a conclusion. Also do this:**
 
 1. **Read selected files**:
    - Small/medium files: read completely
@@ -328,7 +294,7 @@ Before finalizing, consider running:
 
 ---
 
-## Step 9: Intermediate Review (CRITICAL)
+## Step 9: Intermediate Review
 
 After completing analysis, **show user** before generating full report:
 

package/src/gdskills/bundled/skills/orchestration/feature-analyzer/SKILL.cursor.md

@@ -1,6 +1,6 @@
 ---
 name: feature-analyzer
-description: "Use when analyzing feature branch changes across repos, planning implementation, or understanding backend→frontend contracts. NEVER start without explicit user confirmation of source, target, and branch."
+description: "Use when analyzing feature branch changes across repos, planning implementation, or understanding backend→frontend contracts. Requires the source repository, target repository, and branch as confirmed input; the skill's PRE-STEP validates them before any analysis."
 triggers:
   - "Analyze branch"
   - "Analyze changes"
@@ -25,40 +25,6 @@ Proceed directly with your assigned task.
 
 # Feature Analyzer
 
-## ⚠️ MANDATORY: DO NOT PROCEED WITHOUT CONTEXT
-
-**CRITICAL RULE: You CANNOT start analysis until user explicitly provides:**
-1. ✅ Source repository (local path)
-2. ✅ Target repository (local path)
-3. ✅ Branch to analyze
-4. ✅ Confirmation of analysis scope
-
-**DO NOT assume defaults. DO NOT use current directory. DO NOT proceed without asking.**
-
-**If user says:** "Analyze everything related to variables in pipelines"
-
-**You MUST respond:**
-```
-I'll help you analyze variables in pipelines. First, I need to clarify the context:
-
-**SOURCE Repository** (where the changes exist):
-- Local path: [user must provide, e.g., /Users/.../<PROJECT>]
-- GitHub repo: [owner/repo]
-- Branch to analyze: [branch-name]
-
-**TARGET Repository** (where implementation will happen):
-- Local path: [user must provide, e.g., /Users/.../<PROJECT>]
-- GitHub repo: [owner/repo]
-- Current branch: [branch-name]
-
-**FOCUS** (from your request): "variables in pipelines"
-- Keywords: variable, pipeline, param
-
-Once you provide these details, I'll begin the focused analysis.
-```
-
-**If user doesn't provide all required info → STOP and ask again.**
-
 ---
 
 ## Purpose
@@ -267,7 +233,7 @@ git diff "${BASE_SHA}..HEAD"
 
 ### Priority Levels
 
-**P0 — MUST ANALYZE (Critical)**:
+**P0 — must analyze**:
 - API contracts: DTOs, interfaces, type definitions
 - Public API endpoints (controllers, routes)
 - Database schema changes, auth changes, config changes
@@ -293,7 +259,7 @@ When focus specified: boost files matching focus keywords to P0; select ALL focu
 
 ## Step 5: Deep Dive Protocol
 
-**You CANNOT make conclusions from git diff alone. You MUST:**
+**A git diff alone does not support a conclusion. Also do this:**
 
 1. **Read selected files**:
    - Small/medium files: read completely
@@ -328,7 +294,7 @@ Before finalizing, consider running:
 
 ---
 
-## Step 9: Intermediate Review (CRITICAL)
+## Step 9: Intermediate Review
 
 After completing analysis, **show user** before generating full report:
 

package/src/gdskills/bundled/skills/orchestration/feature-analyzer/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: feature-analyzer
-description: "Use when analyzing feature branch changes across repos, planning implementation, or understanding backend→frontend contracts. NEVER start without explicit user confirmation of source, target, and branch."
+description: "Use when analyzing feature branch changes across repos, planning implementation, or understanding backend→frontend contracts. Requires the source repository, target repository, and branch as confirmed input; the skill's PRE-STEP validates them before any analysis."
 triggers:
   - "Analyze branch"
   - "Analyze changes"
@@ -25,40 +25,6 @@ Proceed directly with your assigned task.
 
 # Feature Analyzer
 
-## ⚠️ MANDATORY: DO NOT PROCEED WITHOUT CONTEXT
-
-**CRITICAL RULE: You CANNOT start analysis until user explicitly provides:**
-1. ✅ Source repository (local path)
-2. ✅ Target repository (local path)
-3. ✅ Branch to analyze
-4. ✅ Confirmation of analysis scope
-
-**DO NOT assume defaults. DO NOT use current directory. DO NOT proceed without asking.**
-
-**If user says:** "Analyze everything related to variables in pipelines"
-
-**You MUST respond:**
-```
-I'll help you analyze variables in pipelines. First, I need to clarify the context:
-
-**SOURCE Repository** (where the changes exist):
-- Local path: [user must provide, e.g., /Users/.../<PROJECT>]
-- GitHub repo: [owner/repo]
-- Branch to analyze: [branch-name]
-
-**TARGET Repository** (where implementation will happen):
-- Local path: [user must provide, e.g., /Users/.../<PROJECT>]
-- GitHub repo: [owner/repo]
-- Current branch: [branch-name]
-
-**FOCUS** (from your request): "variables in pipelines"
-- Keywords: variable, pipeline, param
-
-Once you provide these details, I'll begin the focused analysis.
-```
-
-**If user doesn't provide all required info → STOP and ask again.**
-
 ---
 
 ## Purpose
@@ -267,7 +233,7 @@ git diff "${BASE_SHA}..HEAD"
 
 ### Priority Levels
 
-**P0 — MUST ANALYZE (Critical)**:
+**P0 — must analyze**:
 - API contracts: DTOs, interfaces, type definitions
 - Public API endpoints (controllers, routes)
 - Database schema changes, auth changes, config changes
@@ -293,7 +259,7 @@ When focus specified: boost files matching focus keywords to P0; select ALL focu
 
 ## Step 5: Deep Dive Protocol
 
-**You CANNOT make conclusions from git diff alone. You MUST:**
+**A git diff alone does not support a conclusion. Also do this:**
 
 1. **Read selected files**:
    - Small/medium files: read completely
@@ -328,7 +294,7 @@ Before finalizing, consider running:
 
 ---
 
-## Step 9: Intermediate Review (CRITICAL)
+## Step 9: Intermediate Review
 
 After completing analysis, **show user** before generating full report:
 

package/src/gdskills/bundled/skills/orchestration/feature-analyzer/SKILL.opencode.md

@@ -1,6 +1,6 @@
 ---
 name: feature-analyzer
-description: "Use when analyzing feature branch changes across repos, planning implementation, or understanding backend→frontend contracts. NEVER start without explicit user confirmation of source, target, and branch."
+description: "Use when analyzing feature branch changes across repos, planning implementation, or understanding backend→frontend contracts. Requires the source repository, target repository, and branch as confirmed input; the skill's PRE-STEP validates them before any analysis."
 triggers:
   - "Analyze branch"
   - "Analyze changes"
@@ -25,40 +25,6 @@ Proceed directly with your assigned task.
 
 # Feature Analyzer
 
-## ⚠️ MANDATORY: DO NOT PROCEED WITHOUT CONTEXT
-
-**CRITICAL RULE: You CANNOT start analysis until user explicitly provides:**
-1. ✅ Source repository (local path)
-2. ✅ Target repository (local path)
-3. ✅ Branch to analyze
-4. ✅ Confirmation of analysis scope
-
-**DO NOT assume defaults. DO NOT use current directory. DO NOT proceed without asking.**
-
-**If user says:** "Analyze everything related to variables in pipelines"
-
-**You MUST respond:**
-```
-I'll help you analyze variables in pipelines. First, I need to clarify the context:
-
-**SOURCE Repository** (where the changes exist):
-- Local path: [user must provide, e.g., /Users/.../<PROJECT>]
-- GitHub repo: [owner/repo]
-- Branch to analyze: [branch-name]
-
-**TARGET Repository** (where implementation will happen):
-- Local path: [user must provide, e.g., /Users/.../<PROJECT>]
-- GitHub repo: [owner/repo]
-- Current branch: [branch-name]
-
-**FOCUS** (from your request): "variables in pipelines"
-- Keywords: variable, pipeline, param
-
-Once you provide these details, I'll begin the focused analysis.
-```
-
-**If user doesn't provide all required info → STOP and ask again.**
-
 ---
 
 ## Purpose
@@ -267,7 +233,7 @@ git diff "${BASE_SHA}..HEAD"
 
 ### Priority Levels
 
-**P0 — MUST ANALYZE (Critical)**:
+**P0 — must analyze**:
 - API contracts: DTOs, interfaces, type definitions
 - Public API endpoints (controllers, routes)
 - Database schema changes, auth changes, config changes
@@ -293,7 +259,7 @@ When focus specified: boost files matching focus keywords to P0; select ALL focu
 
 ## Step 5: Deep Dive Protocol
 
-**You CANNOT make conclusions from git diff alone. You MUST:**
+**A git diff alone does not support a conclusion. Also do this:**
 
 1. **Read selected files**:
    - Small/medium files: read completely
@@ -328,7 +294,7 @@ Before finalizing, consider running:
 
 ---
 
-## Step 9: Intermediate Review (CRITICAL)
+## Step 9: Intermediate Review
 
 After completing analysis, **show user** before generating full report:
 

package/src/gdskills/bundled/skills/orchestration/feature-analyzer/SKILL.zed.md

@@ -1,6 +1,6 @@
 ---
 name: feature-analyzer
-description: "Use when analyzing feature branch changes across repos, planning implementation, or understanding backend→frontend contracts. NEVER start without explicit user confirmation of source, target, and branch."
+description: "Use when analyzing feature branch changes across repos, planning implementation, or understanding backend→frontend contracts. Requires the source repository, target repository, and branch as confirmed input; the skill's PRE-STEP validates them before any analysis."
 triggers:
   - "Analyze branch"
   - "Analyze changes"
@@ -25,40 +25,6 @@ Proceed directly with your assigned task.
 
 # Feature Analyzer
 
-## ⚠️ MANDATORY: DO NOT PROCEED WITHOUT CONTEXT
-
-**CRITICAL RULE: You CANNOT start analysis until user explicitly provides:**
-1. ✅ Source repository (local path)
-2. ✅ Target repository (local path)
-3. ✅ Branch to analyze
-4. ✅ Confirmation of analysis scope
-
-**DO NOT assume defaults. DO NOT use current directory. DO NOT proceed without asking.**
-
-**If user says:** "Analyze everything related to variables in pipelines"
-
-**You MUST respond:**
-```
-I'll help you analyze variables in pipelines. First, I need to clarify the context:
-
-**SOURCE Repository** (where the changes exist):
-- Local path: [user must provide, e.g., /Users/.../<PROJECT>]
-- GitHub repo: [owner/repo]
-- Branch to analyze: [branch-name]
-
-**TARGET Repository** (where implementation will happen):
-- Local path: [user must provide, e.g., /Users/.../<PROJECT>]
-- GitHub repo: [owner/repo]
-- Current branch: [branch-name]
-
-**FOCUS** (from your request): "variables in pipelines"
-- Keywords: variable, pipeline, param
-
-Once you provide these details, I'll begin the focused analysis.
-```
-
-**If user doesn't provide all required info → STOP and ask again.**
-
 ---
 
 ## Purpose
@@ -267,7 +233,7 @@ git diff "${BASE_SHA}..HEAD"
 
 ### Priority Levels
 
-**P0 — MUST ANALYZE (Critical)**:
+**P0 — must analyze**:
 - API contracts: DTOs, interfaces, type definitions
 - Public API endpoints (controllers, routes)
 - Database schema changes, auth changes, config changes
@@ -293,7 +259,7 @@ When focus specified: boost files matching focus keywords to P0; select ALL focu
 
 ## Step 5: Deep Dive Protocol
 
-**You CANNOT make conclusions from git diff alone. You MUST:**
+**A git diff alone does not support a conclusion. Also do this:**
 
 1. **Read selected files**:
    - Small/medium files: read completely
@@ -328,7 +294,7 @@ Before finalizing, consider running:
 
 ---
 
-## Step 9: Intermediate Review (CRITICAL)
+## Step 9: Intermediate Review
 
 After completing analysis, **show user** before generating full report:
 

package/src/gdskills/bundled/skills/orchestration/feature-dev/SKILL.codex.md

@@ -160,6 +160,4 @@ At each phase transition, report progress:
 | "This phase isn't needed for such a straightforward feature" | Every skipped phase is a deferred bug report |
 | "I understand the requirements, confirmation is just a formality" | The confirmation step exists to catch the gap between what you understood and what was meant |
 
-**IRON LAW 1: NEVER START IMPLEMENTING BEFORE THE SPEC IS WRITTEN AND CONFIRMED.**
-**IRON LAW 2: NEVER WRITE IMPLEMENTATION CODE BEFORE TESTS-CREATOR HAS GENERATED FAILING STUBS.**
-**IRON LAW 3: NEVER DELIVER WITHOUT A PASSING CODE-VERIFIER GATE AND A CHANGE REPORT.**
+**The three constraints that hold the pipeline together:** no implementation before the spec is written and confirmed; no implementation code before tests-creator has generated failing stubs; no delivery without a passing code-verifier gate and a Change Report.

package/src/gdskills/bundled/skills/orchestration/feature-dev/SKILL.cursor.md

@@ -160,6 +160,4 @@ At each phase transition, report progress:
 | "This phase isn't needed for such a straightforward feature" | Every skipped phase is a deferred bug report |
 | "I understand the requirements, confirmation is just a formality" | The confirmation step exists to catch the gap between what you understood and what was meant |
 
-**IRON LAW 1: NEVER START IMPLEMENTING BEFORE THE SPEC IS WRITTEN AND CONFIRMED.**
-**IRON LAW 2: NEVER WRITE IMPLEMENTATION CODE BEFORE TESTS-CREATOR HAS GENERATED FAILING STUBS.**
-**IRON LAW 3: NEVER DELIVER WITHOUT A PASSING CODE-VERIFIER GATE AND A CHANGE REPORT.**
+**The three constraints that hold the pipeline together:** no implementation before the spec is written and confirmed; no implementation code before tests-creator has generated failing stubs; no delivery without a passing code-verifier gate and a Change Report.

package/src/gdskills/bundled/skills/orchestration/feature-dev/SKILL.md

@@ -160,6 +160,4 @@ At each phase transition, report progress:
 | "This phase isn't needed for such a straightforward feature" | Every skipped phase is a deferred bug report |
 | "I understand the requirements, confirmation is just a formality" | The confirmation step exists to catch the gap between what you understood and what was meant |
 
-**IRON LAW 1: NEVER START IMPLEMENTING BEFORE THE SPEC IS WRITTEN AND CONFIRMED.**
-**IRON LAW 2: NEVER WRITE IMPLEMENTATION CODE BEFORE TESTS-CREATOR HAS GENERATED FAILING STUBS.**
-**IRON LAW 3: NEVER DELIVER WITHOUT A PASSING CODE-VERIFIER GATE AND A CHANGE REPORT.**
+**The three constraints that hold the pipeline together:** no implementation before the spec is written and confirmed; no implementation code before tests-creator has generated failing stubs; no delivery without a passing code-verifier gate and a Change Report.