Found via on-device testing after the earlier warm-palette commit: the
View/Guided/Raw SegmentedButton's selected segment rendered in Flutter's
stock Material teal, not the warm palette. Neither ColorScheme.light()
nor .dark() defined secondary/tertiary (or their container/on- variants),
so any M3 widget reaching for secondaryContainer (SegmentedButton, Chips,
etc.) silently fell back to the framework default instead of erroring --
a gap invisible in static review or widget tests, only visible rendered.
The shared palette has one accent, not a separate secondary hue, so these
mirror primary; secondaryContainer/tertiaryContainer use the line-light/
line-dark border color as a distinguishable-but-subtle selected-state fill.
Verified: flutter analyze clean, 188/188 tests at 100% coverage, re-
verified identical in an isolated worktree, and confirmed live on the
physical phone (adb install -r + screenshot) -- the Raw tab now renders
gold/amber instead of teal.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Replaces the inline ColorScheme.fromSeed(Colors.deepPurple) theme with a new
lib/ui/theme.dart built from explicit light/dark ColorSchemes on the frozen
unified-design-system tokens (same shared spacing/radius/type-scale constants
as diet-guard/habit_stack's theme.dart), and adds darkTheme (previously
absent).
Fixes 2 of 3 violations in DESIGN_AUDIT_TODO.md:
- settings_screen.dart's one hardcoded Colors.red -> colorScheme.error,
matching every other error-state text in the app
- markdown_view.dart and note_editor.dart's raw-mode TextField now cap their
reading/editing column at kProseMaxWidth (640) via Center+ConstrainedBox --
the desktop build is an arbitrarily wide Chrome --app window, so text was
running the full viewport. Deliberately no extra Column introduced around
the raw-mode TextField, per its own documented expands:true/nested-Column
regression history.
The 3rd violation (a few off-scale SizedBox/EdgeInsets values, e.g. 6px vs
the file's dominant 4px scale) was attempted but reverted: bumping the
_EnumChips/_MultiChips/_DateRangeField 6px gaps to 8px broke 3 real tests --
the filter bottom sheet's "Apply" button is tight enough against its edge
that even a 2px shift pushes it out of the hit-testable area. Not worth
trading a working control for a cosmetic 2px scale nitpick; left at 6px.
Verified: flutter analyze clean, dart format clean on all touched files,
188/188 tests passing (added test/theme_test.dart for the new file, which
had 0% coverage on its own), 100% total line coverage maintained, re-verified
identical in an isolated worktree at HEAD (narrowly staged around this
repo's own pre-existing uncommitted CLAUDE.md edit, left untouched). A
Flutter-web headless-Chrome screenshot check for the desktop target was
attempted but blocked by a CanvasKit/WebGL rendering issue in this sandbox,
unrelated to the app itself; the widget test suite (which does catch real
RenderFlex overflow, as confirmed during this same rollout) passed clean for
both touched screens instead. Mobile on-device verification (phone-deploy)
is pending -- the phone isn't connected via ADB right now.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
