Record 1.0.0 as shipped and verified

.azure/pipelines/build-whiteboard.yaml

@@ -68,6 +68,11 @@ trigger:
     # that is byte-identical to the one before it.
     - installer/winget
     - scripts/build-release-manifests.ps1
+    # The same reasoning, one file rather than the folder: the rest of installer/msix is
+    # the package manifest and its assets, which do go into a build. The listing text is
+    # a record of what was typed into Partner Center by hand and is read by nothing.
+    - installer/msix/STORE-LISTING.md
+    - scripts/verify-published-site.ps1
 
 # Pull requests are validated by .github/workflows/pull-request.yml, unsigned. Without this,
 # Azure DevOps validates every pull request against a GitHub repository by default, which

TODO.md

@@ -28,9 +28,10 @@ itself as `site/teaser-av1.mp4` / `site/teaser-h264.mp4` — the Vimeo-embed pla
 reversed, see decision 19 in [docs/decisions.md](docs/decisions.md); the production
 script and staging assets are in `docs/teaser/`. The release manifests and the Store
 submission are done and proven: the manifests are live at
-<https://whiteboard.sqlbi.com/stable.json>, and the pipeline's Store stage carried 0.9.5
-through certification unattended, which was the last part of the chain never exercised
-end to end. winget is the one piece still waiting, below. All of it is described in
+<https://whiteboard.sqlbi.com/stable.json>, and the pipeline's Store stage has carried
+two releases through certification unattended. The install-side verification list was
+walked in full for 1.0.0, which was the last part of the chain that had only ever been
+reasoned about. winget is the one piece still waiting, below. All of it is described in
 [docs/release-management.md](docs/release-management.md).
 
 ## Waiting on the first winget submission
@@ -44,16 +45,3 @@ token it needs is set.
 Until that pull request merges, `.github/workflows/publish-winget.yml` fails on every
 release, because `wingetcreate update` has no previous version to read. That failure is
 visible and gates nothing.
-
-## Before promoting 1.0.0
-
-The build, signing, and publishing chain is proven. What has never been done for a real
-release is everything that involves installing the result — `signtool verify` on each
-MSI, install, upgrade and uninstall for each scope, opening a `.wboard` by double-click,
-released and pre-release side by side, and a clean machine for SmartScreen. The list is
-in [docs/release-management.md](docs/release-management.md) under "Verification before a
-public release".
-
-It mattered less through 0.9.x, when a version number invited nobody to install fresh.
-1.0.0 does, so the list is worth walking before the Release stage is approved rather
-than after.

docs/decisions.md

@@ -203,10 +203,13 @@ Three constraints shape it:
   followed (full-trust desktop package, file-type associations in the manifest).
 - Store version numbers must end in `.0`. The MSIX Identity Version is `VersionPrefix.0`,
   not the four-part assembly stamp the MSI uses.
-- Certification takes hours to days, so submission must never gate the web release. The
-  Store stage runs after Release rather than beside it: the GitHub release already exists
-  by the time it starts, so a failed or slow submission changes nothing that shipped, and
-  a build that was never promoted is never submitted.
+- Submission must never gate the web release. Certification took hours to days when this
+  was decided and now runs in under an hour unattended, which changes how long the Store
+  lags the download rather than the reasoning: it is still someone else's queue, it can
+  still stall or reject, and none of that should be able to hold up a release that is
+  already built and signed. The Store stage runs after Release rather than beside it, so
+  the GitHub release already exists by the time it starts, a failed or slow submission
+  changes nothing that shipped, and a build that was never promoted is never submitted.
 
 The first submission was manual, and was made on 20 August 2026 for 0.9.2: listing,
 screenshots, and age rating are one-time work no pipeline performs.

docs/release-management.md

@@ -325,7 +325,8 @@ command line ends up in shell history.
 The **Store** stage of the Azure pipeline submits the released MSIX to Partner Center. It
 depends on **Release**, so it runs only for a build that was actually promoted, and only
 after the GitHub release exists — by the time a submission can fail, every download is
-already published. Certification takes hours to days and gates nothing (decision 13).
+already published. Certification runs unattended in under an hour, and gates nothing
+either way (decision 13).
 
 `UseMSStoreCLI@0` installs the [Microsoft Store Developer CLI][msstore]; `msstore
 reconfigure` authenticates with the `SQLBI-StoreSubmission` group, and `msstore publish`
@@ -371,8 +372,13 @@ release without touching the Store.
 
 ### Verification before a public release
 
-The build, signing, and publishing chain is proven (see above). What has **not** been done
-for a real release is everything that involves installing the result.
+Walked in full for 1.0.0, which is the first release it was done for. Everything above is
+proven by every release that ships; this list is the part that had only ever been reasoned
+about, because nothing before it installs the result.
+
+Worth repeating whenever the installer authoring changes, since that is what these steps
+actually exercise — a missing shortcut, a file association an uninstall left behind, or
+SmartScreen on a fresh reputation are invisible to every check that runs earlier.
 
 - `signtool verify /pa /v` on each MSI.
 - Install, upgrade, and uninstall for each scope; confirm uninstall removes the install

installer/msix/STORE-LISTING.md

@@ -128,8 +128,10 @@ record of them and a change here means a change made by hand in Partner Center.
 
 ## The listing is live
 
-0.9.5 completed certification and is published. The Store ID gives the public
-addresses:
+1.0.0 is published. Certification now runs in under an hour and needs nobody,
+so a promoted release reaches the Store the same day rather than the same week —
+which is why the pipeline submitting it unattended is the whole of the work.
+The Store ID gives the public addresses:
 
 - `https://apps.microsoft.com/detail/9NN5N0L2TMTF`
 - `ms-windows-store://pdp/?ProductId=9NN5N0L2TMTF` (opens the Store app)