v1.0.1

Added

• Screen readers hear the nav, sidebar and pager labels in the page's
  language (VitePress writes them in English): the build writes them into
  each page's HTML, and theme/aria-labels.js sets them again after each
  navigation, from ariaLabels in locales.js.
• The Support page links to Patreon, in the four languages, and
  .github/FUNDING.yml puts the Sponsor button on the repository.
• The site counts visits with Cloudflare Web Analytics, which sets no cookies
  and collects no personal data; Google Tag Manager is gone.
• The language switcher goes to the same page in the other language when it
  is translated, and to that language's home otherwise — in every direction.
  The pages it knows come from TRANSLATED in docs/.vitepress/locales.js
  (and the translated pages under a listed section such as /cookbook/);
  tests/docs/test_language_switch.py checks that each is a page and that
  every translated page is reachable.
• A translated page records the English page it came from and the hash of its
  text (source: / source_hash:). When the English changes, the page says
  "this translation may be out of date" with a link to the English, and CI
  lists the stale pages (scripts/translation-status.py; --stamp after
  updating a translation). tests/docs/test_translations.py checks that every
  translation names an English page that exists and is in its language's
  navigation.
• The site speaks four languages: English, and /pt/ (pt-BR), /es/ and
  /zh/ (zh-CN), with a language switcher and each language's interface text;
  the pages are translated next. The top nav is Home · Docs (Guide, Tutorial,
  Reference, SPEC) · Showcase · Blog · Changelog · Status · Sponsor. Search
  splits Chinese into words (it found nothing inside a Chinese sentence), and
  each page carries hreflang alternates and Open Graph tags.

Documented

• The Examples page in Portuguese, Spanish and Chinese. Every live page now
  has a translation except the generated ones (Reference, SPEC, Changelog),
  which stay in English: their entries in the pt/es/zh navigation say so.

• Every quantum … command in a published page's shell block (all four
  languages) is parsed by the real command line in CI
  (tests/docs/test_docs_commands.py); the homes, the Sponsor page, the blog
  posts and the Roadmap may hold only imports of tested Cookbook files and
  such commands; the theme's example components may appear only on
  unpublished pages.

• The Blog index and Status page in Spanish and Simplified Chinese, generated
  like the Portuguese ones (LANGS in scripts/generate-site-pages.py).

• The docs' deprecated-content check caught a removed value only as written
  in code: the q:application page listed testing in its table of types and
  desktop in a list of targets, and both slipped past. It now also reads
  table rows and lists of values, has patterns for more of the changelog's
  removals (attributes of q:column, q:set, q:param, q:query and
  q:function, a slice step, the mail mock, upload URLs, removed projects,
  the admin's deploy feature), and each pattern proves it catches a sample.
  tests/docs/test_quoted_messages.py checks that a message the site quotes
  in a text block uses only words Quantum prints.

• The Tools pages (the CLI, hot reload, the /_dev panel, error pages,
  quantum check, the VS Code extension, the LSP server) and Desktop in
  Portuguese, Spanish and Chinese, and Community in Spanish and Chinese, with
  their sidebars. Headings keep the English anchors; the VS Code page is
  generated per language from the extension's manifest. Machine translated
  and marked so.

• More of the guide in Simplified Chinese: AI, files and mail, data import,
  services, sessions, the admin, project structure and q:application,
  machine-translated, with the English heading anchors.

• The q:application page no longer lists type="testing" (removed in 0.22,
  replaced by quantum test) or a --target desktop for type="ui"
  (removed in 0.16), and quotes the parser's message as it is.

• The Blog index, Status and Community pages in Brazilian Portuguese.
  scripts/generate-site-pages.py writes the translated Blog index and Status
  page (LANGS) around the same posts and the same measured tables, stamped
  with the English page's hash; the nav's Blog and Status links go to the
  translation when there is one.

• The rest of the guide in Brazilian Portuguese: AI, files and mail, data
  import, services, sessions, the admin, project structure and
  q:application — every guide page now has a pt version. The pt guide
  pages keep the English heading anchors, so a link to a section works in
  both.

• Roadmap and Community in the top nav, in every language. The Showcase in
  Portuguese, Spanish and Chinese, written by scripts/generate-showcase.py
  with the same measured numbers as the English page; the Roadmap and the
  tutorial in Chinese. All machine translated and marked so.

• The core guide in Brazilian Portuguese (/pt/guide/): getting started,
  components, how a page runs, state, loops, conditionals, functions,
  expressions, actions, queries, authentication, UI and testing,
  machine-translated, with the code and its output identical to the English
  and the same heading anchors; the pt guide sidebar has Portuguese labels.

• The core guide in Spanish and Simplified Chinese: Getting Started,
  Components, How a Page Runs, State Management, Loops, Conditionals,
  Functions, Expressions & Databinding, Actions & Forms, Database Queries,
  Authentication, One App, Many Screens and Testing an App (and, in Spanish,
  the rest of the guide: AI, Files and Mail, Data Import, Declared Services,
  Sessions, Quantum Admin, Project Structure and q:application) — machine
  translated and marked as such. The prose is translated segment by segment
  around the English page's code, which is copied as it is; each heading keeps
  the English anchor, so links to a section work in every language.

• The Cookbook in Spanish (/es/cookbook/) and Simplified Chinese
  (/zh/cookbook/): all 51 recipes, machine translated and marked as such. The
  code and results on each page are the English page's imports of the tested
  files, line for line; the prose follows each language's glossary.

• The repository's front door meets the site's bar. README's Quantum examples
  are files of Cookbook recipes, byte for byte, and its quick start is run as
  shown (tests/docs/test_readme.py, which also checks the site and file links
  of README, CONTRIBUTING, SECURITY, SUPPORT_TIERS and the Code of Conduct);
  the deprecated-content check reads those five files too. README's AI
  examples used a model name as if it were a default and an attribute
  (minRelevance) its text no longer explained; it now links the Cookbook,
  Tutorial, Reference, Showcase, Stability and Roadmap. CONTRIBUTING pointed to
  Discussions, which are off; SECURITY called 1.0 "experimental" and suggested
  an environment variable nothing reads; SUPPORT_TIERS cited two files that are
  not in the repository.

• The Cookbook in Brazilian Portuguese (/pt/cookbook/), machine-translated:
  the code and the results are the same files the English imports. The
  generator writes each language's Cookbook index (LANGS in
  scripts/generate-cookbook.py), linking the English page where a recipe is
  not translated yet. All 51 recipes are translated; a test checks that every
  translated page imports the same files as its English page, in order.

• Cookbook, "Screens": a layout that fits the screen, a table edited in
  place, tabs, cards, every kind of field, and the same page in a terminal;
  six tested recipes, two of them also checked in the console
  (tests/docs/test_cookbook_console.py).

• Cookbook, "Basics": a first page, variables and expressions, loops,
  conditionals, functions, a page per URL, the query string and reusable
  components with a slot; eight tested recipes.

• Cookbook, "AI": answers with their sources, when the documents do not know
  (minRelevance), a streamed answer, an agent over your database, when the
  model fails (onerror), sorting messages with JSON answers, and answers
  from a table; seven recipes. In CI they run against a stand-in model server
  (scripts/generate-cookbook.py); before a release, against a real one
  (tests/live_ai/test_cookbook_ai.py). Their tests check structure, never the
  model's words.

• The CLI and LSP server pages say what exists. The CLI page taught exit
  codes, environment variables and a quantum pkg uninstall that do not
  exist, and quantum start --debug as debug mode; the LSP page, a
  pip install quantum-lsp (it is not on PyPI), rename, code actions,
  options and editor packages the server does not have. The VS Code page no
  longer implies the extension runs the language server. Five old notes
  linked from no menu leave the site: a benchmark nothing reproduces, the
  q:query implementation plan and the performance-phase notes.

• The essential pages in Brazilian Portuguese (/pt/): why Quantum,
  installation, quick start, the tutorial, stability, sponsor, the roadmap and
  the 1.0 post, machine-translated until a native speaker reviews them, with a
  glossary (docs/.vitepress/i18n/glossary.pt.md) that keeps the terms the same
  on every page.

• Cookbook, "Data & SQL": a query with parameters, a paginated list, search
  as you type, filter and sort, writes that happen together (a transaction
  rolled back when its last write fails), change history, adding a column
  with a migration, reading CSV and JSON, loading a CSV into a table in one
  transaction, and totals computed over a query's result; eleven tested
  recipes.

• Cookbook, "Forms & actions": each error on its field, a refused form that
  keeps what was typed, redirect with a flash (q:flash for a warning),
  several forms on one page, a form from the table, edit a row, confirm
  before deleting, numbers and dates, and a choice from a list; nine tested
  recipes.

• Cookbook, "Login & permissions": log in with a hashed password, sign up and
  store a hash, a page for one role only, a guard that redirects (and stops the
  page's actions), and sign out; five tested recipes.

• Every xml example of the guide now runs: with the result it shows, or in
  a test that runs the page's code as written (tests/docs/test_guide_*.py);
  the docs guard's list of pages that were only parsed is empty. Running them
  fixed what they claimed: the components page said several q:returns
  returned a list (the first one ends the component, SPEC RET-1), and the
  home page's example now imports the tested "first test" recipe.

• The site in Spanish (/es/, machine translated, reviews welcome): the home,
  Why Quantum, Installation, Quick start, Stability, Sponsor, the Roadmap,
  the tutorial and the "Quantum 1.0" post. Code blocks are the English ones; the terms are in
  docs/.vitepress/i18n/glossary.es.md.

• Cookbook recipes: "When the mail server says no" (onerror="continue"),
  "Test data with test:given" (and test:as) and "Testing what an action
  refuses" (error=, message=, flash=, table=). Recipes in a topic
  keep an order (order: in the page's front matter).

• Pages that described what does not work are gone: the plugin system
  (nothing loads plugins), the package manager page (pages cannot import a
  component from an installed package; q:import from= is a folder under
  paths.components), and the HTML, terminal and mobile target pages (what
  is true about them is in the guide's "Standalone builds"). The VS Code
  extension page is generated from its manifest and says how to run it from
  source — it is not on the Marketplace.

• A Stability page (/stability/), generated from SUPPORT_TIERS.md: what 1.0
  promises, tag by tag, and the semver promise for Core and AI.

• Simplified Chinese (zh-CN) for Why Quantum, Installation, Quick start,
  Stability, Support and the "Quantum 1.0" post — machine translated, marked
  as such until a native speaker reviews them. A translated page must show
  the English code, block for block (the docs guard checks it), and the nav
  links to a translation when one exists. The zh glossary is in
  docs/.vitepress/i18n/glossary.zh.md.

• The site no longer publishes the 15 hand-written example and feature pages
  (docs/examples/*, docs/features/*) whose code did not work with 1.0: they
  taught removed attributes (persist=, maxSize=, cache=) and tags that
  never existed (q:try). The Cookbook, the Showcase and the tutorial replace
  them; the files stay in the repository to be rewritten as recipes.

• tests/docs/test_no_deprecated_content.py: a published page that shows
  something removed or renamed in the changelog (a tag, an attribute, a CLI
  command, a tier name, a default) as current fails CI. Two pages were fixed:
  the UI guide named quantum new, and the CLI reference a retired tier name.

• The hand-written ui: component pages (docs/ui/) are gone: they taught
  components that do not exist. The generated UI tags
  reference and the "One App, Many Screens" guide replace them. The Cookbook
  is in the Docs menu in all four languages.

• Tutorial, "Build the tasks app": from pip install to the app in
  projects/tarefas, in English, in eight steps (validated forms, finish and
  delete, a filter, a table that sorts and edits itself, an edit page with
  history, a quantum test suite). Each step's code is built and run as shown
  by tests/docs/test_tutorial_tasks_app.py, and the finished app is checked
  against projects/tarefas, tag by tag.

• Showcase: the seven proving apps with a screenshot of each running
  (scripts/showcase-screenshots.py, the AI apps on a stand-in model server),
  what it demonstrates, the SPEC rules it cites, its size, its tests and its
  source. The numbers are measured by scripts/generate-showcase.py, and
  tests/docs/test_showcase.py fails when the page and the apps disagree.

• The Cookbook: short recipes for one task each. A recipe is a small app in
  examples/cookbook/ with a quantum test suite; its page imports the tested
  files, and what it shows as a result is written by running it
  (scripts/generate-cookbook.py). The first two: a first test with
  quantum test, and mail in development with host: log.

• Quantum code on the site is tested: CI fails on an xml block that is not a
  run guide example, a parsed guide or generated-reference example, or on a
  page marked "Under review"; a quantum.config.yaml snippet must load
  without errors or warnings. Two snippets taught keys that do not exist.

• Every xml example on the site is checked by the real parser in CI
  (tests/docs/test_docs_xml_blocks.py); the guide's examples with a result
  are also run. 121 of 607 failed: the guide's are fixed, the editor
  illustrations are plain text, and 22 hand-written pages that document tags
  that do not exist (the ui: component pages, UI features, some example and
  target pages) say "Under review" at the top until tested examples replace
  them.

• The site has a changelog (one page per version, with stable anchors), a
  status page ("what really works today", from FEATURE_STATUS.md), a blog
  with an RSS feed and the "Quantum 1.0" post, a support page and a community
  page. scripts/generate-site-pages.py builds the derived pages, and CI fails
  if they are stale.

• The site has a Reference generated from the code (docs/reference/,
  scripts/generate-reference.py): the Core and AI tags with every attribute,
  type, value, default and the rules that specify them; the expression
  functions; the command line; the configuration keys; the ui:* tags, Core
  (UI-7) and Experimental apart, with every attribute the UI parser reads;
  and the SPEC with an anchor per rule (reference/spec#EXPR-14) that lists
  the entries citing it. A test fails when a committed page differs from what
  the generator writes. It replaces the hand-written api/tags-reference,
  api/attributes-reference and api/ui-reference pages.

• The site has a Roadmap (roadmap/): what 1.0 promises, and what is next,
  each item with its status (planned, in design, in progress) and no dates.

Fixed

• The VS Code extension packages: vsce package stopped on an icon that
  package.json named and the repository never had. The extension carries
  its icon and the MIT LICENSE, and leaves its TypeScript sources out.

• Two pages with an in-memory q:knowledge of the same name and different
  sources deleted each other's index: the other page's search failed with
  chromadb's "Collection [...] does not exist", or — at the wrong moment —
  found nothing, which reads as an honest "I don't know". In-memory bases are
  now separate by sources as well as name (IA-2), and a base that was built
  with chunks and has none when searched is an error, never found false
  (IA-6). The three most recently built in-memory versions of each base are
  kept; older ones are dropped.

• python -m quantum.cli.runner — the installation guide's way to run
  quantum without the script on PATH — no longer prints a
  RuntimeWarning before every command. quantum start --debug says what it
  does: it prints the traceback when the server fails to start; debug mode is
  server.debug in quantum.config.yaml.

• A q:query inside a q:loop or a q:if of a q:transaction datasource="…"
  takes the transaction's datasource, like one directly inside it (DB-4); it
  had to repeat datasource=, or the page did not parse.

• q:set name="cart" is local even when the session has a cart (SET-3,
  EXPR-11). It used to overwrite session.cart and leave cart undefined, so
  the page showed {len(cart)} as written.

• q:set name="session.cart" operation="append" starts a list when the key
  does not exist yet (SET-3). It was refused as "non-array": a missing scope
  key reads as ''.

• A page's extracted stylesheet and script (static/styles-<hash>.css) are
  written whole or not at all. Written in place, a second request during the
  write linked the file while it was still empty or partial, and its browser
  got an unstyled page, cached under a name that never changes.

• q:loop type="range" takes expressions in from, to and step, like any
  other {...} attribute (LOOP-5): to="{count}" was read as the text
  "{count}" — an error in a statement, zero rows in markup — and step="{n}"
  became 1. A bound that is not a whole number is now an error that names it,
  in markup too, where it used to draw zero rows.

• q:param type="date" on an action is checked on the server: 2026-02-30
  or tomorrow is refused on its field (ACT-2). Only the browser's date
  input checked it before, and any text reached the action.

• A q:param default= on an action has the param's type (ACT-2). It was
  used as text, so type="boolean" default="false" gave "false", which is
  true: an unchecked box read as checked.

• quantum run --target desktop is no longer offered: the command line says
  the target was removed and points to quantum desktop (UI-8). It used to
  accept the choice and fail later, in the build.