S06 skill专家迭代SOP

变更：V1.1.4（2026-09-25）「四件套 → 1 件套」结构性改造落地——依据炳哥 2026-09-25 裁定①（批准 · 含双认期 1 轮）与《S06改单件_定标请求件_2026-09-25_1418》：B1/B2 治理交付物由四件套（2 Word ＋ 2 Excel）改为1 件套（单文件离线 HTML · 四分区合体）；字体硬约束由「docx 生效字体链」改为「HTML 内联 CSS 字体声明」；后置硬闸门由 assert_fourpiece.py 换为 assert_onefile.py（旧名兼容转发）；双认期口径＝「读旧认 4 件、写新只出 1 件」。
变更：V1.1.3（2026-09-23）新增「重放闸口径（V2.0.0 · 2026-09-23 L1 修复）」节——升版入口 scripts/skill_upgrade.py 的重放闸由旧口径（单相落痕 + 三判据）升为双相落痕（intent/done）＋ 判据 A/B/C ＋ 「registry × 实盘」一致性硬闸 LD-R1 ＋ --allow-resume/--allow-replay 语义分离 ＋ --reconcile 核对入口，确立「registry 与实盘不一致必须拦截」原则；与 W03（V1.2.0 条）／Y02（V1.0.1 修订）同源、逐字一致。缘起：lihengbian_DIY_供应链评价 V1.9.0→V1.10.0→V1.11.0 连跳两级事故。
变更：V1.1.2（2026-09-13）新增「体系评价交接点」——升级前必要时可按 LHB/TS-2026-007《WorkBuddy专家与Skill评价技术标准》V1.0.0 §8.3 取得“达标/有条件达标”四分法结论（机器判据 _tools/carrier_eval.py）。
变更：V1.1.1（2026-09-11）新增「四件套 Word 字体硬约束（国标固化）」节——配套宪法 V1.1.0 第16条（四红线/跨层声明）、基本法 V2.0.0 M3.2（国标排版）/ M5.2（四件套强制）；四件套 Word 须经 fourpiece.emit() 生成并过国标字体闸门。
V1.1.0（2026-09-10）新增「公众号抓取回退链（?scene=25）」skill 专属规则节。

类别：SOP（用户级全域规范）
名称释义：任意 skill/专家版本迭代通用规则（按 --type 三值升 1 位 · 默认补丁号+1）
权威源：宪法 V1.2.0 第16条（四红线）、基本法 V2.3.0 M0.6（S10 触发范围）/ M0.7（业务交付铁律索引）/ M5.2（四件套强制）
固化位置：~/.workbuddy/MEMORY.md（所有 Agent 一律生效）

工作流（启动顺序 + 升级闭环 · 全域硬约束）

本 SOP 为 skill/专家升级/迭代/训练/知识注入的唯一权威依据。任何涉及对象的改动，必须严格按以下五步闭环执行，缺一不可、全域强制。

启动顺序（每次会话/任务启动，全域铁律）

1. 读 MEMORY（拿规则）：首步读 ~/.workbuddy/MEMORY.md，未读不得动手。
2. 跑 _tools 代码（强制）：凡交付物命名与skill/专家迭代升版治理件（1 件套）验证，强制调用 ~/.workbuddy/_tools/（deliverable.py / check_deliverables.py），禁止手敲文件名。
3. 查 README（看 API）：动手前查 ~/.workbuddy/README/<对象目录名>/README.md；无独立 README 时以 SKILL.md 为 API 权威。
4. 查技术规范与 SOP（升级/建夹必过闸）：①升级/迭代/训练/知识注入前先读 ~/.workbuddy/spec\3.行政法规\范式\ 对应范式；②每个新任务启动（含任何 skill 触发产出）先读 S01+S02，建「三字标题_YYYY-MM-DD_HHMM/产出/素材/」，产出落 产出/。
5. 收尾总结（每次任务结束后，200 字铁律）：任何任务每次结束后，在最终回复中用约 200 字总结「当前进展 + 核心结论 + 遗留问题」三要素（见 ~/.workbuddy/spec\3.行政法规\SOP\S10_任务收尾总结SOP.md）；与 S03/S04 收尾三件套、skill/专家迭代升版 1 件套治理件并存、互不替代。

升级五步闭环（硬约束）

• 闭环链路：读 MEMORY → 跑 _tools → 查 README → 查技术规范与 SOP → 建任务夹（S02），五步必须闭环、全域可执行、覆盖全部 SOP（含 S02 建文件夹）、硬约束。
• 只按本技术规范修改：改动逐条对照对应范式对齐，不重写整个 SKILL.md；不碰全域规则（MEMORY.md）与工具链（_tools/），除非其自身变化。
• 无技术规范，拒绝升级（硬闸门）：升级/迭代动手前必须先过闸并保留回执——
• 专家侧：运行 python C:\Users\xub\.workbuddy\_tools\expert_spec_gate.py --expert <目录名>（映射表见脚本 EXPERT_SPEC_MAP），输出命中范式即回执；
• skill 侧：~/.workbuddy/scripts/skill_upgrade.py 的 check_spec_gate 自动拦截（SPEC_MAP 按 base_name 定位）；
• 定位不到或未提供对应范式 → 立即停下、禁止动手改，并回复「请提供其技术规范（如电池专家技术规范）」。
• 技术规范唯一依据：升级依据只认 ~/.workbuddy/spec\3.行政法规\范式\ 对应对象的范式文件（如 B01_电池专利助手范式.md）；禁止用本次迭代自产的《技术规范要求.docx》等交付物充当升级依据（循环论证）——该交付物只是「记录本次所依据规范」的产物，不是依据本身。
• 升级前 checklist（动手前逐条确认，全部 ✓ 才允许执行升版动作）：①读 MEMORY ✓ ②跑 _tools 校验链 ✓ ③查 README ✓ ④闸门过闸（记录命中范式文件名）✓ ⑤双端同步检查（同对象专家包 + 用户级 skill 两处都要注入/登记，见「双端同步」）✓ ⑥skill/专家迭代升版 1 件套治理件齐全（四分区齐备 ＋ 列头逐字 ＋ 时间戳唯一）且过「结构闸（html_onefile_gate.py）＋ 字体声明闸门」✓ ⑦体系评价交接点（可选）：本轮涉评价/达标判定时，按 LHB/TS-2026-007 V1.0.0 §8.3 跑 python _tools/carrier_eval.py --evidence e.json；结论为「不得判定」时禁据其升版 ✓。
• 双端同步（同对象双体系铁律，2026-08-24 审计教训固化）：同一对象可能同时存在「专家包」（~/.workbuddy/plugins/marketplaces/my-experts/plugins/）与「用户级 skill」（~/.workbuddy/skills/）两套载体（如 利衡辨_电池专家）。训练注入 / 知识更新 / 升版必须双端同步执行：知识文件、知识段落、示例提问、README 登记两处都要有，变更履历如实记录两端；只注入一端 = 另一端用户实际调用时新知识缺失（V1.19.1 教训）。收尾回执须附「双端比对」：列出两端各自新增/覆盖的文件清单并确认一致。

skill/专家迭代 SOP（2026-08-21 确立 · 全域规范）

固化与范围：本 SOP 为用户级全域规范，固化于本文件，对所有工作空间、所有任务、所有 Agent 一律生效。适用于任意 skill / 专家的版本迭代优化（公众号助手、技术标准排版助手、电池专家等），是「lihengbian_DIY_jishubiaozhunpaibanzhushou 技能生成/升级 SOP」的通用化升级（本 SOP 通用规则优先，技术标准排版助手 SOP 仅保留其专属方法论细节）。

触发

• 模式：Craft 模式。
• 场景：用户提出「按某要求重新优化 / 升级某个 skill 或专家」时。

核心动作（每次迭代）

1. 版本命名：所有文件统一命名为「现版本号升 1 级 + 所优化的 skill/专家名称」。
   - 「升 1 级」口径 = 与 --type 三值一一对应（2026-09-25 裁定 · 以工具为准 · L6 销项）：bugfix（默认）→ 补丁号+1（第三位递增，如 V1.6.0 → V1.6.1）；feature → 次版本+1 且补丁归零（如 V1.6.0 → V1.7.0）；major → 主版本+1 且次位、补丁归零（如 V1.6.0 → V2.0.0，须炳哥批准）。
   - 三值与 scripts/skill_upgrade.py::bump()、scripts/expert_upgrade.py 同源，不得自行另定口径；「补丁号+1」是默认值而非唯一值——仅当交付物形态／流程发生结构性变更时升次版本（如本轮 G12 V1.0.0 → V1.1.0）。
   - 沿用其命名前缀（如 lihengbian_DIY_gongzhonghaozhushou）。
2. 覆盖与归档旧文件（含缓冲文件）：
   - 将最新版覆盖同名旧文件，清理中间缓冲文件（__pycache__、临时脚本、未定稿草稿、大体积缓冲等）。
   - 被取代的旧版本目录归档为 .bak（与 MEMORY 安全红线一致：不直接递归删，可回退），用户确认无误后再手动清理。
   - ⚠️ 删除/归档范围见上方「安全红线」节（严格限定在该 skill/专家自己的目录 ~/.workbuddy/skills/<skill名>/ 或项目 skill 目录，与本任务产出目录内）。

必出 skill/专家迭代升版 1 件套治理件（每次迭代生成，全域铁律③，缺一不可 · 2026-09-25 改造）

形态：由四件套（2 Word ＋ 2 Excel）合并为1 件（单文件离线 HTML · 四分区合体）；原四类内容逐一对应四个分区，信息不增不减，仅换载体。依据：炳哥 2026-09-25 裁定① ＋《S06改单件_定标请求件_2026-09-25_1418》。

用受管 Python 生成（统一经 _tools/fourpiece.py 的 emit_onefile()；旧 emit() 保留为存量兼容别名，不得再用于新制输出），落位到本任务文件夹 产出/：

• 命名：<升版号>_<skill名称>_<YYYY-MM-DD_HHMM>_治理件.html（原「类型」四值合一为单值 治理件），一律由 deliverable.build_paths(..., onefile=True) 生成，不得手敲（G12 §6 C4）。
• 壳层四件：header.docmeta（页眉）／nav.toc（目次）／main.article（正文）／footer.doc-foot（页脚），缺一不合规。

时间戳：date +"%Y-%m-%d_%H%M" 取本地时间，文档时间戳下划线+分钟（全域统一）；任务文件夹同样用 YYYY-MM-DD_HHMM（下划线+分钟）。示例：V1.8.0_lihengbian_DIY_公众号助手_2026-08-21_1210_治理件.html。
双认期（炳哥 2026-09-25 裁定①）：读旧认存量四件套（历史产出不误报）、写新只出 1 件套；收窄时点由脑定。

治理件字体硬约束（国标固化 · 2026-09-11 立 · 2026-09-25 改「HTML 内联 CSS」口径）

根因（勿再翻案）：fourpiece.py 早期版本以 python-docx 出厂模板裸生成——模板 word/theme/theme1.xml 的 <a:ea typeface=""/> 为空，word/styles.xml 的 docDefaults 却以 eastAsiaTheme="minorEastAsia" 引用它，标题样式另挂 Calibri Light + 主题蓝 365F91 → 中文回落西文字体，交付件在 WPS／部分 Word 显示为「一堆乱码」，而命名闸与四件套断言全部通过（典型静默失败）。

• 判据真源（2026-09-25 立标 · 走 C 路）：《HTML 治理件版式》（~/.workbuddy/spec\3.行政法规\范式\G22_HTML治理件版式.md）。中文字体白名单／字号阶梯／行距／留白／表头样式／「内联 CSS 声明」判据一律以该范式为准；脚本只实现，不自备标准（宪法第 16 条）。
• 字体口径：正文中文宋体｜标题中文黑体｜西文／数字 Times New Roman｜等宽 Consolas；字号阶梯 正文 15px、篇・章 24px、节 18px、条 15.5px；行距 1.75。常量唯一载体 _tools/fourpiece.py 顶部 HTML_GB 字典，改字体只改 HTML_GB。
• 生成侧硬约束：治理件 必须经 fourpiece.emit_onefile(theme, task_folder) 生成（内部走 _onefile_css() 内联声明 ＋ 落盘后 deliverable.check_onefile() 内容闸自检）；禁止自造壳层或绕过自检。
• 闸门（禁静默）：① 结构层——assert_onefile.py 串联 html_onefile_gate.py（零外链／零脚本／壳层四件／目次锚点对账／标签良构）；② 字体层——assert_onefile.py 内置 check_html_fonts()，判「存在内联 font-family 声明 且 中文字体 ∈ 白名单」，不合规即非零退出；③ 契约收窄：check_docx_gb_fonts() 对非 docx 对象返回哨兵 NotApplicable（显式「不适用」），判读一律走 gb_font_state(ret) → 'error'｜'pass'｜'na'，不得再以「返回 None 即通过」的口径读它。
• 存量 docx 路径不废：一切既有 docx 生成路径（各 skill 内 build_word.py、旧四件套 Word 等）仍按原 docx 字体闸门执行，行为零变化；执行细则见 MEMORY_REFERENCE.md §〇·K。

新建类任务输出物清单（A 类 · 首版生成 · 2026-08-26 固化）

本清单定义新建 skill/专家时的输出物，与下方「更新类（B1/B2）」对称。首版无历史版本，故治理件为三件套（无「版本清单」——版本清单为迭代 B 类登记历史版本快照特有）。引用 SOP（Ⓡ=复用）：ⓇS05 利衡辨Word排版助手技能生成升级SOP（首次生成三件套 + Word 排版）、ⓇS06 skill专家迭代SOP（版本命名 + 唯一标识铁律）、ⓇS01 新任务初始化SOP、ⓇS02 文件夹命名SOP。

A1 新建 Skill 输出物清单

1. 新版本目录：V1.0.0_<skill名>（首版，补丁号从 .0 起）；
2. SKILL.md（frontmatter 含 name + description 触发词）+ 配套目录（references/、scripts/、templates/、assets/，按需）；
3. 三件套（首版无「版本清单」）：技术规范要求 Word + 摘要 Word + 变更履历 Excel，命名 <版本号>_<skill名>_<YYYY-MM-DD_HHMM>_技术规范要求/摘要/变更履历（下划线+分钟时间戳）。
   A 类不并轨（2026-09-25 正式条文）：本次「四件套 → 1 件套」改造只覆盖 B 类（更新）；A 类（新建）维持三件套形态（技术规范要求 Word ＋ 摘要 Word ＋ 变更履历 Excel，首版无「版本清单」），不并轨为 1 件套，另立专项规范管理。

A2 新建专家（Agent）输出物清单

1. 专家包：agents/*.md + avatars + references + plugin.json（根副本 + .codebuddy-plugin/ 双副本）+ marketplace.json；
2. 校验报告（Class A 业务交付物，validate_expert.py 输出，落「产出/」）；
3. 注册回执（Class A 业务交付物，register_expert.py 输出，落「产出/」）；
4. 三件套：技术规范要求 Word + 摘要 Word + 变更履历 Excel（首版无「版本清单」）。
   同 A1：A 类不并轨，维持三件套形态（2026-09-25 正式条文）。

⚠️ A/B 差异铁律：A 类（新建）= 三件套（技术规范要求 + 摘要 + 变更履历，首版无版本清单；2026-09-25 定标：不并轨）vs B 类（更新）= 1 件套治理件（含版本清单分区）。目录命名沿用 B1/B2 差异铁律：新建 skill = V1.0.0_<skill名> 版本化目录，新建专家 = 规范 ID（kebab-case）目录（首版即规范 ID，不套用 V1.0.0_ 前缀）。

更新类任务输出物清单（B1/B2 · 规则↔工具链双保险显式化 · 2026-08-26 固化）

本清单把工具链 ~/.workbuddy/scripts/skill_upgrade.py（B1）与 expert_upgrade.py（B2）已实现的输出物显式固化为规则层条文，与上方「1 件套治理件」节互不替代；升级时逐条核对，缺一即视为未完成。引用 SOP（Ⓡ=复用）：ⓇS06 skill专家迭代SOP、S05 利衡辨Word排版助手技能生成升级SOP（Word 排版时）、ⓇS01 新任务初始化SOP、ⓇS02 文件夹命名SOP。

B1 更新 Skill 输出物清单

1. 1 件套治理件：单文件离线 HTML（四分区合体：sec-spec 技术规范要求／sec-summary 进展与遗留摘要／sec-changelog 变更履历／sec-version 版本清单），命名 <升版号>_<skill名>_<YYYY-MM-DD_HHMM>_治理件.html；
2. 新版本目录：V<版本号>_<skill名>（skill 目录即版本化命名，升版新建目录）；
3. 旧目录归档：<旧目录>.bak（不直接递归删，可回退）；
4. 同步 skills_registry.json：~/.workbuddy/skills_registry.json（机器可读唯一权威，由 skill_upgrade.py 唯一读写）。

1 件套断言后置硬闸门（2026-09-25 改造 · W1 §3.4 · 《治理件强制交付物断言技术标准》V1.1.0）：B1 升版 register 前必须运行 _tools/assert_onefile.py <产出目录>（旧名 assert_fourpiece.py 为兼容转发）断言「治理件 HTML 存在 ＋ 四分区齐备 ＋ 列头逐字 ＋ 时间戳唯一 ＋ 过结构闸 ＋ 字体声明合规」；双端一致另由 _tools/check_dual_end.py 判；退出码 ≠0 即阻断下游，杜绝「静默失败」。细则见《治理件强制交付物断言技术标准》V1.1.0（W1 §3.4 受控引用）。

B2 更新专家（Agent）输出物清单

1. 专家包：agents/*.md + avatars + references；
2. 校验报告（Class A 业务交付物，validate_expert.py 输出，落「产出/」）；
3. 注册回执（Class A 业务交付物，register_expert.py 输出，落「产出/」）；
4. 1 件套治理件：单文件离线 HTML（四分区合体：sec-spec／sec-summary／sec-changelog／sec-version），命名 <升版号>_<专家名>_<YYYY-MM-DD_HHMM>_治理件.html；
5. 原地升版（目录名不变）：专家目录名 = 规范 ID（kebab-case，如 liheng-bian-battery-expert），严禁改名/新建版本化目录（S06 §71「严禁修改专家目录名」+ App 按规范 ID 直查），只更新 plugin.json version（双副本）+ agents/*.md frontmatter + README.md 版本串；不归档 .bak（目录名未变，无旧目录可归档）；
6. 同步 skills_registry.json：双端同步（专家包 + 用户级 skill 两端 version/dir/note 对齐）。

1 件套断言后置硬闸门（2026-09-25 改造 · W1 §3.4 · 《治理件强制交付物断言技术标准》V1.1.0）：B2 升版 register 前必须运行 _tools/assert_onefile.py <产出目录>（旧名 assert_fourpiece.py 为兼容转发）断言「治理件 HTML 存在 ＋ 四分区齐备 ＋ 列头逐字 ＋ 时间戳唯一 ＋ 过结构闸 ＋ 字体声明合规」；双端一致另由 _tools/check_dual_end.py 判；退出码 ≠0 即阻断下游，杜绝「静默失败」。细则见《治理件强制交付物断言技术标准》V1.1.0（W1 §3.4 受控引用）。

⚠️ B1/B2 差异铁律：skill 版本化目录（V<版本号>_<skill名>，升版新建目录 + 旧目录归档 .bak）vs 专家规范 ID 目录（原地升版、目录名不变、不归档）。二者不可混用；B2 不套用 B1 的「新版本目录 + 归档 .bak」规则。

生成器一致性校验（回查→比对→差异报告→阻断 · 2026-08-26 固化）

周更生成「插件一览表五件套」逻辑图（模板 gen_logic_map_v7.py）前，强制回查本节「更新类任务输出物清单（B1/B2）」为唯一数据源，与生成器 SCENARIOS 里 B1/B2 的 out/sop 逐项比对，防止规则层↔生成器数据脱节（2026-08-26 08:19 教训：B2 清单漏同步「四件套/原地升版/registry 同步」3 项）。

• 校验锚点：B1 = 1 件套 / 新版本目录 / 旧目录归档 / skills_registry（4 项）；B2 = 专家包 / 校验报告 / 注册回执 / 1 件套 / 原地升版 / skills_registry（6 项）。
• 比对规则：生成器 B1/B2 的 out+sop 须逐锚点命中；规则层已定义而生成器未产出（缺失）、或生成器产出清单外内容（多余），均视为脱节。
• 阻断：脱节即 sys.exit(1) 阻断生成，输出差异清单 → 修正生成器数据 → 重跑。
• 载体：生成器内置 check_s06_sync()（回查 S06 → 提取生成器 B1/B2 输出物 → 逐项比对 → 差异报告 → 阻断），主流程生成前强制过闸。

重放闸口径（V2.0.0 · 2026-09-23 L1 修复）

判据真源：本段是 ~/.workbuddy/scripts/skill_upgrade.py 重放闸的唯一口径真源；脚本内 REPLAY_POLICY_VERSION 常量须与本段同步。改口径＝改本段；脚本只实现、不自备标准（宪法第16条「闸门不自备标准」）。

一、问题定性

同一条升版命令在沙箱放行后可能被重放执行两次（先受限沙箱跑一次、再放行态跑第二次），第二次在第一次产物上再 bump 一级 ⇒ 版本连跳两级、产出「内容与前版无差异的空版本」。2026-09-23 第四次实测（lihengbian_DIY_供应链评价 V1.9.0 → V1.10.0 → V1.11.0）暴露初版闸门（口径 1.0.0：单相落痕 + 三判据）存在结构性盲区，根因三条：

二、新口径（口径版本 2.0.0）

最高位原则：registry 与实盘不一致必须拦截，不得静默续升。 判据主源＝文件系统自身的不一致（即使 journal 被清空，亦能独立拦下重放）；journal 退为辅证。

① 双相落痕（根治 D1）
- 相位一 intent：任何写动作之前（shutil.copytree 之前）落 stage='intent'，记 (skill, kind, note) 指纹与预期 to_ver，返回 rec_id（由 指纹 + 时间戳 派生）。
- 相位二 done：升版成功收尾时把同 rec_id 那条改为 stage='done'。
- 落痕函数以脚本 record_intent() / record_done() 为准；record_upgrade() 保留为「intent + 立即 done」的兼容包装（供 --resume-fourpiece 使用）。dry-run 不落痕。

② 一致性硬闸 LD-R1（判据主源）
resolve_skill_dir_ex() 在 registry.dir 缺失／不存在时按 bare 名兜底扫描，并回传 via_fallback=True。upgrade() 在解析目录之后、任何写动作之前执行本闸：

若 via_fallback 为真：
    reg_ver  = registry[skill].version
    disk_ver = 实盘最高非 .bak 目录的版本号（disk_max_version）
    若 disk_ver != reg_ver → 抛 SystemExit，报「未登记的升版中间态」
    若 disk_ver == reg_ver → 仅目录名漂移，放行（保留既有自愈能力）

③ 判重放判据 A/B/C（辅助判据）
遍历全部同指纹记录（不再只查首条），任一成立即判重放，取最新命中一条返回：

窗口真源 REPLAY_WINDOW_SEC = 900（秒）。旧记录无 stage 键 → 不命中 A，仍走 B/C（向后兼容）。

④ 两个放行口语义分离（不可互相替代）

二者语义不同、不可互相替代；误用时的提示互相指路。

⑤ --reconcile 四方自洽核对入口（默认 dry-run，--apply 才写盘）
逐条报告：① registry[skill].dir 在 skills/ 下是否存在；② registry.version 与 SKILL.md frontmatter version 是否一致；③ 同一 bare 名下是否存在多个非 .bak 目录；④ journal 中 stage=='intent' 的未收尾记录；⑤ 孤立非 .bak 目录（存在但不在 registry）。
--apply 的写盘范围严格限定为「把 registry 的 dir／version 回正到实盘」这一种可逆动作（且仅在实盘该 bare 名下唯一目录时）；③④⑤ 三类只报不改（涉及目录改名或删除，须人裁定）。
中断续跑的标准处置：先 --reconcile --apply 把 registry 回正到实盘，再按正常命令升版（此时 registry 与实盘已一致，LD-R1 自然放行）。

三、不变量与自证

• 不得以 stdout 自述为准：判据一律回读磁盘实况。
• V1 事故复现用例为唯一验收核心：须在 journal 为空的前提下独立拦下重放。
• 口径变更须递增 REPLAY_POLICY_VERSION 并同步本段（现行 '2.0.0'）。

skill 迭代专属要点

• 目录：用户级 skill 位于 ~/.workbuddy/skills/<skill名>/；项目级 skill 位于 <工作空间>/.workbuddy/skills/<skill名>/。
• 核心文件：SKILL.md（frontmatter 含 name + description 触发词）为入口，配套 references/、scripts/、templates/、assets/。
• 迭代原则：只改本次要求变更的部分，不重写整个 SKILL.md；保持 frontmatter 的 name 与触发词一致。
• 版本标识：skill 目录名即版本号（如 V1.17.0_lihengbian_DIY_gongzhonghaozhushou），升版新建版本目录，旧版本按 3.2 删除。
• 纠错义务：skill 内脚本/命令若有笔误、命令名过时、步骤缺失，须在本次迭代中一并修正。

公众号抓取回退链（?scene=25 · skill 专属 · 2026-09-10 固化）

适用对象：lihengbian_DIY_gongzhonghaozhushou skill 的抓取环节。来源：V1.28.0 训练轮实证（2 篇源料经 ?scene=25 通道取得正文全文）。
现状标注（诚实）：scripts/fetch_article.py 当前尚未内置该通道，现有回退链为 --channel auto|direct|bing|sogou；本条须人工改写 URL 参数方可生效（未脚本化）。若下游将 scene=25 脚本化为内置回退级，须另走 skill 迭代升版（V1.12.1 → V1.12.2，补丁号 +1）。

• 触发条件：直连原 URL 返回反爬校验页 / 空正文 / 登录墙，或 fetch_article.py 直连失败（block_reason 命中）时启用。
• 回退顺序（逐级，前级成功即止）：
  1. 直连：原 URL（scripts/fetch_article.py <链接> --title "<标题>"，或直接 WebFetch 原链接）；
  2. scene 参数改写通道：在 URL query 中改写 / 追加 scene=25（备选 ?scene=1）后重取——该通道返回含正文的 HTML，绕过针对直连的反爬拦截（V1.28.0 实证 2/2 成功）。实施要点：保留原 __biz/mid/idx/sn 等身份参数不变，仅改写 / 追加 scene；优先 scene=25，无效再试 scene=1；
  3. 备用检索通道：--channel bing / --channel sogou（必传 --title，以标题为检索式定位）；
  4. 人工兜底：上述均失败时经 WebFetch 取原文，人工核对后入 article_raw.json（记 channel: websearch-fallback 与成功原因）。
• 已知无效路径（勿再踩 · V1.28.0 实测）：curl 直连公众号 URL → 沙箱内 Connection reset，不可用；agent-browser → 报 CDP error (Target.setDiscoverTargets): No such method（Chromium 内核与 CLI 不兼容），不可用。
• 验证要求：任一通道取回后须校验 ① 正文非空且长度合理 ② 标题与目标一致 ③ 无「环境异常 / 请完成验证」等拦截话术；任一不满足即降级到下一通道。
• 红线（诚实标注）：① 回退链仅用于获取源文本，不得伪造 / 补写 / 润色缺失段落，取不全即如实标注「源文本不完整」；② 抓取结果为二手载体，仅用于文风识别与蒸馏，涉硬数据结论仍须按硬锚第 1 条另行取证；③ 遵守目标站点使用条款与相关法律法规，不做高频批量请求。

专家迭代专属要点（铁律）

• 专家目录：~/.workbuddy/plugins/marketplaces/my-experts/plugins（即 $WORKBUDDY_CONFIG_DIR 默认位置），禁止生成到其他目录。
• 迭代流程：定位专家 → 确认修改范围 → 执行修改 → 校验 → 重新注册（validate_expert.py + register_expert.py）。
• 可修改字段：displayName、profession、displayDescription、description、tags、quickPrompts、defaultInitPrompt、avatar、categoryId（需说明理由）、members 展示信息、Agent MD 正文。
• 严禁修改（唯一标识，改了会丢专家）：plugin.json 的 name（kebab-case）与 agentName；专家目录名；agents/ 下 .md 文件名（agentName = MD 文件名）。改名需重新创建专家，不支持原地改名。
• 迭代铁律：tags 固定 3 个；quickPrompts 固定 3 个（第一条 = defaultInitPrompt，超出 3 个须提示替换/删除）；displayDescription 中文 40–50 字；Agent MD frontmatter 禁止声明 tools 字段；头像 512×512、PNG/JPG、≤500KB、同团队风格统一。

收尾

• 更新 ~/.workbuddy/MEMORY.md / ~/.workbuddy/MEMORY_CORE.md（本 SOP 已全域固化；如本次迭代产生新的跨项目偏好/规范再补充）。
• 向用户回执：skill/专家迭代升版 1 件套治理件路径、覆盖/归档的旧文件清单（含缓冲文件）、双端比对结果（专家包与用户级 skill 各自新增/覆盖清单，确认一致）、当前进展一句话、遗留问题清单。