verification-methodology

验证方法

依据预先定义的标准进行通过／失败评估。

验证流程

1. 接收 — 重述待验证的工件、主张或实现，以及验证结果将支持的决策。
2. 评估标准 — 将要求转化为可观察的通过／失败条件；明确哪些情况会推翻每项主张。
3. 调查 — 从请求指定的来源收集直接、可复现的证据，并记录命令、来源位置或来源 URL。只要能够访问来源，就由你自行收集：不要要求用户转述你自己能够获取的证据。只有在确实缺少访问权限时才提出请求。
4. 判定 — 将每项标准标记为通过、失败、受阻或不适用。不要把缺少证据当作通过。
   • 如果验证分为多个工作流，没有任何一个工作流的 PASS 能单独作为最终判定。请等待所有必需工作流完成，并在综合结果前解决冲突。
   • 对于同一工件哈希，后续的来源保真度 BLOCK 优先于先前的文本、渲染或清单 PASS。应立即将先前的 PASS 数据包标记为已取代，避免下游工作人员误将其当作当前判定。
   • 模式扫描和内部一致性检查不能替代依据指定的主要来源或来源档案核查事实转换。
5. 报告 — 使用判定模板区分已验证事实、假设和剩余工作。将判定与候选提交／内容哈希、验收契约版本／哈希、审查范围、已执行检查、环境／测试夹具、结果和证据引用绑定。相关变更会使受影响的批准和证据失效；应将旧数据包标记为已取代，并在交付前重新验证。即使分支、PR 或提交未变，只要未提交内容发生变化，也不再是同一候选版本。

当每项标准都有直接证据，或已明确标记为受阻／不适用时，即可停止。如果标准含糊不清、证据相互冲突或无法获得所需访问权限，则应升级处理。

来源保真度

将请求指定或配置的本地服务视为验证标准的一部分，而非可互换的话题标签。

1. 加载匹配的技能，并在尝试相邻集成、通用网页搜索或公开项目来源之前，使用该技能文档记录的可执行程序或服务路径。
2. 使用技能本身解析出的路径。全局 PATH 中缺少条目，并不能证明捆绑的可执行程序不可用。
3. 如果直接来源不可用，应报告尝试过的命令或端点及其确切错误。不要悄悄用其他来源的证据替代。
4. 仅当用户要求更广泛的背景信息或明确接受备用来源时，才使用替代来源。应将替代来源的证据标记为次要证据，不要将其描述为所请求来源的状态。

示例：在配置了 Jellyfin 技能和捆绑 CLI 的环境中，如果用户问“Jellyfin 有什么新内容？”，应先通过捆绑的 CLI 查询该服务器。Home Assistant 实体和 Jellyfin 项目的公开动态回答的是不同问题。

不适用场景

如果任务是开放式探索，且没有工件、主张、决策或可观察的完成标准，请勿使用此技能。请先使用研究或探索技能；待有可证伪的内容后，再返回此处进行验证。

相关技能

• playwright — 将基于浏览器的 E2E 检查用作验证手段：针对真实 UI 边界编写并运行规范。
• documents — 生成验证报告或证据数据包，并以 PDF／Word／Excel／PowerPoint 交付。

参考文件

参考文件	加载时机
references/criteria-assessment.md	需要评估工作是否满足完成标准时
references/evidence-standards.md	需要判断证据是否支持所作声明时
references/magnus919-refine-to-ship-gate.md	运行 Magnus919 Refine-to-Ship 验证门禁时，包括 12 项标准、编辑修改验证和输出结构
references/verdict-template.md	需要生成结构化的通过／失败／暂缓判定时

Magnus919 Refine-to-Ship 门禁标准

验证器配置文件的 12 项标准。每项标准都对应一项可观察、可复现的检查。

全部 12 项标准

#	标准	验证方法
1	破折号扫描：不得出现 em dash（U+2014）、en dash（U+2013）、horizontal bar（U+2015）或可见的正文双连字符	使用 search_files 搜索 [\u2014\u2013\u2015] 和 \-\-。YAML frontmatter 分隔符中的双连字符可以保留。
2	事实核查：所有方法论声明都必须对应来源；不得捏造数字、时间顺序或普遍性声明	将文章中的声明与来源文档各章节交叉核对。搜索 \d+%、percent、average of、illustrative。搜索 research proves、studies demonstrate。
3	语气检查：符合 Magnus 的写作特征：对话式第一人称、缩略形式、使用“But”转折（而非正式过渡语）、多用冒号而非分号，不采用顾问式行文	搜索 Furthermore、Moreover、Nevertheless、Consequently、Therefore、not only.*but also 和三项并列结构。统计冒号与分号的数量（冒号应明显更多）。
4	Oxford 逗号、拼写、语法：使用美式英语，在并列项中使用 Oxford 逗号，不得有拼写错误	人工检查并列项。检查格式是否一致。
5	不得使用公式化的 AI 收尾：不得出现“In conclusion”“To summarize”“In this article”或泛泛的励志建议	使用 search_files 搜索 In conclusion、Ultimately,、To summarize、In this article、In this post。
6	方法论优先：个人叙述部分不超过文章的约 10%；其余部分应以方法论为主	统计个人叙述部分与正文的段落数。
7	融入人的切身影响：认知负担、专业能力形成、工作转移、反监控、问责权限	检查是否设有专门章节，或是否分散涵盖了所有方面。
8	隐私／匿名化：不得出现公司标识、职位名称、人物姓名、来源文件名或专有领域示例	使用 search_files 搜索公司名称、产品名称以及来源中的领域专用术语。
9	Frontmatter：标题、slug、日期、署名必须正确，且与规格中的值完全一致	使用 read_file 查看第 1–11 行。
10	链接有效：每个不同的 URL 在首次有意义提及时仅出现一次；所有链接均返回 200	对每个 URL 执行 curl -s -o /dev/null -w "%{http_code}"。确认链接文字出现在首次有意义提及时。
11	Hugo 构建和路由：构建退出码为 0；新路由返回 200；旧的 take-home-title 路由返回 404	执行 hugo --quiet && echo EXIT:$?。对两个路由执行 curl。
12	不得重复源文件包：仅有一个目录和一个 index.md；不得有过时的 *take-home* 目录	执行 ls 查看页面包目录。使用 find 在 content/posts 中查找重复 slug 模式。

父配置文件要求的编辑修改

当父配置文件在门禁恢复期间指定了编辑修改时，在进行完整标准扫描前，先验证每项修改是否已落实：

修改类型	验证方法
删除编造的示例数字	使用 search_files 搜索 \d+%、percent、PRs? per、average of；结果应为零
时态修正	使用 search_files 搜索父配置文件指定的确切短语
替换结尾	使用 search_files 搜索父配置文件指定结尾的首句和末句

判定规则

• PASS： 满足全部 12 项标准。生成 00-index.md、01-summary/verdict.md、02-analysis/per-criteria-results.md。
• BLOCK： 任一标准未通过。生成 gap-details.md，并提供具体的修复说明。修复模式请参阅 verifier-gate-recovery 技能。

输出结构

/private/tmp/verifier-gate/<slug>-refine/
  00-index.md              — verdict, links to artifacts
  01-summary/verdict.md    — per-criterion pass/fail table
  02-analysis/
    per-criteria-results.md  — detailed evidence per criterion
    gap-details.md           — only if BLOCK, with remediation instructions

可移植性

此技能刻意保持与宿主环境无关。请使用 Agent 的常规方式加载此处列出的参考资料、模板和脚本。不要假定存在特定的配置文件系统、任务编排器、记忆服务或响应交接格式。