codebee 0.1.103 → 0.1.104

package/app/core/skillpacks/market/character-bible.md

@@ -1,66 +1,66 @@
----
-name: 角色小传与人物弧光模板
-note: 角色档案模板（欲望/恐惧/语言指纹）+ 四拍弧光规划 + 连载防崩人设纪律与自检
-scopes:
-- novel
-- serial_novel
-source: market
-market_id: character-bible
----
-
-# 角色小传与人物弧光模板（市场包）
-
-适用：开书前建角色档案、连载中防人设漂移。与平台流量包互补：流量包管
-「读者为什么追」，本包管「人物为什么可信」。人设崩塌带来的流失不可逆——
-评论区第一次出现「OOC」「崩人设」时，掉的数据基本回不来。
-
-## 一、小传模板（有名有姓的角色都建档，配角用精简版）
-- **基本档案**：姓名 / 年龄 / 身份职业 / 外貌。外貌只挑 ≤3 个**有辨识度且可反复
-  使用**的特征（疤、跛、口音、总戴手套），不要「很帅」「很美」这类无法复用的词。
-- **表层目标**：TA 自己以为想要的东西（金银、复仇、上岸）。
-- **深层需求**：真正缺的东西（认同、安全感、被看见）——弧光的终点就是发现并得到它。
-- **恐惧与软肋**：最怕失去什么；软肋必须**情节可攻击**（有家人的反派才有戏可写）。
-- **创伤与信念**：一句成型的信条（如「强才能活」），角色一切非常规行为的解释源头。
-- **语言指纹**：口头禅 / 句长习惯（文绉绉还是粗短句）/ 禁用词（读书人不说粗话）/
-  称呼习惯（怎么叫主角）。这是对白区分度最硬的抓手。
-- **关系网**：与主要角色的关系各一句话 + 张力在哪（靠什么维系、因什么会破裂）。
-
-## 二、弧光规划（主角必须有，重要配角推荐）
-- 四拍结构：**起点状态**（用旧信念应对世界）→ **触发事件**（旧信念失灵的一击）→
-  **中间摇摆**（至少两次反复：尝试改变，再退回舒适区，不许直线转变）→
-  **终点状态**（新信念，且由高潮事件证明成立）。
-- 弧光要「可拍摄」：终点状态必须体现为**行为变化**（以前遇辱必怒，现在能先忍住
-  查真相），不能靠内心独白宣布「他长大了」。
-- 反派同样要逻辑自洽：反派在自己的故事里是合理的（有目标、有原则、有能力），
-  **反派不无脑**；反派降智 = 主角胜利贬值 = 全书爽点贬值。
-
-## 三、防崩纪律（连载中执行）
-- 写对白前回看该角色的「语言指纹」；**遮名测试**：不同角色的对白遮住名字能认出
-  是谁说的，认不出 = 语言指纹失败，回去改。
-- 配角也要「想要什么」：出场就带着自己的目的行动，哪怕只写一句。
-  只在剧情需要时才动的工具人，是群像发糊的根源。
-- **每 10 章回看小传**：外貌、伤势、随身物、人际关系与正文逐一核对——伤过的手
-  不能无解释痊愈，卖掉的东西不能再掏出来。
-- 能力升级必须有过程与代价；「突然会了」读者瞬间就能感知。
-- 人物相关设定要改，必须回填小传并排查前文旧描述（与一致性台账守则联动）。
-
-## 四、配角精简模板（三行建档）
-- 一句话身份 + 此刻想要什么（出场动机）。
-- 一个可复用的辨识特征（外貌 / 口头禅 / 习惯动作）。
-- 与主要角色的关系张力（靠什么维系、因什么破裂）。
-三行都填不出来 = 这个角色还不该出场；信息攒够再让他登场。
-
-## 五、小传模板示例（可直接复制）
-> **姓名**：xxx　**年龄 / 身份**：xxx
-> **表层目标**：……　**深层需求**：……
-> **恐惧软肋**：……　**信条**：……
-> **语言指纹**：口头禅……；句式……；禁语……
-> **关系网**：与主角——……；与反派——……
-> **弧光四拍**：起点…… → 触发事件…… → 摇摆…… → 终点……
-
-## 六、写作前自检
-- [ ] 本章每个出场角色都知道自己「想要什么」，行为在为目标服务
-- [ ] 对白符合各自语言指纹（遮名测试通过）
-- [ ] 主角行为符合当前弧光阶段：没提前顿悟、没无铺垫地反复横跳
-- [ ] 反派行为在其自身逻辑内成立，没有为剧情方便而降智
-- [ ] 外貌 / 伤势 / 随身物与前文一致，本章新信息已记入小传
+---
+name: 角色小传与人物弧光模板
+note: 角色档案模板（欲望/恐惧/语言指纹）+ 四拍弧光规划 + 连载防崩人设纪律与自检
+scopes:
+- novel
+- serial_novel
+source: market
+market_id: character-bible
+---
+
+# 角色小传与人物弧光模板（市场包）
+
+适用：开书前建角色档案、连载中防人设漂移。与平台流量包互补：流量包管
+「读者为什么追」，本包管「人物为什么可信」。人设崩塌带来的流失不可逆——
+评论区第一次出现「OOC」「崩人设」时，掉的数据基本回不来。
+
+## 一、小传模板（有名有姓的角色都建档，配角用精简版）
+- **基本档案**：姓名 / 年龄 / 身份职业 / 外貌。外貌只挑 ≤3 个**有辨识度且可反复
+  使用**的特征（疤、跛、口音、总戴手套），不要「很帅」「很美」这类无法复用的词。
+- **表层目标**：TA 自己以为想要的东西（金银、复仇、上岸）。
+- **深层需求**：真正缺的东西（认同、安全感、被看见）——弧光的终点就是发现并得到它。
+- **恐惧与软肋**：最怕失去什么；软肋必须**情节可攻击**（有家人的反派才有戏可写）。
+- **创伤与信念**：一句成型的信条（如「强才能活」），角色一切非常规行为的解释源头。
+- **语言指纹**：口头禅 / 句长习惯（文绉绉还是粗短句）/ 禁用词（读书人不说粗话）/
+  称呼习惯（怎么叫主角）。这是对白区分度最硬的抓手。
+- **关系网**：与主要角色的关系各一句话 + 张力在哪（靠什么维系、因什么会破裂）。
+
+## 二、弧光规划（主角必须有，重要配角推荐）
+- 四拍结构：**起点状态**（用旧信念应对世界）→ **触发事件**（旧信念失灵的一击）→
+  **中间摇摆**（至少两次反复：尝试改变，再退回舒适区，不许直线转变）→
+  **终点状态**（新信念，且由高潮事件证明成立）。
+- 弧光要「可拍摄」：终点状态必须体现为**行为变化**（以前遇辱必怒，现在能先忍住
+  查真相），不能靠内心独白宣布「他长大了」。
+- 反派同样要逻辑自洽：反派在自己的故事里是合理的（有目标、有原则、有能力），
+  **反派不无脑**；反派降智 = 主角胜利贬值 = 全书爽点贬值。
+
+## 三、防崩纪律（连载中执行）
+- 写对白前回看该角色的「语言指纹」；**遮名测试**：不同角色的对白遮住名字能认出
+  是谁说的，认不出 = 语言指纹失败，回去改。
+- 配角也要「想要什么」：出场就带着自己的目的行动，哪怕只写一句。
+  只在剧情需要时才动的工具人，是群像发糊的根源。
+- **每 10 章回看小传**：外貌、伤势、随身物、人际关系与正文逐一核对——伤过的手
+  不能无解释痊愈，卖掉的东西不能再掏出来。
+- 能力升级必须有过程与代价；「突然会了」读者瞬间就能感知。
+- 人物相关设定要改，必须回填小传并排查前文旧描述（与一致性台账守则联动）。
+
+## 四、配角精简模板（三行建档）
+- 一句话身份 + 此刻想要什么（出场动机）。
+- 一个可复用的辨识特征（外貌 / 口头禅 / 习惯动作）。
+- 与主要角色的关系张力（靠什么维系、因什么破裂）。
+三行都填不出来 = 这个角色还不该出场；信息攒够再让他登场。
+
+## 五、小传模板示例（可直接复制）
+> **姓名**：xxx　**年龄 / 身份**：xxx
+> **表层目标**：……　**深层需求**：……
+> **恐惧软肋**：……　**信条**：……
+> **语言指纹**：口头禅……；句式……；禁语……
+> **关系网**：与主角——……；与反派——……
+> **弧光四拍**：起点…… → 触发事件…… → 摇摆…… → 终点……
+
+## 六、写作前自检
+- [ ] 本章每个出场角色都知道自己「想要什么」，行为在为目标服务
+- [ ] 对白符合各自语言指纹（遮名测试通过）
+- [ ] 主角行为符合当前弧光阶段：没提前顿悟、没无铺垫地反复横跳
+- [ ] 反派行为在其自身逻辑内成立，没有为剧情方便而降智
+- [ ] 外貌 / 伤势 / 随身物与前文一致，本章新信息已记入小传

package/app/core/skillpacks/market/code-risk-checklist.md

@@ -1,58 +1,58 @@
----
-name: 代码风险自查清单
-note: 提测/评审前的风险过单：边界与异常 / 资源与并发 / 安全 / 兼容与回退
-scopes:
-- "*"
-source: market
-market_id: code-risk-checklist
----
-
-# 代码风险自查清单（市场包）
-
-适用：提交、提测、评审前对**自己写的代码**做一遍系统性过单。条目按事故率排序，
-每一条都对应一类反复发生的线上事故。用法：逐项问「我的改动碰到这条了吗」，
-碰到了就必须有明确答案，**不许「应该没事」**。
-
-## 一、边界与异常（最高频事故源）
-- 空值：入参为 None / 空串 / 空列表 / 空对象时，每一层调用会怎样？
-  dict 取键、列表取 [0]、`a.b.c` 属性链是最常见的崩点。
-- 数值边界：0、负数、极大值、小数精度（金额与计数一律避免 float 裸算的累计误差）。
-- 超长与超量：超长字符串、上千条的批量输入、没做分页的全量查询。
-- 异常处理红线：**禁止裸 `except: pass` 吞异常**——要么处理（记日志 + 降级/重试），
-  要么让它炸出来。吞掉的异常等于把今天的报错换成下周的灵异故障。
-- 失败路径：主流程成功不算完，逐问「每一步失败后，状态是否仍然一致」——
-  写了一半的文件、扣了款没发货的订单、删了源没删索引。
-
-## 二、资源与并发
-- 打开的文件 / 连接 / 锁，在**所有**退出路径上都关闭了吗（含异常路径）？
-  用 with / try-finally / defer 这类语言级保证，不靠「记得 close」。
-- 循环内不做 IO / 网络 / 建连接（N+1 模式）；能批量就批量。
-- 并发共享状态：全局变量、模块级缓存、多线程写同一文件——有锁吗？锁的粒度
-  会不会死锁？**单测通过不代表并发安全**，并发问题要靠设计保证而不是靠运气。
-- 幂等性：重试、重复请求、消息重复消费时，同一操作执行两次结果必须不变
-  （尤其支付、发送、计数类操作）。
-
-## 三、安全（每次改动都扫一眼）
-- 拼 SQL / 拼命令 / 拼 HTML = 注入。参数化或转义，没有例外。
-- 路径拼接必须校验：用户可控输入参与拼路径时防目录穿越（先 resolve 再判前缀，
-  或白名单校验文件名）。
-- 密钥与令牌不硬编码、不打日志；日志里的手机号 / 身份证 / 邮箱脱敏。
-- 对外接口：入参校验（类型 / 长度 / 范围）；错误信息不回显内部堆栈与路径。
-- 新增依赖必须来源可信、版本锁定；升级依赖后过一眼 changelog 的破坏性变更。
-
-## 四、兼容与可回退
-- 跨平台：路径分隔符（用语言自带的路由 API，不手拼 `/` 或 `\`）、文件编码
-  （Windows 默认 GBK，读写文件显式 UTF-8）、换行符、文件名大小写敏感差异。
-- 数据兼容：改字段名 / 改格式时，旧数据还读得动吗？迁移脚本在哪、可重跑吗？
-- 接口兼容：改出参、删字段之前，确认所有调用方（前端、脚本、第三方）已同步修改。
-- 可回退：这次改动出问题，怎么回到上一版本？配置开关、灰度、revert 方案，
-  动手前至少想清楚一个并写进提交说明。
-
-## 五、提测前过单（逐项打勾，全绿才提交评审）
-- [ ] 空值 / 边界入参各试过一次：不崩、行为合理
-- [ ] 无裸吞异常；所有异常路径上资源正确释放
-- [ ] 无循环内 IO；并发路径有并发保护或明确论证过只在单线程运行
-- [ ] 无拼接 SQL / 命令；无硬编码密钥；日志无敏感明文
-- [ ] 路径 / 编码 / 换行已跨平台处理（Windows 环境必查）
-- [ ] 已想好并写下回退方式（revert / 开关 / 迁移脚本）
-- [ ] 新增或修改的逻辑有对应测试，改动的测试全部通过
+---
+name: 代码风险自查清单
+note: 提测/评审前的风险过单：边界与异常 / 资源与并发 / 安全 / 兼容与回退
+scopes:
+- "*"
+source: market
+market_id: code-risk-checklist
+---
+
+# 代码风险自查清单（市场包）
+
+适用：提交、提测、评审前对**自己写的代码**做一遍系统性过单。条目按事故率排序，
+每一条都对应一类反复发生的线上事故。用法：逐项问「我的改动碰到这条了吗」，
+碰到了就必须有明确答案，**不许「应该没事」**。
+
+## 一、边界与异常（最高频事故源）
+- 空值：入参为 None / 空串 / 空列表 / 空对象时，每一层调用会怎样？
+  dict 取键、列表取 [0]、`a.b.c` 属性链是最常见的崩点。
+- 数值边界：0、负数、极大值、小数精度（金额与计数一律避免 float 裸算的累计误差）。
+- 超长与超量：超长字符串、上千条的批量输入、没做分页的全量查询。
+- 异常处理红线：**禁止裸 `except: pass` 吞异常**——要么处理（记日志 + 降级/重试），
+  要么让它炸出来。吞掉的异常等于把今天的报错换成下周的灵异故障。
+- 失败路径：主流程成功不算完，逐问「每一步失败后，状态是否仍然一致」——
+  写了一半的文件、扣了款没发货的订单、删了源没删索引。
+
+## 二、资源与并发
+- 打开的文件 / 连接 / 锁，在**所有**退出路径上都关闭了吗（含异常路径）？
+  用 with / try-finally / defer 这类语言级保证，不靠「记得 close」。
+- 循环内不做 IO / 网络 / 建连接（N+1 模式）；能批量就批量。
+- 并发共享状态：全局变量、模块级缓存、多线程写同一文件——有锁吗？锁的粒度
+  会不会死锁？**单测通过不代表并发安全**，并发问题要靠设计保证而不是靠运气。
+- 幂等性：重试、重复请求、消息重复消费时，同一操作执行两次结果必须不变
+  （尤其支付、发送、计数类操作）。
+
+## 三、安全（每次改动都扫一眼）
+- 拼 SQL / 拼命令 / 拼 HTML = 注入。参数化或转义，没有例外。
+- 路径拼接必须校验：用户可控输入参与拼路径时防目录穿越（先 resolve 再判前缀，
+  或白名单校验文件名）。
+- 密钥与令牌不硬编码、不打日志；日志里的手机号 / 身份证 / 邮箱脱敏。
+- 对外接口：入参校验（类型 / 长度 / 范围）；错误信息不回显内部堆栈与路径。
+- 新增依赖必须来源可信、版本锁定；升级依赖后过一眼 changelog 的破坏性变更。
+
+## 四、兼容与可回退
+- 跨平台：路径分隔符（用语言自带的路由 API，不手拼 `/` 或 `\`）、文件编码
+  （Windows 默认 GBK，读写文件显式 UTF-8）、换行符、文件名大小写敏感差异。
+- 数据兼容：改字段名 / 改格式时，旧数据还读得动吗？迁移脚本在哪、可重跑吗？
+- 接口兼容：改出参、删字段之前，确认所有调用方（前端、脚本、第三方）已同步修改。
+- 可回退：这次改动出问题，怎么回到上一版本？配置开关、灰度、revert 方案，
+  动手前至少想清楚一个并写进提交说明。
+
+## 五、提测前过单（逐项打勾，全绿才提交评审）
+- [ ] 空值 / 边界入参各试过一次：不崩、行为合理
+- [ ] 无裸吞异常；所有异常路径上资源正确释放
+- [ ] 无循环内 IO；并发路径有并发保护或明确论证过只在单线程运行
+- [ ] 无拼接 SQL / 命令；无硬编码密钥；日志无敏感明文
+- [ ] 路径 / 编码 / 换行已跨平台处理（Windows 环境必查）
+- [ ] 已想好并写下回退方式（revert / 开关 / 迁移脚本）
+- [ ] 新增或修改的逻辑有对应测试，改动的测试全部通过

package/app/core/skillpacks/market/git-workflow.md

@@ -1,57 +1,57 @@
----
-name: Git 提交与分支守则
-note: 提交信息规范 / 分支模型 / 危险操作红线 / 冲突与回滚 / 提交前自检清单
-scopes:
-- "*"
-source: market
-market_id: git-workflow
----
-
-# Git 提交与分支守则（市场包）
-
-适用：任何带版本控制的工程或写作任务。目标只有一个——**让半年后的自己（和协作者）
-能从提交历史里读懂「为什么改」，并且任何时候都敢放心回滚**。本包约束的是纪律，
-不是 git 教程；每条红线背后都是一类真实发生过的事故。
-
-## 一、提交信息（Commit Message）
-- 格式：`类型(范围): 一句话摘要`。类型闭集：feat / fix / docs / refactor / test / chore，
-  不自创类型（update、modify、change 这类词无法被工具统计与检索）。
-- 摘要 ≤50 字，祈使句，结尾不加句号；写「做了什么」，不写「改了哪些文件」。
-  反例：`修改了一些文件`；正例：`fix(api): 空请求体导致 500 的问题`。
-- 摘要说不清的改动，空一行后写 body：解释**为什么改**（背景、权衡、副作用），
-  不要复述 diff 本身能看出来的「改了什么」。
-- 一次提交只做一件事：修 bug 的提交里不顺手重构；发现顺手该改的，另起提交。
-  混合提交无法单独回滚，是最常见的 git 事故根源。
-
-## 二、分支模型
-- `main`（或 master）永远可发布：只接受经过验证的合并，禁止把未验证的功能代码
-  直接 push 上去。
-- 分支命名能看出目的：功能 `feat/<短横线描述>`，修复 `fix/<短横线描述>`；
-  一个分支只对应一个目的，合完即删——活过两周的分支几乎必然产生严重冲突。
-- 同步纪律：动手前先拉最新主干；分支生命周期超过 2 天，每天至少同步一次主干，
-  冲突在自己分支上解决，不把冲突攒到合并时刻。
-
-## 三、危险操作红线
-- 禁止对**已推送的公共分支**做 `reset` / `amend` / force push——重写历史会让所有
-  协作者的本地仓库错乱。公共分支上的错误用 `git revert` 生成反向提交。
-- `git push --force` 只允许推自己的功能分支；确需覆盖时用 `--force-with-lease`
-  （远端有别人新提交时会拒绝，防误伤）。
-- 提交前不许 `git add -A` 了事：先 `git status` + `git diff --staged` 逐块确认，
-  防止把临时脚本、日志、密钥、二进制大文件带进历史（进了历史几乎删不干净）。
-- 敏感信息（密钥、口令、内网地址）一旦提交，**立即视为已泄露**：先作废并轮换凭据，
-  再清理历史，顺序不能反——清理历史赶不上爬虫抓取的速度。
-
-## 四、冲突与回滚
-- 冲突解决以**业务正确**为准，不以「保留谁写的」为准；解决完必须编译/跑测通过
-  再提交，冲突盲选是隐性 bug 的最大来源。
-- 回滚决策树：未推送 → `reset`（本地随意）；已推送未发布 → `revert` 反向提交；
-  已发布出问题 → 先 revert 恢复线上，再慢慢定位，**不在主干上现场调试**。
-- 大改动合并前先试合：`git merge --no-commit --no-ff` 预览，或在临时分支上合一遍。
-
-## 五、提交前自检清单
-- [ ] `git status` 干净：没有预期外的未跟踪/被修改文件
-- [ ] `git diff --staged` 逐块看过：无调试代码、无密钥、无大文件
-- [ ] 提交信息符合 `类型(范围): 摘要`，摘要 ≤50 字且脱离上下文能看懂
-- [ ] 一次提交一个意图；无关改动已拆分
-- [ ] 功能分支基于最新主干；公共分支未被重写历史
-- [ ] 提交后本地测试/CI 通过；红了立即 fix 或 revert，不留红主干
+---
+name: Git 提交与分支守则
+note: 提交信息规范 / 分支模型 / 危险操作红线 / 冲突与回滚 / 提交前自检清单
+scopes:
+- "*"
+source: market
+market_id: git-workflow
+---
+
+# Git 提交与分支守则（市场包）
+
+适用：任何带版本控制的工程或写作任务。目标只有一个——**让半年后的自己（和协作者）
+能从提交历史里读懂「为什么改」，并且任何时候都敢放心回滚**。本包约束的是纪律，
+不是 git 教程；每条红线背后都是一类真实发生过的事故。
+
+## 一、提交信息（Commit Message）
+- 格式：`类型(范围): 一句话摘要`。类型闭集：feat / fix / docs / refactor / test / chore，
+  不自创类型（update、modify、change 这类词无法被工具统计与检索）。
+- 摘要 ≤50 字，祈使句，结尾不加句号；写「做了什么」，不写「改了哪些文件」。
+  反例：`修改了一些文件`；正例：`fix(api): 空请求体导致 500 的问题`。
+- 摘要说不清的改动，空一行后写 body：解释**为什么改**（背景、权衡、副作用），
+  不要复述 diff 本身能看出来的「改了什么」。
+- 一次提交只做一件事：修 bug 的提交里不顺手重构；发现顺手该改的，另起提交。
+  混合提交无法单独回滚，是最常见的 git 事故根源。
+
+## 二、分支模型
+- `main`（或 master）永远可发布：只接受经过验证的合并，禁止把未验证的功能代码
+  直接 push 上去。
+- 分支命名能看出目的：功能 `feat/<短横线描述>`，修复 `fix/<短横线描述>`；
+  一个分支只对应一个目的，合完即删——活过两周的分支几乎必然产生严重冲突。
+- 同步纪律：动手前先拉最新主干；分支生命周期超过 2 天，每天至少同步一次主干，
+  冲突在自己分支上解决，不把冲突攒到合并时刻。
+
+## 三、危险操作红线
+- 禁止对**已推送的公共分支**做 `reset` / `amend` / force push——重写历史会让所有
+  协作者的本地仓库错乱。公共分支上的错误用 `git revert` 生成反向提交。
+- `git push --force` 只允许推自己的功能分支；确需覆盖时用 `--force-with-lease`
+  （远端有别人新提交时会拒绝，防误伤）。
+- 提交前不许 `git add -A` 了事：先 `git status` + `git diff --staged` 逐块确认，
+  防止把临时脚本、日志、密钥、二进制大文件带进历史（进了历史几乎删不干净）。
+- 敏感信息（密钥、口令、内网地址）一旦提交，**立即视为已泄露**：先作废并轮换凭据，
+  再清理历史，顺序不能反——清理历史赶不上爬虫抓取的速度。
+
+## 四、冲突与回滚
+- 冲突解决以**业务正确**为准，不以「保留谁写的」为准；解决完必须编译/跑测通过
+  再提交，冲突盲选是隐性 bug 的最大来源。
+- 回滚决策树：未推送 → `reset`（本地随意）；已推送未发布 → `revert` 反向提交；
+  已发布出问题 → 先 revert 恢复线上，再慢慢定位，**不在主干上现场调试**。
+- 大改动合并前先试合：`git merge --no-commit --no-ff` 预览，或在临时分支上合一遍。
+
+## 五、提交前自检清单
+- [ ] `git status` 干净：没有预期外的未跟踪/被修改文件
+- [ ] `git diff --staged` 逐块看过：无调试代码、无密钥、无大文件
+- [ ] 提交信息符合 `类型(范围): 摘要`，摘要 ≤50 字且脱离上下文能看懂
+- [ ] 一次提交一个意图；无关改动已拆分
+- [ ] 功能分支基于最新主干；公共分支未被重写历史
+- [ ] 提交后本地测试/CI 通过；红了立即 fix 或 revert，不留红主干

package/app/core/skillpacks/market/release-notes.md

@@ -1,72 +1,72 @@
----
-name: 版本发布说明撰写模板
-note: 面向用户的更新公告：固定六段结构 / 写作纪律 / 破坏性变更三要素 / 可复制模板与反例
-scopes:
-- "*"
-source: market
-market_id: release-notes
----
-
-# 版本发布说明撰写模板（市场包）
-
-适用：发版时写 Release Notes / 更新公告 / changelog 的用户可读部分。
-核心立场：**写给用户看，不是写给 git log 看**——用户不关心重构了哪个模块，
-只关心「这次更新后我能多做什么、少烦什么、会坏什么」。
-
-## 一、标准结构（顺序固定）
-1. **一句话概览**：这版最值得用户知道的一件事；实在没有就写「稳定性修复」。
-2. **新功能**：能做以前做不了的事。每条 = 功能名 + 用户收益 + 入口在哪。
-3. **体验优化**：以前能做、现在更快 / 更顺 / 更省的事。
-4. **问题修复**：写用户见过的**症状**（「修复导出 PDF 中文乱码」），
-   不写内部成因（「修复字体子集化模块的编码偏移」）。
-5. **升级注意事项 / 破坏性变更**：有则紧跟概览**置顶**（不按上面的顺序排），
-   没有就省略此节。
-6. **已知问题**：带着已知问题发版必须如实列出，并给临时绕过办法。
-
-## 二、写作纪律
-- 每条只说**一个行为变化**，动词开头、面向结果：「支持按标签筛选任务」，
-  而不是「重构筛选服务并接入标签存储」。
-- 收益优先于实现：先说用户能干什么，实现细节放括号或链接里。
-- 数字具体化：「启动更快」要写成「冷启动从约 6 秒降到约 2 秒」；
-  没有数据不要编数字。
-- 不用内部术语：对用户写「登录更稳定」，不写「修复 OAuth2 refresh token 竞态」；
-  这类内容放进面向开发者的附录小节。
-- 每条尽量带出处：issue / PR / 需求单号，方便日后回溯。
-
-## 三、破坏性变更的写法（最容易写砸的部分）
-- 三要素齐全：**什么会坏**（哪个行为 / 接口 / 配置）、**影响谁**、**怎么办**
-  （迁移步骤或替代写法，给可直接复制的示例）。
-- 正面示例：
-  > **升级注意**：`/api/tasks` 返回的 `status` 字段由中文改为枚举值
-  > （`running` / `done` / `failed`）。依赖该字段的脚本需同步修改，
-  > 新旧值对照表见帮助文档「status 迁移」一节。
-- 「可能影响部分用户」这类模糊表述禁止——写清判定条件，让用户 10 秒内
-  判断自己在不在影响范围内。
-
-## 四、模板（可直接复制）
-```
-## vX.Y.Z 更新说明（YYYY-MM-DD）
-
-概览：一句话说清这版最重要的事。
-
-### 新功能
-- 支持xxx：现在可以……（入口：设置 > xxx）(#123)
-
-### 优化
-- xxx 更快 / 更省：从……到……
-
-### 修复
-- 修复「用户看到的现象」(#456)
-
-### 升级注意
-- 变更点 → 影响谁 → 迁移步骤（附示例代码或对照表链接）
-
-### 已知问题
-- ……；临时绕过：……
-```
-
-## 五、反例对照
-- 反例：「优化了底层性能。」→ 正例：「任务列表在 1 万条数据时加载时间从约 4 秒降到约 1 秒。」
-- 反例：「修复若干问题。」→ 正例：「修复搜索结果偶发重复显示；修复深色模式下按钮文字不可读。」
-- 反例：「接口升级，请注意适配。」→ 正例：按三要素写全（什么坏 / 影响谁 / 怎么办）。
-- 反例：「重构核心模块。」→ 用户视角无行为变化的重构不进用户公告，放开发者 changelog。
+---
+name: 版本发布说明撰写模板
+note: 面向用户的更新公告：固定六段结构 / 写作纪律 / 破坏性变更三要素 / 可复制模板与反例
+scopes:
+- "*"
+source: market
+market_id: release-notes
+---
+
+# 版本发布说明撰写模板（市场包）
+
+适用：发版时写 Release Notes / 更新公告 / changelog 的用户可读部分。
+核心立场：**写给用户看，不是写给 git log 看**——用户不关心重构了哪个模块，
+只关心「这次更新后我能多做什么、少烦什么、会坏什么」。
+
+## 一、标准结构（顺序固定）
+1. **一句话概览**：这版最值得用户知道的一件事；实在没有就写「稳定性修复」。
+2. **新功能**：能做以前做不了的事。每条 = 功能名 + 用户收益 + 入口在哪。
+3. **体验优化**：以前能做、现在更快 / 更顺 / 更省的事。
+4. **问题修复**：写用户见过的**症状**（「修复导出 PDF 中文乱码」），
+   不写内部成因（「修复字体子集化模块的编码偏移」）。
+5. **升级注意事项 / 破坏性变更**：有则紧跟概览**置顶**（不按上面的顺序排），
+   没有就省略此节。
+6. **已知问题**：带着已知问题发版必须如实列出，并给临时绕过办法。
+
+## 二、写作纪律
+- 每条只说**一个行为变化**，动词开头、面向结果：「支持按标签筛选任务」，
+  而不是「重构筛选服务并接入标签存储」。
+- 收益优先于实现：先说用户能干什么，实现细节放括号或链接里。
+- 数字具体化：「启动更快」要写成「冷启动从约 6 秒降到约 2 秒」；
+  没有数据不要编数字。
+- 不用内部术语：对用户写「登录更稳定」，不写「修复 OAuth2 refresh token 竞态」；
+  这类内容放进面向开发者的附录小节。
+- 每条尽量带出处：issue / PR / 需求单号，方便日后回溯。
+
+## 三、破坏性变更的写法（最容易写砸的部分）
+- 三要素齐全：**什么会坏**（哪个行为 / 接口 / 配置）、**影响谁**、**怎么办**
+  （迁移步骤或替代写法，给可直接复制的示例）。
+- 正面示例：
+  > **升级注意**：`/api/tasks` 返回的 `status` 字段由中文改为枚举值
+  > （`running` / `done` / `failed`）。依赖该字段的脚本需同步修改，
+  > 新旧值对照表见帮助文档「status 迁移」一节。
+- 「可能影响部分用户」这类模糊表述禁止——写清判定条件，让用户 10 秒内
+  判断自己在不在影响范围内。
+
+## 四、模板（可直接复制）
+```
+## vX.Y.Z 更新说明（YYYY-MM-DD）
+
+概览：一句话说清这版最重要的事。
+
+### 新功能
+- 支持xxx：现在可以……（入口：设置 > xxx）(#123)
+
+### 优化
+- xxx 更快 / 更省：从……到……
+
+### 修复
+- 修复「用户看到的现象」(#456)
+
+### 升级注意
+- 变更点 → 影响谁 → 迁移步骤（附示例代码或对照表链接）
+
+### 已知问题
+- ……；临时绕过：……
+```
+
+## 五、反例对照
+- 反例：「优化了底层性能。」→ 正例：「任务列表在 1 万条数据时加载时间从约 4 秒降到约 1 秒。」
+- 反例：「修复若干问题。」→ 正例：「修复搜索结果偶发重复显示；修复深色模式下按钮文字不可读。」
+- 反例：「接口升级，请注意适配。」→ 正例：按三要素写全（什么坏 / 影响谁 / 怎么办）。
+- 反例：「重构核心模块。」→ 用户视角无行为变化的重构不进用户公告，放开发者 changelog。