Claude: changes for issue #35 #40

Merged

Grandiras merged 1 commit from claude/issue-35 into main

2026-07-27 14:34:50 +00:00

claude-bot commented

2026-07-27 14:32:26 +00:00

Collaborator

Closes #35.

claude-bot added 1 commit

2026-07-27 14:32:26 +00:00

Give the large icon surfaces the real mark, not the tab-strip cut

CI / build (pull_request) Successful in 35s

Details

28b632aa2e

favicon.svg is a reduction: squircle, sun, two streamlines, chosen for
what survives 16 px. It was also the only icon the app declared, so a
browser installing the site — home screen, launcher, desktop shortcut —
had nothing else to install and shipped that compromise at 192 px.

Point every surface with room for it at the full mark instead, through a
manifest and an apple-touch-icon. Three new SVGs, one family and three
decisions: icon.svg is the mark as a file (a Chromium render of it and
BrandMark.razor is pixel-identical); apple-touch-icon.svg is the same
artwork full bleed, because iOS composites on black and would return the
transparent surround as a black ring, then round our 25% corners a second
time; icon-maskable.svg is full bleed with the artwork scaled 0.78 about
the centre, because an Android launcher may crop to a circle of 80%
diameter and the sun's halo reaches 31.4 of our 64.

favicon.svg stays untouched and stays the only rel="icon" — a second one
with sizes="any" lets the browser pick the full mark for a 16 px tab,
which is what favicon.svg exists to prevent.

manifest.json rather than site.webmanifest: an extension the static-file
content-type map doesn't know is served as a 404, and .json always is.

The PNGs are committed build output; tools/render-icons.sh regenerates
them and has to be re-run when a source SVG changes, or iOS and Android
keep showing the old mark. It needs librsvg — ImageMagick's built-in SVG
renderer drops the gradient fills and paints the squircle black.

claude-bot referenced this pull request

2026-07-27 14:32:26 +00:00

Use the real icon whenever possible #35

claude-bot commented

2026-07-27 14:32:29 +00:00

Author

Collaborator

🤖 Reviewing this PR — follow along in the action run; the reply will link the full session transcript.

📜 Live transcript — updating every ~5 minutes while the task runs.

🤖 Reviewing this PR — follow along in [the action run](https://git.grandiras.net/Grandiras/claude-bot/actions/runs/125); the reply will link the full session transcript. 📜 [Live transcript](https://git.grandiras.net/Grandiras/claude-bot/src/branch/claude-logs/transcripts/Grandiras/Ponente/pr-40/run-125.md) — updating every ~5 minutes while the task runs.

claude-reviewer approved these changes

2026-07-27 14:34:27 +00:00

claude-reviewer left a comment

✅ Verdict: approve — no blocking issues found.

Clean, well-scoped change that adds the full mark to install/home-screen surfaces while leaving favicon.svg as the sole tab-strip icon. I verified the actual mechanics rather than just reading the diff:

icon.svg's markup is byte-for-byte identical (modulo fixed vs. per-instance gradient ids) to what BrandMark.razor renders, so the claim that it's a pixel-for-pixel match holds.
Extracted the committed PNGs from the branch and checked their PNG IHDR chunks directly: apple-touch-icon.png is 180×180, color type 2 (no alpha) — matches both render-icons.sh's render size and the new icons.spec.js assertions about an opaque iOS icon. icon-512.png is 512×512, color type 6 (alpha) — matches the manifest's any icon expectations. The committed binaries genuinely match what the new tests assert, so this isn't a case of tests pinning values the build won't reproduce.
Program.cs runs UseAuthentication/UseAuthorization before MapStaticAssets, but nothing scopes an authorization policy to wwwroot paths, so the manifest and icons are reachable anonymously as the new tests assume.
manifest.json's .json extension is served with the correct content-type by ASP.NET Core's default static-file provider, consistent with the comment explaining why site.webmanifest was avoided.

No correctness, security, or omission issues found.

⏱ 1m 47s · 17 turns · tokens: 32.3k in / 6.7k out (+883.4k cache-read)
📜 Full session transcript

✅ **Verdict: approve** — no blocking issues found. Clean, well-scoped change that adds the full mark to install/home-screen surfaces while leaving `favicon.svg` as the sole tab-strip icon. I verified the actual mechanics rather than just reading the diff: - `icon.svg`'s markup is byte-for-byte identical (modulo fixed vs. per-instance gradient ids) to what `BrandMark.razor` renders, so the claim that it's a pixel-for-pixel match holds. - Extracted the committed PNGs from the branch and checked their PNG `IHDR` chunks directly: `apple-touch-icon.png` is 180×180, color type 2 (no alpha) — matches both `render-icons.sh`'s render size and the new `icons.spec.js` assertions about an opaque iOS icon. `icon-512.png` is 512×512, color type 6 (alpha) — matches the manifest's `any` icon expectations. The committed binaries genuinely match what the new tests assert, so this isn't a case of tests pinning values the build won't reproduce. - `Program.cs` runs `UseAuthentication`/`UseAuthorization` before `MapStaticAssets`, but nothing scopes an authorization policy to wwwroot paths, so the manifest and icons are reachable anonymously as the new tests assume. - `manifest.json`'s `.json` extension is served with the correct content-type by ASP.NET Core's default static-file provider, consistent with the comment explaining why `site.webmanifest` was avoided. No correctness, security, or omission issues found. --- ⏱ 1m 47s · 17 turns · tokens: 32.3k in / 6.7k out (+883.4k cache-read) 📜 [Full session transcript](https://git.grandiras.net/Grandiras/claude-bot/src/branch/claude-logs/transcripts/Grandiras/Ponente/pr-40/run-125.md)