flet-box 1.1.1 → 1.1.3

package/bin/utils/toolkit.js

@@ -0,0 +1,191 @@
+/**
+ * @file bin/utils/toolkit.js
+ * @description The diagnosis toolkit, as data — one entry per question an agent
+ * may ask, and the command that answers it.
+ *
+ * The problem this file solves is not "there are no checkers". There are ten,
+ * and each one is right about its own slice. The problem is that an agent does
+ * not know which one to run for the question in front of it, so it runs the one
+ * it remembers and reports a number that answers something else.
+ *
+ * So the tools are listed here with the question each one answers, in the
+ * language a person uses when they are stuck, and every entry names the exact
+ * command. The CLI prints this list (`flet-box tools`), the report links every
+ * finding back to the tool that proves it, and the MCP server (`flet-box mcp`)
+ * exposes the same entries to an assistant that has no shell. One source, three
+ * mouths.
+ *
+ * The rule for membership: a tool in this catalogue **reads**. No entry may
+ * repair, rename, delete, build or write — those are decisions, and the assistant
+ * asks a human before taking one. `writes` is therefore empty on every entry;
+ * the field exists so a future write tool cannot be added silently.
+ *
+ * Pure data: this module imports nothing. Renderers live in
+ * `bin/commands/tools.js` and `bin/mcp.js`.
+ */
+
+/** Bumped only when an entry's shape changes, so a cached copy can be noticed. */
+export const CATALOG_VERSION = 1;
+
+/**
+ * Every read-only tool, ordered from "where do I start" to "one narrow check".
+ *
+ * `params` is the JSON-Schema source used by the MCP server:
+ * `{ name, type: "string"|"boolean", required?, description }`.
+ */
+export const TOOLS = [
+  {
+    id: "report",
+    title: "Project report",
+    question: "Where is the work? Which file is wrong, how wrong, and what is missing?",
+    cli: "flet-box report",
+    usage: "flet-box report [--json | --md | --html] [--tests]",
+    output: ["text", "json", "md", "html"],
+    writes: ["--html only: .fletbox/reports/report.html (or --out <file>)"],
+    params: [
+      { name: "tests", type: "boolean", description: "Also run the project's own test scripts (slow)." },
+      { name: "root", type: "string", description: "Project folder; defaults to the current directory." },
+    ],
+    when: [
+      "after any edit, before saying the work is done",
+      "when a screen renders but is wrong and the file is not obvious",
+      "when the user asks what is missing or what to do next",
+    ],
+  },
+  {
+    id: "widget_props",
+    title: "Widget props",
+    question: "Which props does this widget really accept, with types and deprecations?",
+    cli: "flet-box check-api --props <Widget>",
+    usage: "flet-box check-api --props Text",
+    output: ["text"],
+    writes: [],
+    params: [
+      { name: "widget", type: "string", required: true, description: "Widget name, e.g. Text or Container." },
+      { name: "root", type: "string", description: "Project folder; defaults to the current directory." },
+    ],
+    when: ["before writing a call", "when a prop silently does nothing", "when the cheatsheet looks wrong"],
+  },
+  {
+    id: "widget_contract",
+    title: "Widget contract",
+    question: "Do the declaration, the engine and the docs agree about this widget — and which props are dead?",
+    cli: "flet-box unpack <Widget> --json",
+    usage: "flet-box unpack Text --json",
+    output: ["text", "json"],
+    writes: [],
+    params: [
+      { name: "widget", type: "string", required: true, description: "Widget name, e.g. Text or Container." },
+      { name: "root", type: "string", description: "Project folder; defaults to the current directory." },
+    ],
+    when: ["when a prop is typed but does nothing", "when reading the framework's own gaps"],
+  },
+  {
+    id: "list_widgets",
+    title: "List widgets",
+    question: "What exists in this version of the framework?",
+    cli: "flet-box check-api --list",
+    usage: "flet-box check-api --list",
+    output: ["text"],
+    writes: [],
+    params: [{ name: "root", type: "string", description: "Project folder; defaults to the current directory." }],
+    when: ["before inventing a name", "when unsure whether a helper is real"],
+  },
+  {
+    id: "check",
+    title: "API check",
+    question: "Is any widget, prop or import invented?",
+    cli: "flet-box check-api",
+    usage: "flet-box check-api [--json] [--full]",
+    output: ["text", "json"],
+    writes: [],
+    params: [
+      { name: "full", type: "boolean", description: "List every warning site instead of collapsing repeated ones." },
+      { name: "root", type: "string", description: "Project folder; defaults to the current directory." },
+    ],
+    when: ["when a screen is blank or a widget renders nothing", "after copying code from another project"],
+  },
+  {
+    id: "design",
+    title: "Design check",
+    question: "Are the tokens, the scale, the tap targets, the labels and the contrast legal?",
+    cli: "flet-box check-ui",
+    usage: "flet-box check-ui [--json] [--strict] [--tokens]",
+    output: ["text", "json"],
+    writes: [],
+    params: [
+      { name: "tokens", type: "boolean", description: "Print the measured contrast of every colour token and exit." },
+      { name: "strict", type: "boolean", description: "Fail on contrast warnings too." },
+      { name: "root", type: "string", description: "Project folder; defaults to the current directory." },
+    ],
+    when: ["after building or editing a screen", "when the user says it looks off"],
+  },
+  {
+    id: "syntax",
+    title: "Parse check",
+    question: "Does every module parse?",
+    cli: "flet-box verify --only syntax --no-tests",
+    usage: "flet-box verify --only syntax --no-tests [--json]",
+    output: ["text", "json"],
+    writes: [],
+    params: [{ name: "root", type: "string", description: "Project folder; defaults to the current directory." }],
+    when: ["when the app is blank and the console says nothing", "before blaming the framework"],
+  },
+  {
+    id: "types",
+    title: "Type check",
+    question: "What does the editor complain about?",
+    cli: "flet-box verify --only types --no-tests",
+    usage: "flet-box verify --only types --no-tests [--json]",
+    output: ["text", "json"],
+    writes: [],
+    params: [{ name: "root", type: "string", description: "Project folder; defaults to the current directory." }],
+    when: ["when a widget method or prop is flagged in the editor", "after upgrading the package"],
+  },
+  {
+    id: "metrics",
+    title: "Recurring failures",
+    question: "Which mistakes keep coming back, and does a rule own each one?",
+    cli: "flet-box metrics",
+    usage: "flet-box metrics [--log <file>]",
+    output: ["text"],
+    writes: [],
+    params: [{ name: "root", type: "string", description: "Project folder; defaults to the current directory." }],
+    when: ["when the same finding keeps returning", "when deciding which rule to write"],
+  },
+];
+
+/**
+ * One entry by id.
+ *
+ * @param {string} id
+ * @returns {object|null}
+ */
+export const toolById = (id) => TOOLS.find((tool) => tool.id === id) || null;
+
+/**
+ * The catalogue as the JSON a tool reads: stable, relative to nothing, and with
+ * the invariant stated in the payload so a consumer can assert it.
+ *
+ * @returns {object}
+ */
+export const catalogJson = () => ({
+  tool: "flet-box tools",
+  version: CATALOG_VERSION,
+  // No entry edits a source, deletes, builds or publishes. The only file any of
+  // them can produce is the report's own HTML, and only when `--html` asks.
+  readOnly: true,
+  tools: TOOLS.map((tool) => ({
+    id: tool.id,
+    title: tool.title,
+    question: tool.question,
+    cli: tool.cli,
+    usage: tool.usage,
+    output: tool.output,
+    writes: tool.writes,
+    // The arguments are part of the map: a reader that cannot ask the MCP
+    // server still has to know that `widget_props` needs a widget name.
+    params: tool.params,
+    when: tool.when,
+  })),
+});

package/docs/README.md

@@ -18,6 +18,8 @@ This documentation is one continuous book. Start at **Chapter 0** and follow the
 | 11 | [The CLI](cli/README.md) | Create, run, and build projects with `flet-box` | Intermediate |
 | 12 | [Clean UI](guides/clean-ui.md) | The four skills every app ships with, the design system they hold, and the gate that enforces it | Intermediate |
 | 13 | [Accessibility](guides/accessibility.md) | The focus ring, the keyboard pass over every press, the roles the widgets declare, and the overlays that hold the keyboard | Intermediate |
+| 14 | [Migrate an app to a newer FletBox](guides/migration.md) | What changed between releases, and the codemod that writes it for you | Intermediate |
+| 15 | [The AI toolkit](guides/ai-toolkit.md) | The map from a question to the command, the per-file report, and the MCP server | Intermediate |
 | A | [Appendices](guides/minification-and-protection.md) | Minification, mobile, compatibility, embedding, online updates (OTA) | Advanced |
 
 > **Levels.** *Beginner:* start here and read in order. *Intermediate:* continue in order — you are comfortable with widgets. *Advanced:* for when you ship, skip on a first read.
@@ -56,6 +58,8 @@ Front cover (this page)
 → The CLI · cli/README.md
 → Clean UI · guides/clean-ui.md
 → Accessibility · guides/accessibility.md
+→ Migrating · guides/migration.md
+→ The AI toolkit · guides/ai-toolkit.md
 → Appendices (minification → mobile → compatibility → embedding → online updates)
 → The end of the book
 ```
@@ -71,4 +75,25 @@ Front cover (this page)
 
 - [Server toolkit](server/README.md) — Express/SQLite/Redis backend helpers (separate toolkit).
 - [Architecture](arquitectura.md) — how the framework is built inside.
-- [Contributing](CONTRIBUTING.md) — for people who add code or docs to FletBox.
+- [Contributing](../CONTRIBUTING.md) — for people who add code or docs to FletBox.
+
+## Read this book as an app
+
+The same pages are also a FletBox application: **[flet-box-docs](https://github.com/kuko53348/flet-box-docs)**, published to npm as its own package.
+
+```bash
+npm install flet-box-docs        # then: cd node_modules/flet-box-docs && npm install && npm run dev
+```
+
+It is a normal FletBox project — the router, a categorized index, cross-document
+Previous/Next, a light/dark toggle, an offline cache, and Capacitor wrappers for
+Android and iOS — and every page is rendered by the framework's own `Markdown`
+widget, so the book is also a live demo of the widget that writes it.
+
+Its `docs/` folder is a **snapshot** of this folder, refreshed before each
+release; when the app is online it reads the published source instead, so a page
+added here arrives on an installed device without a new build. That is why
+`flet-box-docs` carries a version of its own: it is a shipping app, and its
+`npm run build` refuses to bundle until `src/constants.js` states both versions
+out loud — the app's own, which must match its `package.json`, and the framework
+release its pages describe.

package/docs/arquitectura.md

@@ -161,4 +161,4 @@ and strips dev warnings from the shipped output. See
 - [Routing](guides/router.md)
 - [Utilities](guides/utilities.md)
 - [Frontend services](guides/frontend-services.md)
-- [Contributing](CONTRIBUTING.md)
+- [Contributing](../CONTRIBUTING.md)

package/docs/cli/README.md

@@ -2,13 +2,13 @@
 
 The FletBox CLI helps you create, run, expand, and build FletBox applications from the terminal.
 
-You do not need to create every folder by hand. The CLI can create a working project, add screens and components, start a development server, and prepare a production bundle.
+You do not need to create every folder by hand. The CLI can create a working project, add screens and components, start a development server, prepare a production bundle, and check the code against the API the installed framework really has.
 
 ## Before you start
 
 Install:
 
-- Node.js 18 or newer.
+- Node.js 20.9 or newer.
 - npm.
 - A terminal such as Terminal, iTerm, PowerShell, or the VS Code terminal.
 
@@ -21,14 +21,17 @@ npm --version
 
 ## Install FletBox
 
-Inside the FletBox package directory:
+FletBox is published to npm, so the CLI is one install away:
 
 ```bash
-npm install
-npm link
+npm install -g flet-box
 ```
 
-After linking, the `flet-box` command is available globally on your computer.
+Or run it without installing anything globally — `npx` fetches the same package:
+
+```bash
+npx flet-box create my-app
+```
 
 Check that it works:
 
@@ -37,12 +40,22 @@ flet-box --version
 flet-box --help
 ```
 
-When using the published package, install it in a project with:
+Inside a project the framework itself is an ordinary dependency:
 
 ```bash
 npm install flet-box
 ```
 
+Cloning the repository and linking it is the exception, and it is for people
+editing the framework:
+
+```bash
+git clone https://github.com/kuko53348/flet-box.git
+cd flet-box
+npm install
+npm link                          # the `flet-box` command now points at this checkout
+```
+
 ## Your first project
 
 Create a project with the default template:
@@ -84,9 +97,12 @@ CI:      .github/workflows/build.yml publishes the web to GitHub Pages on every
 ```
 
 The first positional argument is always the project name; a flag that arrives
-before it is read as the name. Without `--repo` nothing is invented — the
-placeholder stays in both files and the workflow says which two to edit. The
-reason the workflow log, not the header, is the authority on the live address is
+before it is read as the name. Without `--repo` nothing is invented: the
+placeholder stays in `fletbox.config.json` and in the workflow header, and the
+header says which part of it is still a guess. `flet-box createBundle` reads that
+placeholder as "not configured" and derives the real Pages address from the
+project, so the manifest is never aimed at a host that does not exist. The reason
+the workflow log, not the header, is the authority on the live address is
 explained in [The Pages address of a generated app](../guides/online-updates.md).
 
 ## Project templates
@@ -574,6 +590,156 @@ alongside the app, and that file says so.
 The full contract — the 21 rules, every finding code, and how to fix one — is
 [Chapter 12, Clean UI](../guides/clean-ui.md).
 
+## Look up the API the app really has
+
+`flet-box check-api` reads your own `src/` and reports every name that does not
+belong to the installed package: a widget that does not exist, a prop the real
+widget never reads, a widget called with a positional string instead of a props
+object, an import from another framework, and a broken import between two of your
+own modules — the last two resolved statically, so it works offline and in CI.
+
+It imports the package's barrel for real and reads its own types, so it cannot
+judge your code against an API you do not have.
+
+```bash
+flet-box check-api                      # scan ./src
+flet-box check-api --props Button       # print one widget's real props
+flet-box check-api --list               # print every public export
+flet-box check-api --emit-api           # write .fletbox/api/cheatsheet.md
+flet-box check-api --json               # the findings as data
+flet-box check-api --root ../my-app     # scan another project
+```
+
+Aliases: `flet-box check`, `checkApi`, `doctor`. It exits `1` when it finds an
+error, which is what lets it be the `api` gate inside `flet-box verify` and the
+`npm run check` a created app ships.
+
+`--emit-api` writes the cheatsheet an assistant should read before it writes any
+code for the app: every widget, every prop the package can prove, and a prop that
+has been renamed marked `(deprecated → onPress)` — the old spelling still works,
+so nothing else will tell you it is the one being retired. `flet-box create`
+generates the file at scaffold time; after a version bump, regenerate it with the
+command above. It is the API at that version, not the one you remember.
+
+## Unpack a widget
+
+Every prop lives in four places, and they can disagree: the type declaration, the
+engine's prop registry, the widget's own source, and its doc page.
+`flet-box unpack <Widget>` cross-checks the four and labels each disagreement
+instead of hiding it:
+
+| Label | What it means |
+| --- | --- |
+| `DEAD` | Declared in the interface, routed by the engine nowhere and read by the widget nowhere — writing it has no effect. |
+| `INVENTED` | The widget reads it, and no interface declares it. |
+| `UNDOCUMENTED` | The engine handles it for this widget and the interface hides it — the editor underlines a call that works. |
+| `DOC-ONLY` | The doc page promises it and the code has never heard of it. |
+| `CODE-ONLY` | The code accepts it and the doc page never mentions it. |
+
+```bash
+flet-box unpack Button                  # what Button really accepts, prop by prop
+flet-box unpack Button --example        # a paste-ready call using only verified props
+flet-box unpack Modal --diff            # declared vs real, and what disagrees
+flet-box unpack Button --json           # the same contract as data
+flet-box unpack --all                   # every widget → .fletbox/api/api.json
+flet-box unpack --all --md              # and the readable api.md beside it
+flet-box unpack --all --json            # the whole surface on stdout, writing nothing
+flet-box unpack Button --root ../my-app # read another project's package
+```
+
+`--example` is the answer to "what can I paste". It is built only from props the
+four surfaces agree on, never carries a renamed one, samples no blind `width` or
+`height` (a number pasted into `Switch` collapses it), and never drops a required
+prop — so the call it prints runs.
+
+`--all` writes the whole verified surface to `.fletbox/api/api.json`, the file a
+created app's assistant reads as data; `--md` puts `api.md` beside it and
+`--json` prints the same tree to stdout instead of writing anything. `npm run
+api` in a created app is `unpack --all --md`.
+
+## Verify everything at once
+
+`flet-box verify` is the single command: it parses every module, then runs the
+anti-hallucination check, the type check (the project's own `jsconfig.json`
+through TypeScript — the same service the editor uses, so a widget declared as
+a bare `HTMLElement` and the `widget.update({ … })` call it rejects are a gate
+failure with a line, not a squiggle to be ignored), the clean-UI check, the
+structural check and the prop contract **in parallel**, and then runs whichever
+test scripts the project declares — one report, one exit code. It is the command
+to run after every edit: the report names the gate, the file at `line:column`
+and what to do about it, instead of making you run seven commands and remember
+which one failed.
+
+```bash
+flet-box verify                  # every gate and every suite, one report
+flet-box verify --only syntax    # one gate: syntax | api | types | ui | structure | surface | tests
+flet-box verify --only tests     # the project's own suites, nothing else
+flet-box verify --fix            # the mechanical repair first, then the gates
+flet-box verify --json           # the report as data
+flet-box verify --watch          # re-runs the fast gates on every edit (no suites)
+flet-box verify --no-tests       # the static gates only; run the suites yourself
+flet-box run --verify            # the same, while the dev server runs
+```
+
+Every generated app ships it as `npm run verify`. The gates read the installed
+package, so they cannot judge your code against an API you do not have.
+
+The gates, and what each one owns:
+
+| Gate | What it proves |
+| --- | --- |
+| `syntax` | Every module loads. Each `.js`/`.mjs`/`.cjs` outside `node_modules`, `www` and `dist` is handed to `node --check` — the parser the runtime uses — and a parse error is reported at `file:line:column` with the offending source line, a caret under the character and a hint: an unclosed brace, a backtick that never closes, a smart quote that only looks like a quote. |
+| `api` | The code only names widgets and props that exist, and its own modules resolve each other. |
+| `ui` | The code is on the tokens, on the scale, and every control has a name. |
+| `structure` | Two of your modules do not import each other in a circle, every module lives where the project expects it, and no screen writes the DOM by hand. |
+| `surface` | Every prop a widget reads is declared, and every declared prop is read. |
+| `tests` | The project's own suites run and pass. `test`, `test:browser` and `test:visual` are run one after another when `package.json` declares them; a failing suite's own last output is the finding, which is where the rule is named. A project that declares none — a generated app — gets a skipped step, not a green one. |
+
+The parse gate runs first because the other four read code as text. A file that
+does not load is a line, not a finding about an invented prop, and telling the
+two apart is the difference between one edit and a guess.
+
+Every finding prints the same four things: the file at `line:column`, the code,
+what is wrong and a `→` suggestion. Warnings are printed too, under *what to
+review* — they do not fail the run, but they name the same line, which is the
+only form in which an agent can act on them.
+
+`--fix` runs `flet-box audit-fix` first: it rewrites what it can prove — a
+mistyped prop, a wrong relative path, a missing import — and then the gates
+read the result. A typo is mechanical, and it should never reach you as work
+to do.
+
+## The north metric
+
+Every `flet-box verify` run appends a row to the project's log —
+`.fletbox/metrics/generations.md` for a generated app, `metrics/generations.md`
+for this repository — with the time, the project, whether the gates were green,
+which gates failed and which codes they reported. **Every** run, green or not: a
+log that keeps only the successes cannot tell a correction from a first try.
+
+```bash
+flet-box metrics                  # the metric and the failures that recur
+flet-box metrics --log <file>     # read another log
+```
+
+A **generation** is a run of failing rows closed by the first green one. The
+**north metric** is the share of generations whose *first* run was green — the
+share of code that passed the gate with no correction at all. It is the number
+that moves when the code gets better, not when the report gets softer.
+
+The same command prints the three failures that recur most often and the rule
+each one should belong to, and it **exits non-zero** when a code has come back
+three times with no rule behind it. That is the loop closing: a code that keeps
+coming back is a rule that has not been written yet.
+
+The log also holds a **Gate defects** table. A code written there with its
+window — the first and the last day it explains — is the framework's debt, not
+the project's correction: those runs are left out of the metric, never asked to
+justify a rule, and printed on their own (`fixed`, or `⚠ OPEN`). A run after the
+window's last day counts again, so an old row can never silence the same mistake
+coming back. The table is data in the log, not a list inside the command: a
+project records what it proved, and the next release cannot rewrite its past.
+
 ## Command reference
 
 
@@ -607,6 +773,21 @@ The full contract — the 21 rules, every finding code, and how to fix one — i
 | `flet-box check-ui` | Runs the clean-UI gate over `src/`: tokens, scale, tap targets, labels, contrast. |
 | `flet-box check-ui --tokens` | Prints the measured contrast of every color token, on the background and on the surface. |
 | `flet-box check-ui --strict` | Makes the contrast warnings fail the run, not just the errors. |
+| `flet-box check-api` | Checks that every widget, prop and import your code names really exists. |
+| `flet-box check-api --props <Widget>` | Prints the real props of one widget. |
+| `flet-box check-api --list` | Prints every public export. |
+| `flet-box check-api --emit-api` | Writes `.fletbox/api/cheatsheet.md`, the API an assistant reads first. |
+| `flet-box unpack <Widget>` | Cross-checks a widget's four surfaces and labels what disagrees. |
+| `flet-box unpack <Widget> --example` | Prints a paste-ready call built only from verified props. |
+| `flet-box unpack <Widget> --diff` | Prints the reconciliation alone: declared vs real, and what disagrees. |
+| `flet-box unpack --all` | Writes the whole verified surface to `.fletbox/api/api.json`. |
+| `flet-box unpack --all --md` | Adds the readable `api.md` beside it. |
+| `flet-box verify` | Runs every gate at once: one report, one exit code. |
+| `flet-box verify --no-tests` | The static gates only, for a pipeline that runs the suites in their own jobs. |
+| `flet-box verify --fix` | Runs the mechanical repair first, then the gates. |
+| `flet-box metrics` | Reads the project's log: the north metric and the failures that recur. |
+| `flet-box audit-fix` | Rewrites what it can prove: a broken import, a mistyped prop, a renamed prop. |
+| `flet-box audit-fix --only migrations` | Applies only the renames from [the migration guide](../guides/migration.md). |
 | `flet-box pkg` | Opens the package manager. |
 | `flet-box --version` | Shows the CLI version. |
 | `flet-box --help` | Shows the command list. |
@@ -636,9 +817,17 @@ For normal application development, `npm install flet-box` is usually enough.
 
 ### `flet-box: command not found`
 
-The CLI is not linked or installed globally. From the FletBox package directory, run:
+The CLI is not installed globally. Install the published package:
+
+```bash
+npm install -g flet-box
+```
+
+If you are working from a clone of the framework instead, link that checkout so the
+command points at the code you are editing:
 
 ```bash
+cd flet-box
 npm install
 npm link
 ```
@@ -690,6 +879,7 @@ npm install --save-dev esbuild
 - Learn the basics in [Start here](../widget/START_HERE.md).
 - Learn complete app structures in [Build your first FletBox app](../guides/app-templates.md).
 - Explore every widget in the [widget documentation](../widget/README.md).
+- Ask "where is the work?" with [the AI toolkit](../guides/ai-toolkit.md) — `flet-box report`, `flet-box tools`, `flet-box mcp`.
 
 ---
 

package/docs/guides/README.md

@@ -16,6 +16,12 @@ This directory is the **conceptual index** of FletBox: how to build apps, set up
 - **[Accessibility](accessibility.md)** — Chapter 13 · the focus ring, the
   keyboard pass over every press, the roles and states the widgets declare, and
   the overlays that hold the keyboard.
+- **[Migrate an app to a newer FletBox](migration.md)** — Chapter 14 · what
+  changed between releases, the "de X a Y" table, and the codemod that writes
+  the new names for you.
+- **[The AI toolkit](ai-toolkit.md)** — Chapter 15 · the map from a question to
+  the command (`flet-box tools`), the per-file diagnosis (`flet-box report`), and
+  the same tools over MCP stdio (`flet-box mcp`).
 - **[Widget structure](widget-structure.md)** — the canonical, modular shape every widget follows (and how new ones are added).
 
 ## Appendices (Advanced — for shipping)

package/docs/guides/accessibility.md

@@ -158,6 +158,7 @@ is already in place; the table exists so you know what not to duplicate.
 | `Switch` | `switch` | `aria-checked` |
 | `Checkbox` | `checkbox` | `aria-checked` |
 | `Radio` / `Rating` | `radio` / `radiogroup` | `aria-checked` |
+| `ThemePicker` | `radiogroup` / `radio` | `aria-checked`; one Tab stop per swatch, and Enter or Space picks |
 | `Slider` | `slider` | `aria-valuemin`, `aria-valuemax`, `aria-valuenow`, `aria-orientation` |
 | `ProgressBar`, `CircularBar` | `progressbar` | `aria-valuemin`, `aria-valuemax`, `aria-valuenow`, `aria-busy` while indeterminate |
 | `Dropdown` | `combobox` | `aria-expanded`, `aria-controls`, `aria-activedescendant`, `aria-invalid`, `aria-labelledby` |
@@ -276,7 +277,7 @@ forbids. The runtime half lives in `/tests/a11y.html`.
 ## Continue reading
 
 - **Previous:** [Clean UI](clean-ui.md) — Chapter 12
-- **Next:** [Minify and protect a FletBox build](minification-and-protection.md) — Appendix A
+- **Next:** [Migrate an app to a newer FletBox](migration.md) — Chapter 14
 - **Index:** [Guides index](README.md) · [The FletBox Book](../README.md)
 
 You are reading **Chapter 13 · Accessibility**.