dsh-project-based-learning 1.1.0

package/docs/DESIGN-AUDIT.md

@@ -0,0 +1,505 @@
+# 教学教练插件：弱点分析与改动审核（第 1–2 轮）
+
+对象：`通用AI项目制教学工作流.md`（379 行，14 节，下称"原文"）
+产物：可安装的 DSH 技能包 `coach/`（引擎 + Unity/C# 领域包 + 状态契约 + 校验器）
+本文性质：**改动前置审核记录**。任何对原文的改动都必须先通过下方六项检验，且必须经过第二轮反方复审；未通过者驳回或延后，不以"改进"名义直接下手。
+
+---
+
+## 0. 审核协议
+
+| 检验 | 内容 | 不通过的后果 |
+|---|---|---|
+| A 必要性 | 原文在该处是否真的失败？给出可复现的失败场景（必须引用行号） | 不成问题则为"过度设计"，直接驳回 |
+| B 最小性 | 是否存在更小的改动达到同样效果？ | 取最小可行方案，大改延后 |
+| C 反方论证 | 原文这样写保护了什么？改动会失去什么？（写出最强反方） | 反方更强则驳回改动 |
+| D 回归 | 是否与其它条款冲突？是否引入新失败模式（含权限、安全、错误归因）？ | 有冲突则需附缓解条款，否则驳回 |
+| E 可验证 | 改动后如何判定有效？（须是可观察信号，不能是"感觉更好"） | 不可验证则驳回 |
+| F 复审 | 隔一轮重读原文与裁定，检查是否被第一轮结论锚定；给出维持/翻案 | 翻案必须记录 |
+
+裁定枚举：**采纳 / 修改后采纳 / 驳回 / 延后**。
+
+**原则**：原文的默认状态是"保留"。改动必须自证必要，而不是新设计自证优越。
+
+---
+
+## 1. 弱点清单与逐条裁定
+
+### W01 前导漏斗过长
+
+- **位置**：§二（30–47）、§三（51–65）、§四（69–101）、§五（105–133）、§六（143–163）叠加 §十二"每轮问题尽量不超过 3 个"（345）。
+- **失败场景**：用户说"我想做一个 2D 平台跳跃原型"。教练按 §一→§六 顺序推进，每轮至多 3 问，用户需 6–10 轮才拿到第一张任务卡，期间零产出。
+- **候选**：R1 把 §二/§三 合并为一次结构化 intake，诊断压缩为 3 题；R2 设"新手快通道"，直接跳过诊断。
+- **A**：成立。信息量与轮次上限的乘积决定了漏斗长度，这是结构性摩擦，不是执行偏差。
+- **B**：R1 更小；R2 改动更大。
+- **C**：强反方——诊断是证据链的根基（§四 97–101 三态标记；§八 262"只有能解释、修改并验证后，才能作为个人能力证据"）。跳过诊断则基线全为"待验证"，起点只能取信自述，证据链从第一步断裂。**这是全文最不能动的机制。**
+- **D**：R1 无冲突。R2 与 §四、§八 直接冲突。
+- **E**：intake 到首张任务卡的消息轮数 ≤ 2，且仍覆盖"理解预测 + 问题定位 + 小型实现"三类。
+- **F 复审**：维持。压缩**提问方式**，不压缩**证据覆盖**。
+- **裁定**：**修改后采纳 R1；驳回 R2。**
+
+### W02 提示词体积与注意力稀释
+
+- **位置**：全文 379 行；分散规则如 §七.3（203–213）、§十二（347）。
+- **失败场景**：长会话中模型漏掉"不要跳到第 5 级提示""不重复完整路线"，且没有任何机制能发现漏了。
+- **候选**：R1 拆分加载（常驻引擎 + 按需 references）；R2 关键规则改为结构化校验。
+- **A**：成立，但部分原因是常驻规则数量本身过大。
+- **B**：R1 最小（不改内容，只改加载方式）。
+- **C**：反方——拆分后模型可能"忘记读"参考文件。缓解：SKILL.md 必须给出**指令 → 必读文件**的强制映射表。
+- **D**：无冲突。R2 依赖宿主插件（cordis），超出当前工作区可行范围。
+- **E**：常驻体积从 379 行降到约 150 行；级别参数化后可由校验器检查。
+- **F 复审**：维持。
+- **裁定**：**采纳 R1；R2 延后至宿主插件阶段。**
+
+### W03 能力画像的虚假精确
+
+- **位置**：§五（117–141）；张力源自 §三 67"自述不能当作已验证的能力证明"与 §五 118 仍要求给 1–5 分。
+- **失败场景**：无任何证据时给出"实际应用 3 分"，教练与用户都当真；7×6 表格跨轮重写的 token 成本高。
+- **候选**：R1 无证据维度等级封顶且必须标"待验证"，证据列必填引用；R2 删除 1–5 等级。
+- **A**：成立（张力客观存在）。
+- **B**：R1 最小。R2 破坏沟通效率。
+- **C**：反方——等级是教练与用户的共同语言，删除后无法表达差距与进步幅度。R1 保留等级。
+- **D**：与 §四三态标记一致。
+- **E**：可机械校验——`status=已验证 ⇒ evidence 非空且 level≥3`；无 evidence ⇒ `level≤2` 且 `status=待验证`。
+- **F 复审**：维持。
+- **裁定**：**修改后采纳 R1；驳回 R2。**
+
+### W04 三份状态文档无单一事实源
+
+- **位置**：§五基线（107–133）、§六路线（149–161）、§十档案（297–308）。
+- **失败场景**：长会话中基线写"阶段 2"、档案写"阶段 3"；§十 318–323 只规定证据权重，未规定文档间合并规则。
+- **候选**：R1 三合一为单一状态源 + 生成式人类视图；R2 保留三份并声明"以档案为准"。
+- **A**：成立。
+- **B**：R1 略大但消除根因；R2 只是把冲突规则化。
+- **C**：反方——合并后单文件变大，模型每轮重写全文易截断。缓解：状态源用 JSON（机器校验、字段级更新），人类视图为**生成物**。
+- **D**：与 §十 308"只保存结论和证据摘要"一致。
+- **E**：校验器强制 `current.stage` 必须存在于 `route`；`PROGRESS.md` 标注"生成物，勿手工编辑"。
+- **F 复审**：维持。
+- **裁定**：**采纳 R1。**
+
+### W05 持久化不可靠与降级方案摩擦
+
+- **位置**：§十（297–325）。
+- **失败场景**：AI 声称"已保存学习档案"但未写盘；新会话全部丢失。原降级方案要求用户手工复制粘贴（325）。
+- **候选**：R1 写入工作区真实文件（DSH 原生能力）；R2 保留可复制摘要。
+- **A**：成立（这是纯执行层缺陷，原文受产品能力限制）。
+- **B**：R1 即最小。
+- **C**：反方——文件形态对用户不够直观。缓解：生成 `PROGRESS.md` 视图，摘要导出仍保留。
+- **D**：需遵守工作区沙箱边界（见 W10）。
+- **E**：文件存在 + 校验通过 + 新会话可读。
+- **F 复审**：维持。
+- **裁定**：**采纳 R1；R2 降为导出选项保留。**
+
+### W06 重认知轻动机
+
+- **位置**：§九（264–293）全部为认知分支；§十二 350"鼓励应基于具体进展"。
+- **候选**：R1 增加动机/情绪干预流程；R2 增加进度计数与打卡；R3 仅在受阻分类中增加"时间/动力不足"分支。
+- **A**：部分成立。原文确无动力分支，但"不想学"多由任务跨度过大（§九已有"任务跨度过大"）或时间不足引起，属结构问题。
+- **B**：R3 最小。
+- **C**：强反方——教练没有可靠手段处理情绪问题；以"鼓励"回应情绪困扰可能造成伤害；引入不可验证的"情绪评估"与全文证据驱动原则冲突。
+- **D**：R1/R2 引入不可验证信号，回归风险高。
+- **E**：R3 可观察（受阻分类新增分支，措施均为原文已有手段）。
+- **F 复审**：**翻案记录。** 第一轮倾向 R1（作者上一轮曾建议增加动机管理）。第二轮重读 §九后认为：证据不足、越界、与证据驱动原则冲突，改判 R3。这是本次审核中唯一被推翻的自身结论。
+- **裁定**：**驳回 R1、R2；微采纳 R3。**
+
+### W07 学习科学元素单薄
+
+- **位置**：全文仅 §十三"复盘"（362）涉及回顾。
+- **候选**：R1 引入间隔复习子系统；R2 在阶段验收中并入一次限时检索式复述；R3 不改。
+- **A**：部分成立（检索练习有实证支持；原文无任何回顾机制）。
+- **B**：R2 最小——并入既有验收环节，不新增环节。
+- **C**：反方——新增动作与 W01 的压缩方向相反。缓解：限时 5 分钟、无提示复述机制与取舍，作为验收的一部分而非新步骤。
+- **D**：与 §八验收一致。
+- **E**：验收记录新增 `retrievalRecap` 字段，可为空但非空时才允许"通过"。
+- **F 复审**：维持。
+- **裁定**：**修改后采纳 R2；驳回 R1。**
+
+### W08 "充分证据"未定义
+
+- **位置**：§八（255–258）。
+- **失败场景**：教练可为讨好用户宽松通过，也可过度严格拖慢进度，两种偏差都无判据可纠。
+- **候选**：R1 把 262 行的原则上升为验收定义：证据充分 = **可复现 + 可解释 + 可修改**（三条同时满足）；R2 引入评分量表。
+- **A**：成立。
+- **B**：R1 是显式化已有原则，改动极小。
+- **C**：反方——R1 可能与"有条件通过"重叠。缓解：三条缺一即"有条件通过"；核心目标未达成才"未通过"。
+- **D**：与 §八三档结论一致。
+- **E**：校验器强制结论枚举与 `retrievalRecap` 规则。
+- **F 复审**：维持。R2 无实证依据，且量表会诱发新的虚假精确（同 W03）。
+- **裁定**：**采纳 R1；驳回 R2。**
+
+### W09 无示例锚定
+
+- **位置**：§五/§六仅给模板（107–133、149–161）。
+- **候选**：R1 引擎内置完整示例；R2 示例下沉到领域包。
+- **A**：成立但影响中等（模板已可执行）。
+- **B**：R2 更小且不占常驻体积。
+- **C**：反方——引擎内置示例会与学科耦合，违反分层目标。
+- **D**：与"引擎/领域分离"的分层设计一致。
+- **E**：领域包必须含 `example.md`，由校验器强制该文件存在。
+- **F 复审**：维持。
+- **裁定**：**采纳 R2。**
+
+### W10 权限粒度与授权延续未定义
+
+- **位置**：§十一（327–339）。
+- **失败场景**：审阅代码、读日志、跑测试是高频动作；原文只规定"操作前说明"，未定义授权有效期，实践中要么反复打扰用户，要么一次授权被无限扩大。
+- **候选**：R1 授权记录表（对象 + 操作类型 + 时间）：同一对象的**只读**操作一次授权后可延续，写操作每次重新确认；R2 保持原样。
+- **A**：成立。
+- **B**：R1 最小且不放松任何安全边界。
+- **C**：反方——授权记录可能被误读为"永久许可"。缓解：记录仅用于**减少重复询问**，写操作一律重新确认，最终强制层是 DSH 沙箱，不是教练规则。
+- **D**：安全上必须保守：不因记录而扩大范围。
+- **E**：授权写入状态文件，复盘时可审阅。
+- **F 复审**：维持，并加固约束。
+- **裁定**：**修改后采纳 R1（附安全约束条款）。**
+
+### W11 诊断最小覆盖在部分领域生硬
+
+- **位置**：§四（83–87）。
+- **候选**：R1 允许等价替代（设计类项目用方案评审替代小型实现），保留三类覆盖的精神；R2 保持硬性三类。
+- **A**：对 Unity/C# 不构成问题（编译、定位、实现三类都自然）。
+- **B**：当前无收益。
+- **C**：反方——放宽会削弱证据一致性。
+- **E**：无法在当前领域验证收益。
+- **F 复审**：维持延后。仅在领域包契约中保留"等价替代"字段，不写入引擎强制逻辑。
+- **裁定**：**延后。**
+
+### W12 审阅幻觉无护栏
+
+- **位置**：§八（236–252）。
+- **失败场景**：五要素格式（位置、机制、影响、修复方向、验证方式）会让模型虚构的问题显得同样可信。
+- **候选**：R1 审阅必须引用可核对材料（文件路径/行号/日志片段/截图位置），并区分"已核对事实"与"未核对推测"；无法核对的结论降级为提问。
+- **A**：成立。
+- **B**：R1 即最小。
+- **C**：反方——要求行号会增加成本，截图类证据无法给行号。缓解：允许位置描述，但必须声明证据类型与核对状态。
+- **D**：与 §七.5 证据类型一致。
+- **E**：审阅报告模板新增 `依据` 与 `核对状态` 两列。
+- **F 复审**：维持。
+- **裁定**：**采纳 R1。**
+
+### W13 每轮 ≤3 问与信息收集量的冲突
+
+- **位置**：§二 30、§十二 345 与 §三（需收集约 8 项）。
+- **候选**：R1 区分"开放式追问 ≤3"与"结构化清单可一次呈现多项并允许标'未知'"；R2 放宽到 ≤5 问。
+- **A**：成立。
+- **B**：R1 不放松原有约束。
+- **C**：反方——清单化可能让 intake 变成审讯。缓解：只列必要项，允许"未知/稍后"，且清单不计入追问配额。
+- **D**：与 §十二一致。
+- **E**：intake 只发一轮清单即可进入诊断（同 W01 的验证信号）。
+- **F 复审**：维持。R2 会削弱防审讯约束。
+- **裁定**：**修改后采纳 R1；驳回 R2。**
+
+### W14 `直接答案` 可系统性绕过脚手架
+
+- **位置**：§七.2（193）、§十二（349）、§十三（364）。
+- **候选**：R1 记录并标记"未通过脚手架"；R2 增加额外的理解验证动作。
+- **A**：部分成立。
+- **B**：R2 与原文重复——349 行已要求"仍应解释关键取舍，并以少量问题验证理解"。
+- **C**：反方——重复建设。
+- **E**：状态文件保留 `directAnswers` 计数，复盘时提示即可。
+- **F 复审**：维持。
+- **裁定**：**微采纳（仅记录，不新增教学动作）；驳回 R2。**
+
+### W15 无自检机制
+
+- **位置**：全文。
+- **候选**：R1 机械校验器（JSON Schema + 不变量）；R2 提示词内自检清单（模型自述）。
+- **A**：成立（弱模型必然漂移）。
+- **B**：R1 可在工作区内实现，无需宿主插件。
+- **C**：反方——校验器只能检查状态文件，无法检查对话质量（例如是否真的只给了 3 级提示）。**这是能力边界，必须在文档中如实声明，不能宣称"已强制"。**
+- **D**：无冲突。
+- **E**：校验器给出 PASS/FAIL 与逐条问题。
+- **F 复审**：维持。R2 无强制力。
+- **裁定**：**采纳 R1（并声明边界）；驳回 R2。**
+
+### W16 任务时长 30–90 分钟写死
+
+- **位置**：§七.1（189）。
+- **候选**：R1 由领域包提供 `taskMinutes` 默认区间，用户可覆盖；R2 保持写死。
+- **A**：轻微成立（领域与用户差异明显，且 Unity 编译等待时间不可忽略）。
+- **B**：R1 极小（读一个字段）。
+- **C**：反方——放宽可能纵容超长任务。缓解：领域包给出区间上限，超限必须拆分。
+- **E**：状态文件 `estimateMin` 与领域包 `taskMinutes` 区间比对——**已实现为提醒（warn）**：超过上限时提示"必须拆分"（第 3 轮据复核结论补实现，见 6.2 D9）。
+- **F 复审**：维持。
+- **裁定**：**采纳 R1。**
+
+### W17 缺少轻量请求通道
+
+- **位置**：§一意图分类（18–32）与全文默认教练姿态。
+- **失败场景**：用户只想快速问一个报错，却被拉入 intake→诊断→基线→路线全流程（与 W01 同源）。
+- **候选**：R1 新增"快速问答"意图：只回答并记入 `open`/`evidence` 摘要，不建基线、不改路线，用户可随时升级为教学模式；R2 不改。
+- **A**：成立，且与 W01 互为补充。
+- **B**：R1 是 §一已有意图分类的自然延伸。
+- **C**：反方——可能被滥用为逃避流程。缓解：快速问答不计入能力证据（与 §八 262 一致），不影响基线判定。
+- **D**：与 §八、§十三一致。
+- **E**：可观察（快速问答不产生 `route` 变更）。
+- **F 复审**：维持。
+- **裁定**：**采纳 R1。**
+
+### W18 "用户必须亲自完成的部分"无执行机制
+
+- **位置**：§六 156（字段存在），§八未要求核对。
+- **候选**：R1 验收时逐项核对 `userOnly` 清单，未完成不得判"通过"；校验器强制该字段非空；R2 不改。
+- **A**：成立（字段无配套校验即形同虚设，与 §八 262"AI 帮助生成的成果需能解释修改验证"是同一意图）。
+- **B**：R1 即最小。
+- **C**：反方——可能拖慢进度。缓解：清单应小而具体，与验收标准同源。
+- **E**：校验器强制 `route[].userOnly` 非空（机械可查）；"逐项核对是否亲手完成"属验收模板与人工判断，**不可机械校验**（第 3 轮据复核结论修正了原先的过度声明）。
+- **F 复审**：维持。
+- **裁定**：**采纳 R1。**
+
+### W19（新增使用约束）默认用户已有明确目标
+
+- **来源**：本次使用要求，非原文缺陷。
+- **候选**：R1 引擎提供 `assumeGoal` 配置（默认 `false`）：开启后跳过目标询问，但首次任务时用一行确认并写入状态；R2 直接删除 §二/§十四 的目标询问规则。
+- **A**：约束成立。
+- **B**：R1 最小且可回退。
+- **C**：强反方——目标不落盘会导致 MVP 收敛与验收标准失去来源（§二 6 项是后续全部判据的出处）。**因此不能删除规则，只能改变默认交互成本。**
+- **D**：若直接删除，§五基线、§六阶段验收标准、§八验收三档同时失去判据。
+- **E**：`assumeGoal=true` 时首轮不追问目标，但 `state.goal` 必须在首个任务卡前补齐且校验通过。
+- **F 复审**：维持。
+- **裁定**：**修改后采纳 R1（本工作区默认启用）；驳回 R2。**
+
+---
+
+## 2. 驳回与延后清单（防止"改进"名义下的功能膨胀）
+
+| 编号 | 被驳回/延后的改动 | 理由 |
+|---|---|---|
+| R2-W01 | 跳过诊断的新手快通道 | 断裂证据链，与 §四、§八 冲突 |
+| R2-W03 | 删除 1–5 等级 | 破坏教练与用户的共同语言 |
+| R1/R2-W06 | 动机/情绪干预、打卡与进度计数 | 缺乏可靠手段、越界、与证据驱动冲突 |
+| R1-W07 | 间隔复习子系统 | 过度设计，收益可在验收环节以极小成本取得 |
+| R2-W08 | 验收评分量表 | 无实证依据，且制造新的虚假精确 |
+| R2-W13 | 开放式追问放宽至 5 问 | 削弱防审讯约束 |
+| R2-W15 | 提示词内自检清单 | 无强制力 |
+| W11 | 诊断覆盖等价替代的引擎级放宽 | 当前领域不构成问题 |
+| R2-W02 | 宿主级 `coach_*` 工具族（cordis 插件） | 超出工作区可行范围，列为第二阶段 |
+
+---
+
+## 3. 冻结的设计约束（构建必须满足）
+
+- **C1** 引擎与领域内容分离；引擎不含任何 Unity/C# 词条。
+- **C2** 单一状态源，人类视图为生成物。
+- **C3** 常驻引擎 ≤ 约 150 行，其余按需加载；SKILL.md 给出"指令 → 必读文件"映射。
+- **C4** 状态契约含：目标、能力画像（三态 + 证据强制）、策略、路线（含 `userOnly`）、当前任务、证据、待解决项、路线变更、直接答案记录、授权记录。
+- **C5** 校验器机械执行 §四/§五/§八/§六 的关键不变量，并如实声明其覆盖边界。
+- **C6** 验收三档 + 证据充分性三条件 + 检索式复述字段。
+- **C7** 审阅五要素 + 依据 + 核对状态（事实/推测）。
+- **C8** 权限：默认只读、动手前声明、只读可延续、写操作每次确认、沙箱为最终强制层。
+- **C9** `assumeGoal` 可配置，默认本工作区开启，但目标必须落盘。
+- **C10** 交付路径：工作区 `.dsh/skills/` 可直接被发现（免重启），另附市场/包形态以便分发。
+
+---
+
+## 4. 覆盖矩阵（原 14 节逐条落地，防止条款丢失）
+
+| 原文 | 新位置 | 备注 |
+|---|---|---|
+| §一 判断意图（20–32） | `SKILL.md` 入口 + `engine/intake.md` | 新增"快速问答"（W17）；"意图清楚时不重复询问"第 3 轮补入（见 6.2 D11） |
+| §二 确认项目目标（34–47） | `engine/intake.md` | `assumeGoal` 只改变交互成本（W19） |
+| §三 收集已有经验（49–67） | `engine/intake.md` | 清单化，允许标"未知"（W13） |
+| §四 针对性诊断（69–101） | `engine/diagnosis.md` + 领域包 `diagnosis-bank.md` | 三类最小覆盖保留（W01/W11） |
+| §五 学习基线（103–141） | `engine/state.md`（含 1–5 等级定义）+ 校验器不变量 | 等级与证据绑定（W03/W04）；1–5 等级口径第 3 轮补入（见 6.2 D10） |
+| §六 阶段路线（143–173） | `engine/route.md` | `userOnly` 强制（W18） |
+| §七 单次学习任务（175–234） | `engine/task-loop.md` | 时长来自领域包（W16） |
+| §八 审阅与验收（236–262） | `engine/review-acceptance.md` | 证据充分性定义 + 复述（W07/W08/W12） |
+| §九 动态调整（264–293） | `engine/adapt.md` | 新增时间/动力分支（W06） |
+| §十 持久化（295–325） | `engine/state.md` + `scripts/` | 真实文件 + 校验（W04/W05）；"已完成任务"字段与"只存结论与摘要"约束第 3 轮补入（见 6.2 D11） |
+| §十一 权限边界（327–339） | `engine/permissions.md` | 授权记录（W10） |
+| §十二 沟通与上下文（341–350） | `SKILL.md` 输出纪律 | 追问与清单区分（W13） |
+| §十三 可识别指令（352–366） | `SKILL.md` 指令表 | 全部保留并映射到必读文件 |
+| §十四 首次回复规则（368–375） | `SKILL.md` 首次交互 | 受 `assumeGoal` 影响但不删除 |
+
+**结论：原文无条款被删除。** 全部改动属于"加载方式、状态载体、机械校验、边界显式化"四类，教学法内核（先做后教、分级提示、证据判定、动态调整）未改。
+
+---
+
+## 5. 残余风险与已知边界（如实声明）
+
+1. **校验器只覆盖状态层与领域包结构。** 它能强制"无证据不得标已验证""阻塞项未清不得通过"，但不能验证对话中是否真的只给了 3 级提示、是否给了完整答案。提示级别体现在任务卡的提示记录表与对话中，状态层不强制记录（第 3 轮据复核结论修正了原先提到的 `hintLevel` 字段——该字段并不存在）。
+2. **引擎仍依赖模型遵守 SKILL.md。** 机械校验降低了漂移的后果，但未消除漂移。
+3. **领域包内容需实测。** Unity 命令行参数依赖官方文档核对，标注"（未验证）"的条目在真实环境中必须实测后才可用于验收。
+4. **技能加载验证条件。** 工作区 `.dsh/skills` 属 DSH 的 `project-dsh` 根，按官方说明可免重启被发现；但若本机会话未刷新目录，需要重启宿主或新会话。
+5. **原文未覆盖的领域**：多人协作教学、学员之间的比较、证书/学分之类的外部认定，均不在本设计范围。
+
+---
+
+## 6. 第 3 轮：构建后复核
+
+前两轮审核的是**设计**；本轮审核的是**已建成的东西**——它是否真的按设计工作，以及设计声明是否与实现一致。
+
+### 6.1 复核手段与实测结果（均可复现）
+
+| 手段 | 命令 / 产物 | 实测结果 |
+|---|---|---|
+| 校验器回归自测 | `node coach/skills/dsh-coach/scripts/coach-selftest.mjs` | **PASS 6 ｜ SKIP 0 ｜ FAIL 0**（退出码 0） |
+| 正向夹具（真实领域包） | `coach-validate.mjs --state coach/examples/state.demo.json --render` | **PASS**，生成 `PROGRESS.demo.md`（68 行） |
+| 反向夹具 | `--state coach/examples/state.selftest-invalid.json` | **23 条 error**，命中 ST02/03/04/05/06/07/09/10/11/12 与 ST-TYPE（第 3 轮加固后由 21 条增至 23 条） |
+| 端到端建档流程 | 复制 `assets/state.template.json` → 校验 → 填目标与首阶段 → 校验并渲染 | 模板态 **FAIL**（ST11×3 目标未落盘 + ST08 阶段不在 route，退出码 1）；填完后 **PASS**（退出码 0，仅 4 条"限制未填写"提醒）。模板**刻意不通过**，以强制写入真实目标——这是 W19 的落地方式 |
+| 分层反例（自动化） | 自测第 4 项：副本注入 3 个硬令牌 | 副本 **3 条 LY01**，原目录 **0 条**（第 3 轮起 `assets/*.md` 也纳入扫描，扫描面由 10 个文件增至 13 个） |
+| BOM 鲁棒性 | 带 BOM 的状态文件 + 清单 | 修复前解析失败；修复后 **PASS** |
+| 安装器守卫 | `coach-install.mjs` 四种情形 | 复制安装 24 文件（0）；重复安装拒绝（1）；`--force` 成功（0）；目标落在源内 / 在副本内运行均中止（2） |
+| 领域包契约符合性 | 我逐文件独立核对（非依赖生成方自述） | 7 文件全部符合契约；`manifest.yml` 8 键完全一致。计数：原型 6、诊断题 14（理解预测 4 / 问题定位 6 / 小型实现 4，三类最小覆盖齐备）、陷阱 19 条分 9 组、核对配方 5 条覆盖 (a)(b)(c)(d)、术语约 86 条 |
+| 领域包生成方的额外实测 | 其报告中的可复现结论 | `dotnet new console` 在受限环境失败（模板引擎写用户目录被拒）→ 改用**手写 SDK 风格 csproj + `netstandard2.1`**，成功/失败两条路径均实测（`CS1002` 行号定位、exit 1）；裸 `csc.dll` 不带 `/reference:` 必报 `CS0518`，已写明为配方边界；Unity 6 中 `Object.FindObjectOfType` 已过时，替代为 `FindFirstObjectByType`/`FindAnyObjectByType` |
+| 独立对抗性复核 | 外部代理，不共享本会话推理，任务含覆盖矩阵核对、不变量真伪实测、分层反例、规则一致性、可用性缺口 | 见 6.3 |
+
+### 6.2 第 3 轮发现的真实缺陷与处置
+
+| 编号 | 缺陷 | 证据 | 处置 |
+|---|---|---|---|
+| D1 | **BOM 会让状态文件与领域清单解析失败**：`JSON.parse` 遇 BOM 直接抛错；迷你 YAML 解析器把首个键读成 `\uFEFFid`，报"缺少必需键 id" | Windows 编辑器常写 BOM；用带 BOM 夹具复现 | 新增 `readText()` 统一去 BOM，覆盖状态、`manifest.yml`、`manifest.json` 三处读取点；BOM 夹具实测 PASS |
+| D2 | **覆盖矩阵虚报**：原文 §十二 的"术语首次出现附原文"与"日志和代码只要求相关片段"两条**在新结构中并未落地**，但矩阵声称已覆盖 | 自查逐条对照 §十二 后发现 | 补入 `SKILL.md` R6；这是审核流程要抓的典型问题——**声称覆盖 ≠ 实际覆盖** |
+| D3 | **按需加载被体积破坏**：诊断题库 53 KB / 837 行，其"最小覆盖索引"位于文件**末尾**，模型无法先看到索引再决定读哪段 | 文件行号与结构核对 | 题库头部加入读取指引（先读末尾索引定题号 → 按题号定位）；`references/engine/diagnosis.md` 加入学科无关的通用规则"大文件先读索引，一次只读 2–4 道题" |
+| D4 | `--help` 输出包含 shebang 行 | 直接执行 `--help` | 已修（去 shebang 再输出） |
+| D5 | **流程教训（非代码缺陷）**：PowerShell 控制台把 UTF-8 内容显示为乱码，一度疑似文件编码损坏 | 用 read 工具复核磁盘内容，确认为终端解码问题、文件正确 | 记录规则：**不以控制台渲染判断文件编码**，以读取工具或字节级检查为准 |
+| D6 | **疑似出现第二份领域包内容**：领域包生成方报告 `.dsh/skills/...` 下存在同内容文件，并以 `fsutil` 判定该处"非重解析点"，据此怀疑工作区有同步机制复制了一份 | 直接查询链接**本体** `.dsh/skills/dsh-coach`：`Attributes=Directory,ReparsePoint`、`LinkType=Junction`、`Target=coach\skills\dsh-coach`；抽查 3 个文件哈希完全一致 | **澄清，非缺陷**：这是安装脚本 `--link` 建立的目录联接，源与镜像本就是同一份文件。生成方查的是父目录 `.dsh/skills`（该层确实不是重解析点），故结论偏差。**教训：判定符号链接/联接要查链接本体，不是父目录。** |
+| D7 | **分层规则被自己的说明文字触发**：为说明黑名单边界，在 `references/engine/state.md` 的说明里举出了具体禁用词例，使引擎文件自身命中 LY01 | 自测第 4 项断言"原目录必须 0 条 LY01"**立即失败** | 改写为不举具体词例（改指向脚本中的 `DOMAIN_TOKENS`）。**反向价值：这证明分层检查确实有拦截力，且回归自测能抓到自己引入的违规。** |
+| D8 | **【阻塞】"已验证"只查引用 id 存在，不查被引用证据的强度**：把某维度标为"已验证"、却引用一条强度为"待验证"的证据，照样 PASS；`artifact` 写占位符 `-` 也照样通过 | 复核者用探针实测 `ok: true`；我复现同上 | 已修：建立 id→strength 映射，`已验证` 要求被引用证据中至少一条强度为"已验证"；`部分验证` 不得引用全为"待验证"的证据；`artifact` 增加占位符黑名单。复测：降级 E2 强度 → 报 ST03；artifact 改 `-` → 报 ST06 |
+| D9 | **审核文档三处过度声明**：W16 的"`estimateMin` 与领域包区间比对"未实现；矩阵引用的 `schemas/state.schema.json` 不存在；残余风险提到的 `hintLevel` 字段不存在 | 复核者 grep + 实测 `estimateMin=600`（域 `[30,90]`）仍 PASS | 已修：`estimateMin` 超上限改为 **warn（ST-W6）**；矩阵与残余风险改为指向校验器与任务卡提示记录表（不存在的字段与文件已删除引用） |
+| D10 | **覆盖矩阵虚报**：声称覆盖"§五 学习基线（103–141）"，但原文 135–141 的 **1–5 等级定义**在全包 0 命中 | 复核者 grep 原文措辞，命中 0 | 已修：把 1–5 等级定义补入 `references/engine/state.md`（学科无关），矩阵保留 103–141 的声明 |
+| D11 | **三条原文条款未落地**：§一 32"意图清楚不重复询问"、§十 302"已完成任务"（档案项）、§十 308"不保存大段代码/完整日志" | 复核者 grep 0 命中 | 已修：SKILL.md 启用判定补"不重复询问已知信息"；状态新增 `completedTasks` 字段（模板/示例/校验/渲染同步）；证据与摘要超长（>500／>200 字符）改为 warn（ST-W5） |
+| D12 | **模板→校验死锁**：`route: []` 时任何 `current.stage` 都报 ST08，而 SKILL 要求"校验失败必须先修状态"，导致刚建骨架的新生无法进入正轨 | 复核者实测"模板+已填 goal"唯一 error 即 ST08 | 已修：route 为空时 ST08 降为提醒（ST-W4，intake 阶段正常）；但**任务一旦开工而 route 仍为空则报错**。复测：新生仅填目标 → PASS + 1 条 ST-W4 |
+| D13 | **权限条款互斥**：`permissions.md`"任何写操作每次重新确认"与"每次可验收动作后更新状态"字面冲突，未界定 `.coach/` 是否算"写操作" | 复核者对照两文件行号 | 已修：权限表新增一行——教练自有状态与笔记（`.coach/`、技能 `assets/`）的写入不需逐次确认；用户项目文件的写/运行/测试仍逐次确认 |
+| D14 | **分层检查范围与匹配都有问题**：不含 `assets/*.md`（模板也是提示词）；子串匹配会假阳性（普通英文词因含学科词根被误报）；全角字符可绕过；README/C1 却称"不含任何学科词条" | 复核者注入 `assets/task-card.md` 0 命中；普通英文词被误报 | 已修：范围并入 `assets/*.md`（`scripts/` 明确排除，因其含黑名单本身）；匹配改为 **NFKC 归一化 + 整词边界**，一行可报多个令牌；README 与审核文档改为"硬令牌黑名单 + 人工审查"的准确表述。**修复过程中再次自命中一次**（在 state.md 的说明里举出词例）——说明"举词例"这个动作本身就会触发本条，最终改为不举词例 |
+| D15 | **异常与边界路径**：状态为 `null` 时静默 PASS（13 条不变量一条未跑）；`route[0].n` 起点未校验；时间校验实为宽泛 `Date.parse`；`--out` 指向目录时外泄原始堆栈；视图头部硬编码状态路径 | 复核者逐项实测 | 已修：根对象类型断言（ST00）；`route[0].n` 必须为 1；改为严格 ISO 正则；`--out` 为目录时给出 ST-W3 提示（实测无堆栈）；视图头部改用实际状态路径 |
+| D16 | **领域包两个小节的耦合**：`example.md`／`glossary.md` 无任何指令入口（W09"示例锚定"无处落地），却按 DP06 硬失败并阻止 `--render` | 复核者核对映射表与 DP06 逻辑 | 已修：指令映射表补一行"用户要求看样例 / 需要术语口径 → 领域包 `example`、`glossary`" |
+
+### 6.3 我方独立逐条核对（不依赖外部代理）
+
+原文 14 节 → 落地位置 → 核对结论（逐条重读原文后确认，非按记忆填写）：
+
+| 原文条款 | 落地位置 | 结论 |
+|---|---|---|
+| §一 意图判断（20–32） | `SKILL.md` 启用判定 + 指令表 | ✓ 7 类意图均可承接；歧义时先确认意图 |
+| §二 目标 6 项（38–45） | `intake.md` 结构化清单 | ✓ 6/6；完成判据必须可观察 |
+| §三 五级自述 + 5 项（51–65） | `intake.md` 12 项清单 | ✓ 全部保留；自述一律初始"待验证" |
+| §四 三类最小覆盖（83–87） | `diagnosis.md` + 领域包索引 | ✓ 领域包题量分布 4/6/4 支持三类齐备 |
+| §四 三态标记（97–101） | `state.md` + 校验器 ST03/ST04 | ✓ **机械强制**（无证据不得标已验证） |
+| §五 基线格式（107–133） | `state.json` + `PROGRESS.md` 渲染 | ✓ 7 维 + 教学策略 4 字段 |
+| §五 等级 1–5（135–141） | schema + 领域包等级锚点 | ✓ 每维度锚点由领域包给出 |
+| §六 阶段 10 字段（149–161） | `route.md` + schema | ✓ 10/10 |
+| §六 只详展当前与下一阶段（163） | `route.md` 展开粒度 | ✓ |
+| §六 调整触发（165–173） | `route.md` | ✓ 7 条 + 补第 8 条（验收未通过/有未清阻塞项） |
+| §七 五步循环（175–234） | `task-loop.md` | ✓ + 任务卡模板 |
+| §七 五级提示（203–213） | `task-loop.md` + R2 | ✓ 含"未经请求不得跳到第 5 级" |
+| §七 8 类证据（225–234） | `task-loop.md` | ✓ 8/8 |
+| §八 三级问题分类（238–242） | `review-acceptance.md` + 模板 | ✓ |
+| §八 五要素反馈（244–252） | 同左 + 依据/核对状态两列 | ✓ 5 要素 + 2 项防幻觉补充 |
+| §八 三档结论（254–258） | 同左 + 充分性三条件 | ✓ |
+| §八 禁止"明白了吗"（260） | 同左 | ✓ 要求预测/复现/解释 |
+| §八 AI 成果需能解释修改验证（262） | R4 + 验收第 4 步 | ✓ 上升为常驻规则 |
+| §九 受阻 7 类（266–275） | `adapt.md` | ✓ 7 + 1（时间/动力不足） |
+| §九 加难 7 项（286–293） | `adapt.md` | ✓ 7/7 |
+| §十 档案 4 项（299–306） | `state.json` 字段 | ✓ |
+| §十 5 个更新时机（310–316） | `state.md` | ✓ 5/5 |
+| §十 信息优先级（318–323） | `state.md` + 合并规则 3 条 | ✓ 增加了"不得拒绝用户更正" |
+| §十 无持久化降级（325） | `state.md` 末节 | ✓ 保留为导出选项 |
+| §十一 动手前五项（331–337） | `permissions.md` | ✓ 5/5 |
+| §十一 不扩大范围 / 只读不得修改（339） | `permissions.md` + 授权记录 | ✓ |
+| §十二 8 条（343–350） | R6/R7/R8 + `task-loop.md` | ✓ 8/8（其中 2 条为第 3 轮补入，见 D2） |
+| §十三 11 条指令（354–366） | `SKILL.md` 指令表 | ✓ 11/11 |
+| §十四 首回复 4 条（370–375） | `SKILL.md` 首次交互 | ✓ 4/4（`assumeGoal` 只改变交互成本，目标仍须落盘） |
+
+**13 条不变量的"声称 vs 实现"对照**：13 条全部在 `coach-validate.mjs` 中实现（含枚举、类型、跨字段引用、跨对象一致性）。另有 3 条**语义规则无法机械校验**，已在三处如实声明，不计入"已强制"：
+
+1. 证据充分性三条件（可复现/可解释/可修改）——需人判断；
+2. 审阅的"依据"是否真实存在、是否已核对——需打开材料；
+3. 提示是否只给到某一级、是否泄露完整答案——对话层不可校验。
+
+**交叉规则一致性排查**：逐对比较 `SKILL.md` × `references/engine/*.md` 的 6 组相关条款（状态路径、追问配额、提示级别默认、验收三档与复述、权限记录、领域包引用方式），未发现互相矛盾。发现并修复 1 处**操作性缺口**：快速问答车道要求"在状态里记录"，但此时可能尚不存在状态文件 → 已改为"已有状态文件时才记录，不为此单独建档"。
+
+**可用性缺口（假设模型只读 `SKILL.md`）**：
+
+| # | 缺口 | 处置 |
+|---|---|---|
+| 1 | 技能根目录写死为工作区路径，Bundle 安装下会失效 | 第 2 轮已改为"以加载时给出的 Base directory 为准" |
+| 2 | 未说明何时建立状态文件 | 已写明"首轮无状态文件时用 `assets/state.template.json` 建骨架" |
+| 3 | 提示级别的具体判据 | 属设计取舍：常驻只给级别定义，细节在 `task-loop.md`（按需加载） |
+| 4 | 领域包很大时的读取策略 | 第 3 轮已加入"先读索引、只读所需题目"（学科无关表述） |
+| 5 | 校验失败时的处置 | 已写明"先修状态再继续，不得声称已保存" |
+
+### 6.4 外部对抗性复核结论
+
+由**两个不共享我推理过程的独立代理**执行：一个做全量复核（覆盖矩阵逐条、13 条不变量真伪、分层反例与绕过、规则一致性、可用性缺口）；另一个做有界复核（5 项断言 + 实测命令）。二者均只读、均未修改被复核文件。
+
+**结论摘要**
+
+| 断言 | 结论 |
+|---|---|
+| 指令表引用的文件是否都存在 | 成立 |
+| 常驻规则 R1–R8 与 references 细则是否冲突 | **不成立**：`state.md` 关于 `directAnswers` 的"一律不计入证据"与 `task-loop.md`"能解释/修改/验证后可计入"字面互斥 → 已改 `state.md` 措辞 |
+| 13 条不变量是否都在代码中实现 | **不成立**：12 条已实现，第 7 条"从 1 连续唯一"只实现了连续性（缺起点校验）→ 已修（D15） |
+| README 声明与实现是否一致 | **不成立**：①"只覆盖状态层"低估（还含领域包与分层检查）；③Node 版本归属错误（`fs.cpSync` 在自测与安装器里）；②④成立 → 已改 |
+| 文档数字与实跑是否一致 | 成立（反向夹具 error 数、自测项数、PASS/FAIL 与文档一致） |
+
+**关键发现**：1 条阻塞（D8：门禁只认证"引用存在"，可为通过校验而补造证据）、8 条重要（D9–D14、D16、D17 中的 `null` 静默通过）、5 条建议。**全部已在 6.2 表中处置并复测**；复核者提出的"最可能的失败模式：为让校验通过而补造证据/路线"正是 D8 所修——现在"已验证"必须由强度为"已验证"的证据支撑，占位符材料不再算证据。
+
+**双方一致确认**：教学法内核（先做后教、分级提示、证据判定、动态调整）忠实保留；状态层设计可用；分层护栏有效但非证明。
+
+**已复测的修复证据**（隔离探针，每项单独构造，互不污染）：`null` 状态 → ST00 且退出码 1；证据强度降级 → ST03；`artifact='-'` → ST06；`route[0].n=5` → ST07；`updatedAt='March 8, 2026'` → ST12；`--out` 指向目录 → ST-W3 且无原始堆栈；新生仅填目标 → PASS + ST-W4；`estimateMin=600` → ST-W6；视图头部显示真实状态路径。
+
+### 6.5 未解决事项与残余风险（构建后更新）
+
+1. **Unity 环境未实测**：本机默认路径下无 Unity Editor（仅安装 Unity Hub）。`verification.md` 中所有"（未验证）"条目在真实环境实测前**不得用于验收判定**——该约束已写入领域包契约与状态契约。
+2. **校验器只覆盖状态层**：不能验证对话质量与教学效果；这一边界已在 README、`state.md`、校验器输出三处声明。
+3. **原生 CLI 的组合包安装路径未实测**：第 3 轮构建时 `cordis.patch.yml` 走的是"额外插入一个 skill-filesystem 提供方"的写法（依赖 `providerName` 唯一性），该写法**已被第 7 节替换**为官方样板做法（`ctx.skills.register()`）；静态检查通过，但 `dsh plugin add` → 启动的端到端流程仍未在原生 CLI 上执行。
+4. **领域包 152 KB 依赖按索引读取**：已加指引，但仍依赖模型遵守；若模型整篇读入，会造成上下文浪费（非正确性问题）。
+5. **引擎仍依赖模型遵守 SKILL.md**：机械校验降低漂移后果，未消除漂移。
+
+### 6.6 交付清单（实测体积）
+
+| 位置 | 文件数 | 字节 |
+|---|---:|---:|
+| `coach/` 根（审核文档、README、bundle 清单、patch） | 4 | 49,538 |
+| `coach/skills/dsh-coach/SKILL.md`（常驻引擎） | 1 | 7,014 |
+| `coach/skills/dsh-coach/references/engine/`（按需，9 个） | 9 | 27,959 |
+| `coach/skills/dsh-coach/references/domains/unity-csharp/`（按需，7 个） | 7 | 152,124 |
+| `coach/skills/dsh-coach/assets/`（模板） | 4 | 5,714 |
+| `coach/skills/dsh-coach/scripts/`（校验器、自测、安装） | 3 | 50,808 |
+| `coach/examples/`（正向/反向夹具、视图样例） | 3 | 18,059 |
+| **合计** | **31** | **311,216** |
+
+分层检查扫描面：`SKILL.md` + `references/engine/*.md`（9）+ `assets/*.md`（3）= **13 个文件**。
+
+> 本表是第 3 轮构建结束时的快照（当时仓库根为 `coach/`，审核文档在根目录）。其后进入发布化重构：审核文档移至 `docs/`，新增 `lib/index.js`（组合包入口）、`cordis.patch.yml` 重写、`test/`、`.github/workflows/ci.yml` 与开源外壳（`LICENSE`、`.gitignore`、`.gitattributes`、`CHANGELOG.md`、`CONTRIBUTING.md`、双语 README、`docs/installing.zh.md`）。运行时技能内容未变。
+
+---
+
+## 7. 第 4 轮：发布化重构（插件化 + 开源外壳）
+
+### 7.1 触发与结论来源
+
+社区插件 `dsh-plugin-guide@0.3.9`（DSH Desktop 市场安装）带来了三份此前缺失的依据：官方 `docs/user/develop/basic/publish.md`（bundle/profile 契约与层序）、官方 `docs/architecture.zh.md`（profile 组合与 `dsh plugin`）、以及一个**真实可用的第三方样板**——它本身就是一个"只做一件事：把技能注册进 DSH"的组合包。据此，第 3 轮"引擎暂不做插件"的结论被修订为：**技能内容不动，外面加一层薄组合包**。
+
+### 7.2 改动清单
+
+| 项 | 改动 | 依据 |
+|---|---|---|
+| 组合包入口 | 新增 `lib/index.js`：`export name` + `export inject = ['skills']` + `apply(ctx)` → `ctx.effect(() => ctx.skills.register({name, source, description, content, resourceBase:{kind:'directory', path}}))` | 样板 `dsh-plugin-guide/index.js`（58 行）+ `dsh-skill` 文档：注册即 effect、省略 invocation 时默认 `modelInvocable/userInvocable` 均为 true |
+| patch 层 | `cordis.patch.yml` 重写为单行 insert（`id` + `name`，按包名解析） | 官方 `publish.md` 的最小结构 |
+| 技能目录解析 | `resourceBase` 指向 `skills/dsh-coach/`（而非包根），使 `references/`、`assets/`、`scripts/` 的相对引用在两种形态下语义一致 | 本仓库技能布局 |
+| 清单 | `package.json`：去 `private`、`main` 指向 `lib/index.js`、`files` 白名单、`keywords`、`author`/`repository`/`homepage`/`bugs`、`engines`、`packageManager`、peer（`@deepseek-ai/cordis@^4.0.2` + `@deepseek-ai/dsh` 区间，后者 optional） | 样板的元数据约定 + 本机版本实测（`@deepseek-ai/dsh@0.1.2-rc.1`、`cordis@4.0.2`） |
+| 许可 | MIT（`LICENSE`），版权行暂用 `dsh-coach contributors` | 用户决定；官方核心自 `0.1.2-alpha.3` 起亦为 MIT |
+| 仓库外壳 | `.gitignore`（排除 `.coach/`、`PROGRESS.md`、`.dsh/`、临时目录）、`.gitattributes`（LF 归一）、`CHANGELOG.md`、`CONTRIBUTING.md`、`.github/workflows/ci.yml`（ubuntu+windows × node 22/24）、双语 README、`test/entry.smoke.mjs` | 开源发布要求 |
+| 文档 | 审核文档与原文移入 `docs/`；新增 `docs/installing.zh.md`（含实测/未实测标注） | 可复核性 |
+
+### 7.3 验证证据（本机实跑）
+
+| 检查 | 结果 |
+|---|---|
+| `dsh-plugin-dev check --json`（社区官方工具链，`dsh-plugin-guide` 自带） | **ok=true，9 通过 / 0 失败 / 2 警告**。两条警告均为该样板作者的**文档约定**，不采纳：① "五语 README"——官方 harness 仓库亦仅中英双语；② "README headings drifted"——其规则是要求各语言 README 的**标题字符串完全相同**（代码为 `base.filter(h => !headings.includes(h))`），而官方包自己的 `README.zh.md`（如 `@deepseek-ai/dsh-skill`）用的是翻译标题（`## 概述` 对 `## Overview`），故本项目的翻译标题是有官方先例的做法。两条均不做未审校的机器改写 |
+| `node test/entry.smoke.mjs` | PASS（入口契约 + 11 个技能资源存在性） |
+| `node skills/dsh-coach/scripts/coach-selftest.mjs` | PASS 6 / SKIP 0 / FAIL 0 |
+| `dsh --help`（本机 profile 内自带的 CLI） | 确认 `plugin` 子命令与 `--dump-config` 存在，可作为端到端验证入口 |
+| `dsh --profile web --dump-config --patch ./cordis.patch.yml` | **通过**：532 行组合输出中出现本层（`- id: dsh-coach` / `name: dsh-coach`），无 EPERM / FAILED / 模块解析错误。证明 patch 语法与层序在**真实 profile 树**中成立（该命令只读，不写 profile） |
+| `npm pack --dry-run --json` | **通过**：`dsh-coach@1.0.0`，38 个文件，136.7 KB（压缩）/ 344.2 KB（解包）；含 `lib/` 与 `skills/`，**未**误含 `test/` 与 `.github/`，与 `files` 白名单一致 |
+| `git init -b main` + `git add -A` | **通过**：42 个文件入暂存，关键文件（`lib/index.js`、`cordis.patch.yml`、`LICENSE`、双 README、CI、`docs/installing.zh.md`、技能与夹具）全部在内；`git status --ignored` 显示无任何本应提交的文件被忽略。（未提交：等用户提供署名与仓库 URL 后由本人以真实身份提交） |
+
+首次检查曾报 2 条失败，均为真实可修项：① 入口 JSDoc 引用了 `@deepseek-ai/cordis` 类型但未声明 peer → 补 `peerDependencies`；② `files` 白名单没有构建产物目录 → 把入口从包根 `index.js` 移到 `lib/index.js`（**手写来源，非构建产物**，与 harness 各包布局一致）。
+
+### 7.4 仍未完成
+
+1. **原生 CLI 端到端安装**：patch 组合已用 `--dump-config --patch` 在真实 profile 树中验证（见 7.3）；仍未做的是 `dsh plugin --profile <profile> add <路径>` → 启动 → 技能出现在会话目录 → `remove` 的完整闭环。它需要写 `$DSH_HOME/profiles/`，且新建 profile 会连带 pnpm 下载整套 harness 核心，属较重操作，需用户明确同意后执行。
+2. **市场收录**：入口确认为 [awesome-dsh-plugin/awesome-dsh-plugin](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin)，**提交形态已由一处已合并的真实 PR 确认**：[PR #3405](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin/pull/3405) 标题为 `feat(catalog): add dsh-vision-bridge by alaxrpg`，即 `feat(catalog): add <插件名> by <GitHub 账号>` + 在目录 README 增行。另发现三个相关仓库（`dshworks/awesome-dsh-plugins`、`0xsline/awesome-deepseek-harness`、`dsh-plugin-evaluation/dsh-plugin-evaluation-standards`）。**未完成**：各仓库 `contributing` 文件的正文细则——本机对 `raw.githubusercontent.com` 的抓取对这些仓库持续失败（deepseek-harness 的 raw 可抓，故判断为站点/仓库侧限制），需用浏览器打开后按其格式准备 PR。清单与标题格式已写入 `docs/releasing.zh.md`。
+3. **`dshWorkshop` 元数据**：样板的 `package.json` 里有 `omdsh-workshop-package/v1` 块（integration/install/lifecycle/permissions/compatibility/capability）。已在本机 `dshmarket@1.45.1` 的代码中搜索 `dshWorkshop` / `workshop-package` —— **无命中**，故判断它属于某个社区 workshop 的约定，**不是 dshmarket 的必需项**，本轮未采用。
+4. **`repository`/`homepage`/`bugs` 仍是 `OWNER` 占位**，需要用户提供 GitHub 账号后替换。