sftwrdotdev · PathGao · Aug 12, 2026 · Aug 12, 2026 · Aug 12, 2026 · Aug 12, 2026
diff --git a/README.md b/README.md
@@ -75,7 +75,7 @@ The two Windows files differ only in that one installs and one does not — `-se
 
 > After a direct `.dmg` (macOS), `*-setup.exe` (Windows NSIS) or `.AppImage` (Linux) install, Markpad self-updates from GitHub releases via the in-app *Check for Updates…* entry (macOS app menu, or Settings elsewhere). Chocolatey and Snap keep Markpad current through those package managers instead.
 >
-> **`.deb` and `.rpm` are one-time installs.** `tauri-plugin-updater` cannot replace a package-managed install, and there is no apt or dnf repository to update from — upgrading means downloading a newer package from the releases page. *Check for Updates…* will report that a newer version exists but cannot install it ([#570](https://github.com/sftwrdotdev/Markpad/issues/570)).
+> **`.deb` and `.rpm` are one-time installs.** `tauri-plugin-updater` cannot replace a package-managed install, and there is no apt or dnf repository to update from — upgrading means downloading a newer package from the releases page. *Check for Updates…* recognises a package-managed install and tells you so.
 
 ## What Markpad renders
 

diff --git a/README.zh-CN.md b/README.zh-CN.md
@@ -74,7 +74,9 @@ sudo snap install markpad
 
 两个 Windows 文件的区别只在装不装：`-setup.exe` 会把 Markpad 装进 Program Files 和开始菜单，不带 `-setup` 的那个放哪儿就在哪儿运行。
 
-> 通过 `.dmg`（macOS）、`*-setup.exe`（Windows NSIS）或 `.AppImage`（Linux）直接安装之后，Markpad 会通过应用内的 *检查更新…*（macOS 在应用菜单，其它平台在设置里）从 GitHub 发行版自更新。Snap、Chocolatey、`.deb` 和 `.rpm` 的用户请继续通过各自的分发渠道更新。
+> 通过 `.dmg`（macOS）、`*-setup.exe`（Windows NSIS）或 `.AppImage`（Linux）直接安装之后，Markpad 会通过应用内的 *检查更新…*（macOS 在应用菜单，其它平台在设置里）从 GitHub 发行版自更新。Snap 和 Chocolatey 的更新由这两个包管理器负责。
+>
+> **`.deb` 和 `.rpm` 是一次性安装。** `tauri-plugin-updater` 替换不了由包管理器装上的文件，也没有 apt 或 dnf 源可以更新 —— 升级要去发行页面下载新的安装包。*检查更新…* 会认出这类安装并直接告诉你。
 
 ## Markpad 能渲染什么
 

diff --git a/RELEASING.md b/RELEASING.md
@@ -30,7 +30,7 @@ The build workflow reads both at signing time on macOS, Windows, and Linux runne
 
 ### 3. Send the public key content
 
-Send the **single-line content** of `~/.tauri/markpad-updater.key.pub` (no comments, no header lines) to the developer who'll commit it to `src-tauri/tauri.conf.json` under `plugins.updater.pubkey`. This already happened for the current keypair — the committed value is the live public key, not a placeholder — so steps 1–3 are kept as history for anyone who ever has to redo the setup. While the field held a placeholder, auto-update was inert: the app surfaced a clean error state instead of contacting the update server.
+Send the **single-line content** of `~/.tauri/markpad-updater.key.pub` (no comments, no header lines) to the developer who'll commit it to `src-tauri/tauri.conf.json` under `plugins.updater.pubkey`. The committed value is the live public key — steps 1–3 are here for whoever has to redo the setup, not for the next release.
 
 ### 4. CRITICAL: the pubkey is permanent
 
@@ -56,11 +56,13 @@ So: **do not create a repository named `Markpad` under `alecdotdev`, do not fork
 
 The failure is quiet and unfixable from here: `latest.json` 404s, the updater reports no update available, and users on old versions simply stop being offered new ones. It is not a code-execution risk — the pinned `pubkey` means whoever serves that URL cannot produce a signature that installs.
 
-**`build.yml` checks this before creating a release.** It fetches that URL and asserts the feed's download URLs still name this repository, so it tests what actually matters rather than whether a repository exists at the old location — occupying it while serving a correct feed would pass, correctly. A network failure warns instead of blocking.
+**`build.yml` checks this before creating a release.** It fetches that URL and asserts the feed's download URLs still name this repository. A network failure warns instead of blocking.
 
 ## Per-release workflow
 
-The workflow uses `npm ci`, so its installed dependency graph is exactly the committed lockfile. Do not replace it with `npm install` in release jobs. The same applies to [`snapcraft.yaml`](snapcraft.yaml), which builds the snap outside GitHub Actions; `scripts/releaseWorkflow.test.ts` guards both.
+The workflow uses `npm ci`, so its installed dependency graph is exactly the committed lockfile. Do not replace it with `npm install` in release jobs. `scripts/releaseWorkflow.test.ts` guards that.
+
+[`snapcraft.yaml`](snapcraft.yaml) builds nothing. It packages the `.deb` the release already shipped (`plugin: dump`, `source-type: deb`), so the snap carries the same binary as the `.deb` and the AppImage. The same test asserts it is packaging rather than building.
 
 1. **Bump the version:**
    ```bash
@@ -71,8 +73,7 @@ The workflow uses `npm ci`, so its installed dependency graph is exactly the com
    `[package].version`, and the `Markpad` entry in
    [`src-tauri/Cargo.lock`](src-tauri/Cargo.lock). The lock is the one that gets
    forgotten by hand: nothing in the editing loop reads it, so a bump without it
-   lands green and stays wrong until someone's `cargo build` rewrites the line.
-   That is how the 2.7.2/2.7.3 skew was found, one release after it shipped.
+   lands green and stays wrong.
 
    It stops there. Committing, tagging and dispatching stay below, on purpose.
 2. **Commit, tag, push:**
@@ -84,6 +85,9 @@ The workflow uses `npm ci`, so its installed dependency graph is exactly the com
 3. **Trigger the workflow:**
    - GitHub UI: Actions → "Build and Release" → Run workflow → master
    - Or CLI: `gh workflow run build.yml --ref master`
+
+   Only one release build runs at a time — a second dispatch queues behind the
+   first instead of racing it to the same draft.
 4. **Wait** ~30 min for matrix builds to finish, plus ~2 min for `generate-update-feed`.
 5. **Open the draft release** on the [Releases page](https://github.com/sftwrdotdev/Markpad/releases). Verify the assets:
    - **macOS**: `*.dmg`, `*.app.tar.gz`, `*.app.tar.gz.sig`
@@ -92,17 +96,7 @@ The workflow uses `npm ci`, so its installed dependency graph is exactly the com
    - **Linux**: `*.deb`, `*.rpm`, `*.AppImage`, `*.AppImage.sig`
    - **Update feed**: `latest.json` (one entry per successfully built platform)
 6. **Click "Publish release"** — this is the gate. It activates auto-update for all clients pointing at `releases/latest/download/latest.json`, **and** it starts [`publish-packages.yml`](.github/workflows/publish-packages.yml), which pushes to Chocolatey and the Snap Store.
-7. **Watch `Publish Packages` finish.** Two independent jobs; either can fail without affecting the release that already went out. Re-run the failed job after fixing, or run the workflow by hand with the tag as input.
-
-### Why package managers publish after the release, not during the build
-
-Chocolatey and the Snap Store used to be pushed from inside `build.yml`'s platform matrix, so an irreversible external side effect happened *before* anything decided whether a release existed.
-
-That is not hypothetical. Chocolatey's `markpad-app` 2.7.2 was published at 15:37 UTC on 2026-08-07 by run `31192564528` — a run that then failed on Linux and produced no release. The release users actually got came out of a different run three hours later. A Chocolatey version cannot be un-pushed.
-
-Both steps also carried `continue-on-error: true`, which turned a dead channel into a green check: the snap build failed from v2.6.11 onward and the Snap Store went on serving 2.6.11 for three months and six versions, while every release told people to `sudo snap install markpad`. Neither job swallows a failure now. `scripts/releaseWorkflow.test.ts` holds both properties.
-
-`publish-packages.yml` also takes `workflow_dispatch` with a tag, so it can be exercised against an already-published release without cutting a new one — worth doing after any change to `snapcraft.yaml` or the Chocolatey packaging, since neither is reachable from a pull request.
+7. **Watch `Publish Packages` finish.** Two independent jobs, neither swallowing a failure; either can fail without affecting the release that already went out. Fix, then re-run it with the tag as `workflow_dispatch` input — that path also works against an already-published tag, which is the only way to exercise `snapcraft.yaml` or the Chocolatey packaging without cutting a release, since neither is reachable from a pull request.
 
 ## First auto-update-capable release
 
@@ -116,7 +110,7 @@ Mention this clearly in the release notes for the first auto-update-capable vers
 
 - **macOS** uses one universal binary (`darwin-aarch64` + `darwin-x86_64` share the same `.app.tar.gz` and signature).
 - **Windows** uses NSIS — the auto-updater downloads `*-setup.exe` (verified by `*-setup.exe.sig`) and runs it in `passive` install mode. The existing raw portable `.exe` distribution path is preserved alongside, so users who download the portable `.exe` directly continue to work; only the auto-updater path uses the NSIS installer.
-- **Linux**: only `AppImage` users get auto-updates — `tauri-plugin-updater` doesn't support `.deb` or `.rpm`, and there is no apt or dnf repository either. `.deb` and `.rpm` are therefore one-time installs: those users upgrade by downloading a newer package. *Check for Updates…* still offers them the update and then fails to install it, because `__TAURI_BUNDLE_TYPE` is not patched into the Linux binary and every Linux package therefore takes the AppImage install path — see #570. This is stated in the README as well; if a repository is ever published, both change together.
+- **Linux**: only `AppImage` users get auto-updates — `tauri-plugin-updater` doesn't support `.deb` or `.rpm`, and there is no apt or dnf repository either. `.deb` and `.rpm` are therefore one-time installs: those users upgrade by downloading a newer package, and the app's *Check for Updates…* tells them so rather than offering one. This is stated in the README as well; if a repository is ever published, both change together.
 - **Snap / Chocolatey**: independent distribution channels, published by `publish-packages.yml` after the release is published. Their update mechanisms are unaffected. The Chocolatey package wraps the release's own `Markpad_<version>_x64.exe` rather than a second build, which is what `packaging/choco/tools/VERIFICATION.txt` promises.
 
 ## Troubleshooting
@@ -128,8 +122,8 @@ Mention this clearly in the release notes for the first auto-update-capable vers
 | `latest.json` missing entirely | The `generate-update-feed` job didn't run — usually because no `*.sig` files were uploaded. Check the `Upload * Artifacts` steps. |
 | Users don't see the update | (1) Did you click *Publish release*? Drafts aren't visible to clients. (2) Is the user on a version older than the first auto-update-capable release? They need a one-time manual reinstall. |
 | Update download succeeds but install fails with signature error | Pubkey mismatch — the Secrets and `tauri.conf.json` `pubkey` belong to different keypairs. |
-| `Strip host-coupled libraries from AppImage` fails | Run [`scripts/strip-appimage.sh`](scripts/strip-appimage.sh) locally against the AppImage from the draft release — it needs no signing key. It failed in two of the three v2.7.2 attempts, once because `signer sign` had a stray flag and once because it was reading the deprecated `TAURI_PRIVATE_KEY` names on a CLI too old to accept the current ones. |
-| `Publish Packages` / snap job fails | Read the snapcraft error rather than re-running: `Environment validation failed for part 'markpad'` means the `rust-deps` part in `snapcraft.yaml` is gone or renamed. Fix, then re-run the workflow with the tag as `workflow_dispatch` input. |
+| An AppImage check fails | Three scripts run against it and the log says which: [`check-appimage-libraries.sh`](scripts/check-appimage-libraries.sh) (what it bundles), [`strip-appimage.sh`](scripts/strip-appimage.sh) (removing the host-coupled ones), [`smoke-appimage.sh`](scripts/smoke-appimage.sh) (whether it starts). All three run locally against the AppImage from the draft release; no signing key, no FUSE. |
+| `Publish Packages` / snap job fails | Read the snapcraft error rather than re-running. `snapcraft.yaml` only unpacks a `.deb`, so the two live failures are: the job did not put `markpad.deb` next to it (the message names the path), or the `snapcraft` snap the runner installs changed under us — the job prints `snap list snapcraft`. Fix, then re-run with the tag as `workflow_dispatch` input. |
 | `Publish Packages` / chocolatey job fails on push | A version can only be pushed to Chocolatey once. If it is already there, nothing needs doing; if it is not, check `CHOCO_API_KEY`. |
 
 ## Out of scope (not handled by this workflow)

diff --git a/samples/markdown-syntax.md b/samples/markdown-syntax.md
@@ -147,6 +147,10 @@ A list item can hold anything:
 - [ ] An unfinished one
   - [ ] Nested, and also clickable
 
+**The editor writes the markers.** Press `Enter` inside an item and the next line carries the same one: a bullet keeps the character it was written with, a numbered item increments, a task item arrives unticked. `Tab` and `Shift`+`Tab` change the level. `Enter` on an item with nothing in it clears the marker and leaves the list, which is how you get out.
+
+A list can also be started from the keyboard: `Ctrl`/`Cmd` + `Shift` + `8` for bullets, `7` for numbers, `9` for a task list.
+
 ## 4. Quotes and alerts
 
 > An ordinary blockquote.
@@ -260,6 +264,18 @@ An empty cell is written with two pipes — `| 1 || 3 |` — which is why the sp
 |---|---|---|
 | 1 || 3 |
 
+**None of that has to be typed by hand.** With the caret in a table:
+
+| Key | Does |
+|---|---|
+| `Tab` / `Shift`+`Tab` | move to the next / previous cell — `Tab` in the last one appends a row |
+| `Ctrl`/`Cmd` + `Enter` | insert a row below, `Shift` for above |
+| `Ctrl`/`Cmd` + `Shift` + `C` | insert a column |
+| `Ctrl`/`Cmd` + `Shift` + `Backspace` | delete the column |
+| `Ctrl`/`Cmd` + `Alt`/`Option` + `T` | insert a table to begin with |
+
+Every edit reformats the table, so the pipes stay lined up — including in CJK text, where a character is two columns wide. To delete a row, delete its line. The rest of the table commands are in the command palette (`F1`).
+
 ## 7. Thematic breaks
 
 Three or more of `-`, `*` or `_` on their own line, all the same rule:
@@ -285,6 +301,8 @@ The [CommonMark spec][spec] and the [GFM spec][gfm] disagree in about twenty pla
 
 A link to a heading in this document: [back to the table](#what-is-supported-and-what-travels). Type `](#` in the editor and Markpad completes the headings for you.
 
+`Ctrl`/`Cmd` + `K` inserts a link around whatever is selected.
+
 ### Wikilinks
 
 Markpad understands Obsidian's spelling and rewrites it before rendering:

diff --git a/samples/markdown-syntax.zh-CN.md b/samples/markdown-syntax.zh-CN.md
@@ -149,6 +149,10 @@ HTML 实体也认：&copy; &mdash; &hellip; &#8594; &amp;
 - [ ] 未完成
   - [ ] 嵌套的也能点
 
+**标记由编辑器替你写。** 在列表项里按 `Enter`，下一行会带上同样的标记：符号列表沿用你写的那个字符，有序列表编号递增，任务项默认未勾选。`Tab` 和 `Shift`+`Tab` 换层级。在一个空的列表项上按 `Enter` 会清掉标记、离开列表——这是走出列表的方式。
+
+列表也可以直接用键盘起头：`Ctrl`/`Cmd` + `Shift` + `8` 符号列表、`7` 有序列表、`9` 任务列表。
+
 ## 4. 引用与提示框
 
 > 普通的引用块。
@@ -262,6 +266,18 @@ const nested = true;
 |---|---|---|
 | 1 || 3 |
 
+**这些都不用手敲。** 光标在表格里时：
+
+| 按键 | 作用 |
+|---|---|
+| `Tab` / `Shift`+`Tab` | 跳到下一个 / 上一个单元格——在最后一格按 `Tab` 会补一行 |
+| `Ctrl`/`Cmd` + `Enter` | 在下方插入一行，加 `Shift` 是上方 |
+| `Ctrl`/`Cmd` + `Shift` + `C` | 插入一列 |
+| `Ctrl`/`Cmd` + `Shift` + `Backspace` | 删掉这一列 |
+| `Ctrl`/`Cmd` + `Alt`/`Option` + `T` | 从头插入一张表 |
+
+每次编辑都会重排整张表，竖线始终对齐——中日韩字符按两列宽算，所以中文表格也齐。要删掉一行，把那一行删掉就是。其余的表格命令在命令面板里（`F1`）。
+
 ## 7. 分隔线
 
 `-`、`*` 或 `_` 三个以上单独成行，三种是同一条线：
@@ -287,6 +303,8 @@ ___
 
 指向本文档某个标题的链接：[回到那张表](#支持什么以及走得出去多远)。在编辑器里输入 `](#`，Markpad 会把标题列出来给你选。
 
+`Ctrl`/`Cmd` + `K` 给选中的文字套上链接。
+
 ### Wikilink
 
 Markpad 认识 Obsidian 的写法，并在渲染前把它改写成标准链接：

diff --git a/snapcraft.yaml b/snapcraft.yaml
@@ -60,9 +60,11 @@ parts:
   # left to go wrong, because none of it is here.
   #
   # `markpad.deb` is put next to this file by the job that runs snapcraft:
-  # .github/workflows/publish-packages.yml takes it from the release being
-  # published, and .github/workflows/test_snap.yml from the latest release.
-  # Missing, snapcraft fails at pull with the path in the message.
+  # .github/workflows/publish-packages.yml, which takes it from the release
+  # being published. That is the only thing that executes this file — #601
+  # removed the pull-request check — so a change here is first run against a
+  # published tag. Missing, snapcraft fails at pull with the path in the
+  # message.
   markpad:
     plugin: dump
     source: markpad.deb