fix(fetch): a page cut at the cap says it was cut

coilyco-ops commented

2026-08-13 12:50:11 +00:00

Member

io.LimitReader stopped at the cap and returned what it had, so an oversize page
came back looking whole. The model answered from a document whose ending it
never saw, with ordinary confidence, which is the instrument-answers-instead-of-
failing shape rather than a rough edge.

The read now takes one byte past the cap, which is what makes a page that fits
distinguishable from one that does not. fetchAttachment already does this for
the same reason.

Truncating and saying so rather than refusing. A page is usually front-loaded,
so refusing wastes a request that succeeded, where an attachment is usually
wanted whole and refusing is right there. Both are honest and this one is more
useful. Reversible if it reads wrong.

Cutting on a byte offset can split a rune, so the seam is repaired rather than
handed to the model broken. That is a second defect the obvious fix introduces
and a test names it.

Not touching the disclosure footer. A truncated fetch did return data, so a
success glyph is accurate, and a fourth state would be scope creep into 385's
vocabulary. The marker is in the result text where the model reads it and can
tell the member. I dropped that criterion from 435 rather than quietly not
meeting it.

Mutation checked by forcing the untruncated path, where both new tests fail.

closes #435

Co-authored-by: Kai Siren coilysiren@gmail.com
Co-authored-by: Claude noreply@anthropic.com

io.LimitReader stopped at the cap and returned what it had, so an oversize page came back looking whole. The model answered from a document whose ending it never saw, with ordinary confidence, which is the instrument-answers-instead-of- failing shape rather than a rough edge. The read now takes one byte past the cap, which is what makes a page that fits distinguishable from one that does not. fetchAttachment already does this for the same reason. Truncating and saying so rather than refusing. A page is usually front-loaded, so refusing wastes a request that succeeded, where an attachment is usually wanted whole and refusing is right there. Both are honest and this one is more useful. Reversible if it reads wrong. Cutting on a byte offset can split a rune, so the seam is repaired rather than handed to the model broken. That is a second defect the obvious fix introduces and a test names it. Not touching the disclosure footer. A truncated fetch did return data, so a success glyph is accurate, and a fourth state would be scope creep into 385's vocabulary. The marker is in the result text where the model reads it and can tell the member. I dropped that criterion from 435 rather than quietly not meeting it. Mutation checked by forcing the untruncated path, where both new tests fail. closes #435 Co-authored-by: Kai Siren <coilysiren@gmail.com> Co-authored-by: Claude <noreply@anthropic.com>

coilyco-ops added 1 commit

2026-08-13 12:50:11 +00:00

fix(fetch): a page cut at the cap says it was cut

ci / test (pull_request) Successful in 40s

Details

ci / publish-echo-image (pull_request) Has been skipped

Details

ci / publish-observed (pull_request) Has been skipped

Details

ci / image-build (pull_request) Successful in 23s

Details

f622fc16ff

io.LimitReader stopped at the cap and returned what it had, so an oversize page
came back looking whole. The model answered from a document whose ending it
never saw, with ordinary confidence, which is the instrument-answers-instead-of-
failing shape rather than a rough edge.

The read now takes one byte past the cap, which is what makes a page that fits
distinguishable from one that does not. fetchAttachment already does this for
the same reason.

Truncating and saying so rather than refusing. A page is usually front-loaded,
so refusing wastes a request that succeeded, where an attachment is usually
wanted whole and refusing is right there. Both are honest and this one is more
useful. Reversible if it reads wrong.

Cutting on a byte offset can split a rune, so the seam is repaired rather than
handed to the model broken. That is a second defect the obvious fix introduces
and a test names it.

Not touching the disclosure footer. A truncated fetch did return data, so a
success glyph is accurate, and a fourth state would be scope creep into 385's
vocabulary. The marker is in the result text where the model reads it and can
tell the member. I dropped that criterion from 435 rather than quietly not
meeting it.

Mutation checked by forcing the untruncated path, where both new tests fail.

closes #435

Co-authored-by: Kai Siren <coilysiren@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>

coilyco-ops requested review from coilysiren

2026-08-13 12:50:12 +00:00

coilyco-ops force-pushed fix/a-truncated-page-says-so from f622fc16ff

ci / test (pull_request) Successful in 40s

Details

ci / publish-echo-image (pull_request) Has been skipped

Details

ci / publish-observed (pull_request) Has been skipped

Details

ci / image-build (pull_request) Successful in 23s

Details

to 8d7feba0d4