@herbertgao/pi-extensions 2026.10.1 → 2026.10.3

package/node_modules/pi-lens/dist/clients/single-flight.js

@@ -1,158 +0,0 @@
-/**
- * `singleFlight` — at most one execution per key, clear owned by the primitive.
- *
- * Ten sites hand-roll the same five lines: look up a key in a promise map,
- * return the existing promise if there is one, otherwise start the work and
- * delete the key in a `finally`. The class has a measured bug yield, and every
- * bug is in the part the call site wrote rather than the part it meant:
- *
- * - #1690: the `finally`-clear was never exercised, so its regression test
- *   passed with the clear deleted. A memo short-circuit above the in-flight
- *   check meant the second call never reached it.
- * - #1674: the `finally` deleted the key unconditionally, so a probe settling
- *   after a session reset evicted the REPLACEMENT probe a new session had
- *   already started for the same key.
- * - #1687: the trailing-rerun bit shipped unpinned — the test asserted "at most
- *   two passes" one-sidedly, which a coalescer that dropped the rerun entirely
- *   also satisfies.
- * - #1722: an inner latch was vacuous and its own mutation matrix deleted it.
- *
- * This module owns those four guards once. The API is the INTERSECTION of the
- * ten sites, not a superset: share, clear-in-finally, optional trailing-rerun
- * coalescing, optional generation check. Anything a single site needs stays at
- * that site.
- *
- * LIFECYCLE: the primitive owns no module state. `createSingleFlight` returns
- * a closure, so each registry's lifetime is its OWNER's — an instance field
- * lives as long as the instance, a module-level const as long as the process.
- * That keeps the session-state question where it belongs, at the owner, and
- * `clear()` is the seam an owner's reset calls. The two converted sites hold
- * instance fields, exactly as their `ensureInFlight` fields did, so neither
- * one's session-state answer changes.
- *
- * Teardown of a flight that never settles is the owner's question, and neither
- * converted site answers it today: a wedged probe holds its key until the
- * process ends, exactly as its `ensureInFlight` field did on master. This
- * primitive does not make that worse and does not fix it; an owner that needs a
- * deadline wraps `fn` in one before handing it over.
- *
- * The generation hook is deliberately thin — a `() => number` the primitive
- * reads at start and again at completion. The standalone generation-guard
- * primitive is #1754's; when it lands, this stays a callback and composes with
- * it rather than absorbing it.
- */
-/**
- * Create a keyed single-flight registry.
- *
- * Sites with only one thing to dedupe pass a constant key; the map costs one
- * entry and buys the same four guards a single slot would have to re-derive.
- */
-export function createSingleFlight(options = {}) {
-    const { generation: readGeneration, coalesceTrailing = false } = options;
-    const flights = new Map();
-    const currentGeneration = () => readGeneration?.() ?? 0;
-    /**
-     * Release `key`, but ONLY if this exact flight still owns it.
-     *
-     * This is the #1674 eviction direction: a flight that settles late must not
-     * delete the entry a SUCCESSOR already installed under the same key. The
-     * successor may exist because a reset cleared the map and a new caller
-     * arrived, or because the generation moved and `run` superseded the stale
-     * flight. Identity answers both, so identity is the only check here.
-     *
-     * `runner-helpers.ts:1058` writes this as a generation check AND an identity
-     * check. The mutation matrix says the generation half of that pair kills no
-     * test: whenever it would fire, identity has already returned. The pair is
-     * harmless there and not worth churning; it is not worth copying either.
-     */
-    const release = (key, flight) => {
-        if (flights.get(key) !== flight)
-            return;
-        flights.delete(key);
-    };
-    const run = (key, fn) => {
-        const existing = flights.get(key);
-        // Sharing requires BOTH a running flight and a matching generation. A
-        // flight from an earlier generation answers a question a session reset
-        // already invalidated, so this caller falls through and starts a fresh
-        // one; the `flights.set` below replaces the stale entry outright, and the
-        // stale flight's own `release` then finds a foreign entry and leaves it
-        // alone. There is deliberately no explicit delete for the superseded
-        // entry: nothing reads the map between here and that `set`, so a delete
-        // would be a dead statement dressed as a guard.
-        if (existing && existing.generation === currentGeneration()) {
-            // A mid-flight request in the SAME generation. With coalescing it earns
-            // exactly one trailing pass no matter how many such requests arrive;
-            // without it, it shares the running pass. Either way it never starts a
-            // second flight.
-            if (coalesceTrailing)
-                existing.rerunRequested = true;
-            return existing.promise;
-        }
-        // The shared handle is built BEFORE `fn` runs and BEFORE the map entry is
-        // published, so the entry a reentrant caller finds always carries a real
-        // pending promise. The hand-rolled sites all publish the entry after
-        // starting the work, which leaves a synchronous window where a reentrant
-        // call starts a second flight for the same key.
-        let settle;
-        let fail;
-        const promise = new Promise((resolve, reject) => {
-            settle = resolve;
-            fail = reject;
-        });
-        const flight = {
-            promise,
-            generation: currentGeneration(),
-            rerunRequested: false,
-        };
-        const chain = async () => {
-            let result = await fn();
-            // KNOWN INTERACTION, `coalesceTrailing` + `generation`: a flight that
-            // gets superseded mid-pass with its rerun bit already set still runs
-            // that one trailing pass, because the bit lives on the flight and no
-            // caller can reach in to clear it. So a reset can cost ONE extra pass
-            // of pre-reset work, whose result nothing reads — the superseded
-            // promise has no callers left that a live caller depends on.
-            //
-            // Left as-is rather than fixed blind: no site uses both options today,
-            // so any fix would be untested guesswork about which behavior a real
-            // caller wants. A reset arguably SHOULD abandon the pending rerun; it
-            // arguably should also let a pass that is already half-done finish.
-            // The third site to turn this combination on decides, and adds the
-            // test that pins whichever answer it picks.
-            //
-            // Only reruns requested WHILE a pass was running count. Clearing the bit
-            // before each pass — never after — is what pins the coalescing to "at
-            // most one trailing rerun": a request that arrives during pass 2 sets
-            // the bit again and gets pass 3, which is still one trailing pass per
-            // burst-that-overlaps-a-pass, not one per request.
-            while (flight.rerunRequested) {
-                flight.rerunRequested = false;
-                result = await fn();
-            }
-            return result;
-        };
-        flights.set(key, flight);
-        // Release runs on BOTH settlements — a rejected `fn` must not wedge the
-        // key, which is #1690's leak. Release and settle happen in the same
-        // synchronous step, so their order relative to each other is not
-        // observable; what matters is that both run before any awaiting caller's
-        // continuation. A rejection also abandons a pending rerun: re-running
-        // work that just threw is a retry policy, and a retry policy belongs to
-        // the caller that knows what the work was.
-        chain().then((value) => {
-            release(key, flight);
-            settle(value);
-        }, (error) => {
-            release(key, flight);
-            fail(error);
-        });
-        return flight.promise;
-    };
-    return {
-        run,
-        has: (key) => flights.has(key),
-        size: () => flights.size,
-        clear: () => flights.clear(),
-    };
-}

package/node_modules/pi-lens/dist/clients/situational-tool-telemetry.js

@@ -1,108 +0,0 @@
-import { logExtension } from "./extension-log.js";
-import { TOOL_REGISTRY } from "./tool-config.js";
-const situationalTools = TOOL_REGISTRY.filter((tool) => "situational" in tool && tool.situational === true).map((tool) => tool.name);
-const situationalToolSet = new Set(situationalTools);
-const activated = new Set();
-const called = new Set();
-let sessionStarted = false;
-let emitted = false;
-// MCP-only connection-terminal latch: once the connection's row is recorded,
-// repeated initialize/tool-call starts must not reopen the session.
-let connectionEnded = false;
-// Which host owns the open session; only MCP may arm connectionEnded. Pi state
-// belongs to the conversation and survives in-process session rebuilds.
-let sessionHost = "mcp";
-function observe(set, name) {
-    if (situationalToolSet.has(name)) {
-        set.add(name);
-    }
-}
-function clearObservations() {
-    activated.clear();
-    called.clear();
-}
-export function observeSituationalToolActivation(names) {
-    for (const name of names)
-        observe(activated, name);
-}
-export function observeSituationalToolCall(name) {
-    observe(called, name);
-}
-export function resetSituationalToolTelemetry() {
-    // A live telemetry session owns its observation sets: both hosts open the
-    // session (which resets the sets) BEFORE handleSessionStart runs, and a
-    // repeated MCP session_start refresh legitimately re-runs that handler —
-    // clearing here would wipe the calls recorded before the refresh. This
-    // registered reset therefore only acts when no session is open.
-    if (sessionStarted)
-        return;
-    clearObservations();
-    emitted = false;
-}
-/**
- * Open the telemetry session for one host.
- *
- * Pi owns one observation set per session file. A shutdown with a
- * `targetSessionFile` emits the conversation that is ending before the host
- * opens the replacement. Reload keeps the same file, so its factory rebuild
- * does not split the row. A process restart opens an empty set and recovers nothing:
- * pi-lens's own activation memory (`rememberedLazyTools` in `index.ts`) is
- * empty in a new process, so the restore deactivates every situational tool,
- * and the host's restored active set is evidence of REGISTRATION, not of
- * model activation (#2866 review F1). MCP remains connection-scoped.
- */
-export function startSituationalToolTelemetrySession(host) {
-    if (host === "mcp") {
-        if (connectionEnded)
-            return;
-        if (sessionStarted)
-            return;
-        sessionHost = "mcp";
-        clearObservations();
-        emitted = false;
-        sessionStarted = true;
-        return;
-    }
-    if (sessionStarted) {
-        sessionHost = "pi";
-        return;
-    }
-    sessionHost = "pi";
-    clearObservations();
-    emitted = false;
-    sessionStarted = true;
-}
-/** Emit the one session-end row and make repeated shutdown calls harmless. */
-export function endSituationalToolTelemetry() {
-    if (!sessionStarted)
-        return;
-    emitSituationalDeadWeight();
-    if (sessionHost === "mcp")
-        connectionEnded = true;
-    clearObservations();
-    emitted = false;
-    sessionStarted = false;
-}
-export function emitSituationalDeadWeight() {
-    if (emitted)
-        return;
-    emitted = true;
-    const used = new Set([...activated, ...called]);
-    logExtension({
-        subsystem: "tools",
-        level: "debug",
-        message: "situational tool dead weight",
-        metadata: {
-            tools: situationalTools.filter((name) => !used.has(name)),
-        },
-    });
-}
-/** Test-only view of the module's state, for the #1635 session-state registry probe. */
-export function _getSituationalToolTelemetryStateForTests() {
-    return {
-        activated: activated.size,
-        called: called.size,
-        emitted,
-        sessionStarted,
-    };
-}

package/node_modules/pi-lens/dist/clients/skills-resolver.js

@@ -1,141 +0,0 @@
-/**
- * Resolves the skills directory the `resources_discover` handler (#205)
- * registers, and reports the one condition that pi previously loaded with NO
- * visible signal: `<packageRoot>/skills` is absent, unreadable, or holds no
- * skill pi's own loader would find (#2626).
- *
- * `resolvePackagePath(import.meta.url, "skills")`-equivalent resolution
- * (`clients/package-root.ts`'s `getPackageRoot`) is correct for both the
- * source and compiled `dist/` layouts — it walks up from the loaded entry
- * file to the nearest `package.json`. It goes wrong silently, not loudly,
- * when that walk lands somewhere with no `skills/` beside it: `skills/`
- * missing from an installed package, or the entry file copied out of the
- * package tree by a managed extension cache so the nearest `package.json`
- * is the cache's own. Either way `resources_discover` used to hand pi a
- * path that does not exist, `pi` registered zero skills, and nothing — no
- * extension error, no stderr line — said so (investigated on #2587).
- *
- * #2626 review round 2, F1: the FIRST version of this fix inverted the
- * acceptance criterion — it returned `[]` (no skills registered) whenever
- * its own predicate disagreed with pi's real loader, which is worse than
- * the bug it fixed on every layout the predicate got wrong (dropping skills
- * pi WOULD have loaded, a regression vs. pre-fix `master`). The acceptance
- * criteria ask for a RECORD, never a changed return value: this module
- * returns `[skillsDir]` UNCONDITIONALLY, exactly like the pre-fix handler —
- * pi's own `loadSkills`/`collectSkillEntries` already treat a nonexistent
- * path as zero skills from that entry, gracefully, so handing it a path
- * that turns out to be empty is exactly as safe as `master`'s behavior
- * always was. The health check below is PURELY observational.
- *
- * #2636 review F4: the ENOENT/EACCES classification shell below used to be
- * hand-rolled here, character-identical to the ast-grep/tree-sitter sites
- * #2636 fixed for the same silent-zero shape — now shared via
- * `bundled-resource-health.ts`, with `scanEntriesForSkills` supplied as this
- * module's own "what counts as found" predicate.
- */
-import * as path from "node:path";
-import { fileURLToPath } from "node:url";
-import * as fs from "node:fs";
-import { scanEntriesForSkills } from "../scripts/lib/skills-predicate.mjs";
-import { classifyBundledResourceDir, describeBundledResourceHealth, reportBundledResourceDirHealth, } from "./bundled-resource-health.js";
-import { logLatency } from "./latency-logger.js";
-import { getPackageRoot } from "./package-root.js";
-/** The ledger kind this module records under (`clients/degradation-ledger.ts`). */
-const SKILLS_DIR_MISSING_KIND = "skills-dir-missing";
-/**
- * Read `skillsDir` and classify it, sharing `classifyBundledResourceDir`'s
- * ENOENT/EACCES/empty shell but counting pi-LOADABLE skill entry points
- * (`scanEntriesForSkills`), not a bare directory listing — a `skills/`
- * holding only a stray `.gitkeep` must read "empty", not "healthy".
- */
-function checkSkillsHealth(skillsDir) {
-    return classifyBundledResourceDir(skillsDir, (dir) => {
-        const entries = fs.readdirSync(dir, { withFileTypes: true });
-        return scanEntriesForSkills(dir, entries, true).length;
-    });
-}
-/**
- * Resolve the skill path for `resources_discover`. ALWAYS returns
- * `[skillsDir]` (see the module doc for why — F1). When `skillsDir` is
- * absent, unreadable, or holds no skill pi's loader would find, records ONE
- * bounded `skills-dir-missing` degradation and a single `notifyUserDegradation`
- * warning, both naming the resolved path and the entry file's directory.
- *
- * Either way, one `skills_resolved` phase/latency record is written so an
- * empty ledger (no `skills-dir-missing` row) is distinguishable from
- * "`resources_discover` never ran at all" (#2626 review F5) — the SAME
- * silent-zero shape one level up the call stack.
- */
-export function resolveSkillPaths(importMetaUrl) {
-    const packageRoot = getPackageRoot(importMetaUrl);
-    const skillsDir = path.join(packageRoot, "skills");
-    const health = checkSkillsHealth(skillsDir);
-    logLatency({
-        type: "phase",
-        phase: "skills_resolved",
-        filePath: skillsDir,
-        durationMs: 0,
-        metadata: {
-            status: health.status,
-            entryCount: health.status === "healthy" ? health.entryCount : 0,
-        },
-    });
-    if (health.status !== "healthy") {
-        const entryDir = path.dirname(fileURLToPath(importMetaUrl));
-        const healthDescription = describeBundledResourceHealth(health, skillsDir, `no SKILL.md (or loadable .md) found under ${skillsDir}`);
-        // #3175: two DIFFERENT strings, not one `reason` reused for both sinks
-        // as this used to be.
-        //
-        // `notifyReason` (uncapped — `notifyUserDegradation` never truncates)
-        // keeps the full, natural description: classification first, then
-        // where the entry file that triggered this lookup was loaded from.
-        const notifyReason = `${healthDescription} (entry loaded from ${entryDir})`;
-        // `ledgerReason` is built from a SHORT, path-free classification tag
-        // instead of `healthDescription`, because the LEDGER's `reason` field
-        // IS capped (`truncateForLedger`, `LEDGER_FIELD_MAX` = 200 chars,
-        // head-preserving — see `ledger-bounds.ts`) and `healthDescription`
-        // repeats `skillsDir` in full — already recorded, untruncated, in
-        // `subject` below whenever it's under the cap on its own. A
-        // managed-cache `skillsDir` plus this entry's `entryDir` sharing one
-        // long root routinely sums past 200 chars (#3175: TMPDIR ~60+ chars is
-        // a real dry-roll and CI-lane shape, not a pathological one); a
-        // head-preserving cap over the OLD concatenation (dir-bearing text
-        // first, `entryDir` last) then kept the redundant path and dropped the
-        // one fact nothing else records — which entry file's directory
-        // triggered this lookup (#2587's "entry file copied out of the
-        // package tree" case is exactly this). Simply swapping that order is
-        // NOT enough: `healthDescription`'s own `unreadable` branch reads
-        // `cannot read ${dir} (${fsErrorCode})`, so `dir` sitting in the
-        // MIDDLE of the classification text can still push `fsErrorCode`
-        // itself off the cap once `entryDir` leads. Dropping the redundant
-        // path from the ledger's copy entirely — keeping only the
-        // classification word/code — removes that squeeze instead of moving
-        // it, and leaves comfortable room (entry directories under roughly
-        // 150 chars fit whole) for every managed-cache/npm-install layout
-        // observed so far.
-        const classification = health.status === "unreadable"
-            ? `cannot read (${health.fsErrorCode})`
-            : health.status === "empty"
-                ? "no SKILL.md found"
-                : "no such directory";
-        const ledgerReason = `${classification} (entry loaded from ${entryDir})`;
-        // #2626 review F3: the notify-once gate previously re-derived "have we
-        // already recorded this" by scanning `getDegradationSummary()` and
-        // comparing the RAW `skillsDir` against subjects the ledger stores
-        // `truncateForLedger`-ed — a mismatch on any subject over
-        // `LEDGER_FIELD_MAX` (200 chars, an ordinary length for a managed-cache
-        // path) renotified on every call. `reportBundledResourceDirHealth`
-        // reads `incrementDegradationCount`'s own return value for the rising
-        // edge, computed after the SAME truncation the ledger stores by, so
-        // there is no separate key to keep in sync.
-        // #2636 review round 2, F1: the shipped notify sentence ("registers
-        // zero skills") is user-visible product text #2626 chose deliberately
-        // — it names the exact SYMPTOM this whole issue exists to surface, so
-        // the shared helper's generic "<label> unavailable" template must
-        // never silently replace it. Passed explicitly rather than inferred
-        // from `label` so this stays a per-caller decision, not a convention
-        // the next caller has to remember.
-        reportBundledResourceDirHealth(SKILLS_DIR_MISSING_KIND, skillsDir, health, "skills", ledgerReason, `pi-lens: registers zero skills — ${notifyReason}.`);
-    }
-    return [skillsDir];
-}

package/node_modules/pi-lens/dist/clients/slow-fs.js

@@ -1,138 +0,0 @@
-/**
- * Slow-filesystem detection (#462).
- *
- * On WSL 9p mounts (`/mnt/c/...`), synchronous file-tree walks freeze the pi
- * TUI: each `stat`/`readdir` costs ~1.3ms over 9p vs ~17µs native (measured
- * anchor on a Windows host running WSL2 — a 75x slowdown). A 5,000-file sync
- * walk on 9p costs ~6.5s of stat time alone, all on the event loop.
- *
- * This module classifies the workspace by MEASUREMENT, not path shape (no
- * `/mnt/` string-sniffing — that misses drvfs/NFS/SMB and false-positives on
- * fast 9p configurations). A cheap latency probe times a handful of
- * `fs.statSync` calls under the project root at session start; if the median
- * exceeds a threshold, the workspace is flagged "slow FS" for the rest of the
- * process, and callers route sync tree walks to reduced caps / async
- * collectors instead.
- *
- * Escape hatches:
- *   - `PI_LENS_ALLOW_SLOW_FS_SCAN=1` — disable slow-FS mode entirely (full
- *     normal behavior even when the probe would flag the FS as slow).
- *   - `PI_LENS_FORCE_SLOW_FS=1` — force slow-FS mode on regardless of the
- *     probe (testing/CI, or a user who knows their FS is slow but the probe
- *     under-fires).
- *   - `PI_LENS_SLOW_FS_THRESHOLD_US` — override the median-microseconds
- *     threshold (default 500).
- *
- * Follows the lazy-memoized-config house style (see `runtime-config.ts`): env
- * values are read lazily at call time, not module load, and `Number(...)` is
- * gated through `Number.isFinite` before use.
- */
-import { BoundedLruCache } from "./bounded-cache.js";
-import * as fs from "node:fs";
-import * as path from "node:path";
-import { toPositiveFinite } from "./env-utils.js";
-import { normalizeFilePath } from "./path-utils.js";
-/** Default median-stat threshold (microseconds) above which a workspace is
- * classified as slow FS. Measured anchor: 9p ≈ 1300µs/stat, native NTFS/ext4
- * < 200µs/stat — 500µs sits well between the two. */
-export const DEFAULT_SLOW_FS_THRESHOLD_US = 500;
-/** Cap on how many entries the probe stats — keeps the probe itself cheap
- * (15 stats x ~1.3ms worst case is still well under 50ms). */
-const PROBE_SAMPLE_CAP = 15;
-function resolveThresholdMicros() {
-    const envValue = toPositiveFinite(process.env.PI_LENS_SLOW_FS_THRESHOLD_US);
-    return envValue > 0 ? envValue : DEFAULT_SLOW_FS_THRESHOLD_US;
-}
-function median(values) {
-    if (values.length === 0)
-        return 0;
-    const sorted = [...values].sort((a, b) => a - b);
-    const mid = Math.floor(sorted.length / 2);
-    return sorted.length % 2 === 0
-        ? (sorted[mid - 1] + sorted[mid]) / 2
-        : sorted[mid];
-}
-/**
- * Time up to `PROBE_SAMPLE_CAP` `fs.statSync` calls on entries directly under
- * `rootDir` and return the median per-stat cost in microseconds. Wrapped
- * entirely in try/catch: any failure (missing dir, permission error, empty
- * dir) yields `slow: false` — a probe failure must never itself degrade
- * behavior.
- */
-export function probeSlowFs(rootDir) {
-    try {
-        const resolvedRoot = path.resolve(rootDir);
-        const entries = fs.readdirSync(resolvedRoot).slice(0, PROBE_SAMPLE_CAP);
-        if (entries.length === 0) {
-            return { slow: false, medianStatMicros: 0, samples: 0 };
-        }
-        const samplesMicros = [];
-        for (const entry of entries) {
-            const fullPath = path.join(resolvedRoot, entry);
-            const startedAt = process.hrtime.bigint();
-            try {
-                fs.statSync(fullPath);
-            }
-            catch {
-                continue; // vanished / permission-denied entry — skip, don't count
-            }
-            const elapsedNs = process.hrtime.bigint() - startedAt;
-            samplesMicros.push(Number(elapsedNs) / 1000);
-        }
-        if (samplesMicros.length === 0) {
-            return { slow: false, medianStatMicros: 0, samples: 0 };
-        }
-        const medianStatMicros = median(samplesMicros);
-        const threshold = resolveThresholdMicros();
-        return {
-            slow: medianStatMicros > threshold,
-            medianStatMicros,
-            samples: samplesMicros.length,
-        };
-    }
-    catch {
-        return { slow: false, medianStatMicros: 0, samples: 0 };
-    }
-}
-/** Process-lifetime memo of the slow-FS verdict, keyed by normalized cwd so
- * `/` vs `\` inputs share one entry (see path-key invariant tests). */
-const slowFsVerdictCache = new BoundedLruCache(32);
-/**
- * Resolve (and memoize) the slow-FS verdict for `cwd`. Resolution order:
- *   1. `PI_LENS_ALLOW_SLOW_FS_SCAN=1` — kill switch, always false.
- *   2. `PI_LENS_FORCE_SLOW_FS=1` — always true, probe skipped entirely.
- *   3. Measured probe (memoized per cwd for the process lifetime).
- */
-export function getSlowFsVerdict(cwd) {
-    if (process.env.PI_LENS_ALLOW_SLOW_FS_SCAN === "1") {
-        return { slow: false, medianStatMicros: 0, samples: 0 };
-    }
-    if (process.env.PI_LENS_FORCE_SLOW_FS === "1") {
-        return { slow: true, medianStatMicros: 0, samples: 0 };
-    }
-    const key = normalizeFilePath(path.resolve(cwd));
-    const cached = slowFsVerdictCache.get(key);
-    if (cached)
-        return cached;
-    const result = probeSlowFs(cwd);
-    slowFsVerdictCache.set(key, result);
-    return result;
-}
-/** Convenience predicate for call sites that only need the boolean verdict. */
-export function isSlowFs(cwd) {
-    return getSlowFsVerdict(cwd).slow;
-}
-/** Test-only: clear the memoized verdict cache so a subsequent call re-probes
- * (or re-reads the env kill switches). */
-export function _resetSlowFsForTests() {
-    slowFsVerdictCache.clear();
-}
-/** Reduced sync `maxFiles` cap applied in slow-FS mode (env override is
- * deliberately NOT supported per #462's design — this is a safety clamp, not
- * a tuning knob). */
-export const SLOW_FS_REDUCED_MAX_FILES = 500;
-/** Human-readable degradation notice surfaced once per session when slow-FS
- * mode engages, so a user never sees a silently-empty scan result. */
-export function slowFsDegradationNotice() {
-    return "slow filesystem detected (set PI_LENS_ALLOW_SLOW_FS_SCAN=1 to override)";
-}