@aragon-agent/cli 0.6.47 → 0.6.48

package/dist/ui/win-vt-force.js

@@ -1,237 +0,0 @@
-/**
- * Turn `ENABLE_VIRTUAL_TERMINAL_INPUT` on for THIS console, from outside Node
- * (shift-tab-mode-toggle-still-dead-on-windows, C1-M1).
- *
- * ASCII ONLY - this tree is inside the glyph scanner's scope.
- *
- * `win-vt-input.ts` answers "will this console ever deliver `CSI Z`?". This
- * module answers "can we MAKE it deliver one?", and the measured answer is yes.
- * The bit is a property of the console input buffer, not of Node, so any process
- * attached to the same console can set it - and libuv's pre-22.17 translator
- * forwards whatever characters the console generates, `ESC` `[` `Z` included.
- * On Node 20.19.0, in one run, one injected `Shift+Tab` went from `09` to
- * `1b 5b 5a` the instant an outside process OR-ed `0x0200` in (analysis section
- * 3.2; raw probe data under `docs/diagnoses/.../repro/`).
- *
- * Node ships no FFI, so the outside process is `powershell.exe` calling
- * `SetConsoleMode` through P/Invoke. Measured cost end to end: 722 ms, roughly
- * 280 ms of process start plus 300 ms of `Add-Type` compiling C# at run time
- * (analysis section 3.4). That is the whole price of not adding a native
- * dependency, and it is paid ONCE, only on an affected Windows console.
- *
- * THREE TRAPS ARE ENCODED HERE, all of them measured rather than imagined:
- *
- *  1. `windowsHide: true` maps to `CREATE_NO_WINDOW`, which hands the child its
- *     OWN console. The helper then reads, sets and reports success against a
- *     console nobody is typing into: exit code 0, `SetConsoleMode` true, log
- *     clean, and no effect whatsoever - indistinguishable from "the fix was
- *     never written" (analysis section 3.5). Hence `windowsHide: false`.
- *  2. The helper must open `CONIN$` with `CreateFileW`, never
- *     `GetStdHandle(STD_INPUT_HANDLE)`: it is spawned with stdin `ignore`, so
- *     its standard input is `NUL`. Sharing the real stdin instead is not an
- *     option - that handle is being reconfigured underneath it.
- *  3. The `before` mode is the ONLY signal that distinguishes trap 1 from
- *     success, so the helper reports it and `decideVtForceOutcome` checks it.
- *     The check is a POSITIVE bitmask ("is this console already in raw mode"),
- *     not `before !== 0x01F7`: that number is one machine's default and varies
- *     with QuickEdit, with the host, and with a user who already turned VT input
- *     on. A magic-number comparison passes silently on the first machine whose
- *     default happens to differ, which puts trap 1 straight back (review R-3).
- *
- * WHAT UNDOES IT: `setRawMode(false)`. libuv rewrites the whole console mode on
- * every raw-mode transition and its pre-22.17 path does not know about this bit,
- * so one transition clears it (analysis section 3.3). That is why the caller
- * must raise raw mode BEFORE calling this, and it is also the entire restore
- * path - the bit outlives the process otherwise, and neither Windows nor the
- * console clears it (analysis section 3.5b).
- *
- * FAILURE IS ALWAYS GRACEFUL. Constrained Language Mode disables `Add-Type`
- * outright, and enterprise fleets ship it by policy - exactly the "another PC"
- * population this bug is about. Every failure returns `ok: false` with a reason
- * for the log and nothing else happens; the alternate mode-toggle key
- * (`MODE_TOGGLE_KEYS.fallback`) is the rung below that needs none of this.
- */
-import { spawnSync } from 'node:child_process';
-import { existsSync } from 'node:fs';
-import { join } from 'node:path';
-import process from 'node:process';
-/** Console input mode bits (`consoleapi.h`). */
-export const ENABLE_PROCESSED_INPUT = 0x0001;
-export const ENABLE_LINE_INPUT = 0x0002;
-export const ENABLE_ECHO_INPUT = 0x0004;
-export const ENABLE_WINDOW_INPUT = 0x0008;
-export const ENABLE_VIRTUAL_TERMINAL_INPUT = 0x0200;
-/**
- * The three bits a cooked console has and a raw one does not.
- *
- * This is the fingerprint of "libuv has already put this console in raw mode",
- * and it is what tells the two measured samples apart: `0x0008` (the CLI's own
- * console, raw) versus `0x01F7` (a fresh `CREATE_NO_WINDOW` console, cooked).
- */
-export const COOKED_INPUT_BITS = ENABLE_PROCESSED_INPUT | ENABLE_LINE_INPUT | ENABLE_ECHO_INPUT;
-export function isRawConsoleMode(mode) {
-    return (mode & COOKED_INPUT_BITS) === 0;
-}
-/**
- * The PowerShell side, as a string.
- *
- * A LITERAL HERE-STRING (`@'` ... `'@`) around the C# so PowerShell expands
- * nothing inside it, and `'CONIN$'` in single quotes for the same reason - the
- * `$` is part of the device name, not a variable.
- *
- * Shipped inline rather than as a `.ps1` next to the build output, and that is a
- * capability difference rather than tidiness: ExecutionPolicy blocks script
- * FILES and does not apply to `-EncodedCommand`, so a locked-down machine - the
- * population this bug keeps landing on - can still run it. It also removes the
- * "where did my file go after packaging" class of failure entirely.
- */
-export function buildHelperScript() {
-    return [
-        "$ErrorActionPreference = 'Stop'",
-        'try {',
-        '  Add-Type -TypeDefinition @' + "'",
-        'using System;',
-        'using System.Runtime.InteropServices;',
-        'public static class AragonVtInput {',
-        '  [DllImport("kernel32.dll", SetLastError=true, CharSet=CharSet.Unicode)]',
-        '  public static extern IntPtr CreateFileW(string name, uint access, uint share,',
-        '    IntPtr sec, uint disp, uint flags, IntPtr tmpl);',
-        '  [DllImport("kernel32.dll", SetLastError=true)]',
-        '  public static extern bool GetConsoleMode(IntPtr h, out uint mode);',
-        '  [DllImport("kernel32.dll", SetLastError=true)]',
-        '  public static extern bool SetConsoleMode(IntPtr h, uint mode);',
-        '}',
-        "'" + '@',
-        '} catch { Write-Output "error=addtype"; exit 3 }',
-        // GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, OPEN_EXISTING.
-        //
-        // DECIMAL, NOT `0xC0000000`. Windows PowerShell 5.1 - which is what
-        // `resolvePowerShellExe` finds, on every machine - parses a hex literal with
-        // the high bit set as a SIGNED Int32, so `[uint32]0xC0000000` throws
-        // "Cannot convert value -1073741824" before `CreateFileW` is ever reached.
-        // With `$ErrorActionPreference = 'Stop'` that is a terminating error outside
-        // the `try`, so the helper dies with no `before=` line and the whole feature
-        // degrades to `no_before` on 100% of consoles - working code, never once
-        // executed. Round 2's own probe helper carries the same comment.
-        "$h = [AragonVtInput]::CreateFileW('CONIN$', ([uint32]2147483648 -bor [uint32]1073741824)," +
-            ' [uint32]3, [IntPtr]::Zero, [uint32]3, [uint32]0, [IntPtr]::Zero)',
-        'if ($h -eq [IntPtr]::Zero -or $h.ToInt64() -eq -1) { Write-Output "error=conin"; exit 4 }',
-        '$before = [uint32]0',
-        'if (-not [AragonVtInput]::GetConsoleMode($h, [ref]$before)) {',
-        '  Write-Output "error=getmode"; exit 5',
-        '}',
-        'Write-Output ("before=0x{0:X4}" -f $before)',
-        'if (-not [AragonVtInput]::SetConsoleMode($h, ($before -bor 0x0200))) {',
-        '  Write-Output "error=setmode"; exit 6',
-        '}',
-        '$after = [uint32]0',
-        'if (-not [AragonVtInput]::GetConsoleMode($h, [ref]$after)) {',
-        '  Write-Output "error=recheck"; exit 7',
-        '}',
-        'Write-Output ("after=0x{0:X4}" -f $after)',
-        'exit 0',
-    ].join('\n');
-}
-/** `-EncodedCommand` takes base64 of UTF-16LE, which needs no shell quoting. */
-export function encodePowerShellCommand(script) {
-    return Buffer.from(script, 'utf16le').toString('base64');
-}
-/**
- * Prefer the absolute path so a sanitized or hijacked `PATH` cannot decide what
- * runs; fall back to the bare name, which is still better than not trying.
- */
-export function resolvePowerShellExe(env = process.env) {
-    const root = env.SystemRoot ?? env.windir;
-    if (root) {
-        const abs = join(root, 'System32', 'WindowsPowerShell', 'v1.0', 'powershell.exe');
-        if (existsSync(abs))
-            return abs;
-    }
-    return 'powershell.exe';
-}
-/** Pull `before=` / `after=` back out of the helper's stdout. */
-export function parseConsoleModes(stdout) {
-    const read = (label) => {
-        const m = new RegExp(`^${label}=0x([0-9a-fA-F]+)\\s*$`, 'm').exec(stdout);
-        if (!m)
-            return undefined;
-        const n = Number.parseInt(m[1] ?? '', 16);
-        return Number.isFinite(n) ? n : undefined;
-    };
-    const before = read('before');
-    const after = read('after');
-    return { ...(before !== undefined ? { before } : {}), ...(after !== undefined ? { after } : {}) };
-}
-/**
- * PURE, and the reason this feature is testable without a Windows box: every
- * interesting outcome - including the `0x01F7` wrong-console trap that returns
- * exit code 0 - is decided here from two strings and a number.
- */
-export function decideVtForceOutcome(run) {
-    const { before, after } = parseConsoleModes(run.stdout);
-    const carry = before !== undefined ? { before } : {};
-    if (run.status !== 0) {
-        const note = (run.stdout.trim() || run.stderr?.trim() || '').split('\n')[0] ?? '';
-        return { ok: false, reason: 'helper_failed', detail: `exit=${run.status} ${note}`, ...carry };
-    }
-    if (before === undefined)
-        return { ok: false, reason: 'no_before' };
-    // Trap 1. Exit code and API return value both said success; only this tells us
-    // the helper was talking to a different console than the one being typed into.
-    if (!isRawConsoleMode(before))
-        return { ok: false, reason: 'wrong_console', before };
-    if (after === undefined || (after & ENABLE_VIRTUAL_TERMINAL_INPUT) === 0) {
-        // Old conhosts accept `SetConsoleMode` and drop bits they do not implement,
-        // so the re-read is not paranoia - it is the only proof (analysis 3.9).
-        return { ok: false, reason: 'bit_not_set', before, ...(after !== undefined ? { after } : {}) };
-    }
-    return { ok: true, before, after };
-}
-/**
- * Set the bit on the console this process is attached to.
- *
- * SYNCHRONOUS on purpose. The caller has to know the answer before it decides
- * whether the mouse can report and whether to warn the user, and at the one
- * moment this runs - after raw mode is up, before Ink renders - there is nothing
- * else for the event loop to do. An async version would buy nothing and would
- * spread the ordering across two files.
- *
- * NEVER THROWS.
- */
-export function forceWindowsVtInput(opts = {}) {
-    const platform = opts.platform ?? process.platform;
-    if (platform !== 'win32')
-        return { ok: false, reason: 'not_windows' };
-    const exe = resolvePowerShellExe();
-    const args = [
-        '-NoProfile',
-        '-NonInteractive',
-        '-NoLogo',
-        '-EncodedCommand',
-        encodePowerShellCommand(buildHelperScript()),
-    ];
-    try {
-        const run = opts.run ?? defaultRun(opts.timeoutMs ?? 5000);
-        return decideVtForceOutcome(run(exe, args));
-    }
-    catch (err) {
-        return { ok: false, reason: 'spawn_failed', detail: err.message };
-    }
-}
-function defaultRun(timeoutMs) {
-    return (exe, args) => {
-        const r = spawnSync(exe, args, {
-            // stdin `ignore` is trap 2's premise: the helper must not share the handle
-            // whose mode is being rewritten. stdout/stderr are pipes because `before`
-            // has to come back - a log file would be a second failure surface.
-            stdio: ['ignore', 'pipe', 'pipe'],
-            // TRAP 1. Do not "tidy" this to `true`; see the module header.
-            windowsHide: false,
-            timeout: timeoutMs,
-            encoding: 'utf-8',
-        });
-        if (r.error)
-            throw r.error;
-        return { status: r.status, stdout: r.stdout ?? '', stderr: r.stderr ?? '' };
-    };
-}

package/dist/ui/win-vt-input.d.ts

@@ -1,57 +0,0 @@
-/**
- * Will this console ever deliver `CSI Z` and SGR mouse reports?
- * (shift-tab-and-mouse-wheel-dead-on-some-terminals, F1')
- *
- * ASCII ONLY - this tree is inside the glyph scanner's scope.
- *
- * On Windows the answer is decided by NODE, not by the terminal emulator and not
- * by anything this package writes. `Shift+Tab` and SGR mouse reporting both
- * exist only while the console input handle has `ENABLE_VIRTUAL_TERMINAL_INPUT`
- * set, and Node only sets it from v22.17.0 / v24.2.0 onward, where
- * `SetRawMode` switched from `UV_TTY_MODE_RAW` to `UV_TTY_MODE_RAW_VT`
- * (`nodejs/node` `src/tty_wrap.cc`). Before that libuv translates console input
- * records into ANSI itself, and that translation
- *
- *   - has no `VK_TAB` entry, and takes the character branch for it because
- *     `uChar.UnicodeChar` is 0x09, where SHIFT_PRESSED is never read. So
- *     `Shift+Tab` arrives as a PLAIN TAB, byte-identical to `Tab`;
- *   - `continue`s past every record that is not a `KEY_EVENT`, so a mouse
- *     report cannot reach the process at all.
- *
- * Measured rather than reasoned: injecting the same keystrokes into the same
- * console, Node 20.19.0 yields `09` for `Shift+Tab` and Node 22.18.0 yields
- * `1b 5b 5a`; console mode samples `0x0008` and `0x0208` respectively. The full
- * probe data is in `docs/diagnoses/shift-tab-and-mouse-wheel-dead-on-some-terminals/`.
- *
- * PURE: the platform and the version are arguments, so the whole table is
- * testable without a Windows box and without a second Node install.
- */
-/**
- * The versions whose `setRawMode(true)` reaches `UV_TTY_MODE_RAW_VT`.
- *
- * `<23` IS LOAD-BEARING: 23.x branched before the change landed and never got
- * it, and 24.0/24.1 did not have it either - the fix reached the 24 line only in
- * 24.2.0. A range of `>=22.17.0` alone would call both of those supported.
- *
- * A TYPO HERE DISABLES THE WHOLE GATE SILENTLY, because `satisfiesNodeRange`
- * fails open: a clause it cannot parse makes the range unknown and the answer
- * `true`. `win-vt-input.test.ts` pins concrete version strings against concrete
- * booleans for exactly that reason - it is the only guard this constant has.
- */
-export declare const WINDOWS_VT_INPUT_NODE_RANGE = ">=22.17.0 <23 || >=24.2.0";
-/**
- * `false` only for the combination that is known to swallow both inputs:
- * `win32` running a Node outside `WINDOWS_VT_INPUT_NODE_RANGE`.
- *
- * FAILS OPEN, deliberately, in both directions (inherited from
- * `satisfiesNodeRange`, whose own reasoning is written down at its definition):
- * a version string that cannot be parsed is assumed supported. Guessing wrong
- * that way costs nothing beyond today's behaviour; guessing wrong the other way
- * would turn the mouse off on a machine where it works, which is a regression
- * this bug does not justify risking.
- *
- * Every non-Windows platform is `true` unconditionally. macOS and Linux go
- * through a real pty, where the terminal - not Node - encodes the keys, so no
- * version of Node has ever been able to affect this.
- */
-export declare function supportsWindowsVtInput(platform: string, nodeVersion: string): boolean;

package/dist/ui/win-vt-input.js

@@ -1,62 +0,0 @@
-/**
- * Will this console ever deliver `CSI Z` and SGR mouse reports?
- * (shift-tab-and-mouse-wheel-dead-on-some-terminals, F1')
- *
- * ASCII ONLY - this tree is inside the glyph scanner's scope.
- *
- * On Windows the answer is decided by NODE, not by the terminal emulator and not
- * by anything this package writes. `Shift+Tab` and SGR mouse reporting both
- * exist only while the console input handle has `ENABLE_VIRTUAL_TERMINAL_INPUT`
- * set, and Node only sets it from v22.17.0 / v24.2.0 onward, where
- * `SetRawMode` switched from `UV_TTY_MODE_RAW` to `UV_TTY_MODE_RAW_VT`
- * (`nodejs/node` `src/tty_wrap.cc`). Before that libuv translates console input
- * records into ANSI itself, and that translation
- *
- *   - has no `VK_TAB` entry, and takes the character branch for it because
- *     `uChar.UnicodeChar` is 0x09, where SHIFT_PRESSED is never read. So
- *     `Shift+Tab` arrives as a PLAIN TAB, byte-identical to `Tab`;
- *   - `continue`s past every record that is not a `KEY_EVENT`, so a mouse
- *     report cannot reach the process at all.
- *
- * Measured rather than reasoned: injecting the same keystrokes into the same
- * console, Node 20.19.0 yields `09` for `Shift+Tab` and Node 22.18.0 yields
- * `1b 5b 5a`; console mode samples `0x0008` and `0x0208` respectively. The full
- * probe data is in `docs/diagnoses/shift-tab-and-mouse-wheel-dead-on-some-terminals/`.
- *
- * PURE: the platform and the version are arguments, so the whole table is
- * testable without a Windows box and without a second Node install.
- */
-import { satisfiesNodeRange } from '../update/semver.js';
-/**
- * The versions whose `setRawMode(true)` reaches `UV_TTY_MODE_RAW_VT`.
- *
- * `<23` IS LOAD-BEARING: 23.x branched before the change landed and never got
- * it, and 24.0/24.1 did not have it either - the fix reached the 24 line only in
- * 24.2.0. A range of `>=22.17.0` alone would call both of those supported.
- *
- * A TYPO HERE DISABLES THE WHOLE GATE SILENTLY, because `satisfiesNodeRange`
- * fails open: a clause it cannot parse makes the range unknown and the answer
- * `true`. `win-vt-input.test.ts` pins concrete version strings against concrete
- * booleans for exactly that reason - it is the only guard this constant has.
- */
-export const WINDOWS_VT_INPUT_NODE_RANGE = '>=22.17.0 <23 || >=24.2.0';
-/**
- * `false` only for the combination that is known to swallow both inputs:
- * `win32` running a Node outside `WINDOWS_VT_INPUT_NODE_RANGE`.
- *
- * FAILS OPEN, deliberately, in both directions (inherited from
- * `satisfiesNodeRange`, whose own reasoning is written down at its definition):
- * a version string that cannot be parsed is assumed supported. Guessing wrong
- * that way costs nothing beyond today's behaviour; guessing wrong the other way
- * would turn the mouse off on a machine where it works, which is a regression
- * this bug does not justify risking.
- *
- * Every non-Windows platform is `true` unconditionally. macOS and Linux go
- * through a real pty, where the terminal - not Node - encodes the keys, so no
- * version of Node has ever been able to affect this.
- */
-export function supportsWindowsVtInput(platform, nodeVersion) {
-    if (platform !== 'win32')
-        return true;
-    return satisfiesNodeRange(WINDOWS_VT_INPUT_NODE_RANGE, nodeVersion);
-}

package/dist/update/limits.d.ts

@@ -1,111 +0,0 @@
-/**
- * UPDATE_LIMITS - the single authority on every structural bound the updater
- * enforces (cli-auto-update section 5.4).
- *
- * ASCII ONLY: `src/update/**` is inside the glyph scanner's scope
- * (`glyphs.test.ts`), so no literal in this tree may hold a non-ASCII byte. The
- * regex there is a hardcoded directory list, which is why adding this tree and
- * adding `update` to that list are the SAME change (C-2 / AC-18) - a scanner
- * that silently stops scanning is worse than no scanner.
- *
- * TWO KINDS OF NUMBER, AND THEY ARE NOT INTERCHANGEABLE - the distinction
- * `TEAM_LIMITS`, `TODO_LIMITS` and `FAST_LIMITS` all state:
- *
- *  - The entries below are STRUCTURAL. They describe what a background check, a
- *    detached install and a one-row readout can physically carry. A user has no
- *    business tuning them.
- *  - The four `update.*` keys in `config/schema.ts` are POLICY: whether to
- *    install at all, how often to ask, which registry, which dist-tag. Those are
- *    clamped, persisted and user-facing.
- *
- * NOTHING HERE IS IMPORTED AT RUNTIME BY `cli.tsx` (AC-1). This module and
- * `types.ts` are pure, dependency-free and side-effect-free; every other module
- * in this tree is reached only through the dynamic `import()` in section 3.8.
- */
-export declare const UPDATE_LIMITS: {
-    /** Never contend with first paint. */
-    readonly startupDelayMs: 3000;
-    /**
-     * A background check has nobody waiting on it.
-     *
-     * Below `fetch-source.ts`'s `HTTP_TIMEOUT_MS` (15 s) ON PURPOSE: that one
-     * bounds a download a human typed a command for, this one bounds a request the
-     * user never asked for and must never notice.
-     */
-    readonly checkTimeoutMs: 8000;
-    /**
-     * Wall-clock budget for the `installing` PHASE and the lock's staleness
-     * refresh - NEVER FOR THE CHILD (U-5 / P1-5).
-     *
-     * It decides when the UI stops saying "updating" and when a lock is treated as
-     * abandoned. It is deliberately NOT `execFile`'s `timeout`, which stays `0`:
-     * wiring it there makes Node `SIGTERM` npm mid-write - the broken global
-     * installation U-3 and D-10 exist to prevent - and it would fire on exactly
-     * the slow links where a five-minute install is the correct outcome.
-     */
-    readonly installTimeoutMs: 300000;
-    /** The `/latest` document is ~2 KB; this is the C-8 ceiling, not a target. */
-    readonly manifestMaxBytes: number;
-    /** Matches `fetch-source.ts`'s `MAX_REDIRECTS`. */
-    readonly maxRedirects: 3;
-    /**
-     * Longer than `skills`' 60 s, and the difference is the point: the holder here
-     * is an npm install on a cold cache, not a file rename.
-     */
-    readonly lockTtlMs: 600000;
-    /** First retry after a failed check or install. */
-    readonly backoffBaseMs: 1800000;
-    /** Ceiling of the exponential. */
-    readonly backoffMaxMs: 86400000;
-    /**
-     * Consecutive failures before the row says anything at all (D-7).
-     *
-     * Below this the failure is silent, because silence is the requirement and an
-     * unactionable recurring warning is the standard way updaters become hated.
-     */
-    readonly failuresBeforeNotice: 3;
-    /** Thundering-herd spread on the check interval (D-12). */
-    readonly jitterRatio: 0.15;
-    /**
-     * Bounded, redacted npm error tail, read from the install LOG FILE (U-5).
-     *
-     * There is a tail to read at all only because the child writes to a real file
-     * descriptor rather than to `'ignore'`; a pipe would have died with the parent
-     * and broken D-10.
-     */
-    readonly stderrTailChars: 500;
-    /**
-     * Below this many columns the update line renders its short form (section 6.2).
-     *
-     * DELIBERATELY NOT `FAST_LIMITS.statusCompactCols`' 100 (`fast/limits.ts`).
-     * That number governs a multi-part status chip competing with the context
-     * gauge for the same row; this one governs a single short clause that owns its
-     * row outright. Two numbers about two different things - do not unify them.
-     */
-    readonly statusCompactCols: 60;
-    /**
-     * Non-zero exits of a version WE installed before it is rolled back
-     * (cli-auto-update-hardening section 7.2 / D-30).
-     *
-     * Tested against the count of PREVIOUS launches, so `2` means "the third
-     * launch rolls back". One crash can be transient - a machine that ran out of
-     * memory once, or whose session file was corrupt, gets a second chance at the
-     * release it just installed. Two is a pattern.
-     *
-     * NOTHING ELSE IN THIS TABLE BOUNDS THE ROLLBACK. There is deliberately no
-     * `bootGuardMaxAgeMs`: the guard is armed only while `autoInstalledVersion`
-     * equals the RUNNING version, so "a machine offline for a year" is a machine
-     * still running the version we installed, and rolling it back to
-     * `lastGoodVersion` is exactly as correct on day 400 as on day 1 (P1-3).
-     */
-    readonly crashesBeforeRollback: 2;
-    /**
-     * Bound on the `npm view` fallback probe (H3).
-     *
-     * SAFE HERE AND FORBIDDEN FOR THE INSTALLER (C-20). A killed `npm view` has
-     * written nothing; a killed `npm install -g` leaves a broken global
-     * installation, which is why `installTimeoutMs` above bounds the PHASE and
-     * never the child.
-     */
-    readonly npmViewTimeoutMs: 10000;
-};

package/dist/update/limits.js

@@ -1,111 +0,0 @@
-/**
- * UPDATE_LIMITS - the single authority on every structural bound the updater
- * enforces (cli-auto-update section 5.4).
- *
- * ASCII ONLY: `src/update/**` is inside the glyph scanner's scope
- * (`glyphs.test.ts`), so no literal in this tree may hold a non-ASCII byte. The
- * regex there is a hardcoded directory list, which is why adding this tree and
- * adding `update` to that list are the SAME change (C-2 / AC-18) - a scanner
- * that silently stops scanning is worse than no scanner.
- *
- * TWO KINDS OF NUMBER, AND THEY ARE NOT INTERCHANGEABLE - the distinction
- * `TEAM_LIMITS`, `TODO_LIMITS` and `FAST_LIMITS` all state:
- *
- *  - The entries below are STRUCTURAL. They describe what a background check, a
- *    detached install and a one-row readout can physically carry. A user has no
- *    business tuning them.
- *  - The four `update.*` keys in `config/schema.ts` are POLICY: whether to
- *    install at all, how often to ask, which registry, which dist-tag. Those are
- *    clamped, persisted and user-facing.
- *
- * NOTHING HERE IS IMPORTED AT RUNTIME BY `cli.tsx` (AC-1). This module and
- * `types.ts` are pure, dependency-free and side-effect-free; every other module
- * in this tree is reached only through the dynamic `import()` in section 3.8.
- */
-export const UPDATE_LIMITS = {
-    /** Never contend with first paint. */
-    startupDelayMs: 3_000,
-    /**
-     * A background check has nobody waiting on it.
-     *
-     * Below `fetch-source.ts`'s `HTTP_TIMEOUT_MS` (15 s) ON PURPOSE: that one
-     * bounds a download a human typed a command for, this one bounds a request the
-     * user never asked for and must never notice.
-     */
-    checkTimeoutMs: 8_000,
-    /**
-     * Wall-clock budget for the `installing` PHASE and the lock's staleness
-     * refresh - NEVER FOR THE CHILD (U-5 / P1-5).
-     *
-     * It decides when the UI stops saying "updating" and when a lock is treated as
-     * abandoned. It is deliberately NOT `execFile`'s `timeout`, which stays `0`:
-     * wiring it there makes Node `SIGTERM` npm mid-write - the broken global
-     * installation U-3 and D-10 exist to prevent - and it would fire on exactly
-     * the slow links where a five-minute install is the correct outcome.
-     */
-    installTimeoutMs: 300_000,
-    /** The `/latest` document is ~2 KB; this is the C-8 ceiling, not a target. */
-    manifestMaxBytes: 256 * 1024,
-    /** Matches `fetch-source.ts`'s `MAX_REDIRECTS`. */
-    maxRedirects: 3,
-    /**
-     * Longer than `skills`' 60 s, and the difference is the point: the holder here
-     * is an npm install on a cold cache, not a file rename.
-     */
-    lockTtlMs: 600_000,
-    /** First retry after a failed check or install. */
-    backoffBaseMs: 1_800_000,
-    /** Ceiling of the exponential. */
-    backoffMaxMs: 86_400_000,
-    /**
-     * Consecutive failures before the row says anything at all (D-7).
-     *
-     * Below this the failure is silent, because silence is the requirement and an
-     * unactionable recurring warning is the standard way updaters become hated.
-     */
-    failuresBeforeNotice: 3,
-    /** Thundering-herd spread on the check interval (D-12). */
-    jitterRatio: 0.15,
-    /**
-     * Bounded, redacted npm error tail, read from the install LOG FILE (U-5).
-     *
-     * There is a tail to read at all only because the child writes to a real file
-     * descriptor rather than to `'ignore'`; a pipe would have died with the parent
-     * and broken D-10.
-     */
-    stderrTailChars: 500,
-    /**
-     * Below this many columns the update line renders its short form (section 6.2).
-     *
-     * DELIBERATELY NOT `FAST_LIMITS.statusCompactCols`' 100 (`fast/limits.ts`).
-     * That number governs a multi-part status chip competing with the context
-     * gauge for the same row; this one governs a single short clause that owns its
-     * row outright. Two numbers about two different things - do not unify them.
-     */
-    statusCompactCols: 60,
-    /**
-     * Non-zero exits of a version WE installed before it is rolled back
-     * (cli-auto-update-hardening section 7.2 / D-30).
-     *
-     * Tested against the count of PREVIOUS launches, so `2` means "the third
-     * launch rolls back". One crash can be transient - a machine that ran out of
-     * memory once, or whose session file was corrupt, gets a second chance at the
-     * release it just installed. Two is a pattern.
-     *
-     * NOTHING ELSE IN THIS TABLE BOUNDS THE ROLLBACK. There is deliberately no
-     * `bootGuardMaxAgeMs`: the guard is armed only while `autoInstalledVersion`
-     * equals the RUNNING version, so "a machine offline for a year" is a machine
-     * still running the version we installed, and rolling it back to
-     * `lastGoodVersion` is exactly as correct on day 400 as on day 1 (P1-3).
-     */
-    crashesBeforeRollback: 2,
-    /**
-     * Bound on the `npm view` fallback probe (H3).
-     *
-     * SAFE HERE AND FORBIDDEN FOR THE INSTALLER (C-20). A killed `npm view` has
-     * written nothing; a killed `npm install -g` leaves a broken global
-     * installation, which is why `installTimeoutMs` above bounds the PHASE and
-     * never the child.
-     */
-    npmViewTimeoutMs: 10_000,
-};

package/dist/update/semver.d.ts

@@ -1,89 +0,0 @@
-/**
- * Semver comparison and the update decision (cli-auto-update section 3.4).
- *
- * ASCII ONLY - this tree is inside the glyph scanner's scope (C-2 / C-3).
- *
- * HAND-WRITTEN AND NOT `semver`. The package has no such dependency
- * (`package.json`), and this feature needs three questions answered - "is B
- * newer than A", "is B a prerelease", "does this Node satisfy that range" - on a
- * document the registry writes and npm itself only warns about. Adding a
- * transitive dependency to an auto-updater, of all things, is the one place the
- * supply-chain argument in R-1 cuts hardest.
- *
- * PURE: no I/O, no clock, no process. Every function here is total and none of
- * them throws.
- */
-import type { LatestManifest } from './types.js';
-/**
- * The form a version must have before it is interpolated into `npm install`'s
- * argv (section 3.5 / AC-24).
- *
- * ANCHORED AND WITHOUT `v`: a registry that answered `"1.0.0; rm -rf /"` must
- * never reach `execFile`. With `shell: false` this is not an injection surface
- * to begin with, but the rejection is what makes that claim checkable rather
- * than reasoned, and it also satisfies `fetch-source.ts` rule 3 (no leading `-`)
- * by construction.
- */
-export declare const STRICT_VERSION_RE: RegExp;
-export interface Semver {
-    major: number;
-    minor: number;
-    patch: number;
-    /** Dot-separated prerelease identifiers, or `[]` for a release. */
-    prerelease: string[];
-}
-/** Parse a semver string, or `null` when it is not one. Never throws. */
-export declare function parseSemver(raw: unknown): Semver | null;
-export declare function isPrerelease(raw: string): boolean;
-/**
- * `-1 | 0 | 1`. An UNPARSEABLE version sorts BELOW a parseable one and equal to
- * another unparseable one, so a garbage registry answer can never read as newer
- * than what is installed.
- */
-export declare function compareSemver(a: string, b: string): number;
-/**
- * Does `nodeVersion` satisfy `engines.node`?
- *
- * FAILS OPEN, and that is a decision rather than an oversight (D-15). Handled
- * forms are `>=X`, `>=X.Y.Z`, `>X`, `<X`, `<=X`, `=X`, `^X`, `~X`, `X.x`, and
- * `||`-joined unions of those, with space-separated clauses inside a union
- * ANDed together. Anything this cannot parse returns `true`, matching npm's own
- * default of warning rather than refusing.
- *
- * Failing CLOSED here would mean a syntax we did not anticipate silently freezes
- * every user's updates forever, with no message and no way to find out - the
- * worse of the two errors by a wide margin. A range we DID understand and that
- * genuinely excludes this Node yields `false`, and the caller turns that into a
- * `node-too-old` notice so the user is told to upgrade Node rather than left
- * wondering.
- */
-export declare function satisfiesNodeRange(range: string | undefined, nodeVersion: string): boolean;
-export type UpdateAction = 'install' | 'notify' | 'none';
-export interface UpdateDecision {
-    action: UpdateAction;
-    reason: 'up-to-date' | 'prerelease' | 'deprecated' | 'node-too-old' | 'skipped' | 'newer-available';
-}
-export interface DecideUpdateInput {
-    /** The version this process is running. */
-    local: string;
-    manifest: Pick<LatestManifest, 'version' | 'engines' | 'deprecated'>;
-    /** `process.versions.node`, injected so the decision is testable offline. */
-    nodeVersion: string;
-    /** `state.skippedVersion`; `''` when the user has skipped nothing. */
-    skippedVersion: string;
-}
-/**
- * Should we install, merely report, or say nothing? (section 3.4)
- *
- * ORDER IS SEMANTIC. `up-to-date` is answered first because it is the
- * overwhelmingly common case and the cheapest; `skipped` comes before the
- * quality gates so a user who typed `/update skip` is not told about a
- * prerelease they already declined. Only a range we UNDERSTOOD and that excludes
- * this Node produces `notify`; every other rejection is silent (`none`).
- *
- * The SOURCE and the MODE are deliberately NOT inputs here. This function
- * answers "is that version worth having"; whether this machine may install it is
- * the service's question, and folding the two would make a pure decision depend
- * on the filesystem.
- */
-export declare function decideUpdate(input: DecideUpdateInput): UpdateDecision;