ho-06.4 — palana palette: the semantic color-token layer

Give the Workshop a real palette. Today the app leans on the raw macOS system accent (usually blue) and scatters .red / .green / .secondary across the views. This ho replaces that with a small named token layer that maps the pālana design system palette to semantic roles — accent, drift, in-sync, ink text, surfaces — wired through the existing AppAppearance light/dark/system override.

It is a foundation ho: it changes no behavior and adds no feature. It exists so the upcoming right-side-panel ho (the failed-at-gate chrome from ho-06.2, owed forward-only) has a clean panelGround and a coherent accent to build on, and so Sharibako and pālana read as siblings rather than two apps that happened to pick similar greens.

Numbering. Provisional 06.4, to be ratified in the owed K4 overview pass (the panel, multi-root management, and first-run/ingest hos are all still unplaced). The panel ho follows as 06.5 there. This number lets the work start now; it does not pre-empt the K4 pass.

Out of scope:

• The right-side collapsible panel itself — the next ho (06.5). This one only hands it tokens.
• Typography, spacing, radii, and motion. pālana specifies all of these too; this ho is color only. A later pass can consume the rest.
• Flattening the vibrancy materials. .bar and .quaternary (translucent system materials) stay as-is — see Decision 4. The panel ho makes the holistic flat-vs-vibrancy call across the whole window.
• Editing pālana. The palette is read as the source of truth; zero files under ../../../palana/ change. The dark values designed here (Decision 2) are documented in a form portable back to pālana, but that upstreaming is a separate pālana-side decision, not this ho.
• Any change under Sources/SharibakoCLI/ or Sources/SharibakoCore/ — pure app-layer, same rule as ho-05 / 06.1 / 06.2. The CLI has no color.

Phase 1 — Think

Four decisions, ratified 2026-07-11.

Decision 1 — Nine semantic tokens, not a palette dump

The view code should never name a hue. It names a role. The token set:

pālana's optional plugin/umber is dropped: Sharibako has no category axis (pālana §8 explicitly permits this). That keeps us at pālana's three working hues — paper, ink, moss — plus the single rust alarm voice.

Decision 2 — pālana is light-only; the dark set is designed here (as siblings, portable upstream)

pālana §2 gives only light values (warm paper ground, near-black ink). Sharibako must read well in both appearances (the AppAppearance override is live). So the dark half of every token is new design, in pālana's spirit — warm throughout, never pure black or white, one moss accent, one rust alarm, lifted just enough to hold contrast on a dark ground.

These dark values are the candidate to bring pālana in line later; they are written here so that a future pālana dark section can adopt them verbatim. pālana files are not touched in this ho.

Decision 3 — Colorblind-safety is unchanged: shape stays primary

inSync moss vs drift rust is a red/green axis — the exact thing the standing constraint guards. It holds because color stays secondary: the sidebar glyphs and drift badges keep their shape distinction (mappin.circle.fill vs arrow.up.forward.circle; checkmark.seal vs exclamationmark.triangle.fill) and their neutral inkSecondary fill. Only transient status pulses and text labels carry the moss/rust tint, and each of those also carries a word ("In sync" / "Differs") or a shape. No state is distinguishable by hue alone. The glyph/badge colors are therefore not migrated to moss/rust — they stay neutral, as ho-06.2 designed them.

Decision 4 — Migrate text + accent + status now; keep the vibrancy materials

Scope of the swap this ho performs:

• Accent — set the app .tint to accentMoss (was: unset → system blue); .accentColor usages → accentMoss. .borderedProminent CTAs inherit the tint automatically, so primaryActionButton() flips to moss with no change.
• Status — all .red → drift; the one Color.green → inSync.
• Text — .secondary → inkSecondary, .tertiary → inkTertiary.
• Kept as-is — the .bar and .quaternary materials (translucent, already appearance-adaptive) and the ground* tokens' consumption. Replacing vibrancy with flat palette grounds is the visible "notebook-over-Mac" move; it wants to be made holistically in the panel ho, across the whole window, not piecemeal here. The surface tokens are defined now so the panel can consume them; the existing materials are left now so this foundation stays low-risk in both appearances.

Mechanism

Color+Theme.swift — a Color extension over an internal Theme/Palette layer. Each token is an appearance-aware color built with NSColor(name:dynamicProvider:): no asset catalog, no Package.swift resource change, and — because the raw values live in a pure Palette.resolved(dark:) seam — unit-testable without a running scene. The file carries real coverage and is therefore not added to the CI exclusion list.

Tokens are named Color.accentMoss etc. and used explicitly (Color.drift, not .drift) because foregroundStyle(_: some ShapeStyle) won't resolve a leading-dot member against the generic parameter.