litmus-cli 1.4.32 → 1.4.34

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

@@ -1,42 +1,39 @@
 /**
- * Which command actually hands work in, for the install this CLI is running from
- * (ENG-2130).
+ * Which command hands work in, for the install this CLI is running from.
  *
- * There are two flows and each has exactly one submit command:
+ * There are two flows, and inside a Codespaces v2 workspace both names reach the
+ * same place:
  *
- *   * 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.
+ *   * ON A LAPTOP (the CLI flow) `litmus submit` zips the local checkout and
+ *     uploads it to `/cli/submit`.
+ *   * INSIDE A WORKSPACE `litmus push` 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.
+ *     Since ENG-2523 `litmus submit` there runs `push` rather than refusing
+ *     (ENG-2130), because candidates reach for `submit` and a refusal sent them
+ *     back to the browser to press the button.
  *
- * 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.
+ * WHY `submit` DELEGATES RATHER THAN READING THE INJECTED TOKEN ITSELF. Giving it
+ * the env fallback `push` has would route 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.
+ * Delegating keeps one definition. The token must also never be written into
+ * `.litmus/config.json` (what `submit` reads on a laptop): hostd stages that file
+ * with deliberately no `token` because it rides the submission zip and the R2
+ * durability tar.
  *
- * 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.
+ * WHY THE COMMAND WE NAME IS STILL `push`. `submitCommandFor` answers `push`
+ * inside a workspace even though `submit` now works there, because the delegation
+ * is keyed on the INSTALL, not the assessment: a v2 candidate who learns
+ * `litmus submit` and runs it on their own laptop uploads whatever local folder
+ * they are in, and `/cli/submit` does not check the provider. `push` does the
+ * right thing from either place, so it is the one to teach.
  *
  * 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.
+ * decides which command runs and which one a candidate is told to run.
  */
 /** The submit command inside a Codespaces v2 workspace. */
 export declare const WORKSPACE_SUBMIT_COMMAND = "litmus push";
@@ -50,19 +47,13 @@ export declare const LOCAL_SUBMIT_COMMAND = "litmus submit";
  * 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.
+ * Whether `litmus submit` should submit the workspace (run `push`) instead of
+ * zipping a local checkout.
  *
- * 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.
+ * True only for the in-workspace install. The caller must ask BEFORE doing any
+ * work: the laptop path walks the cwd, reads `.litmus/config.json` and builds an
+ * archive, none of which means anything in a workspace (ENG-2130).
  */
-export declare function workspaceSubmitRefusal(moduleUrl: string): SubmitRefusal | null;
+export declare function submitsWorkspace(moduleUrl: string): boolean;
 //# sourceMappingURL=submit-route.d.ts.map

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

@@ -1 +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"}
+{"version":3,"file":"submit-route.d.ts","sourceRoot":"","sources":["../../src/lib/submit-route.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAoCG;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;;;;;;;GAOG;AACH,wBAAgB,gBAAgB,CAAC,SAAS,EAAE,MAAM,GAAG,OAAO,CAE3D"}

package/dist/lib/submit-route.js

@@ -1,42 +1,39 @@
 /**
- * Which command actually hands work in, for the install this CLI is running from
- * (ENG-2130).
+ * Which command hands work in, for the install this CLI is running from.
  *
- * There are two flows and each has exactly one submit command:
+ * There are two flows, and inside a Codespaces v2 workspace both names reach the
+ * same place:
  *
- *   * 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.
+ *   * ON A LAPTOP (the CLI flow) `litmus submit` zips the local checkout and
+ *     uploads it to `/cli/submit`.
+ *   * INSIDE A WORKSPACE `litmus push` 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.
+ *     Since ENG-2523 `litmus submit` there runs `push` rather than refusing
+ *     (ENG-2130), because candidates reach for `submit` and a refusal sent them
+ *     back to the browser to press the button.
  *
- * 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.
+ * WHY `submit` DELEGATES RATHER THAN READING THE INJECTED TOKEN ITSELF. Giving it
+ * the env fallback `push` has would route 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.
+ * Delegating keeps one definition. The token must also never be written into
+ * `.litmus/config.json` (what `submit` reads on a laptop): hostd stages that file
+ * with deliberately no `token` because it rides the submission zip and the R2
+ * durability tar.
  *
- * 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.
+ * WHY THE COMMAND WE NAME IS STILL `push`. `submitCommandFor` answers `push`
+ * inside a workspace even though `submit` now works there, because the delegation
+ * is keyed on the INSTALL, not the assessment: a v2 candidate who learns
+ * `litmus submit` and runs it on their own laptop uploads whatever local folder
+ * they are in, and `/cli/submit` does not check the provider. `push` does the
+ * right thing from either place, so it is the one to teach.
  *
  * 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.
+ * decides which command runs and which one a candidate is told to run.
  */
 import { isWorkspaceInstall } from "./workspace-token.js";
 /** The submit command inside a Codespaces v2 workspace. */
@@ -54,20 +51,14 @@ 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.
+ * Whether `litmus submit` should submit the workspace (run `push`) instead of
+ * zipping a local checkout.
  *
- * 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.
+ * True only for the in-workspace install. The caller must ask BEFORE doing any
+ * work: the laptop path walks the cwd, reads `.litmus/config.json` and builds an
+ * archive, none of which means anything in a workspace (ENG-2130).
  */
-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.`,
-    };
+export function submitsWorkspace(moduleUrl) {
+    return isWorkspaceInstall(moduleUrl);
 }
 //# sourceMappingURL=submit-route.js.map

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

@@ -1 +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"}
+{"version":3,"file":"submit-route.js","sourceRoot":"","sources":["../../src/lib/submit-route.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAoCG;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;AAED;;;;;;;GAOG;AACH,MAAM,UAAU,gBAAgB,CAAC,SAAiB;IAChD,OAAO,kBAAkB,CAAC,SAAS,CAAC,CAAA;AACtC,CAAC"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "litmus-cli",
-  "version": "1.4.32",
+  "version": "1.4.34",
   "description": "CLI tool for Litmus engineering assessments",
   "license": "MIT",
   "author": "elenazhao",