@rubytech/create-maxy-code 0.1.459 → 0.1.461

package/payload/platform/lib/storage-broker/dist/object-limits.js

@@ -12,7 +12,7 @@
  * for. The ui route reads it through the barrel.
  */
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.R2_OBJECT_PUT_MAX_BODY_BYTES = exports.R2_OBJECT_MAX_BYTES = void 0;
+exports.R2_OBJECT_PUT_MAX_BODY_BYTES = exports.R2_OBJECT_ENVELOPE_MAX_BODY_BYTES = exports.R2_OBJECT_MAX_BYTES = void 0;
 exports.base64Ceiling = base64Ceiling;
 exports.tooLargeMessage = tooLargeMessage;
 /**
@@ -39,19 +39,39 @@ function base64Ceiling(bytes) {
     return 4 * Math.ceil(bytes / 3);
 }
 /**
- * Room for the put envelope's bucket, key and JSON punctuation, so a legal
- * at-cap put is not rejected by its own key. Far above any realistic bucket+key
- * length and far below the cap, so it cannot smuggle a meaningfully larger
- * object.
+ * The largest JSON body an object route's metadata envelope can legitimately
+ * carry: a bucket name, one key or prefix, and JSON punctuation. No payload term.
+ *
+ * Used twice, because it answers one question — how large can an envelope
+ * legitimately get. `/r2/object/list`, `get` and `delete` carry an envelope and
+ * nothing else, so this is their whole body limit (Task 1698). `put` carries the
+ * same envelope plus base64 object bytes, so it adds this to the base64 ceiling
+ * below, which is the allowance that keeps a legal at-cap put from being rejected
+ * by its own key.
+ *
+ * Deliberately one constant rather than two that happen to match. This is the
+ * opposite ruling to the email cap above, for the opposite reason: that pair must
+ * stay independent because the numbers track different constraints and would drift
+ * for different reasons. Here the constraint is identical, so a change to either
+ * use must move both.
+ *
+ * Sized from confirmed R2 limits rather than assumed. An object key is at most
+ * 1,024 bytes (developers.cloudflare.com/r2/platform/limits/) and a bucket name is
+ * 3-63 characters (developers.cloudflare.com/r2/buckets/create-buckets/), so a
+ * real envelope is about 1.1 KB, or roughly 6 KiB if every key byte takes a
+ * six-character \uXXXX escape. This clears that by about ten times and sits about
+ * 2,100 times below put's body limit: far above anything a real caller sends, far
+ * below anything that threatens house memory. Nothing here depends on either
+ * figure being exact.
  */
-const PUT_ENVELOPE_ALLOWANCE_BYTES = 64 * 1024;
+exports.R2_OBJECT_ENVELOPE_MAX_BODY_BYTES = 64 * 1024;
 /**
  * The largest JSON body /r2/object/put can legitimately carry.
  *
  * This bounds house memory; it does not adjudicate the last kilobyte. The exact
  * decoded-byte rule lives in the MCP, which knows the source's size exactly.
  */
-exports.R2_OBJECT_PUT_MAX_BODY_BYTES = base64Ceiling(exports.R2_OBJECT_MAX_BYTES) + PUT_ENVELOPE_ALLOWANCE_BYTES;
+exports.R2_OBJECT_PUT_MAX_BODY_BYTES = base64Ceiling(exports.R2_OBJECT_MAX_BYTES) + exports.R2_OBJECT_ENVELOPE_MAX_BODY_BYTES;
 function formatMiB(bytes) {
     return (bytes / 1024 / 1024).toFixed(1);
 }

package/payload/platform/lib/storage-broker/dist/object-limits.js.map

@@ -1 +1 @@
-{"version":3,"file":"object-limits.js","sourceRoot":"","sources":["../src/object-limits.ts"],"names":[],"mappings":";AAAA;;;;;;;;;;;GAWG;;;AAuBH,sCAEC;AAkCD,0CAIC;AA7DD;;;;;;;;;;;;;;;;;GAiBG;AACU,QAAA,mBAAmB,GAAG,GAAG,GAAG,IAAI,GAAG,IAAI,CAAC;AAErD,kFAAkF;AAClF,SAAgB,aAAa,CAAC,KAAa;IACzC,OAAO,CAAC,GAAG,IAAI,CAAC,IAAI,CAAC,KAAK,GAAG,CAAC,CAAC,CAAC;AAClC,CAAC;AAED;;;;;GAKG;AACH,MAAM,4BAA4B,GAAG,EAAE,GAAG,IAAI,CAAC;AAE/C;;;;;GAKG;AACU,QAAA,4BAA4B,GACvC,aAAa,CAAC,2BAAmB,CAAC,GAAG,4BAA4B,CAAC;AAEpE,SAAS,SAAS,CAAC,KAAa;IAC9B,OAAO,CAAC,KAAK,GAAG,IAAI,GAAG,IAAI,CAAC,CAAC,OAAO,CAAC,CAAC,CAAC,CAAC;AAC1C,CAAC;AAED;;;;;;;;;;GAUG;AACH,SAAgB,eAAe,CAAC,IAAY,EAAE,WAAmB;IAC/D,OAAO,GAAG,IAAI,OAAO,SAAS,CAAC,WAAW,CAAC,SAAS,WAAW,8BAA8B,SAAS,CACpG,2BAAmB,CACpB,SAAS,2BAAmB,0BAA0B,CAAC;AAC1D,CAAC"}
+{"version":3,"file":"object-limits.js","sourceRoot":"","sources":["../src/object-limits.ts"],"names":[],"mappings":";AAAA;;;;;;;;;;;GAWG;;;AAuBH,sCAEC;AAsDD,0CAIC;AAjFD;;;;;;;;;;;;;;;;;GAiBG;AACU,QAAA,mBAAmB,GAAG,GAAG,GAAG,IAAI,GAAG,IAAI,CAAC;AAErD,kFAAkF;AAClF,SAAgB,aAAa,CAAC,KAAa;IACzC,OAAO,CAAC,GAAG,IAAI,CAAC,IAAI,CAAC,KAAK,GAAG,CAAC,CAAC,CAAC;AAClC,CAAC;AAED;;;;;;;;;;;;;;;;;;;;;;;;;GAyBG;AACU,QAAA,iCAAiC,GAAG,EAAE,GAAG,IAAI,CAAC;AAE3D;;;;;GAKG;AACU,QAAA,4BAA4B,GACvC,aAAa,CAAC,2BAAmB,CAAC,GAAG,yCAAiC,CAAC;AAEzE,SAAS,SAAS,CAAC,KAAa;IAC9B,OAAO,CAAC,KAAK,GAAG,IAAI,GAAG,IAAI,CAAC,CAAC,OAAO,CAAC,CAAC,CAAC,CAAC;AAC1C,CAAC;AAED;;;;;;;;;;GAUG;AACH,SAAgB,eAAe,CAAC,IAAY,EAAE,WAAmB;IAC/D,OAAO,GAAG,IAAI,OAAO,SAAS,CAAC,WAAW,CAAC,SAAS,WAAW,8BAA8B,SAAS,CACpG,2BAAmB,CACpB,SAAS,2BAAmB,0BAA0B,CAAC;AAC1D,CAAC"}

package/payload/platform/lib/storage-broker/dist/resource-limits.d.ts

@@ -0,0 +1,102 @@
+/**
+ * The bounds on the request bodies the resource-level routes will buffer:
+ * /d1/create, /d1/query and /r2/create (Task 1702).
+ *
+ * Parallel to object-limits.ts, which bounds the object routes. Kept separate
+ * because the facts differ: an object envelope is dominated by R2's 1,024-byte
+ * object key limit, and these routes carry no key at all. Coupling them would tie
+ * a D1 database name to R2's key limit, so a revision to either would move a bound
+ * that has no reason to move.
+ *
+ * These are bounds on house memory. They do not adjudicate the last byte of a name
+ * or a statement — the same stance object-limits.ts takes, for the same reason. The
+ * house process holds the account-wide credential, so an out-of-memory kill there
+ * takes the brand server down, and on the target hardware that is a hard freeze
+ * that emits nothing.
+ *
+ * Deliberately dependency-free, like object-limits.ts: the ui route reads these
+ * through the barrel, and nothing here needs the rest of the lib.
+ */
+/**
+ * Cloudflare's documented maximum SQL statement length.
+ *
+ * "Maximum SQL statement length | 100,000 bytes (100 KB)"
+ * https://developers.cloudflare.com/d1/platform/limits/
+ *
+ * Recorded because it is what governs a legitimate `sql`, and because
+ * D1_QUERY_MAX_BODY_BYTES below is only knowable as safe by way of it.
+ *
+ * A second, independent bound applies to the same string on the way out, and is
+ * recorded here so nobody rediscovers it as a bug: cf-exec's d1Query shells
+ * `execFile("npx", ["wrangler", "d1", "execute", ..., "--command", sql])`, so the
+ * decoded statement travels as a single argv element. Linux caps one such element
+ * at MAX_ARG_STRLEN = 131,072 bytes and fails execve with E2BIG above it
+ * (https://man7.org/linux/man-pages/man2/execve.2.html). That is a property of the
+ * spawn path, not of D1. It does not bind first: 100,000 < 131,072, so a statement
+ * D1 would accept always fits the spawn.
+ */
+export declare const D1_MAX_SQL_STATEMENT_BYTES = 100000;
+/**
+ * The worst-case expansion of a byte when it is serialized into a JSON string.
+ *
+ * A single ASCII control byte becomes the six characters \uXXXX. Multi-byte
+ * characters are cheaper per byte — a 3-byte UTF-8 character also becomes six
+ * characters (2x), and a non-BMP character becomes a 12-character surrogate pair
+ * for 4 bytes (3x) — so 6 is a true ceiling over bytes, reached by ASCII.
+ *
+ * This is why a body limit is not simply the statement limit: the cap bounds the
+ * wire body, and escaping moves the two apart.
+ */
+export declare const JSON_STRING_WORST_CASE_EXPANSION = 6;
+/**
+ * The largest JSON body /d1/create or /r2/create can legitimately carry: a single
+ * resource name and JSON punctuation. No payload term, and no key term.
+ *
+ * Sized on headroom rather than a tight derivation, because only one of the two
+ * names it bounds has a documented hard limit:
+ *
+ * - R2 bucket name: 3-63 characters, lowercase letters, digits and hyphens.
+ *   https://developers.cloudflare.com/r2/buckets/create-buckets/
+ * - D1 database name: no documented limit. The API reference states only
+ *   `name: string`, "D1 database name" — no maxLength, pattern or charset.
+ *   https://developers.cloudflare.com/api/resources/d1/subresources/database/
+ *   The get-started guide gives guidance, not a limit: names "should use a
+ *   combination of ASCII characters, shorter than 32 characters".
+ *
+ * So a real body is under ~100 bytes and 64 KiB clears it by roughly 650x, while
+ * sitting ~2,100x below put's body limit: far above anything a real caller sends,
+ * far below anything that threatens house memory. Nothing here depends on either
+ * figure being exact. An undocumented D1 name limit cannot plausibly approach 64
+ * KiB, and a request body is the wrong place to discover that it had.
+ *
+ * Deliberately not R2_OBJECT_ENVELOPE_MAX_BODY_BYTES, which happens to hold the
+ * same value. That constant is governed by R2's object key limit; this one is not,
+ * and the two must be free to drift. Couple what is one fact; separate what merely
+ * matches today.
+ */
+export declare const STORAGE_RESOURCE_NAME_MAX_BODY_BYTES: number;
+/**
+ * The largest JSON body /d1/query can legitimately carry: a database name and a
+ * SQL statement.
+ *
+ * The envelope reasoning behind the object routes' bound does not govern this. A
+ * large but entirely legal migration or batch statement is not a 1,024-byte object
+ * key, so applying that constant here would reject correct queries.
+ *
+ * The bound is on the wire body, not the decoded statement, and JSON escaping moves
+ * those apart. The largest legal statement (D1_MAX_SQL_STATEMENT_BYTES) can present
+ * a wire body of up to
+ *
+ *   JSON_STRING_WORST_CASE_EXPANSION * 100,000 + 65,536 = 665,536 bytes
+ *
+ * so capping at 100,000 would 413 a statement D1 would have accepted. 1 MiB clears
+ * the worst case by about 1.6x and sits ~133x below put's body limit.
+ *
+ * It is a flat number rather than that expression, for legibility at the call site.
+ * The arithmetic is not decoration: it is the only thing that makes 1 MiB knowable
+ * as safe, so resource-limits.test.ts asserts the relationship. If D1 ever raises
+ * its statement limit above 163,840 bytes, that test fails rather than this route
+ * quietly beginning to refuse legal SQL.
+ */
+export declare const D1_QUERY_MAX_BODY_BYTES: number;
+//# sourceMappingURL=resource-limits.d.ts.map

package/payload/platform/lib/storage-broker/dist/resource-limits.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"resource-limits.d.ts","sourceRoot":"","sources":["../src/resource-limits.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;GAkBG;AAEH;;;;;;;;;;;;;;;;;GAiBG;AACH,eAAO,MAAM,0BAA0B,SAAU,CAAC;AAElD;;;;;;;;;;GAUG;AACH,eAAO,MAAM,gCAAgC,IAAI,CAAC;AAElD;;;;;;;;;;;;;;;;;;;;;;;;;GAyBG;AACH,eAAO,MAAM,oCAAoC,QAAY,CAAC;AAE9D;;;;;;;;;;;;;;;;;;;;;;GAsBG;AACH,eAAO,MAAM,uBAAuB,QAAc,CAAC"}

package/payload/platform/lib/storage-broker/dist/resource-limits.js

@@ -0,0 +1,105 @@
+"use strict";
+/**
+ * The bounds on the request bodies the resource-level routes will buffer:
+ * /d1/create, /d1/query and /r2/create (Task 1702).
+ *
+ * Parallel to object-limits.ts, which bounds the object routes. Kept separate
+ * because the facts differ: an object envelope is dominated by R2's 1,024-byte
+ * object key limit, and these routes carry no key at all. Coupling them would tie
+ * a D1 database name to R2's key limit, so a revision to either would move a bound
+ * that has no reason to move.
+ *
+ * These are bounds on house memory. They do not adjudicate the last byte of a name
+ * or a statement — the same stance object-limits.ts takes, for the same reason. The
+ * house process holds the account-wide credential, so an out-of-memory kill there
+ * takes the brand server down, and on the target hardware that is a hard freeze
+ * that emits nothing.
+ *
+ * Deliberately dependency-free, like object-limits.ts: the ui route reads these
+ * through the barrel, and nothing here needs the rest of the lib.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.D1_QUERY_MAX_BODY_BYTES = exports.STORAGE_RESOURCE_NAME_MAX_BODY_BYTES = exports.JSON_STRING_WORST_CASE_EXPANSION = exports.D1_MAX_SQL_STATEMENT_BYTES = void 0;
+/**
+ * Cloudflare's documented maximum SQL statement length.
+ *
+ * "Maximum SQL statement length | 100,000 bytes (100 KB)"
+ * https://developers.cloudflare.com/d1/platform/limits/
+ *
+ * Recorded because it is what governs a legitimate `sql`, and because
+ * D1_QUERY_MAX_BODY_BYTES below is only knowable as safe by way of it.
+ *
+ * A second, independent bound applies to the same string on the way out, and is
+ * recorded here so nobody rediscovers it as a bug: cf-exec's d1Query shells
+ * `execFile("npx", ["wrangler", "d1", "execute", ..., "--command", sql])`, so the
+ * decoded statement travels as a single argv element. Linux caps one such element
+ * at MAX_ARG_STRLEN = 131,072 bytes and fails execve with E2BIG above it
+ * (https://man7.org/linux/man-pages/man2/execve.2.html). That is a property of the
+ * spawn path, not of D1. It does not bind first: 100,000 < 131,072, so a statement
+ * D1 would accept always fits the spawn.
+ */
+exports.D1_MAX_SQL_STATEMENT_BYTES = 100_000;
+/**
+ * The worst-case expansion of a byte when it is serialized into a JSON string.
+ *
+ * A single ASCII control byte becomes the six characters \uXXXX. Multi-byte
+ * characters are cheaper per byte — a 3-byte UTF-8 character also becomes six
+ * characters (2x), and a non-BMP character becomes a 12-character surrogate pair
+ * for 4 bytes (3x) — so 6 is a true ceiling over bytes, reached by ASCII.
+ *
+ * This is why a body limit is not simply the statement limit: the cap bounds the
+ * wire body, and escaping moves the two apart.
+ */
+exports.JSON_STRING_WORST_CASE_EXPANSION = 6;
+/**
+ * The largest JSON body /d1/create or /r2/create can legitimately carry: a single
+ * resource name and JSON punctuation. No payload term, and no key term.
+ *
+ * Sized on headroom rather than a tight derivation, because only one of the two
+ * names it bounds has a documented hard limit:
+ *
+ * - R2 bucket name: 3-63 characters, lowercase letters, digits and hyphens.
+ *   https://developers.cloudflare.com/r2/buckets/create-buckets/
+ * - D1 database name: no documented limit. The API reference states only
+ *   `name: string`, "D1 database name" — no maxLength, pattern or charset.
+ *   https://developers.cloudflare.com/api/resources/d1/subresources/database/
+ *   The get-started guide gives guidance, not a limit: names "should use a
+ *   combination of ASCII characters, shorter than 32 characters".
+ *
+ * So a real body is under ~100 bytes and 64 KiB clears it by roughly 650x, while
+ * sitting ~2,100x below put's body limit: far above anything a real caller sends,
+ * far below anything that threatens house memory. Nothing here depends on either
+ * figure being exact. An undocumented D1 name limit cannot plausibly approach 64
+ * KiB, and a request body is the wrong place to discover that it had.
+ *
+ * Deliberately not R2_OBJECT_ENVELOPE_MAX_BODY_BYTES, which happens to hold the
+ * same value. That constant is governed by R2's object key limit; this one is not,
+ * and the two must be free to drift. Couple what is one fact; separate what merely
+ * matches today.
+ */
+exports.STORAGE_RESOURCE_NAME_MAX_BODY_BYTES = 64 * 1024;
+/**
+ * The largest JSON body /d1/query can legitimately carry: a database name and a
+ * SQL statement.
+ *
+ * The envelope reasoning behind the object routes' bound does not govern this. A
+ * large but entirely legal migration or batch statement is not a 1,024-byte object
+ * key, so applying that constant here would reject correct queries.
+ *
+ * The bound is on the wire body, not the decoded statement, and JSON escaping moves
+ * those apart. The largest legal statement (D1_MAX_SQL_STATEMENT_BYTES) can present
+ * a wire body of up to
+ *
+ *   JSON_STRING_WORST_CASE_EXPANSION * 100,000 + 65,536 = 665,536 bytes
+ *
+ * so capping at 100,000 would 413 a statement D1 would have accepted. 1 MiB clears
+ * the worst case by about 1.6x and sits ~133x below put's body limit.
+ *
+ * It is a flat number rather than that expression, for legibility at the call site.
+ * The arithmetic is not decoration: it is the only thing that makes 1 MiB knowable
+ * as safe, so resource-limits.test.ts asserts the relationship. If D1 ever raises
+ * its statement limit above 163,840 bytes, that test fails rather than this route
+ * quietly beginning to refuse legal SQL.
+ */
+exports.D1_QUERY_MAX_BODY_BYTES = 1024 * 1024;
+//# sourceMappingURL=resource-limits.js.map

package/payload/platform/lib/storage-broker/dist/resource-limits.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"resource-limits.js","sourceRoot":"","sources":["../src/resource-limits.ts"],"names":[],"mappings":";AAAA;;;;;;;;;;;;;;;;;;GAkBG;;;AAEH;;;;;;;;;;;;;;;;;GAiBG;AACU,QAAA,0BAA0B,GAAG,OAAO,CAAC;AAElD;;;;;;;;;;GAUG;AACU,QAAA,gCAAgC,GAAG,CAAC,CAAC;AAElD;;;;;;;;;;;;;;;;;;;;;;;;;GAyBG;AACU,QAAA,oCAAoC,GAAG,EAAE,GAAG,IAAI,CAAC;AAE9D;;;;;;;;;;;;;;;;;;;;;;GAsBG;AACU,QAAA,uBAAuB,GAAG,IAAI,GAAG,IAAI,CAAC"}

package/payload/platform/lib/storage-broker/src/__tests__/cf-exec.test.ts

@@ -359,17 +359,23 @@ test("makeHouseCfExec runs wrangler with the scoped token, not the minter", asyn
 // proves it), and every failure keeps its body.
 // ---------------------------------------------------------------------------
 
-function objectPage(keys: string[], opts: { cursor?: string; truncated?: boolean } = {}) {
+function objectPage(
+  keys: Array<string | { key: string; size: number }>,
+  opts: { cursor?: string; truncated?: boolean } = {},
+) {
   return JSON.stringify({
     success: true,
     errors: [],
     messages: [],
-    result: keys.map((key) => ({
-      key,
-      size: 10,
-      etag: "e1",
-      last_modified: "2026-01-01T00:00:00Z",
-    })),
+    result: keys.map((k) => {
+      const entry = typeof k === "string" ? { key: k, size: 10 } : k;
+      return {
+        key: entry.key,
+        size: entry.size,
+        etag: "e1",
+        last_modified: "2026-01-01T00:00:00Z",
+      };
+    }),
     result_info: { cursor: opts.cursor ?? "", is_truncated: opts.truncated ?? false },
   });
 }
@@ -544,3 +550,120 @@ test("r2ObjectList follows a cursor when is_truncated is absent, rather than tru
   assert.deepEqual((await cf.r2ObjectList("b")).map((o) => o.key), ["a.jpg", "b.jpg"]);
   assert.equal(calls.length, 2);
 });
+
+// --- r2ObjectFind (Task 1697) ---------------------------------------------
+//
+// Sizing a get needs one record, not the prefix. These tests pin the two
+// properties that make the early exit safe: it matches the exact key, and it
+// stops at the page carrying it.
+
+test("r2ObjectFind returns the exact key when a prefix neighbour is listed first", async () => {
+  // Not hypothetical. Measured 2026-07-16 against the live v4 API: prefix=
+  // a/photo.jpg really does return a/photo.jpg.bak BEFORE a/photo.jpg, because
+  // the listing is not in ascending UTF-8 binary order. Taking the first element
+  // would size the neighbour, which either rejects a legal get or admits an
+  // oversized one.
+  const { fetchFn } = recordingFetch({
+    ok: true,
+    status: 200,
+    body: objectPage([
+      { key: "a/photo.jpg.bak", size: 999 },
+      { key: "a/photo.jpg", size: 3 },
+    ]),
+  });
+  const cf = makeCfExec(cred, throwingRun, fetchFn);
+  const found = await cf.r2ObjectFind("b", "a/photo.jpg");
+  assert.equal(found?.key, "a/photo.jpg");
+  assert.equal(found?.size, 3);
+});
+
+test("r2ObjectFind sends the key as the prefix, encoded", async () => {
+  const { fetchFn, calls } = recordingFetch({ ok: true, status: 200, body: objectPage([]) });
+  const cf = makeCfExec(cred, throwingRun, fetchFn);
+  await cf.r2ObjectFind("b", "person a/x.jpg");
+  assert.ok(calls[0].url.endsWith("/objects?prefix=person+a%2Fx.jpg"), calls[0].url);
+});
+
+test("r2ObjectFind stops at the page carrying the match and fetches no further page", async () => {
+  // The page says truncated with a cursor, so r2ObjectList would fetch page 2.
+  // sequenceFetch throws on an unexpected call, so a second fetch fails here.
+  const { fetchFn, calls } = sequenceFetch([
+    {
+      ok: true,
+      status: 200,
+      body: objectPage([{ key: "k", size: 7 }], { cursor: "c1", truncated: true }),
+    },
+  ]);
+  const cf = makeCfExec(cred, throwingRun, fetchFn);
+  const found = await cf.r2ObjectFind("b", "k");
+  assert.equal(found?.size, 7);
+  assert.equal(calls.length, 1);
+});
+
+test("r2ObjectFind finds a match on a later page, never assuming position", async () => {
+  const { fetchFn, calls } = sequenceFetch([
+    { ok: true, status: 200, body: objectPage(["x.jpg"], { cursor: "c1", truncated: true }) },
+    { ok: true, status: 200, body: objectPage([{ key: "k", size: 5 }], { truncated: false }) },
+  ]);
+  const cf = makeCfExec(cred, throwingRun, fetchFn);
+  const found = await cf.r2ObjectFind("b", "k");
+  assert.equal(found?.size, 5);
+  assert.equal(calls.length, 2);
+});
+
+test("r2ObjectFind returns null when the key is absent after exhausting pages", async () => {
+  const { fetchFn, calls } = sequenceFetch([
+    { ok: true, status: 200, body: objectPage(["k.bak"], { cursor: "c1", truncated: true }) },
+    { ok: true, status: 200, body: objectPage(["k.zzz"], { truncated: false }) },
+  ]);
+  const cf = makeCfExec(cred, throwingRun, fetchFn);
+  assert.equal(await cf.r2ObjectFind("b", "k"), null);
+  assert.equal(calls.length, 2);
+});
+
+test("r2ObjectFind throws on a repeated cursor instead of looping forever", async () => {
+  const { fetchFn } = sequenceFetch([
+    { ok: true, status: 200, body: objectPage(["x"], { cursor: "c1", truncated: true }) },
+    { ok: true, status: 200, body: objectPage(["y"], { cursor: "c1", truncated: true }) },
+  ]);
+  const cf = makeCfExec(cred, throwingRun, fetchFn);
+  await assert.rejects(() => cf.r2ObjectFind("b", "k"), /repeated pagination cursor/);
+});
+
+test("r2ObjectFind throws when truncated but no cursor is given", async () => {
+  const { fetchFn } = recordingFetch({
+    ok: true,
+    status: 200,
+    body: objectPage(["x"], { cursor: "", truncated: true }),
+  });
+  const cf = makeCfExec(cred, throwingRun, fetchFn);
+  await assert.rejects(() => cf.r2ObjectFind("b", "k"), /truncated but gave no pagination cursor/);
+});
+
+test("r2ObjectFind retains the body on a non-2xx", async () => {
+  const { fetchFn } = recordingFetch({ ok: false, status: 403, body: '{"errors":[{"code":10000}]}' });
+  const cf = makeCfExec(cred, throwingRun, fetchFn);
+  await assert.rejects(() => cf.r2ObjectFind("b", "k"), /10000/);
+});
+
+// Code review — the early exit changes observable behaviour on an anomalous
+// page, and an unpinned behaviour change is how a regression starts. Pinned as a
+// decision rather than left implicit.
+//
+// A page that reports truncated with no cursor is an anomaly r2ObjectList throws
+// on, because a partial listing would corrupt the audit. r2ObjectFind returns at
+// the match and never reaches that check, so the same response yields the size
+// instead of an error. That is correct: the size is Cloudflare's own record for
+// the exact key, the cap is enforced on it, and the anomaly concerns pages the
+// sizing does not need. The audit's behaviour on the same response is unchanged
+// and is pinned by "r2ObjectList throws when truncated but no cursor is given".
+test("r2ObjectFind returns a match found before an anomalous page's guard is reached", async () => {
+  const { fetchFn } = recordingFetch({
+    ok: true,
+    status: 200,
+    body: objectPage([{ key: "k", size: 4 }], { cursor: "", truncated: true }),
+  });
+  const cf = makeCfExec(cred, throwingRun, fetchFn);
+  const found = await cf.r2ObjectFind("b", "k");
+  assert.equal(found?.size, 4);
+});

package/payload/platform/lib/storage-broker/src/__tests__/object-limits.test.ts

@@ -1,6 +1,7 @@
 import test from "node:test";
 import assert from "node:assert/strict";
 import {
+  R2_OBJECT_ENVELOPE_MAX_BODY_BYTES,
   R2_OBJECT_MAX_BYTES,
   R2_OBJECT_PUT_MAX_BODY_BYTES,
   base64Ceiling,
@@ -53,6 +54,35 @@ test("the envelope allowance is negligible against the cap", () => {
   assert.ok(allowance < R2_OBJECT_MAX_BYTES / 1000);
 });
 
+test("the envelope limit is 64 KiB", () => {
+  assert.equal(R2_OBJECT_ENVELOPE_MAX_BODY_BYTES, 64 * 1024);
+});
+
+// The sizing rationale, pinned rather than left in prose. An object key is at
+// most 1,024 bytes and a bucket name at most 63 characters, so even a key whose
+// every byte takes a six-character \uXXXX escape leaves an order of magnitude of
+// headroom. A future edit that shrinks this toward a real envelope fails here.
+test("the envelope limit clears a worst-case escaped envelope with headroom", () => {
+  const worstCase = 63 + 1024 * 6 + 64; // bucket + fully escaped key + punctuation
+  assert.ok(
+    R2_OBJECT_ENVELOPE_MAX_BODY_BYTES > worstCase * 5,
+    `${R2_OBJECT_ENVELOPE_MAX_BODY_BYTES} leaves too little headroom over ${worstCase}`,
+  );
+});
+
+// The counterpart to "the cap is not email's attachment cap" above, and the
+// opposite ruling for the opposite reason. That pair must stay apart because the
+// two numbers track different constraints and would drift for different reasons.
+// These two are one fact — how large can an envelope legitimately get — asked once
+// by put's allowance and once by the metadata routes' whole body, so they must
+// move together. This pins the composition; the test above pins the value.
+test("put's body ceiling is composed of the same envelope constant", () => {
+  assert.equal(
+    R2_OBJECT_PUT_MAX_BODY_BYTES,
+    base64Ceiling(R2_OBJECT_MAX_BYTES) + R2_OBJECT_ENVELOPE_MAX_BODY_BYTES,
+  );
+});
+
 test("the over-cap message names the object and the limit", () => {
   const msg = tooLargeMessage("photo.jpg", 150 * 1024 * 1024);
   assert.match(msg, /photo\.jpg/);

package/payload/platform/lib/storage-broker/src/__tests__/resource-limits.test.ts

@@ -0,0 +1,49 @@
+import test from "node:test";
+import assert from "node:assert/strict";
+import {
+  D1_MAX_SQL_STATEMENT_BYTES,
+  D1_QUERY_MAX_BODY_BYTES,
+  JSON_STRING_WORST_CASE_EXPANSION,
+  STORAGE_RESOURCE_NAME_MAX_BODY_BYTES,
+} from "../resource-limits.js";
+
+test("the recorded D1 statement limit is Cloudflare's documented 100,000 bytes", () => {
+  assert.equal(D1_MAX_SQL_STATEMENT_BYTES, 100_000);
+});
+
+test("a resource-name body is bounded at 64 KiB", () => {
+  assert.equal(STORAGE_RESOURCE_NAME_MAX_BODY_BYTES, 64 * 1024);
+});
+
+test("a D1 query body is bounded at 1 MiB", () => {
+  assert.equal(D1_QUERY_MAX_BODY_BYTES, 1024 * 1024);
+});
+
+// The guard. D1_QUERY_MAX_BODY_BYTES is a flat number rather than a computed
+// expression, so nothing but this test holds it to the arithmetic that makes it
+// safe. If D1 ever raises its statement limit above 163,840 bytes, the worst-case
+// wire form of a legal statement exceeds 1 MiB and the route would begin rejecting
+// correct queries with nothing to signal why. This fails first instead.
+test("the D1 query body limit clears the worst-case wire form of a legal statement", () => {
+  const worstCaseLegalBody =
+    JSON_STRING_WORST_CASE_EXPANSION * D1_MAX_SQL_STATEMENT_BYTES +
+    STORAGE_RESOURCE_NAME_MAX_BODY_BYTES;
+  assert.ok(
+    D1_QUERY_MAX_BODY_BYTES > worstCaseLegalBody,
+    `D1_QUERY_MAX_BODY_BYTES (${D1_QUERY_MAX_BODY_BYTES}) must exceed the largest legal wire body (${worstCaseLegalBody}), or legal queries are rejected`,
+  );
+});
+
+// The escape ceiling is the reason the bound is not simply D1's 100,000. Pin the
+// factor against the runtime rather than restating the literal: a single ASCII
+// control byte serializes to the six characters \uXXXX, which is the worst ratio a
+// JSON string can reach over bytes.
+test("the JSON worst-case expansion is the six-character \\uXXXX escape", () => {
+  assert.equal(JSON_STRING_WORST_CASE_EXPANSION, 6);
+  // Written as an escape rather than a literal control byte: a raw 0x01 in source
+  // is invisible in most editors and diffs.
+  const oneControlByte = "\u0001";
+  assert.equal(Buffer.byteLength(oneControlByte), 1);
+  // minus the two quotes JSON.stringify wraps the string in
+  assert.equal(JSON.stringify(oneControlByte).length - 2, JSON_STRING_WORST_CASE_EXPANSION);
+});