fix(service-storage,spec): the upload size refusal answers 413 PAYLOAD_TOO_LARGE

[objectstack-fleet]

Fixes #22314
Clause-②: yes (widening: a new owner provenance row in the published error-code ledger)

The upload size refusal that PR #22311 added (card #22283) now answers 413 with the registered code PAYLOAD_TOO_LARGE at all four service-storage upload doors, in place of the status-derived VALIDATION_ERROR. The error-code ledger lists PAYLOAD_TOO_LARGE under @objectstack/service-storage, beside @objectstack/rest. This is ruling B from the domain:services seat in PR #22311's ACCEPT, carried on the card.

It is not a new code. The status (413), the message, the four doors, and what is stored or refused are all unchanged.

What changed

• packages/spec/src/api/error-code-ledger.zod.ts: one provenance row, 'PAYLOAD_TOO_LARGE', under the @objectstack/service-storage owner key.
  • It follows the shape the ledger's other multi-emitter rows use (PACKAGE_DELETE_PARTIAL and WRITABLE_PACKAGE_REQUIRED under @objectstack/runtime): a comment naming the wire path and the other emitter, then "Provenance, not identity".
  • ErrorCode, RegisteredErrorCode and REGISTERED_ERROR_CODES are unchanged, because the union dedupes.
  • Every sentence of the docblock at standardSynonymOf stays true, including "a phrase for a status the catalog does not name (PAYLOAD_TOO_LARGE, 413) is NOT a synonym".
• packages/services/service-storage/src/storage-routes.ts: the one constant changes from UPLOAD_TOO_LARGE_CODE: StandardErrorCode = 'VALIDATION_ERROR' to UPLOAD_TOO_LARGE_CODE: RegisteredErrorCode = 'PAYLOAD_TOO_LARGE'. Its docblock is rewritten to state the new choice and the reason for it.
• Tests: they now expect PAYLOAD_TOO_LARGE and still assert both code and status at every door.
  • storage-limits.test.ts: the shared expectTooLarge helper asserts 413 + PAYLOAD_TOO_LARGE, and every door case calls it:
    • presigned;
    • chunked start;
    • local raw PUT, by bytes read and by content-length;
    • chunk PUT, by bytes read (three cases) and by content-length.
  • error-envelope.conformance.test.ts: the case for the over-limit upload.
  • packages/qa/dogfood/test/storage-upload-limits.dogfood.test.ts: three assertions over a real boot.
• Text that describes this refusal:
  • the service-storage README limits row;
  • content/docs/api/error-catalog.mdx: the VALIDATION_ERROR 413 callout moves to a new PAYLOAD_TOO_LARGE entry, the quick-reference 413 row changes, and the wire-code count goes from 51 to 52;
  • content/docs/protocol/kernel/error-handling.mdx: the 413 row and the VALIDATION_ERROR entry.
• Changesets:
  • .changeset/22314-storage-payload-too-large-provenance.md is new: @objectstack/spec minor, carrying the Clause-② line above.
  • The pending .changeset/22283-storage-limits-honoured.md gets a one-sentence correction (see the next section).

Pending release note corrected: confirmation requested (Check Changeset is red by design)

.changeset/22283-storage-limits-honoured.md is #22283's pending, unreleased note (@objectstack/service-storage minor). This PR changes one sentence in it:

• Before: "is refused with 413 and the standard code VALIDATION_ERROR, in the usual error envelope,"
• After: "is refused with 413 and the registered code PAYLOAD_TOO_LARGE, in the usual error envelope,"

Nothing else in that note changes. With this edit, the release that first ships the refusal names one code.

check-empty-changeset refuses a changed foreign changeset by design. This PR is the DELIBERATE CORRECTION class: the gate's own remedy is to say so on the PR and have it confirmed. Do not restore the old sentence, which would put the false code back. Do not apply skip-changeset. Please confirm the correction here.

The service-storage code change rides on that note. This PR's own changeset declares @objectstack/spec only. No check-changeset* gate asked for @objectstack/service-storage in an added changeset:

• check-changeset-no-major exits 0.
• check-adr-0087-registration exits 0.
• Require a changeset counts the added 22314 changeset.

Release coupling, checked before building

• npm @objectstack/service-storage:
  • latest is 17.7.0, published 2026-10-06T12:09Z.
  • Its tarball has 0 dist files matching limitsSnapshot or UPLOAD_TOO_LARGE_CODE. The control, upload/presigned, matches in 4 dist files.
• PR fix(service-storage)!: enforce the storage settings Limits group (max_upload_mb, presigned_ttl, session_ttl) at the upload doors #22311 merged on 2026-10-08T16:35Z, and its changeset is still pending on main.
• The Version Packages PR chore: version packages (next) #21988 is open.

So no published version ships the VALIDATION_ERROR refusal.

Measurements (the dispatch's hypotheses)

• H1 holds.
  • PAYLOAD_TOO_LARGE was listed under @objectstack/rest only, which answers it for both import routes' row ceilings (import-prepare.ts, 5,000 and 50,000 rows).
  • HTTP_REASON_PHRASE_STATUS maps it to 413.
  • The new row is one entry in the existing multi-emitter shape.
• H2 holds, with the typed path that already exists.
  • sendError (@objectstack/types) takes ErrorCode = StandardErrorCode | RegisteredErrorCode.
  • RegisteredErrorCode is the type service-analytics already uses for ledger-code constants (read-scope-refusal.ts, dataset-refusal.ts).
  • No shared type was widened, and no cast was added.
  • Reverse check: a misspelled code fails to compile (see Tests).
• H3: every test that pins this refusal now expects PAYLOAD_TOO_LARGE. Sweep hits outside the tests, with line numbers at the base 41d0d4038:
  • Edited (each describes this refusal): the service-storage README :113, error-catalog.mdx :67 and :920, error-handling.mdx :217, :405 and :421, the dogfood test :68, :91 and :102, and the pending changeset :15.
  • Not edited (none describes this refusal):
    • storage-adapter-list.conformance.test.ts :436 and :447 (VALIDATION_ERROR for the list limit/cursor);
    • import-mappings.mdx :224 and import-job-integration.test.ts :202 (rest's import 413, already PAYLOAD_TOO_LARGE);
    • references/api/contract.mdx and references/api/error-code-ledger.mdx (generated union listings, which this change does not move);
    • error-code-ledger.test.ts :87 (the synonym pin, still true).
  • The sibling objectui checkout has no branch on this refusal's code.
• H4 holds. check:error-code-provenance is the gate that makes the row required:
  • Before, at the base 41d0d4038: exit 0, with 334 stamp sites (315 listed, 19 waived).
  • Ablation, at commit b5f9d332f: the storage constant switched and the ledger row removed. The removal went through scripts/ablation-replace.mjs, which showed the anchor count go from 1 to 0 and the blob change, then restored the file to equal HEAD. Result: exit 1, @objectstack/service-storage stamps 'PAYLOAD_TOO_LARGE' (constdef) at packages/services/service-storage/src/storage-routes.ts:93 — not listed under its own owner key.
  • After, at 5b5b812ce: exit 0, with 335 stamp sites (316 listed, 19 waived).
• Generated artifacts: none moves. After pnpm --filter @objectstack/spec build, check:generated reports all 15 generated artifacts up to date, and git status is clean.
• Doc ⇄ runtime status reconciliation: check:error-status-conformance now reconciles PAYLOAD_TOO_LARGE. Its scope line reads "4 ledger code(s) a doc page publishes a status for (INVALID_REQUEST, PAYLOAD_TOO_LARGE, UNIQUE_VIOLATION, VALIDATION_FAILED)", and the derived producer is 413 storage-routes.ts:315. VALIDATION_ERROR keeps no 413 producer and no 413 doc claim. Exit 0.

Tests

At 5b5b812ce, each run under the shared verify lock:

• pnpm --filter @objectstack/service-storage exec vitest run --maxWorkers=2: 45 files and 749 tests passed.
• The targeted spec run (src/api/ plus every spec test that reads the ledger) with vitest run --project local --maxWorkers=2: 59 files and 1724 tests passed.
• pnpm --filter @objectstack/service-storage run typecheck: exit 0.
• pnpm --filter @objectstack/spec run typecheck: exit 0.

At b5f9d332f. The only change from there to 5b5b812ce is comment and changeset wording in three files (5 lines changed):

• pnpm --filter @objectstack/spec test: 626 files passed, with 18740 tests passed and 1 todo.
• The dogfood file over a real boot, storage-upload-limits.dogfood.test.ts: 1 file and 2 tests passed. The service-storage dist it loaded had 1 PAYLOAD_TOO_LARGE match.
• Reverse type check: the constant was set to 'PAYLOAD_TOO_LARGE_ABLATED' through ablation-replace.mjs, and tsc --noEmit failed with TS2820 ... Did you mean '"PAYLOAD_TOO_LARGE"'?. The file was then restored to equal HEAD, with an empty git diff HEAD.

Gates

At 5b5b812ce:

• dispatch-gates --commands derived 115 commands. All 115 ran:
  • 114 exited 0.
  • node scripts/check-empty-changeset.mjs --base origin/main exited 1, by design (the DELIBERATE CORRECTION above).
• The --ran verdict: ✓ dispatch-gates --ran: 115 derived famil(ies) accounted for — 115 run, 0 NOT-MEASURED.
• Also run: check:generated, plus the roster gates check:authz-resolver and check:filter-alias-parity. All exited 0.

ESLint was narrowed to the touched files, with this proof:

1. What eslint checks: eslint.config.mjs lints **/*.{ts,tsx,mts,cts,js,jsx,mjs,cjs}. The touched TypeScript files are the five listed in the next point. The .md and .mdx files match no files glob.
2. What ran: pnpm exec eslint --no-inline-config --format json over those 5 files at 5b5b812ce reported 5 files, 0 errors and 0 warnings.
3. Why other files are unaffected: type-aware linting is not enabled (no parserOptions.project and no typed rules; the config says so at :327). The config's only file reads are two baselines this diff does not touch. So this diff cannot change the lint result of any untouched file.

Acceptance notes

• Landing beyond the claim's file surface: two hand-written docs pages, the service-storage README, and the dogfood test. The H3 sweep named each one as describing this refusal, and each is edited only where it does.
  • The catalog's new PAYLOAD_TOO_LARGE entry also names @objectstack/rest's import row ceilings. The entry catalogs the code, not one door.
  • Documenting a status for the code makes it a reconciled wire code. That is what requires the heading and the count of 52, by error-catalog-docs.test.ts.
• content/docs/references/** is unchanged and regenerates byte-identically.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 2 package(s): @objectstack/service-storage, @objectstack/spec, touching 4 documentable anchor(s). ⚠️ 1 changed file(s) yielded no anchor (packages/services/service-storage/README.md), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

12 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/client-sdk.mdx (via ERROR_CODE_LEDGER (symbol, a top-level const object), VALIDATION_ERROR (literal, a string literal in UPLOAD_TOO_LARGE_CODE))
• content/docs/api/error-catalog.mdx (via ERROR_CODE_LEDGER (symbol, a top-level const object), PAYLOAD_TOO_LARGE (literal, a string literal in ERROR_CODE_LEDGER; a string literal in UPLOAD_TOO_LARGE_CODE), VALIDATION_ERROR (literal, a string literal in UPLOAD_TOO_LARGE_CODE))
• content/docs/api/error-handling-client.mdx (via VALIDATION_ERROR (literal, a string literal in UPLOAD_TOO_LARGE_CODE))
• content/docs/api/error-handling-server.mdx (via ERROR_CODE_LEDGER (symbol, a top-level const object), VALIDATION_ERROR (literal, a string literal in UPLOAD_TOO_LARGE_CODE))
• content/docs/automation/jobs.mdx (via VALIDATION_ERROR (literal, a string literal in UPLOAD_TOO_LARGE_CODE))
• content/docs/automation/webhooks.mdx (via VALIDATION_ERROR (literal, a string literal in UPLOAD_TOO_LARGE_CODE))
• content/docs/data-modeling/drivers.mdx (via VALIDATION_ERROR (literal, a string literal in UPLOAD_TOO_LARGE_CODE))
• content/docs/data-modeling/import-mappings.mdx (via PAYLOAD_TOO_LARGE (literal, a string literal in ERROR_CODE_LEDGER; a string literal in UPLOAD_TOO_LARGE_CODE))
• content/docs/kernel/contracts/data-engine.mdx (via ERROR_CODE_LEDGER (symbol, a top-level const object))
• content/docs/protocol/kernel/error-handling.mdx (via PAYLOAD_TOO_LARGE (literal, a string literal in ERROR_CODE_LEDGER; a string literal in UPLOAD_TOO_LARGE_CODE), VALIDATION_ERROR (literal, a string literal in UPLOAD_TOO_LARGE_CODE))
• content/docs/protocol/objectql/types.mdx (via VALIDATION_ERROR (literal, a string literal in UPLOAD_TOO_LARGE_CODE))
• content/docs/ui/forms.mdx (via VALIDATION_ERROR (literal, a string literal in UPLOAD_TOO_LARGE_CODE))

⛔ 6 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/v17/17-0.mdx (via ERROR_CODE_LEDGER (symbol, a top-level const object))
• content/docs/releases/v17/17-1.mdx (via ERROR_CODE_LEDGER (symbol, a top-level const object), VALIDATION_ERROR (literal, a string literal in UPLOAD_TOO_LARGE_CODE))
• content/docs/releases/v17/17-4.mdx (via ERROR_CODE_LEDGER (symbol, a top-level const object))
• content/docs/releases/v17/17-5.mdx (via VALIDATION_ERROR (literal, a string literal in UPLOAD_TOO_LARGE_CODE))
• content/docs/releases/v17/17-6.mdx (via VALIDATION_ERROR (literal, a string literal in UPLOAD_TOO_LARGE_CODE))
• content/docs/releases/v17/17-7.mdx (via VALIDATION_ERROR (literal, a string literal in UPLOAD_TOO_LARGE_CODE))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• 1 changed file(s) yielded no anchor (packages/services/service-storage/README.md) — pages documenting those are invisible to this run
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 141 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 1cb0edb82dcc7fb67a5eec1157c23900e3915924 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 6800c545620cdd3e5da2df922c8b74c46cdeea83 — the merge of head 5b5b812ce958740650aced54d57219029adf90c3 into base 1cb0edb82dcc7fb67a5eec1157c23900e3915924, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 6800c545620cdd3e5da2df922c8b74c46cdeea83 && git checkout 6800c545620cdd3e5da2df922c8b74c46cdeea83
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 1cb0edb82dcc7fb67a5eec1157c23900e3915924 5b5b812ce958740650aced54d57219029adf90c3 && git checkout -B drift-repro 1cb0edb82dcc7fb67a5eec1157c23900e3915924 && git merge --no-ff 5b5b812ce958740650aced54d57219029adf90c3

node scripts/docs-audit/affected-docs.mjs --json 1cb0edb82dcc7fb67a5eec1157c23900e3915924

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 1cb0edb82dcc7fb67a5eec1157c23900e3915924 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[objectstack-fleet]

Check Changeset is red by design on this PR: the DELIBERATE CORRECTION of a pending release note · domain:spec seat 2 (#18549) · session session_01DhTqaEHqPVSVnAkjG3jywn · 2026-10-08T22:10Z.

• The gate: scripts/check-empty-changeset.mjs. It refuses a change to a changeset that exists on the merge base, and for this class its own text says "this gate stays red either way, and staying red is what puts the decision in front of a person".
• The note and what changed under it: .changeset/22283-storage-limits-honoured.md (PR fix(service-storage)!: enforce the storage settings Limits group (max_upload_mb, presigned_ttl, session_ttl) at the upload doors #22311's, unreleased; the Version Packages PR chore: version packages (next) #21988 is still open). Its sentence named VALIDATION_ERROR for the upload size refusal. This PR changes that refusal's code to PAYLOAD_TOO_LARGE, so restoring the old sentence would publish a false release note.
• The confirmation: the correction is the domain:services seat's ruling B (PR fix(service-storage)!: enforce the storage settings Limits group (max_upload_mb, presigned_ttl, session_ttl) at the upload doors #22311's ACCEPT; carried in spec(error-code-ledger), service-storage: the upload size refusal (PR #22311) answers 413 VALIDATION_ERROR; register the existing PAYLOAD_TOO_LARGE under @objectstack/service-storage and stamp it, before the release that ships #22311 #22314's body: "the one constant in storage-routes.ts, plus the changeset sentence"), made by the seat that owns that note. The maintainer may overrule it on this PR before it lands.
• Why it may enter the queue red on this check alone: Check Changeset is not in main's required set, and pr-automation.yml has no merge_group trigger. Every other check must be green.

---

Generated by Claude Code

[objectstack-fleet]

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 5b5b812ce958740650aced54d57219029adf90c3
Local-runs: none

Inputs: card #22314 (body and all four comments), PR #22359 (body, the 10-file list, the net diff against the merge base 41d0d4038: 84 insertions, 40 deletions) and the check-runs on this head. Nothing was built, run or re-run; every line reference below is a git show / git grep reading of the fetched head or a GitHub read.

① Derived judgments

1. The ledger row: right. ERROR_CODE_LEDGER['@objectstack/service-storage'] gains 'PAYLOAD_TOO_LARGE' (error-code-ledger.zod.ts:523), in the key's alphabetical order between INVALID_RESUME_TOKEN and UPLOAD_SESSION_EXPIRED. The code already exists under @objectstack/rest (:267), HTTP_REASON_PHRASE_STATUS maps it to 413 (:1544), and the comment follows the multi-emitter shape the @objectstack/runtime rows use (:412, :458, :466, all above the new row, so its "see above" resolves). It is a second emitter of a registered code, not a new code, so the standard-synonym admission rule is not engaged and the standardSynonymOf docblock sentence naming PAYLOAD_TOO_LARGE stays true.
2. The accept-set is unchanged, and the declaration says so: right. RegisteredErrorCode is the union over every key's members and REGISTERED_ERROR_CODES is Set-deduped (:1479 to :1484), so ErrorCode, its z.enum and ApiErrorSchema.code accept exactly what they accepted. What widens is the published value of the exported const, which is what the changeset body states. No generated artifact moves: the api-surface baseline records "ERROR_CODE_LEDGER (const)" by name only (packages/spec/api-surface/api.json:324) and the generated references page lists the union once (content/docs/references/api/error-code-ledger.mdx:438), consistent with the file list touching neither.
3. The wire change: right and complete at every door. UPLOAD_TOO_LARGE_CODE: RegisteredErrorCode = 'PAYLOAD_TOO_LARGE' (storage-routes.ts:93) is the only place the code is written. The four doors (presigned :654, chunked start :783, chunk PUT :926 and :940 by content-length then by bytes, raw PUT :1242 and :1252 the same two ways) all pass through requireWithinUploadLimit, whose single sendError at :315 takes code: ErrorCode (packages/types/src/response-envelope.ts:207), so the constant's type narrows rather than widens and no cast is needed. Status 413 and the message are untouched. The provenance gate's constdef pattern admits the annotated spelling (check-error-code-provenance.ts:115), so the stamp is read and the new row is what lists it under its own owner.
4. No published client contract breaks: right. The refusal itself is unreleased: .changeset/22283-storage-limits-honoured.md is still on main at blob 5fa63f06b (read at 2026-10-08T22:19Z), the same blob this diff modifies. The code a client could branch on changes before any release names it, which is the card's ruling B and its release coupling.
5. The tests: right. Every pin of the refusal asserts status and code at each door: expectTooLarge (storage-limits.test.ts:117 to :121) in the presigned, chunked-start, raw-PUT and chunk cases; the conformance table row (error-envelope.conformance.test.ts:255 and :256); the dogfood file's three assertions. A head-tree sweep for VALIDATION_ERROR within three lines of any 413 across content/, service-storage and packages/qa returns only the three "not VALIDATION_ERROR" sentences this diff wrote; no stale description of the refusal remains.
6. Prose surfaces (outside this review's surface; read for the ACCEPT). The catalog gains a PAYLOAD_TOO_LARGE entry and its count moves 51 to 52, which error-catalog-docs.test.ts demands once a page publishes a status for a ledger code (reconciledVocabulary, check-error-status-conformance.mjs:893 to :897); the import ceilings the entry names are real (rest-server.ts:9412, 5000 rows; IMPORT_JOB_MAX_ROWS = 50_000, export.zod.ts:414) and the #size-limits anchor exists (import-mappings.mdx:269). One nit, not a defect: the Quick Reference 413 row keeps validation in its Category column for a ledger code that belongs to no standard category; the gate reads the row's code and status, not that column.

② Semver level

• .changeset/22314-storage-payload-too-large-provenance.md: @objectstack/spec minor, Clause-②: yes (widening: a new owner provenance row in the published error-code ledger). Matches the diff (judgment 2: an exported const's value widens, the accept-set does not change) and the rule (yes takes at least minor; the (widening) arm is non-breaking, so no ADR-0087 marker is owed, and the Check Changeset job's ADR-0087 and no-major steps, 13 and 15, passed on this head). The PR body's Clause-②: line is the claim's line verbatim. Right.
• @objectstack/service-storage: covered by the pending 22283 note (minor, declared breaking, carrying its own adr-0087 marker), whose one sentence this PR corrects. The published 17.7.0 predates the refusal (card and claim), so a second note on the same unreleased behaviour would be wrong, and skip-changeset would be a false declaration for a PR that edits a pending note (ruling D on [finding] the skip-changeset label suppresses the DELIBERATE-CORRECTION refusal whose own text says 「no label and no diff shape makes that safe」 — declared contract against enforced behaviour #18375). Require a changeset (step 11) passed. Right.

③ Boundary flags

• open_questions: none. out_of_scope_findings: none.
• DELIBERATE CORRECTION: confirmed. Check Changeset is red on this head at one step only (12, the foreign-changeset rule of check-empty-changeset.mjs). The note changed is .changeset/22283-storage-limits-honoured.md, one line (:15): "refused with 413 and the standard code VALIDATION_ERROR" becomes "refused with 413 and the registered code PAYLOAD_TOO_LARGE". Judged correct: that sentence names the code this diff changes at every door, the status and every other sentence of the note are untouched, and restoring it would put a false sentence into the release that first ships the refusal. Per the landing reference, an at-tier PASS record on this head that names the note and judges the rewritten sentence is the confirmation, and the three conditions for queueing with this red hold: the workflow self-describes the red as by design and not a required context (pr-automation.yml:728 to :731); the workflow triggers on pull_request only, never on merge_group; the PR body and this record name the gate and the reason.
• Dev deviations (five), each answered. (1) Edits beyond the claimed file surface (two docs pages, the README, the dogfood test): accepted, each is a description of this refusal and the catalog entry and count are forced by the docs test. (2) A spec-only changeset: accepted, see ②. (3) Zero labels written: accepted, the path labels are the labeler's and skip-changeset is refused for this class. (4) The full spec suite and the dogfood run quoted at b5f9d332f: accepted, the diff from that commit to this head is 3 files, 5 lines, all comment and changeset prose. (5) Model-free commit trailers: accepted, both commits carry the Claude-Session and Co-authored-by pair AGENTS.md prescribes.
• Release coupling (standing, for the landing seat): this lands before the release that consumes the 22283 note, or not at all; at 2026-10-08T22:19Z that note is still on main. If the Version Packages PR consumes it first, the card's own rule applies (A stands, the card closes not_planned) and this PR must not land.
• Check-runs at 2026-10-08T22:19Z: 33 on the head. 28 completed: 25 success, 1 failure (Check Changeset, by design, above), 2 skipped as expected (Console Pin Gate, Packed-tarball smoke (opt-in)). 5 still in progress: Test Core 1/6, 2/6, 4/6 and 6/6, and Type Check · workspace. Lint & Repo Gates (the home of check:error-code-provenance, check:error-status-conformance and check:generated), Build Core, the three Dogfood Regression Gate legs, Dogfood Verify CLI, Temporal Conformance and the other two Type Check legs are green. This verdict is on the contract; the landing pre-check (every check green or an expected skip, plus the by-design red above) is read off the head once the five finish.

Implemented-by: claude/issue-22314-storage-payload-too-large
Reviewed-by: session_01DhTqaEHqPVSVnAkjG3jywn

VERDICT: PASS