whats-new drafts from player-facing notes first (whatsNew.source, docs/RELEASE-<version>.md, the CHANGELOG section of the version or Unreleased; --release, --from-git) and only then from the git log; internal jargon warnings (SDK / vendor names, developer and version-control words, file paths, issue ids, code identifiers) with plain alternatives in the draft and whats-new check, one list in cli/lib/jargon.ts, whatsNew.allowWords keeps a word; skill: write from what players feel, never from commit messages; tests

This commit is contained in:
CRTkafa 2026-10-14 14:45:19 +08:00
parent e9507d8884
commit bab3f63227
9 changed files with 287 additions and 21 deletions

View file

@ -5,12 +5,30 @@ description: Write user-facing release notes ("What's new") for a mobile app or
# What's new (release notes)
CLI: `storebound whats-new [--since v1.2.0] [--dry]`. It reads `git log <tag>..HEAD`, drops housekeeping commits
CLI: `storebound whats-new [--since v1.2.0] [--release 1.2.0] [--dry]`. It takes a player-facing source when one exists (below); otherwise it reads `git log <tag>..HEAD`, drops housekeeping commits
(chore, ci, docs, refactor, test, merges, version bumps), turns `feat:` / `fix:` / `perf:` subjects into bullets and
writes a draft into the default language of `store/listing.md` (Play "What's new") and `store/appstore.md`
(`whatsNew`). Nothing is sent to a store. `--all` writes the draft into every language as a starting point for
translation; `storebound check` warns while a translation is still identical to the source.
## Where the text comes from
Write from what players feel, never from commit messages. Commit subjects are written for developers ("Umami
telemetry", "refactor save endpoint", SDK and tool names); players care about what they see and feel ("Levels load
faster", "Your progress is saved more reliably"). So the draft comes from a player-facing source first, the first
that exists:
1. `whatsNew.source` in the config (a notes file; a CHANGELOG-like file gives the version's `## <version>` section),
2. `docs/RELEASE-<version>.md`,
3. the `CHANGELOG.md` section of the version, else its `## Unreleased` section.
The version is `--release 1.2.0`, else `package.json`. Only without any of these (or with `--from-git`) the draft is
built from `git log`; treat that draft as raw material and rewrite every line. If a project keeps a developer
changelog, add a short player-facing `docs/RELEASE-<version>.md` instead of reusing commit-speak.
The draft and `whats-new check` warn about internal jargon (never blocking): SDK / vendor names (Umami, Sentry,
Firebase, Capacitor, Tauri, Jenkins, Forgejo, ...), developer words (telemetry, refactor, endpoint, payload, API,
CI, PR, OTA, fingerprint, bump, deps, ...), version-control words (commit, merge, revert), file paths, issue ids and
code identifiers (`saveSlot`, `max_lives`). Each warning names the word and a plain alternative. Rewrite the line;
when a flagged word is a real player-facing term (a character called "Sentry"), add it to `whatsNew.allowWords`.
## Write it for your users
1. Run `storebound whats-new --dry`, read the draft with the owner.
2. Rewrite: