test(fetch): pin that a cut page and a whole one share one receipt #455

Merged

coilyco-ops merged 1 commit from qa/pin-the-truncated-receipt into main

2026-08-13 13:47:59 +00:00

coilyco-ops commented

2026-08-13 13:47:03 +00:00

Member

#435 shipped two of its three acceptance criteria. The third — "the disclosure footer does not report a truncated fetch as a plain success, or the receipt repeats the lie" — did not, and it is the one the issue author wrote because they expected it to be missed.

whole page      outcome=ok  glyph=✅
truncated page  outcome=ok  glyph=✅

receipt line for a truncated fetch:   > 🔨 ✅ `fetch`

outcomeOf classifies on two things: whether the call errored, and whether the text is blank. A truncated fetch is neither, so it lands on ToolOutcomeOK beside every other success.

The model is told the page was cut. The member is not. That is the original defect moved one component along rather than closed, and the issue's own text predicts it: "a fetch that silently truncated shows ✅ in the receipt, which now tells a member the call returned data. It did, and not all of it."

Characterization, not a demand

The fix is a fourth ToolOutcome — a call that worked and returned less than everything. That touches the glyph vocabulary two surfaces share, which e5c9163 has just been normalising, so it belongs in one decision rather than a fetch-specific patch. Making this test assert the desired behaviour would redden main for a design question nobody has answered.

So it pins today's behaviour and says so, and it flips the moment the gap closes. Verified rather than assumed — teaching outcomeOf to classify a truncated result separately:

--- FAIL: TestATruncatedFetchReceiptLooksLikeAWholeOne
    a truncated fetch now reads ❌ against ✅ for a whole page, so the receipt
    distinguishes them and this test should go with issue 435

The half that did ship is pinned beside it, so a regression in either is visible in one file rather than one of them quietly reverting while the other holds.

Why this shape keeps coming up

Four closed issues checked this hour had partly-unmet criteria — #432, #435, #413 and #417. Every gap sat in the seam between two components while the test sat inside one. footerBudget is correct and the send truncates; fetchText is correct and the receipt does not read it; assertedHistory copies the field it writes and shares the array behind another.

Each shipped fix was right about its own component. This test is deliberately placed across the seam for that reason.

Test-only. No production change.

Refs #435

https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/435 shipped two of its three acceptance criteria. The third — *"the disclosure footer does not report a truncated fetch as a plain success, or the receipt repeats the lie"* — did not, and it is the one the issue author wrote because they expected it to be missed. ``` whole page outcome=ok glyph=✅ truncated page outcome=ok glyph=✅ receipt line for a truncated fetch: > 🔨 ✅ `fetch` ``` `outcomeOf` classifies on two things: whether the call errored, and whether the text is blank. A truncated fetch is neither, so it lands on `ToolOutcomeOK` beside every other success. **The model is told the page was cut. The member is not.** That is the original defect moved one component along rather than closed, and the issue's own text predicts it: *"a fetch that silently truncated shows ✅ in the receipt, which now tells a member the call returned data. It did, and not all of it."* ## Characterization, not a demand The fix is a **fourth `ToolOutcome`** — a call that worked and returned less than everything. That touches the glyph vocabulary two surfaces share, which `e5c9163` has just been normalising, so it belongs in one decision rather than a fetch-specific patch. Making this test assert the *desired* behaviour would redden `main` for a design question nobody has answered. So it pins today's behaviour and says so, and it flips the moment the gap closes. Verified rather than assumed — teaching `outcomeOf` to classify a truncated result separately: ``` --- FAIL: TestATruncatedFetchReceiptLooksLikeAWholeOne a truncated fetch now reads ❌ against ✅ for a whole page, so the receipt distinguishes them and this test should go with issue 435 ``` The half that **did** ship is pinned beside it, so a regression in either is visible in one file rather than one of them quietly reverting while the other holds. ## Why this shape keeps coming up Four closed issues checked this hour had partly-unmet criteria — https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/432, https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/435, https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/413 and https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/417. **Every gap sat in the seam between two components while the test sat inside one.** `footerBudget` is correct and the send truncates; `fetchText` is correct and the receipt does not read it; `assertedHistory` copies the field it writes and shares the array behind another. Each shipped fix was right about its own component. This test is deliberately placed across the seam for that reason. Test-only. No production change. Refs https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/435

coilyco-ops added 1 commit

2026-08-13 13:47:03 +00:00

test(fetch): pin that a cut page and a whole one share one receipt

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

Details

ci / test (pull_request) Successful in 33s

Details

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

Details

ci / publish-observed (pull_request) Has been skipped

Details

c08705b8c8

Issue 435 shipped two of its three acceptance criteria. A page over the cap now
says it was cut, a page under it is byte-identical, and the rune seam is
repaired. The third asked that the disclosure footer not report a truncated
fetch as a plain success, and it does.

outcomeOf classifies on two things, whether the call errored and whether the
text is blank. A truncated fetch is neither, so it lands on ToolOutcomeOK beside
every other success and renders the same glyph.

  whole page      outcome=ok  glyph OK
  truncated page  outcome=ok  glyph OK

So the model is told the page was cut and the member is not, which is the
original defect moved one component along rather than closed.

Characterization rather than a demand, because the fix is a fourth ToolOutcome
for a call that worked and returned less than everything. That touches a glyph
vocabulary two surfaces share and belongs in one decision rather than a
fetch-specific patch.

Verified it flips: teaching outcomeOf to classify a truncated result separately
fails this test with the two glyphs named. The half that shipped is pinned
beside it, so a regression in either is visible in one file.

Refs sirens-echo#435

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: Kai Siren <coilysiren@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>

coilyco-ops requested review from coilysiren

2026-08-13 13:47:03 +00:00

coilyco-ops merged commit 06b347c68d into main

2026-08-13 13:47:59 +00:00

coilyco-ops referenced this pull request from a commit

2026-08-13 13:48:00 +00:00

Merge pull request 'test(fetch): pin that a cut page and a whole one share one receipt' (#455) from qa/pin-the-truncated-receipt into main