Adopt the finished O+A logo in the desktop app

[yujiezhang-ops]

Status

The logo is settled. Artwork lives in the site repo, MaimoryLab/OneAgent-site, under public/images/brand/.

The mark is a thick open ring with a chevron/A form inside it, both drawn in the same solid #007AFF, with the ring broken at the lower right where the inner form crosses it. Measured on the 1024px master at the vertical midpoint: ring stroke 109px (10.6% of canvas), ring-to-inner gap 128px (12.5%), inner stroke 122px (11.9%), gap between the two inner legs 150px (14.6%). Content occupies an 868×879 box with roughly 7% padding on all sides.

Those proportions are the useful part of this issue: they are what determines which sizes the mark survives, and they are measured rather than estimated.

This issue is no longer "design an icon". It is adopt the finished logo in the desktop app, which currently uses neither the mark nor a matching app icon.

What the site has

File	Size	Alpha	Notes
oneagent-logo.png	1024×1024	63.4% transparent	Bare mark, no plate
oneagent-logo-mark-256.png	256×256	60.0% transparent	Used by src/components/BrandMark.astro
oneagent-app-icon-512.png	512×512	4.4% transparent	Mark on a white rounded-square plate
oneagent-app-icon-192.png	192×192	—	PWA manifest icon
favicon.png	64×64	48.2% transparent	Bare mark

So there are two treatments already: a bare mark for in-UI use, and a plated app icon for launcher contexts. That split is the right one and the desktop app should mirror it.

The mark is a single flat colour: #007AFF across 19009 of ~19900 opaque pixels on the 256px asset, the remainder antialiasing. No gradient, no second colour, no outline in a different hue. That is what makes a currentColor SVG viable — see item 4.

What the desktop app has today

Nothing from this logo.

1. build/appicon.png — the old icon, unchanged since 750dea6 ("feat: macos appbundle building"). Measured: 1024×1024, 100% opaque, zero transparent pixels, white in all four corners. It is a hard-edged white square.
2. frontend/src/components/NavigationSidebar.tsx:21-23 — renders lucide's generic <Boxes> glyph inside .brand-mark. A stock icon from the icon library, not a brand at all.

So both surfaces need to change, and they currently do not even agree with each other.

Findings that change what needs doing

1. The app icon needs transparent rounded corners; the current one has none

build/appicon.png is a full-bleed opaque square. macOS does not round app icons for you — the artwork must carry its own squircle with transparent corners, which is exactly what oneagent-app-icon-512.png does (4.4% transparent, corners fully clear). Wails generate icons only converts formats; it does not add rounding.

Use the plated site asset as the source, upscaled to 1024×1024, rather than compositing something new.

2. Windows and Linux icons are not generated at all

build/Taskfile.yml:62-71 has one icon task:

{{.WAILS3}} generate icons -input appicon.png -macfilename darwin/icons.icns -windowsfilename ""

-windowsfilename "" explicitly skips the Windows icon, and there is no .ico anywhere in the repo. build/windows/Taskfile.yml builds the binary with -H windowsgui and no icon step; build/linux/Taskfile.yml has none either.

OneAgent ships Windows x64 and ARM64 artifacts. Right now those binaries carry the default executable icon. Adopting the new logo is the natural moment to fix this: pass a real -windowsfilename and commit the .ico.

3. Below about 20px the ring and the inner form merge

Scaling the measured proportions down gives the actual pixel budget:

Target	Ring stroke	Ring→inner gap	Inner stroke	Inner leg gap
16px	1.7px	2.0px	1.9px	2.3px
20px	2.1px	2.5px	2.4px	2.9px
32px	3.4px	4.0px	3.8px	4.7px
38px (sidebar)	4.0px	4.8px	4.5px	5.6px
64px (favicon)	6.8px	8.0px	7.6px	9.4px

At 38px and above every feature has 4px or more, which is comfortable. At 20px the separating gaps are down to 2.5px and hold only with careful antialiasing. At 16px every feature is under 2.4px, so the ring, the gap, and the inner form each land on roughly two pixels — they blend, and the mark reads as a filled blob rather than a ring with something inside it.

I confirmed this empirically as well as arithmetically: downscaling the 256px asset to 16×16 and inspecting the alpha map shows the inner form losing separation from the ring.

Two places this bites:

• Windows taskbar and Explorer render 16×16 from the .ico. A mechanical downscale will be mud.
• The favicon is 64×64 but browsers display it at 16×16, and it already measures 33.5% partial alpha — heavy antialiasing, consistent with detail being on the edge.

The .ico needs a hand-tuned 16×16: thicken the strokes, widen the gaps, or drop the inner form and ship the ring alone. Per-size artwork inside an .ico is standard practice, and these numbers say this mark requires it rather than merely benefiting from it.

4. The mark's blue matches the light theme exactly and the dark theme not at all

#007AFF is character-for-character --blue: #007aff in frontend/src/styles/tokens.css:26. In dark mode that token becomes #0a84ff (:89, :129).

So a hardcoded #007AFF mark in the sidebar will be visibly off-brand against every other blue element in dark mode. Two options:

• Preferred: single-colour SVG using currentColor, so it inherits whatever the theme sets. This is the approach NOTICE:62 already records for the Agent marks, and the mark qualifies — it is one flat colour with no gradient.
• Otherwise ship two rasters and switch on theme, which is more files and more drift.

Note the sidebar plate helps here: .brand-mark (frontend/src/styles/app.css:35-43) is a 38×38 box with --window-bg background and a --border-strong border, so the mark sits on a theme-aware surface either way.

5. Everything is raster; the app would benefit from a vector

There is no SVG version of the logo in the site repo — all five assets are PNG. Four of the five existing Agent marks in frontend/src/components/icons/agents.tsx are SVG, and the one raster exception only exists because that vendor publishes no vector. Introducing a raster for our own mark would be odd, and it forecloses currentColor theming.

Ask whoever produced the logo for the source vector. It is a small ask now and it removes the theming problem, the small-size problem, and the packaged-size problem at once. Vite inlines every asset (assetsInlineLimit: Number.MAX_SAFE_INTEGER), so a 17KB PNG becomes 17KB of base64 in the bundle where an SVG would be a fraction of that.

6. Three copies of the same file in the site repo

public/images/logo, public/images/logo.png, and public/images/brand/oneagent-logo.png are all byte-identical — sha256 efefa20e… for each. Only the brand/ path is referenced (BrandMark.astro:6); the two at public/images/ are untracked strays.

This is worth cleaning up in the site repo before this work starts, because three paths holding the same bytes is exactly how a later edit updates one and leaves the app copying a stale one. Keep brand/oneagent-logo.png as the single master.

Work items

In this repo:

1. Replace build/appicon.png with a 1024×1024 upscale of the plated icon, preserving transparent corners.
2. Regenerate build/darwin/icons.icns via task generate:darwin:icon. It is stale the moment the PNG changes.
3. Add Windows icon generation. Replace -windowsfilename "" in build/Taskfile.yml:71 with a real path, commit the .ico, and wire it into build/windows/Taskfile.yml. Include a hand-tuned 16×16 in the .ico.
4. Decide on a Linux icon. build/linux/Taskfile.yml has no icon step; check whether the Linux artifact needs one.
5. Replace <Boxes> in frontend/src/components/NavigationSidebar.tsx:21-23 with the mark. Prefer an inline SVG component using currentColor.
6. Verify both themes. frontend/src/styles/agent-mark.test.ts and cascade.test.ts exist as precedent for asserting mark styling.

Compliance — do not skip:

7. This is first-party artwork, so it does not go in asset-rights.json as third-party material (that file tracks the five vendor Agent marks with hashes verified by scripts/generate_third_party_licenses.py:210-246). But NOTICE:40-62 currently describes the icon inventory as vendor marks from lobe-icons plus the OpenClaw derivative. Adding a first-party brand mark must not silently make that description wrong.
   The licence generator only diffs third_party/ — it does not check NOTICE prose, which has drifted before. Re-read NOTICE after this change and confirm it is still true.

Cross-repo:

8. The two repos should not diverge. If the app icon is regenerated from a different source than the site's, they will drift. Decide which repo owns the master artwork — the site repo already has the full set, so it is the natural home — and record where it lives.
9. Delete the stray extensionless public/images/logo in the site repo.

Open question

Is there a source vector? If yes, items 3 and 5 get materially easier and the small-size problem largely goes away. If no, the 16×16 .ico entry and the dark-mode variant both need hand work, and that should be scoped in before starting.

Priority

P2, raised from P3. It is no longer a design task waiting on a decision — the logo exists and the app is shipping with a stock placeholder in its most visible chrome plus a default icon on Windows.