[argszero]

Summary

The "上架 → 分享收益" flow in docs/user-stories.md describes the life of a listed key as: put it up, earn on it, then pause it or take it down. That is not the life it has. Item 1 of the same list already names what a listing carries, and every one of those settings can be changed afterwards — which matters most precisely to someone deciding whether to list a key at all, because a mistyped quota or time window is not a dead end.

Three carriers in the current tree:

• src/routes/sharing.rs — PatchSharingReq takes status, provider, plan, model, key, quota, available, note, each optional and applied as req.X.unwrap_or(cur.X), so an omitted field is left untouched. The module header states it plainly: the PATCH edits a listed key with "all the settings from listing time … a partial update: omitted fields are not modified". The double_option shim in the same file exists only because of the edit form — its comment describes clearing the time window from the editing UI to mean "all day".
• ui/js/app.js — editingShareId carries the in-page edit mode, and the form title switches to share.form.editTitle when editing.
• ui/js/i18n.js — share.form.editTitle ("编辑共享" / "Edit listing") in both packs, and share.edit.ok spells out the blank-key rule.

The blank-key rule is the one fact a reader cannot infer from item 1: entering a new upstream key replaces the stored one, while leaving it empty keeps the existing ciphertext. Without that, an operator who wants to fix a quota has no way to know whether the edit will demand the secret again.

Change

One line, item 3: the key can be edited after listing, a blank key keeps the stored one, and pausing / taking it down are still there. Item 1 is untouched — it already enumerates the settings, and repeating them here would duplicate the list rather than add anything.

This line predates the capability: editing a listed key shipped through the completed work order of 2026-09-30T13:12:07 (PRs #333 and #334), and the sentence was simply never revisited. So this changes no behaviour and settles no argument about the code — only the sentence that describes it.

Tests

• cargo fmt --check — clean
• cargo clippy --all-targets — no warnings
• cargo test — 579 passed, 0 failed

No gate reads docs/user-stories.md (the only mention under src/ is a source comment in gift.rs), so there is no test to add for a documentation-only change.

Related Issue

None — self-contained documentation fix.