Current authoritative state
This forgiving-base64 whitespace resource-boundary defect is repaired on the existing canonical single-writer Draft PR #160 / branch fix/blob-size-preflight-20260811. Protected shipped truth remains exact main@3b38ead2d00f44eb578d0689087b9293b3dabe1e; current exact Draft head is 42b3a5004ec1b93181cd1ae52227b0fac2506227. The repair remains active-PR truth only until #160 integrates under live governance.
Current dataUriToBytes() computes the decoded size of syntactically valid WHATWG-forgiving base64 directly from the raw payload, including ASCII whitespace, before base64ToBytes() performs whitespace normalization/decoder allocation. Oversized accepted input therefore raises the existing Base64SizeError before the environment decoder is reached. Invalid shape, impossible padding, or invalid length still falls through to the existing parser so malformed-input Base64ParseError precedence is preserved. The implementation does not first allocate a full whitespace-stripped copy solely to perform the size preflight.
The same canonical converter lane hardens adjacent runtime/resource boundaries through captured/intrinsic typed-array and Blob capabilities, captured ArrayBuffer.isView, captured TextDecoder classification authority, deterministic Node/browser base64 behavior, and a 1,024-code-unit declared data-URI MIME ceiling enforced before payload decoding. These later repairs preserve the #364 forgiving-base64 size-preflight and malformed-input precedence contracts.
This remains Inkspan-owned local converter reliability/resource scope and adds no network, persistence, credentials, tenancy, model/provider, deployment, retention, migration, authorization, or durable-audit authority.
Test-first lineage
- RED
56320c13001073ad83486cc91baa179735d634f5: CI 31974351525, job 95231498184, checked out that exact head and failed the public whitespace-heavy dataUriToBytes() regression because decoding was reached before Base64SizeError.
- Characterization
b962a38cce9a2a34c9f40e09ab705b2ac12fc476 locked malformed-input Base64ParseError precedence with maxBytes: 0 before changing production behavior.
- Repair
da48f8c269a62f42d8e8e29d3e78141a14e9022a added raw-payload forgiving-base64 size preflight before normalization/decoding.
- Later converter hardening retained that behavior through Blob byte-reader authority, typed-array/view classification, MIME-classifier capability capture, package declaration repair, and declared data-URI MIME bounds. Predecessor workflow/review evidence does not transfer after head movement.
Exact-current-head evidence
For unchanged exact head 42b3a5004ec1b93181cd1ae52227b0fac2506227 against protected main@3b38ead2d00f44eb578d0689087b9293b3dabe1e at the latest fresh refetch:
- CI
32558675130: completed / success;
- build-and-test
96996743975: exact checkout, 163 test files / 912 tests, 100% statements / branches / functions / lines, with packed-package consumers, library build and demo build successful;
- Cross-engine Clipboard / Playwright 1.62.0: completed / success;
- Office Python 3.11, 3.12, 3.13 and 3.14: completed / success;
- Security Scan
32558675113: completed / success;
- SAST Semgrep
32558675118: completed / success;
- formal submitted reviews: 0;
- unresolved inline review threads: 0;
- GitHub reports the Draft mechanically mergeable.
Repository exact-head technical success is not a substitute for separately applicable central workflows, qualifying independent approval, or then-live governance. Pending, queued, skipped, cancelled, absent, neutral, failed, stale, predecessor, status-only, model-only, or vacuous evidence remains non-passing.
Integration boundary
Keep this issue open until #160 integrates under then-live governance. Keep #160 Draft/unmerged while #118 owns the frozen protected v0.6.0 publication/provenance boundary. Any #160 head/base/ruleset movement invalidates corresponding exact-head evidence and requires fresh revalidation. Do not create a competing converter writer, transfer predecessor evidence, self-approve, weaken gates, move protected main, or fabricate release identity.
Current authoritative state
This forgiving-base64 whitespace resource-boundary defect is repaired on the existing canonical single-writer Draft PR #160 / branch
fix/blob-size-preflight-20260811. Protected shipped truth remains exactmain@3b38ead2d00f44eb578d0689087b9293b3dabe1e; current exact Draft head is42b3a5004ec1b93181cd1ae52227b0fac2506227. The repair remains active-PR truth only until #160 integrates under live governance.Current
dataUriToBytes()computes the decoded size of syntactically valid WHATWG-forgiving base64 directly from the raw payload, including ASCII whitespace, beforebase64ToBytes()performs whitespace normalization/decoder allocation. Oversized accepted input therefore raises the existingBase64SizeErrorbefore the environment decoder is reached. Invalid shape, impossible padding, or invalid length still falls through to the existing parser so malformed-inputBase64ParseErrorprecedence is preserved. The implementation does not first allocate a full whitespace-stripped copy solely to perform the size preflight.The same canonical converter lane hardens adjacent runtime/resource boundaries through captured/intrinsic typed-array and Blob capabilities, captured
ArrayBuffer.isView, capturedTextDecoderclassification authority, deterministic Node/browser base64 behavior, and a 1,024-code-unit declared data-URI MIME ceiling enforced before payload decoding. These later repairs preserve the #364 forgiving-base64 size-preflight and malformed-input precedence contracts.This remains Inkspan-owned local converter reliability/resource scope and adds no network, persistence, credentials, tenancy, model/provider, deployment, retention, migration, authorization, or durable-audit authority.
Test-first lineage
56320c13001073ad83486cc91baa179735d634f5: CI31974351525, job95231498184, checked out that exact head and failed the public whitespace-heavydataUriToBytes()regression because decoding was reached beforeBase64SizeError.b962a38cce9a2a34c9f40e09ab705b2ac12fc476locked malformed-inputBase64ParseErrorprecedence withmaxBytes: 0before changing production behavior.da48f8c269a62f42d8e8e29d3e78141a14e9022aadded raw-payload forgiving-base64 size preflight before normalization/decoding.Exact-current-head evidence
For unchanged exact head
42b3a5004ec1b93181cd1ae52227b0fac2506227against protectedmain@3b38ead2d00f44eb578d0689087b9293b3dabe1eat the latest fresh refetch:32558675130: completed / success;96996743975: exact checkout, 163 test files / 912 tests, 100% statements / branches / functions / lines, with packed-package consumers, library build and demo build successful;32558675113: completed / success;32558675118: completed / success;Repository exact-head technical success is not a substitute for separately applicable central workflows, qualifying independent approval, or then-live governance. Pending, queued, skipped, cancelled, absent, neutral, failed, stale, predecessor, status-only, model-only, or vacuous evidence remains non-passing.
Integration boundary
Keep this issue open until #160 integrates under then-live governance. Keep #160 Draft/unmerged while #118 owns the frozen protected
v0.6.0publication/provenance boundary. Any #160 head/base/ruleset movement invalidates corresponding exact-head evidence and requires fresh revalidation. Do not create a competing converter writer, transfer predecessor evidence, self-approve, weaken gates, move protected main, or fabricate release identity.