@herbertgao/pi-extensions 2026.10.1 → 2026.10.2

package/node_modules/pi-lens/dist/clients/dispatch/runners/utils/spawn-outcome.js

@@ -1,101 +0,0 @@
-import { LEDGER_FIELD_MAX } from "../../../ledger-bounds.js";
-import { truncatedByOutputCap } from "../../../spawn-output-cap.js";
-/**
- * The first non-empty line of a tool's output, bounded.
- *
- * Replaces six hand-rolled copies that spelled the same idea two ways —
- * `text.trim().split("\n")[0]` and `(text ?? "").trim().split("\n")[0] ||
- * fallback` — with differing (or absent) length caps. Two behaviours the
- * copies got wrong and this does not: a leading blank line no longer yields an
- * empty "first line", and `\r\n` output no longer keeps its carriage return.
- *
- * Returns `""` when the text is empty or all-whitespace, so callers keep using
- * `firstOutputLine(x) || fallback`.
- */
-export function firstOutputLine(text, max = LEDGER_FIELD_MAX) {
-    for (const line of String(text ?? "").split(/\r?\n/)) {
-        const trimmed = line.trim();
-        if (!trimmed)
-            continue;
-        return trimmed.length > max ? `${trimmed.slice(0, max)}…` : trimmed;
-    }
-    return "";
-}
-/**
- * Decide whether a tool ran, and if not, why (#1816).
- *
- * The defect this closes (the #1736 class): a runner that reads only its
- * parsed diagnostics reports a CLEAN file whenever the parse yields nothing —
- * including when the tool exited non-zero on an unknown flag, was killed by a
- * signal, or never spawned at all. An empty result must distinguish clean from
- * errored.
- *
- * Classification order, most specific first:
- *   1. `result.error` or a signal — the process never completed. `did-not-run`.
- *   2. `status === null` with no error — no exit status ever arrived, so no
- *      analysis can be claimed. `did-not-run`.
- *   3. `reportMissing` — an artifact tool wrote no report. Nonzero exit means
- *      `report-missing`; exit 0 means a genuinely clean run that had nothing
- *      to write.
- *   4. A nonzero status outside the caller's declared `ran` table.
- *      `rejected-invocation`.
- *   5. A nonzero status with nothing to parse. `did-not-run` — a tool that
- *      analysed the file says SOMETHING, so silence plus failure is evidence
- *      it never got that far.
- * Everything else ran.
- *
- * Note what is deliberately NOT a non-ran path: a nonzero status WITH output
- * and no contradicting table. Most linters exit non-zero precisely because
- * they found something, and their findings are on stdout.
- */
-export function classifyRunOutcome(input) {
-    const { result, exitCodes, reportMissing } = input;
-    const status = result.status ?? null;
-    const signal = result.signal ?? null;
-    const output = input.output ?? result.stdout;
-    const base = {
-        status,
-        signal,
-        firstOutputLine: firstOutputLine(result.stderr) ||
-            firstOutputLine(result.stdout) ||
-            firstOutputLine(result.error?.message),
-        // Evidence carried alongside the verdict, never part of deciding it — the
-        // branches below are byte-for-byte the pre-#2100 rules.
-        outputCapped: truncatedByOutputCap(result),
-    };
-    if (result.error || signal)
-        return { kind: "did-not-run", ...base };
-    if (status === null)
-        return { kind: "did-not-run", ...base };
-    if (reportMissing) {
-        return status === 0
-            ? { kind: "ran", ...base }
-            : { kind: "report-missing", ...base };
-    }
-    if (status !== 0 && exitCodes && !exitCodes.ran.includes(status)) {
-        return { kind: "rejected-invocation", ...base };
-    }
-    if (status !== 0 && !output?.trim()) {
-        return { kind: "did-not-run", ...base };
-    }
-    return { kind: "ran", ...base };
-}
-/**
- * True when a tool both failed and produced nothing to parse — it never got as
- * far as linting the file. Callers map this to `skipped`, never `succeeded`.
- *
- * Kept as its own export because callers outside the dispatch runners use it
- * (`dead-code-client.ts`, `knip-client.ts`). It now DELEGATES to
- * `classifyRunOutcome` rather than restating the rule, but keeps its exact
- * historical semantics: the `!output.trim()` conjunct stays here so a spawn
- * error that still produced partial output keeps reaching the parser, which is
- * what today's callers depend on. `classifyRunOutcome` is the stricter,
- * outcome-typed reading; migrate callers to it deliberately, not by accident.
- *
- * `output` defaults to stdout. Runners that parse stderr too pass the exact
- * string they are about to hand the parser, so "nothing to parse" means both
- * streams rather than just one.
- */
-export function spawnFailedWithNoOutput(result, output = result.stdout) {
-    return (classifyRunOutcome({ result, output }).kind !== "ran" && !output?.trim());
-}

package/node_modules/pi-lens/dist/clients/dispatch/runners/utils/tool-failure.js

@@ -1,235 +0,0 @@
-/**
- * One wording for a tool that produced no usable result, and the runner gate
- * that emits it to the degradation ledger (#1816).
- */
-import { incrementDegradationCount } from "../../../degradation-ledger.js";
-import { truncateForLedger } from "../../../ledger-bounds.js";
-import { classifyRunOutcome, firstOutputLine, } from "./spawn-outcome.js";
-/**
- * What ended this run, as one clause, most specific cause first.
- *
- * A signal is a stronger explanation than the exit status, so it displaces a
- * `null` one rather than sitting beside it. Our own output cap is stronger
- * still: the signal it killed with is a detail of OUR decision, and naming that
- * signal alone reads as the tool misbehaving (#2100).
- */
-function describeEnding(input) {
-    if (input.outputCapped)
-        return "was stopped at its output cap";
-    if (input.signal)
-        return `was killed by ${input.signal}`;
-    if (input.status === null)
-        return "did not run (spawn failure)";
-    return `exited ${input.status}`;
-}
-/**
- * One wording for "this tool did not produce a usable result" (#1816).
- *
- * Before this, five reason builders spelled the same sentence five ways and
- * twelve sites truncated with their own literal, and NONE of them named the
- * signal — so a SIGKILLed tool read exactly like a clean exit 0. The wording
- * here is fixed, the truncation is the ledger's own `LEDGER_FIELD_MAX` policy
- * applied once at the end, and the signal is always named when present.
- *
- * Shape: `tool (k=v, k=v) <what happened> with <what was missing>: <detail>`
- */
-export function formatToolFailure(input) {
-    const entries = Object.entries(input.fields ?? {}).filter(([, value]) => value !== undefined && value !== "");
-    const identity = entries.length
-        ? `${input.tool} (${entries.map(([key, value]) => `${key}=${value}`).join(", ")})`
-        : input.tool;
-    const what = describeEnding(input);
-    const missing = input.reportMissing ? "no report file" : "no output";
-    const detail = firstOutputLine(input.stderr) ||
-        firstOutputLine(input.stdout) ||
-        "no stderr";
-    return truncateForLedger(`${identity} ${what} with ${missing}: ${detail}`);
-}
-/**
- * `formatToolFailure` fed straight from a `classifyRunOutcome` verdict — the
- * path every migrated runner takes, so the outcome and the wording can never
- * disagree about the status or the signal.
- */
-export function formatRunOutcomeFailure(tool, outcome, fields) {
-    return formatToolFailure({
-        tool,
-        status: outcome.status,
-        signal: outcome.signal,
-        outputCapped: outcome.outputCapped,
-        stderr: outcome.firstOutputLine,
-        reportMissing: outcome.kind === "report-missing",
-        fields: { outcome: outcome.kind, ...fields },
-    });
-}
-/**
- * The migrated runners' one call: classify the spawn, and when the tool did
- * NOT run, record a bounded `runner-empty-result` row and hand back the
- * `skipped` verdict. Returns `null` when the tool ran, meaning "carry on and
- * parse".
- *
- * `incrementDegradationCount` keeps the record bounded — one latest-reason
- * entry per (kind, subject) with an exact event tally — so a permanently
- * broken tool costs one ledger row, not one per dispatched file. `subject` is
- * the tool id, which is the discriminating identity a reader needs: WHICH tool
- * is silently contributing nothing.
- */
-export function skipUnlessToolRan(tool, input, fields) {
-    const outcome = classifyRunOutcome(input);
-    if (outcome.kind === "ran")
-        return null;
-    incrementDegradationCount({
-        kind: "runner-empty-result",
-        subject: tool,
-        reason: formatRunOutcomeFailure(tool, outcome, fields),
-    });
-    return { status: "skipped", diagnostics: [], semantic: "none" };
-}
-/**
- * The record a runner leaves when its parser read NOTHING out of output the
- * tool did produce (#1948).
- *
- * `skipUnlessToolRan` covers the adjacent case: the tool produced no output at
- * all. The hole it leaves is the one that hid five parser bugs for months —
- * vale (#1933), taplo, stylelint, phpstan (#1946), sqlfluff. Each received a
- * real report, extracted zero diagnostics from it, and reported "succeeded, 0
- * diagnostics", which is byte-for-byte what a genuinely clean file records.
- * A reader could not answer "is this file clean, or did the parser fail?".
- *
- * THE RULE: record only when the exit status is NONZERO, the output handed to
- * the parser is non-empty, and the parse yielded zero diagnostics. A nonzero
- * exit is the tool asserting something is wrong; extracting nothing from that
- * assertion means our reader disagrees with the tool, and one of the two is
- * broken.
- *
- * Exit 0 with zero parsed is deliberately NOT recorded, even with non-empty
- * output: that is the overwhelmingly common clean save. Linters print summary
- * banners, empty JSON arrays, and progress noise on a clean run, so a row per
- * clean save would drown the ledger and bury the real signal.
- *
- * FALSE NEGATIVES this rule accepts, stated plainly:
- *   - A tool that reports findings under exit 0. `swiftlint` is the live
- *     example among the adopters: a warning-only run exits 0 and still writes
- *     a full JSON array, so a swiftlint parser break that never trips a
- *     nonzero exit stays invisible here. (`vale` also exits 0 on findings by
- *     default, but its actual #1933 break exited 1, so it is not the example.)
- *     This gap is deliberate and is NOT closed by adding an output-length
- *     threshold for exit 0. That class belongs to the captured-fixture lane —
- *     `tests/clients/dispatch/runners/captured-real-output.test.ts` pins each
- *     parser against real recorded binary output, which catches a broken
- *     parser directly instead of guessing from output size. A length
- *     threshold here would fire on every clean run of every tool that prints
- *     a summary banner.
- *   - A tool whose parser breaks only for a SUBSET of findings still reports
- *     the ones it can read, so `parsedCount` is nonzero and nothing records.
- *
- * FALSE POSITIVES it accepts: a runner that legitimately parses zero
- * diagnostics out of a failing run — `go-vet` exits nonzero for a SIBLING
- * file's problem and then filters to the edited file, and `terragrunt` does
- * the same across a unit directory. Such runners stay off this helper rather
- * than being special-cased inside it; see the runner-family registries in
- * `tests/clients/dispatch/runners/parsed-nothing-sweep.test.ts`.
- *
- * Bounded by `incrementDegradationCount`: one latest-reason entry per
- * (kind, subject) with an exact tally, so a permanently broken parser costs
- * ONE ledger row and not one per dispatched file. `subject` is the tool id
- * because a parser break is a property of the tool and our reader of it, not
- * of the project it ran in; aggregating on the tool keeps exactly the identity
- * a reader needs ("which tool is stuck") while staying bounded across every
- * workspace in the session.
- *
- * @returns true when a row was recorded.
- */
-export function recordParsedNothing(input) {
-    const { tool, status, output, parsedCount } = input;
-    // Three conjuncts, one per clause of the rule above. Each is separately
-    // load-bearing and separately tested: `parsedCount` keeps a run that DID
-    // yield findings silent, `status` keeps the clean-save case silent (0 and a
-    // never-arrived null alike — neither is a tool asserting a problem), and
-    // `output` keeps "the tool said nothing at all" with `runner-empty-result`
-    // rather than double-recording it here.
-    if (parsedCount > 0)
-        return false;
-    if (!status)
-        return false;
-    const text = output ?? "";
-    if (!text.trim())
-        return false;
-    const entries = Object.entries(input.fields ?? {}).filter(([, value]) => value !== undefined && value !== "");
-    const identity = entries.length
-        ? `${tool} (${entries.map(([key, value]) => `${key}=${value}`).join(", ")})`
-        : tool;
-    incrementDegradationCount({
-        kind: "runner-parsed-nothing",
-        subject: tool,
-        reason: truncateForLedger(`${identity} exited ${status} with ${text.length} chars of output but the parser read 0 diagnostics: ${firstOutputLine(text) || "no first line"}`),
-    });
-    return true;
-}
-/**
- * The one seam a runner uses to go from a spawn result to diagnostics (#1948).
- *
- * It composes the two gates that must BOTH hold before a runner may claim a
- * clean file: `skipUnlessToolRan` (the tool produced nothing — #1816) and
- * `recordParsedNothing` (the tool produced something the parser could not
- * read). Runners call this instead of calling `skipUnlessToolRan` and then
- * parsing on their own, so the second gate cannot be forgotten by whoever
- * writes runner 53. `tests/clients/dispatch/runners/parsed-nothing-sweep.test.ts`
- * enforces that.
- */
-export function parseToolRun(tool, input, parse, options = {}) {
-    const skipped = skipUnlessToolRan(tool, input, options.fields);
-    if (skipped)
-        return { skipped, diagnostics: [], parsedNothing: false };
-    const output = options.parseOutput ?? input.output ?? input.result.stdout ?? "";
-    const diagnostics = [...parse(output)];
-    const parsedNothing = recordParsedNothing({
-        tool,
-        status: input.result.status ?? null,
-        output,
-        parsedCount: diagnostics.length,
-        fields: options.fields,
-    });
-    if (parsedNothing && options.skipWhenParsedNothing) {
-        return {
-            skipped: { status: "skipped", diagnostics: [], semantic: "none" },
-            diagnostics: [],
-            parsedNothing,
-        };
-    }
-    return { skipped: null, diagnostics, parsedNothing };
-}
-export function finishParsedRun(input) {
-    const raw = `${input.result.stdout ?? ""}${input.result.stderr ?? ""}`;
-    const status = input.result.status ?? null;
-    if (input.diagnostics.length === 0) {
-        if (status !== 0 && raw.trim().length > 0) {
-            return {
-                status: "failed",
-                diagnostics: [
-                    {
-                        id: `${input.tool}:parse-error:1`,
-                        message: `${input.tool} exited ${status} but its output could not be parsed`,
-                        filePath: input.ctx.filePath,
-                        line: 1,
-                        column: 1,
-                        severity: "warning",
-                        semantic: "warning",
-                        tool: input.tool,
-                    },
-                ],
-                semantic: "warning",
-            };
-        }
-        return { status: "succeeded", diagnostics: [], semantic: "none" };
-    }
-    const mapped = input.classify?.(input.diagnostics);
-    if (mapped) {
-        return { ...mapped, diagnostics: input.diagnostics };
-    }
-    const hasBlocking = input.diagnostics.some((d) => d.semantic === "blocking");
-    return {
-        status: hasBlocking ? "failed" : "succeeded",
-        diagnostics: input.diagnostics,
-        semantic: hasBlocking ? "blocking" : "warning",
-    };
-}

package/node_modules/pi-lens/dist/clients/dispatch/runners/utils/toolchain-availability.js

@@ -1,169 +0,0 @@
-/**
- * Shared toolchain-availability lifecycle (#1476 Sonar follow-up).
- *
- * `candidate-probe.ts` factored out the PATH sweep the Go and Rust clients ran,
- * but the LIFECYCLE around it stayed written twice: the transient-aware latch,
- * the in-flight dedupe that keeps concurrent first-time callers to one sweep,
- * the path memo, and the two `availability_decision` records. Two copies of one
- * rule is how #1467's fix missed seven sites, so the rule lives here once and
- * each client contributes only its configuration.
- *
- * Callers keep their own public method names — `isGoAvailableAsync`,
- * `findCargoPathAsync` — because other modules call them; only the body moves.
- */
-import { createAvailabilityLatch, logAvailabilityDecision, } from "./availability-policy.js";
-import { probeAvailabilityCandidates } from "./candidate-probe.js";
-import { createAvailabilityProbeFlight } from "../../../availability-probe-flight.js";
-import { createGenerationSource } from "../../../generation-guard.js";
-import { createSingleFlight } from "../../../single-flight.js";
-/**
- * Session generation for toolchain-availability resets (#2455 fix round 3, F2).
- *
- * `reset()` clears the memo and the latch, but a probe that was ALREADY in
- * flight when it ran knows nothing about that. Without a generation, a
- * post-reset caller joins the pre-reset flight and, worse, that flight's own
- * settlement writes its stale verdict back into the freshly cleared latch — so
- * a tool installed between sessions still read "missing" for the whole new
- * session. That is #1674's defect read from both the sharing side and the
- * settle side, and the reason `SingleFlightOptions.generation` exists.
- *
- * This is the repo's extracted primitive (`clients/generation-guard.ts`, #1754)
- * rather than a hand-rolled counter (#2455 fix round 4, F1). Two things come
- * with it that the hand-rolled form did not have: the source is declared by
- * construction, so the #1754 ratchet can see it; and `guardedWrite` puts every
- * superseded write in the degradation ledger as a bounded
- * `generation-guard-stale-write` record per (source, subject), so a dogfood
- * session can tell "the guard is working" from "the guard never fires" instead
- * of watching superseded writes vanish silently (F4).
- *
- * A module-level source rather than a per-instance one, deliberately. It is a
- * counter, so nothing has to be hand-maintained and no flight is retained for
- * the sake of superseding it. And `toolchainProbeFlights` is itself shared
- * ACROSS instances (#2131: two clients probing the same candidate list run one
- * sweep), so its supersede signal cannot live on any one instance. The cost is
- * that resetting one toolchain also supersedes another's in-flight sweep; that
- * is at worst one extra probe, never a wrong verdict, and every registered
- * reset fires in the same `session_start` block anyway.
- */
-const toolchainGenerations = createGenerationSource("toolchain-availability");
-const toolchainProbeFlights = createAvailabilityProbeFlight({ generation: toolchainGenerations.current });
-/**
- * Own one toolchain's availability: sweep the platform candidate list, memoize
- * the path that answered, and park the verdict behind the shared latch so a
- * timed-out probe expires instead of latching "the toolchain is not installed"
- * for the life of the process.
- */
-export function createToolchainAvailability(config) {
-    const availabilityLatch = createAvailabilityLatch();
-    let toolPath = null;
-    /** Classification of the candidate sweep, for the retry decision. */
-    let sweepSawTransient = false;
-    let sweepTransientCause = "probe-timeout";
-    let sweepHostStallMs = 0;
-    /** What the last classified candidate returned, for the decision record. */
-    let sweepEvidence;
-    const ensureFlight = createSingleFlight({
-        generation: toolchainGenerations.current,
-    });
-    async function findPath() {
-        if (toolPath)
-            return toolPath;
-        const paths = process.platform === "win32" ? config.windowsPaths : config.unixPaths;
-        const handle = toolchainGenerations.capture();
-        const shared = toolchainProbeFlights.run(`toolchain:${config.tool}|${config.probeArgs.join("|")}|${config.windowsPaths.join("|")}|${config.unixPaths.join("|")}`, () => probeAvailabilityCandidates(paths, config.probeArgs, config.budgetMs));
-        const sweep = await shared.promise;
-        // A reset may have landed while this sweep was running. Its answer then
-        // describes the session that just ended, so it must not write itself back
-        // into the memo `reset()` just cleared, nor into the classification fields
-        // the replacement flight reads to build ITS verdict. The memo is the
-        // sharper half: a superseded sweep that writes `foundPath` latches a path
-        // the reset may have been called BECAUSE it went away, so the seam that
-        // exists to un-latch a false "missing" would instead latch a false
-        // "found". Callers already holding this promise still get what the sweep
-        // actually found.
-        handle.guardedWrite(`findPath:${config.tool}`, () => {
-            sweepSawTransient = sweep.sawTransient;
-            sweepTransientCause = sweep.transientCause;
-            sweepHostStallMs = sweep.hostStallMs;
-            sweepEvidence = sweep.evidence;
-            if (sweep.foundPath)
-                toolPath = sweep.foundPath;
-        });
-        return sweep.foundPath;
-    }
-    async function resolveAvailability() {
-        const startedAt = Date.now();
-        const handle = toolchainGenerations.capture();
-        const resolvedPath = await findPath();
-        const found = resolvedPath !== null;
-        // #2455 fix round 3, F2: a reset during the probe opened a NEW session.
-        // This flight answers the OLD one, so writing its verdict into the
-        // freshly cleared latch would re-latch a stale "missing" for the whole
-        // new session — the bug the reset exists to prevent, reintroduced by the
-        // reset's own timing. Report the verdict to this flight's own callers;
-        // do not latch it, and say so in the decision record's `latched`.
-        const superseded = !handle.isCurrent();
-        if (found) {
-            handle.guardedWrite(`latch:${config.tool}`, () => availabilityLatch.noteAvailable());
-            // The RESOLVED path, not the memo (#2455 fix round 4, F6). A superseded
-            // sweep is forbidden from writing `toolPath`, so reading the memo here
-            // logged `Go found: null` on exactly the branch this line exists to
-            // explain.
-            config.log(`${config.label} found: ${resolvedPath}`);
-            logAvailabilityDecision({
-                tool: config.tool,
-                verdict: "available",
-                outcome: "success",
-                cause: "ok",
-                elapsedMs: Date.now() - startedAt,
-                latched: !superseded,
-                hostStallMs: sweepHostStallMs,
-                budgetMs: config.budgetMs,
-                classifiedBy: "probe",
-                ...(sweepEvidence !== undefined && { evidence: sweepEvidence }),
-            });
-            return true;
-        }
-        // A timed-out version probe is evidence about this moment, not about
-        // whether the toolchain is installed; it expires instead of latching.
-        const outcome = sweepSawTransient ? "transient" : "missing";
-        const cause = sweepSawTransient ? sweepTransientCause : "not-found";
-        const retryAfterMs = handle.guardedWrite(`latch:${config.tool}`, () => availabilityLatch.noteUnavailable(outcome, cause)) ?? 0;
-        logAvailabilityDecision({
-            tool: config.tool,
-            verdict: "unavailable",
-            outcome,
-            cause,
-            elapsedMs: Date.now() - startedAt,
-            latched: !superseded && outcome !== "transient",
-            hostStallMs: sweepHostStallMs,
-            ...(retryAfterMs > 0 && { retryAfterMs }),
-            budgetMs: config.budgetMs,
-            // Derived from the sweep's own candidate probes, and carrying what the
-            // last of them returned (#1500).
-            classifiedBy: "probe",
-            ...(sweepEvidence !== undefined && { evidence: sweepEvidence }),
-        });
-        return false;
-    }
-    async function isAvailable() {
-        // `read()` returns null when the last verdict was transient and its
-        // cooldown expired, which re-enters the candidate sweep (#1476).
-        const memo = availabilityLatch.read();
-        if (memo !== null)
-            return memo;
-        return ensureFlight.run("availability", resolveAvailability);
-    }
-    function reset() {
-        toolPath = null;
-        availabilityLatch.reset();
-        // Supersede every sweep and availability flight already running, in this
-        // instance and in the shared registry. No `clear()`: the generation bump
-        // is what makes a stale flight unjoinable and unable to re-latch, and
-        // `SingleFlight.release`'s identity check already stops it from evicting
-        // its successor. Clearing the SHARED registry here would additionally
-        // drop another toolchain's live claim and cost it a duplicate sweep.
-        toolchainGenerations.bump();
-    }
-    return { findPath, isAvailable, reset };
-}

package/node_modules/pi-lens/dist/clients/dispatch/runners/utils.js

@@ -1,15 +0,0 @@
-/**
- * Shared utilities for runners
- */
-import * as fs from "node:fs";
-/**
- * Read file content, returning undefined if it can't be read
- */
-export function readFileContent(filePath) {
-    try {
-        return fs.readFileSync(filePath, "utf-8");
-    }
-    catch {
-        return undefined;
-    }
-}

package/node_modules/pi-lens/dist/clients/dispatch/runners/vale.js

@@ -1,128 +0,0 @@
-import * as fs from "node:fs";
-import * as path from "node:path";
-import { pathsEqual } from "../../path-utils.js";
-import { safeSpawnAsync } from "../../safe-spawn.js";
-import { resolveRunnerCwd } from "../../tool-cwd.js";
-import { PRIORITY } from "../priorities.js";
-import { createAvailabilityChecker, resolveToolCommandWithInstallFallback, } from "./utils/runner-helpers.js";
-import { parseToolRun } from "./utils/tool-failure.js";
-const vale = createAvailabilityChecker("vale", ".exe");
-/**
- * Check for a .vale.ini config file in cwd or parent dirs.
- */
-function findValeConfig(cwd) {
-    const local = path.join(cwd, ".vale.ini");
-    if (fs.existsSync(local))
-        return local;
-    let current = path.resolve(cwd);
-    while (true) {
-        const candidate = path.join(current, ".vale.ini");
-        if (fs.existsSync(candidate))
-            return candidate;
-        const parent = path.dirname(current);
-        if (parent === current)
-            break;
-        current = parent;
-    }
-    return undefined;
-}
-export function parseValeOutput(raw, filePath, cwd) {
-    const diagnostics = [];
-    if (!raw.trim())
-        return diagnostics;
-    const absTarget = path.resolve(cwd, filePath);
-    try {
-        const parsed = JSON.parse(raw);
-        if (!parsed || typeof parsed !== "object")
-            return diagnostics;
-        // #3295: vale's top level is keyed BY the linted file's path — the only
-        // place the reported path appears. `Object.values` dropped it, so a
-        // `.vale.ini` glob or a directory argv charged a second file's alerts to
-        // the dispatched one.
-        for (const [reported, alerts] of Object.entries(parsed)) {
-            if (!Array.isArray(alerts))
-                continue;
-            if (reported && !pathsEqual(path.resolve(cwd, reported), absTarget))
-                continue;
-            for (const alert of alerts) {
-                if (!alert.Message)
-                    continue;
-                const severityMap = {
-                    error: "error",
-                    warning: "warning",
-                    info: "info",
-                    suggestion: "info",
-                };
-                const severity = severityMap[alert.Severity?.toLowerCase() ?? ""] ?? "warning";
-                diagnostics.push({
-                    id: `vale-${alert.Line}-${alert.Check ?? "unknown"}`,
-                    message: `[${alert.Check ?? "vale"}] ${alert.Message}`,
-                    filePath,
-                    line: alert.Line ?? 1,
-                    column: alert.Span?.[0] ?? 1,
-                    severity,
-                    semantic: severity === "error" ? "blocking" : "warning",
-                    tool: "vale",
-                    rule: alert.Check ?? "vale",
-                    fixable: false,
-                });
-            }
-        }
-    }
-    catch {
-        // JSON parse failed, return empty
-        return diagnostics;
-    }
-    return diagnostics;
-}
-const valeRunner = {
-    id: "vale",
-    appliesTo: ["markdown"],
-    priority: PRIORITY.DOC_QUALITY,
-    skipTestFiles: false,
-    async run(ctx) {
-        const cwd = resolveRunnerCwd(ctx, "vale");
-        // Config-gated: skip unless a .vale.ini is found
-        if (!findValeConfig(cwd)) {
-            return { status: "skipped", diagnostics: [], semantic: "none" };
-        }
-        let cmd = null;
-        if (await vale.isAvailableAsync(cwd)) {
-            cmd = vale.getCommand(cwd);
-        }
-        else {
-            cmd = await resolveToolCommandWithInstallFallback(cwd, "vale");
-        }
-        if (!cmd)
-            return { status: "skipped", diagnostics: [], semantic: "none" };
-        // Vale exits 0 even on findings, non-zero only on errors
-        const result = await safeSpawnAsync(cmd, ["--output", "JSON", ctx.filePath], { cwd, timeout: 15000 });
-        // #1816: this runner read `result.status` zero times, so a Vale that
-        // rejected its config exited nonzero with an empty stdout, parsed to
-        // zero alerts, and reported clean prose. No exit-code table: Vale's
-        // nonzero codes vary with --minAlertLevel, so the conservative
-        // nothing-to-parse rule is the only safe discriminator here.
-        //
-        // #1948: `parseToolRun` adds the second gate. Vale's `Data.Files`
-        // envelope bug produced exactly this shape — exit 1, a full JSON
-        // report on stdout, zero alerts parsed — and left no record.
-        const run = parseToolRun("vale", {
-            result,
-            // EXIT TABLE (Vale 3.9.6 docs https://vale.sh/docs/topics/metrics/): 0 clean; 1 findings; 2 error; other nonzero rejected.
-            exitCodes: { ran: [1, 2] },
-        }, (raw) => parseValeOutput(raw, ctx.filePath, cwd));
-        if (run.skipped)
-            return run.skipped;
-        const diagnostics = run.diagnostics;
-        if (diagnostics.length === 0) {
-            return { status: "succeeded", diagnostics: [], semantic: "none" };
-        }
-        const hasBlocking = diagnostics.some((d) => d.semantic === "blocking");
-        return {
-            status: hasBlocking ? "failed" : "succeeded",
-            diagnostics,
-            semantic: hasBlocking ? "blocking" : "warning",
-        };
-    },
-};
-export default valeRunner;