fix(fork): sidebar brand mark is no longer blurry

[NoahHendrickson]

The sidebar brand mark rendered blurry. Its art is a 23×23 pixel grid, but the asset shipped as a 24×24 PNG — 23 does not divide into 24, so the export resampled every cell with smoothing and baked the blur permanently into the file. Decoding the shipped PNG confirms it: 562 of its 576 pixels were not in the art's 9-colour palette, and the file held 136 distinct colours. image-rendering: pixelated made it worse rather than better, faithfully enlarging that mush into hard blocks on retina.

Rebuilt the mark as a vector from the Figma node — integer coordinates on a 0 0 23 23 viewBox with shape-rendering="crispEdges", so cells stay hard-edged at any size and DPR — and dropped the now-pointless image-rendering hack.

Left: before. Right: after. Both are the true rasterisation at 24 CSS px on a 2× display, magnified 9× so individual device pixels are visible.

One deliberate side effect: the old export had flattened Figma's #1E1E1E canvas into the bitmap (every pixel was opaque), which is the faint dark square around the mark. The vector is transparent, so it now composites onto the sidebar. The black is genuine art — the mark's outline — and is preserved.

Verification

Figma exports these rects under rotate()/matrix() transforms, so naive x/y parsing yields garbage; positions came from transforming each rect's corners. Three independent checks:

• All 340 rects land exactly on the 23×23 grid, zero off-grid.
• Sampling each cell centre of Figma's own 960px render: all 529 cells match exactly.
• Round-tripping the emitted SVG reproduces all 529 cells with no overlaps.

typecheck clean, lint clean, forkSidebarChrome guards 16/16. The guard previously asserted the PNG was 24×24 — that assertion encoded the defect — so it now pins the vector invariants (23-unit viewBox, crispEdges, integer-only coordinates) instead.

Note: forkComposerShell.test.ts fails on this branch, but it fails identically on a clean custom (COMPOSER_FOOTER_COMPACT_BREAKPOINT_PX is 620, guard expects 400). Pre-existing and unrelated.

Web-only. Mobile and desktop use separate upstream 1024px app icons, which are unaffected.

The evidence image above lives on the assets/brand-mark-crispness branch; delete it once this merges.

🤖 Generated with Claude Code — Claude Opus 5 (1M context)

Review round

Guard hardening landed in 926855d: the pixelated-hack ban now covers the component, and the integer-grid check asserts a coordinate count and bans transform=/<path> so it cannot pass vacuously. The DPR-1 center line (23 cells in a 24px slot) is accepted and documented in the lockup comment — drawing the art at 23px would center it on a half-pixel. The SVG staying over Vite's 4096-byte inline limit is deliberate: collapsing the rects into paths would blind the integer-grid guard, so the mark costs one cached request instead.

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[cursor]

Thermo-nuclear code quality review

No major structural issues found. Approval bar met.

This is a correctly layered asset fix: replace the defect-encoding 24×24 PNG (and the image-rendering:pixelated workaround that amplified it) with a 23-unit vector mark + crispEdges, retarget the fork guard to the real invariants, and update the manifest path. No spaghetti growth, no file-size pressure, no missed code-judo — the PR is the simplification.

  

_{Sent by Cursor Automation: Thermo-nuclear PR review}

[NoahHendrickson]

Code review

The diagnosis is right and the rebuild is sound. I independently verified the risky part rather than taking the PR body's word for it:

• The vector matches the old bitmap. Decoded the removed PNG, reconstructed the new SVG's cell grid, box-resampled the vector 23→24 over #1e1e1e, and compared pixel-by-pixel: mean per-pixel error 12.6/441, max 30.4. Every alternative alignment (half-pixel offsets, 1:1 scale) scored 2–4× worse. That confirms the rects came out of Figma without mirroring, rotation, or an off-by-one — the failure mode most likely to survive the PR's own checks.
• Grid integrity. 147 rects, 253 filled cells, 0 out-of-bounds, 0 overlaps, all-integer coordinates.
• Plumbing. No svgr plugin in apps/web/vite.config.ts, so the default URL import is correct; Mime.getType (apps/server/src/http.ts:363) serves image/svg+xml; Electron CSP allows img-src 'self'; manifest entry updated; no dangling references to the PNG anywhere.
• Transparency change. Net improvement — the old PNG carried a baked #1e1e1e square that was visible in the light theme. In the fork's dark theme the sidebar is exactly #1e1e1e, so the composite is pixel-identical to the flattened bitmap. Good call, and good that the PR body flags it.

Findings

#	Where	What
1	SidebarChrome.tsx:99	23-unit grid in a 24px box — at DPR 1 the center row and column render 2px where every other cell is 1px. Verified in headless Chromium.
2	forkSidebarChrome.test.ts:185	toContain("size-6 shrink-0") still passes if [image-rendering:pixelated] comes back.
3	forkSidebarChrome.test.ts:201	Integer-coordinate loop passes vacuously on zero matches, and ignores transform=/<path>.
4	sidebar-brand-mark.svg	6386 bytes exceeds Vite's 4096 inline limit; the 1093-byte PNG was inlined, so the mark now costs a separate request.

Details inline.

Recommendation: ship it, with #2 and #3 fixed first. The guard weakening is the one I'd hold on — this is a fork guard whose entire job is stopping this defect from returning, and both issues let it go green while the defect is back. They're a few lines each.

#1 is real and worth a decision, but it isn't a reason to block: a crisp mark with one heavy center line is still much better than what's on custom today. Either take the 23px-in-a-24px-slot fix or drop the "any size or DPR" claim from the code comment. #4 is a nit.

Also confirming the PR body's note: forkComposerShell.test.ts does fail identically on a clean custom (COMPOSER_FOOTER_COMPACT_BREAKPOINT_PX is 620, guard expects 400). Pre-existing and unrelated to this change.

---

Generated by Claude Code