# Add a Dark Theme Setting to a Flutter App from a Linear Issue

Yes. An agent picks up the Linear issue, wires system, light and dark theme options on settings, persists them and opens a pull request.

[Run this on Rush](https://cloud.getrush.ai/run/add-dark-theme/flutter/), in a Project that has your repository.

## What the agent does

The run starts from the repository URL in `resources`: the agent clones it into its own cloud sandbox and reads the app the way a new Flutter maintainer would. In an app like `simplezhli/flutter_deer`, `pubspec.yaml` pins Flutter `>=3.19.0`, Dart SDK `>=3.4.0 <4.0.0`, and version `1.3.3+22`. Persistence today goes through `sp_util` 2.0.3, which wraps platform preferences; `lib/main.dart` awaits `SpUtil.getInstance()` before `runApp`, and `MyApp` sets `themeMode: provider.getThemeMode()`.

Theme support already has a home. `lib/setting/provider/theme_provider.dart` maps stored strings `System`, `Light` and `Dark` onto `ThemeMode`, writes them with `SpUtil.putString(Constant.theme, …)`, and builds light and dark `ThemeData` in `getTheme`. `lib/setting/page/theme_page.dart` is the "夜间模式" screen with three rows, and `lib/setting/page/setting_page.dart` links to it from a ClickItem titled 夜间模式. The issue still asks for a setting with system, light and dark options saved with `shared_preferences` and applied at startup, so the agent tightens that path rather than inventing a second theme system.

The agent adds the `shared_preferences` package the issue names, points `ThemeProvider` at it for the `AppTheme` key from `lib/res/constant.dart`, and keeps the same three `ThemeMode` values so the existing ThemePage labels keep working. Startup in `main.dart` still reads the provider before the first frame, so a choice survives process death. Chinese copy on the settings rows can stay; the behaviour is what the issue measures.

Proving it means widget tests next to the ones under `test/setting/`. `setting_accessibility_test.dart` already pumps `ThemePage` inside `MyApp` for tap-target and contrast guidelines. The agent adds a test that selects Dark, rebuilds from a fresh `SharedPreferences` load, and asserts `themeMode` is `ThemeMode.dark`, plus a case for System. Then it runs `flutter analyze` and `flutter test`.

## Start it with one API call

`POST https://api.prix.dev/o/{org}/sessions`

```json
{
  "agent": "claude",
  "input": "A Linear issue labeled agent says: \"Add a Dark Theme Setting to a Flutter App. Add a theme setting with system, light and dark options on the settings screen, saved with shared_preferences and applied at startup.\" Do the work in this repository, add tests for it, run flutter analyze and flutter test, and open a pull request that links back to the issue.",
  "resources": [
    {
      "url": "https://github.com/your-org/your-app"
    }
  ]
}
```

1. **Get an API key.** In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
2. **Send the request.** POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
3. **Read what came back.** Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.

## What comes back

What comes back is a pull request. Its diff updates `pubspec.yaml` for `shared_preferences`, adjusts `theme_provider.dart` and startup wiring in `main.dart` as needed, and adds a widget test under `test/setting/`. The description quotes the issue and links back to it.

The checks on the pull request run `flutter analyze` and `flutter test`. A reviewer reads the diff for three things: system, light and dark are all selectable, the choice is read back after a simulated restart, and ThemePage remains reachable from SettingPage. Unrelated shop, order and goods screens stay untouched.

The session read keeps the record behind the pull request: pub get, analyze and the test output. Anyone who questions a themeMode assertion can open the trajectory and see the exact flutter test command.

## Run it on every Linear issue labelled agent

The Project's automation turns the label into the run. In the console, add an automation with a Linear trigger on `linear.issue.labeled` filtered to the `agent` label and this prompt; each labelled Flutter UX issue starts its own run in its own sandbox and opens its own pull request.

If the automation is not wanted, a small server can do the same: receive Linear's issue webhook, put the issue text into `input`, and POST to `/o/{org}/sessions` with the Flutter repository in `resources`. A `run.completed` webhook on the API key posts the pull request when analyze and tests have finished.

## Why run it on Rush?

On a laptop this job needs a Flutter SDK that matches `pubspec.yaml`, platform toolchains for the targets you care about, and a clean `flutter pub get` before tests will resolve Provider and SpUtil. Each run on Rush boots its own sandbox with that already in reach, runs analyze and the widget tests itself, and keeps every command and its output.

Theme and settings tickets often arrive in bunches during a release polish. Labelling them starts one sandbox per issue, so dark theme, locale and cache-clear work do not serialize on a single developer machine.

## Frequently asked questions

### Flutter Deer already has a night mode screen. What is left to do?

The screen and `ThemeProvider` exist and persist through `sp_util`. The issue names `shared_preferences` and asks for tests that prove system, light and dark survive startup. The agent aligns storage with that package and adds those tests without replacing the settings UI.

### Does the agent rewrite every dark color token?

No. `getTheme` already switches `Colours.dark_*` values for dark mode. The change is about selection, persistence and tests, not a redesign of `lib/res/`.

### Which Flutter version does the sandbox use?

One that satisfies `flutter: ">=3.19.0"` and the Dart SDK bound in `pubspec.yaml`. The agent reads those constraints before running analyze.

### Are integration_test driver scripts required?

Not for this issue. Widget tests under `test/setting/` are enough to prove themeMode persistence; `test_driver/setting/` stays as it is unless the issue asks for a driver run.