@mrciphersmith/keryx 0.2.83 → 0.2.88

package/src/gdskills/bundled/skills/orchestration/code-verifier/SKILL.cursor.md

@@ -68,7 +68,7 @@ Auto-detect the project stack and available verification tools.
 ```bash
 cd <codebase_path>
 
-if   [ -f bun.lockb ];         then PM=bun;    RUNNER="bun run"
+if   [ -f bun.lock ] || [ -f bun.lockb ]; then PM=bun;    RUNNER="bun run"
 elif [ -f pnpm-lock.yaml ];    then PM=pnpm;   RUNNER="pnpm run"
 elif [ -f yarn.lock ];         then PM=yarn;   RUNNER="yarn"
 elif [ -f package-lock.json ]; then PM=npm;    RUNNER="npm run"

package/src/gdskills/bundled/skills/orchestration/code-verifier/SKILL.md

@@ -68,7 +68,7 @@ Auto-detect the project stack and available verification tools.
 ```bash
 cd <codebase_path>
 
-if   [ -f bun.lockb ];         then PM=bun;    RUNNER="bun run"
+if   [ -f bun.lock ] || [ -f bun.lockb ]; then PM=bun;    RUNNER="bun run"
 elif [ -f pnpm-lock.yaml ];    then PM=pnpm;   RUNNER="pnpm run"
 elif [ -f yarn.lock ];         then PM=yarn;   RUNNER="yarn"
 elif [ -f package-lock.json ]; then PM=npm;    RUNNER="npm run"

package/src/gdskills/bundled/skills/orchestration/code-verifier/SKILL.opencode.md

@@ -68,7 +68,7 @@ Auto-detect the project stack and available verification tools.
 ```bash
 cd <codebase_path>
 
-if   [ -f bun.lockb ];         then PM=bun;    RUNNER="bun run"
+if   [ -f bun.lock ] || [ -f bun.lockb ]; then PM=bun;    RUNNER="bun run"
 elif [ -f pnpm-lock.yaml ];    then PM=pnpm;   RUNNER="pnpm run"
 elif [ -f yarn.lock ];         then PM=yarn;   RUNNER="yarn"
 elif [ -f package-lock.json ]; then PM=npm;    RUNNER="npm run"

package/src/gdskills/bundled/skills/orchestration/code-verifier/SKILL.zed.md

@@ -68,7 +68,7 @@ Auto-detect the project stack and available verification tools.
 ```bash
 cd <codebase_path>
 
-if   [ -f bun.lockb ];         then PM=bun;    RUNNER="bun run"
+if   [ -f bun.lock ] || [ -f bun.lockb ]; then PM=bun;    RUNNER="bun run"
 elif [ -f pnpm-lock.yaml ];    then PM=pnpm;   RUNNER="pnpm run"
 elif [ -f yarn.lock ];         then PM=yarn;   RUNNER="yarn"
 elif [ -f package-lock.json ]; then PM=npm;    RUNNER="npm run"

package/src/gdskills/bundled/skills/orchestration/flow-orchestrator/SKILL.md

@@ -119,19 +119,47 @@ it already tried. The flow package does.
       attempts from your own context** — a resumed session's context starts at
       zero while the real count does not, and a loop bound computed from zero
       is not a bound.
-   3. Resume at the first task whose `status` is not `done`, respecting
-      `dependsOn` order.
-   4. Before dispatching a worker for that task, record the attempt:
+   3. Ask the record which task is next, rather than deriving it:
+
+      ```bash
+      keryx flow next <id> --json
+      ```
+
+      This is the first task whose `status` is not `done` and whose declared
+      `dependsOn` are all `done` — the ordering computed from the package
+      instead of re-derived by you from prose.
+
+   4. **Read the `resume` field before dispatching anything.** It has three
+      answers and they are not interchangeable:
+
+      - `never-started` — nothing has been tried. Dispatch normally.
+      - `ended` — a previous attempt reported how it finished. This is a retry;
+        the budget in step 6 applies.
+      - `unresolved` — an attempt was opened and **no end was ever recorded**.
+        Whether its work already landed is UNKNOWN. Do NOT treat this as
+        `never-started`. Inspect the working tree and the task's
+        `evidenceRefs` first, decide whether the work is there, and only then
+        either close the stale attempt
+        (`keryx flow task attempt <id> <Tn> --outcome failed --detail "<what you found>"`)
+        or close the task (`keryx flow task done <id> <Tn>`). Re-dispatching
+        over an unresolved attempt is how the same work gets done twice.
+
+      `keryx flow next` also lists every OTHER not-done task carrying an
+      unresolved attempt, under `unresolved`. Those are parallel dispatches that
+      never reported back; resolve them the same way before assuming the flow is
+      idle.
+
+   5. Before dispatching a worker for that task, record the attempt:
 
       ```bash
       keryx flow task attempt <id> <Tn> --outcome started --detail "resumed after session restart"
       ```
 
-   5. Apply the Phase 4 attempt budget against the **persisted** count. If
+   6. Apply the Phase 4 attempt budget against the **persisted** count. If
       `attempts.count` for the task has already reached **three**, do not
       re-dispatch the same approach: go to the re-planning step (Phase 4, PR
       review/fix loop, step 4) and record the decision in `journal.md`.
-   6. Run the repetition check before spending an attempt, whatever the count
+   7. Run the repetition check before spending an attempt, whatever the count
       says:
 
       ```bash
@@ -142,7 +170,7 @@ it already tried. The flow package does.
       rounds produced identical output. Go straight to the re-planning step.
       Do not spend the remaining attempts on the same approach because the
       budget has some left — that is the failure this check exists to catch.
-   7. If the flow is `blocked`, read the blocking reason from `journal.md`,
+   8. If the flow is `blocked`, read the blocking reason from `journal.md`,
       resolve or escalate it, then `keryx flow unblock <id>`.
 4. If the user wants a new flow, continue at 0.1.
 
@@ -170,13 +198,15 @@ keryx flow init --issue <url>
 or:
 
 ```bash
-keryx flow init --title "<short formalized problem>"
+keryx flow init --title "<short formalized problem>" --base "<branch the work must land on>"
 ```
 
 5. Run `keryx flow status <id>` and read the flow package.
-6. Record the git base branch from which the flow branch was created in
-   `context.md` and `journal.md`; the PR must later be merged into this exact
-   branch.
+6. `--base` records the branch in the flow record itself, where the completion
+   gate reads it. Note it in `context.md` and `journal.md` as well if it helps a
+   reader, but prose is not what the gate checks: before this flag the base
+   survived only as something an agent had written down, which is detectable at
+   dispatch and undetectable at completion.
 
 ## Phase 1: Initialize The Flow Package
 
@@ -414,9 +444,16 @@ How should this flow end?
 
 3. Follow the selected outcome:
 
-- **A - Create PR and merge:** create or confirm a PR in the author's name.
-  Preserve the base branch recorded during initialization. Do not mark the
-  flow implemented or complete before the PR is merged into that branch.
+- **A - Create PR and merge:** create or confirm a PR in the author's name,
+  opened against the base recorded at initialization. Do not mark the flow
+  implemented or complete before the PR is merged into that branch.
+
+  `keryx flow complete` now checks this rather than asking you to confirm it by
+  eye: its `base-branch` condition compares where the merge landed against the
+  base in the record, and refuses when they differ. It reports three states,
+  and only one of them is a pass — a flow that recorded no base gets
+  `not recorded`, which is not a pass either. So the useful thing to do here is
+  make sure the base WAS recorded, not to re-verify the merge yourself.
 
 ### A dispatched run answers the question from its input
 

package/src/gdskills/bundled/skills/orchestration/job-orchestrator/SKILL.codex.md

@@ -686,7 +686,7 @@ git -C <project_dir> worktree add ../<branch-slug> -b feature/<branch-slug> orig
 # Result branch:   feature/pipeline-validation
 
 # Auto-detect package manager and install dependencies
-if [ -f <worktree_path>/bun.lockb ]; then
+if [ -f <worktree_path>/bun.lock ] || [ -f <worktree_path>/bun.lockb ]; then
   PM="bun"; RUNNER="bun run"; bun install --cwd <worktree_path>
 elif [ -f <worktree_path>/pnpm-lock.yaml ]; then
   PM="pnpm"; RUNNER="pnpm run"; pnpm install --prefix <worktree_path>

package/src/gdskills/bundled/skills/orchestration/job-orchestrator/SKILL.cursor.md

@@ -686,7 +686,7 @@ git -C <project_dir> worktree add ../<branch-slug> -b feature/<branch-slug> orig
 # Result branch:   feature/pipeline-validation
 
 # Auto-detect package manager and install dependencies
-if [ -f <worktree_path>/bun.lockb ]; then
+if [ -f <worktree_path>/bun.lock ] || [ -f <worktree_path>/bun.lockb ]; then
   PM="bun"; RUNNER="bun run"; bun install --cwd <worktree_path>
 elif [ -f <worktree_path>/pnpm-lock.yaml ]; then
   PM="pnpm"; RUNNER="pnpm run"; pnpm install --prefix <worktree_path>

package/src/gdskills/bundled/skills/orchestration/job-orchestrator/SKILL.md

@@ -686,7 +686,7 @@ git -C <project_dir> worktree add ../<branch-slug> -b feature/<branch-slug> orig
 # Result branch:   feature/pipeline-validation
 
 # Auto-detect package manager and install dependencies
-if [ -f <worktree_path>/bun.lockb ]; then
+if [ -f <worktree_path>/bun.lock ] || [ -f <worktree_path>/bun.lockb ]; then
   PM="bun"; RUNNER="bun run"; bun install --cwd <worktree_path>
 elif [ -f <worktree_path>/pnpm-lock.yaml ]; then
   PM="pnpm"; RUNNER="pnpm run"; pnpm install --prefix <worktree_path>

package/src/gdskills/bundled/skills/orchestration/job-orchestrator/SKILL.opencode.md

@@ -686,7 +686,7 @@ git -C <project_dir> worktree add ../<branch-slug> -b feature/<branch-slug> orig
 # Result branch:   feature/pipeline-validation
 
 # Auto-detect package manager and install dependencies
-if [ -f <worktree_path>/bun.lockb ]; then
+if [ -f <worktree_path>/bun.lock ] || [ -f <worktree_path>/bun.lockb ]; then
   PM="bun"; RUNNER="bun run"; bun install --cwd <worktree_path>
 elif [ -f <worktree_path>/pnpm-lock.yaml ]; then
   PM="pnpm"; RUNNER="pnpm run"; pnpm install --prefix <worktree_path>

package/src/gdskills/bundled/skills/orchestration/job-orchestrator/SKILL.zed.md

@@ -686,7 +686,7 @@ git -C <project_dir> worktree add ../<branch-slug> -b feature/<branch-slug> orig
 # Result branch:   feature/pipeline-validation
 
 # Auto-detect package manager and install dependencies
-if [ -f <worktree_path>/bun.lockb ]; then
+if [ -f <worktree_path>/bun.lock ] || [ -f <worktree_path>/bun.lockb ]; then
   PM="bun"; RUNNER="bun run"; bun install --cwd <worktree_path>
 elif [ -f <worktree_path>/pnpm-lock.yaml ]; then
   PM="pnpm"; RUNNER="pnpm run"; pnpm install --prefix <worktree_path>

package/src/gdskills/bundled/skills/quality/security-audit/SKILL.codex.md

@@ -8,10 +8,11 @@ triggers:
   - "Security scan"
   - "Check for CVEs"
   - "npm audit"
+  - "bun audit"
   - "Dependency vulnerabilities"
 metadata:
   author: "MrCipherSmith"
-  version: "1.0.0"
+  version: "1.1.0"
   category: "quality"
   compatible_harnesses: "cursor,codex,zed,opencode,claude"
 license: "MIT"
@@ -35,22 +36,63 @@ Comprehensive security audit covering dependency vulnerabilities, secrets in cod
 ## Steps
 
 ### Step 1 — Dependency vulnerabilities
-Auto-detect: `bun.lockb` → `bun audit` | `package-lock.json` → `npm audit --json` | `yarn.lock` → `yarn audit`
+
+Detect from the **lockfile**, not from an installed binary. The lockfile is what
+an audit reads; `bun` being on PATH says nothing about whether `bun audit` has a
+lockfile to resolve.
+
+| Lockfile present (repo root) | Command |
+|---|---|
+| `bun.lock` **or** `bun.lockb` | `bun audit --json` |
+| `package-lock.json` **or** `npm-shrinkwrap.json` | `npm audit --json` |
+| `pnpm-lock.yaml` | `pnpm audit --json` |
+| `yarn.lock` | `yarn npm audit --json` (Yarn 2+), else `yarn audit --json` (Yarn 1) |
+
+Check **both** Bun names — `bun.lock` and `bun.lockb`. Bun 1.2 replaced the
+binary `bun.lockb` with the text `bun.lock`, so a project on current Bun has
+only `bun.lock`, and a `bun.lockb`-only check (`bun.lock` unmatched) finds
+nothing there.
+
+**If no row matches, the dependency audit DID NOT RUN.** Say so:
+
+```
+dependency-audit: NOT RUN — no recognised lockfile in <path>
+```
+
+and carry `not measured` — never `0` — into every severity total in the report.
+Do not fall through to another package manager's audit as a guess.
+
+**A command that could not produce results is also NOT RUN.** `npm audit --json`
+without a lockfile exits 1 and prints roughly 240 bytes of
+`{"error":{"code":"ENOLOCK",...}}` — an object with **no `vulnerabilities` key
+at all**. Grouping that by severity yields zero for critical, high, moderate and
+low, which is indistinguishable from a clean project. So before grouping, check
+that the payload actually carries vulnerability data (`vulnerabilities` /
+`advisories` for npm, the per-package arrays for bun). If it does not, the
+outcome is NOT RUN with the tool's own error, not a clean result.
+
+Only once a command has produced real vulnerability data:
 
 Group by severity: **critical → high → moderate → low**
 
 ### Step 2 — Outdated packages
-Run `bun outdated` or `npm outdated`. Flag packages more than 2 major versions behind.
+Run `outdated` for the package manager Step 1 detected (`bun outdated`,
+`npm outdated`, `pnpm outdated`, `yarn outdated`). Flag packages more than 2
+major versions behind. If Step 1 found no package manager, this step is
+`NOT RUN` for the same reason.
 
 ### Step 3 — Secrets scan
 - Check git history for `.env`, `.key`, `.pem` files
 - Grep source for hardcoded passwords/API keys/secrets (excluding node_modules)
 
 ### Step 4 — Docker image scan
-If Dockerfile present and Docker available: `docker scout cves`
+If a Dockerfile is present and Docker is available: `docker scout cves`.
+Otherwise report `container-scan: NOT RUN — <no Dockerfile | docker unavailable>`.
+"No Dockerfile" and "scanned, nothing found" are different results.
 
 ### Report
-- Total by severity
+- Per step: `RAN` or `NOT RUN — <reason>`. A step that did not run has no totals.
+- Total by severity, for the steps that ran
 - Top 3 critical/high with CVE
 - Recommended immediate actions
 - Packages safe to ignore (dev-only, not reachable in prod)
@@ -59,3 +101,8 @@ If Dockerfile present and Docker available: `docker scout cves`
 
 - Distinguish prod vs dev-only vulnerabilities
 - Never suggest `npm audit fix --force` without explaining what it changes
+- **A check that did not run is not a check that passed.** Never report a
+  severity total — least of all zero — for a step whose command was not
+  selected, could not run, or returned no vulnerability data. Report `not
+  measured` and name the reason. In a security report, silence read as "clean"
+  is the most expensive defect available.

package/src/gdskills/bundled/skills/quality/security-audit/SKILL.cursor.md

@@ -8,10 +8,11 @@ triggers:
   - "Security scan"
   - "Check for CVEs"
   - "npm audit"
+  - "bun audit"
   - "Dependency vulnerabilities"
 metadata:
   author: "MrCipherSmith"
-  version: "1.0.0"
+  version: "1.1.0"
   category: "quality"
   compatible_harnesses: "cursor,codex,zed,opencode,claude"
 license: "MIT"
@@ -35,22 +36,63 @@ Comprehensive security audit covering dependency vulnerabilities, secrets in cod
 ## Steps
 
 ### Step 1 — Dependency vulnerabilities
-Auto-detect: `bun.lockb` → `bun audit` | `package-lock.json` → `npm audit --json` | `yarn.lock` → `yarn audit`
+
+Detect from the **lockfile**, not from an installed binary. The lockfile is what
+an audit reads; `bun` being on PATH says nothing about whether `bun audit` has a
+lockfile to resolve.
+
+| Lockfile present (repo root) | Command |
+|---|---|
+| `bun.lock` **or** `bun.lockb` | `bun audit --json` |
+| `package-lock.json` **or** `npm-shrinkwrap.json` | `npm audit --json` |
+| `pnpm-lock.yaml` | `pnpm audit --json` |
+| `yarn.lock` | `yarn npm audit --json` (Yarn 2+), else `yarn audit --json` (Yarn 1) |
+
+Check **both** Bun names — `bun.lock` and `bun.lockb`. Bun 1.2 replaced the
+binary `bun.lockb` with the text `bun.lock`, so a project on current Bun has
+only `bun.lock`, and a `bun.lockb`-only check (`bun.lock` unmatched) finds
+nothing there.
+
+**If no row matches, the dependency audit DID NOT RUN.** Say so:
+
+```
+dependency-audit: NOT RUN — no recognised lockfile in <path>
+```
+
+and carry `not measured` — never `0` — into every severity total in the report.
+Do not fall through to another package manager's audit as a guess.
+
+**A command that could not produce results is also NOT RUN.** `npm audit --json`
+without a lockfile exits 1 and prints roughly 240 bytes of
+`{"error":{"code":"ENOLOCK",...}}` — an object with **no `vulnerabilities` key
+at all**. Grouping that by severity yields zero for critical, high, moderate and
+low, which is indistinguishable from a clean project. So before grouping, check
+that the payload actually carries vulnerability data (`vulnerabilities` /
+`advisories` for npm, the per-package arrays for bun). If it does not, the
+outcome is NOT RUN with the tool's own error, not a clean result.
+
+Only once a command has produced real vulnerability data:
 
 Group by severity: **critical → high → moderate → low**
 
 ### Step 2 — Outdated packages
-Run `bun outdated` or `npm outdated`. Flag packages more than 2 major versions behind.
+Run `outdated` for the package manager Step 1 detected (`bun outdated`,
+`npm outdated`, `pnpm outdated`, `yarn outdated`). Flag packages more than 2
+major versions behind. If Step 1 found no package manager, this step is
+`NOT RUN` for the same reason.
 
 ### Step 3 — Secrets scan
 - Check git history for `.env`, `.key`, `.pem` files
 - Grep source for hardcoded passwords/API keys/secrets (excluding node_modules)
 
 ### Step 4 — Docker image scan
-If Dockerfile present and Docker available: `docker scout cves`
+If a Dockerfile is present and Docker is available: `docker scout cves`.
+Otherwise report `container-scan: NOT RUN — <no Dockerfile | docker unavailable>`.
+"No Dockerfile" and "scanned, nothing found" are different results.
 
 ### Report
-- Total by severity
+- Per step: `RAN` or `NOT RUN — <reason>`. A step that did not run has no totals.
+- Total by severity, for the steps that ran
 - Top 3 critical/high with CVE
 - Recommended immediate actions
 - Packages safe to ignore (dev-only, not reachable in prod)
@@ -59,3 +101,8 @@ If Dockerfile present and Docker available: `docker scout cves`
 
 - Distinguish prod vs dev-only vulnerabilities
 - Never suggest `npm audit fix --force` without explaining what it changes
+- **A check that did not run is not a check that passed.** Never report a
+  severity total — least of all zero — for a step whose command was not
+  selected, could not run, or returned no vulnerability data. Report `not
+  measured` and name the reason. In a security report, silence read as "clean"
+  is the most expensive defect available.

package/src/gdskills/bundled/skills/quality/security-audit/SKILL.md

@@ -8,10 +8,11 @@ triggers:
   - "Security scan"
   - "Check for CVEs"
   - "npm audit"
+  - "bun audit"
   - "Dependency vulnerabilities"
 metadata:
   author: "MrCipherSmith"
-  version: "1.0.0"
+  version: "1.1.0"
   category: "quality"
   compatible_harnesses: "cursor,codex,zed,opencode,claude"
 license: "MIT"
@@ -35,22 +36,63 @@ Comprehensive security audit covering dependency vulnerabilities, secrets in cod
 ## Steps
 
 ### Step 1 — Dependency vulnerabilities
-Auto-detect: `bun.lockb` → `bun audit` | `package-lock.json` → `npm audit --json` | `yarn.lock` → `yarn audit`
+
+Detect from the **lockfile**, not from an installed binary. The lockfile is what
+an audit reads; `bun` being on PATH says nothing about whether `bun audit` has a
+lockfile to resolve.
+
+| Lockfile present (repo root) | Command |
+|---|---|
+| `bun.lock` **or** `bun.lockb` | `bun audit --json` |
+| `package-lock.json` **or** `npm-shrinkwrap.json` | `npm audit --json` |
+| `pnpm-lock.yaml` | `pnpm audit --json` |
+| `yarn.lock` | `yarn npm audit --json` (Yarn 2+), else `yarn audit --json` (Yarn 1) |
+
+Check **both** Bun names — `bun.lock` and `bun.lockb`. Bun 1.2 replaced the
+binary `bun.lockb` with the text `bun.lock`, so a project on current Bun has
+only `bun.lock`, and a `bun.lockb`-only check (`bun.lock` unmatched) finds
+nothing there.
+
+**If no row matches, the dependency audit DID NOT RUN.** Say so:
+
+```
+dependency-audit: NOT RUN — no recognised lockfile in <path>
+```
+
+and carry `not measured` — never `0` — into every severity total in the report.
+Do not fall through to another package manager's audit as a guess.
+
+**A command that could not produce results is also NOT RUN.** `npm audit --json`
+without a lockfile exits 1 and prints roughly 240 bytes of
+`{"error":{"code":"ENOLOCK",...}}` — an object with **no `vulnerabilities` key
+at all**. Grouping that by severity yields zero for critical, high, moderate and
+low, which is indistinguishable from a clean project. So before grouping, check
+that the payload actually carries vulnerability data (`vulnerabilities` /
+`advisories` for npm, the per-package arrays for bun). If it does not, the
+outcome is NOT RUN with the tool's own error, not a clean result.
+
+Only once a command has produced real vulnerability data:
 
 Group by severity: **critical → high → moderate → low**
 
 ### Step 2 — Outdated packages
-Run `bun outdated` or `npm outdated`. Flag packages more than 2 major versions behind.
+Run `outdated` for the package manager Step 1 detected (`bun outdated`,
+`npm outdated`, `pnpm outdated`, `yarn outdated`). Flag packages more than 2
+major versions behind. If Step 1 found no package manager, this step is
+`NOT RUN` for the same reason.
 
 ### Step 3 — Secrets scan
 - Check git history for `.env`, `.key`, `.pem` files
 - Grep source for hardcoded passwords/API keys/secrets (excluding node_modules)
 
 ### Step 4 — Docker image scan
-If Dockerfile present and Docker available: `docker scout cves`
+If a Dockerfile is present and Docker is available: `docker scout cves`.
+Otherwise report `container-scan: NOT RUN — <no Dockerfile | docker unavailable>`.
+"No Dockerfile" and "scanned, nothing found" are different results.
 
 ### Report
-- Total by severity
+- Per step: `RAN` or `NOT RUN — <reason>`. A step that did not run has no totals.
+- Total by severity, for the steps that ran
 - Top 3 critical/high with CVE
 - Recommended immediate actions
 - Packages safe to ignore (dev-only, not reachable in prod)
@@ -59,3 +101,8 @@ If Dockerfile present and Docker available: `docker scout cves`
 
 - Distinguish prod vs dev-only vulnerabilities
 - Never suggest `npm audit fix --force` without explaining what it changes
+- **A check that did not run is not a check that passed.** Never report a
+  severity total — least of all zero — for a step whose command was not
+  selected, could not run, or returned no vulnerability data. Report `not
+  measured` and name the reason. In a security report, silence read as "clean"
+  is the most expensive defect available.

package/src/gdskills/bundled/skills/review/review-pr-feedback/SKILL.md

@@ -591,6 +591,7 @@ merge, with every reviewer unanswered.
 
 ```bash
 keryx review comments reply --repo <owner/repo> --pr <n> --outcomes <file|-> \
+                            --result <this-run's-output.json> \
                             --sha <mergedHeadSha> --final [--dry-run] [--flow-link <url>]
 ```
 
@@ -598,6 +599,17 @@ Run it **after** the merge, never during the loop: a reply written mid-round sta
 an intention, and by the time the reviewer reads it the intention has changed.
 `--final` is required by the command; it is not a reminder that can be skipped.
 
+`--result` hands this run's own output to the one keryx-owned point that can
+refuse it. Write the result described in Step 11 to a file first and pass it
+here: the command validates it against `review-pr-feedback-output` BEFORE
+posting anything, so a result that contradicts itself — analyze mode reporting a
+merge, or a screen recorded as never having run while excluding comments — stops
+here instead of being published under your name.
+
+Optional in the CLI, and the registry records this contract as `opt-in` rather
+than enforced for exactly that reason: omit the flag and nothing is checked.
+Passing it is the whole of the enforcement.
+
 The judgement is yours; the command owns the mechanics. It routes an inline comment
 to its thread (`pulls/{n}/comments/{id}/replies`) and a review-submission body or
 PR-level comment to one top-level comment that names what it answers — GitHub

package/src/gdgraph/affected.test.ts

@@ -1,133 +0,0 @@
-import { readFile } from "node:fs/promises";
-import path from "node:path";
-import { fileURLToPath } from "node:url";
-import { expect, test } from "bun:test";
-import { computeAffected } from "./affected";
-import { getAffected } from "./query";
-import type { GraphData } from "./types";
-
-const FIXTURE_DIR = fileURLToPath(new URL("../../fixtures/transitive-closure/", import.meta.url));
-
-async function loadFixtureGraph(): Promise<GraphData> {
-  const raw = JSON.parse(await readFile(path.join(FIXTURE_DIR, "graph.json"), "utf8"));
-  return { nodes: raw.nodes, edges: raw.edges };
-}
-
-async function loadExpected(): Promise<any> {
-  return JSON.parse(await readFile(path.join(FIXTURE_DIR, "expected.json"), "utf8"));
-}
-
-// The pre-block default renderer, replicated verbatim so we can assert the new
-// path is byte-for-byte identical at depth 1 (AC2.2).
-function renderDefault(result: { target: string; dependencies: string[]; dependents: string[] }): string {
-  const lines: string[] = [];
-  lines.push(`# Affected context for ${result.target}`);
-  lines.push("");
-  lines.push("## Dependencies");
-  printList(lines, result.dependencies);
-  lines.push("");
-  lines.push("## Dependents");
-  printList(lines, result.dependents);
-  return lines.join("\n");
-}
-
-function printList(lines: string[], items: string[]): void {
-  if (items.length === 0) {
-    lines.push("- none");
-    return;
-  }
-  for (const item of items) {
-    lines.push(`- ${item}`);
-  }
-}
-
-test("AC2.1 — exact N-hop dependent closure per target per depth", async () => {
-  const graph = await loadFixtureGraph();
-  const expected = await loadExpected();
-
-  for (const [target, byDepth] of Object.entries(expected.closures) as [string, Record<string, string[]>][]) {
-    for (const [depthKey, expectedSet] of Object.entries(byDepth)) {
-      const result = computeAffected(graph, target, { depth: Number(depthKey) });
-      expect(result.dependents).toEqual(expectedSet);
-    }
-  }
-});
-
-test("AC2.3 — cyclic fixture terminates and is deterministic across runs", async () => {
-  const graph = await loadFixtureGraph();
-  const a = computeAffected(graph, "src/x.ts", { depth: 10 });
-  const b = computeAffected(graph, "src/x.ts", { depth: 10 });
-  expect(a.dependents).toEqual(["src/y.ts", "src/z.ts"]);
-  expect(a.dependents).toEqual(b.dependents);
-});
-
-test("AC2.2 — default / --depth 1 renderer is byte-identical to pre-block getAffected", async () => {
-  const graph = await loadFixtureGraph();
-  for (const target of ["src/a.ts", "src/b.ts", "src/e.ts", "src/x.ts"]) {
-    const legacy = getAffected(graph, target);
-    const next = computeAffected(graph, target, { depth: 1 });
-
-    // Underlying data is set-equal (dependents + dependencies).
-    expect(next.dependents).toEqual(legacy.dependents);
-    expect(next.dependencies).toEqual(legacy.dependencies);
-    // Rendered stdout is byte-for-byte identical.
-    expect(renderDefault(next)).toBe(renderDefault(legacy));
-  }
-});
-
-test("AC2.2 — no-flag default depth equals depth 1", async () => {
-  const graph = await loadFixtureGraph();
-  const noFlag = computeAffected(graph, "src/a.ts");
-  const depth1 = computeAffected(graph, "src/a.ts", { depth: 1 });
-  expect(noFlag.dependents).toEqual(depth1.dependents);
-  expect(renderDefault(noFlag)).toBe(renderDefault(depth1));
-});
-
-test("AC2.4 — ranked output ordered hop asc → fanIn desc → path asc", async () => {
-  const graph = await loadFixtureGraph();
-  const expected = await loadExpected();
-  const result = computeAffected(graph, "src/a.ts", { depth: 4, ranked: true });
-  expect(result.ranked).toEqual(expected.ranked["src/a.ts"]["4"]);
-});
-
-test("AC2.4 — dependencies are the unchanged one-hop forward set", async () => {
-  const graph = await loadFixtureGraph();
-  const expected = await loadExpected();
-  for (const [target, deps] of Object.entries(expected.dependencies) as [string, string[]][]) {
-    const result = computeAffected(graph, target, { depth: 3 });
-    expect(result.dependencies).toEqual(deps);
-  }
-});
-
-// ---------------------------------------------------------------------------
-// AFC-11 (flow 234) requirement 3 — a type consumer is visible in impact
-// analysis. `edge.importKind === "type-only"` is erased at runtime and is
-// excluded from `getCycles`' load-order adjacency, but the edge itself is
-// still `kind: "imports"` — a real dependency for "what do I have to
-// re-check" — so `computeAffected` (and `getAffected`) must keep surfacing
-// it. Constructed in-memory rather than through `buildGraph()`: this is a
-// pure-function contract on `GraphData`, unrelated to how the edge's
-// `importKind` was derived.
-// ---------------------------------------------------------------------------
-
-test("AFC-11 req3 — a file that only type-imports the target is still a visible dependent", () => {
-  const graph: GraphData = {
-    nodes: [
-      { id: "src/types.ts", kind: "file", path: "src/types.ts", language: "typescript" },
-      { id: "src/consumer.ts", kind: "file", path: "src/consumer.ts", language: "typescript" },
-    ],
-    edges: [
-      {
-        id: "edge:1",
-        from: "src/consumer.ts",
-        to: "src/types.ts",
-        kind: "imports",
-        specifier: "./types",
-        importKind: "type-only",
-      },
-    ],
-  };
-
-  expect(computeAffected(graph, "src/types.ts").dependents).toEqual(["src/consumer.ts"]);
-  expect(getAffected(graph, "src/types.ts").dependents).toEqual(["src/consumer.ts"]);
-});