waterplane 0.0.1 → 0.1.6

package/node_modules/@waterplane/shared/dist/queue/queueretry.d.ts

@@ -0,0 +1,61 @@
+/** Backoff floor/ceiling for a requeued entry. Doubling from 2 s to 60 s: fast
+ *  enough that a blip costs one flush, slow enough that a permanently broken
+ *  request stops being a busy-loop. */
+export declare const RETRY_BACKOFF_MS = 2000;
+export declare const RETRY_BACKOFF_MAX_MS = 60000;
+/** When may an entry that just failed be tried again? */
+export declare function retryDelay(tries: number): number;
+/**
+ * The floor under giving up: a delivery is never declared undelivered until it
+ * has been TRYING for at least this long.
+ *
+ * The attempts cap alone is a count, and a count is not a duration. Eight
+ * receipt windows on a bad radio — each one a socket that went away mid-flight,
+ * none of them a host that said no — could run out inside a few seconds of
+ * wall-clock and put a red "delivery kept failing" row on screen while the link
+ * was still coming back. From the phone that reads as a fatal verdict on words
+ * you just typed, and it is nothing of the kind.
+ *
+ * So the two bounds are ANDed: the host must have refused it `maxAttempts`
+ * times AND a minute must have passed since the first attempt. Past that the
+ * entry still does not die — see `roundDelay`.
+ */
+export declare const MIN_TRY_MS = 60000;
+/**
+ * How long an entry waits before trying the whole attempts ladder AGAIN.
+ *
+ * Exhausting the ladder means the host never answered — a refusal it did
+ * answer is failed by the client on the spot and never reaches here. "Never
+ * answered" is a statement about the link, and a link that is down now is the
+ * one condition this queue exists to ride out, so the answer is to wait longer,
+ * not to stop: 5 minutes, doubling, capped at half an hour, for ever.
+ *
+ * Safe to repeat because delivery is keyed on `ackId` in the host's durable
+ * Intent store — a re-send of something it already ran is re-acked, never typed
+ * twice. Do not raise the cap without checking that ledger still outlives it.
+ */
+export declare const RETRY_ROUND_MS: number;
+export declare const RETRY_ROUND_MAX_MS: number;
+export declare function roundDelay(round: number): number;
+/**
+ * Did this failed upload attempt actually PROVE anything about the file?
+ *
+ * `MAX_SEND_ATTEMPTS` exists to stop retrying something the host keeps
+ * rejecting. It must never be spent on the link being down, because riding out
+ * a dead link is the queue's entire job — and eight attempts on the client's
+ * 5 s sweep is under a minute, so a host restart (or a tunnel blip) could burn
+ * the budget and fail an image outright while the network was fine either side
+ * of it.
+ *
+ * Only an ANSWER counts. A status — any status, including a 500 — means the
+ * host heard this upload and decided; a transport error means nobody decided.
+ * `socketOpen` is deliberately not sufficient on its own: a host being
+ * restarted kills the POST a moment before its WebSocket close event lands, so
+ * the socket still reads "open" for exactly the window in which uploads die.
+ * A stall is wasted too — the client aborted it, so there is no verdict.
+ */
+export declare function uploadAttemptWasted(o: {
+    responded?: boolean;
+    stalled?: boolean;
+    socketOpen: boolean;
+}): boolean;

package/node_modules/@waterplane/shared/dist/queue/queueretry.js

@@ -0,0 +1,66 @@
+// Cut from queue.ts (move only): the retry contract
+// The one door stays `./queue.js`; this slice imports its siblings directly, never the barrel.
+/** Backoff floor/ceiling for a requeued entry. Doubling from 2 s to 60 s: fast
+ *  enough that a blip costs one flush, slow enough that a permanently broken
+ *  request stops being a busy-loop. */
+export const RETRY_BACKOFF_MS = 2000;
+export const RETRY_BACKOFF_MAX_MS = 60000;
+/** When may an entry that just failed be tried again? */
+export function retryDelay(tries) {
+    return Math.min(RETRY_BACKOFF_MAX_MS, RETRY_BACKOFF_MS * Math.pow(2, Math.max(0, tries - 1)));
+}
+/**
+ * The floor under giving up: a delivery is never declared undelivered until it
+ * has been TRYING for at least this long.
+ *
+ * The attempts cap alone is a count, and a count is not a duration. Eight
+ * receipt windows on a bad radio — each one a socket that went away mid-flight,
+ * none of them a host that said no — could run out inside a few seconds of
+ * wall-clock and put a red "delivery kept failing" row on screen while the link
+ * was still coming back. From the phone that reads as a fatal verdict on words
+ * you just typed, and it is nothing of the kind.
+ *
+ * So the two bounds are ANDed: the host must have refused it `maxAttempts`
+ * times AND a minute must have passed since the first attempt. Past that the
+ * entry still does not die — see `roundDelay`.
+ */
+export const MIN_TRY_MS = 60_000;
+/**
+ * How long an entry waits before trying the whole attempts ladder AGAIN.
+ *
+ * Exhausting the ladder means the host never answered — a refusal it did
+ * answer is failed by the client on the spot and never reaches here. "Never
+ * answered" is a statement about the link, and a link that is down now is the
+ * one condition this queue exists to ride out, so the answer is to wait longer,
+ * not to stop: 5 minutes, doubling, capped at half an hour, for ever.
+ *
+ * Safe to repeat because delivery is keyed on `ackId` in the host's durable
+ * Intent store — a re-send of something it already ran is re-acked, never typed
+ * twice. Do not raise the cap without checking that ledger still outlives it.
+ */
+export const RETRY_ROUND_MS = 5 * 60_000;
+export const RETRY_ROUND_MAX_MS = 30 * 60_000;
+export function roundDelay(round) {
+    return Math.min(RETRY_ROUND_MAX_MS, RETRY_ROUND_MS * Math.pow(2, Math.max(0, round - 1)));
+}
+/**
+ * Did this failed upload attempt actually PROVE anything about the file?
+ *
+ * `MAX_SEND_ATTEMPTS` exists to stop retrying something the host keeps
+ * rejecting. It must never be spent on the link being down, because riding out
+ * a dead link is the queue's entire job — and eight attempts on the client's
+ * 5 s sweep is under a minute, so a host restart (or a tunnel blip) could burn
+ * the budget and fail an image outright while the network was fine either side
+ * of it.
+ *
+ * Only an ANSWER counts. A status — any status, including a 500 — means the
+ * host heard this upload and decided; a transport error means nobody decided.
+ * `socketOpen` is deliberately not sufficient on its own: a host being
+ * restarted kills the POST a moment before its WebSocket close event lands, so
+ * the socket still reads "open" for exactly the window in which uploads die.
+ * A stall is wasted too — the client aborted it, so there is no verdict.
+ */
+export function uploadAttemptWasted(o) {
+    return !!o.stalled || !o.responded || !o.socketOpen;
+}
+//# sourceMappingURL=queueretry.js.map

package/node_modules/@waterplane/shared/dist/queue/queueretry.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"queueretry.js","sourceRoot":"","sources":["../../src/queue/queueretry.ts"],"names":[],"mappings":"AAAA,oDAAoD;AACpD,+FAA+F;AAE/F;;uCAEuC;AACvC,MAAM,CAAC,MAAM,gBAAgB,GAAG,IAAI,CAAC;AACrC,MAAM,CAAC,MAAM,oBAAoB,GAAG,KAAK,CAAC;AAE1C,yDAAyD;AACzD,MAAM,UAAU,UAAU,CAAC,KAAa;IACtC,OAAO,IAAI,CAAC,GAAG,CAAC,oBAAoB,EAAE,gBAAgB,GAAG,IAAI,CAAC,GAAG,CAAC,CAAC,EAAE,IAAI,CAAC,GAAG,CAAC,CAAC,EAAE,KAAK,GAAG,CAAC,CAAC,CAAC,CAAC,CAAC;AAChG,CAAC;AAED;;;;;;;;;;;;;;GAcG;AACH,MAAM,CAAC,MAAM,UAAU,GAAG,MAAM,CAAC;AAEjC;;;;;;;;;;;;GAYG;AACH,MAAM,CAAC,MAAM,cAAc,GAAG,CAAC,GAAG,MAAM,CAAC;AACzC,MAAM,CAAC,MAAM,kBAAkB,GAAG,EAAE,GAAG,MAAM,CAAC;AAE9C,MAAM,UAAU,UAAU,CAAC,KAAa;IACtC,OAAO,IAAI,CAAC,GAAG,CAAC,kBAAkB,EAAE,cAAc,GAAG,IAAI,CAAC,GAAG,CAAC,CAAC,EAAE,IAAI,CAAC,GAAG,CAAC,CAAC,EAAE,KAAK,GAAG,CAAC,CAAC,CAAC,CAAC,CAAC;AAC5F,CAAC;AAED;;;;;;;;;;;;;;;;GAgBG;AACH,MAAM,UAAU,mBAAmB,CAAC,CAAkE;IACpG,OAAO,CAAC,CAAC,CAAC,CAAC,OAAO,IAAI,CAAC,CAAC,CAAC,SAAS,IAAI,CAAC,CAAC,CAAC,UAAU,CAAC;AACtD,CAAC"}

package/node_modules/@waterplane/shared/dist/queue/queueserial.d.ts

@@ -0,0 +1,154 @@
+import { type LaneSessionState, type SessionWall } from "./queuelane.js";
+/**
+ * The serialization group for a working directory.
+ *
+ * The REPO DIRECTORY, not the repo: a worktree is a separate checkout, and
+ * making one per task is exactly how this app already runs work in parallel
+ * safely (`parallel` backlog mode). Two sessions in two worktrees cannot write
+ * over each other, so they are not each other's business — the only thing they
+ * share is the usage limit, and that is a knob, not a rule.
+ */
+export declare function serialGroup(cwd: string): string;
+/** How long a just-created session may go without reporting a turn before the
+ *  group stops waiting for it. Covers spawn + `deliverPrompt`'s echo window; past
+ *  it, something went wrong and holding the rest of the queue forever is worse
+ *  than starting the next one. */
+export declare const SERIAL_STARTUP_MS = 60000;
+/** The session facts `busySerialGroups` reads. Primitives again — no SessionInfo
+ *  import, so this stays node-runnable and testable without a host. */
+export interface SerialSessionState extends LaneSessionState {
+    id: string;
+    cwd: string;
+    running?: boolean;
+    /** Epoch ms the session's current/most recent turn started. Absent ⇒ it has
+     *  never run one, i.e. it is still coming up. */
+    turnStartedAt?: number;
+    /** The CLI conversation this session is driving (`claudeSessionId`), so a
+     *  clock row aimed at a gone session id can find its conversation open
+     *  under another one (`liveConvSession`). Absent = not known. */
+    convId?: string;
+    /** What a person calls this session — the desktop's derived tab name, else
+     *  its title. Only the serial SENTENCE reads it (`serialWaitText`); absent
+     *  means the sentence says "another session" rather than inventing one. */
+    name?: string;
+    /** Opened by MACHINERY for queued work (a backlog item, a schedule, an
+     *  agent's posted prompt, a fan-out target, or the reopen of one of those
+     *  at a limit reset) — never a session a person opened by hand. Only the
+     *  INTENT ladder's serial rung reads it (`intentSerialHolders`): a hand
+     *  session never holds a serial backlog row. Absent = a person's. */
+    automatic?: boolean;
+    /** The turn ended on a question asked in PROSE (`SessionInfo.asking`). Not
+     *  a wall for a lane — the answer IS the next prompt — but an automatic
+     *  predecessor that asked one holds the serial row behind it. */
+    asking?: boolean;
+}
+/**
+ * One serialized send that has already gone out, and the session it produced.
+ *
+ * Needed for one narrow window: between `op.ack` naming the new session and
+ * that session reporting a turn, the repo looks IDLE — the CLI is starting, the
+ * prompt has not been typed yet, and nothing about the live session list says
+ * "wait". Releasing there would start the next open a second later and undo the
+ * whole point.
+ */
+export interface SerialWatch {
+    group: string;
+    sessionId: string;
+    /** Epoch ms the ack landed — the start of the startup grace. */
+    at: number;
+}
+/**
+ * Which serialization groups are still busy, and which watches are still worth
+ * keeping.
+ *
+ * Two sources, deliberately:
+ *   • any LIVE session in that directory that `laneBusy()` calls busy — mid-turn,
+ *     parked on a question, or blocked on a usage limit. That includes sessions
+ *     nobody queued (one opened by hand), which is the point: "don't edit this
+ *     repo from two agents at once" is not a statement about who started them.
+ *   • a watch inside its startup grace whose session has not reported a turn
+ *     yet — the gap described on `SerialWatch`.
+ *
+ * A watch is dropped once its session HAS run a turn (the first rule takes over
+ * from there) or once the grace has run out.
+ */
+export declare function busySerialGroups(sessions: readonly SerialSessionState[], watches: readonly SerialWatch[], now: number): {
+    busy: Set<string>;
+    watches: SerialWatch[];
+};
+/**
+ * May this entry go out right now, given the user's two "hold the queue"
+ * switches? Separate from `selectSendable` (which answers "would it corrupt the
+ * session?") because this one answers "did the user mean to send it?".
+ *
+ *   • attempts > 0 — already went out once; a retry is the SAME message, not a
+ *     new decision the switches get a say over.
+ *   • armed — released explicitly (tapped Send with the link up, "Send now",
+ *     "Send all"). Persisted with the entry, so intent survives a reload.
+ *   • otherwise only when auto-send is on and no reconnect confirmation is
+ *     pending.
+ */
+export declare function sendEligible(entry: {
+    attempts?: number;
+    armed?: boolean;
+}, opts: {
+    autoSend: boolean;
+    hold: boolean;
+}): boolean;
+/**
+ * One thing holding a serialization group, as a sentence needs it.
+ *
+ * `wall` is `sessionWall`'s answer for a live session — the SAME derivation
+ * `laneBusy` (and so `busySerialGroups`/`busyIntentGroups`) asks, never a
+ * second reading of the four fields — or `starting` for work the caller knows
+ * is starting or running there whose session is not (yet) behind a wall: the
+ * delivery window, or a session still coming up.
+ */
+export interface SerialHolder {
+    sessionId?: string;
+    name?: string;
+    wall: SessionWall | "starting";
+}
+/**
+ * Which sessions hold each busy group, keyed by `serialGroup(cwd)`.
+ *
+ * The keys are exactly the groups `busyIntentGroups` answers for the same two
+ * inputs (it is built from this), so the sentence can never name a holder for
+ * a group the ladder thinks is free, nor stay silent about one it holds.
+ * `occupied` is the caller's own "work is starting or running here" list; an
+ * entry whose session already holds the group as a live wall adds nothing.
+ *
+ * `automaticOnly` is the INTENT ladder's reading (`intentSerialHolders`): only
+ * a session opened for queued work (`automatic`) can hold the group as a
+ * wall, and such a session that ended its turn on a prose question
+ * (`asking`) holds it as `awaitingAnswer` too. A hand session never does —
+ * a person running five sessions in one repo all day would otherwise hold
+ * every serial row for as long as any one of them was mid-turn. Without it
+ * (the phone's send queue) every live session counts, exactly as before.
+ */
+export declare function serialHolders(sessions: readonly SerialSessionState[], occupied: Iterable<{
+    cwd: string;
+    sessionId?: string;
+    name?: string;
+}>, opts?: {
+    automaticOnly?: boolean;
+}): Map<string, SerialHolder[]>;
+/** The serial sentence when nobody said who holds the group. */
+export declare const SERIAL_WAIT_TEXT = "one at a time in this repo \u2014 waiting for the session before it";
+/**
+ * The holder a serial sentence NAMES, and the one a row offers to open — one
+ * ordering for both, so the words and the button point at the same session.
+ */
+export declare function serialLead(holders: readonly SerialHolder[] | undefined): SerialHolder | undefined;
+/**
+ * The serial sentence, NAMING what holds the repo:
+ * "one at a time in this repo — waiting for 'fix webkit sync' (working)", or
+ * "one at a time in this repo — waiting for your answer in 'fix webkit sync'"
+ * when the predecessor is parked on a question (a box, an unparsable dialog,
+ * or — for an automatic session — a turn that ended asking in prose).
+ *
+ * `serialLead` picks the one named; the rest are "+N more". A claim with
+ * no session and no name is "an automatic job is starting here". No holders
+ * ⇒ the generic sentence — absent facts never become an invented name.
+ */
+export declare function serialWaitText(holders: readonly SerialHolder[] | undefined): string;

package/node_modules/@waterplane/shared/dist/queue/queueserial.js

@@ -0,0 +1,169 @@
+// Cut from queue.ts (move only): serial groups
+// The one door stays `./queue.js`; this slice imports its siblings directly, never the barrel.
+import { laneBusy, sessionWall } from "./queuelane.js";
+/**
+ * The serialization group for a working directory.
+ *
+ * The REPO DIRECTORY, not the repo: a worktree is a separate checkout, and
+ * making one per task is exactly how this app already runs work in parallel
+ * safely (`parallel` backlog mode). Two sessions in two worktrees cannot write
+ * over each other, so they are not each other's business — the only thing they
+ * share is the usage limit, and that is a knob, not a rule.
+ */
+export function serialGroup(cwd) {
+    return `repo:${cwd}`;
+}
+/** How long a just-created session may go without reporting a turn before the
+ *  group stops waiting for it. Covers spawn + `deliverPrompt`'s echo window; past
+ *  it, something went wrong and holding the rest of the queue forever is worse
+ *  than starting the next one. */
+export const SERIAL_STARTUP_MS = 60_000;
+/**
+ * Which serialization groups are still busy, and which watches are still worth
+ * keeping.
+ *
+ * Two sources, deliberately:
+ *   • any LIVE session in that directory that `laneBusy()` calls busy — mid-turn,
+ *     parked on a question, or blocked on a usage limit. That includes sessions
+ *     nobody queued (one opened by hand), which is the point: "don't edit this
+ *     repo from two agents at once" is not a statement about who started them.
+ *   • a watch inside its startup grace whose session has not reported a turn
+ *     yet — the gap described on `SerialWatch`.
+ *
+ * A watch is dropped once its session HAS run a turn (the first rule takes over
+ * from there) or once the grace has run out.
+ */
+export function busySerialGroups(sessions, watches, now) {
+    const busy = new Set();
+    for (const s of sessions) {
+        if (s.running === false)
+            continue;
+        if (laneBusy(s))
+            busy.add(serialGroup(s.cwd));
+    }
+    const kept = [];
+    for (const w of watches) {
+        const s = sessions.find((x) => x.id === w.sessionId);
+        if (s && s.turnStartedAt)
+            continue; // it is live and has run — the rule above owns it now
+        if (now - w.at >= SERIAL_STARTUP_MS)
+            continue; // never came up; stop holding the queue for it
+        busy.add(w.group);
+        kept.push(w);
+    }
+    return { busy, watches: kept };
+}
+/**
+ * May this entry go out right now, given the user's two "hold the queue"
+ * switches? Separate from `selectSendable` (which answers "would it corrupt the
+ * session?") because this one answers "did the user mean to send it?".
+ *
+ *   • attempts > 0 — already went out once; a retry is the SAME message, not a
+ *     new decision the switches get a say over.
+ *   • armed — released explicitly (tapped Send with the link up, "Send now",
+ *     "Send all"). Persisted with the entry, so intent survives a reload.
+ *   • otherwise only when auto-send is on and no reconnect confirmation is
+ *     pending.
+ */
+export function sendEligible(entry, opts) {
+    if ((entry.attempts ?? 0) > 0)
+        return true;
+    if (entry.armed)
+        return true;
+    return opts.autoSend && !opts.hold;
+}
+/**
+ * Which sessions hold each busy group, keyed by `serialGroup(cwd)`.
+ *
+ * The keys are exactly the groups `busyIntentGroups` answers for the same two
+ * inputs (it is built from this), so the sentence can never name a holder for
+ * a group the ladder thinks is free, nor stay silent about one it holds.
+ * `occupied` is the caller's own "work is starting or running here" list; an
+ * entry whose session already holds the group as a live wall adds nothing.
+ *
+ * `automaticOnly` is the INTENT ladder's reading (`intentSerialHolders`): only
+ * a session opened for queued work (`automatic`) can hold the group as a
+ * wall, and such a session that ended its turn on a prose question
+ * (`asking`) holds it as `awaitingAnswer` too. A hand session never does —
+ * a person running five sessions in one repo all day would otherwise hold
+ * every serial row for as long as any one of them was mid-turn. Without it
+ * (the phone's send queue) every live session counts, exactly as before.
+ */
+export function serialHolders(sessions, occupied, opts = {}) {
+    const out = new Map();
+    const add = (g, h) => {
+        const list = out.get(g);
+        if (!list) {
+            out.set(g, [h]);
+            return;
+        }
+        if (h.sessionId && list.some((x) => x.sessionId === h.sessionId))
+            return;
+        list.push(h);
+    };
+    for (const s of sessions) {
+        if (s.running === false)
+            continue;
+        if (opts.automaticOnly && !s.automatic)
+            continue;
+        const wall = sessionWall(s) ?? (opts.automaticOnly && s.asking ? "awaitingAnswer" : null);
+        if (wall)
+            add(serialGroup(s.cwd), { sessionId: s.id, wall, ...(s.name ? { name: s.name } : {}) });
+    }
+    for (const o of occupied) {
+        const s = o.sessionId ? sessions.find((x) => x.id === o.sessionId) : undefined;
+        const name = s?.name || o.name;
+        add(serialGroup(o.cwd), { ...(o.sessionId ? { sessionId: o.sessionId } : {}), wall: "starting", ...(name ? { name } : {}) });
+    }
+    return out;
+}
+/** The serial sentence when nobody said who holds the group. */
+export const SERIAL_WAIT_TEXT = "one at a time in this repo — waiting for the session before it";
+const SERIAL_WALL_WORDS = {
+    sessionBusy: "working",
+    limit: "on a usage limit",
+    starting: "starting a queued job",
+};
+/** How long a quoted session name may run in the sentence. */
+const SERIAL_NAME_MAX = 48;
+/** Lead order: an open question first (it is the one a PERSON can clear, and
+ *  the reason the owner asked for this hold), then any other session wall,
+ *  then a `starting` claim. Stable within a rank. */
+const SERIAL_RANK = { awaitingAnswer: 0, limit: 1, sessionBusy: 1, starting: 2 };
+/**
+ * The holder a serial sentence NAMES, and the one a row offers to open — one
+ * ordering for both, so the words and the button point at the same session.
+ */
+export function serialLead(holders) {
+    if (!holders || !holders.length)
+        return undefined;
+    return [...holders].sort((a, b) => SERIAL_RANK[a.wall] - SERIAL_RANK[b.wall])[0];
+}
+/**
+ * The serial sentence, NAMING what holds the repo:
+ * "one at a time in this repo — waiting for 'fix webkit sync' (working)", or
+ * "one at a time in this repo — waiting for your answer in 'fix webkit sync'"
+ * when the predecessor is parked on a question (a box, an unparsable dialog,
+ * or — for an automatic session — a turn that ended asking in prose).
+ *
+ * `serialLead` picks the one named; the rest are "+N more". A claim with
+ * no session and no name is "an automatic job is starting here". No holders
+ * ⇒ the generic sentence — absent facts never become an invented name.
+ */
+export function serialWaitText(holders) {
+    const first = serialLead(holders);
+    if (!holders || !first)
+        return SERIAL_WAIT_TEXT;
+    const more = holders.length > 1 ? ` +${holders.length - 1} more` : "";
+    if (first.wall === "starting" && !first.name && !first.sessionId) {
+        return `one at a time in this repo — an automatic job is starting here${more}`;
+    }
+    const raw = (first.name ?? "").trim();
+    const name = raw.length > SERIAL_NAME_MAX ? `${raw.slice(0, SERIAL_NAME_MAX - 1)}…` : raw;
+    if (first.wall === "awaitingAnswer") {
+        return `one at a time in this repo — waiting for your answer in ${name ? `'${name}'` : "the session before it"}${more}`;
+    }
+    const who = name ? `'${name}'` : "another session";
+    return `one at a time in this repo — waiting for ${who} (${SERIAL_WALL_WORDS[first.wall]})${more}`;
+}
+//# sourceMappingURL=queueserial.js.map

package/node_modules/@waterplane/shared/dist/queue/queueserial.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"queueserial.js","sourceRoot":"","sources":["../../src/queue/queueserial.ts"],"names":[],"mappings":"AAAA,+CAA+C;AAC/C,+FAA+F;AAE/F,OAAO,EAAE,QAAQ,EAAE,WAAW,EAA2C,MAAM,gBAAgB,CAAC;AAEhG;;;;;;;;GAQG;AACH,MAAM,UAAU,WAAW,CAAC,GAAW;IACrC,OAAO,QAAQ,GAAG,EAAE,CAAC;AACvB,CAAC;AAED;;;kCAGkC;AAClC,MAAM,CAAC,MAAM,iBAAiB,GAAG,MAAM,CAAC;AA+CxC;;;;;;;;;;;;;;GAcG;AACH,MAAM,UAAU,gBAAgB,CAC9B,QAAuC,EACvC,OAA+B,EAC/B,GAAW;IAEX,MAAM,IAAI,GAAG,IAAI,GAAG,EAAU,CAAC;IAC/B,KAAK,MAAM,CAAC,IAAI,QAAQ,EAAE,CAAC;QACzB,IAAI,CAAC,CAAC,OAAO,KAAK,KAAK;YAAE,SAAS;QAClC,IAAI,QAAQ,CAAC,CAAC,CAAC;YAAE,IAAI,CAAC,GAAG,CAAC,WAAW,CAAC,CAAC,CAAC,GAAG,CAAC,CAAC,CAAC;IAChD,CAAC;IACD,MAAM,IAAI,GAAkB,EAAE,CAAC;IAC/B,KAAK,MAAM,CAAC,IAAI,OAAO,EAAE,CAAC;QACxB,MAAM,CAAC,GAAG,QAAQ,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,EAAE,KAAK,CAAC,CAAC,SAAS,CAAC,CAAC;QACrD,IAAI,CAAC,IAAI,CAAC,CAAC,aAAa;YAAE,SAAS,CAAa,sDAAsD;QACtG,IAAI,GAAG,GAAG,CAAC,CAAC,EAAE,IAAI,iBAAiB;YAAE,SAAS,CAAE,+CAA+C;QAC/F,IAAI,CAAC,GAAG,CAAC,CAAC,CAAC,KAAK,CAAC,CAAC;QAClB,IAAI,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;IACf,CAAC;IACD,OAAO,EAAE,IAAI,EAAE,OAAO,EAAE,IAAI,EAAE,CAAC;AACjC,CAAC;AAED;;;;;;;;;;;GAWG;AACH,MAAM,UAAU,YAAY,CAC1B,KAA6C,EAC7C,IAA0C;IAE1C,IAAI,CAAC,KAAK,CAAC,QAAQ,IAAI,CAAC,CAAC,GAAG,CAAC;QAAE,OAAO,IAAI,CAAC;IAC3C,IAAI,KAAK,CAAC,KAAK;QAAE,OAAO,IAAI,CAAC;IAC7B,OAAO,IAAI,CAAC,QAAQ,IAAI,CAAC,IAAI,CAAC,IAAI,CAAC;AACrC,CAAC;AAmBD;;;;;;;;;;;;;;;;GAgBG;AACH,MAAM,UAAU,aAAa,CAC3B,QAAuC,EACvC,QAAsE,EACtE,OAAoC,EAAE;IAEtC,MAAM,GAAG,GAAG,IAAI,GAAG,EAA0B,CAAC;IAC9C,MAAM,GAAG,GAAG,CAAC,CAAS,EAAE,CAAe,EAAE,EAAE;QACzC,MAAM,IAAI,GAAG,GAAG,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC;QACxB,IAAI,CAAC,IAAI,EAAE,CAAC;YAAC,GAAG,CAAC,GAAG,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC,CAAC,CAAC;YAAC,OAAO;QAAC,CAAC;QACvC,IAAI,CAAC,CAAC,SAAS,IAAI,IAAI,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,SAAS,KAAK,CAAC,CAAC,SAAS,CAAC;YAAE,OAAO;QACzE,IAAI,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;IACf,CAAC,CAAC;IACF,KAAK,MAAM,CAAC,IAAI,QAAQ,EAAE,CAAC;QACzB,IAAI,CAAC,CAAC,OAAO,KAAK,KAAK;YAAE,SAAS;QAClC,IAAI,IAAI,CAAC,aAAa,IAAI,CAAC,CAAC,CAAC,SAAS;YAAE,SAAS;QACjD,MAAM,IAAI,GAAG,WAAW,CAAC,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,aAAa,IAAI,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,gBAAgB,CAAC,CAAC,CAAC,IAAI,CAAC,CAAC;QAC1F,IAAI,IAAI;YAAE,GAAG,CAAC,WAAW,CAAC,CAAC,CAAC,GAAG,CAAC,EAAE,EAAE,SAAS,EAAE,CAAC,CAAC,EAAE,EAAE,IAAI,EAAE,GAAG,CAAC,CAAC,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,IAAI,EAAE,CAAC,CAAC,IAAI,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC,EAAE,CAAC,CAAC;IACpG,CAAC;IACD,KAAK,MAAM,CAAC,IAAI,QAAQ,EAAE,CAAC;QACzB,MAAM,CAAC,GAAG,CAAC,CAAC,SAAS,CAAC,CAAC,CAAC,QAAQ,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,EAAE,KAAK,CAAC,CAAC,SAAS,CAAC,CAAC,CAAC,CAAC,SAAS,CAAC;QAC/E,MAAM,IAAI,GAAG,CAAC,EAAE,IAAI,IAAI,CAAC,CAAC,IAAI,CAAC;QAC/B,GAAG,CAAC,WAAW,CAAC,CAAC,CAAC,GAAG,CAAC,EAAE,EAAE,GAAG,CAAC,CAAC,CAAC,SAAS,CAAC,CAAC,CAAC,EAAE,SAAS,EAAE,CAAC,CAAC,SAAS,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC,EAAE,IAAI,EAAE,UAAU,EAAE,GAAG,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,IAAI,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC,EAAE,CAAC,CAAC;IAC/H,CAAC;IACD,OAAO,GAAG,CAAC;AACb,CAAC;AAED,gEAAgE;AAChE,MAAM,CAAC,MAAM,gBAAgB,GAAG,gEAAgE,CAAC;AAEjG,MAAM,iBAAiB,GAAoE;IACzF,WAAW,EAAE,SAAS;IACtB,KAAK,EAAE,kBAAkB;IACzB,QAAQ,EAAE,uBAAuB;CAClC,CAAC;AAEF,8DAA8D;AAC9D,MAAM,eAAe,GAAG,EAAE,CAAC;AAE3B;;qDAEqD;AACrD,MAAM,WAAW,GAAyC,EAAE,cAAc,EAAE,CAAC,EAAE,KAAK,EAAE,CAAC,EAAE,WAAW,EAAE,CAAC,EAAE,QAAQ,EAAE,CAAC,EAAE,CAAC;AAEvH;;;GAGG;AACH,MAAM,UAAU,UAAU,CAAC,OAA4C;IACrE,IAAI,CAAC,OAAO,IAAI,CAAC,OAAO,CAAC,MAAM;QAAE,OAAO,SAAS,CAAC;IAClD,OAAO,CAAC,GAAG,OAAO,CAAC,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,CAAC,EAAE,EAAE,CAAC,WAAW,CAAC,CAAC,CAAC,IAAI,CAAC,GAAG,WAAW,CAAC,CAAC,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC;AACnF,CAAC;AAED;;;;;;;;;;GAUG;AACH,MAAM,UAAU,cAAc,CAAC,OAA4C;IACzE,MAAM,KAAK,GAAG,UAAU,CAAC,OAAO,CAAC,CAAC;IAClC,IAAI,CAAC,OAAO,IAAI,CAAC,KAAK;QAAE,OAAO,gBAAgB,CAAC;IAChD,MAAM,IAAI,GAAG,OAAO,CAAC,MAAM,GAAG,CAAC,CAAC,CAAC,CAAC,KAAK,OAAO,CAAC,MAAM,GAAG,CAAC,OAAO,CAAC,CAAC,CAAC,EAAE,CAAC;IACtE,IAAI,KAAK,CAAC,IAAI,KAAK,UAAU,IAAI,CAAC,KAAK,CAAC,IAAI,IAAI,CAAC,KAAK,CAAC,SAAS,EAAE,CAAC;QACjE,OAAO,iEAAiE,IAAI,EAAE,CAAC;IACjF,CAAC;IACD,MAAM,GAAG,GAAG,CAAC,KAAK,CAAC,IAAI,IAAI,EAAE,CAAC,CAAC,IAAI,EAAE,CAAC;IACtC,MAAM,IAAI,GAAG,GAAG,CAAC,MAAM,GAAG,eAAe,CAAC,CAAC,CAAC,GAAG,GAAG,CAAC,KAAK,CAAC,CAAC,EAAE,eAAe,GAAG,CAAC,CAAC,GAAG,CAAC,CAAC,CAAC,GAAG,CAAC;IAC1F,IAAI,KAAK,CAAC,IAAI,KAAK,gBAAgB,EAAE,CAAC;QACpC,OAAO,2DAA2D,IAAI,CAAC,CAAC,CAAC,IAAI,IAAI,GAAG,CAAC,CAAC,CAAC,uBAAuB,GAAG,IAAI,EAAE,CAAC;IAC1H,CAAC;IACD,MAAM,GAAG,GAAG,IAAI,CAAC,CAAC,CAAC,IAAI,IAAI,GAAG,CAAC,CAAC,CAAC,iBAAiB,CAAC;IACnD,OAAO,4CAA4C,GAAG,KAAK,iBAAiB,CAAC,KAAK,CAAC,IAAI,CAAC,IAAI,IAAI,EAAE,CAAC;AACrG,CAAC"}

package/node_modules/@waterplane/shared/dist/queue/queueuploads.d.ts

@@ -0,0 +1,65 @@
+import type { SendQueueEntry } from "./queueentry.js";
+/**
+ * Pull the uploads a message REFERENCES into that message's lane.
+ *
+ * An image is parked in the queue when it is attached, and the path it will
+ * land at goes into the compose box — but the message naming it is queued
+ * LATER, from wherever the user happens to send it, and nothing tied the two
+ * together except the hope that both were parked under the same lane key. They
+ * routinely were not: an attach made with no session open, an attach for the
+ * repo (backlog/gallery flows park under the repo dir), or simply switching
+ * sessions between attaching and sending, all left the picture in one lane and
+ * the prompt in another. Two lanes drain CONCURRENTLY, so the prompt won the
+ * race against its own image essentially every time — the agent was pointed at
+ * `.claude/inbox/<file>` a second before the bytes were written, and read a
+ * file that did not exist. With the link UP, which is what made it look
+ * unrelated to the offline queue it came from.
+ *
+ * So the reference is what decides the lane, not the tap that created the
+ * upload: any live upload whose predicted path appears in `text` is moved into
+ * `lane`, where the one-in-flight-per-lane rule makes the prompt wait for it.
+ * Array order is untouched — an upload parked earlier is already ahead of the
+ * message, which is exactly the order needed.
+ *
+ * ackIds are KEPT (unlike `retargetEntry`): an upload's ackId is the key its
+ * bytes are stored under, and the host de-dupes this path on the file itself
+ * (`x-dedupe`), not on the ledger — so there is nothing a fresh id would buy
+ * and a photo to lose.
+ *
+ * `failed` entries are deliberately not adopted: a dead upload is never going
+ * to arrive, and moving it would park the lane behind a corpse. The caller
+ * refuses the send instead (`danglingUploadRefs`).
+ */
+export declare function adoptReferencedUploads<T extends SendQueueEntry>(entries: readonly T[], text: string, lane: string): T[];
+/**
+ * The inbox paths this message names that are provably never going to exist:
+ * an upload sitting in the queue as `failed`.
+ *
+ * Sending such a message is worse than not sending it — the agent gets a path
+ * it cannot read and the phone reports success, so both ends disagree about
+ * what happened. The caller keeps the text and says which image has to be
+ * re-attached.
+ */
+export declare function danglingUploadRefs<T extends SendQueueEntry>(entries: readonly T[], text: string): string[];
+/**
+ * Where to insert a newly tapped ANSWER in the flat queue.
+ *
+ * Not the end of its lane, and not the front of it either.
+ *
+ * Not the end, because everything queued behind a blocked session is PROSE, and
+ * prose typed into a session parked on a dialog goes into the dialog: it
+ * neither runs nor answers the question. The answer is what unblocks the
+ * session the text is waiting for, so it goes first. That is also the order the
+ * user wrote them in — they answered the question they could see, then typed.
+ *
+ * Not the front, because a checkbox box is answered by several taps in sequence
+ * (toggle 1, toggle 2, Submit) which all carry the SAME question fingerprint.
+ * Jumping each one to the head would deliver them in reverse and submit the
+ * wrong set.
+ *
+ * So: ahead of the lane's first queued non-answer, behind any answer already
+ * waiting. `pending` entries are never overtaken — they may be on a live PTY
+ * already. Returns `entries.length` (i.e. append) when the lane holds no queued
+ * text, which is the ordinary case.
+ */
+export declare function answerInsertAt(entries: readonly SendQueueEntry[], lane: string): number;

package/node_modules/@waterplane/shared/dist/queue/queueuploads.js

@@ -0,0 +1,79 @@
+// Cut from queue.ts (move only): uploads an entry references, answer placement
+// The one door stays `./queue.js`; this slice imports its siblings directly, never the barrel.
+/**
+ * Pull the uploads a message REFERENCES into that message's lane.
+ *
+ * An image is parked in the queue when it is attached, and the path it will
+ * land at goes into the compose box — but the message naming it is queued
+ * LATER, from wherever the user happens to send it, and nothing tied the two
+ * together except the hope that both were parked under the same lane key. They
+ * routinely were not: an attach made with no session open, an attach for the
+ * repo (backlog/gallery flows park under the repo dir), or simply switching
+ * sessions between attaching and sending, all left the picture in one lane and
+ * the prompt in another. Two lanes drain CONCURRENTLY, so the prompt won the
+ * race against its own image essentially every time — the agent was pointed at
+ * `.claude/inbox/<file>` a second before the bytes were written, and read a
+ * file that did not exist. With the link UP, which is what made it look
+ * unrelated to the offline queue it came from.
+ *
+ * So the reference is what decides the lane, not the tap that created the
+ * upload: any live upload whose predicted path appears in `text` is moved into
+ * `lane`, where the one-in-flight-per-lane rule makes the prompt wait for it.
+ * Array order is untouched — an upload parked earlier is already ahead of the
+ * message, which is exactly the order needed.
+ *
+ * ackIds are KEPT (unlike `retargetEntry`): an upload's ackId is the key its
+ * bytes are stored under, and the host de-dupes this path on the file itself
+ * (`x-dedupe`), not on the ledger — so there is nothing a fresh id would buy
+ * and a photo to lose.
+ *
+ * `failed` entries are deliberately not adopted: a dead upload is never going
+ * to arrive, and moving it would park the lane behind a corpse. The caller
+ * refuses the send instead (`danglingUploadRefs`).
+ */
+export function adoptReferencedUploads(entries, text, lane) {
+    return entries.map((e) => e.mode === "upload" && e.status !== "failed" && e.sessionId !== lane &&
+        e.upload && text.includes(e.upload.relPath)
+        ? { ...e, sessionId: lane }
+        : e);
+}
+/**
+ * The inbox paths this message names that are provably never going to exist:
+ * an upload sitting in the queue as `failed`.
+ *
+ * Sending such a message is worse than not sending it — the agent gets a path
+ * it cannot read and the phone reports success, so both ends disagree about
+ * what happened. The caller keeps the text and says which image has to be
+ * re-attached.
+ */
+export function danglingUploadRefs(entries, text) {
+    return entries
+        .filter((e) => e.mode === "upload" && e.status === "failed" && e.upload && text.includes(e.upload.relPath))
+        .map((e) => e.upload.relPath);
+}
+/**
+ * Where to insert a newly tapped ANSWER in the flat queue.
+ *
+ * Not the end of its lane, and not the front of it either.
+ *
+ * Not the end, because everything queued behind a blocked session is PROSE, and
+ * prose typed into a session parked on a dialog goes into the dialog: it
+ * neither runs nor answers the question. The answer is what unblocks the
+ * session the text is waiting for, so it goes first. That is also the order the
+ * user wrote them in — they answered the question they could see, then typed.
+ *
+ * Not the front, because a checkbox box is answered by several taps in sequence
+ * (toggle 1, toggle 2, Submit) which all carry the SAME question fingerprint.
+ * Jumping each one to the head would deliver them in reverse and submit the
+ * wrong set.
+ *
+ * So: ahead of the lane's first queued non-answer, behind any answer already
+ * waiting. `pending` entries are never overtaken — they may be on a live PTY
+ * already. Returns `entries.length` (i.e. append) when the lane holds no queued
+ * text, which is the ordinary case.
+ */
+export function answerInsertAt(entries, lane) {
+    const at = entries.findIndex((e) => e.sessionId === lane && e.status === "queued" && !e.answer);
+    return at < 0 ? entries.length : at;
+}
+//# sourceMappingURL=queueuploads.js.map

package/node_modules/@waterplane/shared/dist/queue/queueuploads.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"queueuploads.js","sourceRoot":"","sources":["../../src/queue/queueuploads.ts"],"names":[],"mappings":"AAAA,+EAA+E;AAC/E,+FAA+F;AAI/F;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA8BG;AACH,MAAM,UAAU,sBAAsB,CACpC,OAAqB,EACrB,IAAY,EACZ,IAAY;IAEZ,OAAO,OAAO,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CACvB,CAAC,CAAC,IAAI,KAAK,QAAQ,IAAI,CAAC,CAAC,MAAM,KAAK,QAAQ,IAAI,CAAC,CAAC,SAAS,KAAK,IAAI;QACpE,CAAC,CAAC,MAAM,IAAI,IAAI,CAAC,QAAQ,CAAC,CAAC,CAAC,MAAM,CAAC,OAAO,CAAC;QACzC,CAAC,CAAC,EAAE,GAAG,CAAC,EAAE,SAAS,EAAE,IAAI,EAAE;QAC3B,CAAC,CAAC,CAAC,CAAC,CAAC;AACX,CAAC;AAED;;;;;;;;GAQG;AACH,MAAM,UAAU,kBAAkB,CAChC,OAAqB,EACrB,IAAY;IAEZ,OAAO,OAAO;SACX,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,KAAK,QAAQ,IAAI,CAAC,CAAC,MAAM,KAAK,QAAQ,IAAI,CAAC,CAAC,MAAM,IAAI,IAAI,CAAC,QAAQ,CAAC,CAAC,CAAC,MAAM,CAAC,OAAO,CAAC,CAAC;SAC1G,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,MAAO,CAAC,OAAO,CAAC,CAAC;AACnC,CAAC;AAED;;;;;;;;;;;;;;;;;;;;GAoBG;AACH,MAAM,UAAU,cAAc,CAAC,OAAkC,EAAE,IAAY;IAC7E,MAAM,EAAE,GAAG,OAAO,CAAC,SAAS,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,SAAS,KAAK,IAAI,IAAI,CAAC,CAAC,MAAM,KAAK,QAAQ,IAAI,CAAC,CAAC,CAAC,MAAM,CAAC,CAAC;IAChG,OAAO,EAAE,GAAG,CAAC,CAAC,CAAC,CAAC,OAAO,CAAC,MAAM,CAAC,CAAC,CAAC,EAAE,CAAC;AACtC,CAAC"}

package/node_modules/@waterplane/shared/dist/queue/queuewords.d.ts

@@ -0,0 +1,22 @@
+import type { SendBlockReason, BlockedEntry } from "./queueplan.js";
+/** The sentence for one block reason. Wording lives here so every surface that
+ *  explains a stuck queue says the same thing. */
+export declare function blockedReasonText(r: SendBlockReason): string;
+/**
+ * Why did nothing go out? — in one sentence, for a flush that sent zero.
+ *
+ * The bug this replaces: every caller of `flushOutbox()` treated a zero return
+ * as proof the link was down, and said "still offline — staying queued" over a
+ * header chip reading `open · 100.64.0.5`. The link was one of at least seven
+ * possible answers and usually not the right one.
+ *
+ * Precedence is by what the user can DO about it, not by queue order: the gate
+ * is a switch one tap away, a backoff clears itself, and the rest are facts
+ * about a session. `null` = nothing is stuck (nothing queued, or something did
+ * go out), so the caller stays silent rather than inventing reassurance.
+ */
+export declare function queueIdleReason(blocked: readonly BlockedEntry[], opts: {
+    online: boolean;
+    queued: number;
+    serialText?: string;
+}): string | null;