[xgreenx]

Stacked on #2 (feat/ceremony-constructions). The commit GitHub never attached to #8 — that PR merged carrying only its first commit, so this is the other half, re-cut on the current base.

The measurement

A chunked body carries \r\n<size>\r\n between chunks, and that framing holds no quote, comma or brace — so every scan in ranges.rs runs straight through it. A member split across a boundary is found in the decoded body and in the raw one, and the raw range silently spans the framing:

RAW:  ...19\r\n{"access_token":"ghu_AAAA\r\n1c\r\nBBBB","token_type":"bearer"}...
compute_field_snippet_range -> "access_token":"ghu_AAAA\r\n1c\r\nBBBB"

compute_id_snippet_range_after claimed the opposite in a comment — "a snippet split across a chunk boundary won't be found contiguously here and fails closed — never mis-resolves" — which holds only when the split lands inside the needle. A split inside the value is the case that occurs, and nothing caught it.

Why it matters, and why it is live

What that range selects is not the member:

• revealed, it puts framing inside the handle a Platform Verifier reads;
• committed, it puts framing inside the bearer a Proving Circuit opens — against the clean value, because ProverResult::response_body is decoded by hyper while the commitment is over raw transcript bytes.

The on-chain framing check passes anyway: requireFramedCommitment reads the delimiters either side of the commitment, not its contents. So it fails at REQ-PLAT-52, three components from the cause.

This is not hypothetical. Over HTTP/1.1 — which is what hyper::client::conn::http1 speaks, and the request sends Connection: close — both token endpoints chunk:

endpoint	HTTP/1.1 framing
github.com/login/oauth/access_token	Transfer-Encoding: chunked
api.x.com/2/oauth2/token	Transfer-Encoding: chunked
api.github.com/user	Content-Length
api.x.com/2/users/me	Content-Length

Both answer HTTP/2 to a modern client, so this is invisible unless you force 1.1. A small JSON body usually arrives as a single chunk, which is the bad shape: passes tests, passes staging, fails intermittently when a response is flushed mid-body.

The fix

Re-framing cannot repair a spanning range — a commitment covers one contiguous run and this member is two — so all three finders compare the raw bytes against the decoded ones and refuse when they differ. The session fails where the reason is a decodable body rather than an unopenable commitment.

token_response now goes through that shared reader instead of scanning the raw transcript with its own copy of the template. This is the session the deployment itself runs (platform-ceremonies §6: a deployment-owned token exchange, a browser-owned /user), so it is the one that most needed the check and had none. The reuse also scopes the search to the response body — the old scan started at byte zero, so a response header carrying the delimiter answered before the body's own member. An empty bearer is refused too: it would leave the two delimiters adjacent, commit nothing, and give requireFramedCommitment no bearer to find.

Verification

• cargo +nightly fmt --all -- --check
• cargo clippy --workspace --all-targets -- -D warnings
• cargo test --workspace — 102 passed (6 new)

Tests cover the straddling case for each of the three finders and for token_response, plus a chunked body whose member sits in one piece and still resolves: the rule is contiguity, not the absence of chunking.

Follow-up, not in this PR

The browser runs /user with the same construction in TypeScript. Those endpoints send Content-Length today, which is why it has not bitten there — a server-side choice that can change without notice. The TS mirror deserves the same check.