mkit-cli 0.3.1__tar.gz → 0.4.0__tar.gz

{mkit_cli-0.3.1 → mkit_cli-0.4.0}/CHANGELOG.md

@@ -7,6 +7,35 @@ it rather than doing the wrong thing.
 
 ## Unreleased
 
+## 0.4.0 — 2026-10-23
+
+**Guides.** `mkit guide` reads the guides every app follows — the About screen,
+in-app review, in-app updates, ASO, support replies, app UI, the store folder,
+store art, news notifications — filled in with your studio's details from
+`[studio]`, `[about]` and `[support]` in `~/.mkit/config.toml` or an app's
+`mkit.toml`. They ship inside the package, so they work offline. Anything not
+set shows as ‹key› and is listed; `--raw` gives the guide as written.
+
+- **The About screen is yours to shape.** `[about] parts` picks which of its
+  nine parts an app has, and every line it says has an `[about]` key with a
+  default.
+- **Your own rules beside a guide.** A file of the same name in
+  `[guide] house_dir` is appended under *This studio's own rules*, and wins
+  where the two disagree.
+- Five guides are new to this repo: about-screen, in-app-review, aso,
+  support-replies and app-ui.
+
+**`--dry-run` can no longer quietly make the change.** `mkit init --dry-run`
+wrote every file it was meant to preview, and twelve other write-class commands
+ignored the flag the same way: `bump` committed, `share` uploaded, `firebase
+sha-add` changed the Firebase project. Commands now declare whether they
+support a dry run, and the CLI refuses `--dry-run` for any that do not — exit 2,
+`NO_DRY_RUN` — before anything runs. `init` and `bump` preview for real. Every
+publish-class command already honoured it and still does.
+
+- `mkit commands --json` reports `dry_run` per command, so an agent can tell in
+  advance which commands it can rehearse.
+
 ## 0.3.1 — first public release
 
 mkit shipped a small studio's Android apps for a year before this; this is that

{mkit_cli-0.3.1 → mkit_cli-0.4.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: mkit-cli
-Version: 0.3.1
+Version: 0.4.0
 Summary: Release Android apps to Google Play from the command line: build, upload, listing, screenshots, data safety, in-app products, vitals and Firebase, in one tool built for humans and AI agents.
 Project-URL: Homepage, https://github.com/almasumdev/mkit-cli
 Project-URL: Documentation, https://github.com/almasumdev/mkit-cli/blob/main/docs/commands.md
@@ -137,6 +137,29 @@ Some things have no API and must be done in the Play Console. `mkit manual`
 lists them, so you know what is left rather than discovering it at release
 time.
 
+## Guides
+
+Some things every app has to do, and every app that works them out alone does
+differently: an About screen, asking for a rating, checking for updates, being
+found on Play, answering users. mkit carries a guide for each, and fills it in
+with your studio's details:
+
+```bash
+mkit guide              # the list
+mkit guide about        # the About screen, with your email, developer page, links
+mkit guide review       # when to ask for a rating, and what Play forbids around it
+```
+
+Set your details once in `~/.mkit/config.toml` — `[studio]` for the facts,
+`[about]` for which parts your About screen has and what it says — and every
+guide, for every app, uses them. Anything not set shows as ‹key› and is listed.
+Keep your own rules beside a guide in `[guide] house_dir`; they are appended
+and win where they disagree. The keys are in
+[docs/config.md](https://github.com/almasumdev/mkit-cli/blob/main/docs/config.md#studio-details-mkit-guide).
+
+They are written so an AI agent building the screen can follow them too:
+`mkit guide about --json` returns the text.
+
 ## Working with AI agents
 
 mkit answers in JSON whenever it is not attached to a terminal, with one
@@ -151,6 +174,11 @@ and what an agent must never do.
 |---|---|
 | [docs/commands.md](https://github.com/almasumdev/mkit-cli/blob/main/docs/commands.md) | every command and flag |
 | [docs/config.md](https://github.com/almasumdev/mkit-cli/blob/main/docs/config.md) | `mkit.toml`, the store and keyword files, credentials |
+| [docs/about-screen.md](https://github.com/almasumdev/mkit-cli/blob/main/docs/about-screen.md) | the About screen: its parts, words, marks and behaviour (`mkit guide about`) |
+| [docs/in-app-review.md](https://github.com/almasumdev/mkit-cli/blob/main/docs/in-app-review.md) | asking for a rating: when, where, and the rules Play enforces (`mkit guide review`) |
+| [docs/aso.md](https://github.com/almasumdev/mkit-cli/blob/main/docs/aso.md) | being found on Play: the indexed fields, winnable keywords, the title |
+| [docs/support-replies.md](https://github.com/almasumdev/mkit-cli/blob/main/docs/support-replies.md) | answering users by email |
+| [docs/app-ui.md](https://github.com/almasumdev/mkit-cli/blob/main/docs/app-ui.md) | how an app is organised: colours, Pro, pickers, Settings |
 | [docs/store.md](https://github.com/almasumdev/mkit-cli/blob/main/docs/store.md) | the `store/` folder: what lives where, in every language |
 | [docs/store-art.md](https://github.com/almasumdev/mkit-cli/blob/main/docs/store-art.md) | screenshots and the feature graphic, built from real captures |
 | [docs/in-app-update.md](https://github.com/almasumdev/mkit-cli/blob/main/docs/in-app-update.md) | how an app should check for updates: Play first, your policy second |

{mkit_cli-0.3.1 → mkit_cli-0.4.0}/README.md

@@ -105,6 +105,29 @@ Some things have no API and must be done in the Play Console. `mkit manual`
 lists them, so you know what is left rather than discovering it at release
 time.
 
+## Guides
+
+Some things every app has to do, and every app that works them out alone does
+differently: an About screen, asking for a rating, checking for updates, being
+found on Play, answering users. mkit carries a guide for each, and fills it in
+with your studio's details:
+
+```bash
+mkit guide              # the list
+mkit guide about        # the About screen, with your email, developer page, links
+mkit guide review       # when to ask for a rating, and what Play forbids around it
+```
+
+Set your details once in `~/.mkit/config.toml` — `[studio]` for the facts,
+`[about]` for which parts your About screen has and what it says — and every
+guide, for every app, uses them. Anything not set shows as ‹key› and is listed.
+Keep your own rules beside a guide in `[guide] house_dir`; they are appended
+and win where they disagree. The keys are in
+[docs/config.md](https://github.com/almasumdev/mkit-cli/blob/main/docs/config.md#studio-details-mkit-guide).
+
+They are written so an AI agent building the screen can follow them too:
+`mkit guide about --json` returns the text.
+
 ## Working with AI agents
 
 mkit answers in JSON whenever it is not attached to a terminal, with one
@@ -119,6 +142,11 @@ and what an agent must never do.
 |---|---|
 | [docs/commands.md](https://github.com/almasumdev/mkit-cli/blob/main/docs/commands.md) | every command and flag |
 | [docs/config.md](https://github.com/almasumdev/mkit-cli/blob/main/docs/config.md) | `mkit.toml`, the store and keyword files, credentials |
+| [docs/about-screen.md](https://github.com/almasumdev/mkit-cli/blob/main/docs/about-screen.md) | the About screen: its parts, words, marks and behaviour (`mkit guide about`) |
+| [docs/in-app-review.md](https://github.com/almasumdev/mkit-cli/blob/main/docs/in-app-review.md) | asking for a rating: when, where, and the rules Play enforces (`mkit guide review`) |
+| [docs/aso.md](https://github.com/almasumdev/mkit-cli/blob/main/docs/aso.md) | being found on Play: the indexed fields, winnable keywords, the title |
+| [docs/support-replies.md](https://github.com/almasumdev/mkit-cli/blob/main/docs/support-replies.md) | answering users by email |
+| [docs/app-ui.md](https://github.com/almasumdev/mkit-cli/blob/main/docs/app-ui.md) | how an app is organised: colours, Pro, pickers, Settings |
 | [docs/store.md](https://github.com/almasumdev/mkit-cli/blob/main/docs/store.md) | the `store/` folder: what lives where, in every language |
 | [docs/store-art.md](https://github.com/almasumdev/mkit-cli/blob/main/docs/store-art.md) | screenshots and the feature graphic, built from real captures |
 | [docs/in-app-update.md](https://github.com/almasumdev/mkit-cli/blob/main/docs/in-app-update.md) | how an app should check for updates: Play first, your policy second |

mkit_cli-0.4.0/docs/about-screen.md

@@ -0,0 +1,228 @@
+# The About screen
+
+Every app needs an About screen, and every app that solves it on its own ends
+up with a different one. This guide is a spine that works: which parts, in what
+order, what each says and does, and what it must never claim. **Only the theme
+changes between apps** — colours, type, and the app's own row and button
+components.
+
+Read it with `mkit guide about`. Your studio's details are filled in from
+`[studio]`, and which parts you use and what they say from `[about]` — in
+`~/.mkit/config.toml` for every app, or an app's own `mkit.toml` to differ.
+Anything you have not set shows as ‹key›.
+
+## Make it yours
+
+```toml
+[studio]
+name             = "Acme Apps"
+tagline          = "Small tools, done properly."
+email            = "hello@acme.dev"          # where users and clients write
+website          = "https://acme.dev"
+privacy_url      = "https://acme.dev/privacy"
+terms_url        = "https://acme.dev/terms"
+play_developer_id = "1234567890123456789"    # from your Play developer page URL
+developer        = "Ada Example"
+developer_role   = "Mobile app developer at Acme Apps"
+portfolio        = "https://ada.example"
+photo            = "https://github.com/ada-example.png?size=460"
+
+[about]
+# Leave out a part to drop it - its row, its words and its behaviour.
+parts = ["mark", "name", "version", "what", "rating", "maker", "ask", "more_apps", "footer"]
+# Every line below can be reworded; these are the defaults.
+rating_heading = "Enjoying <App>?"
+ask            = "We design and build mobile apps. <App> is one of ours. If you have one in mind, tell us about it."
+```
+
+`<App>` stands for the app's name, translated with the rest of the line.
+
+## The spine
+
+Top to bottom, in this order. A studio leaves out what it does not want;
+nothing is reordered.
+
+| # | Part | What it holds |
+|---|---|---|
+| 1 | **Mark** | the app's own launcher icon, centred, nothing behind it | <!-- part:mark -->
+| 2 | **Name** | the app name, the largest type on the page | <!-- part:name -->
+| 3 | **Version** | `v1.2.3` — the short form, bare, no tag or box, no build number | <!-- part:version -->
+| 4 | **What it is** | one sentence, centred, the app's own words; never marketing | <!-- part:what -->
+| 5 | **Rating** | a heading, one line, five stars → the Play listing | <!-- part:rating -->
+| 6 | **The maker** | photo, name, role → the portfolio | <!-- part:maker -->
+| 7 | **The ask** | a few lines about the studio, then two actions: email, website | <!-- part:ask -->
+| 8 | **More apps** | a heading, one line, one Play button → the developer page | <!-- part:more_apps -->
+| 9 | **Footer** | Privacy · Terms, then `© <year> {{studio.name}}` | <!-- part:footer -->
+
+The first four are one block, centred. The middle parts are banks, each with a
+heading and left-aligned text. The footer is centred and quiet. That single
+change of alignment is what tells the eye where the reading starts.
+
+**No cards.** Not for the rating, not for the maker, not for the Play button —
+even in an app whose other screens are made of cards. Groups are made by space
+alone: a heading sits close to what it names and far from what it does not, and
+that asymmetry is the whole of the grouping. Roughly 10dp under a heading
+against 26dp under a bank; wider — about 34dp — above the first bank and below
+the last, where the page changes subject rather than section. An About page is
+a few short things in a column, and a container round each is how it turns into
+a filing cabinet.
+
+## The words
+
+English below; translate them into each of the app's locales. Every line is an
+`[about]` key, so a studio rewords it once for all its apps.
+
+| String | Key | Text |
+|---|---|---|
+| What it is | — | the app's own one sentence — the only line it writes itself | <!-- part:what -->
+| Rating heading | `rating_heading` | `{{about.rating_heading}}` | <!-- part:rating -->
+| Rating line | `rating_line` | `{{about.rating_line}}` | <!-- part:rating -->
+| Maker heading | `maker_heading` | `{{about.maker_heading}}` | <!-- part:maker -->
+| Maker name / role | `[studio]` | `{{studio.developer}}` / `{{studio.developer_role}}` | <!-- part:maker -->
+| The ask | `ask` | `{{about.ask}}` | <!-- part:ask -->
+| Email button | `email_button` | `{{about.email_button}}` | <!-- part:ask -->
+| Website button | `website_button` | `{{about.website_button}}` | <!-- part:ask -->
+| More heading | `more_heading` | `{{about.more_heading}}` | <!-- part:more_apps -->
+| More line | `more_line` | `{{about.more_line}}` | <!-- part:more_apps -->
+| Play button | — | `Google Play` | <!-- part:more_apps -->
+| Footer | — | `Privacy` · `Terms` · `© <year> {{studio.name}}` | <!-- part:footer -->
+
+The buttons **name their destination and nothing else**. The sentence saying
+what is over there goes above them. A button carrying the whole explanation is
+a sentence with a button drawn round it.
+
+An app's own heading style still applies: if its section headers are uppercased
+by its own component, these are too. The words are shared; the case is the
+app's.
+
+## What it never does
+
+- **No rating it does not have.** The stars carry no number and show nothing
+  back. They are a link to the listing, not a score.
+- **No install counts, no review counts, no awards, no "loved by N users".**
+- **No "All rights reserved."** It has carried no legal weight since the Berne
+  Convention. The bare `© <year> {{studio.name}}` stays, and the year is read
+  from the clock so the line cannot rot.
+- **No list of the studio's other apps inside the app.** A hard-coded list
+  cannot know what shipped after the build, what was renamed or what was
+  pulled, and each of those becomes a false line on a page whose whole claim is
+  that it states facts. The Play developer page is the same information, kept
+  by the shop that sells it.
+- **No second button saying what the first one does.** A "Rate on Google Play"
+  button under five stars that do exactly that asks twice.
+
+## The marks
+
+One shape per job, at one weight. Take them from the app's own outline icon set.
+
+| Where | Mark |
+|---|---|
+| A row that navigates | chevron pointing forward |
+| Email button | envelope | <!-- part:ask -->
+| Website button | globe | <!-- part:ask -->
+| Google Play button | Google Play's own four-colour mark, from Google's brand resources — never redrawn | <!-- part:more_apps -->
+| Rating | five hollow stars | <!-- part:rating -->
+
+Outline weight throughout, one family throughout. A filled glyph beside a hollow
+one is the fastest way to make a page look assembled from whatever was to hand.
+The Play mark is the single exception to the app's palette and is **never
+tinted**: it is a trademark, and an icon slot that paints its content with the
+surface's colour would flatten all four of its colours into one.
+
+## What changes per app
+
+A short list on purpose. Read the app's design doc, or its theme file, and take
+four things from it:
+
+1. **Every colour** — the ground, the ink, and a warm tone for the stars.
+2. **The type scale**, and which style is a heading.
+3. **The row it already uses** for "tap to go somewhere".
+4. **The button it already uses** for a primary action.
+
+Two rules hold whatever those are:
+
+1. **Reuse the app's own components.** If its settings list has a row, the
+   About page uses that row; a page built from new one-off widgets is how two
+   screens in one app stop looking related. Reuse the *component*, not a
+   container: a card the app has is still a card and still does not belong here.
+2. **Keep the app's colour discipline.** Where an app gives colours meanings,
+   this page obeys them and adds no new accent. If its palette has no gold for
+   the stars, take the nearest warm tone it already has.
+
+## The two assets that fool you
+
+**The app icon.** An adaptive icon is drawn on a canvas bigger than the mark on
+it — the safe-zone margin a launcher masks away. Drawn plainly it arrives with a
+ring of transparent air that reads as a hole, and no spacer around it fixes that,
+because the air is inside the picture. Measure the mark in the vector's own path
+data, then draw the canvas at `mark_size × viewport / mark_height` inside a box
+the size of the mark, and let the margin overflow. A mark running 21→87 of a 108
+viewport, wanted at 72dp, needs a 118dp canvas. In Compose that overflow needs
+`requiredSize`, not `size`, or the box's constraints shrink it back.
+
+**No tile behind it** — not the icon's own background layer, not a rounded plate.
+A filled tile is a card. That leaves two layers, and which one is a contrast
+question, not a matter of taste:
+
+1. **The foreground alone**, where its artwork carries its own colour and that
+   colour reads on both of the app's grounds.
+2. **The monochrome layer, tinted with the page's ink**, where the foreground
+   was drawn for the icon's own background and disappears without it — a
+   near-black foreground on a dark theme is the same colour twice. The
+   monochrome layer is that shape with the colour taken out, so it takes the
+   page's ink and reads on both themes.
+
+Check the foreground against the app's darkest **and** lightest surface before
+choosing. Both layers carry the same margin, so size either off the mark.
+
+**The photo.** One square image, centre-cropped to a circle, never letterboxed
+into it. 256px is enough for a 46–52dp avatar. Take it from `{{studio.photo}}`
+and store it density-independent (`drawable-nodpi` on Android, a single asset in
+Flutter).
+
+## Behaviour
+
+| Control | Does |
+|---|---|
+| Any star | the app's own Play listing: `market://details?id=<package>`, then `https://play.google.com/store/apps/details?id=<package>` | <!-- part:rating -->
+| Maker row | `{{studio.portfolio}}` | <!-- part:maker -->
+| Email button | `mailto:{{studio.email}}`, with a subject naming the app | <!-- part:ask -->
+| Website button | `{{studio.website}}` | <!-- part:ask -->
+| Google Play button | `market://dev?id={{studio.play_developer_id}}`, then `https://play.google.com/store/apps/dev?id={{studio.play_developer_id}}` | <!-- part:more_apps -->
+| Privacy, Terms | `{{studio.privacy_url}}`, `{{studio.terms_url}}` | <!-- part:footer -->
+
+Every one of these hands the user to something the app does not own, so every
+one can fail: no mail app, no browser, no Play. Fail in silence — there is no
+second way to do any of them, and a toast saying the phone has no email client
+helps nobody.
+
+For when a rating is *asked for* rather than offered here — the prompt at a
+good moment, and what happens after a low score — see `mkit guide review`.
+
+## Strings
+
+Every line except the studio's own names is translated into all of the app's
+locales in the same change that adds it. An About page that is half English is
+worse than one that is plainly smaller. These stay untranslated
+(`translatable="false"` on Android): the developer's name, the studio name, the
+website's address, and `Google Play` — a product name Google requires to be left
+in English.
+
+## In Flutter
+
+The same spine maps onto the app's own widgets: `package_info_plus` for the
+version, `url_launcher` for every row in the behaviour table, the launcher icon
+from the app's own asset, and the app's existing section header, list row and
+button widgets for everything below the centred block.
+
+## Checklist for a new app
+
+1. Set `[studio]` and `[about]` once; check them with `mkit guide about`.
+2. Read the app's design doc and take the four things above from it.
+3. Build the spine with that app's components — no new widgets unless the app
+   genuinely lacks one, and no cards.
+4. App icon sized off its own artwork; photo cropped to a circle.
+5. All strings in every locale the app ships.
+6. Wire the behaviours; let each fail silently.
+7. Check it in the app's light and dark themes, and in its right-to-left locale
+   if it has one.

mkit_cli-0.4.0/docs/app-ui.md

@@ -0,0 +1,123 @@
+# App UI foundations
+
+This decides how an app is organised, never how it looks: where colours
+live, how Pro is marked, what a picker does, how Settings is put together. No
+colour value (except Pro's gold) and no size of the app's look is set here;
+each app keeps its own palette, type, shapes and components. A studio whose
+apps share one look keeps that look in its own rules beside this guide.
+
+Read this before adding a colour, a Pro mark, a settings row or a picker to
+any app. Read it with `mkit guide ui`.
+
+## Colours from one place
+
+Every colour an app draws is defined in its theme folder and nowhere else.
+
+| Kind | Where |
+|---|---|
+| Follows the theme and palette | the palette file: one complete set per palette, light and dark |
+| Never changes with the theme | `fixed_colors.dart` (or the native app's equivalent) |
+| The framework's own (Material `ColorScheme`, Compose `ColorScheme`) | mapped from the palette set by the theme builder |
+
+Widgets read colours through the app's token accessor (a context extension in
+Flutter, a `CompositionLocal` in Compose) and the framework's widgets get them
+through the colour scheme the builder maps them into. A widget never writes a
+colour literal: in Flutter no `Color(0x…)`, `Color.fromRGBO`, `Color.fromARGB`
+or `Colors.<name>` (only `Colors.transparent`); in Compose no `Color(0x…)`.
+
+**The rule is a test, not a convention.** Each app carries one that walks its
+source, skips the theme folder, generated files and comment lines, and fails
+on any colour literal, naming the file and line. Write it once and copy it to
+each app, changing only the folder name.
+
+**One complete set per palette.** Every palette, in light and in dark, is one
+full colour set: the ground, the inks from strongest to faintest, the card,
+the lines, the primary fill and the ink on it, the icon tile and its glyph,
+the accent and its soft wash, danger, the warning colour, and whatever else
+the app draws with (a receipt's paper, a panel's gradient). The theme builder
+and the token class only map that set; neither writes a colour of its own. An
+app with one palette has one set per brightness, and the same rule.
+
+**Two inks for the primary colour.** A primary colour dark enough to carry
+white text as a button is often too dark to read as text on a dark ground.
+So a set carries an ink for the primary colour used as text or an icon (a
+price, a check, a cursor, a focused field, a text button), and one for the
+glyph on an icon tile, separate from the fill. Fills (buttons, switches, a
+selected dot) keep the primary. Where the two are the same colour, the set
+simply says so twice.
+
+What goes in `fixed_colors.dart`, and nothing else: the brand (a mascot, the
+intro slides), Pro's gold, other companies' marks in their own colours,
+shadows and scrims, and colours fixed by what they sit on (white on a red
+swipe, ink on a photo). A colour that ought to change with the palette is in
+the palette set, even if today it happens to be the same in every palette.
+
+## Pro's mark
+
+Pro is the studio's product, so its mark is the same in every app: **one
+crown, drawn, in one gold.**
+
+- **The shape** is one crown, drawn in code on a 24-unit
+  grid, never an icon font's crown (`workspace_premium` and the like): three
+  points with round tips over a band, solid, one colour, the jewel and the gap
+  above the band cut through it (even-odd).
+
+  ```text
+  body (even-odd):  M3.6 8.2 7.7 11.7 12 5.4 16.3 11.7 20.4 8.2 18.7 16.2H5.3Z
+                    M12 11.2 13.6 13 12 14.8 10.4 13Z
+  tips:             circles r1.6 at (3.6, 6.9) and (20.4, 6.9), r1.7 at (12, 3.9)
+  band:             rounded rect 4.8,18 → 19.2,20.8, corner 1.4
+  ```
+
+  One component per app draws it: an icon widget in Flutter, a composable in
+  Compose.
+- **The colour** is Pro gold — this guide uses `#E3A93C` — a fixed colour, the same in light
+  and dark and in every palette: a mark of the product that changed with the
+  theme would read as two marks.
+- **The tag** beside anything the free plan lacks is an outline, never a
+  fill: the crown and the word `PRO` in gold inside a gold-outlined pill, in
+  the app's own type. Shown only while Pro is not owned.
+- **Where the crown stands alone:** a locked colour theme's swatch, a locked
+  action's icon, the Pro screen's header, in gold. Inside a filled button it
+  takes the button's own ink instead. On a row whose other rows have icon
+  tiles, it sits on the row's usual tile in the tile's glyph colour, so it
+  lines up with the rest.
+
+## Settings
+
+- **Groups under section headers.** Rows that belong together form a group;
+  groups sit under short section headers in the app's own style.
+- **The Pro row** comes first, on its own, with the crown as its icon.
+- **The rating, share and feedback rows** are those of `mkit guide review`;
+  the update row and the version line at the very foot are those of
+  `mkit guide update`.
+- **An app with colour themes** puts the light/dark choice and the colour
+  choice together, one after the other in the same place. A locked colour can
+  be tried on before buying; leaving Settings ends the try-on.
+
+## Picker sheets
+
+A choice from a list (a language, a currency, a list to move to) is a
+**bottom sheet**; a question with a few answers is a dialog
+(`mkit guide review`).
+
+- **One frame** for every sheet in the app: its handle, its title, its body.
+  One component, not one per sheet.
+- **A long list has search.** Any picker with more than about a dozen
+  choices (languages, currencies) opens with a search field and stays clear of
+  the keyboard. Matching: a language by its own name, its English name or a
+  code prefix; a currency by code, sign, name or country. Nothing found is one
+  plain line saying so, not an empty sheet.
+- **The chosen row is marked one way in every picker** of the app, in its own
+  colours (a wash, a check, a bolder title: whichever the app chose, the same
+  everywhere). Two pickers that mark it two ways is the bug.
+- Tapping a row applies it and closes the sheet; there is no Done button.
+
+## Checklist, every app
+
+1. No colour literal outside the theme folder, and the test that proves it.
+2. One complete colour set per palette and brightness; the builder only maps.
+3. Pro gold in `fixed_colors.dart`, the drawn crown everywhere Pro is marked,
+   no icon-font crown left, and the Pro tag an outline.
+4. Language and currency pickers search, and every picker marks the choice
+   the same way.