Per-scheme view of how Aaron UI decodes the active scheme. The four windows above are the live render; everything below is the data behind it — chrome cicns with parts/recipe overlays, the wnd# entries, the parts table, and the full extracted catalog.
Period rendering of the scheme — what the author actually saw on the classic Mac. Mass:werk schemes have curated thumbnails on file; exotic schemes link out to the Kaleidoscope Scheme Archive.
Each chrome state cicn at 4× scale. Toggle overlays to see how the renderer interprets the bitmap. Hover the ⓘ icons for what each overlay shows and why it matters.
For each side: list of {at, part} entries. at is the cicn-pixel position along the side axis. part matching a slug in the parts table = named; not in the table = fill (tiles cicn pixels in the segment).
Slugs referenced by recipe entries. Each rect [left, top, right, bottom] in cicn pixels.
How many extracted assets does Aaron UI actually consume? See architecture spec and spec A §23 for conformance levels.
Live walk of the first demo window's DOM tree, annotated with which recipe entry / cicn part / chromeElement each chrome-related element came from. Use this to verify "this wnd# data → this DOM element" without guessing.
Per spec B §4.16-§4.18, Kaleidoscope schemes carry explicit pixel coordinates in each cinf (Background/Text/Embossing) at which the renderer samples colors. This panel calls extractColorsFromCicn() on every chrome element whose cinf provides a bgAnchor. See disassembly findings §3 for how we discovered this.
Every cicn the extractor decoded from the scheme's resource fork — not just document-window chrome. Click any thumb to open the raw PNG.