aterm app icons make the role palette a durable artifact, not just a window colour #363

New issue

Open

opened 2026-08-26 09:12:15 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-26 09:12:15 +00:00

Member

Per-role icons are being made for the seven macOS .app bundles aterm bundles writes. They render this repository's contract, so the decision has a stake here even though no code change is asked for yet.

consumer, the bundle generator: coilyco-flight-deck/agentic-os#1282
the art itself: coilyco-bridge/agentic-os-xxx#45

What the icons consume

favorite_color, plus for each personality in the meld an emblem (name, emoji, glyph) and a form (silhouette, geometry, motion). That is the same material native-ui already renders as a theme, and the same material aterm's identity card draws from and animates on. Icons are the third renderer of it.

They inherit #358, and harder

#358 measured 18 of 21 role pairs below the side-by-side JND as window backgrounds, and noted those windows are never side by side. Icons are the case that breaks that mercy: seven tiles sit in one Finder window and one Dock, literally side by side, at a fraction of a window's size. A colour separation that is marginal at full-window scale will not survive at 32 px.

So the icons should consume whatever separated palette #358 lands, not raw favorite_color. Producing art against today's values first would mean redrawing it.

They are the first consumer that persists

Every renderer so far recomputes from the catalogue each time it runs, so a palette change is picked up by the next launch and nothing goes stale. A committed .icns does not work that way. Once art exists, changing a role's colour, silhouette, or geometry invalidates files rather than just re-rendering a window.

That is worth weighing in #358's rollout, and it is really a question this repo should answer for the consumers: is the icon set generated at bundle time from live values, staying correct by construction, or produced once and committed, needing regeneration discipline whenever the catalogue moves? The first keeps this contract authoritative. The second makes a catalogue change a cross-repo chore.

Ask

No change requested here yet. This is the pointer so #358 is solved knowing it now has a downstream consumer whose output is durable, and so the ordering is deliberate rather than discovered after seven icons are drawn.

Per-role icons are being made for the seven macOS `.app` bundles `aterm bundles` writes. They render this repository's contract, so the decision has a stake here even though no code change is asked for yet. - consumer, the bundle generator: https://forgejo.coilysiren.me/coilyco-flight-deck/agentic-os/issues/1282 - the art itself: https://forgejo.coilysiren.me/coilyco-bridge/agentic-os-xxx/issues/45 ## What the icons consume `favorite_color`, plus for each personality in the meld an `emblem` (name, emoji, glyph) and a `form` (silhouette, geometry, motion). That is the same material `native-ui` already renders as a theme, and the same material aterm's identity card draws from and animates on. Icons are the third renderer of it. ## They inherit #358, and harder #358 measured 18 of 21 role pairs below the side-by-side JND as window backgrounds, and noted those windows are never side by side. Icons are the case that breaks that mercy: seven tiles sit in one Finder window and one Dock, literally side by side, at a fraction of a window's size. A colour separation that is marginal at full-window scale will not survive at 32 px. So the icons should consume whatever separated palette #358 lands, not raw `favorite_color`. Producing art against today's values first would mean redrawing it. ## They are the first consumer that persists Every renderer so far recomputes from the catalogue each time it runs, so a palette change is picked up by the next launch and nothing goes stale. A committed `.icns` does not work that way. Once art exists, changing a role's colour, silhouette, or geometry invalidates files rather than just re-rendering a window. That is worth weighing in #358's rollout, and it is really a question this repo should answer for the consumers: is the icon set generated at bundle time from live values, staying correct by construction, or produced once and committed, needing regeneration discipline whenever the catalogue moves? The first keeps this contract authoritative. The second makes a catalogue change a cross-repo chore. ## Ask No change requested here yet. This is the pointer so #358 is solved knowing it now has a downstream consumer whose output is durable, and so the ordering is deliberate rather than discovered after seven icons are drawn.

coilyco-ops referenced this issue from coilyco-flight-deck/agentic-os

2026-08-26 09:12:32 +00:00

aterm bundles: per-role icons instead of the generic system icon #1282

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

coilyco-flight-deck/agent-compose#363

No description provided.

Rows
Columns