@herbertgao/pi-extensions 2026.10.0 → 2026.10.2

package/node_modules/pi-lens/dist/clients/zizmor-config.js

@@ -1,340 +0,0 @@
-import * as path from "node:path";
-import { safeSpawnAsync } from "./safe-spawn.js";
-import { findLocalToolConfig } from "./path-utils.js";
-import { incrementDegradationCount } from "./degradation-ledger.js";
-import { classifyProbeFailure, createAvailabilityLatch, logAvailabilityDecision, startHostStallSampler, } from "./dispatch/runners/utils/availability-policy.js";
-/**
- * zizmor (GitHub Actions workflow security scanner) configuration discovery and
- * online-mode token resolution. zizmor runs as a cross-cutting auxiliary LSP
- * (#272); this module owns the two repo/environment-derived inputs the server
- * spawn and the auxiliary profile need.
- */
-// zizmor discovers its config (curated ignores + per-rule config) as
-// `zizmor.yml`/`.yaml` at the repo root or under `.github/` — see zizmor's
-// configuration docs (discovery order: .github/zizmor.y[a]ml, then root). The
-// presence of one is the repo's deliberate opt-in: it carries the author's
-// chosen severities/ignores, so we let zizmor findings BLOCK in that workspace
-// (advisory-only otherwise, like Opengrep's local-rules gate).
-const LOCAL_ZIZMOR_CONFIG_NAMES = [
-    path.join(".github", "zizmor.yml"),
-    path.join(".github", "zizmor.yaml"),
-    "zizmor.yml",
-    "zizmor.yaml",
-];
-// Deliberately UNCEILINGED at $HOME (refs #2472 review round 3, F1): a
-// user-level `~/zizmor.yml` (or `~/.github/zizmor.yml`) is a legitimate
-// global config, not an escaped-workspace accident.
-export function findLocalZizmorConfig(startDir) {
-    return findLocalToolConfig(startDir, LOCAL_ZIZMOR_CONFIG_NAMES);
-}
-// zizmor's own input collection (see `zizmor --collect`) only ever audits three
-// path shapes: workflow YAML under `.github/workflows/`, a composite/reusable
-// action definition (`action.yml`/`action.yaml`, anywhere in the repo — GitHub
-// resolves these relative to whichever directory references them, not just the
-// root), and the repo's Dependabot config (`.github/dependabot.yml`/`.yaml`,
-// GitHub only ever reads this one location). Every other YAML file is a
-// guaranteed no-op: measured directly against a real `zizmor --lsp` process
-// (#<issue>), a non-matching file gets NO `publishDiagnostics` at all — not
-// even an empty one — so `waitForDiagnostics` burns its full aggregateWaitMs
-// budget (2000ms, bounded by the per-edit caller cap) on every such edit for
-// zero signal (#636). This predicate is the LSP-candidacy gate (server.ts's
-// `ZizmorServer.pathFilter`) that keeps zizmor out of the candidate list for
-// files it can never report on, mirroring its own collection rules exactly —
-// under-matching would silently drop real workflow/action coverage,
-// over-matching would leave the wasted-wait gap in place for common
-// non-GitHub YAML (docker-compose.yml, k8s manifests, …).
-export function isZizmorAuditTarget(filePath) {
-    const normalized = filePath.replace(/\\/g, "/");
-    const base = path.basename(normalized).toLowerCase();
-    if (/(^|\/)\.github\/workflows\/[^/]+\.ya?ml$/i.test(normalized))
-        return true;
-    if (base === "action.yml" || base === "action.yaml")
-        return true;
-    if (/(^|\/)\.github\/dependabot\.ya?ml$/i.test(normalized))
-        return true;
-    return false;
-}
-// A transient-aware latch for the `gh auth token` derivation (#1535, the
-// #1467/#1494 permanent-probe-latch family). The old code folded EVERY
-// failure — including a 5s host stall — into a memoized `{ value: undefined }`
-// that stuck for the whole process, so a single slow `gh` disabled zizmor's
-// GitHub-aware online audits (known-vulnerable-actions, unpinned-uses,
-// impostor-commit) for the rest of the session while the scan still reported
-// success. Only a genuine answer (gh ran and returned a real exit code, or is
-// proven absent) latches now; a timeout/stall/unspawnable probe expires on the
-// shared cooldown and is re-probed on the next call.
-//
-// The cooldown ladder is capped below zizmor's respawn cadence, but that
-// cadence isn't a single number: `clients/runtime-turn.ts`'s ordinary LSP
-// idle reset is 240s, while a subagent session or budget pressure can
-// recycle the fleet on `clients/lsp-budget.ts`'s shorter
-// `DEFAULT_LSP_BUDGET_IDLE_TIMEOUT_MS` (60s). The 120s cap sits BELOW the
-// 240s cadence but ABOVE the 60s one, so that faster respawn can still land
-// inside a still-cooling verdict — the shared default cap
-// (`TRANSIENT_MAX_COOLDOWN_MS`, 5 min) would make either respawn read the
-// cache instead of re-probing. The 60s gap is covered differently: the
-// cache-hit path in `resolveZizmorGitHubToken` logs an
-// `availability_decision` and counts a degradation on every transient cache
-// read, not only on the probe that produced it, so a respawn landing inside
-// EITHER cadence is still observable even when it isn't re-probed (#1535
-// review).
-const ZIZMOR_TOKEN_MAX_COOLDOWN_MS = 120_000;
-const ghTokenLatch = createAvailabilityLatch({
-    maxCooldownMs: ZIZMOR_TOKEN_MAX_COOLDOWN_MS,
-});
-let cachedToken;
-const GH_TOKEN_PROBE_TIMEOUT_MS = 5000;
-/**
- * Forget the memoized `gh auth token` verdict. Called at `session_start`
- * (`clients/runtime-session.ts`, alongside the sibling `#1266`
- * `resetDispatchAvailabilityState` reset) so a user who runs `gh auth login`
- * and starts a new session doesn't keep reading a stale "no token" answer
- * from the previous one — the latch is process-lived storage, but its
- * DURABILITY contract is per-session, matching every other dispatch
- * availability latch.
- */
-export function resetZizmorTokenAvailability() {
-    ghTokenLatch.reset();
-    cachedToken = undefined;
-}
-/**
- * Test-only internals access for the session-state registry probe (#1535):
- * the conformance suite arms a latched "missing" verdict and proves the
- * session reset forgets it.
- */
-export function _getZizmorTokenLatchForTests() {
-    return ghTokenLatch;
-}
-/** Test-only alias — kept so existing tests don't need a rename. */
-export function _resetZizmorTokenCacheForTests() {
-    resetZizmorTokenAvailability();
-}
-/**
- * Classify a failed `gh auth token` probe.
- *
- * `classifyProbeFailure`'s default branch treats ANY unrecognized failure —
- * including a spawn that never actually ran (EACCES, a resolution error, the
- * generic `spawn-failed` bucket) — as a durable `non-installable` verdict.
- * That is correct for a probe that ran and rejected, but wrong here: an
- * unspawnable prober never asked `gh` anything, so it must not be read as a
- * durable "no" (the lesson from this week's sibling-fix reviews on the
- * #1467/#1494 latch family). Only two shapes may latch: a completed run (any
- * exit code — that IS gh's answer) and a proven-absent `gh` binary.
- */
-function classifyGhTokenFailure(res, hostStallMs) {
-    // #1651 review F5: `!res.error` alone is not proof gh ran and answered.
-    // A `null` or negative `status` is Node's OWN signal that the process
-    // never completed a real run — no completed process exits with either —
-    // so this never trusts a bare-`error` check over that shape, regardless
-    // of whether `safeSpawnAsync` happened to attach an `error` for this
-    // particular result. OS-independent by construction: it reads the status
-    // Node reports, not a platform-specific errno.
-    const neverAnswered = res.status === null || (res.status ?? 0) < 0;
-    if (!res.error && !neverAnswered) {
-        // The process ran to completion with a real (nonzero, since the zero
-        // exit is handled before this is ever called) exit code — a genuine
-        // "not authenticated" (or otherwise rejected) answer, safe to cache.
-        return {
-            outcome: "non-installable",
-            cause: "probe-rejected",
-            classifiedBy: "caller",
-        };
-    }
-    if (res.spawnFailure?.kind === "tool-not-found") {
-        // gh genuinely isn't on PATH — a durable fact about the machine.
-        return { outcome: "missing", cause: "not-found", classifiedBy: "caller" };
-    }
-    const classified = classifyProbeFailure(res, { hostStallMs });
-    if (classified.outcome === "transient" || classified.outcome === "missing") {
-        return { ...classified, classifiedBy: "probe" };
-    }
-    // Everything else (EACCES/permission-denied, cwd-unresolvable, a generic
-    // spawn-failed, or an unrecognized errno) means the child never launched —
-    // that's evidence about this moment, not about gh's auth state.
-    return {
-        outcome: "transient",
-        cause: classified.cause,
-        classifiedBy: "caller",
-    };
-}
-async function deriveGhCliToken(consumer) {
-    const sampler = startHostStallSampler();
-    const startedAt = Date.now();
-    // Best-effort: a missing/unauthenticated `gh` leaves the requesting
-    // consumer without a derived token; only the zizmor wrapper turns that into
-    // an offline-mode degradation.
-    // ignoreAmbientSignal so a mid-turn Esc can't silently drop the server into
-    // offline mode; short timeout so a wedged `gh` never stalls the warm spawn.
-    // safeSpawnAsync never rejects (every failure resolves into `res`), so no
-    // try/finally is needed to guarantee the sampler stops.
-    const res = await safeSpawnAsync("gh", ["auth", "token"], {
-        timeout: GH_TOKEN_PROBE_TIMEOUT_MS,
-        ignoreAmbientSignal: true,
-    });
-    const hostStallMs = sampler.stop();
-    const elapsedMs = Date.now() - startedAt;
-    if (!res.error && res.status === 0) {
-        const token = res.stdout.trim();
-        if (token.length > 0) {
-            ghTokenLatch.noteAvailable();
-            logAvailabilityDecision({
-                tool: consumer === "zizmor" ? "zizmor-gh-token" : "github-token",
-                verdict: "available",
-                outcome: "success",
-                cause: "ok",
-                elapsedMs,
-                latched: true,
-                hostStallMs,
-                budgetMs: GH_TOKEN_PROBE_TIMEOUT_MS,
-                classifiedBy: "probe",
-            });
-            return token;
-        }
-        // `gh` ran cleanly and answered with nothing — a genuine, durable "no
-        // token" verdict (distinct from a rejected/nonzero exit), so it is safe
-        // to cache. Reviewer-caught #1535 gap: the pre-fix version of this
-        // branch called `noteAvailable()` / logged `verdict:"available"` here
-        // regardless of whether `token` was empty, so the record claimed the
-        // online audits ran while zizmor was actually about to launch offline
-        // — the #1535 silence moved into the telemetry instead of being fixed.
-        return recordGhTokenUnavailable(consumer, {
-            outcome: "non-installable",
-            cause: "empty-result",
-            classifiedBy: "caller",
-        }, elapsedMs, hostStallMs);
-    }
-    return recordGhTokenUnavailable(consumer, classifyGhTokenFailure(res, hostStallMs), elapsedMs, hostStallMs);
-}
-/**
- * Shared tail for every "no token" verdict: latches (or cools down) the
- * memo, records the degradation this causes when it isn't durable-expected,
- * and logs the decision. Centralized so the empty-answer and failure paths
- * can't drift on which fields get set.
- */
-function recordGhTokenUnavailable(consumer, { outcome, cause, classifiedBy }, elapsedMs, hostStallMs) {
-    const retryAfterMs = ghTokenLatch.noteUnavailable(outcome, cause);
-    if (consumer === "zizmor" && outcome === "transient") {
-        recordZizmorOfflineDegradation(`gh auth token probe ${cause}; running offline until the next zizmor start (retry allowed in ${Math.round(retryAfterMs / 1000)}s)`);
-    }
-    logAvailabilityDecision({
-        tool: consumer === "zizmor" ? "zizmor-gh-token" : "github-token",
-        verdict: "unavailable",
-        outcome,
-        cause,
-        elapsedMs,
-        latched: outcome !== "transient",
-        hostStallMs,
-        ...(retryAfterMs > 0 && { retryAfterMs }),
-        budgetMs: GH_TOKEN_PROBE_TIMEOUT_MS,
-        // Shared tail for both call paths; the caller carries whether ITS
-        // own verdict was a `classifyProbeFailure` passthrough or one of
-        // this module's own assertions (#2226 review F2).
-        classifiedBy,
-    });
-    return undefined;
-}
-/**
- * The degradation itself: zizmor is about to run offline
- * (known-vulnerable-actions/unpinned-uses/impostor-commit skipped) NOT
- * because the token is genuinely absent, but because a probe never got a
- * fair hearing (or is still cooling down from one). Make that legible
- * instead of letting the scan silently report "clean" (#1459's
- * security-silence shape).
- *
- * `incrementDegradationCount` (not the bare `recordDegradation`) per
- * AGENTS.md's degradation-telemetry convention: every offline spawn across a
- * cooldown cycle contributes to the exact group count, but the health view
- * retains only one updated entry per subject instead of five near-identical
- * lines.
- */
-function recordZizmorOfflineDegradation(reason) {
-    incrementDegradationCount({
-        kind: "mode-suppression",
-        subject: "zizmor",
-        reason,
-    });
-}
-/**
- * Resolve a GitHub token to put zizmor into ONLINE mode, so the audits that need
- * the GitHub API (e.g. `known-vulnerable-actions`, `unpinned-uses`,
- * `impostor-commit`) actually run instead of being silently skipped.
- *
- * zizmor's own precedence: `ZIZMOR_OFFLINE` forces offline regardless of any
- * token; otherwise any of `GH_TOKEN` / `GITHUB_TOKEN` / `ZIZMOR_GITHUB_TOKEN`
- * enables online mode. Those env vars already flow to the spawned server
- * (launchLSP merges `process.env`), so the ONLY gap we close here is the very
- * common case of a user who has authenticated the `gh` CLI but exported no
- * token — we derive one via `gh auth token`. Memoized per session through a
- * transient-aware latch (#1535, reset by `resetZizmorTokenAvailability` at
- * `session_start`): only a genuine answer (gh ran and returned an exit code,
- * or is proven absent) is remembered — a timeout/stall/unspawnable probe
- * expires on a cooldown and is re-derived on the next call, so a single slow
- * `gh` can't disable online audits for the rest of the session.
- *
- * Caveat callers should know: this only decides what token a NEW zizmor spawn
- * receives. A warm zizmor process already has its `GH_TOKEN` set at launch
- * time (`ZizmorServer.spawn`) and does not re-read it — recovering from a
- * transient failure means the NEXT spawn goes online, not the current one.
- */
-export async function resolveZizmorGitHubToken() {
-    // Respect an explicit offline request — never derive a token then.
-    if (process.env.ZIZMOR_OFFLINE)
-        return undefined;
-    return resolveGitHubToken(["ZIZMOR_GITHUB_TOKEN", "GH_TOKEN", "GITHUB_TOKEN"], { consumer: "zizmor" });
-}
-/**
- * Resolve a GitHub token for an API client. Explicit environment variables are
- * checked in the caller's order; when none is present, reuse the bounded,
- * session-reset `gh auth token` resolver above rather than spawning once per
- * request. The returned token is ephemeral and callers must not persist or
- * send it to non-API hosts.
- */
-export async function resolveGitHubToken(envKeys = ["GITHUB_TOKEN", "GH_TOKEN"], options = {}) {
-    const consumer = options.consumer ?? "github-api";
-    const fromEnv = envKeys.map((key) => process.env[key]).find(Boolean);
-    if (fromEnv)
-        return fromEnv;
-    const memo = ghTokenLatch.read();
-    if (memo !== null) {
-        if (consumer === "zizmor" &&
-            memo === false &&
-            ghTokenLatch.getOutcome() === "transient") {
-            // Served straight from the still-cooling latch: no new probe runs,
-            // so `deriveGhCliToken`'s own logging never fires. Without this, once
-            // the cooldown ladder crosses zizmor's own respawn cadence (bounded
-            // below `TRANSIENT_MAX_COOLDOWN_MS` via `ZIZMOR_TOKEN_MAX_COOLDOWN_MS`
-            // for exactly this reason) a spawn could start offline with nothing
-            // in latency.log or the degradation ledger to say so (#1535 review).
-            const cause = ghTokenLatch.getCause();
-            if (cause === null) {
-                // `getOutcome() === "transient"` is only ever set by `noteUnavailable`
-                // in the same call that sets `cause` — the two fields are written
-                // together, so this can't happen without the latch's own invariant
-                // breaking. Assert rather than fabricate a plausible-looking default
-                // (e.g. `?? "probe-timeout"`): a fake cause here would silently
-                // mislabel WHY the current cycle is offline, in exactly the spot
-                // this fix exists to make honest.
-                throw new Error("zizmor gh-token latch: transient outcome with no cause (invariant violated)");
-            }
-            const retryAfterMs = Math.max(0, ghTokenLatch.getRetryAtMs() - Date.now());
-            recordZizmorOfflineDegradation(`gh auth token still cooling down (${cause}); serving cached offline verdict, retry allowed in ${Math.round(retryAfterMs / 1000)}s`);
-            logAvailabilityDecision({
-                tool: "zizmor-gh-token",
-                verdict: "unavailable",
-                outcome: "transient",
-                cause,
-                elapsedMs: 0,
-                latched: false,
-                hostStallMs: 0,
-                ...(retryAfterMs > 0 && { retryAfterMs }),
-                budgetMs: GH_TOKEN_PROBE_TIMEOUT_MS,
-                // No probe ran here: the latch's own remembered cause is replayed
-                // as-is, so the call site is the one asserting it (#2209).
-                classifiedBy: "caller",
-            });
-        }
-        return memo ? cachedToken : undefined;
-    }
-    cachedToken = await deriveGhCliToken(consumer);
-    return cachedToken;
-}

package/node_modules/pi-lens/dist/i18n.js

@@ -1,69 +0,0 @@
-const translations = {
-    es: {
-        "lens.health.title": "🩺 SALUD DE PI-LENS",
-        "lens.health.crashes": "Fallos de pipeline (sesión): {count}",
-        "lens.health.files": "Archivos afectados: {count}",
-        "lens.health.topCrashFiles": "Archivos con más fallos:",
-        "lens.health.noLatency": "Aún no hay informes de latencia de dispatch.",
-        "lens.health.diagnosticsShown": "Diagnósticos mostrados: {count}",
-        "lens.health.autoFixed": "Auto-corregidos: {count}",
-        "lens.health.agentFixed": "Corregidos por el agente: {count}",
-        "lens.health.unresolved": "Arrastre sin resolver: {count}",
-        "lens.health.repeatOffenders": "Infractores repetidos:",
-        "lens.health.topNoisyRules": "Reglas más ruidosas:",
-    },
-    fr: {
-        "lens.health.title": "🩺 SANTÉ DE PI-LENS",
-        "lens.health.crashes": "Plantages du pipeline (session) : {count}",
-        "lens.health.files": "Fichiers concernés : {count}",
-        "lens.health.topCrashFiles": "Fichiers avec le plus de plantages :",
-        "lens.health.noLatency": "Aucun rapport de latence dispatch pour le moment.",
-        "lens.health.diagnosticsShown": "Diagnostics affichés : {count}",
-        "lens.health.autoFixed": "Auto-corrigés : {count}",
-        "lens.health.agentFixed": "Corrigés par l’agent : {count}",
-        "lens.health.unresolved": "Report non résolu : {count}",
-        "lens.health.repeatOffenders": "Récidives :",
-        "lens.health.topNoisyRules": "Règles les plus bruyantes :",
-    },
-    "pt-BR": {
-        "lens.health.title": "🩺 SAÚDE DO PI-LENS",
-        "lens.health.crashes": "Falhas do pipeline (sessão): {count}",
-        "lens.health.files": "Arquivos afetados: {count}",
-        "lens.health.topCrashFiles": "Arquivos com mais falhas:",
-        "lens.health.noLatency": "Ainda não há relatórios de latência do dispatch.",
-        "lens.health.diagnosticsShown": "Diagnósticos mostrados: {count}",
-        "lens.health.autoFixed": "Corrigidos automaticamente: {count}",
-        "lens.health.agentFixed": "Corrigidos pelo agente: {count}",
-        "lens.health.unresolved": "Pendências não resolvidas: {count}",
-        "lens.health.repeatOffenders": "Infratores recorrentes:",
-        "lens.health.topNoisyRules": "Regras mais ruidosas:",
-    },
-};
-let currentLocale = "en";
-export function initI18n(pi) {
-    pi.events?.emit?.("pi-core/i18n/registerBundle", {
-        namespace: "pi-lens",
-        defaultLocale: "en",
-        locales: translations,
-    });
-    pi.events?.emit?.("pi-core/i18n/requestApi", {
-        onReady: (api) => {
-            const next = api.getLocale?.();
-            if (isLocale(next))
-                currentLocale = next;
-            api.onLocaleChange?.((locale) => {
-                if (isLocale(locale))
-                    currentLocale = locale;
-            });
-        },
-    });
-}
-export function t(key, fallback, params = {}) {
-    const template = currentLocale === "en"
-        ? fallback
-        : (translations[currentLocale]?.[key] ?? fallback);
-    return template.replaceAll(/\{(\w+)\}/g, (_, name) => String(params[name] ?? `{${name}}`));
-}
-function isLocale(locale) {
-    return (locale === "en" || locale === "es" || locale === "fr" || locale === "pt-BR");
-}

package/node_modules/pi-lens/dist/mcp/build-staleness.js

@@ -1,124 +0,0 @@
-/**
- * Warm-server build-staleness detection (#535).
- *
- * The MCP server is long-lived (weeks, per #514/#256's warm/fresh doctrine) —
- * it loads its code ONCE at process start and never re-reads disk. A
- * `npm run build:dist` or a `git merge` that changes `dist/mcp/server.js` (or
- * the in-place `mcp/server.js` during dev) never reaches an already-running
- * warm server: it keeps serving the OLD schema/logic indefinitely. Dogfooding
- * #517 caught this live — a post-#517 rebuild still answered with the
- * pre-#517 `pilens_module_report` shape. That is the "plausible-but-wrong"
- * failure mode the #240/#511 honesty doctrine exists to prevent, not a mere
- * error — so the warm boundary must detect it and say so, never silently
- * serve stale.
- *
- * Design: capture an mtime "stamp" of the server's own entry file at process
- * start (module-level, once). On each call at the warm boundary, cheaply
- * re-stat the SAME file and compare. A full content hash was considered and
- * rejected for the hot path — mtime already changes on any rebuild/checkout
- * that touches the file (build tools + git both update it), and hashing the
- * whole bundle on every tool call is needless I/O; mtime is the same signal
- * class the #492 cross-process reader already trusts for freshness.
- *
- Pure/testable: `computeBuildStamp`/`checkStaleness` take an injectable stat
- * function so tests never touch the real filesystem or a real build.
- *
- * Throttle: re-stating on EVERY call would still be one syscall per call —
- * cheap, but under a tool-call burst (e.g. a batch of `pilens_symbol_search`)
- * that's needless repeated I/O for a condition that changes at most once per
- * rebuild. `StalenessGate` re-stats at most once per `checkIntervalMs`
- * (default 1000ms, matching the #492 precedent's "cheap per-call check, not
- * per-call I/O" shape) and reuses the last verdict in between.
- */
-import * as fs from "node:fs";
-const realStat = (targetPath) => {
-    try {
-        return fs.statSync(targetPath);
-    }
-    catch {
-        return undefined;
-    }
-};
-/**
- * Captures the startup stamp for `entryPath` (the server's own loaded module
- * file). Returns `undefined` if the entry can't be stat'd — e.g. running from
- * a bundle/packaging layout where the on-disk file legitimately doesn't exist
- * at that path; in that case staleness checking degrades to "always fresh"
- * rather than false-flagging every call.
- */
-export function computeBuildStamp(entryPath, stat = realStat) {
-    const info = stat(entryPath);
-    if (!info)
-        return undefined;
-    return { entryPath, mtimeMs: info.mtimeMs, size: info.size };
-}
-/**
- * One-shot comparison: re-stats `stamp.entryPath` and compares against the
- * startup mtime AND size (#2300 — a same-mtime-bucket rebuild that changes
- * the bundle's length is otherwise invisible). A failed re-stat (file briefly
- * missing mid-rebuild-write, or an installed-package layout) is treated as
- * NOT stale — we only ever flag a build change we can positively observe,
- * never assume one from an I/O hiccup (false positives would make every tool
- * call route to fresh, which defeats the warm server's entire purpose).
- */
-export function checkStaleness(stamp, stat = realStat) {
-    const info = stat(stamp.entryPath);
-    if (!info)
-        return { stale: false, stamp, currentMtimeMs: undefined };
-    return {
-        stale: info.mtimeMs !== stamp.mtimeMs || info.size !== stamp.size,
-        stamp,
-        currentMtimeMs: info.mtimeMs,
-    };
-}
-/**
- * Mtime-gated staleness gate for the hot call path (mirrors the #492
- * cross-process reader's "one `fs.stat`, cache the verdict" shape): a burst
- * of tool calls within `checkIntervalMs` of each other costs exactly ONE
- * `fs.stat`, not one per call.
- */
-export class StalenessGate {
-    stamp;
-    checkIntervalMs;
-    stat;
-    now;
-    lastCheckedAt;
-    lastVerdict = false;
-    constructor(stamp, options = {}) {
-        this.stamp = stamp;
-        this.checkIntervalMs = options.checkIntervalMs ?? 1000;
-        this.stat = options.stat ?? realStat;
-        this.now = options.now ?? Date.now;
-    }
-    /** True when the warm server's loaded code is known to be stale. */
-    isStale() {
-        if (!this.stamp)
-            return false; // no stamp captured — never flag
-        const nowMs = this.now();
-        if (this.lastCheckedAt !== undefined &&
-            nowMs - this.lastCheckedAt < this.checkIntervalMs) {
-            return this.lastVerdict;
-        }
-        this.lastCheckedAt = nowMs;
-        this.lastVerdict = checkStaleness(this.stamp, this.stat).stale;
-        return this.lastVerdict;
-    }
-}
-/** Env kill switch: `PI_LENS_WARM_STALENESS_CHECK=0` disables the whole guard. */
-export function stalenessCheckEnabled(env = process.env) {
-    return env.PI_LENS_WARM_STALENESS_CHECK !== "0";
-}
-/**
- * Standard advisory text appended when a tool result was served through the
- * fresh-fork route because the warm build was stale.
- */
-export const STALE_SERVED_BY_FRESH = "fresh (warm code stale — restart the Claude session to re-warm)";
-/**
- * Standard advisory text for tools that CANNOT be routed to a fresh fork
- * (they depend on warm-process-only state: the in-memory review graph, the
- * word-index cache, the warm LSP fleet) — honest degrade instead of routing.
- */
-export const STALE_WARN_ONLY = "warmCodeStale: this result was served by the warm server's loaded code, " +
-    "which is older than the on-disk build (a rebuild or merge landed after " +
-    "this session started). Restart the Claude session to re-warm, or use " +
-    "pilens_rebuild + a tool that supports mode=fresh if available.";