Version Release

Version Release Workflow

This skill is a router. The detailed steps live in references/.

Scope Boundary (Important)

This skill is only for:

1. Release branch / PR workflow 2. CI trigger constraints (auto-tag-release.yml) 3. GitHub Release note writing

This skill is not for writing docs/changelog/*.mdx.\ If the user asks for website changelog pages, load ../docs-changelog/SKILL.md.

Mandatory Companion Skill

For every /version-release execution, you MUST load and apply:

• ../microcopy/SKILL.md

Overview

The primary development branch is canary. All day-to-day development happens on canary. When releasing, canary is merged into main. After merge, auto-tag-release.yml automatically handles tagging, version bumping, creating a GitHub Release, and syncing back to the canary branch.

Only two release types are used in practice (major releases are extremely rare and can be ignored):

For writing the release-note body (any release type), see references/release-notes-style.md.

Auto-Release Trigger Rules (auto-tag-release.yml)

After a PR is merged into main, CI determines whether to release based on the following priority:

1. Minor Release (Exact Version)

PR title matches 🚀 release: v{x.y.z} -> uses the version number from the title.

2. Patch Release (Auto patch +1)

Triggered by the following priority:

• Branch name match: hotfix/* or release/* -> triggers directly (skips title detection)
• Title prefix match: PRs with the following title prefixes will trigger:
• style / 💄 style
• feat / ✨ feat
• fix / 🐛 fix
• refactor / ♻️ refactor
• hotfix / 🐛 hotfix / 🩹 hotfix
• build / 👷 build

3. No Trigger

PRs that don't match any conditions above (e.g. docs, chore, ci, test) will not trigger a release when merged into main.

Post-Release Automated Actions

1. Bump `package.json` — commits 🔖 chore(release): release version v{x.y.z} [skip ci] 2. Create annotated tag — v{x.y.z} 3. Create GitHub Release 4. Dispatch `sync-main-to-canary` — syncs main back to canary

Agent Action Guide

When the user requests a release:

Precheck (applies to all release types)

Before creating the release branch, verify the source branch:

• Weekly Release (release/weekly-*): must branch from canary
• All other release/hotfix branches: must branch from main; run git merge-base --is-ancestor main <branch> && echo OK
• If the branch is based on the wrong source, recreate from the correct base

Routing

Pick the right reference and follow it end-to-end:

• Minor release → references/minor-release.md
• Patch release (weekly / hotfix / model launch / DB migration) → references/patch-release-scenarios.md
• Writing the PR body / release notes (any release type) → references/release-notes-style.md

Hard Rules (apply to every release type)

• Do NOT manually modify package.json version — CI handles it.
• Do NOT manually create tags — CI handles them.
• Minor PR title format is strict (🚀 release: v{x.y.z}).
• Patch PRs do not need an explicit version number.
• Keep release facts accurate; do not invent metrics or availability statements. Release-note inputs (compare base, PR refs, contributor list) must be derived from `git` per references/release-notes-style.md § Computing Inputs — never from memory or descriptions.

🚀 LobeHub Release (20260416)

Release Date: April 20, 2026\ Migration Scope: Agent benchmark data model bootstrap (5 new tables, 2 new indexes)

This release introduces a schema foundation for benchmark execution and reporting, so agent evaluation data is stored as a complete lifecycle instead of fragmented records.

---

🗄️ Migration Overview

Added tables:

• agent_eval_benchmarks
• agent_eval_datasets
• agent_eval_runs
• agent_eval_run_topics
• agent_eval_records

Added indexes:

• idx_agent_eval_runs_status_created_at
• idx_agent_eval_run_topics_run_id_topic_id

These additions close a previous gap where benchmark data existed in partial forms but lacked a stable relational backbone for auditing and historical analysis.

---

⚙️ Operator Notes

• Migration runs automatically on application startup.
• No manual SQL is required in standard deployment paths.
• Schedule rollout in a low-traffic window and take a backup snapshot before deployment.
• If migration fails, do not retry repeatedly; inspect migration logs and lock state first.

---

🔒 Reliability & Risk

• Existing chat/session paths are unaffected unless benchmark features are enabled.
• Migration is additive (new tables/indexes only), minimizing downgrade risk to existing entities.
• Rollback should follow your standard DB restore or migration rollback policy if your environment requires strict reversibility.

---

👥 Owner

Migration owner: @{pr-author}

The migration owner is responsible for rollout follow-up and incident handling for this schema change.

\[!NOTE]: Replace {pr-author} with the actual PR author. Retrieve via gh pr view <number> --json author --jq '.author.login' or from commit metadata. Do not hardcode a username.

🚀 LobeHub Release (20260427)

Hotfix Scope: Agent topic-switching regression — stale chat state on agent change

Clears residual topic state when navigating between agents and restores blank-canvas behavior on agent switch.

🐛 What's Fixed

• Stale topic on agent switch — Switching from /agent/agt_A/tpc_X to /agent/agt_B no longer leaves the previous topic's messages on screen, and _Start new topic_ responds again. (#14231)
• Header & sidebar consistency — Conversation header now shows the active subtopic's title, and the sidebar keeps the parent topic's thread list expanded while a thread is open.

⚙️ Upgrade

• Self-hosted: pull the new image and restart. No schema or env changes.
• Cloud: applied automatically.

👥 Owner

@{pr-author}

\[!NOTE]: Replace {pr-author} with the actual PR author. Retrieve via gh pr view <number> --json author --jq '.author.login'. Do not hardcode a username.

🚀 LobeHub Release (20260420)

Release Date: April 20, 2026\ Since previous release: 96 commits · 58 merged PRs · 31 resolved issues · 17 contributors

This weekly release focuses on reducing friction in everyday agent work: faster model routing, smoother gateway behavior, stronger task continuity, and clearer operator diagnostics when something goes wrong.

---

✨ Highlights

• Gateway Session Recovery — Agent sessions now recover more reliably after short network interruptions, so long-running tasks continue with less manual retry. (#10121, #10133)
• Fast Model Routing — Expanded low-latency routing for priority model tiers, reducing wait time in high-frequency generation workflows. (#10102, #10117)
• Agent Task Workspace — Running tasks now remain isolated from main chat state, which keeps primary conversations cleaner while background work progresses. (#10088)
• Provider Coverage Update — Added support for new model variants across OpenAI-compatible and regional providers, improving fallback options in production. (#10094, #10109)
• Desktop Attachment Flow — File and screenshot attachment behavior is more predictable in desktop sessions, especially for mixed text + media prompts. (#10073)
• Security Hardening Pass — Closed multiple input validation gaps in webhook and file-path handling paths. (#10141, #10152)

---

🏗️ Core Agent & Architecture

Agent loop and context handling

• Improved context compaction thresholds to reduce mid-task exits under tight token budgets. (#10079)
• Added better diagnostics for tool-call truncation and recovery behavior during streamed responses. (#10106)
• Refined delegate task activity propagation to improve parent-child task status consistency. (#10098)

Provider and model behavior

• Unified provider-side timeout handling in fallback chains to reduce false failure classification. (#10097)
• Updated reasoning-model defaults and response normalization for better cross-provider consistency. (#10109)

---

📱 Gateway & Platform Integrations

• Gateway now drains in-flight events more safely before restart, reducing duplicate notification bursts. (#10125)
• Discord and Slack adapters received retry/backoff tuning for unstable webhook windows. (#10091, #10119)
• WeCom callback-mode message state persistence now uses safer atomic updates. (#10114)

---

🖥️ CLI & User Experience

• Improved slash command discoverability in CLI and gateway contexts with clearer hint messages. (#10086)
• /model switching feedback now returns clearer success/failure states in cross-platform chats. (#10108)
• Setup flow now warns earlier about missing provider credentials in first-run scenarios. (#10115)

---

🔧 Tooling

• MCP registration flow now validates duplicate tool names before activation, reducing runtime conflicts. (#10093)
• Browser tooling improved stale-session cleanup to prevent orphaned local resources. (#10112)

---

🔒 Security & Reliability

• Security: Hardened path sanitization for uploaded assets and webhook callback validation. (#10141, #10152)
• Reliability: Reduced empty-response retry storms by refining retry-classification conditions. (#10130)
• Reliability: Improved timeout defaults for long-running background processes in constrained environments. (#10122)

---

👥 Contributors

58 merged PRs from 17 contributors across 96 commits.

Community Contributors

• @alice-example - Gateway recovery and retry improvements
• @bob-example - Provider fallback normalization
• @charlie-example - Desktop media attachment flow
• @dora-example - Webhook validation hardening

---

Full Changelog: <previous-tag>...<current-tag>

Minor Release Workflow

Used to publish a new minor version (e.g. v2.2.0), roughly every 4 weeks. The PR title carries the exact version number; CI parses it to drive the rest of the release.

Steps

1. Create a release branch from canary

   git checkout canary
   git pull origin canary
   git checkout -b release/v{version}
   git push -u origin release/v{version}

2. Determine the version number — Read the current version from package.json and compute the next minor version (e.g. 2.1.x → 2.2.0).

3. Create a PR to main

   gh pr create \
     --title "🚀 release: v{version}" \
     --base main \
     --head release/v{version} \
     --body-file release_body.md

\[!IMPORTANT]

The PR title must strictly match the 🚀 release: v{x.y.z} format. CI uses a regex on this title to determine the exact version number.

4. Write the PR body as release notes — Follow release-notes-style.md. Compare base is the latest semver tag on main (git describe --tags --abbrev=0 origin/main).

5. Automatic trigger after merge — auto-tag-release detects the title format, uses the version number from the title, bumps package.json, tags v{x.y.z}, creates the GitHub Release, and dispatches sync-main-to-canary.

Scripts

bun run release:branch         # Interactive
bun run release:branch --minor # Directly specify minor

Hard Rules (specific to Minor)

• PR title format is strict: 🚀 release: v{x.y.z}. Any deviation falls through to patch detection.
• Do NOT manually modify package.json version — CI will bump it.
• Do NOT manually create the tag — CI will tag.
• Highlights bullet count is usually 8–12 (see release-notes-style.md size heuristics).

Patch Release Scenarios

All Patch Release scenarios automatically bump the patch version (e.g. 2.1.31 → 2.1.32). PR titles do not need to include a version number.

---

1. Weekly Release (canary → main)

The most common release type. Collects a week's worth of changes from canary and ships them to main.

Steps

1. Create release branch from canary

git checkout canary
git pull origin canary
git checkout -b release/weekly-{YYYYMMDD}
git push -u origin release/weekly-{YYYYMMDD}

2. Scan changes and write changelog

Compute the previous tag from main first — never reuse the last weekly's tag, since hotfixes published in between will be missed:

git fetch origin main canary --tags
PREV_TAG=$(git describe --tags --abbrev=0 origin/main --match 'v*.*.*' --exclude '*-canary*' --exclude '*-nightly*')
git log "$PREV_TAG..origin/release/weekly-{YYYYMMDD}" --oneline --no-merges
git diff "$PREV_TAG...origin/release/weekly-{YYYYMMDD}" --stat

Then follow ./release-notes-style.md § Computing Inputs (Hard Rules) to derive PR refs, metrics, and contributors. Every (#XXXX) in the body must come from actual commit subjects in this range — never inferred from descriptions.

3. Create PR to main with the changelog as the PR body

gh pr create \
  --title "🚀 release: {YYYYMMDD}" \
  --base main \
  --head release/weekly-{YYYYMMDD} \
  --body-file changelog.md

4. After merge: auto-tag-release detects release/* branch → auto patch +1.

---

2. Bug Hotfix

Emergency bug fix shipped directly from main.

Steps

1. Create hotfix branch from main

git checkout main
git pull --rebase origin main
git checkout -b hotfix/v{version}-{short-hash}
git push -u origin hotfix/v{version}-{short-hash}

2. Create PR to main with a gitmoji prefix title (e.g. 🐛 fix: description)

3. Write a short hotfix changelog — See changelog-example/hotfix.md. Keep it minimal: scope line, 1-3 fix bullets (symptom + fix in one sentence), upgrade note, owner. No long root-cause section — that lives in the commit message.

• Hotfix owner: Use the actual PR author (retrieve via gh pr view <number> --json author --jq '.author.login'), never hardcode a username.

4. After merge: auto-tag-release detects hotfix/* branch → auto patch +1.

Script

bun run hotfix:branch

---

3. New Model Launch

New AI model or provider support, typically contributed via community PRs.

How it works

• Community contributors submit PRs with titles like ✨ feat: add xxx model or 💄 style: support xxx models
• These PR title prefixes (feat / style) are in the auto-tag trigger list
• No special branch naming or manual release steps required — merging the PR triggers auto patch +1

When an agent is involved

If asked to add model support, just create a normal feature PR. The title prefix will trigger the release automatically.

---

4. DB Schema Migration

Database schema changes that need to be released independently. These require a dedicated changelog explaining the migration for self-hosted users.

Steps

1. Create release branch from main and cherry-pick migration commits

git checkout main
git pull --rebase origin main
git checkout -b release/db-migration-{name}
git cherry-pick <migration-commit-hash>
git push -u origin release/db-migration-{name}

2. Write a migration-specific changelog — See db-migration-changelog-example.md for the format. This should explain:

• What tables/columns are added, modified, or removed
• Whether the migration is backwards-compatible
• Any action required by self-hosted users
• Migration owner: Use the actual PR author (retrieve via gh pr view <number> --json author --jq '.author.login' or git log commit author), never hardcode a username

3. Create PR to main with the migration changelog as the PR body

gh pr create \
  --title "👷 build: {migration description}" \
  --base main \
  --head release/db-migration-{name} \
  --body-file changelog.md

4. After merge: auto-tag-release detects release/* branch → auto patch +1.

GitHub Release Changelog Standard (Long-Form Style)

Use this guide for GitHub Release notes — the body of a release PR that becomes the GitHub Release after merge. Do not use it for docs/changelog/*.mdx website pages (load ../../docs-changelog/SKILL.md instead).

Table of Contents

1. Positioning — what this style optimizes for 2. Required Inputs Before Writing 3. Computing Inputs (Hard Rules — Verify, Never Guess) — base ref, PR refs, metrics, authors, pre-publish verification 4. Canonical Structure (Long-Form: Minor / Weekly) 5. Variants for Shorter Releases — hotfix, DB migration 6. Writing Rules (Hard) 7. Style Rules (Long-Form) 8. Release Size Heuristics — when to use which variant 9. Contributor Ordering 10. Template — copy-paste skeleton 11. Quick Checklist — long-form + hotfix

Positioning

This release-note style is:

1. Data-backed at the top (date, range, key metrics) 2. Narrative first, then structured detail 3. Deep but scannable (clear sectioning + compact bullets) 4. Contributor-forward (credits are part of the release story)

Required Inputs Before Writing

Collect these inputs first:

1. Compare range (<prev_tag>...<current_tag>) 2. Release metrics (commits, merged PRs, resolved issues, contributors, optional files/insertions/deletions) 3. High-impact changes by domain (core loop, platform/gateway, UX, tooling, security, reliability) 4. Contributor list (with standout contributions if known) 5. Known risks / migrations / rollout notes (if any)

If metrics cannot be reliably computed, omit unknown numbers instead of guessing.

Computing Inputs (Hard Rules — Verify, Never Guess)

Hallucinated PR numbers and wrong "Since v..." bases are the #1 failure mode of this skill. Every number and every (#XXXX) must come from git, never from memory or inference.

1. Compare base = latest semver tag on main

Do not eyeball the tag list or pick the "last weekly" PR. Compute it:

git fetch origin main canary --tags
PREV_TAG=$(git describe --tags --abbrev=0 origin/main --match 'v*.*.*' --exclude '*-canary*' --exclude '*-nightly*')
echo "$PREV_TAG"

Sanity check that the tag is reachable from the release branch:

git merge-base --is-ancestor "$PREV_TAG" origin/release/weekly-{YYYYMMDD} && echo OK

If the check fails, stop and ask the user — the release branch is based on the wrong source.

Why not "the last weekly release PR"? Hotfixes (v2.1.54, v2.1.55, …) merge directly into main between weeklies. They get back-merged via sync-main-to-canary, so the latest semver tag on main _is_ the correct previous release for both weekly and minor flows. Picking the previous weekly's tag will silently undercount and put a stale version in "Since v…".

2. PR refs must come from commit subjects — never from descriptions

Compute the canonical set:

git log "$PREV_TAG..origin/release/weekly-{YYYYMMDD}" \
  --pretty=format:'%s' --no-merges \
  | grep -oE '\(#[0-9]+\)$' \
  | sort -u > /tmp/release_prs.txt

Hard rules:

• Every (#XXXX) you write in the body must appear in /tmp/release_prs.txt. No exceptions.
• Never infer a PR number from a feature description. If you remember "the KB BM25 PR was around #14501", that memory is wrong about half the time. Look up the commit hash by feature keyword and read its actual subject.
• If your terminal truncates long subjects (any wrapper that compresses output, e.g. rtk), bypass it. With rtk use rtk proxy git log …. Verify with wc -l /tmp/release_prs.txt — the count must match git log $PREV_TAG..HEAD --no-merges --pretty=format:'%h' | wc -l minus the few commits without a PR ref. A mismatch of >5% means subjects are being silently truncated.

3. Metrics must come from git counts

PR_COUNT=$(wc -l < /tmp/release_prs.txt | tr -d ' ')

COMMIT_COUNT=$(git log "$PREV_TAG..origin/release/weekly-{YYYYMMDD}" --no-merges --pretty=format:'%h' | wc -l | tr -d ' ')

CONTRIBUTOR_COUNT=$(git log "$PREV_TAG..origin/release/weekly-{YYYYMMDD}" --no-merges --pretty=format:'%an' \
  | sort -u \
  | grep -viE '^(lobehubbot|LobeHub Bot|renovate\[bot\])$' \
  | wc -l | tr -d ' ')

If a number cannot be confidently derived, omit it — never guess.

4. Author-to-handle resolution

Git %an is the commit author display name, not the GitHub handle. For each author you mention, confirm the handle:

gh pr view "$PR_NUMBER" --repo lobehub/lobe-chat --json author --jq '.author.login'

Use the result for @handle. Then classify each author per the LobeHub team roster below; community first, team after.

5. Pre-publish verification (mandatory)

Before gh pr create / gh pr edit --body-file, diff body PR refs against the canonical set:

grep -oE '#[0-9]+' release_body.md | sort -u > /tmp/body_prs.txt
sed 's/[()]//g' /tmp/release_prs.txt > /tmp/release_prs_clean.txt

echo "=== In body but NOT in actual range (must be EMPTY) ==="
comm -23 /tmp/body_prs.txt /tmp/release_prs_clean.txt

Empty diff = OK. Any output = the body cites a PR that wasn't merged in this range. Stop and fix before publishing.

Also verify the metrics line in the body matches the computed values (PR_COUNT, CONTRIBUTOR_COUNT) and that **Full Changelog** uses $PREV_TAG, not some older tag.

Canonical Structure (Long-Form: Minor / Weekly)

Follow this section order for Minor and Weekly releases unless the user asks otherwise. For Hotfix and DB Migration, see § Variants for Shorter Releases below — the canonical structure does not apply.

1. # 🚀 LobeHub Release (<YYYYMMDD>) 2. Metadata lines:

• Release Date
• Since <Previous Version> metrics

3. One quoted release thesis (single paragraph, 1-2 lines) 4. ## ✨ Highlights (6-12 bullets for major releases; 3-8 for weekly) 5. Domain blocks with optional ### subsections:

• ## 🏗️ Core Agent & Architecture (or equivalent product core)
• ## 📱 Platforms / Integrations
• ## 🖥️ CLI & User Experience
• ## 🔧 Tooling
• ## 🔒 Security & Reliability
• ## 📚 Documentation (optional if meaningful)

6. ## 👥 Contributors 7. **Full Changelog**: <prev>...<current>

Use --- separators between major blocks for long releases.

Variants for Shorter Releases

The Canonical Structure above is for long-form (Minor / Weekly). Two short-form variants override it.

Hotfix Variant

A hotfix targets one regression and ships fast. The body is short and operator-focused — no Highlights, no domain blocks, no Contributors line.

Required sections, in order:

1. # 🚀 LobeHub Release (<YYYYMMDD>) 2. **Hotfix Scope:** — one line summarizing the regression scope (e.g. Agent topic-switching regression — stale chat state on agent change). Replaces the long-form Release Date / Since vX.Y.Z metrics. 3. One quoted thesis (single paragraph, 1-2 lines) describing what is now restored. 4. ## 🐛 What's Fixed — 1-3 bullets, each **<symptom>** — <fix in one sentence>. (#PR). No root-cause prose; that lives in the commit message. 5. ## ⚙️ Upgrade — short notes for self-hosted (pull image / restart, schema or env changes) and cloud (usually "applied automatically"). 6. ## 👥 Owner — single @handle for the PR author, resolved via gh pr view "$PR" --json author --jq '.author.login'. Never hardcoded.

Hard rules specific to hotfix:

• No Highlights / domain blocks / Contributors / Full Changelog — these add noise to a one-shot fix.
• No metric line — Since vX.Y.Z doesn't apply; the body cites the single PR (or 1-3 PRs) directly.
• Owner ≠ Contributors — one author, listed under § Owner. Not a flat handle list.
• See changelog-example/hotfix.md for the canonical template.

DB Migration Variant

Database schema changes that need to be released independently. Operator impact is the headline.

Required sections, in order:

1. # 🚀 LobeHub Release (<YYYYMMDD>) + scope line 2. Migration overview — what tables / columns are added, modified, or removed 3. Operator impact — backwards-compatible? required actions for self-hosted? 4. Rollback / backup note — how to recover 5. ## 👥 Owner — single PR author, resolved via gh pr view

See changelog-example/db-migration.md for the canonical template.

Writing Rules (Hard)

1. No fabricated metrics: all numbers must be traceable. 2. No vague headline bullets: each bullet must include capability + impact. 3. No internal-only framing: phrase from user/operator perspective. 4. Security must be explicit when security-sensitive fixes are present. 5. PR/issue linkage: use (#1234) when IDs are available. 6. Terminology consistency: same feature/provider name across sections. 7. Do not bury migration or breaking changes: elevate to dedicated section or callout.

Style Rules (Long-Form)

1. Start with an "everyday use" framing, not implementation internals. 2. Mix narrative sentence + evidence bullets. 3. Keep bullets compact but informative:

• Good: **Fast Mode (/fast)** — Priority routing for OpenAI and Anthropic, reducing latency on supported models. (#6875, #6960)

4. Use bold only for capability names, not for whole sentences. 5. Keep heading depth ≤ 3 levels.

Release Size Heuristics

• Minor / major milestone release
• Long-form structure with multiple domain blocks.
• Highlights usually 8-12 bullets.
• Weekly patch release
• Long-form skeleton with reduced subsection count.
• Highlights usually 4-8 bullets.
• Hotfix release
• Short-form (see § Variants → Hotfix). No Highlights, no domain blocks, no Contributors.
• 1-3 fix bullets. Body should fit on one screen.
• DB migration release
• Short-form (see § Variants → DB Migration).
• Must include Migration overview, operator impact, and rollback/backup note.

Contributor Ordering

Render contributors as a single flat list (no separate "Community" / "Core Team" subsections). Order: community contributors first, team members after. Within each group, sort by PR count desc. Bots (@lobehubbot, renovate[bot]) go on a separate "maintenance" line.

LobeHub team roster — anyone in this list is a team member; anyone not in this list is a community contributor:

• @arvinxx
• @Innei
• @tjx666 (commit author name: YuTengjing)
• @LiJian
• @Neko
• @Rdmclin2
• @AmAzing129
• @sudongyuer (commit author name: Tsuki)
• @rivertwilight (commit author name: René Wang)
• @CanisMinor
• @cy948 (commit author name: Rylan Cai)

Resolving handles — git author names (e.g. YuTengjing) are not always the GitHub handle. Verify via gh pr view "$PR" --json author or gh api search/users -f q='<email>' before listing.

If a new contributor appears who is not on this list, treat them as community by default and ask the user whether to add them to the roster.

Template

# 🚀 LobeHub Release (<YYYYMMDD>)

**Release Date:** <Month DD, YYYY>  
**Since <Previous Version>:** <N merged PRs> · <N resolved issues> · <N contributors>

> <One release thesis sentence: what this release unlocks in practice.>

---

## ✨ Highlights

- **<Capability A>** — <What changed and why it matters>. (#1234)
- **<Capability B>** — <What changed and why it matters>. (#2345)
- **<Capability C>** — <What changed and why it matters>. (#3456)

---

## 🏗️ Core Product & Architecture

### <Subdomain>

- <Concrete change + impact>. (#...)
- <Concrete change + impact>. (#...)

---

## 📱 Platforms / Integrations

- <Platform update + impact>. (#...)
- <Compatibility/reliability fix + impact>. (#...)

---

## 🖥️ CLI & User Experience

- <User-facing workflow improvement>. (#...)
- <Quality-of-life fix>. (#...)

---

## 🔧 Tooling

- <Tool/runtime improvement>. (#...)

---

## 🔒 Security & Reliability

- **Security:** <hardening or vulnerability fix>. (#...)
- **Reliability:** <stability/performance behavior improvement>. (#...)

---

## 👥 Contributors

Huge thanks to **<N contributors>** who shipped **<N merged PRs>** this cycle.

@<community-handle> · @<community-handle> · @<team-handle> · @<team-handle>

Plus @lobehubbot and renovate[bot] for maintenance.

---

**Full Changelog**: <previous_tag>...<current_tag>

Quick Checklist

Long-Form (Minor / Weekly)

• [ ] PREV_TAG is git describe --tags --abbrev=0 origin/main (latest semver), not the last weekly's tag
• [ ] Every (#XXXX) in the body appears in /tmp/release_prs.txt (verified via comm -23)
• [ ] Since v… line uses $PREV_TAG; PR / contributor counts match wc -l on the computed sets
• [ ] **Full Changelog** uses $PREV_TAG...release/weekly-<YYYYMMDD> (or …v{x.y.z} for minor)
• [ ] Author handles resolved via gh pr view --json author, not assumed from %an
• [ ] Uses top metadata and a clear release thesis
• [ ] Includes Highlights plus domain-grouped sections
• [ ] Every major bullet states both change and user/operator impact
• [ ] Security and reliability updates are explicitly surfaced (when present)
• [ ] Contributor credits and compare range are included
• [ ] All numbers and claims are verifiable

Hotfix

• [ ] **Hotfix Scope:** line replaces metrics line
• [ ] Single quoted thesis describes what is restored (operator-facing, not internal)
• [ ] ## 🐛 What's Fixed has 1-3 bullets, each **<symptom>** — <fix>. (#PR) with PR ref verified to exist and be merged
• [ ] ## ⚙️ Upgrade notes self-hosted action and cloud auto-apply
• [ ] ## 👥 Owner is a single @handle resolved via gh pr view "$PR" --json author
• [ ] No Highlights / domain blocks / Contributors / Full Changelog included