litmus-cli 1.4.21 → 1.4.24

package/dist/lib/session-end.d.ts

@@ -0,0 +1,111 @@
+/**
+ * What happens to a NATIVE editor window when the session ends — ENG-2154.
+ *
+ * ## The decision, which this ticket was asked to make explicitly
+ *
+ * **We do not close the candidate's editor window. We tell them what the window
+ * is doing instead.** Elena asked for the opposite ("when I finish submitting
+ * can you exit out of the ID editor, because the file tree is still there even
+ * though I'm disconnecting the codebase"), so the reasons are worth stating
+ * rather than leaving in a PR description.
+ *
+ * MEASURED FIRST, on a real VS Code 1.136 / Remote-SSH 0.128.0 window connected
+ * over ssh into a container whose transport was then killed. The window does not
+ * go quiet: the title bar and the Explorer root still read `[SSH: <host>]`, the
+ * status bar flips to `Disconnected from SSH: <host>`, and the resolver raises a
+ * modal reporting that it could not establish the connection and offering to retry.
+ * So the state a candidate is left in is not a silent stale file tree — it is an
+ * ERROR DIALOG, arriving seconds after they pressed submit. That is the ENG-2066
+ * misreading pointed at a different surface: a workspace that stops working with
+ * no explanation reads as a FAILED SUBMISSION. Disambiguating it is the whole
+ * job; making the window vanish is not.
+ *
+ * And closing it is not reachable anyway, for three independent reasons:
+ *
+ *   1. **Nothing of ours is running on the laptop at submit time.** `litmus
+ *      connect` spawns the editor detached and returns; a v2 candidate then
+ *      submits from the container (`litmus push` in the editor's own remote
+ *      terminal) or from the assessment page. Closing the window would mean
+ *      leaving a background daemon on a candidate's machine for the life of the
+ *      assessment, purely to close a window.
+ *   2. **We could not honour "only the window we opened."** `code --remote` hands
+ *      the request to an already-running Electron app and exits; the window is
+ *      not a process we own. Every close mechanism available (osascript UI
+ *      scripting, PowerShell `CloseMainWindow`, wmctrl) picks its target by
+ *      window title, which is a guess that can land on a window the candidate
+ *      opened themselves. The ticket forbids exactly that.
+ *   3. **macOS gates it behind a permission the candidate has not granted.** UI
+ *      scripting needs an Automation/Accessibility grant; without it the attempt
+ *      is refused (`-1743`), and the first attempt in a fresh grant state blocks
+ *      on a system dialog — which is what ENG-1502 measured when it made its own
+ *      close best-effort and detached.
+ *
+ * A window that vanishes while somebody is reading their own code is worse than
+ * one that says what happened, and (1)-(3) mean we could only ever have vanished
+ * it unreliably. So: say it, and leave the window to them.
+ *
+ * ## Why the copy lives in a module
+ *
+ * The same answer is needed at two moments, in two commands, and a second copy
+ * of it would rot — the argument `submit-guidance.ts` and the candidate page's
+ * `workspace-guidance.ts` already make:
+ *
+ *   - `litmus connect` says it AHEAD of time, because it is the only laptop-side
+ *     moment we have, and it is the only thing that reaches a candidate whose
+ *     session ends some other way (they submit from the assessment page, the
+ *     company ends the trial, the deadline cron fires).
+ *   - `litmus push` says it AT the moment, in the terminal that is very often
+ *     the disconnecting window's own.
+ *
+ * ## What the copy may claim
+ *
+ * NO EDITOR-SPECIFIC CONTROL IS NAMED. The dialog's buttons were measured on VS
+ * Code only; Cursor resolves `ssh-remote+` through `anysphere.remote-ssh`, a
+ * different extension whose dialog we have not measured, and naming a button a
+ * candidate cannot find costs us the trust they need in the rest of the sentence
+ * (the same line `workspace-guidance.ts` draws over its tool list). What is true
+ * of both is the shape: the window stays, it reports a lost connection, and
+ * closing it is theirs to do. That bound is tighter than it first looks and
+ * Greptile caught the first draft crossing it — describing WHAT THE EDITOR WILL
+ * ASK ("and offers to try again") is as unmeasured on Cursor as naming the
+ * button would be, and a candidate told to expect a prompt that never appears
+ * is left doubting the sentence that was meant to reassure them. Only the fact
+ * of a reported disconnection is verified on both.
+ *
+ * It also may not claim the assessment is FINISHED. A submit can still owe a
+ * post-submit walkthrough, and `runPush` prints the next step right after this;
+ * the claim here is only about the workspace and the window.
+ */
+/**
+ * The state the candidate's native editor window is now in, said once.
+ *
+ * Printed after a submit that ENDED the session — a fresh capture, an
+ * `already_submitted`, or a confirmed empty submission. Never after a refusal, a
+ * cancellation or a failure: in all three the workspace is still live and the
+ * window is still connected, so this would be a lie about both.
+ *
+ * Written as a conditional ("if ... is open") because `litmus push` runs from
+ * four places — a native remote window's terminal, the browser IDE's terminal, a
+ * plain ssh session, and a laptop with an explicit token — and cannot tell them
+ * apart. The browser IDE's own tab is deliberately not mentioned: ENG-2066 ends
+ * that one by navigating it, so describing it here would contradict what that
+ * candidate is about to see.
+ */
+export declare function editorEndingLines(): string[];
+/**
+ * The same fact, said before it happens, on the native-editor path of
+ * `litmus connect`.
+ *
+ * Two lines, and deliberately no more. This is the ONLY route that reaches a
+ * candidate who ends their session from somewhere we do not run — the assessment
+ * page's Submit, End trial, the deadline cron — and for them it is the whole
+ * warning. But it is also printed at the top of a session, minutes or days
+ * before it is true, next to a Cursor notice that is already long; anything more
+ * than the fact and what to do with it is noise at the wrong moment.
+ *
+ * @param editorLabel  what the candidate calls the editor being opened, from
+ *   `NATIVE_EDITORS` — this one CAN be named, because `connect` knows which one
+ *   it is launching. The dialog's controls still cannot be.
+ */
+export declare function editorEndingForewarning(editorLabel: string): string[];
+//# sourceMappingURL=session-end.d.ts.map

package/dist/lib/session-end.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"session-end.d.ts","sourceRoot":"","sources":["../../src/lib/session-end.ts"],"names":[],"mappings":"AAEA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6EG;AAEH;;;;;;;;;;;;;;GAcG;AACH,wBAAgB,iBAAiB,IAAI,MAAM,EAAE,CAS5C;AAED;;;;;;;;;;;;;;GAcG;AACH,wBAAgB,uBAAuB,CAAC,WAAW,EAAE,MAAM,GAAG,MAAM,EAAE,CAKrE"}

package/dist/lib/session-end.js

@@ -0,0 +1,126 @@
+import chalk from "chalk";
+/**
+ * What happens to a NATIVE editor window when the session ends — ENG-2154.
+ *
+ * ## The decision, which this ticket was asked to make explicitly
+ *
+ * **We do not close the candidate's editor window. We tell them what the window
+ * is doing instead.** Elena asked for the opposite ("when I finish submitting
+ * can you exit out of the ID editor, because the file tree is still there even
+ * though I'm disconnecting the codebase"), so the reasons are worth stating
+ * rather than leaving in a PR description.
+ *
+ * MEASURED FIRST, on a real VS Code 1.136 / Remote-SSH 0.128.0 window connected
+ * over ssh into a container whose transport was then killed. The window does not
+ * go quiet: the title bar and the Explorer root still read `[SSH: <host>]`, the
+ * status bar flips to `Disconnected from SSH: <host>`, and the resolver raises a
+ * modal reporting that it could not establish the connection and offering to retry.
+ * So the state a candidate is left in is not a silent stale file tree — it is an
+ * ERROR DIALOG, arriving seconds after they pressed submit. That is the ENG-2066
+ * misreading pointed at a different surface: a workspace that stops working with
+ * no explanation reads as a FAILED SUBMISSION. Disambiguating it is the whole
+ * job; making the window vanish is not.
+ *
+ * And closing it is not reachable anyway, for three independent reasons:
+ *
+ *   1. **Nothing of ours is running on the laptop at submit time.** `litmus
+ *      connect` spawns the editor detached and returns; a v2 candidate then
+ *      submits from the container (`litmus push` in the editor's own remote
+ *      terminal) or from the assessment page. Closing the window would mean
+ *      leaving a background daemon on a candidate's machine for the life of the
+ *      assessment, purely to close a window.
+ *   2. **We could not honour "only the window we opened."** `code --remote` hands
+ *      the request to an already-running Electron app and exits; the window is
+ *      not a process we own. Every close mechanism available (osascript UI
+ *      scripting, PowerShell `CloseMainWindow`, wmctrl) picks its target by
+ *      window title, which is a guess that can land on a window the candidate
+ *      opened themselves. The ticket forbids exactly that.
+ *   3. **macOS gates it behind a permission the candidate has not granted.** UI
+ *      scripting needs an Automation/Accessibility grant; without it the attempt
+ *      is refused (`-1743`), and the first attempt in a fresh grant state blocks
+ *      on a system dialog — which is what ENG-1502 measured when it made its own
+ *      close best-effort and detached.
+ *
+ * A window that vanishes while somebody is reading their own code is worse than
+ * one that says what happened, and (1)-(3) mean we could only ever have vanished
+ * it unreliably. So: say it, and leave the window to them.
+ *
+ * ## Why the copy lives in a module
+ *
+ * The same answer is needed at two moments, in two commands, and a second copy
+ * of it would rot — the argument `submit-guidance.ts` and the candidate page's
+ * `workspace-guidance.ts` already make:
+ *
+ *   - `litmus connect` says it AHEAD of time, because it is the only laptop-side
+ *     moment we have, and it is the only thing that reaches a candidate whose
+ *     session ends some other way (they submit from the assessment page, the
+ *     company ends the trial, the deadline cron fires).
+ *   - `litmus push` says it AT the moment, in the terminal that is very often
+ *     the disconnecting window's own.
+ *
+ * ## What the copy may claim
+ *
+ * NO EDITOR-SPECIFIC CONTROL IS NAMED. The dialog's buttons were measured on VS
+ * Code only; Cursor resolves `ssh-remote+` through `anysphere.remote-ssh`, a
+ * different extension whose dialog we have not measured, and naming a button a
+ * candidate cannot find costs us the trust they need in the rest of the sentence
+ * (the same line `workspace-guidance.ts` draws over its tool list). What is true
+ * of both is the shape: the window stays, it reports a lost connection, and
+ * closing it is theirs to do. That bound is tighter than it first looks and
+ * Greptile caught the first draft crossing it — describing WHAT THE EDITOR WILL
+ * ASK ("and offers to try again") is as unmeasured on Cursor as naming the
+ * button would be, and a candidate told to expect a prompt that never appears
+ * is left doubting the sentence that was meant to reassure them. Only the fact
+ * of a reported disconnection is verified on both.
+ *
+ * It also may not claim the assessment is FINISHED. A submit can still owe a
+ * post-submit walkthrough, and `runPush` prints the next step right after this;
+ * the claim here is only about the workspace and the window.
+ */
+/**
+ * The state the candidate's native editor window is now in, said once.
+ *
+ * Printed after a submit that ENDED the session — a fresh capture, an
+ * `already_submitted`, or a confirmed empty submission. Never after a refusal, a
+ * cancellation or a failure: in all three the workspace is still live and the
+ * window is still connected, so this would be a lie about both.
+ *
+ * Written as a conditional ("if ... is open") because `litmus push` runs from
+ * four places — a native remote window's terminal, the browser IDE's terminal, a
+ * plain ssh session, and a laptop with an explicit token — and cannot tell them
+ * apart. The browser IDE's own tab is deliberately not mentioned: ENG-2066 ends
+ * that one by navigating it, so describing it here would contradict what that
+ * candidate is about to see.
+ */
+export function editorEndingLines() {
+    return [
+        "",
+        "  If VS Code or Cursor is open on this workspace, that window stays open on your",
+        "  machine and will report a lost connection. That is not a failed submission — it is",
+        "  this session ending, and nothing is left to save.",
+        `  ${chalk.dim("Close the window whenever you are ready; we do not close it for you.")}`,
+        "",
+    ];
+}
+/**
+ * The same fact, said before it happens, on the native-editor path of
+ * `litmus connect`.
+ *
+ * Two lines, and deliberately no more. This is the ONLY route that reaches a
+ * candidate who ends their session from somewhere we do not run — the assessment
+ * page's Submit, End trial, the deadline cron — and for them it is the whole
+ * warning. But it is also printed at the top of a session, minutes or days
+ * before it is true, next to a Cursor notice that is already long; anything more
+ * than the fact and what to do with it is noise at the wrong moment.
+ *
+ * @param editorLabel  what the candidate calls the editor being opened, from
+ *   `NATIVE_EDITORS` — this one CAN be named, because `connect` knows which one
+ *   it is launching. The dialog's controls still cannot be.
+ */
+export function editorEndingForewarning(editorLabel) {
+    return [
+        chalk.dim(`  When your assessment ends, this ${editorLabel} window loses its connection and`),
+        chalk.dim("  reports an error. That is the session ending, not a failure — close it then."),
+    ];
+}
+//# sourceMappingURL=session-end.js.map

package/dist/lib/session-end.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"session-end.js","sourceRoot":"","sources":["../../src/lib/session-end.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,MAAM,OAAO,CAAA;AAEzB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6EG;AAEH;;;;;;;;;;;;;;GAcG;AACH,MAAM,UAAU,iBAAiB;IAC/B,OAAO;QACL,EAAE;QACF,kFAAkF;QAClF,sFAAsF;QACtF,qDAAqD;QACrD,KAAK,KAAK,CAAC,GAAG,CAAC,sEAAsE,CAAC,EAAE;QACxF,EAAE;KACH,CAAA;AACH,CAAC;AAED;;;;;;;;;;;;;;GAcG;AACH,MAAM,UAAU,uBAAuB,CAAC,WAAmB;IACzD,OAAO;QACL,KAAK,CAAC,GAAG,CAAC,qCAAqC,WAAW,kCAAkC,CAAC;QAC7F,KAAK,CAAC,GAAG,CAAC,gFAAgF,CAAC;KAC5F,CAAA;AACH,CAAC"}

package/dist/lib/submit-route.d.ts

@@ -0,0 +1,68 @@
+/**
+ * Which command actually hands work in, for the install this CLI is running from
+ * (ENG-2130).
+ *
+ * There are two flows and each has exactly one submit command:
+ *
+ *   * ON A LAPTOP (the CLI flow) it is `litmus submit`, which zips the local
+ *     checkout and uploads it to `/cli/submit`.
+ *   * INSIDE A CODESPACES v2 WORKSPACE it is `litmus push`, which POSTs
+ *     `/workspace/submit` — the same endpoint the assessment page's Submit
+ *     button calls, capturing the live container filesystem host-side (ENG-621).
+ *     There is nothing local to zip.
+ *
+ * WHY THIS MODULE EXISTS RATHER THAN A CHECK PER SITE. Before ENG-2064 the CLI
+ * was not in the container at all, so `litmus submit` there was `command not
+ * found` — useless but unambiguous. That ticket put the CLI on the container's
+ * PATH and wired the injected `LITMUS_ASSESSMENT_TOKEN` into `push` alone, so
+ * `submit` became present, runnable, and unable to authenticate: it reads its
+ * bearer from `.litmus/config.json`, and `hostd._stage_litmus_config` writes
+ * that file with DELIBERATELY no `token` because it rides the submission zip and
+ * the R2 durability tar, where a live credential must never sit. The upload
+ * therefore went out as a literal `Authorization: Bearer undefined` and was
+ * refused — AFTER the archive had been built, so a candidate read it as an
+ * upload failure rather than as the wrong command. Every surface that names a
+ * submit command was naming the laptop one to both audiences, so the answer is
+ * derived in one place and the sites ask.
+ *
+ * NOT FIXED BY GIVING `submit` THE ENV FALLBACK `push` HAS. That would make the
+ * command "work", but it routes a v2 candidate down `/cli/submit`, which grades
+ * an uploaded zip, while v2's canonical submit grades the live filesystem — the
+ * two flows would then disagree about what a submission is. That is a product
+ * decision, not a patch. And it must NOT be fixed by writing the token into
+ * `.litmus/config.json`, for the reason that file has none today.
+ *
+ * The predicate is `isWorkspaceInstall`, read from our own module path for the
+ * reasons its own docstring gives (an env marker is absent in an sshd session,
+ * and a marker injected alongside the token disappears in exactly the case we
+ * need to describe). Nothing security-relevant hangs off any of this: it only
+ * decides which command a candidate is told to run.
+ */
+/** The submit command inside a Codespaces v2 workspace. */
+export declare const WORKSPACE_SUBMIT_COMMAND = "litmus push";
+/** The submit command on the candidate's own machine. */
+export declare const LOCAL_SUBMIT_COMMAND = "litmus submit";
+/**
+ * The command that submits, for the install `moduleUrl` belongs to.
+ *
+ * Callers pass their own `import.meta.url`. Use this anywhere candidate-facing
+ * copy names the submit command, so a workspace terminal is never told to run
+ * the laptop one.
+ */
+export declare function submitCommandFor(moduleUrl: string): string;
+/** A refusal to run, as `fatal(message, hint)` takes it. */
+export type SubmitRefusal = {
+    message: string;
+    hint: string;
+};
+/**
+ * Why `litmus submit` must not run here, or `null` when it may.
+ *
+ * Non-null only for the in-workspace install. The caller is expected to refuse
+ * on it BEFORE doing any work — the whole defect is that the failure used to
+ * arrive after a full archive build, which is what made it read as an upload
+ * problem. Both routes named in the hint reach `/workspace/submit`, so this
+ * points at the two things that work and sends the candidate nowhere new.
+ */
+export declare function workspaceSubmitRefusal(moduleUrl: string): SubmitRefusal | null;
+//# sourceMappingURL=submit-route.d.ts.map

package/dist/lib/submit-route.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"submit-route.d.ts","sourceRoot":"","sources":["../../src/lib/submit-route.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAuCG;AAIH,2DAA2D;AAC3D,eAAO,MAAM,wBAAwB,gBAAgB,CAAA;AAErD,yDAAyD;AACzD,eAAO,MAAM,oBAAoB,kBAAkB,CAAA;AAEnD;;;;;;GAMG;AACH,wBAAgB,gBAAgB,CAAC,SAAS,EAAE,MAAM,GAAG,MAAM,CAE1D;AAED,4DAA4D;AAC5D,MAAM,MAAM,aAAa,GAAG;IAC1B,OAAO,EAAE,MAAM,CAAA;IACf,IAAI,EAAE,MAAM,CAAA;CACb,CAAA;AAED;;;;;;;;GAQG;AACH,wBAAgB,sBAAsB,CAAC,SAAS,EAAE,MAAM,GAAG,aAAa,GAAG,IAAI,CAO9E"}

package/dist/lib/submit-route.js

@@ -0,0 +1,73 @@
+/**
+ * Which command actually hands work in, for the install this CLI is running from
+ * (ENG-2130).
+ *
+ * There are two flows and each has exactly one submit command:
+ *
+ *   * ON A LAPTOP (the CLI flow) it is `litmus submit`, which zips the local
+ *     checkout and uploads it to `/cli/submit`.
+ *   * INSIDE A CODESPACES v2 WORKSPACE it is `litmus push`, which POSTs
+ *     `/workspace/submit` — the same endpoint the assessment page's Submit
+ *     button calls, capturing the live container filesystem host-side (ENG-621).
+ *     There is nothing local to zip.
+ *
+ * WHY THIS MODULE EXISTS RATHER THAN A CHECK PER SITE. Before ENG-2064 the CLI
+ * was not in the container at all, so `litmus submit` there was `command not
+ * found` — useless but unambiguous. That ticket put the CLI on the container's
+ * PATH and wired the injected `LITMUS_ASSESSMENT_TOKEN` into `push` alone, so
+ * `submit` became present, runnable, and unable to authenticate: it reads its
+ * bearer from `.litmus/config.json`, and `hostd._stage_litmus_config` writes
+ * that file with DELIBERATELY no `token` because it rides the submission zip and
+ * the R2 durability tar, where a live credential must never sit. The upload
+ * therefore went out as a literal `Authorization: Bearer undefined` and was
+ * refused — AFTER the archive had been built, so a candidate read it as an
+ * upload failure rather than as the wrong command. Every surface that names a
+ * submit command was naming the laptop one to both audiences, so the answer is
+ * derived in one place and the sites ask.
+ *
+ * NOT FIXED BY GIVING `submit` THE ENV FALLBACK `push` HAS. That would make the
+ * command "work", but it routes a v2 candidate down `/cli/submit`, which grades
+ * an uploaded zip, while v2's canonical submit grades the live filesystem — the
+ * two flows would then disagree about what a submission is. That is a product
+ * decision, not a patch. And it must NOT be fixed by writing the token into
+ * `.litmus/config.json`, for the reason that file has none today.
+ *
+ * The predicate is `isWorkspaceInstall`, read from our own module path for the
+ * reasons its own docstring gives (an env marker is absent in an sshd session,
+ * and a marker injected alongside the token disappears in exactly the case we
+ * need to describe). Nothing security-relevant hangs off any of this: it only
+ * decides which command a candidate is told to run.
+ */
+import { isWorkspaceInstall } from "./workspace-token.js";
+/** The submit command inside a Codespaces v2 workspace. */
+export const WORKSPACE_SUBMIT_COMMAND = "litmus push";
+/** The submit command on the candidate's own machine. */
+export const LOCAL_SUBMIT_COMMAND = "litmus submit";
+/**
+ * The command that submits, for the install `moduleUrl` belongs to.
+ *
+ * Callers pass their own `import.meta.url`. Use this anywhere candidate-facing
+ * copy names the submit command, so a workspace terminal is never told to run
+ * the laptop one.
+ */
+export function submitCommandFor(moduleUrl) {
+    return isWorkspaceInstall(moduleUrl) ? WORKSPACE_SUBMIT_COMMAND : LOCAL_SUBMIT_COMMAND;
+}
+/**
+ * Why `litmus submit` must not run here, or `null` when it may.
+ *
+ * Non-null only for the in-workspace install. The caller is expected to refuse
+ * on it BEFORE doing any work — the whole defect is that the failure used to
+ * arrive after a full archive build, which is what made it read as an upload
+ * problem. Both routes named in the hint reach `/workspace/submit`, so this
+ * points at the two things that work and sends the candidate nowhere new.
+ */
+export function workspaceSubmitRefusal(moduleUrl) {
+    if (!isWorkspaceInstall(moduleUrl))
+        return null;
+    return {
+        message: "`litmus submit` cannot submit a Litmus workspace: it uploads a local checkout, and your work lives in this container.",
+        hint: `Run \`${WORKSPACE_SUBMIT_COMMAND}\` in this terminal instead, or click Submit assessment on your assessment page.`,
+    };
+}
+//# sourceMappingURL=submit-route.js.map

package/dist/lib/submit-route.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"submit-route.js","sourceRoot":"","sources":["../../src/lib/submit-route.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAuCG;AAEH,OAAO,EAAE,kBAAkB,EAAE,MAAM,sBAAsB,CAAA;AAEzD,2DAA2D;AAC3D,MAAM,CAAC,MAAM,wBAAwB,GAAG,aAAa,CAAA;AAErD,yDAAyD;AACzD,MAAM,CAAC,MAAM,oBAAoB,GAAG,eAAe,CAAA;AAEnD;;;;;;GAMG;AACH,MAAM,UAAU,gBAAgB,CAAC,SAAiB;IAChD,OAAO,kBAAkB,CAAC,SAAS,CAAC,CAAC,CAAC,CAAC,wBAAwB,CAAC,CAAC,CAAC,oBAAoB,CAAA;AACxF,CAAC;AAQD;;;;;;;;GAQG;AACH,MAAM,UAAU,sBAAsB,CAAC,SAAiB;IACtD,IAAI,CAAC,kBAAkB,CAAC,SAAS,CAAC;QAAE,OAAO,IAAI,CAAA;IAC/C,OAAO;QACL,OAAO,EACL,uHAAuH;QACzH,IAAI,EAAE,SAAS,wBAAwB,kFAAkF;KAC1H,CAAA;AACH,CAAC"}

package/dist/lib/watcher.js

@@ -26,6 +26,7 @@ import { getEffectiveDeadline, writeConfig, validateRebuiltTimes, computeTimeSyn
 import { CLI_VERSION } from "./version.js";
 import { armDeadlinePoll, createAutoSubmitController } from "./deadline.js";
 import { resumeChainFromLog } from "./chain.js";
+import { buildGitBundle, currentHead } from "./git-bundle.js";
 import { fetchInitMetadata, ServerError } from "./api.js";
 import { ServerTimesSchema } from "./schemas.js";
 import { detectInstalledHooks } from "./ai-tracking.js";
@@ -1429,6 +1430,12 @@ function getRecentCommits() {
         return [];
     }
 }
+// ── Git history (ENG-2238) ──────────────────────────────────────
+// Capture lives in lib/git-bundle.ts; what belongs here is the one piece of
+// session state: HEAD at the last bundle the SERVER ACKED, so an unchanged
+// history is not re-uploaded every five minutes and a failed upload is still
+// retried on the next tick.
+let lastBundledHead = null;
 function uploadSnapshot() {
     if (!uploadConfig)
         return;
@@ -1449,7 +1456,17 @@ function uploadSnapshot() {
     // interview agent's context. Without this, a reconstruction restores the
     // candidate's code but none of their AI-usage evidence.
     const activityLog = readActivityLogTail(projectDir);
-    const body = JSON.stringify({ files, git_diff: gitDiff, recent_commits: recentCommits, activity_log: activityLog });
+    const head = currentHead(projectDir);
+    const bundle = head && head !== lastBundledHead ? buildGitBundle(projectDir) : null;
+    const body = JSON.stringify({
+        files,
+        git_diff: gitDiff,
+        recent_commits: recentCommits,
+        activity_log: activityLog,
+        // Omitted entirely when unchanged or unavailable; the server keeps the last
+        // good bundle rather than reading an absent field as "no history".
+        ...(bundle ? { git_bundle_gz: bundle.toString("base64") } : {}),
+    });
     const url = new URL(`${uploadConfig.backendUrl}/cli/snapshot`);
     const reqFn = url.protocol === "https:" ? https.request : http.request;
     const req = reqFn(url, {
@@ -1468,7 +1485,11 @@ function uploadSnapshot() {
                 process.stderr.write(`[watcher] snapshot upload failed: ${res.statusCode}\n`);
             }
             else {
-                process.stderr.write(`[watcher] snapshot uploaded: ${fileCount} files, ${(Buffer.byteLength(body) / 1024).toFixed(0)}KB\n`);
+                // Only now is the history durably ours: an upload that never landed
+                // must be retried on the next tick, not suppressed as already sent.
+                if (bundle && head)
+                    lastBundledHead = head;
+                process.stderr.write(`[watcher] snapshot uploaded: ${fileCount} files, ${(Buffer.byteLength(body) / 1024).toFixed(0)}KB${bundle ? ` (+git history ${(bundle.length / 1024).toFixed(0)}KB)` : ""}\n`);
             }
         });
     });