docs(readme): re-render frame 5 for the TASK-169 Signal leftovers (TASK-165)

[lilyshen0722]

What this is

Frame 5 of the README (Bring your own agent) re-rendered against main now that #1917 removed the last pre-Signal rules from the BYO page. One commit, two files, the same bytes in both:

path	before	after
docs/assets/readme/byo-2x.png	378746d0 (255658 B)	1b0dfaab (255057 B)
frontend/src/assets/landing/byo.png	378746d0 (255658 B)	1b0dfaab (255057 B)

The rendered change is the TASK-169 footnote code chips; 2880×1880 is unchanged.

README.md is not in the diff. The file name is unchanged, so the reference, the alt text and the caption are byte-identical. Whether the alt still describes the new render is a pixel question, not a text question, and it is the gate below rather than an assertion here.

Where the bytes came from, and how they were authenticated

Not from the pod attachment. GET /api/agents/runtime/pods/:podId/files/:fileName/content answers content: null + "Binary file — content is not returned as text" for image/png (backend/routes/agentsRuntime.ts:1838), which is correct behaviour — the alternative (AX entry 19) was a .docx returned as raw ZIP bytes decoded as text. Filenames also prove nothing about contents, since this PR carries a same-name overwrite.

Authenticated instead by hash off the renderer's path:

.dev/signal/t161/f159b/byo-2x.png
  git hash-object → 1b0dfaabdce33e017967966ef5cb7579c73e45cd
  size 255057 B, IHDR 2880×1880

which matches ux-lead's announcement of 1b0dfaab and its dimensions, and differs from main's 378746d0, so this is a real change.

The render still describes main-as-now. It was rendered from 159bc313; main has moved four times since (9eabb90b #1901 backend, 8235be3d #1885 guard, 5df4c1b6 #1918 landing/i18n, 4e60f240 #1955 docs). Only the i18n pair overlaps this frame's inputs at all, and those 52 lines are landing.features.* — grep -c agentByo over the changed lines is 0, so nothing the BYO page renders moved:

git diff --stat 159bc313..HEAD -- frontend/src/v2/components/V2AgentBYO.tsx \
  frontend/src/v2/v2.css frontend/src/i18n/locales/
→ locales only, zero agentByo keys

Why both files in one commit

frontend/src/v2/landing/__tests__/landingFrames.test.ts byte-pins each landing copy to its README frame. Moving one without the other reds the pin, so the pair travels together — this is the refresh-once rule seen from the producer side.

Evidence

On this head, with these bytes in place:

• landingFrames.test.ts + readmeFrames.test.ts — 19 passed, 19 total, 2 suites.
• Positive control for the pin's discriminating power: reverting only frontend/src/assets/landing/byo.png to main's 378746d0 while the README frame keeps 1b0dfaab reds landingFrames.test.ts (1 failed / 5 passed). So the green is a real comparison of these two paths, not an incidental pass.

Gate

ux-lead: blob identity + pixel diff, as requested in their ask — at 1200 and 390, with the alt re-checked against the new pixels.

Provenance

Timing on the previous frame-5 event, for anyone reading this PR in the middle of it: #1919's press won a race against ux-lead's earlier re-render by six minutes, so that change landed as a same-name follow-up PR. This one is the redraw for #1917, opened after #1918 merged, which is the ordering the pinned-copy set requires.

[lilyshen0722]

UX-GATE: PASS @ e58899d

Blob identity: docs/assets/readme/byo-2x.png and frontend/src/assets/landing/byo.png are both 1b0dfaab, 2880×1880, byte-equal to the frame-5 render I delivered from main 159bc31. No other path changes: one commit, Lily-authored, and README.md is untouched.

Pixel read: I built the PR head once and rendered the landing twice, en and zh at 1200 and 390. One run is as built; in the other, only the byo asset request is answered with main's 378746d0 bytes, so the image is the single variable.

• Geometry is identical in both and equal to the #1918 PASS. Row 4's shot is 573.4×375 at 1200 and 342×223.9 at 390. Overflow is 0, with no bar and no shadow.
• All of the en diff is inside the byo image, and nearly all of it sits in the footnote band where the TASK-169 code chips are: 8,483 of 8,548 px at 1200 (max delta 134), and 3,522 of 3,559 at 390 (max 87). The rest is at most 5 levels, from form-field corner anti-aliasing.
• zh shows the same band, plus differences of at most 1 level in rows 1–3. Those images are byte-identical in both runs, so this is resampling noise, not the swap.

Alt: README.md:113 and landing.features.byo.alt in en and zh are unchanged. They are still true, because the chips are the only thing that changed.

Currency: since 159bc31, main's only frontend change is #1918's landing files and its landing.features.* keys. V2AgentBYO.tsx and v2.css are untouched, so the frame still shows main. #1926 and #1876 landed after this PR's base and touch neither file nor README line 113.

[lilyshen0722]

CODE GATE: PASS @ e58899d5 — sprint-review.

Scope is exactly two files, both the same blob, README and all prose untouched: docs/assets/readme/byo-2x.png and frontend/src/assets/landing/byo.png each go 378746d0 → 1b0dfaab (255658 → 255057 B). The two copies are byte-identical to each other at the head, which is what landingFrames.test.ts pins, so the pin holds by construction rather than by luck. 2880×1880 = 3.27× the rendered 880. Guards: readmeFrames + landingFrames 19/19. Behind 2, author Lily throughout.

The swap is real and it carries the change it claims. A different blob only proves a re-render; the PR's claim is that it carries TASK-169. I pixel-diffed 378746d0 against 1b0dfaab: 47,293 differing pixels (0.87% of the frame), and 99.9% of them fall in a single 78px band at y 1716–1793 — the CLI footnote. That is where item 7 lives (.v2-byo__footnote code, ui-monospace stack → var(--v2-font-mono)), and it is the only TASK-169 item that touches a surface this frame renders; the rest are after-submit states the pre-submit view never shows. The remaining ~0.1% is ten 5px bands at the input and select edges, consistent with corner-radius antialiasing.

So: consistent with item 7 landing, and inconsistent with a no-op re-render — which was the thing worth ruling out, since a same-name swap that changed nothing would look identical in the diffstat.

Two notes, neither blocking:

1. The README alt is untouched while the image changed. It still reads true of the new render — "On my computer" chosen, fern, Sam's MacBook Pro, Launch — but that is the trap a fixed-filename swap sets, and it is worth re-reading on every such PR rather than only when the diff mentions the prose.
2. Visually the pre-submit surface is unchanged at a glance. That is expected here, not a defect: TASK-169's other items are after-submit surfaces. Anyone re-rendering to demonstrate those states will need a frame captured after submit.