bvandeusenandClaude Opus 5
b91091caca
CI & Build / Build now, or wait for Android? (push) Successful in 3s
CI & Build / Python lint (push) Successful in 3s
CI & Build / TypeScript typecheck (push) Successful in 11s
CI & Build / Python tests (push) Successful in 13s
CI & Build / integration (push) Successful in 19s
CI & Build / Build & push image (push) Skipped
Desktop (Tauri) / Windows installer (cross-compiled) (push) Successful in 2m54s
Desktop (Tauri) / Tauri desktop (Linux) (push) Successful in 5m15s
Desktop (Tauri) / Update manifest (push) Successful in 4s
Android / Kotlin + Rust (APK) (push) Successful in 7m59s
A card's fill stops being a function of the note. One neutral per theme on all three surfaces — white in light, neutral-900 in dark, which is what the palette's `default` always was and what both editors already used, so this is a collapse onto a surface everything already had rather than a colour anybody has to like. Measured, against "not the same color as their background but close to it": card vs board 1.04 light / 1.10 dark, edge vs card 1.98 / 1.73, body text 17.93 / 17.17, muted 10.37 / 14.23. The fill is deliberately the weakest number on the card — the edge and the shadow separate it from the board, so a fill that separated on its own would make it a panel. Deleted, since the card was their only consumer: `derivedFill` / `hslHex` and the level tables in colors.ts, `derivedFillArgb` / `hslToArgb` in DerivedTint.kt, `NOTE_CARD_CLASSES_STRONG`, `chosenNoteColor`, `noteCardClasses`, `noteTintVars`, the `.note-tint` rule in style.css, `chosenBackground` / `tintable` / `noteTintFor` / `noteCardColor` / `noteIsStrong` / `firstLabelColor` in NoteTint.kt, and `resolvedNoteColor` / `noteColorIsChosen`. `tintHash` and `derivedTint` STAY, against the plan: a label with no colour of its own still derives one from its name, and that path was never the one that failed. The mirrored pair and its fixture survive intact. The editor follows the card, and its Done button takes the brand — the board's compose FAB is the app's existing statement of "affirmative action here", where Material's default secondaryContainer is a baseline colour this theme never sets. The colour picker is left in place, doing nothing, for exactly one step: removing it here would leave `note.color` written by nothing and read by nothing, which is a worse intermediate than a control that visibly does nothing. #3041 takes the field and the picker together. Step 1 of M315. #3148 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>