chore: back-merge main into develop

.agents/skills/bump-version/SKILL.md

@@ -1,14 +1,14 @@
 ---
 name: bump-version
 description: >
-  Set the laud version across every package.json and promote the CHANGES.md
+  Set the ailoud version across every package.json and promote the CHANGES.md
   Development section to a released Version section, then create the release
   commit. Does not tag or push.
 ---
 
 # bump-version
 
-Bump the laud version and prepare the release commit. Tagging and pushing
+Bump the ailoud version and prepare the release commit. Tagging and pushing
 remain separate, deliberate steps.
 
 ## Steps
@@ -44,7 +44,7 @@ Run `git diff` and confirm the version bump touched exactly these files:
   `## Development`).
 
 No other files changed. There is no `Cargo.toml` and no
-`tauri.conf.json` in this project -- laud is a pure TypeScript workspace.
+`tauri.conf.json` in this project -- ailoud is a pure TypeScript workspace.
 
 ### 4. Create the release commit
 

.agents/skills/check-dependencies/SKILL.md

@@ -0,0 +1,141 @@
+---
+name: check-dependencies
+description: >
+  Audit npm dependencies for known vulnerabilities, report who asks for
+  funding, and update what is behind -- refusing any version published less
+  than 14 days ago unless it fixes a critical advisory. Run before every
+  release and after any dependency change.
+---
+
+# check-dependencies
+
+Three questions, in this order: is anything we depend on known to be
+vulnerable, who is asking to be paid for it, and what should be updated.
+Updating comes last because the first two decide what an update is for.
+
+## Steps
+
+1. **Look for known vulnerabilities.**
+
+   ```bash
+   pnpm audit            # everything, including the dev toolchain
+   pnpm audit --prod     # only what the three published packages ship
+   ```
+
+   Read them separately. A high-severity advisory in a test runner is a
+   different problem from one in `commander`: the first cannot reach a user,
+   the second is installed on their machine. Fix the `--prod` findings first
+   and say which list a finding came from.
+
+2. **Report funding.**
+
+   ```bash
+   npm fund
+   ```
+
+   `pnpm` has no `fund` command; `npm fund` reads the installed tree and works
+   in this workspace. The list is long and almost all of it is the dev
+   toolchain. What is worth surfacing is the intersection with what actually
+   ships:
+
+   ```bash
+   npm fund --json | node -e '
+     let s = "";
+     process.stdin.on("data", (d) => (s += d)).on("end", () => {
+       const names = [];
+       const rec = (n) => {
+         for (const [name, child] of Object.entries(n.dependencies ?? {})) {
+           names.push(name);
+           rec(child);
+         }
+       };
+       rec(JSON.parse(s));
+       const runtime = new Set();
+       for (const p of ["packages/core", "packages/providers", "apps/cli"]) {
+         Object.keys(require(`./${p}/package.json`).dependencies ?? {}).forEach((k) =>
+           runtime.add(k),
+         );
+       }
+       console.log(names.filter((n) => runtime.has(n)).join(", ") || "(none)");
+     })'
+   ```
+
+   Report the count and that intersection. Do not open funding pages or
+   install anything.
+
+3. **See what is behind.**
+
+   ```bash
+   pnpm outdated -r
+   ```
+
+   Nothing here is urgent by default. A version bump is worth taking when it
+   fixes something this project hits, closes an advisory from step 1, or keeps
+   a major version from drifting far enough to become a project of its own.
+   "It is newer" is not a reason.
+
+4. **Apply the 14-day rule BEFORE updating anything.**
+
+   ```bash
+   node scripts/check-dependency-age.mjs
+   ```
+
+   A compromised release is discovered by other people, and that takes days --
+   every npm supply-chain incident in recent memory was caught within a week
+   or two of publication, after everyone who upgraded immediately had already
+   installed it. Waiting costs nothing: there is no urgency in a patch that
+   has been out for two weeks that was not there on day one.
+
+   So a candidate version younger than 14 days is not taken. Pin the previous
+   one and come back to it.
+
+   **Unless it fixes a critical or high advisory.** Then waiting is the worse
+   risk -- a known exploit beats an unaudited release. Record the decision in
+   `scripts/dependency-age-exceptions.json` with the advisory ID:
+
+   ```json
+   {
+     "some-package@2.0.1": "fixes GHSA-xxxx-yyyy-zzzz (critical), 2026-09-05"
+   }
+   ```
+
+   The exception is a statement about one moment, so the check reports entries
+   that have aged out and should be deleted. Never add one to silence the
+   check for convenience; if there is no advisory ID, there is no exception.
+
+5. **Update carefully.**
+
+   One concern per commit, so a regression is bisectable:
+
+   ```bash
+   pnpm update --latest <package>      # or edit the manifest and pnpm install
+   ```
+
+   - Keep versions **exact**. This project pins them; a range hands the
+     decision to whatever resolved last, and the age check cannot judge it.
+   - Run the `check-licenses` skill if any `package.json` changed -- a new
+     version can change its licence.
+   - Run the `run-tests-and-linters` skill. A dependency update that passes
+     nothing is not an update.
+   - A user-visible consequence goes in CHANGES.md; a toolchain bump does not.
+
+6. **Verify the result.**
+
+   ```bash
+   pnpm audit --prod
+   node scripts/check-dependency-age.mjs
+   ```
+
+   Both must pass. Report what changed, what was deliberately left behind and
+   why, and any advisory that remains open with the reason it cannot be closed
+   yet.
+
+## Do not
+
+- Do not run `pnpm audit --fix` or `npm audit fix`. They resolve to whatever
+  is newest, which is the version the 14-day rule exists to refuse.
+- Do not update a major version as part of a release. It is its own change,
+  with its own testing.
+- Do not treat a clean `pnpm audit` as proof of anything beyond "no advisory
+  has been published". Most of what the age rule protects against has no
+  advisory yet.

.agents/skills/check-docs/SKILL.md

@@ -22,11 +22,17 @@ release, or right after adding or changing a CLI command or option.
    - Confirm every `pnpm` command shown in README.md exists as a script in
      the root `package.json` (`pnpm lint`, `pnpm typecheck`, `pnpm test:cov`,
      `pnpm build`, `pnpm format:check`, `pnpm test:e2e`, etc.).
-   - Confirm every `laud` CLI command shown (`import`, `transcribe`, `ls`,
-     `show`, `doctor`) is a command M1 actually ships, per the "Project
-     Overview" section of AGENTS.md. `laud` has no `search`, `collection`,
-     `tag`, `summarize`, `export`, or `config` command yet; flag any of
-     those names if they appear in README.md or AGENTS.md.
+   - Confirm every `ailoud` command shown really exists, by asking the
+     BINARY rather than any prose:
+     `node apps/cli/dist/bin/ailoud.js --help` after `pnpm build`, then
+     `--help` on each group and verb. AGENTS.md says outright not to trust a
+     list of commands in prose over the binary, and this skill used to name a
+     fixed set of commands and assert that `search` and `summarize` did not
+     exist -- both had shipped long before anyone noticed the skill was
+     telling agents otherwise.
+     Note that zsh does NOT word-split an unquoted variable, so `$cmd --help`
+     with `cmd="audio ls"` passes one argument and commander prints the
+     TOP-LEVEL help, making every subcommand look like it has no flags.
    - Confirm every relative link in README.md and AGENTS.md resolves to a
      file that exists in the repository. Links into `.superpowers/` are a
      defect: that directory is git-ignored and absent from a fresh clone.
@@ -45,7 +51,13 @@ release, or right after adding or changing a CLI command or option.
 5. **Check version references.**
    Search `README.md`, `AGENTS.md` and `CONTRIBUTING.md` for version
    strings. Any hardcoded version must match the version in root
-   `package.json`. This project ships no documentation site.
+   `package.json`.
+
+   This project DOES ship a documentation site: `docs/` built with mkdocs and
+   published per release to `gh-pages`. Build it with `pnpm docs:build`
+   (strict) and check the rendering with `node scripts/check-docs-render.mjs`
+   -- the strict build cannot see an admonition whose content fell outside its
+   box, which has shipped here before.
 
 6. **Check CHANGES.md structure.**
    Confirm the file starts with a `## Development` section and that

.agents/skills/check-fixtures/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: check-fixtures
 description: >
-  Drive the built laud binary against fixtures/ end to end -- import,
+  Drive the built ailoud binary against fixtures/ end to end -- import,
   transcribe, ls, show, and doctor -- in a throwaway HOME, XDG_CONFIG_HOME,
   and XDG_DATA_HOME, and confirm the working tree stays clean afterward.
 ---
@@ -10,7 +10,7 @@ description: >
 
 The unit tests cover the domain core against fakes (`MemFs`, `FakeClock`,
 `FakeIds`, `FakeStt`). This skill covers the layer they cannot: the real
-`laud` binary, against real audio, writing to a real filesystem (inside a
+`ailoud` binary, against real audio, writing to a real filesystem (inside a
 sandbox). It is the only check that would catch a regression living in the
 wiring between the CLI, the providers, and the filesystem -- for example a
 provider writing to the wrong data directory, or a pipeline that behaves
@@ -28,14 +28,14 @@ right lens" below.
 Three short fixtures, each with a reference transcript: an English clip, a
 Russian clip, and a clip that mixes both languages. The suite drives:
 
-- `laud doctor` against a sandbox with no config, and again after
+- `ailoud doctor` against a sandbox with no config, and again after
   configuring the model.
-- `laud import` against a fixture file, including the "already present"
+- `ailoud import` against a fixture file, including the "already present"
   path on a repeat import.
-- `laud transcribe`, checked by word error rate against the reference
+- `ailoud transcribe`, checked by word error rate against the reference
   transcript rather than exact string equality -- a model or quantization
   change shifts wording by a word or two without being a regression.
-- `laud show` in both `srt` and `json` formats, plus its error paths (a
+- `ailoud show` in both `srt` and `json` formats, plus its error paths (a
   missing id, an unsupported `--format`).
 
 ## Isolation
@@ -44,7 +44,7 @@ The suite must never touch the developer's machine state. Every invocation
 of the built binary sets all three of:
 
 - `XDG_CONFIG_HOME`, which relocates `config.yaml`.
-- `XDG_DATA_HOME`, which relocates `laud.db` and the `media/` tree.
+- `XDG_DATA_HOME`, which relocates `ailoud.db` and the `media/` tree.
 - `HOME`, so nothing the process resolves relative to the real home
   directory (for example a fallback default when an XDG variable is
   unset) can reach outside the sandbox.

.agents/skills/check-licenses/SKILL.md

@@ -11,7 +11,7 @@ description: >
 
 Verify that every direct npm dependency is license-compatible with
 Apache-2.0 and keep the Third-Party Notices section of `LICENSE` up to
-date. `laud` is a pure TypeScript pnpm workspace -- there is no cargo
+date. `ailoud` is a pure TypeScript pnpm workspace -- there is no cargo
 workspace to check, unlike the source repository this project inherits its
 conventions from.
 
@@ -71,7 +71,7 @@ dependencies` subsection's table -- replace from its `| Package |`
    | <name> | npm | <version> | <spdx> | <copyright> |
    ```
 
-   Every row's Ecosystem column is `npm` -- laud has no other dependency
+   Every row's Ecosystem column is `npm` -- ailoud has no other dependency
    ecosystem. List rows alphabetically by package name. Preserve
    everything above the table verbatim: the Apache 2.0 license text, the
    `## Third-Party Notices` heading, and the intro paragraph above the