@rosthq/cli 0.7.140 → 0.7.141

package/README.md

@@ -119,11 +119,16 @@ rost onboard source-ingest \
 The JSON output contains the opaque `source_upload_id` and the exact
 `source_ref` object to place in the setup plan's `sources[]`.
 
-Transport note: the command body is capped server-side at 1 MiB, and base64
-expands content by 4/3 — so the largest source file reachable through this
-command today is about 780 KB, not the protocol's documented 5,000,000-byte
-bound. The CLI checks this before sending and names the exact fitting size;
-split or trim a larger export.
+Transport note: two ceilings apply, and the smaller one wins. The application
+caps the command body at 1 MiB for most commands, but `onboarding.source_ingest`
+gets a selectively raised cap (≈ 6.7 MB) sized for its base64 expansion (×4/3).
+The hosting platform enforces a lower request-body ceiling in front of that —
+measured at **at least 4 MiB**, the largest body proven to reach the function —
+and rejects a larger body at the edge before the application sees it. Base64
+expansion therefore puts the largest source file this command can carry at
+roughly **3.1 MB**, not the protocol's documented 5,000,000-byte bound. The CLI
+derives its pre-check from the platform ceiling and names the exact fitting size
+before sending; split or trim a larger export.
 
 Stage the one-approval composite setup with the complete declarative plan
 (`--input '<json>'` inline, or `--input-file <path>` for a large plan):

package/dist/commands/onboarding.d.ts

@@ -7,6 +7,26 @@ export type OnboardingDeps = {
     makeClient(): Promise<CommandClient>;
     readFile?: (path: string) => Promise<Buffer>;
 };
+/**
+ * The largest source file this invocation can actually send: the smallest of the
+ * three real limits, derived ONCE so the byte count the CLI PRINTS is the byte
+ * count it ENFORCES.
+ *
+ * Exported and parameterised on `bodyCapBytes` for one reason: the
+ * `ONBOARDING_SOURCE_MAX_BYTES` clamp is **not the binding term today** — the
+ * platform ceiling puts the transport-derived term at ~3.14 MB, well under the
+ * 5,000,000-byte protocol bound — so no fixture built from the shipped constants
+ * can exercise it, and an untestable clamp is indistinguishable from a clamp that
+ * does not work. It becomes binding the moment the effective body cap rises above
+ * `ceil(ONBOARDING_SOURCE_MAX_BYTES / 3) * 4 + margins`, which is exactly what
+ * happens when the platform ceiling is raised (DER-2927). Passing the cap in lets
+ * a test pin that future without waiting for it.
+ *
+ * `overheadBytes` is the invocation's own serialized size measured with an EMPTY
+ * `content_base64`; base64 is ASCII, so its character length equals its UTF-8 byte
+ * length and the remaining budget converts at 4 base64 chars per 3 source bytes.
+ */
+export declare function maxSendableSourceFileBytes(overheadBytes: number, bodyCapBytes?: number): number;
 export type OnboardingInvocation = {
     commandId: "onboarding.status" | "onboarding.resume" | "onboarding.rehearse" | "onboarding.activate" | "onboarding.source_ingest" | "onboarding.setup";
     body: Record<string, unknown>;

package/dist/commands/onboarding.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"onboarding.d.ts","sourceRoot":"","sources":["../../src/commands/onboarding.ts"],"names":[],"mappings":"AAEA,OAAO,EAAE,aAAa,EAAsB,MAAM,sBAAsB,CAAC;AAMzE,KAAK,KAAK,GAAG;IACX,MAAM,EAAE,IAAI,CAAC,MAAM,CAAC,WAAW,EAAE,OAAO,CAAC,CAAC;IAC1C,MAAM,EAAE,IAAI,CAAC,MAAM,CAAC,WAAW,EAAE,OAAO,CAAC,CAAC;CAC3C,CAAC;AAEF,MAAM,MAAM,cAAc,GAAG;IAI3B,UAAU,IAAI,OAAO,CAAC,aAAa,CAAC,CAAC;IAGrC,QAAQ,CAAC,EAAE,CAAC,IAAI,EAAE,MAAM,KAAK,OAAO,CAAC,MAAM,CAAC,CAAC;CAC9C,CAAC;AAmDF,MAAM,MAAM,oBAAoB,GAAG;IACjC,SAAS,EACL,mBAAmB,GACnB,mBAAmB,GACnB,qBAAqB,GACrB,qBAAqB,GACrB,0BAA0B,GAC1B,kBAAkB,CAAC;IACvB,IAAI,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC;IAC9B,IAAI,EAAE,OAAO,CAAC;IACd,MAAM,EAAE,QAAQ,GAAG,QAAQ,GAAG,UAAU,GAAG,UAAU,GAAG,eAAe,GAAG,OAAO,GAAG,cAAc,CAAC;IAInG,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,SAAS,CAAC,EAAE,MAAM,CAAC;CACpB,CAAC;AAEF,qBAAa,oBAAqB,SAAQ,KAAK;gBACjC,OAAO,EAAE,MAAM;CAI5B;AAED,wBAAsB,aAAa,CAAC,IAAI,EAAE,MAAM,EAAE,EAAE,EAAE,EAAE,KAAK,EAAE,IAAI,EAAE,cAAc,GAAG,OAAO,CAAC,MAAM,CAAC,CAepG;AAED;;;;;;;GAOG;AACH,wBAAsB,2BAA2B,CAC/C,UAAU,EAAE,oBAAoB,EAChC,EAAE,EAAE,KAAK,EACT,MAAM,EAAE,aAAa,GACpB,OAAO,CAAC,MAAM,CAAC,CAAC;AACnB,wBAAsB,2BAA2B,CAC/C,UAAU,EAAE,oBAAoB,EAChC,EAAE,EAAE,KAAK,EACT,MAAM,EAAE,aAAa,EACrB,OAAO,EAAE;IAAE,OAAO,EAAE,CAAC,KAAK,EAAE,OAAO,KAAK,SAAS,GAAG,OAAO,CAAA;CAAE,GAC5D,OAAO,CAAC,MAAM,GAAG,cAAc,CAAC,CAAC;AAoCpC;;;;;GAKG;AACH,wBAAsB,gCAAgC,CACpD,UAAU,EAAE,oBAAoB,EAChC,YAAY,GAAE,CAAC,IAAI,EAAE,MAAM,KAAK,OAAO,CAAC,MAAM,CAAY,GACzD,OAAO,CAAC,IAAI,CAAC,CA8Cf;AAgDD,wBAAgB,yBAAyB,CAAC,IAAI,EAAE,MAAM,EAAE,GAAG,oBAAoB,CA+G9E;AA2FD,wBAAgB,eAAe,IAAI,MAAM,CAUxC;AAED,wBAAgB,sBAAsB,CACpC,MAAM,EAAE,oBAAoB,CAAC,QAAQ,CAAC,EACtC,MAAM,EAAE,OAAO,GACd,MAAM,CAoBR"}
+{"version":3,"file":"onboarding.d.ts","sourceRoot":"","sources":["../../src/commands/onboarding.ts"],"names":[],"mappings":"AAQA,OAAO,EAAE,aAAa,EAAsB,MAAM,sBAAsB,CAAC;AAMzE,KAAK,KAAK,GAAG;IACX,MAAM,EAAE,IAAI,CAAC,MAAM,CAAC,WAAW,EAAE,OAAO,CAAC,CAAC;IAC1C,MAAM,EAAE,IAAI,CAAC,MAAM,CAAC,WAAW,EAAE,OAAO,CAAC,CAAC;CAC3C,CAAC;AAEF,MAAM,MAAM,cAAc,GAAG;IAI3B,UAAU,IAAI,OAAO,CAAC,aAAa,CAAC,CAAC;IAGrC,QAAQ,CAAC,EAAE,CAAC,IAAI,EAAE,MAAM,KAAK,OAAO,CAAC,MAAM,CAAC,CAAC;CAC9C,CAAC;AAkDF;;;;;;;;;;;;;;;;;;GAkBG;AACH,wBAAgB,0BAA0B,CACxC,aAAa,EAAE,MAAM,EACrB,YAAY,GAAE,MAAsC,GACnD,MAAM,CAMR;AAqBD,MAAM,MAAM,oBAAoB,GAAG;IACjC,SAAS,EACL,mBAAmB,GACnB,mBAAmB,GACnB,qBAAqB,GACrB,qBAAqB,GACrB,0BAA0B,GAC1B,kBAAkB,CAAC;IACvB,IAAI,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC;IAC9B,IAAI,EAAE,OAAO,CAAC;IACd,MAAM,EAAE,QAAQ,GAAG,QAAQ,GAAG,UAAU,GAAG,UAAU,GAAG,eAAe,GAAG,OAAO,GAAG,cAAc,CAAC;IAInG,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,SAAS,CAAC,EAAE,MAAM,CAAC;CACpB,CAAC;AAEF,qBAAa,oBAAqB,SAAQ,KAAK;gBACjC,OAAO,EAAE,MAAM;CAI5B;AAED,wBAAsB,aAAa,CAAC,IAAI,EAAE,MAAM,EAAE,EAAE,EAAE,EAAE,KAAK,EAAE,IAAI,EAAE,cAAc,GAAG,OAAO,CAAC,MAAM,CAAC,CAepG;AAED;;;;;;;GAOG;AACH,wBAAsB,2BAA2B,CAC/C,UAAU,EAAE,oBAAoB,EAChC,EAAE,EAAE,KAAK,EACT,MAAM,EAAE,aAAa,GACpB,OAAO,CAAC,MAAM,CAAC,CAAC;AACnB,wBAAsB,2BAA2B,CAC/C,UAAU,EAAE,oBAAoB,EAChC,EAAE,EAAE,KAAK,EACT,MAAM,EAAE,aAAa,EACrB,OAAO,EAAE;IAAE,OAAO,EAAE,CAAC,KAAK,EAAE,OAAO,KAAK,SAAS,GAAG,OAAO,CAAA;CAAE,GAC5D,OAAO,CAAC,MAAM,GAAG,cAAc,CAAC,CAAC;AAoCpC;;;;;GAKG;AACH,wBAAsB,gCAAgC,CACpD,UAAU,EAAE,oBAAoB,EAChC,YAAY,GAAE,CAAC,IAAI,EAAE,MAAM,KAAK,OAAO,CAAC,MAAM,CAAY,GACzD,OAAO,CAAC,IAAI,CAAC,CAqEf;AAgDD,wBAAgB,yBAAyB,CAAC,IAAI,EAAE,MAAM,EAAE,GAAG,oBAAoB,CA+G9E;AA2FD,wBAAgB,eAAe,IAAI,MAAM,CAUxC;AAED,wBAAgB,sBAAsB,CACpC,MAAM,EAAE,oBAAoB,CAAC,QAAQ,CAAC,EACtC,MAAM,EAAE,OAAO,GACd,MAAM,CAoBR"}

package/dist/index.js

@@ -36074,6 +36074,9 @@ var canonicalReadingDecimalSchema = external_exports.string().trim().min(1).max(
 var managedInferenceHardCapSchema = external_exports.string().trim().max(11).regex(/^(?:0|[1-9]\d{0,7})\.\d{2}$/);
 var ONBOARDING_SETUP_PLAN_MAX_BYTES = 1048576;
 var ONBOARDING_SOURCE_MAX_BYTES = 5e6;
+var ONBOARDING_SOURCE_INGEST_BODY_MARGIN_BYTES = 8192;
+var ONBOARDING_SOURCE_INGEST_BODY_CAP_BYTES = Math.ceil(ONBOARDING_SOURCE_MAX_BYTES / 3) * 4 + ONBOARDING_SOURCE_INGEST_BODY_MARGIN_BYTES;
+var COMMAND_TRANSPORT_PLATFORM_BODY_CEILING_BYTES = 4194304;
 var onboardingSourceKindSchema = external_exports.enum([
   "org_chart",
   "signal_export",
@@ -53708,7 +53711,7 @@ External connectors are being rolled out provider by provider, conservatively (r
     order: 48,
     title: "CLI and MCP installation guide",
     summary: "Install the public CLI, register remote token-backed MCP clients, and find the full command and tool catalog.",
-    version: "2026-07-31.1",
+    version: "2026-07-31.2",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing"],
@@ -54242,7 +54245,7 @@ These are the security posture rules for operating after install \u2014 a checkl
 {{cli}} onboard rehearse|activate --setup-application-id <uuid> ... [--json]
 \`\`\`
 
-Every tenant-scoped \`onboard\` verb (\`status\`, \`resume\`, \`source-ingest\`, \`setup\`, \`setup-status\`, \`rehearse\`, \`activate\` \u2014 \`onboard run\` is an offline public print) authenticates with an existing implementation-bootstrap credential first and falls back to the user session, so the agent-led composite flow works without a personal login. \`onboard source-ingest\` reads one local business file client-side, base64-encodes it, and calls \`onboarding.source_ingest\`; the server computes the digest and family manifest and returns the opaque \`source_ref\` to reference from the setup plan's \`sources[]\` (paths and client digests are rejected). The server's 1 MiB command-body cap is authoritative, and base64 expands content by 4/3, so the largest file reachable through this command today is about 780 KB \u2014 the CLI pre-checks and names the exact fitting size; split a larger export. \`onboard setup\` submits the complete declarative plan to \`onboarding.setup\`: staging succeeds with exit code 0 and prints the pending confirmation id plus the exact approval URL (with \`--json\`, the full pending-confirmation object). \`onboard setup-status\` re-submits the identical plan to discover state through the command's idempotent contract: after approval it returns the immutable applied receipt (application id, receipt revision, input digest) without staging anything; while approval is still pending it returns the current approval card \u2014 an identical still-valid card is reused with the same confirmation id and URL, and only a changed server-derived projection supersedes the stale card and mints a fresh one. After application, a same-key re-submission with a different plan digest is a typed conflict.
+Every tenant-scoped \`onboard\` verb (\`status\`, \`resume\`, \`source-ingest\`, \`setup\`, \`setup-status\`, \`rehearse\`, \`activate\` \u2014 \`onboard run\` is an offline public print) authenticates with an existing implementation-bootstrap credential first and falls back to the user session, so the agent-led composite flow works without a personal login. \`onboard source-ingest\` reads one local business file client-side, base64-encodes it, and calls \`onboarding.source_ingest\`; the server computes the digest and family manifest and returns the opaque \`source_ref\` to reference from the setup plan's \`sources[]\` (paths and client digests are rejected). Two size ceilings apply to this upload and the smaller one wins. The application's command-body cap is 1 MiB for most commands, but \`onboarding.source_ingest\` gets a selectively raised cap (\u2248 6.7 MB, on both the REST and MCP command transports) sized for base64 expansion (\xD74/3). In front of that, the hosting platform enforces a lower request-body ceiling \u2014 measured at at least 4 MiB, the largest body proven to reach the function \u2014 and rejects a larger body at the edge before {{brand}} sees it, so no {{brand}} error can describe that failure. **The platform ceiling is what sets the maximum size.** The raised 6.7 MB application cap sits above it and so never rejects a body the platform would have delivered. The 5,000,000-byte protocol bound is still enforced \u2014 a larger file is refused on that ground first \u2014 but it too sits above the reachable size, so it never decides how large a source can actually be. Only the platform ceiling does, which is why raising the 6.7 MB cap on its own would not make a bigger source uploadable. After base64 expansion the largest source file this command can carry is therefore about **3.1 MB**, short of the protocol's documented 5,000,000-byte source range; reaching that full range needs the platform ceiling raised, which is a separate change. The CLI derives its pre-check from the platform ceiling and names the exact fitting size before sending \u2014 split a larger export. \`onboard setup\` submits the complete declarative plan to \`onboarding.setup\`: staging succeeds with exit code 0 and prints the pending confirmation id plus the exact approval URL (with \`--json\`, the full pending-confirmation object). \`onboard setup-status\` re-submits the identical plan to discover state through the command's idempotent contract: after approval it returns the immutable applied receipt (application id, receipt revision, input digest) without staging anything; while approval is still pending it returns the current approval card \u2014 an identical still-valid card is reused with the same confirmation id and URL, and only a changed server-derived projection supersedes the stale card and mints a fresh one. After application, a same-key re-submission with a different plan digest is a typed conflict.
 
 | Command | Purpose | Scope | Safe example |
 |---|---|---|---|
@@ -59058,8 +59061,18 @@ function formatStagedConfirmation(commandId, details, overrides = {}) {
 var REHEARSE_USAGE = `${cliBrand.binName} onboard rehearse --setup-application-id <uuid> --expected-input-digest <sha256:digest> --expected-receipt-revision <integer> --idempotency-key <key> [--json]`;
 var ACTIVATE_USAGE = `${cliBrand.binName} onboard activate --setup-application-id <uuid> --expected-input-digest <sha256:digest> --expected-receipt-revision <integer> --terminal-rehearsal-batch-receipt-id <uuid> --rehearsal-runs '<json-array>' --configuration-digests '<json-array>' --idempotency-key <key> [--json]`;
 var SOURCE_INGEST_USAGE = `${cliBrand.binName} onboard source-ingest --file <path> --source-key <key> --kind <kind> --title <title> [--json]`;
-var SERVER_COMMAND_BODY_CAP_BYTES = 1048576;
+var SERVER_COMMAND_BODY_CAP_BYTES = Math.min(
+  ONBOARDING_SOURCE_INGEST_BODY_CAP_BYTES,
+  COMMAND_TRANSPORT_PLATFORM_BODY_CEILING_BYTES
+);
 var COMMAND_BODY_SAFETY_MARGIN_BYTES = 4096;
+function maxSendableSourceFileBytes(overheadBytes, bodyCapBytes = SERVER_COMMAND_BODY_CAP_BYTES) {
+  const preflightCap = bodyCapBytes - COMMAND_BODY_SAFETY_MARGIN_BYTES;
+  return Math.min(
+    Math.floor((preflightCap - overheadBytes) / 4) * 3,
+    ONBOARDING_SOURCE_MAX_BYTES
+  );
+}
 var SETUP_USAGE = `${cliBrand.binName} onboard setup --input '<json-plan>' | --input-file <path> [--json]`;
 var SETUP_STATUS_USAGE = `${cliBrand.binName} onboard setup-status --input '<json-plan>' | --input-file <path> [--json]`;
 function sourceIngestKinds() {
@@ -59126,15 +59139,23 @@ async function resolveOnboardingInvocationFiles(invocation, readFileImpl = readF
     if (bytes.length === 0) {
       throw new OnboardingUsageError(`--file ${invocation.sourceFile} is empty.`);
     }
+    const overheadBytes = Buffer.byteLength(
+      JSON.stringify({ ...invocation.body, content_base64: "" }),
+      "utf8"
+    );
+    const preflightCap = SERVER_COMMAND_BODY_CAP_BYTES - COMMAND_BODY_SAFETY_MARGIN_BYTES;
+    const maxSendableFileBytes = maxSendableSourceFileBytes(overheadBytes);
+    if (bytes.length > ONBOARDING_SOURCE_MAX_BYTES) {
+      throw new OnboardingUsageError(
+        `--file ${invocation.sourceFile} is ${bytes.length} bytes, over the onboarding.source_ingest protocol's documented ${ONBOARDING_SOURCE_MAX_BYTES}-byte source range. The largest file this invocation can actually send is about ${maxSendableFileBytes} bytes. Split the export or trim rows/columns to fit.`
+      );
+    }
     const contentBase64 = bytes.toString("base64");
     invocation.body.content_base64 = contentBase64;
     const bodyBytes = Buffer.byteLength(JSON.stringify(invocation.body), "utf8");
-    const preflightCap = SERVER_COMMAND_BODY_CAP_BYTES - COMMAND_BODY_SAFETY_MARGIN_BYTES;
     if (bodyBytes > preflightCap) {
-      const overheadBytes = bodyBytes - contentBase64.length;
-      const effectiveMaxFileBytes = Math.floor((preflightCap - overheadBytes) / 4) * 3;
       throw new OnboardingUsageError(
-        `--file ${invocation.sourceFile} is ${bytes.length} bytes; base64-encoded it makes a ${bodyBytes}-byte command body, over the server's authoritative ${SERVER_COMMAND_BODY_CAP_BYTES}-byte command-transport cap (this check stops ${COMMAND_BODY_SAFETY_MARGIN_BYTES} bytes early on purpose). The largest file this invocation can send is about ${effectiveMaxFileBytes} bytes. The onboarding.source_ingest protocol documents sources up to 5,000,000 bytes; reaching that range needs the server-side transport follow-up. Split the export or trim rows/columns to fit.`
+        `--file ${invocation.sourceFile} is ${bytes.length} bytes; base64-encoded it makes a ${bodyBytes}-byte command body, over the ${preflightCap}-byte preflight budget for this command (the ${SERVER_COMMAND_BODY_CAP_BYTES}-byte request-body ceiling it has to get through, minus a deliberate ${COMMAND_BODY_SAFETY_MARGIN_BYTES}-byte margin). The largest file this invocation can send is about ${maxSendableFileBytes} bytes. Split the export or trim rows/columns to fit.`
       );
     }
     delete invocation.sourceFile;