LobeHub Release (20260427)【免费下载链接】lobehub LobeHub is your Chief Agent Operator, organizing your agents into 7×24 operations by hiring, scheduling, and reporting on your entire AI team.项目地址: https://gitcode.com/GitHub_Trending/lo/lobehub- 日期格式固定为 YYYYMMDD取自发布当天 - 前缀 与 long-form 版本保持一致用于快速辨识这是一次发布说明。 ### 3.2 Scope 行替代指标行 markdown **Hotfix Scope:** Agent topic-switching regression — stale chat state on agent change这是热修复模板独有的字段一行概括回归影响范围。它取代了长式说明里的Release Date/Since vX.Y.Z指标行。按照 release-notes-style.md Hotfix Checklist 的约束这一行应描述回归所在的用户行为域而不是内部实现细节例如这里写的是Agent 主题切换回归——切换 Agent 时残留陈旧聊天状态。3.3 引语thesis Clears residual topic state when navigating between agents and restores blank-canvas behavior on agent switch.单段 1~2 行用面向使用者的口吻描述修复后恢复了什么。示例中即清除在 Agent 间导航时残留的主题状态恢复切换 Agent 时的空白画布行为。判断准则不写内部机制写用户重新获得的能力。3.4## Whats Fixed## Whats Fixed - **Stale topic on agent switch** — Switching from /agent/agt_A/tpc_X to /agent/agt_B no longer leaves the previous topics messages on screen, and _Start new topic_ responds again. (#14231) - **Header sidebar consistency** — Conversation header now shows the active subtopics title, and the sidebar keeps the parent topics thread list expanded while a thread is open.约束要点每条 bullet 的格式固定为**症状** — 一句话修复说明. (#PR)先加粗描述用户可见的症状再用一句话说明修复后的行为最后用(#PR)关联 PR条数限制在1~3 条覆盖一次回归的完整修复面示例用第 2 条补充了同一次回归在头部标题与侧边栏线程树上的连带修复不写根因长文。patch-release-scenarios.md第 2 节明确写道No long root-cause section — that lives in the commit message根因分析属于 commit message 的职责发布说明里只需症状 修复结果。示例中第一条对应#14231演示了从一个话题会话/agent/agt_A/tpc_X切换到另一个 Agent/agent/agt_B后屏幕不再残留上一话题的消息开始新话题功能恢复正常这是典型的状态清理缺失型回归适合用热修复发布。3.5## ⚙️ Upgrade## ⚙️ Upgrade - Self-hosted: pull the new image and restart. No schema or env changes. - Cloud: applied automatically.面向操作者的升级指引通常分成两行自托管Self-hosted明确需要执行的动作拉取新镜像并重启以及是否涉及 schema 或环境变量变更——若本次热修复涉及 DB 迁移则应改用changelog-example/db-migration.md变体并单列迁移说明而不是简单一句无 schema 变更云Cloud一般标注已自动应用applied automatically。3.6## Owner## Owner {pr-author}只列一位修复作者。文档末尾的备注给出了严格约束[!NOTE]: Replace{pr-author}with the actual PR author. Retrieve viagh pr view number --json author --jq .author.login. Do not hardcode a username.即作者必须是通过 GitHub CLI 实时查询得到的实际 PR 作者而不是凭记忆硬编码的用户名。同样的约束在 patch-release-scenarios.md 中再次强调Use the actual PR author ... never hardcode a username。3.7 模板快速自检清单release-notes-style.md 末尾为 Hotfix 专门整理了一份 checklist可当作发文前的最终校验**Hotfix Scope:**行替代了指标行引语描述恢复了什么面向 operator 而非内部细节## Whats Fixed有 1~3 条每条格式为**症状** — 修复.(#PR)且 PR 号已验证存在并已合并## ⚙️ Upgrade注明自托管动作与云自动应用## Owner为单个handle通过gh pr view $PR --json author解析未包含 Highlights / 领域分块 / Contributors / Full Changelog。四、发布说明的撰写输入全部来自 git绝不靠记忆热修复说明同样受 release-notes-style.md Computing Inputs (Hard Rules) 的约束其核心警告非常直白Hallucinated PR numbers and wrong Since v... bases are the #1 failure mode of this skill. Every number and every(#XXXX)must come fromgit, never from memory or inference.对热修复场景尤其关键的两条PR 号必须来自真实 commit subject。正文中出现的每个(#XXXX)都应能从实际提交信息中提取到禁止根据功能描述猜测 PR 号。官方给出的提取方式是先计算对比基线再枚举 commit subjectgit fetch origin main canary --tags PREV_TAG$(git describe --tags --abbrev0 origin/main --match v*.*.* --exclude *-canary* --exclude *-nightly*) git log $PREV_TAG..HEAD --prettyformat:%s --no-merges | grep -oE \(#[0-9]\)$ | sort -u作者 handle 与 git 作者名不一致例如 commit author name 为YuTengjingGitHub handle 是tjx666。因此一律通过gh pr view number --json author --jq .author.login解析真实 handle不得把%an输出直接当 handle 使用。此外为什么热修复的版本基线要重新从 main 计算而非沿用上一次周发布的 tag因为热修复会以v2.1.54 → v2.1.55 → …的形式直接合并进 main再通过sync-main-to-canary回流到 canary若沿用上一个周发布的 tag 作为对比基线就会漏算中间插入的所有热修复导致版本号与变更统计错误。五、源码佐证一合并即触发自动 patch 1 的 CI 判定链写好的发布说明将作为 PR body 合并进main随后由 CI 决定是否发版。触发逻辑可以在 .github/workflows/auto-tag-release.yml 中看到完整实现。该 workflow 监听pull_request_target的closed事件且限定main分支并在github.event.pull_request.merged true第 17 行时继续执行。判定顺序分两级Minor Release精确版本PR 标题匹配^ release: v(数字.数字.数字...)$第 35~43 行时直接采用标题中的版本号Patch Release自动 patch 1两级优先级第 45~69 行优先级 1分支名匹配只要head.ref以hotfix/*或release/*开头就触发绕过标题判定第 56~60 行优先级 2标题前缀兜底标题以style/feat/fix/refactor/hotfix/build前缀开头含 gitmoji 变体如 fix:、 hotfix:即触发第 63 行其余前缀docs、chore、ci、test等合并进 main 不触发发版。对热修复而言开发者不需要在 PR 标题里写版本号。patch 版本的解析在 Resolve patch version 步骤第 85~101 行完成CURRENT_VERSION$(node -p require(./package.json).version) # 先规整为稳定基线如 2.0.0-beta.1 - 2.0.0再 bump patch- 2.0.1 BASE_VERSION$(npx -y semver7 ${CURRENT_VERSION} -c) NEXT_VERSION$(npx -y semver7 -i patch ${BASE_VERSION})合并后依次执行改写package.json版本并以 chore(release): release version v{x.y.z} [skip ci]提交第 176 行→ 生成 annotated taggit tag -a v$VERSION ...第 194 行→ 用softprops/action-gh-release创建 GitHub Release第 201~219 行→ 派发sync-main-to-canaryworkflow 把 main 回流同步到 canary第 221~227 行。由此可以看出规则不要手动改 package.json、不要手动打 tag的由来整个版本号演进与 tag 创建都由该 workflow 接管人为介入反而会造成与 CI 状态不一致。六、源码佐证二hotfix:branch一键脚本的完整执行流手动操作的分支创建、推送、PR 创建也可以全部交给仓库内置脚本完成。package.json中声明的命令为hotfix:branch: tsx ./scripts/hotfixWorkflow/index.ts【免费下载链接】lobehub LobeHub is your Chief Agent Operator, organizing your agents into 7×24 operations by hiring, scheduling, and reporting on your entire AI team.项目地址: https://gitcode.com/GitHub_Trending/lo/lobehub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考