charness 0.0.0-stage → 3.1.0

package/dist/utils/claudeLimitSwitch.js

@@ -0,0 +1,54 @@
+"use strict";
+/**
+ * @description Pure decisions behind SWITCHING A TOPIC TO ANOTHER CLAUDE ACCOUNT when its own hits a usage
+ * limit (`utils/claudeProfiles.ts`, `utils/claudeUsage.ts`): which profiles may take the work over, ranked by
+ * headroom, and until when the exhausted one is marked limited. This ranking is what the fallback chain
+ * (`utils/fallbackChain.ts`) falls back to when the operator configured no chain: the within-Claude
+ * account→account switch as it existed before the chain. The auto / offer decision, the notice's buttons and
+ * the auto-switch toggle (`/account`, `/fallback`; OFF by default — the operator opts in, because moving work
+ * between subscriptions is an account-policy decision) live in the chain module.
+ *
+ * No I/O, no `Date.now()`: the caller passes the clock and the profile views, so every rule is unit-tested.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.resolveClaudeAutoSwitchOnLimitEnabled = void 0;
+exports.pickClaudeLimitSwitchCandidates = pickClaudeLimitSwitchCandidates;
+exports.resolveClaudeLimitedUntil = resolveClaudeLimitedUntil;
+const claudeUsage_1 = require("./claudeUsage");
+/** The toggle's resolver (OFF when unset) lives beside `/auto_continue_limits`'s, where `state.ts` reads it. */
+var autoContinueOnLimit_1 = require("./autoContinueOnLimit");
+Object.defineProperty(exports, "resolveClaudeAutoSwitchOnLimitEnabled", { enumerable: true, get: function () { return autoContinueOnLimit_1.resolveClaudeAutoSwitchOnLimitEnabled; } });
+/**
+ * @description The profiles that may take a topic's work over, best first: signed in, not marked limited, with
+ * KNOWN and fresh usage that leaves headroom on the windows `model` drains, and not the profile that just hit
+ * the limit. A profile whose usage is unknown or stale is left out on purpose — the switch is sold as "this
+ * one has room", and a guess could land the topic in a second limit.
+ */
+function pickClaudeLimitSwitchCandidates(input) {
+    const report = (0, claudeUsage_1.buildClaudeProfilesReport)(input.profiles, input.model, input.nowMs);
+    return report.profiles
+        .filter((entry) => entry.name !== input.currentName)
+        .filter((entry) => entry.isEligible && entry.loggedIn === true && !entry.isUsageStale)
+        .filter((entry) => entry.headroomPercent !== null && entry.headroomPercent > 0)
+        .sort((a, b) => (b.headroomPercent ?? 0) - (a.headroomPercent ?? 0))
+        .map((entry) => entry.name);
+}
+/**
+ * @description Until when the profile that hit the limit is marked limited, so the ranking skips it before the
+ * window resets: the instant the error named, else the profile's own session-window reset when that lies ahead,
+ * else `fallbackMs` from now (the retry's blind delay). A mark already further in the future is kept.
+ */
+function resolveClaudeLimitedUntil(input) {
+    const sessionReset = (0, claudeUsage_1.getClaudeUsageBucket)(input.usage, 'session')?.resetsAt ?? null;
+    const sessionResetMs = sessionReset === null ? Number.NaN : Date.parse(sessionReset);
+    let untilMs = input.resetAtMs !== undefined && input.resetAtMs > input.nowMs
+        ? input.resetAtMs
+        : Number.isFinite(sessionResetMs) && sessionResetMs > input.nowMs
+            ? sessionResetMs
+            : input.nowMs + input.fallbackMs;
+    const existingMs = input.existingLimitedUntil === null ? Number.NaN : Date.parse(input.existingLimitedUntil);
+    if (Number.isFinite(existingMs) && existingMs > untilMs)
+        untilMs = existingMs;
+    return new Date(untilMs).toISOString();
+}
+//# sourceMappingURL=claudeLimitSwitch.js.map

package/dist/utils/claudeLimitSwitch.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"claudeLimitSwitch.js","sourceRoot":"","sources":["../../src/utils/claudeLimitSwitch.ts"],"names":[],"mappings":";AAAA;;;;;;;;;;GAUG;;;AAaH,0EAcC;AAOD,8DAiBC;AAjDD,+CAAuI;AAEvI,gHAAgH;AAChH,6DAA8E;AAArE,4IAAA,qCAAqC,OAAA;AAE9C;;;;;GAKG;AACH,SAAgB,+BAA+B,CAAC,KAM/C;IACC,MAAM,MAAM,GAAG,IAAA,uCAAyB,EAAC,KAAK,CAAC,QAAQ,EAAE,KAAK,CAAC,KAAK,EAAE,KAAK,CAAC,KAAK,CAAC,CAAC;IACnF,OAAO,MAAM,CAAC,QAAQ;SACnB,MAAM,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,KAAK,CAAC,IAAI,KAAK,KAAK,CAAC,WAAW,CAAC;SACnD,MAAM,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,KAAK,CAAC,UAAU,IAAI,KAAK,CAAC,QAAQ,KAAK,IAAI,IAAI,CAAC,KAAK,CAAC,YAAY,CAAC;SACrF,MAAM,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,KAAK,CAAC,eAAe,KAAK,IAAI,IAAI,KAAK,CAAC,eAAe,GAAG,CAAC,CAAC;SAC9E,IAAI,CAAC,CAAC,CAAC,EAAE,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,CAAC,eAAe,IAAI,CAAC,CAAC,GAAG,CAAC,CAAC,CAAC,eAAe,IAAI,CAAC,CAAC,CAAC;SACnE,GAAG,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC;AAChC,CAAC;AAED;;;;GAIG;AACH,SAAgB,yBAAyB,CAAC,KAMzC;IACC,MAAM,YAAY,GAAG,IAAA,kCAAoB,EAAC,KAAK,CAAC,KAAK,EAAE,SAAS,CAAC,EAAE,QAAQ,IAAI,IAAI,CAAC;IACpF,MAAM,cAAc,GAAG,YAAY,KAAK,IAAI,CAAC,CAAC,CAAC,MAAM,CAAC,GAAG,CAAC,CAAC,CAAC,IAAI,CAAC,KAAK,CAAC,YAAY,CAAC,CAAC;IACrF,IAAI,OAAO,GAAG,KAAK,CAAC,SAAS,KAAK,SAAS,IAAI,KAAK,CAAC,SAAS,GAAG,KAAK,CAAC,KAAK;QAC1E,CAAC,CAAC,KAAK,CAAC,SAAS;QACjB,CAAC,CAAC,MAAM,CAAC,QAAQ,CAAC,cAAc,CAAC,IAAI,cAAc,GAAG,KAAK,CAAC,KAAK;YAC/D,CAAC,CAAC,cAAc;YAChB,CAAC,CAAC,KAAK,CAAC,KAAK,GAAG,KAAK,CAAC,UAAU,CAAC;IACrC,MAAM,UAAU,GAAG,KAAK,CAAC,oBAAoB,KAAK,IAAI,CAAC,CAAC,CAAC,MAAM,CAAC,GAAG,CAAC,CAAC,CAAC,IAAI,CAAC,KAAK,CAAC,KAAK,CAAC,oBAAoB,CAAC,CAAC;IAC7G,IAAI,MAAM,CAAC,QAAQ,CAAC,UAAU,CAAC,IAAI,UAAU,GAAG,OAAO;QAAE,OAAO,GAAG,UAAU,CAAC;IAC9E,OAAO,IAAI,IAAI,CAAC,OAAO,CAAC,CAAC,WAAW,EAAE,CAAC;AACzC,CAAC"}

package/dist/utils/claudeLivenessAction.d.ts

@@ -0,0 +1,208 @@
+/**
+ * @description Pure decision for the Claude per-thread liveness loop: given the
+ * session's current busy state, whether a rolling status frame is on screen,
+ * whether real output is actively streaming, and whether this tick crossed a
+ * busy→idle edge, decide what the loop should do with the status frame.
+ *
+ * Why a separate machine (not folded into the status coalescer): the live bug
+ * (#11) is that a busy Claude session can show NOTHING in Telegram — the frame
+ * is emitted only opportunistically when a spinner line happens to be scraped,
+ * and `handleAgentOutput` DELETES it on every real output chunk. So while the
+ * agent keeps working after some output (or thinks quietly during the poll
+ * backoff) the topic looks idle/hung. The fix drives the frame off the cheap,
+ * reliable `checkIsBusy` footer signal instead of the scrape, and this pure
+ * function is the single owner of the create/tick/delete decision so the loop
+ * and `handleAgentOutput` can't thrash (delete→instant-recreate flicker / a
+ * 429 storm of editMessageText).
+ *
+ * Extracted from `bot.ts` so the rule is unit-testable without the
+ * Telegraf / tmux machinery (same pattern as `statusFlushDecision.ts`).
+ *
+ * @name ClaudeLivenessAction
+ *
+ * (S1/S2 — working-status un-freeze + pane-static idle removal, plan
+ * `2026-06-29-claude-working-status-liveness-and-idle-removal.md`: this module
+ * also owns {@link buildClaudeLivenessFrameText} — the frame text carries a live
+ * elapsed `m:ss` so a glyph-only tick is no longer the ONLY change the dedup
+ * strips — and {@link checkShouldForceIdleRemoval} — the 30s pane-static net.)
+ * @description
+ * - `create` — busy, no frame on screen, output not streaming: send a fresh
+ *   activity frame to the bottom of the topic (THE bug — recreate after an
+ *   output chunk deleted it while work continues).
+ * - `tick`   — busy, frame already present, output not streaming: re-edit it
+ *   so it reads as alive during a quiet thinking stretch / poll backoff.
+ * - `delete` — the session went idle (busy→idle edge or simply not busy) and a
+ *   frame is still on screen: remove it (idle-only removal).
+ * - `noop`   — nothing to do: output is actively streaming (let it own the
+ *   message — don't fight it), or the session is idle with no frame.
+ */
+export type ClaudeLivenessAction = 'create' | 'tick' | 'delete' | 'noop';
+export interface ClaudeLivenessActionInput {
+    /** Is the Claude session mid-turn right now (`adapter.checkIsBusy`)? */
+    isBusy: boolean;
+    /** Is a rolling status frame currently on screen for this thread? */
+    hasStatusFrame: boolean;
+    /** Is real agent output actively streaming (queued / debouncing / sending)? */
+    isOutputStreaming: boolean;
+    /**
+     * Did this tick observe a busy→idle edge? Folds into the same removal as
+     * `!isBusy`; kept explicit so a caller that tracks the edge (and tests) can
+     * assert the transition removes the frame even if a later poll flips busy
+     * back on.
+     */
+    idleTransition: boolean;
+    /**
+     * Idle-removal latch (S2): a previous tick force-removed the frame because
+     * the scraped pane went static for ≥ the idle threshold, so the agent is
+     * treated as idle until the next prompt re-arms activity. While latched the
+     * loop must NEVER `create`/`tick` a fresh working frame (it would resurrect
+     * the very status the 30s net just removed); a stray frame is cleaned up.
+     * Cleared on a new prompt / the next fresh liveness arm.
+     */
+    isSuppressed: boolean;
+}
+/**
+ * @description Decide what the Claude liveness loop should do this tick.
+ *
+ * Priority order matters:
+ *  1. Streaming output wins — never edit/delete the frame while output owns the
+ *     message (anti-thrash with `handleAgentOutput`'s delete-on-output).
+ *  2. Idle (edge or steady) with a frame still up → `delete` (idle-only removal;
+ *     a false-idle would reintroduce the gap, a false-busy a stuck spinner, so
+ *     the caller anchors `isBusy` to the footer signal that drops on idle).
+ *  3. Busy without a frame → `create` (the bug).
+ *  4. Busy with a frame → `tick` (keep it visibly alive).
+ *  5. Otherwise (idle, no frame) → `noop`.
+ */
+export declare function getClaudeLivenessAction(input: ClaudeLivenessActionInput): ClaudeLivenessAction;
+/**
+ * @description Whether the liveness loop may STOP after this tick. Kept separate
+ * from the create/tick/delete action because the stop decision must ALSO weigh
+ * the status COALESCER: `sendStatusFrame` stores `statusMessageId` only AFTER its
+ * network await, so a frame create can still be in flight on a tick that reads
+ * `hasStatusFrame === false`. Stopping then strands the just-sent frame with no
+ * loop left to delete it on idle — an orphan that lingers until the next message
+ * (live 2026-06-29: a hung "☁️ thinking …" whose final frame landed exactly as
+ * the agent went idle, so the idle tick saw no frame, stopped, and the send then
+ * resurrected one with nothing watching it).
+ *
+ * Stop ONLY when idle, no frame tracked, AND the coalescer is fully drained
+ * (nothing in flight, queued, or deferred behind a 429 cooldown). While any of
+ * those hold, keep ticking: the pending send lands, the next idle tick deletes
+ * the frame, and the loop then stops cleanly.
+ *
+ * S2 busy-onset arming grace: when the loop is armed by a freshly-forwarded
+ * prompt (not by a scrape emit), Claude has not flipped its footer busy signal
+ * yet, so the first tick reads idle. Without the grace the loop would self-stop
+ * immediately (idle, no frame, nothing pending) and never show a working frame
+ * for a long quiet think. While `withinArmingGrace`, NEVER stop — keep ticking
+ * until Claude goes busy (normal flow takes over) or the grace expires (then the
+ * idle stop applies as usual).
+ */
+export declare function getClaudeLivenessShouldStop(input: {
+    isBusy: boolean;
+    hasStatusFrame: boolean;
+    statusSendPending: boolean;
+    withinArmingGrace: boolean;
+}): boolean;
+/**
+ * @description Resolve what `sendStatusFrame` must do with a status message it
+ * just CREATED (a brand-new Telegram message id, from the no-existing-frame
+ * branch), once the create's `await` resolves.
+ *
+ * The bug this guards (#11 follow-up — orphaned/duplicate spinner frames): the
+ * status-frame lifecycle mutates `statusMessageId` across `await` boundaries
+ * from THREE concurrent paths — the liveness tick (`create`/`tick`), the scraped
+ * status coalescer, and `handleAgentOutput`'s delete-on-output. `sendStatusFrame`
+ * reads `statusMessageId` at entry but only writes the new id back AFTER its
+ * network `await`. If a `deleteStatusMessage` runs during that window it sees a
+ * still-`null` id (or a stale one), deletes nothing of the in-flight message, and
+ * the create then resurrects `statusMessageId` pointing at a message nothing will
+ * ever remove → an orphan left on screen after idle, and a second `create` (the
+ * next glyph tick) spawning a SEPARATE message instead of editing the one frame.
+ *
+ * Fix: a monotonic per-thread `generation`, bumped on every `deleteStatusMessage`.
+ * `sendStatusFrame` captures the generation before creating, and feeds it here
+ * with the generation observed after the `await`:
+ *  - unchanged  → `store`   : safe to record the new id as the single tracked frame.
+ *  - changed    → `discard` : a delete (idle / output-supersede) landed mid-create;
+ *                 the new message is already orphaned — delete it, DON'T store its id.
+ *
+ * Pure + tiny so the invariant ("delete during an in-flight create wins, no
+ * orphan, single tracked id") is unit-testable without the Telegraf/tmux stack.
+ */
+export type StatusFrameStoreDecision = 'store' | 'discard';
+export declare function getStatusFrameStoreDecision(generationAtCreateStart: number, generationNow: number): StatusFrameStoreDecision;
+/**
+ * @description Decide whether the liveness loop should RE-RENDER+SEND the
+ * working-status frame on this tick (S3 — cooldown-scaled throttle).
+ *
+ * Mirrors the relay output debounce ({@link ./outputFlushTiming.ts}): the 1s
+ * idle-CHECK tick must not turn into a per-second `editMessageText`, so a `tick`
+ * (frame already on screen) only re-sends after the throttle window. The window
+ * is the LONGER of the base refresh floor and the live remaining 429 cooldown —
+ * so while the chat is throttling, the status frame coalesces into one larger,
+ * later edit instead of piling more requests onto the storm (the status frame was
+ * ~half the 429-storm traffic, live 2026-06-29). A `create` (no frame yet) always
+ * sends so the indicator appears immediately, regardless of cooldown.
+ *
+ * Pure so the cadence rule is unit-testable without the Telegraf/tmux stack.
+ */
+export declare function checkShouldSendLivenessFrame(input: {
+    /** Is this a `create` (no frame on screen yet)? Then always send. */
+    isCreate: boolean;
+    /** Ms since the loop last sent the frame. */
+    msSinceLastSent: number;
+    /** Base refresh floor (`claudeWorkingStatusRefreshMs`). */
+    refreshMs: number;
+    /** Live remaining 429 cooldown for the chat, ms (0 when not limited). */
+    remainingCooldownMs: number;
+}): boolean;
+/**
+ * @description Build the Claude working-status frame text (S1 un-freeze).
+ *
+ * Root cause of the freeze: the loop rotated a leading spinner glyph each tick
+ * to look alive, but `getStatusFlushAction` STRIPS that lead glyph before its
+ * dedup compare — so when the scraped activity line had no ticking tail (a
+ * generic tool / "working…" indicator), the only thing changing was the part
+ * the dedup removed → every tick `skip`ped → the frame sat static for minutes,
+ * indistinguishable from a hung agent.
+ *
+ * Fix: append a live elapsed `m:ss` tail (reusing the shared {@link formatElapsed}
+ * the sub-agent status uses) anchored at `workingSince`. The elapsed advances
+ * every second and is NOT stripped by `stripLeadingSpinnerGlyph`, so a re-render
+ * a few seconds later differs after the glyph strip → the coalescer `send`s it →
+ * the frame visibly ticks. Prefers the scraped activity word (e.g. "Clauding…",
+ * lead glyph swapped for our rotating one) over `fallbackText` (a neutral
+ * localized "working…"). `workingSince === null` ⇒ no tail (defensive; the loop
+ * always sets it on a fresh turn).
+ */
+export declare function buildClaudeLivenessFrameText(input: {
+    /** Rotating heartbeat glyph for this tick (from `CLAUDE_LIVENESS_GLYPHS`). */
+    glyph: string;
+    /** Latest scraped activity line, or null when none has been seen this turn. */
+    activityText: string | null;
+    /** Already-localized neutral fallback (i18n `agent.workingIndicator`). */
+    fallbackText: string;
+    /** Epoch ms the current busy turn started, or null when not tracking. */
+    workingSince: number | null;
+    /** Now, epoch ms — the elapsed base for `m:ss`. */
+    nowMs: number;
+}): string;
+/**
+ * @description S2 hard anti-hang net: should the liveness loop FORCE-remove the
+ * working-status frame because the scraped TUI pane has gone static for too long?
+ *
+ * The frame is normally removed on the busy→idle edge (`getClaudeLivenessAction`
+ * `delete`), but that anchors on Claude's footer busy signal, which can wrongly
+ * stay "busy" after a turn ends — leaving a working status hanging for minutes
+ * (live 2026-06-29). A genuinely working agent keeps the pane changing every
+ * second (animated spinner + the TUI's own elapsed timer), so a pane that has
+ * NOT changed for `idlePaneThresholdMs` is idle regardless of the footer: remove
+ * the frame and stop the loop. `null` age (no live session) never triggers it.
+ */
+export declare function checkShouldForceIdleRemoval(input: {
+    msSincePaneChange: number | null;
+    idlePaneThresholdMs: number;
+}): boolean;
+//# sourceMappingURL=claudeLivenessAction.d.ts.map

package/dist/utils/claudeLivenessAction.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"claudeLivenessAction.d.ts","sourceRoot":"","sources":["../../src/utils/claudeLivenessAction.ts"],"names":[],"mappings":"AAGA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAqCG;AACH,MAAM,MAAM,oBAAoB,GAAG,QAAQ,GAAG,MAAM,GAAG,QAAQ,GAAG,MAAM,CAAC;AAEzE,MAAM,WAAW,yBAAyB;IACxC,wEAAwE;IACxE,MAAM,EAAE,OAAO,CAAC;IAChB,qEAAqE;IACrE,cAAc,EAAE,OAAO,CAAC;IACxB,+EAA+E;IAC/E,iBAAiB,EAAE,OAAO,CAAC;IAC3B;;;;;OAKG;IACH,cAAc,EAAE,OAAO,CAAC;IACxB;;;;;;;OAOG;IACH,YAAY,EAAE,OAAO,CAAC;CACvB;AAED;;;;;;;;;;;;GAYG;AACH,wBAAgB,uBAAuB,CAAC,KAAK,EAAE,yBAAyB,GAAG,oBAAoB,CAU9F;AAED;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AACH,wBAAgB,2BAA2B,CAAC,KAAK,EAAE;IACjD,MAAM,EAAE,OAAO,CAAC;IAChB,cAAc,EAAE,OAAO,CAAC;IACxB,iBAAiB,EAAE,OAAO,CAAC;IAC3B,iBAAiB,EAAE,OAAO,CAAC;CAC5B,GAAG,OAAO,CAGV;AAED;;;;;;;;;;;;;;;;;;;;;;;;;GAyBG;AACH,MAAM,MAAM,wBAAwB,GAAG,OAAO,GAAG,SAAS,CAAC;AAE3D,wBAAgB,2BAA2B,CACzC,uBAAuB,EAAE,MAAM,EAC/B,aAAa,EAAE,MAAM,GACpB,wBAAwB,CAE1B;AAED;;;;;;;;;;;;;;GAcG;AACH,wBAAgB,4BAA4B,CAAC,KAAK,EAAE;IAClD,qEAAqE;IACrE,QAAQ,EAAE,OAAO,CAAC;IAClB,6CAA6C;IAC7C,eAAe,EAAE,MAAM,CAAC;IACxB,2DAA2D;IAC3D,SAAS,EAAE,MAAM,CAAC;IAClB,yEAAyE;IACzE,mBAAmB,EAAE,MAAM,CAAC;CAC7B,GAAG,OAAO,CAGV;AAED;;;;;;;;;;;;;;;;;;GAkBG;AACH,wBAAgB,4BAA4B,CAAC,KAAK,EAAE;IAClD,8EAA8E;IAC9E,KAAK,EAAE,MAAM,CAAC;IACd,+EAA+E;IAC/E,YAAY,EAAE,MAAM,GAAG,IAAI,CAAC;IAC5B,0EAA0E;IAC1E,YAAY,EAAE,MAAM,CAAC;IACrB,yEAAyE;IACzE,YAAY,EAAE,MAAM,GAAG,IAAI,CAAC;IAC5B,mDAAmD;IACnD,KAAK,EAAE,MAAM,CAAC;CACf,GAAG,MAAM,CAUT;AAED;;;;;;;;;;;GAWG;AACH,wBAAgB,2BAA2B,CAAC,KAAK,EAAE;IACjD,iBAAiB,EAAE,MAAM,GAAG,IAAI,CAAC;IACjC,mBAAmB,EAAE,MAAM,CAAC;CAC7B,GAAG,OAAO,CAGV"}

package/dist/utils/claudeLivenessAction.js

@@ -0,0 +1,135 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.getClaudeLivenessAction = getClaudeLivenessAction;
+exports.getClaudeLivenessShouldStop = getClaudeLivenessShouldStop;
+exports.getStatusFrameStoreDecision = getStatusFrameStoreDecision;
+exports.checkShouldSendLivenessFrame = checkShouldSendLivenessFrame;
+exports.buildClaudeLivenessFrameText = buildClaudeLivenessFrameText;
+exports.checkShouldForceIdleRemoval = checkShouldForceIdleRemoval;
+const claudeScrapeShapes_1 = require("./claudeScrapeShapes");
+const subagentStatusRender_1 = require("./subagentStatusRender");
+/**
+ * @description Decide what the Claude liveness loop should do this tick.
+ *
+ * Priority order matters:
+ *  1. Streaming output wins — never edit/delete the frame while output owns the
+ *     message (anti-thrash with `handleAgentOutput`'s delete-on-output).
+ *  2. Idle (edge or steady) with a frame still up → `delete` (idle-only removal;
+ *     a false-idle would reintroduce the gap, a false-busy a stuck spinner, so
+ *     the caller anchors `isBusy` to the footer signal that drops on idle).
+ *  3. Busy without a frame → `create` (the bug).
+ *  4. Busy with a frame → `tick` (keep it visibly alive).
+ *  5. Otherwise (idle, no frame) → `noop`.
+ */
+function getClaudeLivenessAction(input) {
+    if (input.isOutputStreaming)
+        return 'noop';
+    if (!input.isBusy || input.idleTransition) {
+        return input.hasStatusFrame ? 'delete' : 'noop';
+    }
+    // Idle-removal latch (S2): the pane went static ≥ threshold this turn, so the
+    // agent is treated as idle until the next prompt. Never create/tick a fresh
+    // working frame while latched; clean up a stray one if it somehow exists.
+    if (input.isSuppressed)
+        return input.hasStatusFrame ? 'delete' : 'noop';
+    return input.hasStatusFrame ? 'tick' : 'create';
+}
+/**
+ * @description Whether the liveness loop may STOP after this tick. Kept separate
+ * from the create/tick/delete action because the stop decision must ALSO weigh
+ * the status COALESCER: `sendStatusFrame` stores `statusMessageId` only AFTER its
+ * network await, so a frame create can still be in flight on a tick that reads
+ * `hasStatusFrame === false`. Stopping then strands the just-sent frame with no
+ * loop left to delete it on idle — an orphan that lingers until the next message
+ * (live 2026-06-29: a hung "☁️ thinking …" whose final frame landed exactly as
+ * the agent went idle, so the idle tick saw no frame, stopped, and the send then
+ * resurrected one with nothing watching it).
+ *
+ * Stop ONLY when idle, no frame tracked, AND the coalescer is fully drained
+ * (nothing in flight, queued, or deferred behind a 429 cooldown). While any of
+ * those hold, keep ticking: the pending send lands, the next idle tick deletes
+ * the frame, and the loop then stops cleanly.
+ *
+ * S2 busy-onset arming grace: when the loop is armed by a freshly-forwarded
+ * prompt (not by a scrape emit), Claude has not flipped its footer busy signal
+ * yet, so the first tick reads idle. Without the grace the loop would self-stop
+ * immediately (idle, no frame, nothing pending) and never show a working frame
+ * for a long quiet think. While `withinArmingGrace`, NEVER stop — keep ticking
+ * until Claude goes busy (normal flow takes over) or the grace expires (then the
+ * idle stop applies as usual).
+ */
+function getClaudeLivenessShouldStop(input) {
+    if (input.withinArmingGrace)
+        return false;
+    return !input.isBusy && !input.hasStatusFrame && !input.statusSendPending;
+}
+function getStatusFrameStoreDecision(generationAtCreateStart, generationNow) {
+    return generationAtCreateStart === generationNow ? 'store' : 'discard';
+}
+/**
+ * @description Decide whether the liveness loop should RE-RENDER+SEND the
+ * working-status frame on this tick (S3 — cooldown-scaled throttle).
+ *
+ * Mirrors the relay output debounce ({@link ./outputFlushTiming.ts}): the 1s
+ * idle-CHECK tick must not turn into a per-second `editMessageText`, so a `tick`
+ * (frame already on screen) only re-sends after the throttle window. The window
+ * is the LONGER of the base refresh floor and the live remaining 429 cooldown —
+ * so while the chat is throttling, the status frame coalesces into one larger,
+ * later edit instead of piling more requests onto the storm (the status frame was
+ * ~half the 429-storm traffic, live 2026-06-29). A `create` (no frame yet) always
+ * sends so the indicator appears immediately, regardless of cooldown.
+ *
+ * Pure so the cadence rule is unit-testable without the Telegraf/tmux stack.
+ */
+function checkShouldSendLivenessFrame(input) {
+    if (input.isCreate)
+        return true;
+    return input.msSinceLastSent >= Math.max(input.refreshMs, input.remainingCooldownMs);
+}
+/**
+ * @description Build the Claude working-status frame text (S1 un-freeze).
+ *
+ * Root cause of the freeze: the loop rotated a leading spinner glyph each tick
+ * to look alive, but `getStatusFlushAction` STRIPS that lead glyph before its
+ * dedup compare — so when the scraped activity line had no ticking tail (a
+ * generic tool / "working…" indicator), the only thing changing was the part
+ * the dedup removed → every tick `skip`ped → the frame sat static for minutes,
+ * indistinguishable from a hung agent.
+ *
+ * Fix: append a live elapsed `m:ss` tail (reusing the shared {@link formatElapsed}
+ * the sub-agent status uses) anchored at `workingSince`. The elapsed advances
+ * every second and is NOT stripped by `stripLeadingSpinnerGlyph`, so a re-render
+ * a few seconds later differs after the glyph strip → the coalescer `send`s it →
+ * the frame visibly ticks. Prefers the scraped activity word (e.g. "Clauding…",
+ * lead glyph swapped for our rotating one) over `fallbackText` (a neutral
+ * localized "working…"). `workingSince === null` ⇒ no tail (defensive; the loop
+ * always sets it on a fresh turn).
+ */
+function buildClaudeLivenessFrameText(input) {
+    const elapsedSuffix = input.workingSince === null ? '' : ` · ${(0, subagentStatusRender_1.formatElapsed)(input.nowMs - input.workingSince)}`;
+    const activity = input.activityText?.trim();
+    if (activity) {
+        // Swap the scrape's own leading spinner glyph for our rotating one so the
+        // heartbeat shows while preserving the activity word + any scraped tail.
+        return `${input.glyph} ${(0, claudeScrapeShapes_1.stripLeadingSpinnerGlyph)(activity)}${elapsedSuffix}`;
+    }
+    return `${input.fallbackText}${elapsedSuffix}`;
+}
+/**
+ * @description S2 hard anti-hang net: should the liveness loop FORCE-remove the
+ * working-status frame because the scraped TUI pane has gone static for too long?
+ *
+ * The frame is normally removed on the busy→idle edge (`getClaudeLivenessAction`
+ * `delete`), but that anchors on Claude's footer busy signal, which can wrongly
+ * stay "busy" after a turn ends — leaving a working status hanging for minutes
+ * (live 2026-06-29). A genuinely working agent keeps the pane changing every
+ * second (animated spinner + the TUI's own elapsed timer), so a pane that has
+ * NOT changed for `idlePaneThresholdMs` is idle regardless of the footer: remove
+ * the frame and stop the loop. `null` age (no live session) never triggers it.
+ */
+function checkShouldForceIdleRemoval(input) {
+    if (input.msSincePaneChange === null)
+        return false;
+    return input.msSincePaneChange >= input.idlePaneThresholdMs;
+}
+//# sourceMappingURL=claudeLivenessAction.js.map

package/dist/utils/claudeLivenessAction.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"claudeLivenessAction.js","sourceRoot":"","sources":["../../src/utils/claudeLivenessAction.ts"],"names":[],"mappings":";;AAiFA,0DAUC;AA0BD,kEAQC;AA8BD,kEAKC;AAiBD,oEAYC;AAqBD,oEAqBC;AAcD,kEAMC;AA3PD,6DAAgE;AAChE,iEAAuD;AAmEvD;;;;;;;;;;;;GAYG;AACH,SAAgB,uBAAuB,CAAC,KAAgC;IACtE,IAAI,KAAK,CAAC,iBAAiB;QAAE,OAAO,MAAM,CAAC;IAC3C,IAAI,CAAC,KAAK,CAAC,MAAM,IAAI,KAAK,CAAC,cAAc,EAAE,CAAC;QAC1C,OAAO,KAAK,CAAC,cAAc,CAAC,CAAC,CAAC,QAAQ,CAAC,CAAC,CAAC,MAAM,CAAC;IAClD,CAAC;IACD,8EAA8E;IAC9E,4EAA4E;IAC5E,0EAA0E;IAC1E,IAAI,KAAK,CAAC,YAAY;QAAE,OAAO,KAAK,CAAC,cAAc,CAAC,CAAC,CAAC,QAAQ,CAAC,CAAC,CAAC,MAAM,CAAC;IACxE,OAAO,KAAK,CAAC,cAAc,CAAC,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,QAAQ,CAAC;AAClD,CAAC;AAED;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AACH,SAAgB,2BAA2B,CAAC,KAK3C;IACC,IAAI,KAAK,CAAC,iBAAiB;QAAE,OAAO,KAAK,CAAC;IAC1C,OAAO,CAAC,KAAK,CAAC,MAAM,IAAI,CAAC,KAAK,CAAC,cAAc,IAAI,CAAC,KAAK,CAAC,iBAAiB,CAAC;AAC5E,CAAC;AA8BD,SAAgB,2BAA2B,CACzC,uBAA+B,EAC/B,aAAqB;IAErB,OAAO,uBAAuB,KAAK,aAAa,CAAC,CAAC,CAAC,OAAO,CAAC,CAAC,CAAC,SAAS,CAAC;AACzE,CAAC;AAED;;;;;;;;;;;;;;GAcG;AACH,SAAgB,4BAA4B,CAAC,KAS5C;IACC,IAAI,KAAK,CAAC,QAAQ;QAAE,OAAO,IAAI,CAAC;IAChC,OAAO,KAAK,CAAC,eAAe,IAAI,IAAI,CAAC,GAAG,CAAC,KAAK,CAAC,SAAS,EAAE,KAAK,CAAC,mBAAmB,CAAC,CAAC;AACvF,CAAC;AAED;;;;;;;;;;;;;;;;;;GAkBG;AACH,SAAgB,4BAA4B,CAAC,KAW5C;IACC,MAAM,aAAa,GACjB,KAAK,CAAC,YAAY,KAAK,IAAI,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC,MAAM,IAAA,oCAAa,EAAC,KAAK,CAAC,KAAK,GAAG,KAAK,CAAC,YAAY,CAAC,EAAE,CAAC;IAC7F,MAAM,QAAQ,GAAG,KAAK,CAAC,YAAY,EAAE,IAAI,EAAE,CAAC;IAC5C,IAAI,QAAQ,EAAE,CAAC;QACb,0EAA0E;QAC1E,yEAAyE;QACzE,OAAO,GAAG,KAAK,CAAC,KAAK,IAAI,IAAA,6CAAwB,EAAC,QAAQ,CAAC,GAAG,aAAa,EAAE,CAAC;IAChF,CAAC;IACD,OAAO,GAAG,KAAK,CAAC,YAAY,GAAG,aAAa,EAAE,CAAC;AACjD,CAAC;AAED;;;;;;;;;;;GAWG;AACH,SAAgB,2BAA2B,CAAC,KAG3C;IACC,IAAI,KAAK,CAAC,iBAAiB,KAAK,IAAI;QAAE,OAAO,KAAK,CAAC;IACnD,OAAO,KAAK,CAAC,iBAAiB,IAAI,KAAK,CAAC,mBAAmB,CAAC;AAC9D,CAAC"}

package/dist/utils/claudeMcpHeal.d.ts

@@ -0,0 +1,92 @@
+/**
+ * @description The wire shapes + the decision behind healing a `claude` session
+ * whose bot-injected MCP server (`telegramBot`) has latched `failed`.
+ *
+ * WHY this exists: a json-stream session is an EXTERNAL process, so it survives
+ * every bot restart — but the MCP client inside it does not retry a server it
+ * once failed to reach. A session that was alive across a restart therefore kept
+ * reporting `{name:'telegramBot', status:'failed'}` for the rest of its life and
+ * lost `schedule_*` / `compact_conversation` / `send_file_to_user` /
+ * `send_messages_to_user` with nothing short of replacing the session to bring
+ * them back. The CLI answers `mcp_status` / `mcp_reconnect` on the SAME stdio
+ * control channel the adapter already uses for permissions, and a reconnect
+ * measurably moves the server `failed` → `connected`.
+ *
+ * The request/response format is reverse-engineered (measured against a live
+ * `claude` process, not documented anywhere), so it lives in exactly ONE tested
+ * place — the adapter only mints ids, writes the frames, and reads the verdict.
+ * Pure: no IO, no timers, no adapter imports.
+ */
+/**
+ * @description How long to wait for ONE control round-trip before treating the
+ * server status as unknown. The channel is loopback stdio answered by a process
+ * that is already running, so a healthy reply lands in milliseconds — this is a
+ * generous upper bound that keeps a silent CLI from hanging the caller, not a
+ * tuning knob.
+ */
+export declare const mcpControlRequestTimeoutMs = 15000;
+/** `mcp_status` — ask the CLI for every MCP server it holds and its state. */
+export interface McpStatusControlRequest {
+    type: 'control_request';
+    request_id: string;
+    request: {
+        subtype: 'mcp_status';
+    };
+}
+/** `mcp_reconnect` — make the CLI re-handshake ONE server by name. */
+export interface McpReconnectControlRequest {
+    type: 'control_request';
+    request_id: string;
+    request: {
+        subtype: 'mcp_reconnect';
+        serverName: string;
+    };
+}
+/**
+ * @name McpHealDecision
+ * @description What to do about one server's reported status.
+ */
+export type McpHealDecision = 'reconnect' | 'healthy' | 'skip';
+/**
+ * @name McpHealOutcome
+ * @description What a heal attempt actually achieved — the adapter method's
+ * result, so a caller can log only the sessions it really repaired.
+ *  - `healed` — the server was `failed` and the reconnect answered success.
+ *  - `healthy` — nothing was wrong, no frame written beyond the status ask.
+ *  - `skipped` — the status says a reconnect is not the right move
+ *    ({@link decideMcpHeal}).
+ *  - `unavailable` — the heal could not be completed: no live session, the CLI
+ *    never answered (or refused) the status ask, or the reconnect itself was
+ *    refused. In every case the server is still whatever it was.
+ */
+export type McpHealOutcome = 'healed' | 'healthy' | 'skipped' | 'unavailable';
+/** Build the `mcp_status` control request (`requestId` is echoed back in the
+ *  response's `request_id`, which is how the reply is matched). */
+export declare function buildMcpStatusControlRequest(requestId: string): McpStatusControlRequest;
+/** Build the `mcp_reconnect` control request for ONE server. `serverName` is
+ *  camelCase on the wire (unlike the snake_case envelope fields). */
+export declare function buildMcpReconnectControlRequest(requestId: string, serverName: string): McpReconnectControlRequest;
+/**
+ * @description Read one server's `status` out of an `mcp_status` response
+ * payload (`{mcpServers:[{name, status, …}]}`). Returns `null` when the payload
+ * is absent / not the expected shape, when no entry carries that name, or when
+ * the entry has no string status — every one of which means "unknown", which
+ * {@link decideMcpHeal} deliberately refuses to act on.
+ */
+export declare function getMcpServerStatus(payload: Record<string, unknown> | null, serverName: string): string | null;
+/**
+ * @description Decide what a reported MCP server status calls for.
+ *
+ *  - `connected` → `healthy`: the server completed its handshake, so touching it
+ *    would only risk interrupting live tools.
+ *  - `failed` → `reconnect`: the exact latched state this whole path exists for —
+ *    the CLI never retries it on its own, and a reconnect is measurably what
+ *    brings the tools back.
+ *  - `needs-auth` → `skip`: a human must authorise that server; reconnecting
+ *    would fail again immediately and loop.
+ *  - anything else, INCLUDING `null` → `skip`: an unknown or unreadable status
+ *    must never be guessed into a live session. A future status name is then
+ *    inert rather than wrongly acted on.
+ */
+export declare function decideMcpHeal(status: string | null): McpHealDecision;
+//# sourceMappingURL=claudeMcpHeal.d.ts.map

package/dist/utils/claudeMcpHeal.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"claudeMcpHeal.d.ts","sourceRoot":"","sources":["../../src/utils/claudeMcpHeal.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;GAkBG;AAIH;;;;;;GAMG;AACH,eAAO,MAAM,0BAA0B,QAAQ,CAAC;AAEhD,8EAA8E;AAC9E,MAAM,WAAW,uBAAuB;IACtC,IAAI,EAAE,iBAAiB,CAAC;IACxB,UAAU,EAAE,MAAM,CAAC;IACnB,OAAO,EAAE;QAAE,OAAO,EAAE,YAAY,CAAA;KAAE,CAAC;CACpC;AAED,sEAAsE;AACtE,MAAM,WAAW,0BAA0B;IACzC,IAAI,EAAE,iBAAiB,CAAC;IACxB,UAAU,EAAE,MAAM,CAAC;IACnB,OAAO,EAAE;QAAE,OAAO,EAAE,eAAe,CAAC;QAAC,UAAU,EAAE,MAAM,CAAA;KAAE,CAAC;CAC3D;AAED;;;GAGG;AACH,MAAM,MAAM,eAAe,GAAG,WAAW,GAAG,SAAS,GAAG,MAAM,CAAC;AAE/D;;;;;;;;;;;GAWG;AACH,MAAM,MAAM,cAAc,GAAG,QAAQ,GAAG,SAAS,GAAG,SAAS,GAAG,aAAa,CAAC;AAO9E;mEACmE;AACnE,wBAAgB,4BAA4B,CAAC,SAAS,EAAE,MAAM,GAAG,uBAAuB,CAEvF;AAED;qEACqE;AACrE,wBAAgB,+BAA+B,CAAC,SAAS,EAAE,MAAM,EAAE,UAAU,EAAE,MAAM,GAAG,0BAA0B,CAEjH;AAED;;;;;;GAMG;AACH,wBAAgB,kBAAkB,CAAC,OAAO,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,GAAG,IAAI,EAAE,UAAU,EAAE,MAAM,GAAG,MAAM,GAAG,IAAI,CAS7G;AAED;;;;;;;;;;;;;GAaG;AACH,wBAAgB,aAAa,CAAC,MAAM,EAAE,MAAM,GAAG,IAAI,GAAG,eAAe,CAIpE"}

package/dist/utils/claudeMcpHeal.js

@@ -0,0 +1,91 @@
+"use strict";
+/**
+ * @description The wire shapes + the decision behind healing a `claude` session
+ * whose bot-injected MCP server (`telegramBot`) has latched `failed`.
+ *
+ * WHY this exists: a json-stream session is an EXTERNAL process, so it survives
+ * every bot restart — but the MCP client inside it does not retry a server it
+ * once failed to reach. A session that was alive across a restart therefore kept
+ * reporting `{name:'telegramBot', status:'failed'}` for the rest of its life and
+ * lost `schedule_*` / `compact_conversation` / `send_file_to_user` /
+ * `send_messages_to_user` with nothing short of replacing the session to bring
+ * them back. The CLI answers `mcp_status` / `mcp_reconnect` on the SAME stdio
+ * control channel the adapter already uses for permissions, and a reconnect
+ * measurably moves the server `failed` → `connected`.
+ *
+ * The request/response format is reverse-engineered (measured against a live
+ * `claude` process, not documented anywhere), so it lives in exactly ONE tested
+ * place — the adapter only mints ids, writes the frames, and reads the verdict.
+ * Pure: no IO, no timers, no adapter imports.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.mcpControlRequestTimeoutMs = void 0;
+exports.buildMcpStatusControlRequest = buildMcpStatusControlRequest;
+exports.buildMcpReconnectControlRequest = buildMcpReconnectControlRequest;
+exports.getMcpServerStatus = getMcpServerStatus;
+exports.decideMcpHeal = decideMcpHeal;
+const claudeStreamJson_1 = require("./claudeStreamJson");
+/**
+ * @description How long to wait for ONE control round-trip before treating the
+ * server status as unknown. The channel is loopback stdio answered by a process
+ * that is already running, so a healthy reply lands in milliseconds — this is a
+ * generous upper bound that keeps a silent CLI from hanging the caller, not a
+ * tuning knob.
+ */
+exports.mcpControlRequestTimeoutMs = 15000;
+/** The status of a server that completed its handshake — nothing to do. */
+const mcpStatusConnected = 'connected';
+/** The status of a server whose connection attempt failed and is never retried. */
+const mcpStatusFailed = 'failed';
+/** Build the `mcp_status` control request (`requestId` is echoed back in the
+ *  response's `request_id`, which is how the reply is matched). */
+function buildMcpStatusControlRequest(requestId) {
+    return { type: 'control_request', request_id: requestId, request: { subtype: 'mcp_status' } };
+}
+/** Build the `mcp_reconnect` control request for ONE server. `serverName` is
+ *  camelCase on the wire (unlike the snake_case envelope fields). */
+function buildMcpReconnectControlRequest(requestId, serverName) {
+    return { type: 'control_request', request_id: requestId, request: { subtype: 'mcp_reconnect', serverName } };
+}
+/**
+ * @description Read one server's `status` out of an `mcp_status` response
+ * payload (`{mcpServers:[{name, status, …}]}`). Returns `null` when the payload
+ * is absent / not the expected shape, when no entry carries that name, or when
+ * the entry has no string status — every one of which means "unknown", which
+ * {@link decideMcpHeal} deliberately refuses to act on.
+ */
+function getMcpServerStatus(payload, serverName) {
+    if (!payload)
+        return null;
+    const servers = payload.mcpServers;
+    if (!Array.isArray(servers))
+        return null;
+    for (const entry of servers) {
+        if (!(0, claudeStreamJson_1.checkIsStreamRecord)(entry) || entry.name !== serverName)
+            continue;
+        return typeof entry.status === 'string' ? entry.status : null;
+    }
+    return null;
+}
+/**
+ * @description Decide what a reported MCP server status calls for.
+ *
+ *  - `connected` → `healthy`: the server completed its handshake, so touching it
+ *    would only risk interrupting live tools.
+ *  - `failed` → `reconnect`: the exact latched state this whole path exists for —
+ *    the CLI never retries it on its own, and a reconnect is measurably what
+ *    brings the tools back.
+ *  - `needs-auth` → `skip`: a human must authorise that server; reconnecting
+ *    would fail again immediately and loop.
+ *  - anything else, INCLUDING `null` → `skip`: an unknown or unreadable status
+ *    must never be guessed into a live session. A future status name is then
+ *    inert rather than wrongly acted on.
+ */
+function decideMcpHeal(status) {
+    if (status === mcpStatusConnected)
+        return 'healthy';
+    if (status === mcpStatusFailed)
+        return 'reconnect';
+    return 'skip';
+}
+//# sourceMappingURL=claudeMcpHeal.js.map

package/dist/utils/claudeMcpHeal.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"claudeMcpHeal.js","sourceRoot":"","sources":["../../src/utils/claudeMcpHeal.ts"],"names":[],"mappings":";AAAA;;;;;;;;;;;;;;;;;;GAkBG;;;AAsDH,oEAEC;AAID,0EAEC;AASD,gDASC;AAgBD,sCAIC;AAlGD,yDAAyD;AAEzD;;;;;;GAMG;AACU,QAAA,0BAA0B,GAAG,KAAK,CAAC;AAoChD,2EAA2E;AAC3E,MAAM,kBAAkB,GAAG,WAAW,CAAC;AACvC,mFAAmF;AACnF,MAAM,eAAe,GAAG,QAAQ,CAAC;AAEjC;mEACmE;AACnE,SAAgB,4BAA4B,CAAC,SAAiB;IAC5D,OAAO,EAAE,IAAI,EAAE,iBAAiB,EAAE,UAAU,EAAE,SAAS,EAAE,OAAO,EAAE,EAAE,OAAO,EAAE,YAAY,EAAE,EAAE,CAAC;AAChG,CAAC;AAED;qEACqE;AACrE,SAAgB,+BAA+B,CAAC,SAAiB,EAAE,UAAkB;IACnF,OAAO,EAAE,IAAI,EAAE,iBAAiB,EAAE,UAAU,EAAE,SAAS,EAAE,OAAO,EAAE,EAAE,OAAO,EAAE,eAAe,EAAE,UAAU,EAAE,EAAE,CAAC;AAC/G,CAAC;AAED;;;;;;GAMG;AACH,SAAgB,kBAAkB,CAAC,OAAuC,EAAE,UAAkB;IAC5F,IAAI,CAAC,OAAO;QAAE,OAAO,IAAI,CAAC;IAC1B,MAAM,OAAO,GAAG,OAAO,CAAC,UAAU,CAAC;IACnC,IAAI,CAAC,KAAK,CAAC,OAAO,CAAC,OAAO,CAAC;QAAE,OAAO,IAAI,CAAC;IACzC,KAAK,MAAM,KAAK,IAAI,OAAO,EAAE,CAAC;QAC5B,IAAI,CAAC,IAAA,sCAAmB,EAAC,KAAK,CAAC,IAAI,KAAK,CAAC,IAAI,KAAK,UAAU;YAAE,SAAS;QACvE,OAAO,OAAO,KAAK,CAAC,MAAM,KAAK,QAAQ,CAAC,CAAC,CAAC,KAAK,CAAC,MAAM,CAAC,CAAC,CAAC,IAAI,CAAC;IAChE,CAAC;IACD,OAAO,IAAI,CAAC;AACd,CAAC;AAED;;;;;;;;;;;;;GAaG;AACH,SAAgB,aAAa,CAAC,MAAqB;IACjD,IAAI,MAAM,KAAK,kBAAkB;QAAE,OAAO,SAAS,CAAC;IACpD,IAAI,MAAM,KAAK,eAAe;QAAE,OAAO,WAAW,CAAC;IACnD,OAAO,MAAM,CAAC;AAChB,CAAC"}

package/dist/utils/claudeProfileUsageLines.d.ts

@@ -0,0 +1,15 @@
+import { type ClaudeUsageSnapshot } from './claudeUsage';
+/** What the lines read of a profile: its usage snapshot and limit mark (a state record and a usage view both fit). */
+export interface ClaudeProfileUsageSource {
+    usage?: ClaudeUsageSnapshot;
+    limitedUntil?: string | null;
+}
+/**
+ * @description The profile's usage as display lines: the windows as `used% 🔄 reset` — 5h and weekly always (`—`
+ * for one the snapshot lacks), Fable only when the account HAS that window (a corporate seat has none: nothing
+ * is written about it) — `(stale)` when the last poll could not refresh, and the limit mark while it holds, the
+ * reset instant in `timezone`. The lines carry the locale's own indentation (they hang under a row); empty for a
+ * profile never polled and not limited.
+ */
+export declare function formatClaudeProfileUsageLines(source: ClaudeProfileUsageSource | undefined, timezone: string, nowMs: number): string[];
+//# sourceMappingURL=claudeProfileUsageLines.d.ts.map

package/dist/utils/claudeProfileUsageLines.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"claudeProfileUsageLines.d.ts","sourceRoot":"","sources":["../../src/utils/claudeProfileUsageLines.ts"],"names":[],"mappings":"AAKA,OAAO,EAML,KAAK,mBAAmB,EACzB,MAAM,eAAe,CAAC;AAEvB,sHAAsH;AACtH,MAAM,WAAW,wBAAwB;IACvC,KAAK,CAAC,EAAE,mBAAmB,CAAC;IAC5B,YAAY,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;CAC9B;AAOD;;;;;;GAMG;AACH,wBAAgB,6BAA6B,CAAC,MAAM,EAAE,wBAAwB,GAAG,SAAS,EAAE,QAAQ,EAAE,MAAM,EAAE,KAAK,EAAE,MAAM,GAAG,MAAM,EAAE,CAoBrI"}