bump-version

name	bump-version
description	Use when preparing a PlainTab release or bumping the PlainTab version, triggered by phrases like "更新版本", "bump version", "upgrade to vX.Y.Z", "发布新版本". Updates manifest.json, runtime UI/version constants, localized changelogs, store listings, release notes, validation notes, and current project docs.

Bump PlainTab Version

Purpose

Prepare a PlainTab release using the current project structure. Keep the release surface split by audience:

• docs/changelog-i18n/*.txt: one-line localized changelog summaries.
• docs/RELEASE_NOTES.md: historical detailed release notes, maintained only in Chinese and English.
• docs/GITHUB_RELEASE.md: the body text for the current GitHub Release page only.
• docs/store-listing/*.txt: Chrome Web Store descriptions, one file per language.

Do not recreate removed files such as docs/CHANGELOG.md, docs/release-note.md, or docs/requirements.md. Do not add a version badge to the root README.md; it intentionally does not use one. Localized docs/README_*.md files that already have version badges should keep that style and have the existing badge version updated.

Inputs

Ask for missing essentials only:

• Target version, for example 3.3.0.
• Release summary in Chinese or English.
• Important changes, grouped as user-facing bullets. Conventional commit lines may be used as source material, but do not expose commit tags in user-facing docs unless the user explicitly asks.

If the user does not provide release notes, derive candidate changes from git log and local diffs, then write user-facing summaries.

Style Rules

• Preserve the current document style. Before writing release copy, inspect the newest entry in each touched file and match its punctuation, bullet shape, heading level, language register, and sentence length.
• Keep product copy user-facing. Translate implementation work into outcomes; do not paste raw commit subjects, module names, storage keys, or test names unless the user asks for maintainer-facing wording.
• Keep Chinese release copy in the existing concise PlainTab tone. Do not add marketing hype, emoji, slogans, or unrelated feature explanation.
• Keep English release copy in the existing calm, compact product tone. Do not switch to a different launch-note style mid-file.
• Keep commit style aligned with the current history: Chinese Conventional Commit subject by default, for example docs: 更新版本发布资料 or chore: 准备 X.Y.Z 发布. Do not switch to English, long titles, or a different body format unless the user asks.

Step 1: Read Current State

Before editing:

• Read manifest.json and record the old version.
• Check git status --short and preserve unrelated user changes.
• Inspect existing entries in docs/changelog-i18n/en.txt, docs/changelog-i18n/zh-CN.txt, docs/RELEASE_NOTES.md, and docs/GITHUB_RELEASE.md for local tone and format.
• Inspect the latest 5 to 10 commits with git log --oneline before suggesting or creating a release commit, so the commit message keeps the current repository style.
• Search for the old version before replacing it. Classify every hit as current runtime/config/test/docs or historical release/task archive before editing.

Step 2: Runtime Version Surfaces

Update every current runtime or data version surface:

"version": "X.Y.Z"

Also update:

• index.html: first-level settings panel version text, currently .l1-version.
• js/settings-panel.js: About tab version text, currently .about-version.
• js/wallpaper/data.js: BASELINE_APP_VERSION when the release represents the current app/storage baseline.
• Current validation harnesses or task notes that assert the active baseline, for example docs/ai-tasks/*test.js.
• Current rule snapshots such as .claude/rules/README.md, .claude/rules/10-storage.md, and .claude/rules/90-storage-history.md when their baseline statements would otherwise become stale.

Do not update old version numbers in historical release entries, old changelog entries, or dated task-plan prose unless they are active validation files or current factual guidance.

Use semantic versioning language when helpful:

• Major version: breaking architecture or compatibility change.
• Minor version: substantial feature, UX, documentation, or capability update without breaking the core framework.
• Patch version: small fix or maintenance release.

Step 3: Short Localized Changelogs

Update every file in docs/changelog-i18n/*.txt.

Format:

• vX.Y.Z · One sentence covering the release.

Rules:

• Add the new entry directly below the title line.
• Keep it to one sentence or one compact line.
• Do not use sub-bullets or conventional commit tags.
• Maintain all 16 files unless the user explicitly narrows the release scope.

Language files:

en, zh-CN, zh-TW, hi, es, ar, fr, pt_BR, ru, de, ja, it, tr, vi, ko, pl.

Step 4: Detailed Release Notes

Update docs/RELEASE_NOTES.md.

This file is the detailed historical release record and is maintained only in Chinese and English. Add the new version section at the top, below the introductory note.

Format:

## vX.Y.Z

### 中文

**摘要**：中文摘要。

**更新内容**

- 中文详细条目。

### English

**Summary**: English summary.

**Details**

- English detailed item.

Rules:

• Write for users and maintainers, not as raw commit logs.
• Do not include conventional commit tags such as fix, docs, or refactor.
• Keep Chinese and English sections equivalent in meaning, not necessarily word-for-word identical.

Step 5: GitHub Release Body

Replace docs/GITHUB_RELEASE.md with only the current version's GitHub Release page body. Historical details belong in docs/RELEASE_NOTES.md.

Recommended structure:

# PlainTab GitHub Release Body

---

**PlainTab vX.Y.Z**

- Install from the [Chrome Web Store](https://chromewebstore.google.com/detail/plaintab-%C2%B7-minimal-new-ta/jhpfjcefcmooplmaimgdafohdlhacjdo) for automatic updates.
- Or download the `.crx` file below and drag it into `chrome://extensions`.

**Highlights**

- User-facing English bullet.

**Summary**

One polished English paragraph explaining what changed and why it matters.

---

**PlainTab vX.Y.Z**

- 前往 [Chrome 网上应用店](https://chromewebstore.google.com/detail/plaintab-%C2%B7-minimal-new-ta/jhpfjcefcmooplmaimgdafohdlhacjdo) 安装，可自动更新。
- 或下载下方 `.crx` 文件，拖入 `chrome://extensions` 页面即可。

**更新重点**

- 面向用户的中文条目。

**总结**

一段中文总结，说明这次更新改了什么、为什么重要。

Rules:

• This file is meant to be pasted into a GitHub Release page.
• Keep only the current release.
• Use user-facing bullets, not conventional commit tags.
• Keep the installation boilerplate stable unless the install process changes.

Step 6: Store Listing Files

Update every file in docs/store-listing/*.txt when preparing a public release.

Rules:

• Add the vX.Y.Z entry at the top of the changelog/update block.
• Use compact one-line localized summaries, matching docs/changelog-i18n/*.txt.
• Preserve each file's existing language and formatting.

Step 7: README And Project Docs

Update these only when the release changes their content:

• README.md: English project README.
• docs/README_zh-CN.md: Simplified Chinese README.
• docs/README_*.md: localized README files.
• docs/technical/README_en.md and docs/technical/README_zh-CN.md: technical docs.
• AGENTS.md and .claude/rules/: project guidance, only when durable agent instructions change.
• .agents/skills/bump-version/SKILL.md: this skill, only when release workflow or project structure changes.
• .agents/README.md: shared skill index, when skill ownership or release coverage changes.

README link rules:

• The root README.md currently has no version badge; do not add one during a bump.
• Localized docs/README_*.md files currently include version badges; update existing badge URLs and alt text when bumping the public version, but do not redesign the badge block.
• Keep the short changelog link in every README pointing to the matching docs/changelog-i18n/*.txt file.
• Keep a detailed release notes link in every README pointing to docs/RELEASE_NOTES.md.
• The detailed release notes file is bilingual only, but every localized README should still link to it so readers can discover the full history.
• Use a localized label for the link when practical; the target stays RELEASE_NOTES.md from files inside docs/, and docs/RELEASE_NOTES.md from root README files.

Do not update removed files. In the current structure, docs/requirements.md is not part of the release workflow.

Step 8: Verify

Run checks before declaring the release prep done:

Select-String -Path manifest.json,README.md,docs\*.md,docs\technical\*.md,docs\changelog-i18n\*.txt,docs\store-listing\*.txt -Pattern "OLD_VERSION" -SimpleMatch
git grep -n "OLD_VERSION" -- index.html js .claude .agents docs/ai-tasks

Expected result: no stale old-version references except intentionally historical text. Explain any remaining old-version hits and why they are historical.

Also verify:

• manifest.json, index.html, js/settings-panel.js, and js/wallpaper/data.js use the target version where they expose the current app version.
• Root README.md still has no version badge, and existing localized README version badges use the target version without changing their surrounding badge style.
• docs/CHANGELOG.md does not exist.
• docs/release-note.md does not exist.
• docs/RELEASE_NOTES.md exists.
• docs/GITHUB_RELEASE.md exists.
• At least en and zh-CN changelog/store-listing entries are correct; spot-check a few other languages when all 16 are updated.
• JavaScript touched by the version bump parses, for example node --check js\settings-panel.js and node --check js\wallpaper\data.js.

Current File Map

Purpose	Files
Extension version	manifest.json
Runtime version display	index.html, js/settings-panel.js
Storage/app baseline	js/wallpaper/data.js, .claude/rules/10-storage.md, .claude/rules/README.md, .claude/rules/90-storage-history.md, active docs/ai-tasks/*test.js assertions
Root README	README.md without a version badge
Localized READMEs	docs/README_*.md, including existing version badges
Short changelogs	docs/changelog-i18n/*.txt
Detailed release history	docs/RELEASE_NOTES.md
GitHub Release body	docs/GITHUB_RELEASE.md
Chrome Web Store copy	docs/store-listing/*.txt
Technical docs	docs/technical/README_en.md, docs/technical/README_zh-CN.md