@aragon-agent/cli 0.6.46 → 0.6.48

package/dist/proc/limits.d.ts

@@ -1,200 +0,0 @@
-/**
- * PROC_LIMITS — the single authority on every structural bound the process
- * supervisor enforces (background-service-supervision §6).
- *
- * ASCII ONLY: `src/proc/**` is inside the glyph scanner's scope
- * (`glyphs.test.ts::inScope`), whose hardcoded directory regex this feature
- * extends. A NEW TREE IS INVISIBLE TO THAT SCAN UNTIL IT IS NAMED THERE, and a
- * guard rail that silently stops guarding is worse than no guard rail — this
- * package has now paid for that edit eleven times.
- *
- * TWO KINDS OF NUMBER, AND THEY ARE NOT INTERCHANGEABLE — the distinction
- * `TODO_LIMITS` and `TEAM_LIMITS` each record at length:
- *
- *  - Everything below is STRUCTURAL: how many rows a tail can physically carry,
- *    how many children one session may hold, how long a kill may take before it
- *    stops being a kill. A user has no business tuning them, so they are
- *    constants.
- *  - The four `bash.*` config keys (`config/schema.ts`) are POLICY: register the
- *    tools at all, let the classifier fire, how long a launch may block the
- *    turn, how long to wait for readiness. They are clamped, persisted and
- *    user-facing.
- */
-export declare const PROC_LIMITS: {
-    /**
-     * Rows the per-service ring retains.
-     *
-     * DELIBERATELY A DIFFERENT NUMBER FROM `cardTailRows` BELOW, and from
-     * `LIVE_TAIL_ROWS` (8) in `tools/tool-output-store.ts`. They bound unrelated
-     * things — what `bash_output` can page back through, versus what one card
-     * draws — and a shared literal is how a later edit collapses two bounds into
-     * one.
-     */
-    readonly serviceTailRows: 200;
-    /** Rows a snapshot (and therefore a card) carries. */
-    readonly cardTailRows: 8;
-    /**
-     * JOB RECORDS one session may hold — services AND tasks share the number.
-     *
-     * NAMED `maxJobs`, NOT `maxServices` (long-task-jobs D-7). A constant that
-     * counts two kinds of job while being called `maxServices` is the next edit's
-     * bug: the limit and its refusal message would go on saying "service" while
-     * the model is holding a training run.
-     *
-     * Eviction only ever removes a record in a TERMINAL state
-     * (`exited | failed | stopped`). When all 16 are live `start()` refuses and
-     * names the oldest ids rather than evicting: evicting a live record would
-     * orphan a running server that nothing can any longer name or stop.
-     */
-    readonly maxJobs: 16;
-    /**
-     * How long `bash` waits after `'exit'` for the stdio streams to close before
-     * settling anyway.
-     *
-     * This number IS defence 1. `'close'` fires only once every stream is closed,
-     * and a detached grandchild that inherited the pipe keeps it open after the
-     * shell is long gone — so a tool that settles on `'close'` alone has a path
-     * that never settles at all.
-     *
-     * IT IS A BOUND, NOT A VERDICT. Expiry says "stop waiting"; it does NOT say
-     * the pipe was held, and the note is only printed when the streams are
-     * observed still open at that moment (`proc/output-streams.ts` records the
-     * release-gate failure a timer-based verdict caused). The ordinary path does
-     * not even reach this bound: two ended streams after `'exit'` settle the call
-     * with the byte-identical body, one notification earlier.
-     */
-    readonly drainMs: 250;
-    /**
-     * How long an aborted/timed-out `bash` waits after the kill before settling
-     * WHETHER OR NOT the child ever reported exit.
-     *
-     * A pending promise after an abort is the bug; a possibly-premature result is
-     * not.
-     */
-    readonly killGraceMs: 2000;
-    /** Readiness port probe interval. */
-    readonly probeIntervalMs: 500;
-    /** Socket timeout for one readiness probe. */
-    readonly probeSocketTimeoutMs: 1000;
-    /**
-     * Output-event coalescing window inside the supervisor.
-     *
-     * At the SOURCE rather than in the view, because the same event is also
-     * consumed by `/bg` and by `bash_output`. A webpack build emitting thousands
-     * of lines a second must not become thousands of React renders.
-     */
-    readonly outputCoalesceMs: 100;
-    /** `SIGTERM` -> `SIGKILL` escalation window for a graceful stop. */
-    readonly stopGraceMs: 3000;
-    /**
-     * How long to KEEP ASKING whether the `SIGKILL` actually landed before
-     * declaring the job `stopped`.
-     *
-     * THIS NUMBER IS NOT A GUESS ABOUT THE PLATFORM. `killTree` spawns `taskkill`,
-     * which is a process of its own: a Windows tree kill of a shell plus its node
-     * child measures ~0.8 s on the reference machine (while starting `cmd` costs
-     * 50 ms), so the fixed 250 ms this used to allow expired first and `stop()`
-     * reported `stopped` with the child still running - AC-18 caught exactly that.
-     * The wait stays BOUNDED against the opposite failure (a promise that never
-     * resolves); at this deadline the record keeps the honest `killIncomplete`
-     * flag instead.
-     */
-    readonly killVerifyMs: 2000;
-    /** Liveness poll interval while waiting for a `SIGKILL` to land. */
-    readonly killVerifyPollMs: 50;
-    /**
-     * How long ONE synchronous tree kill (`killTreeSync`) may take.
-     *
-     * MEASURED, NOT GUESSED. A `taskkill /pid <shell> /t /f` of a shell plus its
-     * node child takes 1027-1058 ms on the reference machine on an IDLE host (five
-     * samples, 2026-10-23), so the old 2000 ms was 1.9x the honest cost and the
-     * 2026-10-23 release run - where the whole suite took 340 s against the usual
-     * 200-240 s - is comfortably inside the range where a single tree kill exceeds
-     * it. Crossing it is not a slow kill, it is NO kill: `spawnSync` kills
-     * `taskkill` itself at the deadline and the tree keeps running (verified: a
-     * 150 ms budget left the child alive 1.5 s later, `ETIMEDOUT` / `status null`).
-     *
-     * 5000 ms is ~5x the measured cost. It is a CEILING and not a cost: a tree that
-     * dies in the usual second still returns in that second. The worst case is
-     * `maxJobs` (16) trees at the ceiling on an exit hook, which is why this is not
-     * any larger - the reaper prefers a reported miss to an exit that never ends,
-     * and the miss is now reported (`ProcRecord.killIncomplete`).
-     */
-    readonly killTreeSyncTimeoutMs: 5000;
-    /** Below this many terminal columns the status chip degrades to `[N]`. */
-    readonly statusCompactCols: 92;
-    /**
-     * Rows of new output one `job_wait` result carries, in addition to its status,
-     * progress, cursor, `[note]`/`[stalled]` and `[next]` lines.
-     *
-     * THE NUMBER IS THE FEATURE. One wait must cost ~150 tokens, not the ~6k a
-     * 200-row tail costs - that economy is the whole reason `job_wait` exists
-     * instead of a seventh `bash_output` poll.
-     */
-    readonly waitTailRows: 6;
-    /** Seconds a single wait may block, as a STRUCTURAL floor and ceiling (`jobs.waitSeconds` is clamped into this range). */
-    readonly waitMinSeconds: 5;
-    readonly waitMaxSeconds: 60;
-    /**
-     * Characters one extracted progress line may occupy.
-     *
-     * Also the width the card's progress row is assumed to take, which is why
-     * `ui/layout/virtual-window.ts` can count it as exactly one row.
-     */
-    readonly waitProgressChars: 80;
-    /**
-     * Rows `extractProgress` scans, from the tail, before giving up.
-     *
-     * Eight because a tqdm bar plus its ETA plus the loss line above it is the
-     * realistic worst case, and because a wider window is how a stale `100%` from
-     * an earlier phase wins over the live one.
-     */
-    readonly progressScanRows: 8;
-    /** Notices one `<job_notices>` block may render. Bounded so the block stays ~8 lines. */
-    readonly maxNotices: 8;
-    /** Log rows a failed job's notice carries. Two: the message and the frame above it. */
-    readonly noticeTailRows: 2;
-    /** Rows `job_list` prints before it collapses the rest into `+N more`. */
-    readonly listRows: 8;
-    /**
-     * Consecutive waits with no new row and no progress change before the
-     * `[guard]` line is prepended (R-3).
-     *
-     * A HINT, NEVER A REFUSAL: the seventh wait still waits. Refusing would take
-     * the decision away from the model at exactly the point where it has the most
-     * context.
-     */
-    readonly maxConsecutiveWaits: 6;
-    /** Bytes one mirrored job log may occupy before it stops appending. */
-    readonly logMirrorMaxBytes: 2000000;
-    /** Coalescing window for the log mirror's appends (<=4 writes/second). */
-    readonly mirrorFlushMs: 250;
-    /** Session directories the mirror keeps, newest by mtime. */
-    readonly mirrorRetainDirs: 5;
-};
-/**
- * Bumped whenever the wording of the `<background_services>` block changes, so a
- * behaviour report can be tied to a block revision with one grep.
- */
-export declare const BACKGROUND_SERVICES_BLOCK_VERSION = "v1";
-/**
- * The same discipline for the `<background_jobs>` block. A SEPARATE CONSTANT,
- * not a bump of the one above: the two blocks are spliced by different flags
- * (`bash.background` and `jobs.enabled`), so one version number covering both
- * would make "which block changed" unanswerable from a report.
- */
-export declare const JOBS_BLOCK_VERSION = "v1-2026-10";
-/**
- * Head-room a single wait leaves below the tool ceiling (I-4).
- *
- * `jobs.waitSeconds * 1000 + JOB_WAIT_MARGIN_MS <= toolTimeoutMs` is the whole
- * reason a wait never needs to pause the idle watchdog (D-3): a 60 s wait inside
- * a 180 s tool call in a 210 s idle window cannot be mistaken for a hang.
- *
- * IT LIVES HERE RATHER THAN IN `config/schema.ts`, where the design document put
- * it, because the TOOL layer needs the same number for its call-time convergence
- * (AC-14) and nothing in `tools/` may import `config/` - a tool takes its policy
- * through closures. One constant, two readers, no second copy to drift. Recorded
- * in `docs/plans/long-task-jobs/spec.md` under `## 实施过程发现的方案缺陷` (I-2).
- */
-export declare const JOB_WAIT_MARGIN_MS = 30000;

package/dist/proc/limits.js

@@ -1,207 +0,0 @@
-/**
- * PROC_LIMITS — the single authority on every structural bound the process
- * supervisor enforces (background-service-supervision §6).
- *
- * ASCII ONLY: `src/proc/**` is inside the glyph scanner's scope
- * (`glyphs.test.ts::inScope`), whose hardcoded directory regex this feature
- * extends. A NEW TREE IS INVISIBLE TO THAT SCAN UNTIL IT IS NAMED THERE, and a
- * guard rail that silently stops guarding is worse than no guard rail — this
- * package has now paid for that edit eleven times.
- *
- * TWO KINDS OF NUMBER, AND THEY ARE NOT INTERCHANGEABLE — the distinction
- * `TODO_LIMITS` and `TEAM_LIMITS` each record at length:
- *
- *  - Everything below is STRUCTURAL: how many rows a tail can physically carry,
- *    how many children one session may hold, how long a kill may take before it
- *    stops being a kill. A user has no business tuning them, so they are
- *    constants.
- *  - The four `bash.*` config keys (`config/schema.ts`) are POLICY: register the
- *    tools at all, let the classifier fire, how long a launch may block the
- *    turn, how long to wait for readiness. They are clamped, persisted and
- *    user-facing.
- */
-export const PROC_LIMITS = {
-    /**
-     * Rows the per-service ring retains.
-     *
-     * DELIBERATELY A DIFFERENT NUMBER FROM `cardTailRows` BELOW, and from
-     * `LIVE_TAIL_ROWS` (8) in `tools/tool-output-store.ts`. They bound unrelated
-     * things — what `bash_output` can page back through, versus what one card
-     * draws — and a shared literal is how a later edit collapses two bounds into
-     * one.
-     */
-    serviceTailRows: 200,
-    /** Rows a snapshot (and therefore a card) carries. */
-    cardTailRows: 8,
-    /**
-     * JOB RECORDS one session may hold — services AND tasks share the number.
-     *
-     * NAMED `maxJobs`, NOT `maxServices` (long-task-jobs D-7). A constant that
-     * counts two kinds of job while being called `maxServices` is the next edit's
-     * bug: the limit and its refusal message would go on saying "service" while
-     * the model is holding a training run.
-     *
-     * Eviction only ever removes a record in a TERMINAL state
-     * (`exited | failed | stopped`). When all 16 are live `start()` refuses and
-     * names the oldest ids rather than evicting: evicting a live record would
-     * orphan a running server that nothing can any longer name or stop.
-     */
-    maxJobs: 16,
-    /**
-     * How long `bash` waits after `'exit'` for the stdio streams to close before
-     * settling anyway.
-     *
-     * This number IS defence 1. `'close'` fires only once every stream is closed,
-     * and a detached grandchild that inherited the pipe keeps it open after the
-     * shell is long gone — so a tool that settles on `'close'` alone has a path
-     * that never settles at all.
-     *
-     * IT IS A BOUND, NOT A VERDICT. Expiry says "stop waiting"; it does NOT say
-     * the pipe was held, and the note is only printed when the streams are
-     * observed still open at that moment (`proc/output-streams.ts` records the
-     * release-gate failure a timer-based verdict caused). The ordinary path does
-     * not even reach this bound: two ended streams after `'exit'` settle the call
-     * with the byte-identical body, one notification earlier.
-     */
-    drainMs: 250,
-    /**
-     * How long an aborted/timed-out `bash` waits after the kill before settling
-     * WHETHER OR NOT the child ever reported exit.
-     *
-     * A pending promise after an abort is the bug; a possibly-premature result is
-     * not.
-     */
-    killGraceMs: 2000,
-    /** Readiness port probe interval. */
-    probeIntervalMs: 500,
-    /** Socket timeout for one readiness probe. */
-    probeSocketTimeoutMs: 1000,
-    /**
-     * Output-event coalescing window inside the supervisor.
-     *
-     * At the SOURCE rather than in the view, because the same event is also
-     * consumed by `/bg` and by `bash_output`. A webpack build emitting thousands
-     * of lines a second must not become thousands of React renders.
-     */
-    outputCoalesceMs: 100,
-    /** `SIGTERM` -> `SIGKILL` escalation window for a graceful stop. */
-    stopGraceMs: 3000,
-    /**
-     * How long to KEEP ASKING whether the `SIGKILL` actually landed before
-     * declaring the job `stopped`.
-     *
-     * THIS NUMBER IS NOT A GUESS ABOUT THE PLATFORM. `killTree` spawns `taskkill`,
-     * which is a process of its own: a Windows tree kill of a shell plus its node
-     * child measures ~0.8 s on the reference machine (while starting `cmd` costs
-     * 50 ms), so the fixed 250 ms this used to allow expired first and `stop()`
-     * reported `stopped` with the child still running - AC-18 caught exactly that.
-     * The wait stays BOUNDED against the opposite failure (a promise that never
-     * resolves); at this deadline the record keeps the honest `killIncomplete`
-     * flag instead.
-     */
-    killVerifyMs: 2000,
-    /** Liveness poll interval while waiting for a `SIGKILL` to land. */
-    killVerifyPollMs: 50,
-    /**
-     * How long ONE synchronous tree kill (`killTreeSync`) may take.
-     *
-     * MEASURED, NOT GUESSED. A `taskkill /pid <shell> /t /f` of a shell plus its
-     * node child takes 1027-1058 ms on the reference machine on an IDLE host (five
-     * samples, 2026-10-23), so the old 2000 ms was 1.9x the honest cost and the
-     * 2026-10-23 release run - where the whole suite took 340 s against the usual
-     * 200-240 s - is comfortably inside the range where a single tree kill exceeds
-     * it. Crossing it is not a slow kill, it is NO kill: `spawnSync` kills
-     * `taskkill` itself at the deadline and the tree keeps running (verified: a
-     * 150 ms budget left the child alive 1.5 s later, `ETIMEDOUT` / `status null`).
-     *
-     * 5000 ms is ~5x the measured cost. It is a CEILING and not a cost: a tree that
-     * dies in the usual second still returns in that second. The worst case is
-     * `maxJobs` (16) trees at the ceiling on an exit hook, which is why this is not
-     * any larger - the reaper prefers a reported miss to an exit that never ends,
-     * and the miss is now reported (`ProcRecord.killIncomplete`).
-     */
-    killTreeSyncTimeoutMs: 5000,
-    /** Below this many terminal columns the status chip degrades to `[N]`. */
-    statusCompactCols: 92,
-    // --- long-task-jobs: bounded waiting, progress, notices, log mirror --------
-    //
-    // EVERY ONE OF THESE IS STRUCTURAL, not policy. The user-tunable knobs are the
-    // five `jobs.*` keys in `config/schema.ts` (how many seconds to wait, when
-    // silence becomes `[stalled]`, whether to mirror the log, whether notices may
-    // steer). What a result can PHYSICALLY carry lives here, for the reason this
-    // file's header records at length.
-    /**
-     * Rows of new output one `job_wait` result carries, in addition to its status,
-     * progress, cursor, `[note]`/`[stalled]` and `[next]` lines.
-     *
-     * THE NUMBER IS THE FEATURE. One wait must cost ~150 tokens, not the ~6k a
-     * 200-row tail costs - that economy is the whole reason `job_wait` exists
-     * instead of a seventh `bash_output` poll.
-     */
-    waitTailRows: 6,
-    /** Seconds a single wait may block, as a STRUCTURAL floor and ceiling (`jobs.waitSeconds` is clamped into this range). */
-    waitMinSeconds: 5,
-    waitMaxSeconds: 60,
-    /**
-     * Characters one extracted progress line may occupy.
-     *
-     * Also the width the card's progress row is assumed to take, which is why
-     * `ui/layout/virtual-window.ts` can count it as exactly one row.
-     */
-    waitProgressChars: 80,
-    /**
-     * Rows `extractProgress` scans, from the tail, before giving up.
-     *
-     * Eight because a tqdm bar plus its ETA plus the loss line above it is the
-     * realistic worst case, and because a wider window is how a stale `100%` from
-     * an earlier phase wins over the live one.
-     */
-    progressScanRows: 8,
-    /** Notices one `<job_notices>` block may render. Bounded so the block stays ~8 lines. */
-    maxNotices: 8,
-    /** Log rows a failed job's notice carries. Two: the message and the frame above it. */
-    noticeTailRows: 2,
-    /** Rows `job_list` prints before it collapses the rest into `+N more`. */
-    listRows: 8,
-    /**
-     * Consecutive waits with no new row and no progress change before the
-     * `[guard]` line is prepended (R-3).
-     *
-     * A HINT, NEVER A REFUSAL: the seventh wait still waits. Refusing would take
-     * the decision away from the model at exactly the point where it has the most
-     * context.
-     */
-    maxConsecutiveWaits: 6,
-    /** Bytes one mirrored job log may occupy before it stops appending. */
-    logMirrorMaxBytes: 2_000_000,
-    /** Coalescing window for the log mirror's appends (<=4 writes/second). */
-    mirrorFlushMs: 250,
-    /** Session directories the mirror keeps, newest by mtime. */
-    mirrorRetainDirs: 5,
-};
-/**
- * Bumped whenever the wording of the `<background_services>` block changes, so a
- * behaviour report can be tied to a block revision with one grep.
- */
-export const BACKGROUND_SERVICES_BLOCK_VERSION = 'v1';
-/**
- * The same discipline for the `<background_jobs>` block. A SEPARATE CONSTANT,
- * not a bump of the one above: the two blocks are spliced by different flags
- * (`bash.background` and `jobs.enabled`), so one version number covering both
- * would make "which block changed" unanswerable from a report.
- */
-export const JOBS_BLOCK_VERSION = 'v1-2026-10';
-/**
- * Head-room a single wait leaves below the tool ceiling (I-4).
- *
- * `jobs.waitSeconds * 1000 + JOB_WAIT_MARGIN_MS <= toolTimeoutMs` is the whole
- * reason a wait never needs to pause the idle watchdog (D-3): a 60 s wait inside
- * a 180 s tool call in a 210 s idle window cannot be mistaken for a hang.
- *
- * IT LIVES HERE RATHER THAN IN `config/schema.ts`, where the design document put
- * it, because the TOOL layer needs the same number for its call-time convergence
- * (AC-14) and nothing in `tools/` may import `config/` - a tool takes its policy
- * through closures. One constant, two readers, no second copy to drift. Recorded
- * in `docs/plans/long-task-jobs/spec.md` under `## 实施过程发现的方案缺陷` (I-2).
- */
-export const JOB_WAIT_MARGIN_MS = 30_000;

package/dist/proc/progress.d.ts

@@ -1,40 +0,0 @@
-/**
- * Progress extraction for a long-running job (long-task-jobs §4.5).
- *
- * ASCII ONLY: `src/proc/**` is inside the glyph scanner's scope.
- *
- * PURE: no IO, no clock, no process. That is what lets `progress.test.ts`
- * enumerate the whole table, and it is why the cost of a progress line is one
- * function call inside an already-coalesced output tick rather than a second
- * subscription to the child's stdio.
- *
- * THE POINT IS EXTRACTION, NOT TRANSPORT. The alternative - handing the model
- * the last 200 rows so it can notice the `47%` itself - costs 4k-8k tokens per
- * check and buries the one number that matters. Here the ring keeps the rows and
- * the model gets `47%`.
- *
- * NOTHING DECIDES ANYTHING FROM THIS (R-4). Progress is a REPORT. `status`,
- * `exitCode` and `signal` are the only things a job's outcome is ever read from,
- * so a false `100%` in `[100%] built target foo` costs one confusing word rather
- * than a wrong conclusion.
- */
-export type ProgressKind = 'percent' | 'ratio' | 'epoch' | 'bytes' | 'text';
-export interface JobProgress {
-    /** Already clipped to `PROC_LIMITS.waitProgressChars`. */
-    text: string;
-    kind: ProgressKind;
-    /** `carry` = the not-yet-newline-terminated line, where every progress bar lives. */
-    source: 'row' | 'carry';
-    /** Index into the scanned window; `-1` for the carry line. Diagnostics and tests only. */
-    rowIndex: number;
-}
-/**
- * Extract one line of progress from the tail of a job's output.
- *
- * `rows` is the scan window (the caller passes at most
- * `PROC_LIMITS.progressScanRows`); `carry` is the not-yet-terminated line, which
- * is where a `\r`-rewritten bar keeps its whole life. Returns `undefined` when
- * nothing but decoration has been printed - an honest "there is no progress to
- * show", which the callers render as absence rather than as a fake `0%`.
- */
-export declare function extractProgress(rows: readonly string[], carry: string): JobProgress | undefined;

package/dist/proc/progress.js

@@ -1,135 +0,0 @@
-/**
- * Progress extraction for a long-running job (long-task-jobs §4.5).
- *
- * ASCII ONLY: `src/proc/**` is inside the glyph scanner's scope.
- *
- * PURE: no IO, no clock, no process. That is what lets `progress.test.ts`
- * enumerate the whole table, and it is why the cost of a progress line is one
- * function call inside an already-coalesced output tick rather than a second
- * subscription to the child's stdio.
- *
- * THE POINT IS EXTRACTION, NOT TRANSPORT. The alternative - handing the model
- * the last 200 rows so it can notice the `47%` itself - costs 4k-8k tokens per
- * check and buries the one number that matters. Here the ring keeps the rows and
- * the model gets `47%`.
- *
- * NOTHING DECIDES ANYTHING FROM THIS (R-4). Progress is a REPORT. `status`,
- * `exitCode` and `signal` are the only things a job's outcome is ever read from,
- * so a false `100%` in `[100%] built target foo` costs one confusing word rather
- * than a wrong conclusion.
- */
-import { PROC_LIMITS } from './limits.js';
-/**
- * The ordered table (first match wins PER ROW, newest row scanned first).
- *
- * BYTES SITS ABOVE THE GENERIC RATIO, and that rewrites the order the design
- * document lists. `1.2/3.4 GiB` satisfies the generic ratio pattern as `2/3`
- * (the digits either side of the slash, with `.` a word boundary), so a table
- * that tried `\d+/\d+` first would report every download as `2/3`. The document's
- * constraint - ordered, anchored, single-line, no backtracking blowup - is kept;
- * only the relative order of those two rows changed. Recorded in
- * `docs/plans/long-task-jobs/spec.md` under `## 实施过程发现的方案缺陷` (I-1).
- */
-const PERCENT = /(\d{1,3}(?:\.\d+)?)\s*%/;
-const EPOCH_STEP = /\b(epoch|step)\s+(\d{1,7})\s*\/\s*(\d{1,7})/i;
-const BYTES = /(\d+(?:\.\d+)?)\s*(GiB|MiB|KiB|GB|MB|KB|gb|mb|kb|gib|mib)?\s*\/\s*(\d+(?:\.\d+)?)\s*(GiB|MiB|KiB|GB|MB|KB|gb|mb|kb|gib|mib)/;
-const RATIO = /[\[(]?\b(\d{1,7})\s*\/\s*(\d{1,7})\b[\])]?/;
-const ETA = /ETA[^0-9]{0,4}([0-9:]+[a-z]*)/i;
-/** A row that is decoration, not information: `...`, `|`, `-`, `===`, a bare path separator. */
-const NOISE = /^[\s.\-_=|\\/+*#>~]+$/;
-/** Clip to the one-line budget, ASCII ellipsis, never mid-surrogate. */
-function clip(text, limit = PROC_LIMITS.waitProgressChars) {
-    // VERTICAL whitespace only is collapsed: a stray `\r` or `\n` would break the
-    // one-row contract, while the DOUBLE SPACE before `ETA` is how the row is meant
-    // to read (`47%  ETA 13m`) and collapsing it would make the table's rendering
-    // depend on which function ran last.
-    const flat = text.replace(/[\r\n\t]+/g, ' ').trim();
-    if (flat.length <= limit)
-        return flat;
-    return `${flat.slice(0, Math.max(0, limit - 3)).trimEnd()}...`;
-}
-/**
- * The structured signals for one line, in table order.
- *
- * ORDER WITHIN A LINE IS THE TABLE'S ORDER; the caller decides which LINE wins
- * (newest first), because a live `47%` must beat a stale `100%` from the phase
- * above it.
- */
-function signalsOf(line) {
-    const percent = PERCENT.exec(line);
-    if (percent?.[1])
-        return { text: `${percent[1]}%`, kind: 'percent' };
-    const epoch = EPOCH_STEP.exec(line);
-    if (epoch?.[1] && epoch[2] !== undefined && epoch[3] !== undefined) {
-        return { text: `${epoch[1].toLowerCase()} ${epoch[2]}/${epoch[3]}`, kind: 'epoch' };
-    }
-    const bytes = BYTES.exec(line);
-    if (bytes?.[1] && bytes[3]) {
-        // Normalised to the TOTAL's unit, which is the one the user's own command
-        // printed: `1.2/3.4 GiB` reads, `1.2 GiB/3.4 GiB` is noise. The numerator's
-        // unit is optional because the common form writes it once, at the end.
-        return { text: `${bytes[1]}/${bytes[3]} ${bytes[4]}`, kind: 'bytes' };
-    }
-    const ratio = RATIO.exec(line);
-    if (ratio?.[1] && ratio[2] !== undefined) {
-        return { text: `${ratio[1]}/${ratio[2]}`, kind: 'ratio' };
-    }
-    return undefined;
-}
-/** Append the ETA once, when the window names one. */
-function withEta(signal, window) {
-    if (signal.text.includes('ETA'))
-        return signal;
-    for (const line of window) {
-        const eta = ETA.exec(line);
-        if (eta?.[1])
-            return { text: `${signal.text}  ETA ${eta[1]}`, kind: signal.kind };
-    }
-    return signal;
-}
-/**
- * Extract one line of progress from the tail of a job's output.
- *
- * `rows` is the scan window (the caller passes at most
- * `PROC_LIMITS.progressScanRows`); `carry` is the not-yet-terminated line, which
- * is where a `\r`-rewritten bar keeps its whole life. Returns `undefined` when
- * nothing but decoration has been printed - an honest "there is no progress to
- * show", which the callers render as absence rather than as a fake `0%`.
- */
-export function extractProgress(rows, carry) {
-    const displayCarry = carry.trim();
-    // NEWEST FIRST, INSIDE ONE WINDOW. The carry line is the newest of all by
-    // definition, so it is tested before every completed row.
-    const candidates = [];
-    if (displayCarry.length > 0 && !NOISE.test(displayCarry)) {
-        candidates.push({ line: displayCarry, source: 'carry', rowIndex: -1 });
-    }
-    for (let i = rows.length - 1; i >= 0; i -= 1) {
-        const line = rows[i] ?? '';
-        if (line.trim().length === 0 || NOISE.test(line))
-            continue;
-        candidates.push({ line, source: 'row', rowIndex: i });
-    }
-    const window = candidates.map((c) => c.line);
-    for (const candidate of candidates) {
-        const signal = signalsOf(candidate.line);
-        if (!signal)
-            continue;
-        return {
-            text: clip(withEta(signal, window).text),
-            kind: signal.kind,
-            source: candidate.source,
-            rowIndex: candidate.rowIndex,
-        };
-    }
-    // Fallback: the newest line that at least says something.
-    const last = candidates[0];
-    if (!last)
-        return undefined;
-    return {
-        text: clip(last.line),
-        kind: 'text',
-        source: last.source,
-        rowIndex: last.rowIndex,
-    };
-}