Either side of the diff, onto the clipboard — and the .har that crashed it

[mindaugaskasp]

Copy either side

Copying a side is not copying the diff. Each file slot now carries a copy control that puts that file's own text on the clipboard verbatim — reachable from the slot, Edit ▸ Copy Left/Right Side, the palette, and Cmd/Ctrl+Shift+1 / +2 (Shift over the digit that opens that side). Paste mode reads the typed buffers.

A side with no text to give — a spreadsheet carries sheets, a streamed file only a path — shows no control at all rather than one that refuses. utils/sideText.js answers that once for both the button and the action, so no surface can offer what another declines.

Two files sat at their exact ratchets and forced the extraction rather than a raised cap:

	before	after
diffStore.js	747 / 747	710 — copy actions → stores/diffCopy.js
buildMenus	87 / 87	67 — Edit section → editSection()

The .har crash — three faults

Reproduced in e2e/deep-html.spec.mjs (red → green):

1. .har was in no extension map, so it fell through to content sniffing.
2. Sniffing sees a 50k prefix, which cuts a multi-MB capture into JSON that no longer parses. HTML_RE then matched the <div>/<script> inside the captured response bodies and named the whole file HTML.
3. Monaco's HTML worker walks document symbols by plain recursion with no depth guard, and every tag inside a JSON string is unclosed to an HTML parser — the nesting accumulated until the stack went.

Fixed: har/map/webmanifest resolve to json outright; the two sniffers that scan anywhere skip JSON-shaped text; documentSymbols is off for HTML, which removes the crash surface for any deeply nested HTML rather than this one route. Nothing here consumes symbols.

detectLanguage.js was itself at 250/250, so the claude.ai link helpers — never language detection — moved to utils/claudeLink.js.

The theme check, and the instrument that was wrong

The all-20 check for the new control lives in e2e, not theme-sweep: every surface there opens through paste mode, which replaces the slots row, and the control exists only once a real file is loaded.

It caught .btn-icon's --text-dim falling under the 3:1 mark floor on five light grounds — sepia 2.09, solar 2.37, bloom 2.58, linen 2.72, meridian 2.91 — so the revealed state takes full ink.

The first run of that probe was itself wrong: .btn transitions colour over 120ms and getComputedStyle reports the interpolated value, so it measured a colour no one ever sees and named the wrong themes. It now settles before measuring and carries a control probe that fails the instrument, not the theme, when a reading is impossible.

Verified

• npm run check exit 0 — 3498 tests, re-run after rebasing onto main
• Full e2e in Docker — 518 passed, 3 skipped
• make theme-sweep — 1480 measurements across 20 themes
• The spreadsheet guard proven red→green by deliberately breaking the rule

Not verified: the raw Cmd+Shift+1/2 keypress — CDP-injected keys never reach a native accelerator, so the spec drives the menu item and the binding rests on the unit-level shortcut guard.

🤖 Generated with Claude Code