[xycld]

What and why

Adds a 每日构建 update channel so people who want the newest build get it every morning without reinstalling, as the maintainer asked. Until now nightlies were download-only. Design and trade-offs: ADR-0014 (proposed), which amends ADR-0010.

• Its own key: NIGHTLY_UPDATE_KEYS is trusted for update-nightly.json only (trustedUpdateKeys(channel)). The key lives in a new nightly environment without a reviewer. The production key and the release environment are untouched.
• Client:
  • 每日构建 reads the nightly, beta and stable feeds and takes the newest.
  • A nightly feed may offer only -nightly. versions.
  • Leaving 每日构建 drops the nightly it offered, its minimumVersion and a nightly waiting to install. The running version stays until a steadier channel has a newer one (no downgrade).
• Old launchers:
  • install.json keeps stable/beta (RECORD_CHANNELS), because installed launchers accept nothing else and are never updated.
  • 每日构建 is saved as updateChannel: 'beta' + nightlyUpdates, and the flag counts only with beta, so rolling back to an older version reads it as 测试版 and keeps updating.
• Workflow (nightly.yml):
  • Version X.Y.Z-nightly.YYYYMMDD.<run>.
  • With MOSS_NIGHTLY_SIGNING_KEY set, the run fetches the last nightly (fetch-nightly.mjs), builds deltas from it, writes and signs update-nightly.json (make-feed.mjs --nightly) and verifies it against NIGHTLY_UPDATE_KEYS.
  • It uploads the packages to the rolling updates release, then the .sig, then the feed, and only then prunes nightlies older than the previous one.
  • Without the secret, nightlies stay download-only exactly as before.
• UI: 设置 › 通知与更新 › 更新渠道 gains 每日构建.

How it was verified

• pnpm lint: 0 errors, the same 12 warnings as main. pnpm format:check and pnpm typecheck are clean. pnpm test:unit: 3560 passed.
• pnpm test:e2e: 345 passed. update.e2e.ts now picks 每日构建 and saves the screenshot update-channel-nightly-light; the visual suite covers 设置 › 更新 in light and dark.
• pnpm test:install: PASS (Linux: install 2.0.0, update to 2.0.1, roll back from 2.0.2, uninstall).
• Docs: docs/how-to/release.md (nightly section, nightly key setup and rotation), docs/reference/architecture.md, ADR-0014 with the index and ADR-0010's amended-by, and docs/README.md.
• A separate security review found five problems, all fixed here, each with a test:
  • the prune step deleted the feed it had just uploaded;
  • after a rollback, choosing 正式版 could turn back into nightly;
  • leaving 每日构建 kept the nightly selection;
  • the settings IPC could set nightlyUpdates;
  • a nightly feed could offer non-nightly versions.
• New unit tests:
  • key scope per channel;
  • a nightly-signed stable or beta feed is rejected;
  • nightly before any production key exists;
  • leaving nightly, including when no other feed can be read;
  • the saved settings shape;
  • nightly version ordering, make-feed --nightly end to end, and prune selection.

Platforms affected

• Platform-independent (all four platforms build nightlies)

Notes for the reviewer

• Not live yet: NIGHTLY_UPDATE_KEYS is empty, so nothing changes in practice until a maintainer runs pnpm release:keygen --nightly, merges the public key and adds MOSS_NIGHTLY_SIGNING_KEY to a nightly environment limited to main (see the release how-to).
• Updates in general are not live: PRODUCTION_UPDATE_KEYS is still empty too, so no released build can update yet, on any channel.
• The workflow has not run yet: the shell was checked with shellcheck and the logic is in tested library functions, but GitHub hasn't run it. The first nightly after the key is set up is its real test.