peaks-loop 4.0.14 → 4.0.16

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "peaks-loop",
-  "version": "4.0.14",
+  "version": "4.0.16",
   "description": "Loop Engineering CLI — workflow primitive / loop guards / evaluators / slice orchestration",
   "author": "SquabbyZ",
   "keywords": [
@@ -93,6 +93,7 @@
     "node": ">=20.0.0"
   },
   "dependencies": {
+    "@alibaba-group/open-code-review": "^1.8.9",
     "@colbymchenry/codegraph": "0.7.10",
     "better-sqlite3": "^12.11.1",
     "commander": "^12.1.0",
@@ -100,17 +101,9 @@
     "headroom-ai": "0.22.4",
     "yaml": "^2.9.0",
     "zod": "^3.25.76",
-    "peaks-loop-shared": "0.0.45",
-    "peaks-loop-shared-channel": "0.0.22",
-    "peaks-loop-mut": "0.1.18"
-  },
-  "peerDependencies": {
-    "@alibaba-group/open-code-review": "1.3.1"
-  },
-  "peerDependenciesMeta": {
-    "@alibaba-group/open-code-review": {
-      "optional": true
-    }
+    "peaks-loop-mut": "0.1.19",
+    "peaks-loop-shared-channel": "0.0.23",
+    "peaks-loop-shared": "0.0.47"
   },
   "devDependencies": {
     "@changesets/cli": "2.31.1",

package/skills/bee/peaks-rd/SKILL.md

@@ -84,7 +84,7 @@ See `references/rd-runbook.md` for the full 9-step runbook (steps #0–#8) with
 
 You cannot declare a phase complete from memory. Each gate below is a `ls` or `grep` command you **MUST run** and whose output you **MUST see** before proceeding. CLI enforcement: the gates are ALSO enforced by `peaks request transition`, which fails with `code: PREREQUISITES_MISSING` if any are absent.
 
-Gate index: A (project-scan), A2 (tech-doc path verification), A3 (CLAUDE.md + .claude/rules), B (tech-doc + request artifact), B2 (unit tests on changed surface), B3 (code-review.md), B4 (security-review.md), B5 (lint — no unfilled placeholders), B6 (request-type-sanity), B7 (repair-status — 3-cycle cap), B8 (diff-vs-scope), B9 (perf-baseline).
+Gate index: A (project-scan), A2 (tech-doc path verification), A3 (CLAUDE.md + .claude/rules), B (tech-doc + request artifact), B2 (unit tests on changed surface), B3 (code-review.md), B4 (security-review.md), B5 (lint — no unfilled placeholders + JS/TS ESLint 卡控 via `peaks lint check`. First-time project setup: run `peaks lint baseline` to generate the project-level `.peaks/lint/baseline.json`. Per-slice flow uses `peaks lint check` (= diffOnly: true + baseline waiver + redLineMode: 'baseline-aware'). LLM red-line reference lives at `.peaks/memory/lint-redline-summary.md` (auto-written by `peaks lint check --red-line`); read it BEFORE writing JS/TS so the next slice sees prior sibling-violation context. Project-aware baseline: each project regenerates its own baseline; cross-project reuse is low-value — see `references/jsts-eslint-gate.md` §7), B6 (request-type-sanity), B7 (repair-status — 3-cycle cap), B8 (diff-vs-scope), B9 (perf-baseline).
 
 → see `references/rd-transition-gates.md` for the per-gate contract + `ls` / `grep` shell snippets.
 

package/skills/bee/peaks-rd/references/jsts-eslint-gate.md

@@ -0,0 +1,197 @@
+---
+title: JS/TS ESLint Gate (Gate B5 卡控)
+rid: 2026-08-06-eslint-jsts-gate
+session: 2026-08-06-session-cacde8
+status: shipped-4.0.16
+---
+
+# JS/TS ESLint Gate (Gate B5 卡控)
+
+## Section 1 — what the runner does
+
+`peaks lint` is a read-only ESLint verifier for the peaks-rd Gate B5
+surface. It calls `npx` with four pinned packages (no `devDependencies`
+added to peaks-loop) and parses the JSON envelope emitted by
+`--format json`.
+
+Pinned packages (slice PRD-002; aligned with the rules resolved by
+`config/eslint/.peaks-rules.cjs`):
+
+| Package | Pin | Source |
+|---|---|---|
+| `eslint` | 10.8.0 | npm registry |
+| `@typescript-eslint/parser` | 8.66.0 | npm registry |
+| `@typescript-eslint/eslint-plugin` | 8.66.0 | npm registry |
+| `eslint-plugin-import` | 2.32.0 | npm registry |
+
+The runner lives at `src/services/lint/eslint-runner.ts` and exports
+`runEslint({ cwd, scope?, configPath?, fix?, write?, timeoutMs? })`.
+
+## Section 2 — 5-state detect table
+
+`detect-eslint` returns one of:
+
+| State | Meaning | Behavior |
+|---|---|---|
+| `ready` | npx is on PATH and the registry resolves all 4 pins | run lint |
+| `eslint-missing` | lint exited with no findings (likely a toolchain error) | warn |
+| `config-error` | config did not parse | block |
+| `npx-failed` | npx is not on PATH | warn |
+| `detection-failed` | unexpected detection exception | warn |
+
+The wrapper returns `state: 'ok' | 'eslint-missing' | 'npx-failed' |
+'execution-failed'` (lint cannot reach `config-error` because the
+runner is config-agnostic; the consumer supplies `--config <path>`).
+
+## Section 3 — Layer 3 dynamic loading
+
+`config/eslint/.peaks-rules.cjs` allows the L3 (framework) layer to be
+loaded dynamically by `npx --package <pkg> -- eslint`. peaks-loop
+itself never installs the L3 packages; the user opts in per-project.
+If a project needs `eslint-plugin-react`, it is up to the user to
+either:
+
+- run `npm i -D eslint-plugin-react` and update
+  `config/eslint/.peaks-rules.cjs` to extend the relevant config, or
+- call `peaks lint --scope src/` after pre-installing the plugin
+  in their environment.
+
+## Section 4 — soft-fail table
+
+| Runner state | Gate B5 verdict |
+|---|---|
+| `ok` with zero findings | pass |
+| `ok` with findings | warn (findings printed; never block) |
+| `npx-failed` / `eslint-missing` | warn — Gate B5 still passes |
+| `execution-failed` | warn — user must inspect the toolchain |
+
+peaks-rd never blocks a slice on lint; per the G-lint-2 red line,
+peaks lint is a verifier, not a formatter.
+
+## Section 5 — Gate B5 transitions
+
+- `rd:qa-handoff` reads the lint envelope. A missing `peaks lint`
+  run is acceptable if the project is non-JS/TS (Gate B5 is per-language).
+- peaks-rd's own 4-dim lint (placeholder hunt) runs alongside ESLint.
+- The unified verdict is the worst of the two lint families (ESLint
+  warn never escalates to block).
+
+## Section 6 — Configuration precedence
+
+`config/eslint/.peaks-rules.cjs` composes its rule set by extending
+four upstream configs in this order (last-wins on rule overrides):
+
+1. `eslint:recommended` — base ES syntax + best practices.
+2. `plugin:@typescript-eslint/recommended-type-checked` — TS rules
+   that require type info. Requires `@typescript-eslint/parser` to
+   resolve with `project: true`.
+3. `plugin:import/recommended` — module-boundary / import-resolution
+   rules. Reports unresolved imports as errors.
+4. `plugin:import/typescript` — TypeScript-aware import resolver
+   layered on top of `import/recommended`.
+
+User-level `.eslintrc.cjs` (or `--config <path>`) overrides extend in
+priority order: the closer the config is to the source file, the
+higher its precedence. `peaks lint` honours the `--config` flag
+so projects that carry a non-default config can point the runner at
+it without copying into the peaks-loop repo.
+
+The `import/recommended` and `import/typescript` layers in particular
+make the wrapper sensitive to the project's `tsconfig.json` `paths`
+config. A monorepo with `baseUrl` + `paths` aliases must keep its
+tsconfig in scope; otherwise `import/no-unresolved` reports
+spurious errors that downgrade Gate B5 to a noisy warn.
+
+`recommended-type-checked` likewise depends on a resolvable
+`tsconfig.json`; projects that ship a non-default config must pass
+it via `--config` so ESLint can locate the program files for type
+introspection. Without a reachable tsconfig the type-aware rules
+silently no-op, which the runner reports as zero type-checked
+findings (not as an error).
+
+The L3 framework plugins (react / vue / svelte / nestjs) are NOT
+included in the four pinned packages. `peaks lint` will not
+auto-resolve them; the project's own devDependencies must list the
+plugin and the local `.peaks-rules.cjs` must extend its config.
+This keeps the peaks-loop devDeps surface flat while still letting
+per-project opt-in.
+
+## Section 7 — Project-aware baseline (PRD-002b D6 + S1)
+
+`.peaks/lint/baseline.json` is a **project-level** file. Each project
+generates its own baseline via `peaks lint baseline`; downstream
+projects **do not** inherit peak-loop's baseline even when they share
+the same language (TypeScript) — language similarity ≠ project
+structure / toolchain / coding style.
+
+| Project type | Baseline source | Why |
+|---|---|---|
+| `peaks-loop` itself | Ship as reference + fixture | TS CLI; reference value high |
+| Downstream React TS | MUST run `peaks lint baseline` | Different framework / hooks / component patterns |
+| Downstream Python / Go / Java | Language-specific toolchain (future slice) | Cross-language; zero reference value today |
+
+The baseline.json schema (internal contract, not public):
+
+```jsonc
+{
+  "version": 1,
+  "generatedAt": "2026-08-06T...",
+  "toolVersion": "peaks-loop-4.0.16+",
+  "violations": [
+    { "ruleId": "max-lines", "file": "src/x.ts", "line": 401,
+      "severity": "error", "message": "..." }
+  ]
+}
+```
+
+`peaks lint baseline` writes this file at the cwd (default
+`.peaks/lint/baseline.json`); the file is gitignored by default —
+projects that want to ship it (peak-loop itself) use `git add -f`.
+
+## Section 8 — Red-line (LLM development red line; PRD-002b S2)
+
+The lint envelope carries a `redLine` section whenever
+`redLineMode='baseline-aware'` (the default). It aggregates
+baseline.json violations by `ruleId`, sorted by count desc, with the
+top 5 file:line buckets per rule. Sample shape:
+
+```jsonc
+{
+  "redLine": [
+    { "ruleId": "max-lines-per-function", "count": 7,
+      "topFiles": [
+        { "file": "src/services/foo.ts", "count": 3 },
+        { "file": "src/services/bar.ts", "count": 2 }
+      ] }
+  ]
+}
+```
+
+LLM workflow:
+
+1. Before writing JS/TS, read `.peaks/memory/lint-redline-summary.md`
+   (auto-generated by `peaks lint check --red-line` or
+   `peaks lint baseline --red-line`).
+2. If `redLine[0].ruleId === 'max-lines-per-function'` shows 5+
+   existing occurrences, the LLM MUST split any function ≥ 30 lines
+   it would otherwise write; this prevents the violation count from
+   climbing while存量 stays at baseline.
+3. The red-line is **low value when baseline is empty** (project
+   bootstrap) and **high value when baseline is saturated** (≥ 5
+   per rule). The CLI prints a one-line warning when the red-line
+   would help; the LLM should still consult it on every Gate B5.
+
+The red-line is informational, not blocking — Gate B5 still passes
+when redLine has entries. Its job is to keep存量 violation counts
+flat as new code lands, not to escalate存量 work.
+
+## Cross-references
+
+- PRD: `.peaks/_runtime/2026-08-06-session-cacde8/prd/requests/002-2026-08-06-eslint-jsts-gate-and-ocr-multilang-rebuild.md`
+- Sediment: `.peaks/memory/2026-08-06-eslint-jsts-gate-and-ocr-multilang-rebuild-sediment.md`
+- Skills: `skills/bee/peaks-rd/SKILL.md` Gate B5 paragraph
+- Skills: `skills/peaks-code/SKILL.md` Quality-gate commands cheat sheet
+- Config: `config/eslint/.peaks-rules.cjs`
+- Runner: `src/services/lint/eslint-runner.ts`
+- Detect: `src/services/lint/detect-eslint.ts`
+- CLI: `src/cli/commands/lint-commands.ts`

package/skills/bee/peaks-rd/references/ocr-multilang-1.8.md

@@ -0,0 +1,132 @@
+---
+title: OCR 1.8.x Multi-language Reviewer Adapter
+rid: 2026-08-06-ocr-multilang-1-8
+session: 2026-08-06-session-cacde8
+status: shipped-4.0.16
+---
+
+# OCR 1.8.x Multi-language Reviewer Adapter
+
+## Section 1 — per-platform optionalDependencies (1.8.x postinstall fix)
+
+`@alibaba-group/open-code-review@1.8.9` replaces the 2.0.3-era
+GitHub Releases HTTPS download with per-platform `optionalDependencies`
+(`@alibaba-group/ocr-{darwin,linux,win32}-{arm64,x64}`). `npm install`
+hits the registry only; postinstall runs the embedded Node installer
+(`scripts/install.js`) and resolves the platform binary locally.
+
+Sandbox evidence (2026-08-06, `npm@10.9.4`):
+
+```
+npm install @alibaba-group/open-code-review@1.8.9
+added 2 packages in 5s
+npm info run @alibaba-group/open-code-review@1.8.9 postinstall { code: 0, signal: null }
+```
+
+No HTTPS to `github.com` is required. The 2.0.3 install pain (which
+drove the 2.8.2 peerDep downgrade) no longer applies.
+
+## Section 2 — 8-language routing
+
+| `--language` | file extension filter (ocr 1.8.9) |
+|---|---|
+| `python` | `*.py` |
+| `go` | `*.go` |
+| `java` | `*.java` |
+| `rust` | `*.rs` |
+| `cpp` | `*.cc` / `*.cpp` / `*.h` / `*.hpp` |
+| `csharp` | `*.cs` |
+| `ruby` | `*.rb` |
+| `php` | `*.php` |
+
+`--language java` maps to Java review. The wrapper rejects any other
+language with `state: 'language-unsupported'` and a supported list in
+`nextActions`.
+
+## Section 3 — 5-state detect table
+
+`detect-ocr-18` returns one of:
+
+| State | Meaning | Behavior |
+|---|---|---|
+| `ready` | npx + ocr 1.8.9 both resolve | run review |
+| `ocr18-missing` | npx or ocr package cannot resolve | warn |
+| `binary-missing` | platform binary optionalDep missing | warn |
+| `llm-config-missing` | Delegation Mode not requested and no key | warn |
+| `detection-failed` | unexpected detection exception | warn |
+
+The runtime wrapper returns `language-unsupported` as a 6th state
+when the caller supplies a non-mapped language.
+
+## Section 4 — Delegation Mode
+
+`peaks code-review ocr-18-delegate-preview` runs `ocr delegate preview`
+with no LLM key. The wrapper returns the spec the host agent must
+fill in (file list + rule references); the host agent's own LLM
+performs the analysis. This is the fallback path when the user does
+not have an Anthropic/OpenAI key configured.
+
+## Section 5 — soft-fail policy
+
+`run-ocr-18` never blocks a slice. When ocr 1.8.x is not ready, the
+wrapper returns `state: 'ocr18-missing'` (or appropriate) and
+peaks-rd records a TXT note `code-review-ocr18-degraded-to-inline`.
+
+## Section 6 — Gate B3 routing
+
+- JS/TS / TSX / JSX: `peaks lint` + ECC bridge.
+- Python / Go / Java / Rust / C++ / C# / Ruby / PHP:
+  `peaks code-review run-ocr-18 --language <lang>`.
+- Mixed monorepo: per-language routing, findings merged.
+
+## Section 7 — Why per-language routing matters
+
+OCR 1.8.x is the multi-language reviewer in the peaks-rd Gate B3
+router; ECC bridge stays the JS/TS path. The split is intentional and
+informed by AACR-bench (Alibaba's multi-language review benchmark):
+
+- **Precision vs. recall trade-off.** ECC bridge is tuned for JS/TS
+  idioms and ships tighter precision for that surface; on Python or
+  Java codebases it under-recalls (false-negative on async/lifetime
+  bugs). OCR 1.8.x is the inverse: broad language coverage with
+  per-language rule packs.
+- **Enterprise-class checks per language.** OCR 1.8.x's Java pack
+  reports NPE / SQL injection / XSS / thread-safety patterns that
+  have no analogue in the JS/TS ECC skill set. Routing a Java
+  project through ECC would silently drop these findings.
+- **Layered output normalization.** Each language's OCR output is
+  flattened into the peaks-loop `Ocr18Finding` envelope (filePath,
+  line, ruleId, severity, message) so downstream Gate B3 merge
+  works uniformly across all 8 languages.
+- **Failure isolation.** When OCR 1.8.x is missing for one language
+  on a given host, only that language degrades to inline review;
+  other languages still get the full Gate B3 path.
+
+A Python project therefore routes to OCR 1.8.x (not ECC) because
+(a) the Python rule pack has the broadest coverage in 1.8.9, and
+(b) routing it through ECC would mask Python-specific findings.
+
+For monorepos, the router scans the changed file extensions to pick
+a per-language reviewer. A commit that touches `.py` and `.ts`
+sources gets a parallel ECC + OCR-1.8 invocation; the resulting
+finding arrays are merged at Gate B3 with severity sort and
+duplicate suppression (same `filePath:line:ruleId` collapses to a
+single entry).
+
+When Delegation Mode is enabled, the host agent receives a JSON
+spec listing files and candidate rules, applies the user's own LLM
+key, and returns structured findings that the wrapper normalises
+back into the same `Ocr18Finding` envelope — so downstream Gate B3
+merge code does not need a separate code path for the delegation
+flow.
+
+## Cross-references
+
+- PRD: `.peaks/_runtime/2026-08-06-session-cacde8/prd/requests/002-2026-08-06-eslint-jsts-gate-and-ocr-multilang-rebuild.md`
+- Sediment: `.peaks/memory/2026-08-06-eslint-jsts-gate-and-ocr-multilang-rebuild-sediment.md`
+- Skills: `skills/bee/peaks-rd/SKILL.md` Gate B3 paragraph
+- Skills: `skills/peaks-code/SKILL.md` Quality-gate commands cheat sheet
+- Runner: `src/services/lint/ocr-multilang-adapter.ts`
+- Detect: `src/services/lint/detect-ocr-18.ts`
+- CLI: `src/cli/commands/code-review-commands.ts`
+- ECC bridge (production JS/TS path): `src/services/code-review/ecc-bridge.ts`

package/skills/bee/peaks-rd/references/parallel-review-fanout.md

@@ -46,7 +46,7 @@ Note: sub-agent 1 (code-reviewer) and sub-agent 3 (karpathy-reviewer) write to `
 - Inspect for: correctness, type safety, error handling, mutation patterns, file-size, naming, dead code, regressions, contract drift.
 - Output: `.peaks/_runtime/<sessionId>/rd/code-review.md` with sections: Summary, Findings, Required Fixes, Recommended, Verdict.
 - Required for Gate B3.
-- **v2.11.0 Tier 7 (Group D):** the code-reviewer dispatch goes through the **ECC bridge** (`src/services/code-review/ecc-bridge.ts`). The parent RD loop invokes the Agent tool with `subagent_type: "everything-claude-code:code-review"` and receives a structured envelope `{ passed, violations[], gateAction }`. The bridge adapter (`adaptEccEnvelopeToRdCodeReview`) renders that envelope into the canonical `rd/code-review.md` markdown shape that Gate B3 reads (`mustContain: ['## Findings', 'CRITICAL']`). The pre-Tier-7 5-state detect (`detectEcc`: ready / plugin-missing / agent-missing / dispatch-failed / envelope-malformed) soft-fails to inline review on any non-ready state — TXT note `code-review-ecc-degraded-to-inline`. Same soft-fail philosophy as `ocr-service.ts` and `detectOcr`.
+- **v2.11.0 Tier 7 (Group D):** the code-reviewer dispatch goes through the **ECC bridge** (`src/services/code-review/ecc-bridge.ts`). The parent RD loop invokes the Agent tool with `subagent_type: "everything-claude-code:code-review"` and receives a structured envelope `{ passed, violations[], gateAction }`. The bridge adapter (`adaptEccEnvelopeToRdCodeReview`) renders that envelope into the canonical `rd/code-review.md` markdown shape that Gate B3 reads (`mustContain: ['## Findings', 'CRITICAL']`). The 5-state detector (`detectEcc`: ready / plugin-missing / agent-missing / dispatch-failed / envelope-malformed) soft-fails to inline review on any non-ready state — TXT note `code-review-ecc-degraded-to-inline`.
 
 **Sub-agent 2 — qa-test-cases-writer (always runs for feature / refactor / bugfix):**
 - Read the git diff and the PRD acceptance criteria.

package/skills/peaks-code/SKILL.md

@@ -208,7 +208,7 @@ Read `references/refactor-mode.md` first. Default MVP: `peaks-code refactor`. Re
 
 ## Peaks-Loop Quality-gate commands (CLI cheat sheet)
 
-Five CLI commands harden the workflow against silent skips: `peaks request lint`, `peaks request repair-status`, `peaks scan request-type-sanity`, `peaks scan libraries`, `peaks slice check` (plus `peaks request transition`). See `references/quality-gate-cheatsheet.md`.
+Five CLI commands harden the workflow against silent skips: `peaks request lint`, `peaks request repair-status`, `peaks scan request-type-sanity`, `peaks scan libraries`, `peaks slice check` (plus `peaks request transition`). For JS/TS project lint enforcement (Gate B5 expansion), use `peaks lint [--scope <path>] [--format json]` (ESLint read-only verifier; layer-3 dynamic loading via `npx --package`; soft-fail when ESLint is missing — does not block the slice). See `references/quality-gate-cheatsheet.md`.
 
 ## Peaks-Loop Completion handoff
 

package/dist/services/code-review/ocr-service.d.ts

@@ -1,129 +0,0 @@
-import type { OcrLlmConfig } from '../config/config-types.js';
-export type OcrDetectState = 'ready' | 'package-missing' | 'binary-missing' | 'config-missing' | 'detection-failed';
-export interface OcrDetectResult {
-    readonly state: OcrDetectState;
-    readonly packageInstalled: boolean;
-    readonly binaryPath: string | null;
-    readonly version: string | null;
-    /**
-     * The peaks-loop config path that holds `peaksConfig.ocr.llm`.
-     * The user pastes the `peaks code-review config-template` output
-     * here. Empty string when peaks-loop has not been bootstrapped.
-     */
-    readonly configPath: string;
-    readonly configValid: boolean;
-    readonly missingKeys: readonly string[];
-    readonly warnings: readonly string[];
-    readonly nextActions: readonly string[];
-}
-export interface OcrReviewInput {
-    readonly projectRoot: string;
-    readonly from?: string;
-    readonly to?: string;
-    readonly commit?: string;
-}
-export interface OcrReviewResult {
-    readonly spawned: boolean;
-    readonly state: OcrDetectState;
-    readonly exitCode: number | null;
-    readonly stdout: string;
-    readonly stderr: string;
-    readonly durationMs: number;
-    /** Parsed JSON envelope if the ocr subprocess emitted valid JSON. */
-    readonly parsed: unknown;
-    readonly warnings: readonly string[];
-    readonly nextActions: readonly string[];
-}
-export interface SubprocessRunner {
-    run(command: string, args: readonly string[], options: {
-        cwd?: string;
-        timeoutMs: number;
-        env?: NodeJS.ProcessEnv;
-    }): {
-        status: number | null;
-        stdout: string;
-        stderr: string;
-        error?: string;
-    };
-}
-/**
- * Locate the ocr launcher script (`bin/ocr.js`) inside our own
- * node_modules tree. Returns null when the npm package is not
- * present (peaks-loop was installed but its dependency tree is
- * corrupt, or the user removed it).
- *
- * Walks up from this file (dist/services/code-review/) to
- * find the project root, then checks node_modules.
- */
-export declare function resolveOcrLauncher(searchRoots: readonly string[]): string | null;
-/**
- * Resolve search roots for the ocr launcher. We look in two
- * places: (1) the peaks-loop install root (next to our own dist/),
- * (2) the user's cwd.
- */
-export declare function defaultOcrSearchRoots(currentDirPath: string, cwd: string): readonly string[];
-/**
- * Validate the `peaksConfig.ocr.llm` block the caller (CLI / test)
- * read out of `~/.peaks/config.json`. Returns the list of missing
- * required keys (`url`, `authToken`, `model`); empty array means
- * the block is ready to drive the ocr subprocess.
- *
- * The block is independent of the OCR package's own
- * `~/.opencodereview/config.json` file. peaks-loop only ever reads
- * from its own config; the env-var injection in `runOcrReview`
- * makes the legacy file irrelevant.
- */
-export declare function getOcrLlmMissingFields(llm: OcrLlmConfig | null): readonly string[];
-/**
- * Build the env-var overlay peaks-loop injects into the ocr
- * subprocess. Maps `peaksConfig.ocr.llm` onto the OCR package's
- * env-var surface (its highest-priority config source).
- */
-export declare function buildOcrEnv(llm: OcrLlmConfig): NodeJS.ProcessEnv;
-/**
- * The JSON template the user pastes into their peaks-loop config
- * (`peaksConfig.ocr.llm`). Returned as a stable string so the
- * `peaks code-review config-template` CLI command can print it
- * verbatim, and so the detector's `nextActions` payload embeds
- * the same shape the user is told to add.
- */
-export declare function getOcrConfigTemplate(): string;
-export interface OcrDetectOptions {
-    readonly cwd: string;
-    /**
-     * The peaks-loop config path that holds `peaksConfig.ocr.llm`.
-     * Surfaced in the detect result so the user knows where to
-     * paste the template.
-     */
-    readonly peaksConfigPath: string;
-    /**
-     * The parsed `peaksConfig.ocr.llm` block. `null` when the user
-     * has not yet populated the config; the detector surfaces the
-     * `config-missing` state with a templated `nextActions`.
-     */
-    readonly peaksOcrConfig: OcrLlmConfig | null;
-    readonly searchRoots?: readonly string[];
-    readonly runner?: SubprocessRunner;
-}
-/**
- * Detect the full ocr install + config state. The 5 reason states
- * are unchanged from the soft-optional 2.0.0 contract; only the
- * source of `config-missing` moved from `~/.opencodereview/config.json`
- * to `peaksConfig.ocr.llm`.
- */
-export declare function detectOcr(options: OcrDetectOptions): OcrDetectResult;
-export interface OcrReviewOptions extends OcrDetectOptions {
-    readonly input: OcrReviewInput;
-}
-/**
- * Run ocr review and return the structured result. Detects state
- * first; soft-fails when ocr isn't ready (the caller — typically
- * peaks-rd — proceeds without the second-opinion review).
- *
- * The LLM endpoint config from `peaksConfig.ocr.llm` is injected
- * as env vars (`OCR_LLM_URL` / `OCR_LLM_TOKEN` / ...), which the
- * ocr package treats as the highest-priority config source. This
- * is how peaks-loop wires the user-managed config into the ocr
- * subprocess without ever writing `~/.opencodereview/config.json`.
- */
-export declare function runOcrReview(options: OcrReviewOptions): OcrReviewResult;