Mutable. Part 1.

A NotifierProvider — the mode is mutable (the user changes it). A plain Provider is read-only and can't be reassigned from the UI.

build() + state =.

class ThemeModeNotifier extends Notifier<ThemeMode> {
  @override ThemeMode build() => ThemeMode.system;
  void setMode(ThemeMode m) => state = m;
}
final themeModeProvider = NotifierProvider<ThemeModeNotifier, ThemeMode>(ThemeModeNotifier.new);

Initial state.

The initial ThemeMode — typically ThemeMode.system, the respectful default.

watch → themeMode.

final mode = ref.watch(themeModeProvider);
MaterialApp(theme: light, darkTheme: dark, themeMode: mode, home: const HomePage());

(Root is a ConsumerWidget, wrapped in ProviderScope.)

Root.

A ProviderScope at the very top (runApp(const ProviderScope(child: App()))).

Rebuild on change.

It must rebuild with the new themeMode whenever the mode changes; watch subscribes it, read would grab a stale one-time value.

read(.notifier).

onPressed: () => ref.read(themeModeProvider.notifier).toggle(),

watch + read.

ref.watch for the current mode (so the icon updates); ref.read(provider.notifier).toggle() inside onPressed for the action.

SegmentedButton + setMode.

SegmentedButton<ThemeMode>(
  segments: const [
    ButtonSegment(value: ThemeMode.light, label: Text('Light')),
    ButtonSegment(value: ThemeMode.dark, label: Text('Dark')),
    ButtonSegment(value: ThemeMode.system, label: Text('System')),
  ],
  selected: {ref.watch(themeModeProvider)},
  onSelectionChanged: (s) => ref.read(themeModeProvider.notifier).setMode(s.first),
);

Inherited theme.

MaterialApp rebuilds with the new mode, swapping the active ThemeData; widgets that read theme roles via the inherited Theme rebuild and re-read the new scheme.

Act, not subscribe.

A callback should act (call a method), not subscribe. read(provider.notifier) fetches the notifier once; watch-ing it just to call a method is the anti-pattern.

Ternary on state.

void toggle() => state = state == ThemeMode.dark ? ThemeMode.light : ThemeMode.dark;

Talks to the provider.

It calls ref.read(themeModeProvider.notifier).setMode(...) — talking to the provider, not a parent. MaterialApp separately watches the same provider and rebuilds. No onThemeChanged prop-drilling.

No reactivity.

Changing it doesn't rebuild anything — no reactivity. You'd bolt on a ChangeNotifier and reinvent providers.

Prop-drilling.

setState keeps the mode in one widget's State, so any descendant changing it needs an onThemeChanged callback prop-drilled down. NotifierProvider makes the mode globally readable/mutable via ref, with automatic scoped rebuilds — and sets up cleanly for persistence/testing.

ProviderScope + ConsumerWidget.

void main() => runApp(const ProviderScope(child: App()));
class App extends ConsumerWidget {
  const App({super.key});
  @override
  Widget build(BuildContext c, WidgetRef ref) => MaterialApp(
    theme: light, darkTheme: dark,
    themeMode: ref.watch(themeModeProvider), home: const HomePage());
}

Override.

The mode lives in an overridable provider; tests can override it (or the notifier) in a ProviderScope/ProviderContainer and assert without driving real UI.

Mutate from below.

It's lots of boilerplate and awkward to mutate from descendants; NotifierProvider gives clean read+mutate from anywhere with ref.

State / watch / change.

ThemeMode is state (a NotifierProvider), MaterialApp watches it, and any widget can change it.

overrideWith.

ProviderScope(
  overrides: [
    themeModeProvider.overrideWith(() => _FakeMode(ThemeMode.dark)),
  ],
  child: const App(),
);

(or override the notifier with a fake that builds ThemeMode.dark).

Small KV. Part 2.

Good for small primitive key-value settings (theme choice, flags, username); not for large/structured data — use a database/files.

mode.name.

Write mode.name ('light'/'dark'/'system'); read the string and map back, defaulting to ThemeMode.system.

await on build.

Initialization depends on storage; getInstance() is async, so build() is async and state is modeled as AsyncValue (the "if build() awaits, use AsyncNotifier" rule).

getString → enum.

ThemeMode read() => switch (_prefs.getString('themeMode')) {
  'light' => ThemeMode.light,
  'dark' => ThemeMode.dark,
  _ => ThemeMode.system,
};

Async.

AsyncValue<ThemeMode> (loading / data / error).

UnimplementedError.

final sharedPrefsProvider = Provider<SharedPreferences>(
  (ref) => throw UnimplementedError('Override in ProviderScope'));

await getInstance.

final prefs = await SharedPreferences.getInstance();
ProviderScope(overrides: [sharedPrefsProvider.overrideWithValue(prefs)], child: const App());

(plus WidgetsFlutterBinding.ensureInitialized().)

Sync downstream.

Doing the one unavoidable async load once makes every downstream read synchronous and keeps the store injectable/overridable (testable), avoiding repeated async calls.

AsyncData first.

Future<void> setMode(ThemeMode m) async {
  state = AsyncData(m);                                  // optimistic
  await ref.read(themeRepositoryProvider).write(m);      // persist
}

Instant UI.

So the UI flips immediately instead of waiting on the disk write (a few ms); the write persists a moment later. No perceived latency.

watch repo.read().

@override
Future<ThemeMode> build() async => ref.watch(themeRepositoryProvider).read();

Seam.

It isolates storage behind a testable seam — swap stores or inject a fake repository in tests without touching notifier logic.

valueOrNull ?? system.

final mode = ref.watch(themeModeProvider).valueOrNull ?? ThemeMode.system;

Non-blocking.

A theme is non-blocking; rendering with system and snapping to the saved value (usually the same frame, since prefs are pre-loaded) is smoother than gating the app behind a spinner for one setting.

valueOrNull.

Future<void> toggle() async {
  final cur = state.valueOrNull ?? ThemeMode.system;
  await setMode(cur == ThemeMode.dark ? ThemeMode.light : ThemeMode.dark);
}

try/catch around write.

Keep the optimistic state = AsyncData(mode), wrap await write(mode) in try/catch. On failure, either surface a transient snackbar (keep the new look) or revert and set state = AsyncError(e, st) — for a theme, a non-fatal snackbar while keeping the change is usually best.

Other settings.

Any persisted setting — locale, onboarding flags, auth tokens, feature toggles. The pattern is universal.

Offline persistence.

Built-in offline persistence — providers can cache/restore their state locally automatically. Doing it manually once teaches what it's doing under the hood.

Override repo.

final c = ProviderContainer.test(overrides: [
  themeRepositoryProvider.overrideWithValue(FakeThemeRepository(ThemeMode.dark)),
]);
expect(await c.read(themeModeProvider.future), ThemeMode.dark);

Stable across reorders.

name is a stable string ('dark') that survives reordering or inserting enum values; an index would silently change meaning if the enum's order changed, corrupting saved preferences.

Just a rebuild. Part 3.

It's a rebuild: changing the active ThemeData updates the inherited Theme, and dependent widgets rebuild with new values in a frame. The tree persists; only read values change.

Subscribe.

It subscribes the widget to the inherited theme, so it rebuilds when the theme changes.

state → MaterialApp → Theme → widgets.

toggle() → state changes → MaterialApp (watching) rebuilds with new themeMode → installs dark ThemeData → widgets reading Theme.of(context) rebuild with dark roles → repaint.

Root + control.

Essentially just the root MaterialApp (to set themeMode) plus any control showing the current mode. Leaves read Theme.of(context).

select.

final isDark = ref.watch(themeModeProvider.select((m) => m == ThemeMode.dark));

Skip + narrow.

const subtrees are canonicalized and skipped during rebuilds; select narrows a subscription to a derived slice so the widget rebuilds only when that slice changes.

AnimatedTheme.

AnimatedTheme(
  data: Theme.of(context),
  duration: const Duration(milliseconds: 250),
  child: const Body(),
)

Wraps in AnimatedTheme.

Yes — it wraps the app in an AnimatedTheme, so top-level changes cross-fade by default; you can wrap a subtree for a custom duration/curve.

Double-subscribe.

The inherited theme already rebuilds theme-reading widgets; watching the provider too is redundant double-subscription. Read the theme, not the mode provider, in leaves.

TweenAnimationBuilder + ColorTween.

TweenAnimationBuilder<Color?>(
  tween: ColorTween(end: Theme.of(context).colorScheme.surface),
  duration: const Duration(milliseconds: 300),
  builder: (c, color, child) => Container(color: color, child: child),
  child: const Content(),
)

Sluggish vs polished.

A long fade on a theme change feels sluggish, not smooth; short transitions read as "polished," not "showy."

debugPrint in build.

Widget build(BuildContext c, WidgetRef ref) {
  debugPrint('rebuilt');
  final s = Theme.of(c).colorScheme; // subscribes → prints on each toggle
  return Container(color: s.surfaceContainerHigh);
}

A pure const Text('Hi') won't be forced to rebuild.

Subscribe in build.

The theme subscription is established by reading Theme.of(context) during build (via dependOnInheritedWidgetOfExactType). Reading in initState captures a one-time value (and is discouraged). Move the read into build so it re-subscribes and re-reads on each change.

Hardcoded or captured.

It hardcoded a color (replace with a scheme role), or it captured the color outside build (read Theme.of(context) in build instead).

Big non-const watcher.

A large non-const subtree watches the theme unnecessarily. const the static parts and read the theme narrowly so only dependent widgets rebuild.

valueOrNull.

themeMode: ref.watch(themeModeProvider).valueOrNull ?? ThemeMode.system,

ConsumerWidget / ProviderScope.

The root isn't a ConsumerWidget (so it doesn't ref.watch), or it isn't under a ProviderScope. Fix both.

Decoupled.

One provider subscription at the root drives a whole tree of theme-reading widgets; the provider concern and the theme concern stay decoupled, and leaves don't know a provider drives the theme.

Theme.of only.

class PriceTag extends StatelessWidget {
  const PriceTag({super.key});
  @override
  Widget build(BuildContext c) =>
      Text('\$9', style: TextStyle(color: Theme.of(c).colorScheme.primary));
}

const + narrow + select.

const static subtrees, read the theme narrowly (only the root watches the mode), and use select for derived slices.

OS vs override. Part 4.

The OS brightness and the user's ThemeMode. A light/dark override wins; the OS only applies in system mode.

platformBrightnessOf.

final os = MediaQuery.platformBrightnessOf(context); // Brightness.light/dark

Rebuild on OS change.

Yes — widgets reading it rebuild when the user changes the OS setting while the app is open.

No context.

It needs a BuildContext, which providers don't have. Bridge it via a WidgetsBindingObserver notifier (or push from a widget).

addObserver + didChangePlatformBrightness.

class PlatformBrightnessNotifier extends Notifier<Brightness> with WidgetsBindingObserver {
  @override
  Brightness build() {
    final b = WidgetsBinding.instance;
    b.addObserver(this);
    ref.onDispose(() => b.removeObserver(this));
    return b.platformDispatcher.platformBrightness;
  }
  @override
  void didChangePlatformBrightness() =>
      state = WidgetsBinding.instance.platformDispatcher.platformBrightness;
}

didChange…

WidgetsBindingObserver.didChangePlatformBrightness() — read platformDispatcher.platformBrightness and assign to state.

removeObserver onDispose.

Remove its observer when disposed: ref.onDispose(() => WidgetsBinding.instance.removeObserver(this));. Otherwise it leaks past the provider's life.

switch on mode.

final effectiveBrightnessProvider = Provider<Brightness>((ref) {
  final mode = ref.watch(themeModeProvider).valueOrNull ?? ThemeMode.system;
  return switch (mode) {
    ThemeMode.light => Brightness.light,
    ThemeMode.dark => Brightness.dark,
    ThemeMode.system => ref.watch(platformBrightnessProvider),
  };
});

Override beats OS.

If mode is light/dark, that override sets the brightness (OS ignored); if system, effective brightness equals the OS brightness. It recomputes when either input changes.

watch effective.

final isDark = ref.watch(effectiveBrightnessProvider) == Brightness.dark;
return Image.asset(isDark ? 'assets/logo_light.png' : 'assets/logo_dark.png');

Ignores override.

Forced-dark users on a light OS get light-mode assets/colors in your custom widgets (even though MaterialApp is dark), because the in-app override was ignored. Resolve through the effective provider.

Rendering logic.

For rendering logic, almost always — MaterialApp already resolved themeMode, so it reflects the effective theme. Use the providers when non-widget logic needs the answer.

Three APIs.

MediaQuery.platformBrightnessOf(context); Theme.of(context).brightness; ref.watch(effectiveBrightnessProvider).

darkTheme.

A non-null darkTheme — system detection is pointless without a dark theme to switch to.

Pure function.

It's a pure function of two reactive inputs with no mutable state of its own; a computed Provider that watches both recomputes whenever either changes. A Notifier would add needless mutable state to keep in sync.

MediaQuery.

Skip the notifier entirely and call MediaQuery.platformBrightnessOf(context) — it's already reactive. The notifier is only needed when other providers depend on OS brightness.

Either input.

When the mode changes (user picks light/dark/system) or, in system mode, when the OS brightness flips — because it watches both inputs.

read in a method.

final b = ref.read(effectiveBrightnessProvider);
analytics.log('theme', {'dark': b == Brightness.dark});

Graph propagation.

The provider derives from both themeModeProvider and platformBrightnessProvider; Riverpod recomputes and re-notifies it whenever either changes, so the watching logo always reflects the true effective brightness.

OS notifier + derived effective.

Bridge OS brightness into a WidgetsBindingObserver notifier (with onDispose cleanup) and resolve it against the user's ThemeMode in a derived effectiveBrightnessProvider, watched by any logic that needs "is the app effectively dark."

Subtree only. Part 5.

It applies the overrides only to that subtree; descendants see overridden values, the rest of the app keeps the originals.

Need something to override.

You can only override something that comes from a provider; sourcing the seed/theme from a provider gives a handle to override per subtree.

fromSeed.

final seedProvider = Provider<Color>((ref) => const Color(0xFF6750A4));
final lightThemeProvider = Provider<ThemeData>(
  (ref) => themeFor(ref.watch(seedProvider), Brightness.light));

overrideWithValue.

ProviderScope(
  overrides: [seedProvider.overrideWithValue(const Color(0xFFB8860B))],
  child: const PremiumThemed(),
)

Scope + Theme.

The nested ProviderScope override (changes what theme providers compute) and a local Theme widget (changes what Theme.of(context) returns for Material widgets in the subtree).

Theme(data: watch(...)).

final theme = Theme.of(context).brightness == Brightness.dark
  ? ref.watch(darkThemeProvider) : ref.watch(lightThemeProvider);
return Theme(data: theme, child: const PremiumBody());

Widgets only.

When only widgets (via Theme.of(context)) consume the local theme — no provider logic depends on the overridden seed/brand.

local Theme dark.

Theme(
  data: themeFor(const Color(0xFF6750A4), Brightness.dark),
  child: const ViewerBody(),
)

The global themeModeProvider is untouched.

Local Theme only.

It wraps the subtree in a local Theme with dark ThemeData; Theme.of(context) returns dark only inside that subtree — MaterialApp/themeModeProvider are unchanged.

Compute vs return.

The scope override changes what the theme providers compute (gold seed); the Theme widget changes what Theme.of(context) returns so standard widgets actually render gold. Different layers.

watch seedProvider.

final seed = ref.watch(seedProvider); // gold inside the nested scope, purple outside

Scoping.

Nested ProviderScope scoping/overrides — the same mechanism Riverpod uses for all scoped state.

Whitelabel logic.

A whitelabel partner flow where logic (not just colors) depends on the brand: analytics tags, a logo provider, copy/string providers and the theme all read brandProvider/seedProvider. A nested scope overriding brandProvider makes every provider in that branch compute partner-specific values; a local Theme would only re-skin Material widgets.

List of overrides.

ProviderScope(
  overrides: [
    seedProvider.overrideWithValue(partnerSeed),
    brandProvider.overrideWithValue(partnerBrand),
  ],
  child: const PartnerFlow(),
)

Most needs are local Theme.

Most "this screen looks different" needs are just a local Theme; reaching for a ProviderScope override when no provider logic depends on the value adds needless complexity. Reserve it for genuine per-feature provider state.

And yet.

Global mode (P1), persisted (P2), live-switched (P3), OS-resolved (P4) — and yet any subtree can opt out with a local override (P5). Global by default, local where needed.

watch light/dark theme providers.

MaterialApp(
  theme: ref.watch(lightThemeProvider),
  darkTheme: ref.watch(darkThemeProvider),
  themeMode: ref.watch(themeModeProvider).valueOrNull ?? ThemeMode.system,
  home: const HomePage());

Providers change, widgets don't.

The theme providers recompute from the new seed inside the scope, but standard Material widgets still read the ancestor Theme (unchanged), so they don't re-skin. You need the local Theme to feed the recomputed ThemeData into Theme.of(context).

Who consumes it.

If only widgets consume the local theme (Theme.of(context)), use a plain local Theme. If providers in the subtree must also see the overridden value, use a nested ProviderScope override (plus a local Theme for rendering).

State → persist → switch → resolve → scope.

ThemeMode is a (persisted) NotifierProvider/AsyncNotifier watched by MaterialApp, switched live via the inherited theme, resolved against the OS in a derived effectiveBrightnessProvider, and overridable per subtree with nested ProviderScope — global by default, local where needed.

class ThemeModeNotifier extends Notifier<ThemeMode> {
  @override ThemeMode build() => ThemeMode.system;
  void setMode(ThemeMode m) => state = m;
  void toggle() => state = state == ThemeMode.dark ? ThemeMode.light : ThemeMode.dark;
}
final themeModeProvider = NotifierProvider<ThemeModeNotifier, ThemeMode>(ThemeModeNotifier.new);
// MaterialApp(themeMode: ref.watch(themeModeProvider), ...)

final isDark = ref.watch(themeModeProvider) == ThemeMode.dark;
IconButton(
  icon: Icon(isDark ? Icons.light_mode : Icons.dark_mode),
  onPressed: () => ref.read(themeModeProvider.notifier).toggle());

class ThemeRepository {
  ThemeRepository(this._p); final SharedPreferences _p;
  ThemeMode read() => switch (_p.getString('themeMode')) {
    'light' => ThemeMode.light, 'dark' => ThemeMode.dark, _ => ThemeMode.system };
  Future<void> write(ThemeMode m) => _p.setString('themeMode', m.name);
}

class ThemeModeNotifier extends AsyncNotifier<ThemeMode> {
  @override Future<ThemeMode> build() async => ref.watch(themeRepositoryProvider).read();
  Future<void> setMode(ThemeMode m) async {
    state = AsyncData(m);
    await ref.read(themeRepositoryProvider).write(m);
  }
}
final themeModeProvider = AsyncNotifierProvider<ThemeModeNotifier, ThemeMode>(ThemeModeNotifier.new);

Future<void> main() async {
  WidgetsFlutterBinding.ensureInitialized();
  final prefs = await SharedPreferences.getInstance();
  runApp(ProviderScope(
    overrides: [sharedPrefsProvider.overrideWithValue(prefs)], child: const App()));
}

final mode = ref.watch(themeModeProvider).valueOrNull ?? ThemeMode.system;
MaterialApp(theme: light, darkTheme: dark, themeMode: mode, home: const HomePage());

class PlatformBrightnessNotifier extends Notifier<Brightness> with WidgetsBindingObserver {
  @override Brightness build() {
    final b = WidgetsBinding.instance;
    b.addObserver(this);
    ref.onDispose(() => b.removeObserver(this));
    return b.platformDispatcher.platformBrightness;
  }
  @override void didChangePlatformBrightness() =>
      state = WidgetsBinding.instance.platformDispatcher.platformBrightness;
}
final platformBrightnessProvider =
    NotifierProvider<PlatformBrightnessNotifier, Brightness>(PlatformBrightnessNotifier.new);

final effectiveBrightnessProvider = Provider<Brightness>((ref) {
  final mode = ref.watch(themeModeProvider).valueOrNull ?? ThemeMode.system;
  return switch (mode) {
    ThemeMode.light => Brightness.light,
    ThemeMode.dark => Brightness.dark,
    ThemeMode.system => ref.watch(platformBrightnessProvider),
  };
});
// final isDark = ref.watch(effectiveBrightnessProvider) == Brightness.dark;

ProviderScope(
  overrides: [seedProvider.overrideWithValue(const Color(0xFFB8860B))],
  child: Consumer(builder: (c, ref, _) {
    final theme = Theme.of(c).brightness == Brightness.dark
      ? ref.watch(darkThemeProvider) : ref.watch(lightThemeProvider);
    return Theme(data: theme, child: const PremiumBody());
  }),
)

import 'package:flutter/material.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';
import 'package:shared_preferences/shared_preferences.dart';

// --- Theme factory + seed-driven providers (Part 5) ---
ThemeData themeFor(Color seed, Brightness b) =>
    ThemeData(colorScheme: ColorScheme.fromSeed(seedColor: seed, brightness: b));
final seedProvider = Provider<Color>((ref) => const Color(0xFF6750A4));
final lightThemeProvider = Provider<ThemeData>((ref) => themeFor(ref.watch(seedProvider), Brightness.light));
final darkThemeProvider  = Provider<ThemeData>((ref) => themeFor(ref.watch(seedProvider), Brightness.dark));

// --- Persistence seam (Part 2) ---
final sharedPrefsProvider = Provider<SharedPreferences>((ref) => throw UnimplementedError());
class ThemeRepository {
  ThemeRepository(this._p); final SharedPreferences _p; static const _k = 'themeMode';
  ThemeMode read() => switch (_p.getString(_k)) {
    'light' => ThemeMode.light, 'dark' => ThemeMode.dark, _ => ThemeMode.system };
  Future<void> write(ThemeMode m) => _p.setString(_k, m.name);
}
final themeRepositoryProvider = Provider<ThemeRepository>((ref) => ThemeRepository(ref.watch(sharedPrefsProvider)));

// --- Persisted mode state (Parts 1+2) ---
class ThemeModeNotifier extends AsyncNotifier<ThemeMode> {
  @override Future<ThemeMode> build() async => ref.watch(themeRepositoryProvider).read();
  Future<void> setMode(ThemeMode m) async {
    state = AsyncData(m);
    await ref.read(themeRepositoryProvider).write(m);
  }
  Future<void> toggle() async {
    final cur = state.valueOrNull ?? ThemeMode.system;
    await setMode(cur == ThemeMode.dark ? ThemeMode.light : ThemeMode.dark);
  }
}
final themeModeProvider = AsyncNotifierProvider<ThemeModeNotifier, ThemeMode>(ThemeModeNotifier.new);

// --- OS brightness + effective resolution (Part 4) ---
class PlatformBrightnessNotifier extends Notifier<Brightness> with WidgetsBindingObserver {
  @override Brightness build() {
    final b = WidgetsBinding.instance;
    b.addObserver(this);
    ref.onDispose(() => b.removeObserver(this));
    return b.platformDispatcher.platformBrightness;
  }
  @override void didChangePlatformBrightness() =>
      state = WidgetsBinding.instance.platformDispatcher.platformBrightness;
}
final platformBrightnessProvider =
    NotifierProvider<PlatformBrightnessNotifier, Brightness>(PlatformBrightnessNotifier.new);
final effectiveBrightnessProvider = Provider<Brightness>((ref) {
  final mode = ref.watch(themeModeProvider).valueOrNull ?? ThemeMode.system;
  return switch (mode) {
    ThemeMode.light => Brightness.light,
    ThemeMode.dark => Brightness.dark,
    ThemeMode.system => ref.watch(platformBrightnessProvider),
  };
});

// --- Root (Parts 1+3) ---
Future<void> main() async {
  WidgetsFlutterBinding.ensureInitialized();
  final prefs = await SharedPreferences.getInstance();
  runApp(ProviderScope(
    overrides: [sharedPrefsProvider.overrideWithValue(prefs)],
    child: const App(),
  ));
}

class App extends ConsumerWidget {
  const App({super.key});
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    return MaterialApp(
      theme: ref.watch(lightThemeProvider),
      darkTheme: ref.watch(darkThemeProvider),
      themeMode: ref.watch(themeModeProvider).valueOrNull ?? ThemeMode.system,
      home: const HomePage(),
    );
  }
}

class HomePage extends ConsumerWidget {
  const HomePage({super.key});
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final isDark = ref.watch(effectiveBrightnessProvider) == Brightness.dark;
    return Scaffold(
      appBar: AppBar(
        title: const Text('Theme demo'),
        actions: [
          IconButton(
            icon: Icon(isDark ? Icons.light_mode : Icons.dark_mode),
            onPressed: () => ref.read(themeModeProvider.notifier).toggle(),
          ),
        ],
      ),
      // Per-feature override (Part 5): a gold "premium" card.
      body: ProviderScope(
        overrides: [seedProvider.overrideWithValue(const Color(0xFFB8860B))],
        child: Consumer(builder: (c, r, _) {
          final theme = Theme.of(c).brightness == Brightness.dark
              ? r.watch(darkThemeProvider) : r.watch(lightThemeProvider);
          return Theme(
            data: theme,
            child: const Card(child: ListTile(title: Text('Premium (gold)'))),
          );
        }),
      ),
    );
  }
}

This capstone assembles the whole series: a persisted AsyncNotifier<ThemeMode> with a repository seam (Part 1 + Part 2); a root MaterialApp that watches it for a live, restart-free switch (Part 3); an OS-brightness notifier with onDispose cleanup and a derived effectiveBrightnessProvider (Part 4); and a nested ProviderScope seed override + local Theme for a per-feature palette (Part 5). Override sharedPrefsProvider/themeRepositoryProvider with fakes to test it all.