fix(jetbrains): normalize icon canvas and stroke geometry

[kirillk]

Context

Stacked on top of #12731 (palette fixes). The icon-jetbrains audit found ~33 JetBrains plugin icons drawn on a 20-unit grid, plus book-open-check and wand-sparkles on a 24-unit grid, while declaring width/height="16". That mismatch meant the IDE rendered those assets as scaled-down 16px icons with inconsistent effective stroke weights, mixed square/round caps, and canvas geometry that did not match the intended IntelliJ action-icon size.

This PR normalizes the affected icon assets to a native 16x16 coordinate grid and makes the stroke geometry explicit.

What changed

• Rescaled icon canvases to viewBox="0 0 16 16" for the affected SVGs, uniformly scaling geometry from 20x20 (x0.8) or 24x24 (x0.667) into the native IntelliJ action-icon canvas.
• Normalized primary outline strokes to the intended 1px round-stroke treatment so icons no longer rely on implicit 20->16 downscaling to produce ~0.8px lines.
• Preserved proportional secondary/decorative strokes where needed after review: window titlebar dots keep their decorative hairline, shield badge rings stay flush with the status dot, and glasses/mcp use scaled 0.8px strokes to avoid cap clipping or unintended weight changes.
• Updated cap/join geometry from mixed square caps to round caps/joins where that matches the normalized icon set; arc geometry in book-open-check was scaled while preserving rotation and arc flags.

Untouched: already-16 icons, the 20x20 (plus, kilo@20x20) and 40x40 (scroll-*) icons whose canvas already matches their role, and the brand logos.

Before and after

Scope note

This fixes the canvas-size and stroke-geometry mismatch. It does not attempt a full designer pixel-snapping pass: uniformly scaling existing paths preserves shape proportions but can leave fractional coordinates such as 5.3332. A future manual vector pass could snap individual curves/strokes to the pixel grid if we want sharper rasterization beyond this normalization.

Some icons will look slightly heavier than before because they previously rendered a default stroke-width="1" from a 20-unit viewBox at an effective ~0.8px. The normalized 16x16 assets intentionally render primary strokes at 1px. Secondary strokes that were decorative or would clip after the canvas change now use explicit scaled widths instead.

How to Test

Automated/local verification

• Rendered every affected icon before/after into montages and visually checked shape fidelity, including the arc-based book-open-check.
• Parsed the review-touched SVGs as XML after the follow-up stroke fixes.
• Ran bun run typecheck from packages/kilo-jetbrains/ successfully.
• Push hook also ran repository typechecks, including @kilocode/kilo-jetbrains:typecheck, successfully.

Reviewer test steps

1. Run the plugin with ./gradlew runIde from packages/kilo-jetbrains/.
2. Eyeball the affected icons in both light and dark themes at 100% scale and on a HiDPI display.
3. Confirm no icon is clipped, off-center, or visually heavier/lighter than intended for its UI role.

Blocked checks and substitute verification

• In-IDE HiDPI visual QA could not be run headlessly; substituted with before/after rasterized montages via ImageMagick.

Checklist

• Issue linked above, or exception explained
• Tests/verification described
• Screenshots/video included for visual changes, or marked N/A
• Changeset considered for user-facing changes
• I personally reviewed the diff and can explain the changes, including any AI-assisted work.

[kilo-code-bot]

WARNING: The three window dots grow ~75% — this stroke was a 0.25 hairline, not a real 1px stroke.

The original path used stroke-width="0.25" on the 20-unit grid (≈0.2px at 16px render) purely to fatten the filled dots slightly. Scaling the geometry by ×0.8 while forcing stroke-width="1" takes each dot from ≈1.07px to ≈1.87px diameter, so the dots will render noticeably heavier and blobbier than before. That contradicts the PR's "shapes are unchanged" claim for this icon.

Suggest scaling this decorative hairline like the geometry (0.25 × 0.8 = stroke-width="0.2") rather than normalizing it to 1. window-cursor_dark.svg:3 needs the same change.

Also worth a look: the frame path on line 2 went from stroke-width="1.07143" on the 20 grid (≈0.857px effective) to a full 1px, so the window outline gets ~17% heavier too.

---

Reply with @kilocode-bot fix it to have Kilo Code address this issue.

[kilo-code-bot]

SUGGESTION: The white badge ring now overlaps the green fill.

Before, this ring was r="3" with an implicit stroke-width="1" on the 20-unit grid, so the stroke spanned r 2.5–3.5 and its inner edge sat exactly on the r="2.5" green fill edge. After scaling, the ring is r="2.4" but the stroke is still an unscaled 1, spanning r 1.9–2.9 — it now paints over 0.1 units of the r="2" green fill, shrinking the visible green badge.

Scaling the implicit stroke keeps the ring flush with the fill edge as designed. shield-filled_dark.svg:5 needs the same change.

Suggested change

	<circle cx="12" cy="12" r="2.4" stroke="#FFFFFF"/>
	<circle cx="12" cy="12" r="2.4" stroke="#FFFFFF" stroke-width="0.8"/>

---

Reply with @kilocode-bot fix it to have Kilo Code address this issue.

[kilo-code-bot]

SUGGESTION: Temple end caps are now clipped at both edges of the 16×16 canvas.

The two temple segments run from x=0.3333 and to x=15.6666. With a 1px round cap centered on those points the caps reach -0.167 and 16.167, so they're clipped by the viewBox. Previously the same geometry clipped by only ~0.07px of rendered output (0.4166 on a 20 grid with an effective 0.8px stroke), so this is roughly 2.5× worse.

Nudging both endpoints inward (0.5 and 15.5) would keep the caps inside the canvas. glasses_dark.svg:2 has the same geometry. views/mcp.svg has a milder version of this at the top of path 1 (y=0.4217 → -0.078).

---

Reply with @kilocode-bot fix it to have Kilo Code address this issue.

[kilo-code-bot]

Code Review Summary

Status: 1 Issue Found | Recommendation: Address before merge

Overview

Severity	Count
CRITICAL	0
WARNING	0
SUGGESTION	1

Issue Details (click to expand)

SUGGESTION

File	Line	Issue
frontend/src/test/kotlin/.../PromptPanelTest.kt	1055	Values are correct, but the test hardcodes the palette hexes while its name claims parity with the scroll button colors. Deriving the expectation from scroll-bottom.svg would stop this line from needing a manual edit on every palette change.

Verification notes

Incremental review of the single commit since 2f4ffc3 (test(jetbrains): update send icon color expectations), which changes only two assertion lines in PromptPanelTest.kt.

I confirmed the new expectations match the assets at this HEAD: send.svg is fill="#3574F0" and send_dark.svg is fill="#548AF7", identical to scroll-bottom.svg / scroll-bottom_dark.svg. The old #0066B8 / #0A7BD8 values no longer exist anywhere under resources/icons/, so this update was required by the palette change on the stacked base branch (fix/jetbrains-icon-palette) rather than by anything in this PR's own SVG edits. The test change is correct and no icon asset changed in this revision.

The two remaining stroke-weight suggestions from the previous revision (views/glasses.svg, views/mcp.svg) are unchanged in code, and the PR description now documents the 0.8 widths as a deliberate choice to avoid cap clipping and unintended weight changes. That answers the mcp confirmation request and records the rejected alternative for glasses, so I am not carrying them forward as open findings; the existing inline threads remain for reference.

In-IDE HiDPI visual QA is still not runnable in this environment. No changeset is expected — packages/kilo-jetbrains is not a changesets package.

Files Reviewed (1 file)

• packages/kilo-jetbrains/frontend/src/test/kotlin/ai/kilocode/client/session/ui/PromptPanelTest.kt - 1 issue

Fix these issues in Kilo Cloud

Previous Review Summaries (2 snapshots, latest commit 2f4ffc3)

Current summary above is authoritative. Previous snapshots are kept for context only.

Previous review (commit 2f4ffc3)

Status: 2 Issues Found | Recommendation: Address before merge

Overview

Severity	Count
CRITICAL	0
WARNING	0
SUGGESTION	2

Issue Details (click to expand)

SUGGESTION

File	Line	Issue
icons/views/glasses.svg	2	Fixing the cap clipping by thinning the whole path to stroke-width="0.8" opts this icon out of the 1px normalization, so it renders lighter than its views/ neighbours. Insetting the temple endpoints to 0.5/15.5 keeps both. Same in glasses_dark.svg.
icons/views/mcp.svg	2	stroke-width="0.8" on the <g> reverts to the pre-PR weight, but unlike glasses there was no clipping to avoid here (extents fit a 1px cap), so this is a pure weight inconsistency vs. the rest of the set. Same in mcp_dark.svg.

Previous issues resolved in this revision

All three findings from the earlier review are fixed by scaling the stroke widths along with the geometry:

• views/window-cursor.svg / _dark — dot stroke 1 → 0.2 (= 0.25 × 0.8), restoring the ~1.07px painted dot diameter. Fixed.
• shield-filled.svg / _dark — badge ring stroke-width="0.8" on r=2.4 now spans 2.0–2.8, flush with the r=2 green fill instead of overlapping it. Fixed.
• views/glasses.svg / _dark — cap extents are back to -0.0667 / 16.0666, identical to the pre-PR design rather than ~2.5× worse. Fixed (see the remaining weight-consistency note above).

Verification notes

Incremental review of the 8 files changed since b1911c5. I re-derived each stroke width against its pre-PR value on the original 20-unit grid and confirmed every one is the correct × 0.8 scale, and re-computed the affected cap/ring extents by hand.

For views/mcp.svg I checked all three inherited paths for edge proximity, including the Bézier extremum on the first path (y ≈ 0.636 at t = 0.5, not the 0.4217 control-point value), so a 1px stroke would not clip.

I could not run in-IDE HiDPI visual QA in this environment, so rendered-output impact is derived analytically. packages/kilo-jetbrains is not a changesets package, so no changeset is expected.

Files Reviewed (8 files)

• icons/views/glasses.svg - 1 issue
• icons/views/glasses_dark.svg - covered by the above
• icons/views/mcp.svg - 1 issue
• icons/views/mcp_dark.svg - covered by the above
• icons/views/window-cursor.svg - previous issue fixed
• icons/views/window-cursor_dark.svg - previous issue fixed
• icons/shield-filled.svg - previous issue fixed
• icons/shield-filled_dark.svg - previous issue fixed

Fix these issues in Kilo Cloud

Previous review (commit b1911c5)

Status: 3 Issues Found | Recommendation: Address before merge

Overview

Severity	Count
CRITICAL	0
WARNING	1
SUGGESTION	2

Issue Details (click to expand)

WARNING

File	Line	Issue
icons/views/window-cursor.svg	3	stroke-width on the filled dots went from a 0.25 decorative hairline to 1, growing each dot ~75% (≈1.07px → ≈1.87px). Same in window-cursor_dark.svg.

SUGGESTION

File	Line	Issue
icons/shield-filled.svg	5	White badge ring r scaled to 2.4 but its implicit stroke stayed 1, so it now paints over 0.1 units of the r=2 green fill instead of sitting flush with it. Same in shield-filled_dark.svg.
icons/views/glasses.svg	2	Temple end caps at x=0.3333 / x=15.6666 with a 1px round cap now extend to -0.167 / 16.167 and get clipped by the viewBox (~2.5× worse than before). Milder version in views/mcp.svg.

Verification notes

I re-derived the coordinate transform by hand for a representative sample across both scale factors — arrow-down-to-line, compress, checklist, code-lines, console, task, bubble-5, glasses, magnifying-glass-menu, mcp, brain (×0.8 from 20), and book-open-check, wand-sparkles (×0.6667 from 24, including arc rx/ry and relative-segment scaling). All geometry scaling is arithmetically correct, and the book-open-check arc flags are preserved as claimed.

The stroke-linecap square → round swap is visually benign: both cap styles extend half a stroke width past the endpoint, so extents don't change.

The issues above are all cases where geometry was scaled but a non-default stroke-width was normalized to 1 (or left implicit at 1) instead of scaled with it, so the stroke/geometry ratio shifted. The intentional weight normalizations flagged in the PR description (1.25→1 on arrow-down-to-line, 2→1 on book-open-check, 1.4→1 on the shield-filled check) look deliberate and I did not flag them.

I could not run visual QA in this environment, so the rendered-output impact is derived analytically rather than observed. packages/kilo-jetbrains is not a changesets package, so no changeset is expected here.

Files Reviewed (66 files)

All 66 SVG assets under packages/kilo-jetbrains/frontend/src/main/resources/icons/:

• icons/views/window-cursor.svg, icons/views/window-cursor_dark.svg - 1 issue
• icons/shield-filled.svg, icons/shield-filled_dark.svg - 1 issue
• icons/views/glasses.svg, icons/views/glasses_dark.svg - 1 issue
• arrow-down-to-line, arrow-up, book-open-check, chevron-down, collapse, compress, copy, discord, expand, shield, wand-sparkles (+ _dark) - no issues
• views/brain, bubble-5, bullet-list, check-small, check-small-active, checklist, chevron-down, chevron-left, chevron-right, close-small, close-small-active, code, code-lines, console, eye, magnifying-glass-menu, mcp, task, warning (+ _dark) - no issues

Fix these issues in Kilo Cloud

---

_{Reviewed by claude-opus-5 · Input: 34 · Output: 9.1K · Cached: 944.8K}

_{Review guidance: REVIEW.md from base branch fix/jetbrains-icon-palette}

[kilo-code-bot]

SUGGESTION: Thinning the whole path to 0.8 fixes the clipping, but it also opts this icon out of the 1px normalization.

stroke-width="0.8" restores the exact pre-PR effective weight (0.8px at 16px), so the temple caps now land at -0.0667 / 16.0666 — identical to before, so no regression there. The tradeoff is that glasses now renders visibly lighter than its views/ neighbours (task, console, eye, brain, …) that this PR moved to a true 1px stroke.

An alternative that keeps both properties: leave stroke-width at 1 and inset just the two temple endpoints from 0.3333/15.6666 to 0.5/15.5, so the round caps sit flush inside the canvas. Same applies to glasses_dark.svg.

Either way, the PR description's "Strokes normalized to stroke-width="1"" is no longer accurate for this file and views/mcp.svg — worth a description tweak so future audits don't re-flag these.

---

Reply with @kilocode-bot fix it to have Kilo Code address this issue.

[kilo-code-bot]

SUGGESTION: Confirm this weight change is intentional and not a blanket revert.

stroke-width="0.8" on the <g> restores the pre-PR effective weight (0.8px at 16px) for all three inherited paths. Unlike views/glasses.svg, there is no clipping to avoid here: the extents are x ∈ [0.7781, 14.4918] and y ∈ [~0.636, 15.3439], so a 1px round cap (half-width 0.5) stays inside the 16×16 canvas on every side.

So the only effect is that mcp renders lighter than the other views/ icons this PR normalized to 1px. If the goal was pixel-identical output, that's fine — but it's a visible inconsistency inside the same tool window. Same in mcp_dark.svg.

---

Reply with @kilocode-bot fix it to have Kilo Code address this issue.

[kilo-code-bot]

SUGGESTION: The values are correct, but the test duplicates the palette instead of asserting the parity its name claims.

I verified send.svg is #3574F0 and send_dark.svg is #548AF7 at this HEAD, matching scroll-bottom.svg / scroll-bottom_dark.svg, so this update is right. The test name is test send icon matches scroll button theme colors, yet nothing here reads the scroll button asset — the needing-to-edit-this-line-at-all is the drift the test was supposed to catch. If the scroll button palette moves again and send.svg is missed, this test keeps passing on a stale hardcoded hex.

Deriving the expectation from the scroll asset would make it self-maintaining, e.g. extract the fill="#......" from /icons/scroll-bottom.svg and assert /icons/send.svg contains the same value (and likewise for the _dark pair). Non-blocking — your call.

---

Reply with @kilocode-bot fix it to have Kilo Code address this issue.