Skill Forge（造 skill 的 skill）

> 核心目的：帮人把重复性工作流 / 个人方法论做成经过实测、可直接交付使用的 skill 包——质量门保证产出合规可信，经验闭环保证越用越聪明（C46 目的自证）。

> 本 skill 把"建 / 改 skill"固化为一条自动化、带质量门、且反馈可信、且能自我进化的流水线，作为公共 skill
> （user-level，跨所有工作区生效）被统一调用：编排（建索引/规划）→ 分析（实施+四维度机器检查）→ 交付（带报告）→ 进化（沉淀教训）。
> 八条核心纪律：
> 1. 先有索引再动手——没有关联索引不准改任何代码 / 文档。
> 2. "通过"只能由四维度无 BLOCK 得出——绝不允许凭印象或口头"看起来没问题"放行。
> 3. 反馈必须可信——交付依据是 forge_check.py 的机器报告与退出码（0=无 BLOCK / 1=有 BLOCK），而非文字描述。
> 4. 踩过的坑必须沉淀（自我迭代能力）——每一个由 skill-forge 创建的 skill 都必须内置 references/lessons-learned.md，
> 把构建 / 测试 / 迭代中出现的问题、根因、修复、优化逐条记录；下次动手前先 Read 该文件，避免重复踩坑。
> 该文件是强制交付物，forge_check.py 会对 agent_created:true 的 skill 核查其存在（缺失即 BLOCK）。
> 另外，skill-forge 自身暴露出泛化规则缺口时，要起草对 forge_check.py / 本 SKILL.md 的补丁并请用户确认后落地，同时自增 version。
> 5. 检查器也要被检查（元验证闭环）——跑 forge_check.py 前先确认 skill-forge 自身与检查器是最新版、无已知未修复盲区（Phase 3.0 / 4.0）；
> 检查器报告须自报版本（Checker: skill-forge vX），杜绝用过期检查器跑出"假 PASS"。
> 6. 成功经验必须沉淀为默认范式（防自由发挥）——凡本次验证通过、走对了路的做法，必须沉淀为 references/success-patterns.md 的"已知良好范式"
> （场景 + 制胜做法 + 成功证据 + 可复用要点 + 适用边界）；下次同类任务先套用已验证范式、再在此基础上调整，而非从空白自由发挥。
> forge_check.py C36 对"已迭代多轮却无成功范式"的 skill 给出 WARN 提示（软约束，不阻断）。
> 7. 回复结果必须带证据，禁止凭记忆与猜测断言——任何由 skill-forge 创建的 skill，向用户汇报结论 / 结果 / 状态时，必须附带可验证证据
> （命令输出、文件读取内容、测试 / 检查器报告、退出码、日志片段等），不能只说"我记得 / 应该是 / 没问题 / 我猜"。
> 严禁猜测与假设：拿不准、未验证、未读取的部分，必须明确说"未验证 / 未读取"，绝不允许靠猜测或假设编出结论（"大概率是 X""应该就是 Y"这类无依据的推断等同猜测，须先查证再下结论）。
> 无证据不结论：证据是结论的支撑，结论须可被证据回溯。该要求须写进 created skill 的 SKILL.md（运行时指令），由 forge_check.py C37 软性核查（同时核查是否点名"禁止猜测 / 假设"）。
> 8. 大任务必须拆解计划 + 严禁谎报读取完成——实施前先评估任务规模：若目标文件 / 代码 / 数据量超出"单次可完整读取并处理的上下文预算"，
> 必须先拆解为可独立验证的子任务并制定计划（逐项实施、逐项验证），不得一次性硬塞进超长上下文导致遗漏或失真。
> 严禁只读一部分就宣称"已读完 / 已完成"：读取必须覆盖全部目标，未读部分须如实标注"未读"而非默认已读；向用户汇报时明确说明读取范围与未覆盖项。
> 该要求须写进 created skill 的 SKILL.md（运行时指令），由 forge_check.py C38 软性核查。

> 表达纪律（对话拟人，按读者分流）：面向用户 / 下游的回复与生成的人读文档须"去壳添魂"——砍敷衍开场、连接词堆叠、金句，有观点直说；
> 按读者分流：机器读的输出（检查报告 / JSON / 机器说明）保持精简不拟人，人读的（对话回复 / 人读文档）才拟人；
> 铁律：只改语气不改事实——数字、结论、证据不得因表达方式而变动。

何时使用

> 补充触发词（长尾，description 已按官方上限瘦身，长尾在此登记）：按需调研、skill 调研、同类 skill 调研、skill 免调研、调研决策、ima 知识库经验、经验分层、按标签分库、分层知识库、ima 多库路由、经验沉淀硬门槛、经验去重、教训去重、去重沉淀、提升闭环、教训提升为规则、回忆纪律、记忆检索、低置信度明说、渐进加载、日志去重、检索词翻译、无结果降级、skills.sh、skills 生态、废弃 skill、下线 skill、deprecated、过期 skill、审核落库、借鉴落库、运行环境、依赖声明、skill 依赖、_work、deliverable、交付物目录、可观测、可复现、verify_scaffold、skill 可观测、skill 可复现、行为留痕、备份留痕、流程分级、样例门槛、子智能体、独立复核、只读环节外包、写智能体、定义智能体、智能体规范、agent 规范、智能体边界、智能体授权、停止条件、升级条件、多智能体、团队编排、agent 分工、agent 交接、agent spec、人格文件、SOUL、AGENTS.md。

• 用户要新建一个 skill（从零写 SKILL.md + 配套 scripts/ references/ assets/）
• 用户要编辑 / 更新 / 迭代已有 skill，尤其是改动触发词、命令、脚本、引用文档、输出格式时
• 用户要求"评估 / 检查 skill 质量""防止 skill 遗漏""skill 完整性""skill 自测"
• 用户要求审核 / 审计 / 审查某个 skill（含外部 / 市场 / 内置 skill），并希望从中借鉴可取之处、沉淀为做新 skill 的经验
• 用户要定义或审计智能体规范——单个智能体 / 一组智能体的职责边界、能力授权、输入输出契约、交接契约、停止与升级条件（走 Mode A，细则见 references/agent-spec-guide.md）。注意：要「能被平台识别、出现在专家列表里」的专家包请找 expert-manager，本技能 Mode A 不造专家包（三层分工表见该指南 §1）

提问纪律（该问就问、该停就停）

先问后动，但只问影响交付边界的——判据是「问错了后果可不可逆」，不是「我能不能猜到」：
- 必问判据：答案不可逆（返工会推倒已完成的工作）/ 下游直接消费（别人拿它当输入）/ 影响验收口径与范围——命中即须问，禁止以「我能推断」自答。
- 停手判据：连续 2 轮无新增信息 / 用户已明确授权或说「你定」/ 再问的收益低于先出最小初稿。停手不等于不交付：拿不到就按最保守假设先出最小可改初稿，把假设晾晒出来供人纠正。
- 上限的性质：数量 / 轮数上限是收敛条件（达不到把握就转最小初稿 / 降级产出），不是合规额度（不是「问满 N 个就算尽到义务」）；跨技能对齐这类口径时只对齐性质、不对齐数值。
- 强度分档：不可逆 / 高风险决策用强档（穷尽必问项、逐条确认），可逆 / 探索型用弱档（先出稿再迭代）；同类问题的第二次询问降档。
- 一次一问 + 给选项带推荐：相关的合并成一组问，每条带选项 + 推荐项 + 推荐理由。细则见 references/operating-details.md Phase 0.8（需求澄清交互规则）。
- 本节由 C98 核查（声明驱动：索引声明 提问纪律：required 时验「真在场 + 含 ≥2 项实质判据 + 正文 ≥120 字符」）；新技能骨架由 init_skill.py 默认写入此节。口径总纲＝跨技能同族键 interaction.question_intensity。

质量基线（harness 工程思路）

本技能自身按「可观测 + 可复现 + 质量门 + 回归守卫」设计，且四要素须落在磁盘事实上（本轮起，见版本历史）：
- 可观测：有可复核的产物——闸结果 _gate_result.json（schema gate-result/v1）与脚本真实输出，不靠"看起来没问题"。
- 可复现：核心判定由脚本给确定性退出码（forge_check.py：0＝无 BLOCK / 1＝有 BLOCK），非人工印象。
- 质量门：scripts/forge_check.py 四维度检查（功能性 / 专业性 / 完整性 / 安全性）+ 封包强制 --strict（任何 WARN 拒包）。
- 回归守卫：scripts/test_forge_check.py（用例回归）+ scripts/guard_health.py（守卫体检，防"该报的不报"静默失效）+ scripts/verify_scaffold.py（脚手架端到端）。

落实证据（磁盘事实，非文本承诺）：自测入口 scripts/test_forge_check.py ｜ 闸结果 deliverable/_gate_result.json ｜ 守卫体检 scripts/guard_health.py。
forge_check.py 的 C28 会核查本节真在场且落实证据来自磁盘（仅在关联索引声明 Harness 基线：required 时核查；未声明不报，是待办不是错误）。
口径总纲＝跨技能同族键 process.harness_baseline（待落公共库 canonical-rules.md，11 → 12 键）。纯文档型 skill 确无自测，可在关联索引声明 Harness 基线：skipped ｜ 原因：… 豁免。

核心概念（摘要，详解见 references/operating-details.md）

1. 关联索引（强制优先）：建 / 改 skill 前先把全部组件（触发词 / 脚本 / references / assets / 输出契约 / 外部工具 / 边界 / 版本 / 迭代日志 / ima 沉淀）登记为可机器核查的映射表（ID / 类型 / 位置 / depends_on / affects / 状态），防改一处漏多处。
2. 四维度质量关卡：功能性 / 专业性 / 完整性 / 安全性，新建与迭代结束必跑；BLOCK=整体 FAIL（退出码 1）、WARN=建议、--strict 把 WARN 也升级为阻断（v1.3.0 起真实生效，封包强制 --strict——交付物必为 0 WARN 0 BLOCK）；回归守卫自动对比 .prev 报告，上次 PASS 本次 BLOCK 即判回归失败。
3. 自我迭代（每个产出 skill 强制内置 lessons-learned.md）：缺失即 BLOCK；追加前 grep 去重、同类教训累计 ≥3 次提炼为规则标 promoted（见 C40）。
4. ima 经验沉淀与复用：跨 skill 经验按功能大标签分层入库 / 制作前检索（软性，外部不可用不阻断）。
5. 外向学习：审核外部 skill 只读萃取，可取之处抽象为通用经验沉淀 ima 或回流 skill-forge（泛化补丁须用户确认）。
6. harness 工程基线：产出 skill 须可观测 / 可复现 / 带质量门 / 有回归守卫（C28 软查，纯文档型可声明跳过）。
7. 流程完整性（G1–G10）：需求验收登记、UAT 卡点、ima 沉淀硬门槛、检索记录、首版回归基准、harness 真验证、运行环境声明、废弃下线、落库校验——全部下沉为"索引可登记 + 检查器可核查"。
8. 智能体规范（Mode A，v1.6.0 立）：Phase 0 的第三种模式（与 Create / Iterate 并列）——把「一个智能体 / 一组智能体该怎么被约束」写成可机器核查的规范：八要素（定位 / 职责边界 / 能力授权 / 输入契约 / 输出契约 / 交接契约 / 停止与升级 / 证据留痕）+ 团队层四件（成员表 / 分工矩阵 / 消息协议 / 并发纪律）。机器侧＝A 系列守卫（独立命名空间）。细则见 references/agent-spec-guide.md。
9. 领域家族标与公共能力复用（v1.6.19 立）：建新 skill 先判领域家族并在 frontmatter 写 family（受控词表 7 值，与 category 同值域 ⇒ C97 核查两者一致）；再查公共能力——清单不手写，＝磁盘上持 contract.json 的技能（当前 5 个，由扫描器抽取）；接入一律引用式（静态零依赖 + 运行时委托 + 探针预检 + 自动回落 legacy，四护栏缺一不可），不得硬依赖（外部硬约束「skill 不得显式引用其它 skill」见 references/external-standards.md §二）。全过程细则（含 7 家族实扫表 / family 映射 / 8 个统一项挂守卫情况）见 references/domain-family-spec.md。

工作流程（阶段地图，详细规则见 references/operating-details.md）

• 编排（Plan）：Phase 0 判定 Create / Iterate / Agent（Agent＝智能体规范模式（Mode A），判据与边界见 references/agent-spec-guide.md §1–§2）→ 0.7 优先检索 ima 经验 + 读经验三动作（自身 lessons/success → 目标 lessons + 范式同类匹配 → 结果留痕 G4，C48 核查）→ 0.5 联网调研（新建必查 / 迭代询问用户；先做"场景→检索词翻译"domain+task；多源含 npx skills / skills.sh；无结果走降级三步：承认 → 直接帮 → 建议自建；外部方案对标分支：外部方案/提示词/报告影响面大时必查业界做法，三栏结论 + 无依据降级）→ 0.8 登记需求与验收标准（G1；需求澄清交互规则：先问后动、一次一问、可判定停手信号、追问 ≤3 轮转最小初稿；给选项须带推荐；用户输入同样过专业判断（存疑才问、不存疑不问）、先判后果再判存疑（不可逆 / 下游直接消费一律必问，禁以「我能推断」自答）——见 operating-details）→ 0.9 计划闸（先分流：决策类[范围 / 取舍 / 风险 / 交付形态]才出试跑计划四要素呈确认；过程类直接做 + 留痕可否决；超范围升级为决策类；确认后第一个动作＝备份并验证可读，再改动）；每次写入前复核目标 version/mtime（多线并行时防覆盖式编辑冲突）→ 长任务：检查点落盘（五要素写 _work/checkpoint.md，覆盖式）+ 压缩保真（不可压清单 / 保因果时序转折点 / 压后抽查）→ 1 建 / 载关联索引（含 harness 合规 + 运行环境 + 需求验收组件 + 对抗性评审适用性判定：按 references/adversarial-review-injection.md 四条判据判定，命中任一项须停下问用户是否注入 grill-me 对抗性评审机制，用户确认后才注入，不注入须留痕声明；注入时必须双层落点（正文口径锚 + references 详细），只写 references 等同不触发）
• Mode A · 智能体规范（v1.6.0 立，仅当 Phase 0 判定为 Agent）：M1 建模——按八要素逐项填（用户说清一项填一项；scope.notDoing（不做什么）与 stopConditions（停止 / 升级条件）必须由用户确认，AI 不得代拟填空——这两项是授权边界，猜错代价最高；只能建议的项写进 _pendingConfirmation 留痕）→ M2 落盘——判落点 / 判白名单 / 判命名，产出 agent-spec.json（机读契约）+ 人读规范（模板见 references/agent-spec-template.md）→ M3 校验——跑 forge_check.py 的 A 系列闸：A1 八要素齐全 / A2「不做什么」≥2 条 / A4 停止条件每条带可判定 criterion（无判据＝不通过）/ A9 授权边界确认状态（WARN）。两个入口：技能内规范走 forge_check.py <skill_dir>，技能树之外的规范（平台团队目录 / 工作区根人格文件——§4 落点的主要情形）走 --agent-spec <path>，否则闸永不触发 → M4 确认——待确认项交用户拍板，确认后删 _pendingConfirmation（A9 转 ✔）→ 重跑 M3。范围诚实：本轮实现 A1 / A2 / A4（BLOCK）+ A9（WARN），A3 / A5–A8 尚未实现（勿当成已覆盖）；落点、平台人格文件的白名单例外、反模式见 references/agent-spec-guide.md §4–§7 → 其余复用 1 / 3 / 3.5 / 4 / 4.5 / 5
• 分析（Analyze）：2 实施改动（迭代时反向查受影响组件）→ 3 跑 forge_check.py 四维度机器检查（含回归守卫）；跑前先做 3.0 检查器自检（确认 skill-forge 与检查器最新、无已知未修复盲区） → 3.5 独立复核闸（严格档默认执行：改质量门 / 核心流程 / 纪律、多文件、不可逆、用户要求——默认起独立子智能体，不询问不省略；只给产物 + 标准，不给实施思路；未走须显式写明原因，C67 核查） → 3.7 外部标准合规审核（取外部权威规范逐条对照，缺口修完转成 C 守卫；基线见 references/external-standards.md）→ 只读环节可外包（0.5 调研 / 0.7 检索可并行起子智能体，写权主 Agent 独占串行）→ 跨技能同步：经验三层归属（方法论归本技能 / 领域经验留在各技能 / 共享知识归 ima）+ 同步三步（读现状 → 同构判定 → 只落增量）+ 独立性原则（下游技能不得依赖本技能运行时） → 流程分级（轻量 / 标准 / 严格三档；标准 / 严格档须先做样例并人工确认再全量铺开；闸位化——有实物品 / 可视产出的技能须把样板门槛落成具名闸并写进其 SKILL.md 正文（只写 references ＝ 不触发），无实物品可评审者显式豁免；投产级产物（下游直接消费）的完整性 / 一致性 / 规范符合类检查必须硬闸；节点门只设"样例后 + 交付前"两道）
• 交付（Deliver）：4 出具可信交付物（索引 + 机器报告 + 自我迭代日志；首版 PASS 建立回归基准）→ 4.5 用户验收 UAT（必须用户确认满足需求才封包）→ 封包 {name}-v{version}.zip
• 进化（Evolve）：5 沉淀教训（追加前 grep 去重，用 Pattern-Key / See Also / Recurrence-Count 累计，同类 ≥3 次提炼为一句预防规则并标 promoted——教训及时消化为规则）+ 沉淀成功范式（C36）→ 泛化规则缺口起草补丁（须用户确认）+ 自增 version → ima 分层沉淀 → 本地知识库沉淀（摘要+回链写 knowledge-hub/personal-kb/02-技能经验/skill-forge/，全文仍写本技能 references/lessons-learned.md——两层协同不重复；新技能由 init_skill 自动建目录并自动挂载 KB-SYNC，规则见 @skill:knowledge-hub-sync）
• 全库（Scale）：harness_runner.py 批量扫描 ~/.workbuddy/skills/*，产出跨 skill 质量趋势报告
• 借鉴（Learn）：6 审核外部 / 市场 / 内置 skill，萃取可取之处沉淀 ima 或回流补丁；6.5 审核落库校验；7 废弃 / 下线（标 deprecated 单列）

> 检查器硬闸口（forge_check.py，v1.3.0 起 C37/C38/C40 为硬性 BLOCK，仅 agent_created）：
> C37 回复须带证据 + 点名禁止猜测；C38 大任务拆解 + 严禁谎报读取完成；C40 经验沉淀去重 + 提升闭环——缺失即质量门 FAIL（一次性脚本型 skill 可在关联索引声明「纪律豁免：skipped ｜ 原因」跳过）。
>
> 守卫体检（guard_health.py，v1.5.39）：动态构造缺项样本，验证"该报的守卫真的会报"——防"静默失效"（守卫被改名 / 正则写错后回归仍全绿）；未验证项如实标记，不假装通过。
> C39 外部工具依赖须配套可用性自检（缺失可声明「外部工具自检：skipped ｜ 原因」豁免）。
>
> 经验 / 知识读取的可核查项（v1.6.1 汇总，用户问「什么时候读、确保会不会读」时按此答）：
> C22 G4 段存在且非空 ｜ C24 已迭代但 lessons 无真实条目＝迭代未沉淀 ｜ C48 G4 段须含日期 且写出「读到了什么」（命中的 Lxx / 范式 / 或显式「无同类」）｜
> C72（v1.6.1 新立） 家族技能的 G4 段须含「工作区记忆」留痕——把"读工作区记忆"（先读顺序第 6 条）从纯纪律变为可核查，补上此前唯一无守卫的重要读取环节；触发范围＝家族技能（判据：SKILL.md 有同一行同时含「家族」与「结构纪律」，即家族通用条款指针的形态；外部 skill 不受牵连）。当前家族成员 5 个：skill-forge · product-prd-prototype · prototype-hifi-pipeline · page-dissection · requirement-communication——成员资格以"带家族通用条款指针"为准，新增成员须在自己的 SKILL.md 加该指针（不靠名单硬编码）。否定式不算留痕（写「未读 / 不适用」不通过，须写恢复了什么）。
> C73（v1.6.3 新立） 版本段条目须已落全量记录（references/version-history.md 或 changelog.md）——版本段按规范保留最近若干条（最新在前），换版本时忘记同步就会永久丢失旧条目（实测曾丢 8 个版本）；判据刻意宽松（只认版本号文本、不认条目格式，因各 skill 格式不同），解析不到版本段或没有全量记录文件时一律不报（保守：宁可漏报不误报）。
> C98（v1.6.20 新立；WARN，声明驱动）提问纪律在场与实质判据：索引行首声明 提问纪律：required 时，SKILL.md 须有「## 提问纪律」节、且节内含 ≥2 项实质判据（停手判据 / 上限的性质 / 强度分档 / 只对齐性质不对齐数值）并 ≥120 字符；声明 on-demand 不强制常驻节但有节则同查（防空壳）；skipped / 未声明 / 占位 / 取值未识别一律不报。机器不判提问语义与语气（语义启发式必然误报），只判可证的在场与要素；入口侧由 init_skill.py 骨架默认写入该节。
> 边界诚实：以上守卫核查的是"留痕写没写、写得实不实"，查不到"是否真读了"——真读靠纪律，可核查性靠留痕；package_skill.py 以 --strict 复跑，上述任一项不满足即拒绝打包（WARN 在交付闸上等价于阻断）。
> 交付闸口：package_skill.py 以 --strict 复跑质量门——任何 WARN 都拒绝打包，交付物必为 0 WARN 0 BLOCK。详见 references/operating-details.md。
> 结构纪律（v1.4.0 立，v1.5.64 扩为家族通用条款，C43 / C71 守卫）：技能树与工作区都必须结构可预期——顶层只放白名单，生成物只有唯一落点，报告只在三类时机产出。
> - 技能树顶层白名单：<技能名>/ · 系统 *.json · _backup/（唯一允许常驻的结构性目录；C54 解析基准硬编码 dirname(skill_dir)/_backup/，不可搬移）。禁止平级 _dist/ _work/ 与散落 .zip（历史版本一律归 _backup/，见其 _README.md）。
> - 技能内白名单：SKILL.md · references/ · scripts/ · assets/ ·（可选）tools/ verification/ config/ deliverable/ examples/ templates/。顶层另允许 1 个依赖声明文件（requirements.txt / package.json 一类，属运行环境声明 G8；v1.5.66 补——实测 prototype-hifi-pipeline 顶层有 requirements.txt，而 C71 只查目录不查文件、故既不报也不合法，属「灰状态」）。过程区只允许 _work/ 一个，且只留 README.md + 最近 1 份机器报告 + 在用脚本，阈值 ≤5 MB / ≤500 文件（C71 守卫）；不可再生的原始素材不得放技能树内，落工作区 _work/assets/<技能名>/。
> - 版本叙事文件口径（v1.5.66 立）：家族内不要求统一文件名——三种形态均合法：① references/changelog.md ② references/version-history.md ③ 无独立文件（SKILL.md 版本段即全量）。但必须在 SKILL.md 版本段写明「哪个是权威 + 首条须等于 frontmatter」。禁止为「命名统一」而改名——实测改名会直接打断既有守卫（如 product-prd-prototype 的 C7 检查 changelog.md 首条 == frontmatter），改名收益远小于风险；统一靠声明，不靠重命名。
> - 生成物唯一落点：过程脚本 / 探针 / 中间产物 → _work/；报告 → 本技能 _work/；交付 zip → deliverable/{name}-v{version}.zip（只放当版，历史版归 _backup/）。
> - 报告只在三类时机产出：① 用户明确要求 ② 交付闸（机器报告 / _gate_result.json）③ 迭代收口（版本历史条目）。其余时机禁止新建报告或过程文档。
> - 临时物命名 + 生命周期：临时目录 / 文件必须以 _tmp 或 .tmp 开头（封包器按此前缀剔除这一类；.{技能名}-* 系残留不在该前缀内，真正拦住它的是 C71 + --strict，v1.6.12 订正——原表述会让人以为封包器已兜住）；.{技能名}-package-<随机> 这类工具暂存目录属中断残留——同一轮任务结束前必须清掉，遗留即由 C71 报出。报出范围（v1.6.11 写明）：技能内任意层级的残留，加技能父目录 _backup/ 顶层的本技能名限定残留（工具把暂存目录建在 --output 父目录，--output 落 _backup/ 时残留即在 _backup/ 顶层）；不含 _backup/ 里非本技能名限定的通用临时物——那属树级问题（harness_runner.py 的 C71-T）。形态穷尽（v1.6.12）：同一工具还会产出 .{技能名}-<随机>.zip.tmp（mkstemp），同样报出；技能名匹配大小写不敏感（Windows 文件系统不敏感）。封包落点（v1.6.12 受控实测订正）：工具会自清——package / backup 的 finally 里 shutil.rmtree(stage_root, ignore_errors=True)，实测「--output 落普通目录」「落 <x>/deliverable/」两臂 rc=0 均无残留。但清理带 ignore_errors=True：进程在 finally 前被杀、或清理本身失败，都会被静默吞 ⇒ 残留仍会出现（判据＝异常终止 / 清理未完成，不是「成功也留」）⇒ --output 宜落在技能目录之外，再把 zip 移入 deliverable/，让「万一清理失败」的落点不在技能树内（C71 就不会命中）。
> - 产出前检查（四步，落盘前必过 · v1.5.65 立）：① 判落点——过程物 → _work/；交付件 → 本技能约定产物根 / 交付目录；报告 → 只在三类时机。② 判白名单——技能内目录须在白名单，新结构寄生既有目录，禁新建顶层平级目录。③ 判命名——临时物以 _tmp / .tmp 开头，本轮结束前清。④ 判不出落点就不落盘——先确认再写，禁「先写再说 / 边写边想」。本条是上述各条的动作化：条款写下 ≠ 被执行，故纪律必须落成产出前的动作序列，而不只是可被跳过的说明文字。
> - 禁令的相邻归属（不禁什么）：不禁创建 / 保留 _work/（它是官方过程区，只需瘦身）；不禁工作区（非技能树）侧自建归档结构；不禁 verification/ 内的用例夹具（那是验证资产，不属过程稿）；不禁平台约定落在工作区根的人格文件（AGENTS.md / SOUL.md / IDENTITY.md / USER.md / BOOTSTRAP.md——v1.6.0 补：它们按平台约定必须在工作区根，与「工作区根白名单」天然冲突，故显式列为例外；不写这条例外，读者会把合法动作一起停掉，同族 guard.scope_ambiguity）。
> - 口径差异（打包排除）：交付物 = SKILL.md + scripts/ + references/ + assets/ + deliverable/；自带 package_skill.py 排除 _work/deliverable/verification，而 skill_ops.py 三者皆不排除且其 validate 会扫 _work/ ⇒ 用标准工具链时以「工作区内干净副本」为源，见 operating-details「封包工具链与干净副本做源」。

配套资源

> 运行环境：仅 Python 3.x 标准库（9 脚本零第三方依赖，Python 3.13 实测）。回归测试为自定义入口 python scripts/test_forge_check.py（自研 _case 框架，非 pytest/unittest；入口打印实跑条数），python -m unittest 发现不到属预期。

先读顺序（执行本 skill 前）

1. references/operating-details.md（概念详解 + Phase 0–7 规则）——执行细节以它为准
2. references/lessons-learned.md + references/success-patterns.md（历史教训与成功范式）——lessons 先读文件头「Pattern 家族索引」表，只下读跟本次任务撞脸的家族（全读会让相关条目淹进无关条目；见 operating-details「教训结构化与分层读法」）
3. references/association-index.md（本 skill 自身组件依赖图）
4. references/machine-spec.md（机器对接契约）/ references/overview-guide.md（人读综述）
5. 个人知识库（可选增强，路径不存在自动跳过；KB-SYNC 自动挂载）：06-个人偏好/ 4 文件 → 00-索引层/术语表.md → 02-技能经验/skill-forge/使用技巧.md + lessons.md 摘要（先辅）；需要细节再读本技能 references/lessons-learned.md 全文（后主）。（造新技能/迭代前另读全部技能经验 + 01-通用经验/；09-外部文档切片/ 与 10-待分类/ 只读不写——写入归整理任务）。 协同规则见 @skill:knowledge-hub-sync（KB-SYNC 挂载，唯一权威源，本地无副本）
6. 项目工作区记忆（跨会话/长任务接续必读；本会话简单新任务可跳过）：<工作区>/.workbuddy/memory/MEMORY.md + 最近 1–3 个 YYYY-MM-DD.md 日志——恢复「上次干到哪 / 用户已定口径 / 项目约定 / 交付物位置」，先于技能经验读取；避免跨会话接续时只靠系统注入的摘要（可能不全）

版本历史

• v1.9.2（2026-09-25）：F4 收口——把「隐形守卫」补登记为 C100（注册表 + §6 + 组件表 + 行为体检四处配齐），并为三位数编号扩 §6 解析正则（PATCH） —— 起因＝上轮登记的 F4 挂账（用户「下一轮从 F4 起」，并拍板「按此推进」〔取 C100 + 扩 _row_re〕与「一并修」〔顺手瑕疵〕）。① 写前两件事＝60s 并发判定（20×3s，0 变动；自检三项全过，含灵敏度反向验证——人为拨 mtime 能被差分抓到 ⇒ 证明差分不是恒空）＋备份 _backup/skill-forge-v1.9.1-20260925-0558-preC100.zip（33 文件 / 1,244,812 B）。② 问题＝关联索引「路径漂移」守卫是真守卫（forge_check.py Completeness 段），却既不在 GUARD_REGISTRY、也不在 §6 ⇒ 不受 C45 双向核、不被 guard_health.py 行为体检、报文不带编号；历史条目曾称它 C11，而组件表 C11 是「回归守卫」⇒ 号段已错位。③ 取号 C100＝两位号段 C01–C78 + C85–C99 已占尽、C79–C84 有意缺号（家族其它技能占用）⇒ 顺延三位数。④ 必要前置＝扩 _row_re：C45 的 §6 解析正则原为 C\d{2}（只认两位）⇒ 不扩则 §6 里 | C100 | 解析不到、反被 C45 报「漏登记」而闸红；扩为 C\d{2,3} 并顺带修掉一个已登记的限度（三位数编号原先静默忽略 ⇒ 真缺陷样本退化成"没报"）。影响面先核：该正则全库仅 1 处使用、无用例依赖旧行为。⑤ 报文同步＝两条漂移报文加 ，C100，但保留「疑似漂移」子串（既有回归用例依赖它，grep 疑似漂移 共 7 处）。⑥ 顺手修 2 处＝C99 组件行移回序号位置、test_forge_check.py 用例名过期计数「38 条」→ 54 条。验证＝回归 194 → 197 条全过（3 条两侧成对）· guard_health.py 75 → 77 例（1 正 1 反）· 负样本验收（新用例喂给改前检查器 ⇒ 恰好 2 条转红〔C998 幽灵 / 报文带编号〕+ 1 负对照保持绿；另做受控变异——只把 _row_re 回退为 C\d{2} ⇒ C45 报「§6 漏登记 C100」，证明扩正则是必要前置）· --strict：升版后未刷新闸结果时 rc=1（C65 + C96 各 1 条），刷新闸结果后复测 rc=0 / 0 WARN（封包前）；注册表 57 → 58 条（实现 53 → 54）、组件表 91 → 92 行。顺带发现（如实登记）＝组件表 C47 行亦乱序（排在 C56 后，不在批准范围、不擅自动）+ 技能树顶层 .backups/ / _work/ 属 C71-T（树级、不在四闸内、mtime 早于本轮 ⇒ 非并发写入者）⇒ 两项入 §待办。

• v1.9.1（2026-09-24）：修「把跨技能引用判成本技能漂移」的两条守卫 + 补两条静默跳过 + 订正一处失实文档结论（PATCH） —— 起因＝承接上轮登记的两条挂账（写前先做 60s 并发判定（20×3s）：0 变动 + 正向自检有效 ⇒ 静止态；备份 33 条目 / 1,206,616 B 落技能树顶层 _backup/）。① C63「跨技能引用」豁免：报文 ≠ 实现——实现把跨技能名单硬编码成 4 个名字，报文却称「跨技能引用已自动豁免」；实测引用 skill-crafting / dual-track-conformance 等其余任何已安装技能仍被误报。改为 _sibling_skill_names()（从磁盘抽取，口径同 _public_engine_names）并排除自指。② 关联索引「路径漂移」守卫：加左界 + 跨技能解析——原路径正则无左界，带技能名前缀的路径被抽成以 scripts 开头的短路径（丢掉前缀）⇒ 本技能内当然不存在 ⇒ 必然误报 BLOCK（本轮前由一次真实误报复现）。改为「前缀在磁盘上是同级技能 ⇒ 解析到同级目录去核；否则按本地路径核」——既消误报，又把「跨技能引用腐烂」纳入真检测。③ 本版内自查出的真缺陷（由既有回归用例抓出）——名单动态化后，同级若存在短名目录（doc），裸子串会命中 ghost-doc.md 里的 doc ⇒ 过度豁免、吞掉本该报出的悬空引用（实测夹具父目录有 18000+ 个无关目录）；两处同修：名单判据收紧为「目录内含 SKILL.md」+ 匹配侧加词边界，并补 1 条用例锁死该形态。④ 账本段名写死 ⇒ 两条守卫静默跳过（F3）——C86（索引粘行）与 C54（备份痕迹）都用写死的段名去读取账本段，实测 dual-track-conformance / prd-prototype-diff 用 ## 维护记录 ⇒ 两条守卫对它们静默跳过（有守卫、无保护：失效的闸不报错、只是不再检查）⇒ 段名放宽为「账本段」（迭代维护记录 / 维护记录 / 变更记录）。⑤ 文档失实结论订正——machine-spec.md 原注称「原指向的详解文档全库不存在 ⇒ C63 未报出 ⇒ C63 的扫描面不覆盖本文件」；结论与机理不符：本文件在 C63 扫描面内，真因是该裸文件名没有 references 类前缀 ⇒ 正则不匹配。验证＝回归 181 → 194 条（新增 13 条，全部两侧成对：C63 3 + 索引漂移 4 + 账本段名 6）；⑦ 段名匹配无行锚（本版内自查出的第二处真缺陷）——组件表里解释守卫自身的那行含字面量 ## 维护记录，无锚时那个 ## 被当成段落起点 ⇒ 从表格中间伪造出一个假段（实测本技能索引多 1 个假段、段外内容被无声纳入扫描面）⇒ 段名口径收敛为 _SEC_LEDGER_BLOCKS（唯一定义 + 行锚 ^ / re.M，常量处登记全部 8 处持有者及其口径）；三项预演对拍（C63 改动：全库 24 技能上改前/改后悬空集完全一致；索引漂移：全库 23 份索引改前/改后同为 0 条；账本段名：新增覆盖段 C86 粘行 0 / C54 缺失备份 0）；forge_check --strict rc=0 / 0 WARN；负样本验收（把 2 条行锚用例喂给改前的检查器 ⇒ 恰好这 2 条转红、其余全绿 ⇒ 证明用例真能抓缺陷）；受控变异（把 C63 豁免改回硬编码 4 名 / 把 C86 段名改回写死 ⇒ 正样本各变红、负对照保持沉默）。同步面＝forge_check.py / test_forge_check.py / machine-spec.md（§1 · §6 的 C54/C63/C86 行 · §11 · 用例计数）/ association-index.md（组件表 + 经验检索 + 迭代维护记录 + 待办）/ 本段 / version-history.md。新登记（本轮未做）＝F4：路径漂移守卫不在 GUARD_REGISTRY ⇒ 不受 C45 双向核、不被 guard_health 体检；F5：C67 / C68 段名仍写死 迭代维护记录 ⇒ 对用 ## 维护记录 / 裸 ## 变更记录 的 5 个技能静默跳过（放宽会给他方技能新增 7 条报出 ⇒ 须先按「分批体检」确认）；F6：C98 / C28 / C99 的段剔除仍是窄口径；S3 已知限度：C63 豁免按行粒度 ⇒ 短名作独立 token 时仍可能整行豁免（实测收紧过后会新增 13 条报出，逐条抽样均为合法跨技能引用或「声明不存在」的叙述 ⇒ 保持宽松）。｜备份：_backup/skill-forge-v1.9.0-20260924-2030-preGuardFix.zip（33 条目 / 1,206,616 B，testzip() 返回 None）｜复核：独立子智能体 · 严格档（只给产物 + 验收标准、不给实施思路）· 结论 PASS-with-caveats（P0 无）——S1–S9 九条逐条 PASS，含复核方自跑的受控变异（M-A 把 C63 豁免改回硬编码 / M-B 把 C86 段名改回写死 ⇒ 各 191 ✔ + 1 ❌、零误伤）与全库零新增（旧 vs 新检查器跑 23 技能 ⇒ 逐技能 issue 集合完全相同）；4 条 caveat 已逐条处置（E1 留痕口径重写并同步版本史 / E2 分发包由封包兑现 / S2 报文措辞同步 / S3 登记为已知限度）。

• v1.9.0（2026-09-24）：闸口深度化——判据从「读目录」改为「读内容」，并补两个漏网形态（MINOR） —— 起因＝用户口径「所有的检测 / 评审 / 闸口都应该是深度检索，读取内容、比对文档，而不是简单地读取目录」，并明确「创建的技能如果判断可以使用公共能力的一定需要使用公共的」。① C28 深度化：旧判据自己写明「按文件名判，不读内容」「空的 .py 同名文件亦算证据」——存在性判据的典型病症（PASS 只证明「有个同名文件」）。升级四处：扫描范围补 verification/（旧实现看不见 product-prd-prototype/verification/**/test_*.py，该技能正因目录不在范围被漏认）；自测入口读内容（>=200B + AST 可解析且去 docstring 后仍有 ≥200 字符可执行体）；闸结果读 JSON（可解析 + 非空 overall + 非空 gates）；守卫体检须存在且 >=200B。刻意不要求 assert——实测test_interaction_gate.py（18884B、0 个 assert）是以退出码判成败的合法自测台，用关键词当判据会造假阴性。改前测量：存量 16 个自建技能零新增 WARN。② C93 两处扩围：前置条件从「有 probe_*.py」放宽为「有跨技能调用动作」（实证 product-delivery-review/scripts/review_gate.py 真的委托 prd-prototype-diff，但委托写在 *_gate.py 里、没有 probe 文件 ⇒ 旧判据整条漏掉）；引擎清单从手写 3 个改为从磁盘抽取（旧清单缺 3 个真引擎、含 1 个非引擎）。③ 新增 C99「公共能力优先」（声明驱动）：落实「判断可用公共能力就必须用」——判「判断留痕在场」（真消费归 C93），机器不判语义。过程中的两次自我纠错（新判据首跑即被真样本抓住）：C28 补丁首版直接 open() 了 collect_files 返回的相对路径，静默 continue ⇒ 3 个有自测入口的技能被误判「无落实证据」；C93 扩围首版用「引擎名 + subprocess」当调用判据，误报 11 处（自指 5 + 散文提及 3）⇒ 收紧为「真的拼了对方 scripts 路径」并排除自指。验收：① 副本预演（真实检查器 vs 副本检查器跑同样 16 技能）新增 WARN=0；② 受控变异实验——占位闸结果 / 空同名桩在浅判据下漏检、深判据下检出，正样本两侧不报；③ 回归 158 → 173 条（新增 15 条：C28 深判据 3 + C99 8 + C93 扩围 4，两侧成对；同版加固后 181 条，+8：R1 2 + R2 1 + R8 2 + 模板自伤守卫 3），并修 3 个会被收紧打破的旧样本（test_check.py 仅 28B / 闸结果样本无 overall / guard_health.py 仅 12B）。④ 出口侧复核加固（同版内）：独立复核 8 项 ⇒ 落地 4 项 —— R1（候选闸结果取第一个合格件，旧实现取第一个存在件即 break ⇒ 根目录占位件会遮蔽 deliverable/ 的合格件）/ R2（自测入口改 AST 判定，旧实现只剥 # 行注释 ⇒ docstring 桩可冒充）/ R5（C93 报文改「可证事实 + 条件式风险」）/ R8（C99 排除自指）；其余 4 项如实登记已知限度。⑤ 收口期自查出两处真缺陷：⑴ C99「信息地图」行写入带目录前缀的示例路径 ⇒ 新技能出厂 2 条 BLOCK（checker.self_harm 第八形态第 3 次复发）⇒ 模板改裸文件名 + 自检内建进生成器（init_skill.template_self_harm_paths()）+ 3 条正反用例；⑵ init_skill.py 的 import re 原写在 if __name__ == "__main__": 内（脚本运行不报、被 import 即崩）⇒ 提到模块顶层。同步面：GUARD_REGISTRY（56 → 57）、machine-spec.md §1/§6、init_skill.py 模板、lessons-learned.md（第八形态第 3 次复发）、guard_health.py、本段、version-history.md、association-index.md（组件表 + 迭代维护记录）。

• v1.8.2（2026-09-24）：闸随内容走——C69 / C86 补扫「分册后的归档册」（PATCH） —— 起因＝P4 第二批把 association-index.md 的「迭代维护记录」与 lessons-learned.md 的「条目字段口径」按月份分册后，forge_check 对 hifi 报出 C69 幽灵键 WARN 4 个（checker.empty_pass / checker.static_limit / geom.coord_must_measure / parity.two_way_audit）——索引表登记了键，而承载条目的正文被迁走了。根因＝C69 只读 lessons-learned.md、C86 只读主文件的「迭代维护记录」段，都没跟着内容走。改法＝① C69 把 lessons-learned-entries-*.md 并入正文一起核；② C86 把 association-index-log-*.md 整文件纳入粘行扫描（归档册整体即该段的延续）。原则（升为通用纪律）：内容搬走，闸要跟着走——否则拆分会让既有闸静默失效，比不拆更危险（失效的闸不报错、只是不再检查）。验证：C69 幽灵键 WARN 4 → 0；C86 仍报「通过 ✔」——主文件刻意保留段标题与最近条目，保证判据仍被触发（若整段迁走，C86 会因段不存在而静默跳过）。

> 完整变更记录见 references/version-history.md（逐版全量）。本段保留最近若干条（最新在前），不删历史。
- v1.8.1（2026-09-24）：C63 悬空引用豁免改为模式匹配——修「changelog 分册后历史引用被报成悬空引用」的假报（PATCH） —— 起因＝产品家族 P4 把 changelog.md 分册为 changelog-archive-2026-09-p1.md 等 8 个文件后，forge_check 对 hifi / ppp 各报 1 条 C63 WARN。根因（不是新缺陷，是被豁免掩盖的旧引用）＝_HIST63 是精确文件名元组，只含 4 个历史文件名；那些引用一直躺在 changelog 历史叙述里被豁免挡住，分册后新文件名不在清单 ⇒ 同一批历史文本突然按普通正文扫描，旧引用被判悬空——分册只是挪位置，不该改变豁免性质。改法＝新增 _is_hist63(name)：name in _HIST63 或（startswith("changelog-archive") 且 endswith(".md")），扫描处改用它；只放宽历史类文件，不动判据。
- v1.8.0（2026-09-24）：harness 工程基线落成「声明驱动」三段式——升级既有 C28（保编号）+ 入口注入 + 回归 / 体检成对（MINOR） —— 起因＝用户提交外部方案《AI Harness 工程化框架 · 项目级公共底座方案 v2.0/2.1》，主张「把 7 个引擎抽成项目级公共底座，所有技能都跑在上面」。同构判定先行（逐条实查，不照抄）：4 条平台已有（模型调用 / 上下文管理 / memory / 部署发布——workbuddy 系统级 models.json、settings.json、身份记忆文件）、3 条半同构（Prompt 管理 ≈ SKILL.md 三态确认闸；评估测试 ≈ 四维度机器闸 + 回归；调试监控 ≈ 闸结果与报告）、2 条技能层不可实现（跨技能共享运行时；工作区级配置面——实测只有 memory/ 可写）、1 条真缺口（harness 基线只有声明没有落实）、1 条须改写（「温度参数标准」——models.json 无 temperature 字段、settings.json grep 0 命中，替身是 reasoning.effort ⇒ 改写为「行为强度契约、禁写数值」）。真缺口取证（全库只读实测，自建 16 技能）：索引含 harness 声明 16/16，而回归守卫 1/16、自测入口 3/16、闸结果 9/16 ⇒ 典型「声明满格、落地稀薄」（guard.keyword_gaming 的病症：PASS 只证明「碰巧提到」）。落地三段式（依 D1–D6 决策）：① 入口注入——init_skill.py 的 INDEX_TEMPLATE 写死声明行 Harness 基线：required（值域 required ｜ on-demand ｜ skipped），信息地图补「harness 基线」权威源行（新建即带）；② 出口拦截——升级既有 C28（保编号，不新立） 为声明驱动 + 落实证据：required ⇒ ① SKILL.md 须有「质量基线 / Harness 基线」节 ② 含 scripts/ 者落实证据须来自磁盘事实（自测入口 test_*.py / 闸结果 _gate_result.json / 守卫体检 guard_health.py 至少其一）；on-demand ⇒ 不强制常驻节、有节则同查磁盘证据；skipped ⇒ 跳过；未声明 ⇒ 一律不报 WARN（待办不是错误，对齐 D2 / C97 / C98）；③ 豁免沿用既有形态。本轮自查抓出并修掉的三处（非外部提出）：(a) 实现与声明分叉——定稿前「未声明 且 索引未提 harness」仍会报 WARN，与注释 / 决策 D2 正面矛盾（「报文声称的动作必须在代码里找得到」的反向形态：代码做了报文没说的判定）⇒ 降为证据行并固化为回归守卫 t_c28_undeclared_no_kw_ok；(b) 模板组件编号自相矛盾——init_skill.py 的组件表登记 harness 合规＝C04，正文两处却写「登记 C07」⇒ 生成的新技能索引出厂即自相矛盾，已改齐 C04（并如实登记：references/association-index-template.md 用的是 C07，两份同源模板编号不一致，登记为待办）；(c) 留痕失实——G4 检索记录引用的 process.declaration_drift 并不在家族索引表内（此前仅出现在正文散文里，C69 只解析 Pattern-Key： 形态 ⇒ 表外键对守卫不可见）⇒ 本轮正式登记入表（45 → 46 键）并补正文条目。验证：① 回归 144 → 158/158 全过（C28 共 14 条：4 真缺陷 + 3 正样本 + 7 反向样本）；② 受控变异实验（把 required 识别分支打断 ⇒ C28 两条真缺陷全转红、其余 11 条保持沉默、零误伤；实验脚本属过程产物、不在技能内，故只记方法与结论、不引路径）；③ guard_health.py 59 → 67 已验证 / 0 盲区（C28 从 UNVERIFIED 移入实测，+8 例）；④ 本技能自身 dogfood——索引声明 Harness 基线：required、SKILL.md 备「质量基线」节、三项磁盘证据齐备，C28 实跑报通过 ✔；⑤ 存量 16 个自建技能零新增 WARN。独立复核（严格档）驱动修复（第二轮，逐条留痕）：对定稿做独立复核（只给产物与验收标准、不给实施思路）——复核者自造反例 + 自做四组变异测试，7 条验收标准判 6 PASS / 1 FAIL，并抓出 3 处文档与实现 / 事实的偏差，本轮逐条修掉：(a) 报文 ≠ 实现（最硬，复核以探针实测证明）——提示文案写「文件名为 test_*.py」，实现却是 startswith("test_")、不限扩展名；实测 test_probe.txt / demo_selftest.md 这类同名桩都被当成自测入口 ⇒ 判据可被同名物绕过（guard.keyword_gaming 病症）⇒ 两侧同修：实现收紧为 .py + 报文按真实判据改写（连同 machine-spec.md §6 / 本索引组件行 / operating-details.md 概念 6 / 脚手架模板共 5 处同源文案一并改齐）+ 新增 1 条真缺陷用例与 1 条体检例守住收紧后的语义——该用例经负样本变异验证：把判据改回旧形态即变红、原有正样本零误伤（checker.negative_control：只打印 PASS 的闸等于没有闸）；(b) 引用悬空的留痕——版本段引用变异实验脚本路径，但该脚本在本轮工作区、不在技能内，且 _work/ 前缀逃过 C63 漂移扫描（其正则只认 scripts|references|assets|tools 前缀）⇒ 改为描述性说法、不再引路径；(c) 计数自相矛盾——同一事实（C28 用例分类）在版本段写「5 + 8」、在机器说明写「3 + 3 + 7」（实测以后者为准，「5」把真缺陷与正样本混计）⇒ 统一为「4 真缺陷 + 3 正样本 + 7 反向」（同族 process.declaration_drift：同一事实的全部声明触点须一次改齐）。另补：机器说明 §6 与组件行写明残留限度「不读证据文件内容」（空 .py 同名文件亦算证据）——复核点名的 S4，属文件名判据的固有上限，如实声明而非假装覆盖。独立复核未覆盖事项（由复核者主动列出，原样登记）：改动前的存量基线快照无法取到（只能证「当前全库零 C28 WARN」）；144 → 157 / 59 → 66 的「改前侧」已不在盘上，只能核终值。同步文件：forge_check.py / test_forge_check.py / guard_health.py / init_skill.py / SKILL.md / machine-spec.md / association-index.md / version-history.md / lessons-learned.md。未做（如实登记）：process.harness_baseline 尚未落 public-kb/canonical-rules.md（下一任务）；两份同源模板的组件编号不一致待裁决；评审稿 D5 / D6 的《新技能制作规范》并入待评审通过。
- v1.7.2（2026-09-24）：存量 family 补标批次二/三（部分完成）+ 刷新规范现状声明（PATCH） —— 起因＝继续执行补标待办（用户「有待办就执行」/「继续」）。本轮实测：① 完成 3 个——产品家族的 page-dissection（v0.7 系列）与 prd-prototype-diff（v1.3 系列）、能力引擎家族的 visual-analysis-engine（v1.2 系列），三者均静止且 skill_ops validate 通过，补标后 family == category（C97 ✔）、C73/C90/C96 复跑通过。② family 持有者 4 / 23 → 7 / 23。③ 发现硬前置（本轮最重要）——skill_ops backup（唯一许可的备份工具）必先过 validate，而全树 validate 实测仅 8 / 23 通过 ⇒ 余下 9 个待补技能中 6 个被既有校验错误硬阻塞（absolute_path 用户绝对路径泄漏 / history_section 变更记录章节 / dead_reference / body_length 正文超 500 行 / state_marker）。故本批只能先做「静止且合规」的子集，其余按「先修校验错误、再补标」排序（详见 domain-family-spec.md §6 批次表）。改法：domain-family-spec.md §2.4 / §6 现状声明刷新 + §6 批次表重排（含阻塞原因）。不改：守卫判据、回归用例、脚本行为。未做（如实登记）：余下 9 个补标、C99（经验读取侧守卫）仍未立。
- v1.7.1（2026-09-24）：经验归属改「专项 / 公共」两轴 + 补齐公共库读取链路 + 规范声明漂移刷新（MINOR） —— 起因＝用户提问「沉淀的成功和失败的经验会分级吗 还有分组吗？分组要分为专项和公共的，写入读取时候都需要注意」。取证（盘上事实，先取证再动手）：① 分级已有三套、缺强度维——成熟度（Status / Recurrence-Count / 已升规则 / 已定稿）+ 读取成本三档 + 流程三档；后两者同名不同义（一个管「读多少」、一个管「走多重」），与 v1.6 系列在 interaction.question_intensity 里立的「不得同名混用」同族 ⇒ 本轮如实登记（不改档位名：改名会打断既有守卫与索引）。② 分组已有三维，但「专项 / 公共」不是一等概念——归属层（v1.5.31「三层」）/ 家族键 / 公共库四视图。③ 四处实证缺口：(a) 写入侧无判据（唯一信号是生成器事后算出的「同键 ≥2 技能」）；(b) 归属层过时——v1.5.31 的三层表不含 09-22 才建的 public-kb/；(c) 读取侧完全没接（最严重）——「读经验的四类固定动作」与「经验三源体检」都未含本地 public-kb/（第 ③ 源「ima 共享/订阅库（公共库）」指的是云端）；全树 grep 实测 public-kb 只出现在变更记录 / 参考说明 / 生成器注释 ⇒ 正违反本技能自立的 process.sink_vs_retrieve（沉淀的验收是「下次能被检索到」，不是「写进文件了」）；(d) 同名冲突——「公共库」被 ima 云端占了名，本地 public-kb/ 反而无名。改动：① operating-details.md §「经验三层归属」→ §「经验归属：专项 / 公共两轴」——轴一 归属（专项＝技能内 lessons-learned / success-patterns〔唯一权威源〕；公共＝工作区 public-kb/〔只读派生视图〕）；轴二 分级（成熟度 × 强度〔已落硬闸（登记守卫编号）/ 软约束〕）+ 写入判据三条（同键 ≥2 技能 / 已被机器守卫承载 / 属方法论域，任一即建议升公共、须人工确认）+ 读取顺序（自身专项 → 同族公共键 → 目标专项 → 三源）+ 消歧（「公共库」归本地 public-kb/，ima 第 ③ 源改称 「ima 订阅库」）。② §「经验三源体检」补第 ④ 源＝本地公共库（探测 public-kb/index.json），「三源」→「四源」。③ §「读经验的四类固定动作」→ 五类，新增「读公共同族键」。④ domain-family-spec.md 刷新声明漂移：§2.4 / §6 的「family 当前 0 / 23」→ 4 / 23（skill-engineering 家族 4 / 4 完整）；§3.1「当前实测快照」版本同步（dual-track-conformance v1.0 系列 / skill-evaluation-engine v1.0 系列）。⚠ 读取侧无机器守卫（如实挂账，不假装已覆盖）——现有守卫只查「检索记录段是否非空 / 有无真实痕迹」（C48 / C67 / C68），查不出「有没有去读公共键」；候选 C99 须先定「跨技能键」的判据算法（需跨技能扫描）⇒ 登记为待办（与 guard.rule_without_guard 的关系：本要求按 §4「缺口如实挂账」的既有惯例标注，而非假装已落闸）。默认假设（可推翻，用户「继续」＝按建议放行）：强度取值＝登记守卫编号；本轮不加 C99；同意消歧改名；不顺带修 skill-install-audit 的两个既有 WARN。验证：forge_check --strict PASS / rc=0 / 零 WARN；回归 / 守卫体检 / 脚手架三闸复跑；版本三处一致 + C69/C94 家族键双向一致。
- v1.7.0（2026-09-24）：批次 T1 收口——封包链路接入守卫体检 + 组件表补登 + C71 漏报/精度修复（MINOR） —— 起因＝用户「把待办处理吧」并选定批次「我点名的 3 条 + 同类小缺陷」⇒ 逐项先取证再动手（不凭待办文字）。① 封包链路接入守卫体检（P2-3）——package_skill.py 此前只跑 forge_check --strict，而 guard_health 只在 emit_gate_result.py 的 GATES 里 ⇒ 守卫体检没过也能被打包；改为 generic 接线：目标技能内存在 scripts/guard_health.py 就跑它并要求 rc==0（不存在则跳过 ⇒ 其余技能零影响）。② 封包器排除逻辑建回归（test_forge_check.py 全域 packag 0 覆盖）：排除判据抽为模块级 _is_excluded(rel_parts, name)；verify_scaffold.py 新增 [2c] 封包链路回归（独立硬前提，不并入 C29「五点」，同 [2b] 的处理）——9 组谓词正 / 反样本 + 真实打包比对剔除物 + guard_health 接线双臂（rc=0 产出 / rc≠0 拒包）；并把匹配面由绝对路径 parts 改为技能内相对路径（避免同名祖先目录被误排除）。③ 组件表补登 14 行——C77（人读 overview-guide.md）/ C78（quick-start-template.md）补「§2 资源地图有、组件表 0 次提及」的登记面缺口；C85–C96（12 条守卫）此前只登记在 §6 与 GUARD_REGISTRY、组件表缺行；并写明登记惯例（守卫型组件 ID == 守卫编号 · 子守卫随父组件登记不单列行 · C79–C84 缺号是有意的——让位家族其它技能）。④ C71 顶层扫描不再一律跳过隐藏项——旧写法 not n.startswith(".") 把 .cache/ 一类白名单外隐藏目录静默漏报（独立复核 P2 实测 NO-REPORT）；改为「白名单外一律报，仅 C71_ALLOWED_HIDDEN（.git/.github/.vscode/.idea）豁免」。⑤ C71 体量提示精度——%.1f MB 在阈值调小时退化成「0.0 MB > 0.0 MB」⇒ 新增 _fmt_size 按 B / KB / MB 自适应。⑥ 文档四处小修——operating-details.md「版本号书写规范」末句收窄到正文（扫描器只读 SKILL.md；references/ 的取证性记述保留精确版本）；version-history.md 文件头补排序说明（降序、首条＝最新——v1.6.10 降序重排后该待办实际已过时，本轮如实登记并补说明、不留假待办）；lessons-learned.md 里 _backup/…v1.5.33… 串补注为「当时错误记录的原文引用」（按「不抹事实」保留原文）；SKILL.md 配套资源表被一个空行截断（后半段因此丢表头、按 GFM 不渲染为表格；存量）⇒ 删该空行。⑦ 教训沉淀——新家族键 guard.exemption_by_shape（豁免必须枚举、禁用形态 / 前缀 / 通配一刀切），并把「排除逻辑缺回归覆盖」并入 packaging.transient_leak 第四形态（家族键 44 → 45）。⑧ 顺带修——组件表 C67 行竖线未转义（| 被当表格分隔符 ⇒ 该行渲染错格；v1.6.0 复核即点过）。验证：forge_check --strict 四维 PASS / rc=0 / 零 WARN；回归 141 → 144/144；guard_health.py 57 → 59 已验证 / 0 盲区；verify_scaffold PASS（含新增 [2c] 四项子检查）；_gate_result.json 刷新（overall=PASS / gates=4）。复核＝独立子智能体（严格档：只给产物 + 验收标准 + 检查清单、不给实施思路）：PASS-with-caveats（P0 无）——8 项硬验收全过（含封包排除面端到端真跑、rc≠0 拒绝打包且无产物落地）；P1×1＝§2 组件号范围陈旧（C01–C76 → C01–C78 与 C85–C96）本轮已修；P2×6：2 项存量（3 个 references/ 文件行尾与约定不符 / 资源表被空行截断——本轮顺手修）、3 项观察（闸结果 evidence 含绝对路径但不进包 / 版本条目措辞时序差 / 组件表行数自报 89 实为 90——已订正）、1 项口径题（C71 新豁免的隐藏项在 C92 不豁免 ⇒ 已登记待办待拍板）。
- v1.6.21（2026-09-23）：「提问纪律」跨技能共同形补齐 + 外部源登记 + 已知限度 + 独立复核修订（PATCH） —— 起因＝v1.6.20 落地「三段式」后两端并进：① 本会话取得独立复核（严格档）结论；② 另一会话对同一功能做逐条复查（对照公共库键与外部源）。本轮合并且逐项实测：① 独立复核修订（P1×1 + P2×6 全修）——C98 声明解析前先剔除「迭代维护记录」段（该段是散文区，行首写成声明形态的历史叙述会被误当声明 ⇒ 对没声明的技能系统误报），并补 4 条回归（137 → 141）；machine-spec.md §6 对 C98 的措辞过度承诺收窄为实测口径（判据实为「≥2 项要素词命中 且 正文 ≥120 字符」；真「讲清与否」机器判不了、归人 / 独立复核）；资源地图组件号C01–C74 → C01–C76；更正「存量 16 个全部未写」为「除本技能自身外其余 15 个」；lessons-learned.md 家族索引表被空行截成两张表 ⇒ 删该空行。② 跨技能共同形（P0-1 / P1-4）——公共库键 interaction.question_intensity 的家族规范形补「档位统称提问强度档、不得与流程分级的轻量/标准/严格同名混用」+「先判后果 → 再判可答性」硬顺序（只改文档、不动 C98 关键词，故回归数不变）。③ 外部源登记（P0-2）——references/external-standards.md 补生态共识源 ask-questions-if-underspecified（社区多份同名变体，非官方发布；官方机制为 Claude Code AskUserQuestion）+ checklist 四项 + 审核记录（此前该文件提问 / 澄清维度 grep 全 0 命中）。④ 已知限度（P0-3）——§6 的 C98 行补「有节但没写声明行 ⇒ 不被核查」（声明驱动解析法的固有限度，不得据「无 WARN」推定全库已覆盖）。⑤ on-demand 入选判据（P1-5）——§7 补「有无对话环节 → 提问是否主路径」两级判定（此前版本只写「先留给人判」）。⑥ 下游首个样板（同轮）——requirement-communication 的「## 提问纪律」节实测仅命中 1/4 项判据 ⇒ 直接声明 required 会当场刷红（自伤），按「不满足就改到满足」先补节至 4/4 项（2099 字符）再声明 required，并升 v2.2 系列（PATCH；确切版本号见 references/version-history.md，本文件按「别家版本写系列式」约定规避误读）（实测 --strict PASS / 0 WARN）。⑦ 教训沉淀——新家族键 write.readback_assertion（补丁脚本的写后回读断言须按替换类型分型；断言失败 ≠ 写盘失败）。验证：forge_check --strict 四维 PASS / rc=0 / 零 WARN；回归 141/141；guard_health.py 57 已验证 / 0 盲区；lessons-learned.md 家族键 43 → 44（C69 / C94 双向一致）；公共库 check_public_kb.py problems=0 / warns=0。
- v1.6.20（2026-09-23）：提问纪律落成「三段式」——骨架注入 + 守卫拦截 + 豁免通道（MINOR） —— 起因＝用户提交外部方案《澄清式提问引擎（拷问模式）· 公共能力方案 v1.0》，要求「全库技能统一具备澄清式提问模式」。同构判定先行：方案 §一–§五 与库内三处既有实现同构（requirement-communication 的澄清手册 / prototype-hifi-pipeline 的 ask-discipline / 本技能 Phase 0.8 的需求澄清交互规则），且两处与已定稿规范正面冲突（「一次只问 2-3 个」 vs requirement-communication v2.2 系列已取消提问数量上限；「已能推断的不要问」 vs Phase 0.8 先判后果再判存疑）⇒ 经用户依次拍板不新增公共技能 / 引擎，只立跨技能同族键 interaction.question_intensity（落 public-kb/canonical-rules.md）。本轮补的真缺口：「不新增公共技能，怎么保证以后做的技能都有这个模式」——键只是记录，它不会自己跑进新技能里。取证＝全库逐个体检：23 技能 / 16 个 agent_created 中仅 7 个含实质提问判据、没有一个写全（含本技能自身） ⇒ 靠自觉必然漂移；但一律强制会造 16 条 WARN 噪音（噪音一多就没人看＝等同于没立）。落地三段式：① 入口注入——init_skill.py 的 SKILL_TEMPLATE 默认写入「## 提问纪律」节、INDEX_TEMPLATE 默认写声明行 提问纪律：required（新建即带）；② 出口拦截——新立 C98（WARN，forge_check.py），声明驱动：声明 required 者须 ① 真有该节 ② 节内 ≥2 项实质判据（停手判据 / 上限的性质 / 强度分档 / 只对齐性质不对齐数值）且正文 ≥120 字符；on-demand 不强制常驻节但有节则同查（防空壳）；未声明 / 占位 / 取值未识别一律不报（未声明是待办；取值未识别只出证据行——变更记录里用同格式叙述机制属常见写法，报 WARN 会系统性误报，该限度如实写明）；机器不判提问语义与语气（与 guard.keyword_gaming 同源），语义质量归人 / 独立复核；③ 豁免通道沿用既有『纪律豁免：skipped ｜ 原因：…』。验证：回归 141/141 全过（C98 共 11 条：7 条 + 复核补 4 条）；受控变异实验——把 C98 入口改恒假 ⇒ 3 条真缺陷全转红、4 条反向保持沉默（证明用例真在测 C98，不是被别的守卫背书），还原后逐字节一致；guard_health.py 57 已验证 / 0 盲区（新增 7 例，3 正 4 反）；本技能自身先 dogfood——声明 required 并加节（活样本，C98 实测「4/4 项判据、693 字符」通过）。复核＝独立子智能体（严格档，只给产物 + 验收标准 + 检查清单、不给实施思路）：PASS-with-caveats（P0 无）——P1×1（machine-spec.md §6 对 C98 的措辞过度承诺：行为可接受、文档须收窄）+ P2 若干（组件号未随 C76 同步 / 「存量 16 个全部未写」不实 / 教训索引表被空行截成两张 / 声明解析会误吃变更记录里的叙述行 / 三分支无回归）⇒ 本轮全修，仅 1 项登记待办。未做（如实登记）：除本技能自身（已 dogfood 声明 required）外，其余 15 个 agent_created 的 提问纪律 声明一个都没写（＝未声明 ⇒ C98 不报），补声明须逐个体检后分批；on-demand 的适用范围尚无判据，先留给人判。
- v1.6.19（2026-09-23）：落《新技能制作规范 v4.1》——领域家族标成字段、公共能力清单不再手写（MINOR） —— 起因＝用户提出《新技能制作规范 v4.0》（要求「做新技能先打家族标 / 先查公共能力」），审核通过后落地。取证发现 v4.0 三处与磁盘不符：① §3.1 列 6 个「公共能力」，实测只有 3 个持 contract.json，且漏掉 2 个真引擎（dual-track-conformance / prd-prototype-diff，全库实为 5 个）；② §2.2 家族表覆盖不到 9/23 个在库技能（含本技能自己），测试家族 0 成员；③ §3.2 写「有 → 直接调用」，与外部硬约束「skill 不得显式引用其它 skill」正面冲突（见 references/external-standards.md §二）——按字面实施＝硬依赖，破坏独立交付。本轮落地：① 新增 references/domain-family-spec.md（v4.1 落版：7 个领域家族实扫全量覆盖 23；family 受控词表与 category 同值域；接回「引用式 + 四护栏」；8 个统一项挂守卫并标出 2 个真缺口）；② 立 C97 守卫——家族标须在受控词表内 且 == category（只校验词表会漏掉「family=product 而 category=design」这种自相矛盾，等于没立；未标定不报）；③ 本技能自身打 family: skill-engineering 作首个活样本；④ 识别出本库已有三个分组轴（category 能力域 23/23 · suite 链归属 7/23 · scene 组合包 1/23）⇒ 规范写明三方分工，防再造第四套。验证：回归 130/130 全过（新增 4 条 C97 正负成对）；guard_health.py 50 已验证 / 0 盲区（新增 4 例，2 正 2 反）；本技能 --strict 零 WARN。未做（如实登记）：存量技能 family 持有者仍 0/23，补标须分批；实测 requirement-communication / product-delivery-review 正在被其它会话修改，补标前必须先确认静止态。
- v1.6.18（2026-09-23）：立 C95/C96 闸结果自检守卫——并且把「声明了却从没人跑」的入口真的接上（MINOR） —— 起因①（真缺口）＝迭代收口时实测：emit_gate_result.py --selftest 被四处文档声明（gate-result-contract.md / machine-spec.md / operating-details.md / 脚手架 init_skill.py），却没有任何闸执行它（全库仅有 2 处引用，均为 C65 的注释）。这为什么危险：skill-evaluation-engine 的产出器恰恰把「空清单守卫」写在 --selftest 里（assert GATES, "空闸清单产出的 PASS 是假 PASS"）⇒ 断言惰性、永不生效——「报不出的守卫等于不存在」的活标本。起因②（自相矛盾）＝本技能闸结果声明 artifact.path = deliverable/skill-forge-v1.6.17.zip，而该文件不存在（C65 注释里点明「刻意不查存在性」）。原设计被实测推翻：本想立「声明的自检入口必须被某道闸执行」，两版探针分别误报 ≥4 例 / 2 例——漏 "cmd": [...] 列表形态、漏 os.path.join(_HERE, mod) 变量模块名、把 changelog/version-history 的历史记载当现行声明、把「例外形态 selftest 子命令」误当 --selftest；且 prototype-hifi-pipeline 的 audit_smoke.py 是运行期动态枚举所有带 --selftest 的脚本 ⇒ 静态判「未执行」必然出错。该判据不可靠，故不立（宁可少一条守卫，不留一条会误报的）。改为两条静态可证的新守卫：C95（WARN）＝产出器填写区体检——GATES 必须非空，且 cmd 里出现的 "xxx.py" 必须在本技能内真实存在；C96（WARN）＝闸结果 artifact 自称的版本（version 字段 + path 内嵌的 vX.Y.Z）必须 == frontmatter，占位形态自动跳过。C96 为何只判版本不判存在性：skill_ops.py package 明令 within(output, source) 即拒 ⇒ 交付包不可能落在技能树内；artifact.path 是工作区交付区相对路径，而检查器只拿得到 skill_dir ⇒ 真去查会退化成惰性判据（比不立更糟）。存在性由封包动作解决，不由守卫假装解决。同轮把入口真的接上：verify_scaffold.py 增跑脚手架产出技能的 scripts/emit_gate_result.py --selftest（assert rc==0）⇒ F1 由「从不被执行」变为「每轮脚手架回归都执行」。验证：① 回归 121 → 126 条（C95 两个子判据各 1 真缺陷样本 + 1 负样本；C96 1 真缺陷 + 1 占位负样本）；② guard_health.py 增 C95/C96 体检样本；③ 受控变异实验（真缺陷样本 + 负样本双向）；④ 全库探针实测触发面：C95b 命中 0 / 通过 9 / 不适用 12，C96 命中 0（4 例占位跳过、poe 已在位）。同轮修的声明漂移＝lessons-learned.md 散文里「配套新键 env.shell_path_first」——该键从未落地（全库无索引行、无正文条目），而 C69 只解析 **Pattern-Key**： 形态 ⇒ 散文级声明漂移结构上不可见（与本轮 F1 同族：声明了却没人核），故删掉失实声明而非凭空补一个空键。｜备份：_backup/skill-forge-v1.6.17-20260923-prec95.zip（486 618 B / 31 文件 / sha256 139b2e47…）
- v1.6.17（2026-09-23）：立 C94 家族索引键唯一性守卫——修掉 C69 的「取值写法掩盖缺陷」（MINOR） —— 起因＝给 page-dissection 做家族索引订正时实测：其索引表 design.pseudo_mode 登记了两行（表 24 行 / 去重 23 键），而 C69 全绿。根因＝取值写法：C69 取键写作 set(re.findall(...))，set() 把重复键折叠成唯一键 ⇒ 「表里重复、闸门全绿、无人能看见」——这是判据恒真的又一形态（与 v1.6.9 重写 C45 前那版「拿编号比组件清单 ⇒ 必有交集」同源：判据在真缺陷上恒不报警）。危害不止「多一行」：同键两行 ⇒ 同一 Rule 两个版本，读的人不知道以哪行为准。全库取证（10 张同类索引表）：2 张中招——page-dissection 的 design.pseudo_mode、visual-analysis-engine 的 contract.stale_declaration，两处均已修复。新守卫 C94（WARN）：取 C69 的同一段索引文本，但刻意用 list 而非 set 再看重复，报文同时给出「表行数 / 去重键数」两个口径并指名重复的键与次数。验证：① 回归 119 → 121 条（+「同键两行必报」与「多键各一行不得报」各 1 条）；② guard_health.py 增 2 个体检用例；③ 受控变异实验（真实对象）：把 page-dissection 的 lessons-learned.md 换回改动前带重复键的版本跑闸 ⇒ C94 报红；换回修好版 ⇒ 沉默并出 ✔ 证据行。为何是 WARN 而非 BLOCK：与 C69 同级（同一段索引的两种核查），且存量 2 例已修，不宜让历史包体积压阻断交付。同轮消掉的声明漂移：本文件「版本历史」段与 references/overview-guide.md 长期声称「本段只留最新一条」，而实际已保留 5 条全量摘要 ⇒ 声明改为「保留最近若干条（最新在前），不删历史」（对应家族键 process.declaration_drift 的做法：修声明、不删历史）。
- v1.6.16（2026-09-22）：立 C93 契约消费守卫——把「下游真去读契约」从约定变成门禁（MINOR） —— 起因＝用户要求「公共技能要各技能真实调用」，实测发现声明侧已管住、消费侧无人管：C89–C91 只审「引擎有没有把 contract.json 写对」，而 page-dissection / prototype-hifi-pipeline 的 probe_visual_engine.py 照样把 coreIntact 硬编码在自己脚本里（与 visual-analysis-engine/contract.json 的 probe.successField 重复）。危害形态：引擎日后改字段名，下游不会报「契约变了」，而是表现为「引擎不可用」——排查方向全错，是最贵的假阴性。判据（三条件同时成立才报，防触发面扩散）：① 有 scripts/probe_*.py；② 正文或索引声明了委托公共引擎（出现引擎名）；③ 该探针无读取动作（既无 contract.json 字面量、也无 def read_contract）或未取任何契约字段（successField/extraAssertions/fallbackHint/versionGate/contractVersion）。严重度定为 WARN 而非 BLOCK：契约消费是增强（缺失时探针仍能用硬编码值工作），BLOCK 只留给缺了就崩的形态（如 C88 假委托）。判据收紧过一次：首版只看「有没有 contract.json 字样」⇒ 注释里提一句就骗过，改为必须有读取动作。同步＝machine-spec.md §6 补登记（消 C45 报警）+ §3.4/§7 用例计数 116 → 119 + 回归套件新增 3 条（1 真缺陷样本 / 1 正样本 / 1 反向样本，回归 119/119 全过）+ guard_health.py 体检 37 → 40 已验证报出 / 0 盲区。
- v1.6.15（2026-09-22）：白名单同步修复——两张顶层白名单各补一格（PATCH） —— 起因＝产品智能体链路整体审计（只读）实测两条守卫要求相反：contract.json 被 C91 立为公共技能必填（缺即 BLOCK），C92 的 _STRAY_OK 已收录，唯独 C71 的 C71_ALLOWED_TOP 漏收 ⇒ 同一文件「必须有」与「报白名单外」并存、无解。① C71 补 contract.json：实测复现（加一个 contract.json 即得 C71 WARN）。② C92 补 deliverable：⚠ 与 C71 有意不一致，不是漏同步——C71 管静态结构合法性（_work/ 与 deliverable/ 都合法）、C92 管「交付前是否仍带过程物」；而 package_skill.py L85 无显式输出目录时默认就把 zip 打进 skill_dir/deliverable（官方工具主动创建该目录）⇒ C92 把它当残留报出是与工具链自身默认行为冲突，修法＝收录，不是要求移除。_work/ 仍报（过程区封包前应瘦身）。C92 提示文案同步改写（原文把两者并称「过程物」，已过时）。验证：受控对照实验（逐个加 contract.json / deliverable / _work 观察两闸反应）证明三项行为全部符合预期；回归 116 条全过；guard_health 37 已验证 / 0 盲区（无回归）；两公共引擎 --strict 由带 2 条 WARN 转为 rc=0；本技能自身 --strict rc=0。PATCH。｜备份：_backup/round8-whitelist-sync-20260922-1520/forge_check.py.bak（182 891 B · md5 c6748854… 与改前逐字节一致）
- v1.6.14（2026-09-22）：立 C88–C92 公共技能协同守卫——把「默认调用」与「独立交付」的矛盾交给机器看着（MINOR） —— 起因＝用户提出「之后会做很多公共技能，需要默认调用，但独立交付又会有问题」。取证：只读扫描 27 技能得 code 级硬依赖 0 条、data 3 条、delegation 8 条，但 contract.json 0/27、requires 声明 0/27 ⇒ 风险不在依赖形式，在依赖未登记、未被机器审。新守卫：C88 假委托（声明排他委托却找不到回落实现 → BLOCK，这是该矛盾的真正防线）· C89 公共引擎缺 contract.json · C90 contract 身份一致（name/version vs 本体）· C91 必填 9 字段 + 引用脚本真实存在 · C92 技能目录顶层过程物。同批实装：为 page-operation-engine / visual-analysis-engine 写 contract.json（前者判据 ok、后者 coreIntact —— 同名 check_env 字段不同，凭设计稿写必错）。验证：C88 正负成对（假委托报 / 条件委托不报）+ C92 正样本，共 3/3 有鉴别力；skill-forge 自身 --strict 零 BLOCK。教训：探针判据必须落在可执行位置，且须排除声明类区块（首版扫描器把 changelog 叙述当实现证据，4 条 code 边全假）。
- v1.6.13（2026-09-22）：C65 再扩身份判据——闸结果「不是本技能产出的」也须报（PATCH） —— 起因＝本工作区交付公共引擎 page-operation-engine v1.3.0 全链路时，我误用 skill-forge/scripts/emit_gate_result.py 给另外三个技能代产闸结果：该脚本 ROOT = dirname(HERE) 写死为自己目录、ARTIFACT_NAME/"skill" 也是字面量 skill-forge，而 --out 只改「写哪儿」不改身份 ⇒ 三个技能的 _gate_result.json 全被盖成 skill="skill-forge" / skillVersion="1.6.12"（而它们 frontmatter 是 0.7 系列 / 1.52 系列 / 1.23 系列），自相矛盾且无人能发现。为何 v1.6.12 的版本判据兜不住：它只比 skillVersion，一旦版本号偶然相同（或都读成 unknown）就完全查不出；身份错是独立缺陷类型，须独立判据。落地：① C65 新增身份判据——_gate_result.json 的 skill 须 == 技能目录名，不符即 WARN 并指出去向（「请用本技能自带的 scripts/emit_gate_result.py 重新产出」）；字段缺失不报（契约 §二 未列为必填，避免误伤极简闸结果）。② 判据落错误分支的最前（原顺序为 skillVersion 缺失 → 脱节 → 正样本），否则身份不符会被下游 elif 吞掉。③ 连带修两处「样本目录名随机」的测试基建：test_forge_check.py 的 _c65_warns() 与 guard_health.py 的 _run() 都用 tempfile.mkdtemp() 的随机名当技能目录名 ⇒ 新判据会让每个 C65 样本都先命中「身份不符」，把本该报的「版本脱节」挤掉，guard_health 因此把 C65 误报成盲区——两处改成可预期的 demo 子目录（guard_health 顺带把清理目标由 root 改为外层 outer）。教训（已登记 lessons L44，家族键 gate.author_per_skill）：跨技能调用工具前先读它的 ROOT / 身份常量定义——--out 存在 ≠ 该工具通用。验收：--strict rc=0 · 0 WARN / 0 BLOCK · 回归 113 → 116 条 · guard_health 28 → 29 已验证 / 0 盲区 · C45 计数同步 · 脚手架 PASS。PATCH。｜备份：_backup/skill-forge-v1.6.12-20260922-preverify.zip（454 072 B）
- v1.6.12（2026-09-21）：独立复核驱动修复——检查器只读化 + C71 形态穷尽 + C65 扩判据 + 补登记 C71-T（PATCH） —— 起因＝对本技能做独立复核（严格档：只给产物与验收标准、不给实施思路），10 项复核项得 5 PASS / 5 FAIL，其中 4 条落在检查器本体、1 条文档自相矛盾。① 检查器只读化（P2-1）：py_compile.compile() 默认把 .pyc 写进被检查技能的 scripts/__pycache__/（harness_runner.py 全库扫描＝批量写 25 个技能树）⇒ 改 cfile=<临时目录>/out.pyc；⚠ 复核方给的建议 cfile=os.devnull 在 Windows 实测抛 FileExistsError 且发生在编译之前，会被 except OSError 吞成「脚本编译异常」⇒ 语法检查整体失效——复核建议是假设不是结论。② C71 形态穷尽（P1-3 / P2-6）：残留正则补上同工具第四种暂存名 .{名}-<随机>.zip.tmp（skill_ops.py L864 mkstemp，同目录 / 同中断路径）并改大小写不敏感。③ C65 扩判据（P0，用户采纳）：闸结果不只是「文件在不在」——_gate_result.json 的 skillVersion 须 == frontmatter（连续两轮「交付物 / 闸结果停在旧版本」无人发现；C85 把包存在性委托给闸结果，而闸结果自身无人校验＝委托链断裂）；刻意不查 artifact.path 存在性（模板类技能写占位路径）。④ 补登记 C71-T（P1-2）：它早已实现、§3.6 也有描述，却不在「唯一权威源」GUARD_REGISTRY 与 §6（同类跨脚本守卫 C29 是登记了的）⇒ 注册表 44 → 45 条，并连带扩 C45 解析 §6 的正则（否则反手报「§6 漏登记」）。⑤ 文档事实同步：Phase 3 示例把报告写进目标技能 references/（照做触发 C43 WARN，而封包器强制 --strict ⇒ 照文档做等于关上自己的交付闸）→ 改 _work/；「7 脚本」→ 9 并补两行资源表；§6 缺严重度标注的行补齐。未修（如实登记）：C71-T 无回归用例、C45 不比重度、artifact.path 存在性、_backup/ 嵌套层残留（两个守卫的夹缝）。验收：--strict rc=0 · 0 WARN / 0 BLOCK · 回归 106 → 113 条 · guard_health 25 → 28 已验证 / 0 盲区 · 脚手架 PASS。PATCH。｜备份：_backup/skill-forge-v1.6.11-20260921.zip（32 文件 · 与改前盘逐字节一致）