waterplane 0.0.1 → 0.1.6

package/node_modules/@waterplane/shared/dist/promptid.d.ts

@@ -0,0 +1,48 @@
+/** The parts of a `DetectedPrompt` the fingerprint is built from. Structural
+ *  rather than importing the type, so this file stays free of wire-DTO churn. */
+export interface FingerprintablePrompt {
+    kind: string;
+    question: string;
+    options: readonly {
+        index: number;
+        label: string;
+    }[];
+    multi?: boolean;
+    nav?: boolean;
+    freeText?: boolean;
+}
+/**
+ * A short, stable id for a question box.
+ *
+ * Every field that changes what an answer MEANS is in it: the kind (a "2" at a
+ * trust dialog and a "2" at a tool-approval box are different acts), the
+ * question, every option index paired with its label, `multi` (a digit TOGGLES
+ * a row in a checkbox box instead of answering it, so the same keystroke has a
+ * different effect) and `nav` (an unnumbered box is answered by WALKING the
+ * selection onto the option, so "2" is not a keystroke there at all). Option
+ * ORDER is part of it by construction — the indices are what get typed, or
+ * counted.
+ *
+ * FNV-1a, because this is a change-detector and not a security boundary: the
+ * host is already the machine running `claude` (SECURITY.md), and there is no
+ * adversary here to forge a collision — only a screen that moved on.
+ */
+export declare function promptFingerprint(p: FingerprintablePrompt): string;
+/**
+ * Does an answer minted against `expected` still apply to what is on screen?
+ *
+ * `null` current = no question is up at all, which is a mismatch: the box was
+ * answered by someone else, or the agent moved on. Both mean the keystroke must
+ * not be written.
+ */
+/** The longest typed answer a phone may send to a question (`session.input` `promptText`) —
+ *  the same bound the host puts on words a source asks it to type (`SOURCE_TYPED_MAX`). */
+export declare const ANSWER_TEXT_MAX = 1000;
+/**
+ * Why `text` is not a typed answer to a question box, or null when it is. Both ends ask
+ * this one function: the phone before it queues the answer, the host before it hands the
+ * words to the CLI. One line of words — no control character at all (a Return, an Escape,
+ * a newline would be a KEYSTROKE riding inside an answer), at most `ANSWER_TEXT_MAX`.
+ */
+export declare function answerTextProblem(text: unknown): string | null;
+export declare function promptStillCurrent(current: FingerprintablePrompt | null | undefined, expected: string): boolean;

package/node_modules/@waterplane/shared/dist/promptid.js

@@ -0,0 +1,116 @@
+// Identity of a detected CLI question — the safety interlock for answering one
+// OFFLINE.
+//
+// The phone can now hold a question it saw during a brief connectivity window,
+// let you answer it with no link at all, and deliver the answer when the tunnel
+// comes back (see web/outbox.ts `answer` entries). That delay is the whole
+// point, and it is also the whole danger: an answer is not text, it is a
+// KEYSTROKE aimed at whatever box happens to be on screen when it lands. "2"
+// typed at the question you read means "use the existing branch"; the same "2"
+// arriving four minutes later, after that box is gone and another one is up,
+// answers a different question entirely — or drops a stray digit into the
+// composer that the next Return submits as a prompt. Text sent late is stale;
+// a choice sent late is WRONG, and nothing downstream can tell the difference.
+//
+// So an answer names the question it is answering. The client records this
+// fingerprint of the prompt it rendered, the host compares it against the
+// prompt it currently has live, and a mismatch refuses the write rather than
+// guessing (`input.ack` state "stale"). Both sides derive it from the SAME
+// published `DetectedPrompt`, so exact equality is the right comparison — this
+// is not a fuzzy match against re-scraped screen text.
+//
+// It lives in `shared` for the usual reason: `shared/dist` is node-runnable, so
+// `e2e-answer.mjs` can pin the rules instead of trusting that two copies of the
+// hashing agreed.
+/**
+ * Collapse the runs of whitespace a TUI repaint inserts, and trim.
+ *
+ * Not a normalization for MATCHING two different scrapes — the two sides
+ * fingerprint the same object — but a repaint can legitimately re-publish a
+ * prompt whose label gained a trailing space, and re-deriving a different id
+ * for a box that never changed would refuse an answer that is perfectly valid.
+ */
+const norm = (s) => s.replace(/\s+/g, " ").trim();
+/**
+ * A short, stable id for a question box.
+ *
+ * Every field that changes what an answer MEANS is in it: the kind (a "2" at a
+ * trust dialog and a "2" at a tool-approval box are different acts), the
+ * question, every option index paired with its label, `multi` (a digit TOGGLES
+ * a row in a checkbox box instead of answering it, so the same keystroke has a
+ * different effect) and `nav` (an unnumbered box is answered by WALKING the
+ * selection onto the option, so "2" is not a keystroke there at all). Option
+ * ORDER is part of it by construction — the indices are what get typed, or
+ * counted.
+ *
+ * FNV-1a, because this is a change-detector and not a security boundary: the
+ * host is already the machine running `claude` (SECURITY.md), and there is no
+ * adversary here to forge a collision — only a screen that moved on.
+ */
+export function promptFingerprint(p) {
+    const parts = [
+        p.kind,
+        p.multi ? "multi" : "single",
+        norm(p.question),
+        ...p.options.map((o) => `${o.index}\u0000${norm(o.label)}`),
+        /**
+         * Appended only when SET, where `multi` contributes either way.
+         *
+         * Not an inconsistency — `multi` was here from the start, and `nav` is a
+         * field added to a wire an APK may have pinned an old bundle of. Both ends
+         * derive this from the same published prompt, so a formula that contributed
+         * a term for every ordinary box would re-derive a different id on the new
+         * host than on the old client, and every queued answer in the world would
+         * come back `stale`. A term that can only appear on a box an old client
+         * could never be shown (a `nav` box exists only on a backend whose options
+         * carry no digits) leaves every existing id byte-identical.
+         */
+        ...(p.nav ? ["nav"] : []),
+        // Same rule, same reason: only a `question` box posed on a backend's own channel carries it.
+        ...(p.freeText ? ["text"] : []),
+    ];
+    return fnv1a(parts.join("\u0001"));
+}
+/** 32-bit FNV-1a, hex. Deliberately tiny: it rides on every queued answer and
+ *  is compared for equality, never inverted. */
+function fnv1a(s) {
+    let h = 0x811c9dc5;
+    for (let i = 0; i < s.length; i++) {
+        h ^= s.charCodeAt(i);
+        // The mul-by-prime, kept in 32-bit range without BigInt.
+        h = (h + ((h << 1) + (h << 4) + (h << 7) + (h << 8) + (h << 24))) >>> 0;
+    }
+    return h.toString(16).padStart(8, "0");
+}
+/**
+ * Does an answer minted against `expected` still apply to what is on screen?
+ *
+ * `null` current = no question is up at all, which is a mismatch: the box was
+ * answered by someone else, or the agent moved on. Both mean the keystroke must
+ * not be written.
+ */
+/** The longest typed answer a phone may send to a question (`session.input` `promptText`) —
+ *  the same bound the host puts on words a source asks it to type (`SOURCE_TYPED_MAX`). */
+export const ANSWER_TEXT_MAX = 1000;
+/**
+ * Why `text` is not a typed answer to a question box, or null when it is. Both ends ask
+ * this one function: the phone before it queues the answer, the host before it hands the
+ * words to the CLI. One line of words — no control character at all (a Return, an Escape,
+ * a newline would be a KEYSTROKE riding inside an answer), at most `ANSWER_TEXT_MAX`.
+ */
+export function answerTextProblem(text) {
+    if (typeof text !== "string" || !text.trim())
+        return "the answer has no words in it";
+    if (text.length > ANSWER_TEXT_MAX)
+        return `the answer is ${text.length} characters, and a typed answer is at most ${ANSWER_TEXT_MAX}`;
+    for (let i = 0; i < text.length; i++) {
+        const c = text.charCodeAt(i);
+        if (c < 0x20 || (c >= 0x7f && c < 0xa0))
+            return `the answer holds a control character (0x${c.toString(16).padStart(2, "0")}) — a typed answer is one line of words`;
+    }
+    return null;
+}
+export function promptStillCurrent(current, expected) {
+    return !!current && promptFingerprint(current) === expected;
+}
+//# sourceMappingURL=promptid.js.map

package/node_modules/@waterplane/shared/dist/promptid.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"promptid.js","sourceRoot":"","sources":["../src/promptid.ts"],"names":[],"mappings":"AAAA,+EAA+E;AAC/E,WAAW;AACX,EAAE;AACF,+EAA+E;AAC/E,gFAAgF;AAChF,2EAA2E;AAC3E,yEAAyE;AACzE,6EAA6E;AAC7E,+EAA+E;AAC/E,6EAA6E;AAC7E,0EAA0E;AAC1E,8EAA8E;AAC9E,+EAA+E;AAC/E,EAAE;AACF,2EAA2E;AAC3E,0EAA0E;AAC1E,6EAA6E;AAC7E,2EAA2E;AAC3E,+EAA+E;AAC/E,uDAAuD;AACvD,EAAE;AACF,gFAAgF;AAChF,gFAAgF;AAChF,kBAAkB;AAalB;;;;;;;GAOG;AACH,MAAM,IAAI,GAAG,CAAC,CAAS,EAAE,EAAE,CAAC,CAAC,CAAC,OAAO,CAAC,MAAM,EAAE,GAAG,CAAC,CAAC,IAAI,EAAE,CAAC;AAE1D;;;;;;;;;;;;;;;GAeG;AACH,MAAM,UAAU,iBAAiB,CAAC,CAAwB;IACxD,MAAM,KAAK,GAAG;QACZ,CAAC,CAAC,IAAI;QACN,CAAC,CAAC,KAAK,CAAC,CAAC,CAAC,OAAO,CAAC,CAAC,CAAC,QAAQ;QAC5B,IAAI,CAAC,CAAC,CAAC,QAAQ,CAAC;QAChB,GAAG,CAAC,CAAC,OAAO,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,GAAG,CAAC,CAAC,KAAK,SAAS,IAAI,CAAC,CAAC,CAAC,KAAK,CAAC,EAAE,CAAC;QAC3D;;;;;;;;;;;WAWG;QACH,GAAG,CAAC,CAAC,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,EAAE,CAAC;QACzB,6FAA6F;QAC7F,GAAG,CAAC,CAAC,CAAC,QAAQ,CAAC,CAAC,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,EAAE,CAAC;KAChC,CAAC;IACF,OAAO,KAAK,CAAC,KAAK,CAAC,IAAI,CAAC,QAAQ,CAAC,CAAC,CAAC;AACrC,CAAC;AAED;gDACgD;AAChD,SAAS,KAAK,CAAC,CAAS;IACtB,IAAI,CAAC,GAAG,UAAU,CAAC;IACnB,KAAK,IAAI,CAAC,GAAG,CAAC,EAAE,CAAC,GAAG,CAAC,CAAC,MAAM,EAAE,CAAC,EAAE,EAAE,CAAC;QAClC,CAAC,IAAI,CAAC,CAAC,UAAU,CAAC,CAAC,CAAC,CAAC;QACrB,yDAAyD;QACzD,CAAC,GAAG,CAAC,CAAC,GAAG,CAAC,CAAC,CAAC,IAAI,CAAC,CAAC,GAAG,CAAC,CAAC,IAAI,CAAC,CAAC,GAAG,CAAC,CAAC,IAAI,CAAC,CAAC,GAAG,CAAC,CAAC,IAAI,CAAC,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,CAAC,CAAC,CAAC,KAAK,CAAC,CAAC;IAC1E,CAAC;IACD,OAAO,CAAC,CAAC,QAAQ,CAAC,EAAE,CAAC,CAAC,QAAQ,CAAC,CAAC,EAAE,GAAG,CAAC,CAAC;AACzC,CAAC;AAED;;;;;;GAMG;AACH;2FAC2F;AAC3F,MAAM,CAAC,MAAM,eAAe,GAAG,IAAI,CAAC;AAEpC;;;;;GAKG;AACH,MAAM,UAAU,iBAAiB,CAAC,IAAa;IAC7C,IAAI,OAAO,IAAI,KAAK,QAAQ,IAAI,CAAC,IAAI,CAAC,IAAI,EAAE;QAAE,OAAO,+BAA+B,CAAC;IACrF,IAAI,IAAI,CAAC,MAAM,GAAG,eAAe;QAAE,OAAO,iBAAiB,IAAI,CAAC,MAAM,8CAA8C,eAAe,EAAE,CAAC;IACtI,KAAK,IAAI,CAAC,GAAG,CAAC,EAAE,CAAC,GAAG,IAAI,CAAC,MAAM,EAAE,CAAC,EAAE,EAAE,CAAC;QACrC,MAAM,CAAC,GAAG,IAAI,CAAC,UAAU,CAAC,CAAC,CAAC,CAAC;QAC7B,IAAI,CAAC,GAAG,IAAI,IAAI,CAAC,CAAC,IAAI,IAAI,IAAI,CAAC,GAAG,IAAI,CAAC;YAAE,OAAO,2CAA2C,CAAC,CAAC,QAAQ,CAAC,EAAE,CAAC,CAAC,QAAQ,CAAC,CAAC,EAAE,GAAG,CAAC,yCAAyC,CAAC;IACtK,CAAC;IACD,OAAO,IAAI,CAAC;AACd,CAAC;AAED,MAAM,UAAU,kBAAkB,CAAC,OAAiD,EAAE,QAAgB;IACpG,OAAO,CAAC,CAAC,OAAO,IAAI,iBAAiB,CAAC,OAAO,CAAC,KAAK,QAAQ,CAAC;AAC9D,CAAC"}

package/node_modules/@waterplane/shared/dist/ptysize.d.ts

@@ -0,0 +1,74 @@
+/**
+ * The geometry a PTY may be given — and the floor under it.
+ *
+ * A client reports the size of the grid it is showing, and the host passes it
+ * to the PTY as a SIGWINCH. Both ends used to accept anything above two rows,
+ * which is how a session ended up three rows tall for forty minutes: the
+ * phone's terminal container was laid out with (almost) no height — a sheet
+ * open over it, a reader view, a WebView mid-layout — so `FitAddon` measured a
+ * full-width, no-height box and reported `54x3`. Nothing about that report is
+ * wrong as arithmetic; it is simply not a viewport.
+ *
+ * The consequence is not cosmetic. The claude TUI cannot draw its composer box
+ * in three rows, so text typed into that session appears NOWHERE on the
+ * rendered screen — and the rendered screen is the only thing `deliver.ts` has
+ * to confirm a delivery with. Every send became `unconfirmed`, every `absent`
+ * verdict authorised a re-send that also could not be read back, and the
+ * composer quietly stacked five copies of the same prompt. Twenty-eight
+ * consecutive echo misses, all of them a layout bug wearing a delivery bug's
+ * clothes.
+ *
+ * So: a geometry that cannot hold the CLI's composer is not accepted as one.
+ * The host clamps (a PTY bigger than the viewport is a scrolled view, which is
+ * survivable; one too small to read back is not), and the client does not
+ * report a fit it took off a collapsed container at all — it waits for the
+ * layout it is actually showing. One number, stated once, so the two ends
+ * cannot disagree about what "too small to drive" means.
+ */
+/** Narrowest grid the CLI's box drawing survives at all. */
+export declare const MIN_PTY_COLS = 20;
+/**
+ * Fewest rows the claude TUI can draw a composer in and still be readable
+ * back: the box's two borders, a row of text inside it, the status line and
+ * the mode line, plus enough above it that the echo probe has something to
+ * match against. Well under any real phone in portrait (≈24-40 rows), so this
+ * floor only ever catches a measurement nobody was looking at.
+ */
+export declare const MIN_PTY_ROWS = 12;
+/**
+ * Widest grid a PTY is given — the floor's twin. A desktop window's main pane
+ * fits 230+ columns, and the CLI wraps its prose to the width it is told, so a
+ * sign-in URL or a paragraph became one unreadable line across the screen.
+ * Every screen heuristic here (`prompt.ts`, the echo probe in `deliver.ts`) was
+ * measured at ≤120 columns, and the screen log's VT replay and the scrollback
+ * archive both scale with the width. The client draws the capped grid
+ * left-aligned and leaves the rest of the pane as margin; the host clamps to
+ * the same number (symmetry, never a refusal). A constant by the owner's
+ * decision (docs/analysis/desktop-workspace-plan.md, O2).
+ */
+export declare const MAX_PTY_COLS = 160;
+/** A terminal size, as the PTY will be told it. */
+export type PtySize = {
+    cols: number;
+    rows: number;
+};
+/**
+ * Is this a grid a person is actually looking at?
+ *
+ * The question the CLIENT asks before reporting a fit. A collapsed container
+ * answers no, and a report withheld costs nothing — the next layout change
+ * fires another one, and `session.attach` re-states the geometry on reconnect.
+ */
+export declare const drawableViewport: (cols: number, rows: number) => boolean;
+/** The columns a client draws for a fit of `cols`: the fit, never wider than
+ *  `MAX_PTY_COLS`. Rows are untouched — height is not the readability problem. */
+export declare const cappedCols: (cols: number) => number;
+/**
+ * The size to actually give a PTY, whatever was asked for.
+ *
+ * The question the HOST asks, and it clamps rather than refuses: a client that
+ * reports a too-small grid is still a client with a session open, and leaving
+ * the PTY at whatever it was is what the floor is for. Non-numbers fall back to
+ * the floor too — an absent geometry is not a small one.
+ */
+export declare function ptySize(cols: unknown, rows: unknown): PtySize;

package/node_modules/@waterplane/shared/dist/ptysize.js

@@ -0,0 +1,77 @@
+/**
+ * The geometry a PTY may be given — and the floor under it.
+ *
+ * A client reports the size of the grid it is showing, and the host passes it
+ * to the PTY as a SIGWINCH. Both ends used to accept anything above two rows,
+ * which is how a session ended up three rows tall for forty minutes: the
+ * phone's terminal container was laid out with (almost) no height — a sheet
+ * open over it, a reader view, a WebView mid-layout — so `FitAddon` measured a
+ * full-width, no-height box and reported `54x3`. Nothing about that report is
+ * wrong as arithmetic; it is simply not a viewport.
+ *
+ * The consequence is not cosmetic. The claude TUI cannot draw its composer box
+ * in three rows, so text typed into that session appears NOWHERE on the
+ * rendered screen — and the rendered screen is the only thing `deliver.ts` has
+ * to confirm a delivery with. Every send became `unconfirmed`, every `absent`
+ * verdict authorised a re-send that also could not be read back, and the
+ * composer quietly stacked five copies of the same prompt. Twenty-eight
+ * consecutive echo misses, all of them a layout bug wearing a delivery bug's
+ * clothes.
+ *
+ * So: a geometry that cannot hold the CLI's composer is not accepted as one.
+ * The host clamps (a PTY bigger than the viewport is a scrolled view, which is
+ * survivable; one too small to read back is not), and the client does not
+ * report a fit it took off a collapsed container at all — it waits for the
+ * layout it is actually showing. One number, stated once, so the two ends
+ * cannot disagree about what "too small to drive" means.
+ */
+/** Narrowest grid the CLI's box drawing survives at all. */
+export const MIN_PTY_COLS = 20;
+/**
+ * Fewest rows the claude TUI can draw a composer in and still be readable
+ * back: the box's two borders, a row of text inside it, the status line and
+ * the mode line, plus enough above it that the echo probe has something to
+ * match against. Well under any real phone in portrait (≈24-40 rows), so this
+ * floor only ever catches a measurement nobody was looking at.
+ */
+export const MIN_PTY_ROWS = 12;
+/**
+ * Widest grid a PTY is given — the floor's twin. A desktop window's main pane
+ * fits 230+ columns, and the CLI wraps its prose to the width it is told, so a
+ * sign-in URL or a paragraph became one unreadable line across the screen.
+ * Every screen heuristic here (`prompt.ts`, the echo probe in `deliver.ts`) was
+ * measured at ≤120 columns, and the screen log's VT replay and the scrollback
+ * archive both scale with the width. The client draws the capped grid
+ * left-aligned and leaves the rest of the pane as margin; the host clamps to
+ * the same number (symmetry, never a refusal). A constant by the owner's
+ * decision (docs/analysis/desktop-workspace-plan.md, O2).
+ */
+export const MAX_PTY_COLS = 160;
+/**
+ * Is this a grid a person is actually looking at?
+ *
+ * The question the CLIENT asks before reporting a fit. A collapsed container
+ * answers no, and a report withheld costs nothing — the next layout change
+ * fires another one, and `session.attach` re-states the geometry on reconnect.
+ */
+export const drawableViewport = (cols, rows) => Number.isFinite(cols) && Number.isFinite(rows) &&
+    Math.floor(cols) >= MIN_PTY_COLS && Math.floor(rows) >= MIN_PTY_ROWS;
+/** The columns a client draws for a fit of `cols`: the fit, never wider than
+ *  `MAX_PTY_COLS`. Rows are untouched — height is not the readability problem. */
+export const cappedCols = (cols) => Math.min(cols, MAX_PTY_COLS);
+/**
+ * The size to actually give a PTY, whatever was asked for.
+ *
+ * The question the HOST asks, and it clamps rather than refuses: a client that
+ * reports a too-small grid is still a client with a session open, and leaving
+ * the PTY at whatever it was is what the floor is for. Non-numbers fall back to
+ * the floor too — an absent geometry is not a small one.
+ */
+export function ptySize(cols, rows) {
+    const n = (v, min, max = Infinity) => {
+        const x = typeof v === "number" && Number.isFinite(v) ? Math.floor(v) : 0;
+        return Math.min(max, Math.max(min, x));
+    };
+    return { cols: n(cols, MIN_PTY_COLS, MAX_PTY_COLS), rows: n(rows, MIN_PTY_ROWS) };
+}
+//# sourceMappingURL=ptysize.js.map

package/node_modules/@waterplane/shared/dist/ptysize.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"ptysize.js","sourceRoot":"","sources":["../src/ptysize.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;GA0BG;AAEH,4DAA4D;AAC5D,MAAM,CAAC,MAAM,YAAY,GAAG,EAAE,CAAC;AAE/B;;;;;;GAMG;AACH,MAAM,CAAC,MAAM,YAAY,GAAG,EAAE,CAAC;AAE/B;;;;;;;;;;GAUG;AACH,MAAM,CAAC,MAAM,YAAY,GAAG,GAAG,CAAC;AAKhC;;;;;;GAMG;AACH,MAAM,CAAC,MAAM,gBAAgB,GAAG,CAAC,IAAY,EAAE,IAAY,EAAW,EAAE,CACtE,MAAM,CAAC,QAAQ,CAAC,IAAI,CAAC,IAAI,MAAM,CAAC,QAAQ,CAAC,IAAI,CAAC;IAC9C,IAAI,CAAC,KAAK,CAAC,IAAI,CAAC,IAAI,YAAY,IAAI,IAAI,CAAC,KAAK,CAAC,IAAI,CAAC,IAAI,YAAY,CAAC;AAEvE;kFACkF;AAClF,MAAM,CAAC,MAAM,UAAU,GAAG,CAAC,IAAY,EAAU,EAAE,CAAC,IAAI,CAAC,GAAG,CAAC,IAAI,EAAE,YAAY,CAAC,CAAC;AAEjF;;;;;;;GAOG;AACH,MAAM,UAAU,OAAO,CAAC,IAAa,EAAE,IAAa;IAClD,MAAM,CAAC,GAAG,CAAC,CAAU,EAAE,GAAW,EAAE,GAAG,GAAG,QAAQ,EAAU,EAAE;QAC5D,MAAM,CAAC,GAAG,OAAO,CAAC,KAAK,QAAQ,IAAI,MAAM,CAAC,QAAQ,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC;QAC1E,OAAO,IAAI,CAAC,GAAG,CAAC,GAAG,EAAE,IAAI,CAAC,GAAG,CAAC,GAAG,EAAE,CAAC,CAAC,CAAC,CAAC;IACzC,CAAC,CAAC;IACF,OAAO,EAAE,IAAI,EAAE,CAAC,CAAC,IAAI,EAAE,YAAY,EAAE,YAAY,CAAC,EAAE,IAAI,EAAE,CAAC,CAAC,IAAI,EAAE,YAAY,CAAC,EAAE,CAAC;AACpF,CAAC"}

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

@@ -0,0 +1,40 @@
+import type { SendQueueEntry } from "./queueentry.js";
+/**
+ * Bind the prompts queued behind a `session.create` to the session it produced.
+ *
+ * Called when `op.ack` names the new session id: every `pendingCreate` entry in
+ * that lane swaps its placeholder lane key (`create:<cwd>`) for the real
+ * session id and drops the flag. `ts` is restamped so the queue sheet sorts and
+ * ages the row from the moment it became a real send.
+ *
+ * The ackIds are KEPT. These entries are provably un-sent (the lane rule holds
+ * everything behind the create, and a `pendingCreate` entry is never picked at
+ * all), so no host ledger can hold a verdict for them — unlike `retargetEntry`,
+ * which must mint fresh ids precisely because its entries may have been out
+ * once already.
+ *
+ * Array order is untouched, so the prompts stay in the order they were written.
+ */
+export declare function bindPendingSession<T extends SendQueueEntry>(entries: readonly T[], lane: string, sessionId: string, now: number, createAck?: string): T[];
+/**
+ * The parked prompts one create owns — what App fails alongside a create that
+ * could not be delivered.
+ *
+ * Same ownership rule as `bindPendingSession`, in one place: "which of this
+ * repo's queued prompts hang off this create" is a question three call sites
+ * ask, and answering it differently in any of them is how a second create's
+ * chain gets failed by the first one's bad news.
+ */
+export declare function ownedPendingCreates<T extends SendQueueEntry>(entries: readonly T[], lane: string, createAck?: string): T[];
+/**
+ * Drop the park flag on the entries `selectSendable` just released: the turn
+ * they were waiting for has ended, so they are ordinary queued messages now.
+ *
+ * Clearing the flag is the whole job. It used to also restamp `ts`, because
+ * that clock decided when the entry was shredded as "queued too long" and an
+ * entry parked against a 35-minute turn was already past it the moment it
+ * became sendable. There is no such clock any more, so there is nothing to
+ * reset — what remains is stopping the next pass from reporting the same
+ * release for ever.
+ */
+export declare function applyRelease<T extends SendQueueEntry>(entries: readonly T[], released: readonly T[]): T[];

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

@@ -0,0 +1,70 @@
+// Cut from queue.ts (move only): pending-session binding and release
+// The one door stays `./queue.js`; this slice imports its siblings directly, never the barrel.
+/**
+ * Bind the prompts queued behind a `session.create` to the session it produced.
+ *
+ * Called when `op.ack` names the new session id: every `pendingCreate` entry in
+ * that lane swaps its placeholder lane key (`create:<cwd>`) for the real
+ * session id and drops the flag. `ts` is restamped so the queue sheet sorts and
+ * ages the row from the moment it became a real send.
+ *
+ * The ackIds are KEPT. These entries are provably un-sent (the lane rule holds
+ * everything behind the create, and a `pendingCreate` entry is never picked at
+ * all), so no host ledger can hold a verdict for them — unlike `retargetEntry`,
+ * which must mint fresh ids precisely because its entries may have been out
+ * once already.
+ *
+ * Array order is untouched, so the prompts stay in the order they were written.
+ */
+export function bindPendingSession(entries, lane, sessionId, now, createAck) {
+    return entries.map((e) => e.pendingCreate && e.sessionId === lane && ownedByCreate(e, createAck)
+        ? { ...e, sessionId, pendingCreate: undefined, createAck: undefined, ts: now }
+        : e);
+}
+/**
+ * Does this parked prompt belong to THIS create?
+ *
+ * The lane is `create:<cwd>`, i.e. per REPO — so two "open a session and run
+ * these" written for the same repo (the thing the Start sheet is built to let
+ * you do offline, one after another) share it. Matching on the lane alone bound
+ * the second one's chain to the FIRST session, ran it there, and left the
+ * second session with only the prompt that rode inside its own op.
+ *
+ * `createAck` is the create op's ackId, stamped on every prompt queued behind
+ * it. An entry that predates this field (persisted by an older build) carries
+ * none and still binds on the lane — there is exactly one create in flight per
+ * lane, so the old behaviour is the right fallback for it.
+ */
+function ownedByCreate(e, createAck) {
+    return !createAck || !e.createAck || e.createAck === createAck;
+}
+/**
+ * The parked prompts one create owns — what App fails alongside a create that
+ * could not be delivered.
+ *
+ * Same ownership rule as `bindPendingSession`, in one place: "which of this
+ * repo's queued prompts hang off this create" is a question three call sites
+ * ask, and answering it differently in any of them is how a second create's
+ * chain gets failed by the first one's bad news.
+ */
+export function ownedPendingCreates(entries, lane, createAck) {
+    return entries.filter((e) => e.pendingCreate && e.sessionId === lane && e.status === "queued" && ownedByCreate(e, createAck));
+}
+/**
+ * Drop the park flag on the entries `selectSendable` just released: the turn
+ * they were waiting for has ended, so they are ordinary queued messages now.
+ *
+ * Clearing the flag is the whole job. It used to also restamp `ts`, because
+ * that clock decided when the entry was shredded as "queued too long" and an
+ * entry parked against a 35-minute turn was already past it the moment it
+ * became sendable. There is no such clock any more, so there is nothing to
+ * reset — what remains is stopping the next pass from reporting the same
+ * release for ever.
+ */
+export function applyRelease(entries, released) {
+    if (!released.length)
+        return entries.slice();
+    const ids = new Set(released.map((e) => e.ackId));
+    return entries.map((e) => (ids.has(e.ackId) ? { ...e, holdUntilIdle: undefined } : e));
+}
+//# sourceMappingURL=queuebind.js.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"queuebind.js","sourceRoot":"","sources":["../../src/queue/queuebind.ts"],"names":[],"mappings":"AAAA,qEAAqE;AACrE,+FAA+F;AAI/F;;;;;;;;;;;;;;;GAeG;AACH,MAAM,UAAU,kBAAkB,CAChC,OAAqB,EACrB,IAAY,EACZ,SAAiB,EACjB,GAAW,EACX,SAAkB;IAElB,OAAO,OAAO,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CACvB,CAAC,CAAC,aAAa,IAAI,CAAC,CAAC,SAAS,KAAK,IAAI,IAAI,aAAa,CAAC,CAAC,EAAE,SAAS,CAAC;QACpE,CAAC,CAAC,EAAE,GAAG,CAAC,EAAE,SAAS,EAAE,aAAa,EAAE,SAAS,EAAE,SAAS,EAAE,SAAS,EAAE,EAAE,EAAE,GAAG,EAAE;QAC9E,CAAC,CAAC,CAAC,CAAC,CAAC;AACX,CAAC;AAED;;;;;;;;;;;;;GAaG;AACH,SAAS,aAAa,CAAC,CAAiB,EAAE,SAAkB;IAC1D,OAAO,CAAC,SAAS,IAAI,CAAC,CAAC,CAAC,SAAS,IAAI,CAAC,CAAC,SAAS,KAAK,SAAS,CAAC;AACjE,CAAC;AAED;;;;;;;;GAQG;AACH,MAAM,UAAU,mBAAmB,CACjC,OAAqB,EACrB,IAAY,EACZ,SAAkB;IAElB,OAAO,OAAO,CAAC,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAC1B,CAAC,CAAC,aAAa,IAAI,CAAC,CAAC,SAAS,KAAK,IAAI,IAAI,CAAC,CAAC,MAAM,KAAK,QAAQ,IAAI,aAAa,CAAC,CAAC,EAAE,SAAS,CAAC,CAAC,CAAC;AACrG,CAAC;AAED;;;;;;;;;;GAUG;AACH,MAAM,UAAU,YAAY,CAA2B,OAAqB,EAAE,QAAsB;IAClG,IAAI,CAAC,QAAQ,CAAC,MAAM;QAAE,OAAO,OAAO,CAAC,KAAK,EAAE,CAAC;IAC7C,MAAM,GAAG,GAAG,IAAI,GAAG,CAAC,QAAQ,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,KAAK,CAAC,CAAC,CAAC;IAClD,OAAO,OAAO,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,EAAE,GAAG,CAAC,EAAE,aAAa,EAAE,SAAS,EAAE,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC;AACzF,CAAC"}

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

@@ -0,0 +1,175 @@
+export type SendStatus = "queued" | "pending" | "failed";
+/**
+ * What an entry DOES when it is delivered.
+ *   input   — type it into the live session (the default).
+ *   backlog — add it as a work item for the repo (`backlog.add`).
+ *   op      — a durable one-shot action (`fanout.run`, `build.run`, …) acked by
+ *             `op.ack`. An op is NOT text and must never be retargeted at
+ *             another session: its payload names its own subject.
+ *   upload  — an IMAGE waiting to reach the repo inbox. The only mode that does
+ *             not travel over the socket (it is an HTTP POST), and it is in this
+ *             queue for the ordering: a prompt that names
+ *             `.claude/inbox/<file>` must not be delivered before the file is
+ *             actually there, so the upload takes the lane ahead of it. Its
+ *             bytes live in IndexedDB, keyed by ackId.
+ */
+export type SendMode = "input" | "backlog" | "op" | "upload";
+/** The scheduler only needs these fields; the client's entry carries more. */
+export interface SendQueueEntry {
+    ackId: string;
+    /** Lane key. Entries sharing it are strictly serialized. */
+    sessionId: string;
+    /** When it was queued (ms epoch). Ordering and display only — nothing here
+     *  expires on it. */
+    ts: number;
+    status: SendStatus;
+    attempts?: number;
+    mode?: SendMode;
+    /**
+     * "Send it when the agent is done." The entry waits while its lane is busy
+     * (a turn is in flight) instead of landing in the composer mid-answer — a
+     * deliberate park, not a delivery failure. See `selectSendable`.
+     *
+     * It survives here for exactly one job the host cannot do: a CHAIN queued
+     * behind a `session.create` (prompt 2 must not be typed while prompt 1's turn
+     * is running, or the TUI concatenates them). "Wait until this repo is free"
+     * as a piece of DEFERRED work is `trigger:{kind:"idle"}` on an intent, and
+     * the host owns it.
+     */
+    holdUntilIdle?: boolean;
+    /**
+     * A prompt written for a session that DOES NOT EXIST YET — the follow-ups
+     * queued behind a `session.create` op in the same `create:<cwd>` lane.
+     *
+     * Queuing "open a CLI here" on its own is close to pointless: what you
+     * actually wanted was the work that follows it, and offline there is no
+     * session id for a `session.input` to name. So the first prompt rides INSIDE
+     * the create op (the host types it through `deliverToNewSession`) and every
+     * further one waits here until `op.ack` names the session it belongs to —
+     * `bindPendingSession` then rewrites the lane and they drain in order like
+     * any other queued text.
+     *
+     * While the flag is set the entry is UNSENDABLE and holds its lane: its
+     * `sessionId` is the lane key, not a session, and writing it to the socket
+     * would address a session id the host has never heard of. Its fate follows
+     * the create ahead of it: the client fails these alongside a create that
+     * could not be delivered.
+     */
+    pendingCreate?: boolean;
+    /**
+     * The ackId of the `session.create` this parked prompt belongs to.
+     *
+     * The lane (`create:<cwd>`) is per REPO, not per create, and more than one
+     * "open a session here and run these" can be queued for one repo — which is
+     * the whole point of writing them offline. Without this, `bindPendingSession`
+     * hands the SECOND create's chain to the FIRST session, and one create's
+     * failure fails the other's prompts. Absent on entries written by an older
+     * build; see `ownedByCreate`.
+     */
+    createAck?: string;
+    /**
+     * Set when this entry is an ANSWER to a question box (the client carries the
+     * details; the scheduler only needs to know that it is one). Two rules here
+     * depend on it: it is never retargetable (`canRetarget`), and it is queued by
+     * `answerInsertAt` rather than appended.
+     */
+    answer?: unknown;
+    /**
+     * Explicitly released by the user (tapped Send with the link up, "Try now",
+     * "Send all"). Read by `sendEligible` for the auto-send switch, and by the
+     * usage-budget hold: a person choosing to spend the last of a window is the
+     * one sender the budget was never meant to stop.
+     */
+    armed?: boolean;
+    /**
+     * The text this entry would deliver. The scheduler itself does not read it —
+     * `adoptReferencedUploads`/`danglingUploadRefs` do, because "does this prompt
+     * name a file that is still on its way?" is an ORDERING question and the
+     * ordering rules live here.
+     */
+    text?: string;
+    /** upload mode: the repo-relative path these bytes will land at (predicted at
+     *  queue time — see the client's `plannedInboxPath`). */
+    upload?: {
+        relPath: string;
+    };
+    /**
+     * The repo these words were composed for.
+     *
+     * Read by the scheduler for exactly one decision: whether a lane whose session
+     * has GONE may still be sent. With a `cwd` the host can rescue it into that
+     * repo's work items, so it must be; without one there is nowhere to put it and
+     * it is held (`goneLanes`). Everything else about it is the client's business.
+     */
+    cwd?: string;
+    /**
+     * Earliest ms-epoch this entry may be attempted again — the retry BACKOFF.
+     *
+     * It exists because the attempt counter deliberately does not bound every
+     * failure. An attempt that nobody answered (a dead tunnel, an aborted stall,
+     * a POST the browser never even made) is ROLLED BACK, so riding out an outage
+     * costs no budget — which is right, and which also means a failure mode that
+     * returns instantly and forever has nothing stopping it. The observed shape
+     * was a CORS preflight the host refused: `xhr.onerror` fires in
+     * milliseconds, the catch requeues with the attempt rolled back, the lane
+     * release re-fires the flush ~450 ms later, and the entry re-attempted at
+     * roughly 2 Hz for ever — hammering a request that could
+     * not work, repainting every queue surface in the app twice a second, and
+     * holding its lane the entire time so nothing queued behind it ever went out.
+     *
+     * So a requeued entry names when it may go again, and `selectSendable` skips
+     * it until then. It still HOLDS its lane while it waits: anything behind it
+     * was queued after it and must stay behind it.
+     */
+    retryAt?: number;
+    /**
+     * SERIALIZATION GROUP — "these must not run at the same time as each other".
+     *
+     * The lane rule already stops two messages being typed into one composer at
+     * once, but it says nothing about the work they START. A queued
+     * `session.create` is acked the moment the host has spawned the CLI and typed
+     * the first prompt, so a lane full of them drains in seconds and leaves N
+     * agents editing one repo in parallel — burning one account's usage limit N
+     * times over while finishing none of it, and writing over each other's edits.
+     *
+     * An entry carrying a group waits until the work the PREVIOUS member started
+     * has finished (`busySerial`), not merely until it was accepted. The group key
+     * is the repo directory (`serialGroup()`), so sessions in different worktrees
+     * — which is what `parallel` backlog mode makes worktrees FOR — stay
+     * independent.
+     *
+     * Only ever set client-side, and always overridable per entry: "run this one
+     * now" is a tap, not a code change.
+     */
+    serial?: string;
+    /**
+     * Attempts made, INCLUDING the ones rolled back out of `attempts`. Never
+     * decremented. `attempts` answers "should we give up?"; this answers "how
+     * long should we wait before trying again?", and the two must not be the same
+     * number — the whole point of the rollback is that a dead link does not count
+     * against giving up, while a dead link is exactly when backing off matters.
+     */
+    tries?: number;
+    /**
+     * When the FIRST delivery attempt for this entry went on the wire.
+     *
+     * `ts` is when it was queued, which on this app is routinely hours before
+     * anything could be attempted at all (composed in a tunnel, held by the
+     * auto-send switch, parked behind a create). What the give-up rule has to be
+     * measured against is how long delivery has actually been TRIED — see
+     * `minTryMs`.
+     *
+     * Absent on entries written by an older build, and absent means "no floor to
+     * apply": there is nothing to measure and the attempts cap stands alone.
+     */
+    firstTryAt?: number;
+    /**
+     * How many give-up ROUNDS this entry has already served.
+     *
+     * Running out of attempts is no longer terminal for a delivery nobody
+     * answered (see `MIN_TRY_MS`): the entry goes back to the queue on a long
+     * backoff and tries the whole ladder again. This counts those rounds, and is
+     * what sizes the wait between them (`roundDelay`). Never decremented.
+     */
+    round?: number;
+}

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

@@ -0,0 +1,4 @@
+// Cut from queue.ts (move only): the entry record
+// The one door stays `./queue.js`; this slice imports its siblings directly, never the barrel.
+export {};
+//# sourceMappingURL=queueentry.js.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"queueentry.js","sourceRoot":"","sources":["../../src/queue/queueentry.ts"],"names":[],"mappings":"AAAA,kDAAkD;AAClD,+FAA+F"}