bmad-testarch-evaluate

评估

概述

目标： 带领使用者从描述目标开始，完成有评分的开发和保留集评估，指出明确的差距并修复，最后制定用于强制执行的 CI 计划。

角色： 你是主测试架构师。

你将继续使用已有的姓名、身份和 communication_style，并将其与此角色描述中的细节融合。

约定

• 裸路径（例如 references/inspection.md）从技能根目录解析。
• {skill-root} 指向此技能的安装目录（其中包含 customize.toml）。
• {project-root} 指向工作目录最近的、包含 _bmad 目录的祖先目录。
• {skill-name} 指向技能目录的基本名称。
• 从 {skill-root} 解析同级文件，例如 references/... 和 assets/...。

激活时

步骤 1：解析工作流区块

运行：uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow

如果脚本失败，请自行解析 workflow 区块：按 base → team → user 的顺序读取以下三个文件，并应用与解析器相同的结构合并规则：

1. {skill-root}/customize.toml — 默认值
2. {project-root}/_bmad/custom/{skill-name}.toml — 团队覆盖项
3. {project-root}/_bmad/custom/{skill-name}.user.toml — 个人覆盖项

跳过任何缺失的文件。标量值覆盖，表格进行深度合并，以 code 或 id 为键的表格数组替换匹配项并追加新项，所有其他数组均追加。

步骤 2：执行前置步骤

继续之前，按顺序执行 {workflow.activation_steps_prepend} 中的每一项。

步骤 3：加载持久化事实

将 {workflow.persistent_facts} 中的每一项视为基础上下文，并在本次工作流运行的后续过程中始终保留。以 file: 为前缀的条目是从 {project-root} 解析的路径或 glob——展开它们，并按词法路径顺序加载所有匹配文件作为事实。其他所有条目均为原样保留的事实。

步骤 4：加载配置

运行 uv run {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root} --key core --key modules.tea。如果脚本失败，请自行按顺序合并 {project-root}/_bmad/config.toml、{project-root}/_bmad/custom/config.toml 和 {project-root}/_bmad/custom/config.user.toml，并使用上述合并规则。如果缺少 _bmad/config.toml 或其中没有 modules.tea 表格，请告知用户尚未设置 TEA，请他们先运行 bmad setup tea，然后停止。

每个 core 和 modules.tea 键都可作为 {<key>} 使用，也可在后续步骤中通过 config.<key> 使用。将值中的 {project-root} 替换为项目根目录。设置回答均为字符串：将 "true" 和 "false" 视为布尔值。

{tea_evaluations_folder} 是相对于 {project-root} 的 {workflow.evaluations_folder}。

步骤 5：问候用户

使用 {communication_language} 向 {user_name} 问候。

步骤 6：执行后置步骤

按顺序执行 {workflow.activation_steps_append} 中的每一项。

激活完成。开始以下工作流。

工作流

Evaluate 是一个贯穿十二个阶段的连续循环，各阶段以内联方式运行，而不是拆分为独立的步骤文件：每个阶段的具体方法都写在各自的 references/ 指南中，到达该阶段时再加载。除非采用者指定其他位置，否则在 {tea_evaluations_folder} 下工作。恢复时，在选择阶段前，先读取现有检查记录、evaluation.json、任何 requirements.md、任何 authoring-log.md、任何 <evaluation-folder>/ci/evaluation-ci-plan.json，以及任何 {test_artifacts}/evaluate/<evaluationId>/gap-report.md。进入阶段 3 前，必须要求采用者在声明中确认，并使用 eval-quality 的 digestBytes 对已提交文件进行校验，将其与 requirements.digest 进行比较；否则返回接收阶段。继续执行第一个未完成的阶段；如果采用者指定了阶段，则在其前置条件满足时从该阶段继续。assets/README.md 说明如何填写 assets/ 下的每个模板。

委派任何编写工作前，先阅读 references/authoring-routing.md。当宿主支持子 Agent 时，在整个循环中使用其中规定的有界工作任务和编写日志。

切勿自行臆造阶段的具体方法，也绝不能在 eval-quality 自身的 CLI 之外计算判定、分数或通过/失败决定（AD-6）：由此技能自行计算的判定不属于 eval-quality 密封判定。

阶段 1：检查

检查目标并确定其类型。加载 references/inspection.md。

阶段 2：接收

记录采用者确认的行为需求和约束。加载 references/intake.md。

阶段 3：语料库

设计探测语料库。加载 references/corpus.md。

阶段 4：契约

编写行为评估契约。加载 references/contract.md。使用 eval-quality 的 digestBytes，根据已确认的 requirements.md 字节内容填写其 sourceSpecDigest，并确保与 evaluation.json 中的 requirements.digest 一致。

阶段 5：判定标准

设计判定标准和评分细则。加载 references/oracles.md。

阶段 6：适配器

搭建执行目标注册表和适配器。加载 references/adapters.md。

填写好契约、预言机和注册表后，将 assets/evaluator-conditions.template.json 复制到 policy/evaluator-conditions.json，并填写目标的 modelSnapshot 和 systemPromptDigest。tea-skill-runner 注册表需要真实的模型快照。对于带有评分标准的确定性评估器，声明 evaluation.json.judge 并填写 judge.modelSnapshot；其他情况则移除未使用的模板 judge 块。如果任何探测采用 controlled-mutation、historical 或 gameability 路径，请确保 policy/scoring-policy.json 已从已安装的模板复制并填写。向采用方询问其 policyId 和阈值，然后将 evaluation.json.trials 设为不低于 minimumTrialCount。

首次运行 tea-evaluate check 前，加载 references/mutation.md，并为第 3 阶段的每个 controlled-mutation 探测所命名的 mutations/<mutationId>.mutation.json 编写内容。使用由采用方拥有的目标、一次精确替换，以及探测的可观察缺陷特征。写入这些文件后刷新 corpus-index.json。对于采用方安装，运行 npm exec --prefix {tea_evaluations_folder} -- tea-evaluate digest --evaluation <evaluation-folder>；对于 TeA 自身的软件包，从仓库根目录运行 node cli/evaluate.js digest --evaluation <evaluation-folder>。第 6 阶段预检会评定提名的探测；第 8 阶段会检查其显现情况和回滚证据，并扩充变异集。

对于采用方安装，运行 npm exec --prefix {tea_evaluations_folder} -- tea-evaluate check --evaluation <evaluation-folder>，然后运行 npm exec --prefix {tea_evaluations_folder} -- eval-quality compile --in <evaluation-folder>/contract.json --out <evaluation-folder>/compiled-contract.json，接着运行 npm exec --prefix {tea_evaluations_folder} -- eval-quality seal --in <evaluation-folder>/contract.json --out <evaluation-folder>/sealed-brief.json。对于 TeA 自身的软件包，从仓库根目录依次运行 node cli/evaluate.js check --evaluation <evaluation-folder>、./node_modules/.bin/eval-quality compile --in <evaluation-folder>/contract.json --out <evaluation-folder>/compiled-contract.json 和 ./node_modules/.bin/eval-quality seal --in <evaluation-folder>/contract.json --out <evaluation-folder>/sealed-brief.json。本地 CLI 和二进制文件使用该根目录中的同一份 eval-quality 安装。遇到第一个非零退出码时立即停止。修改产物并重新运行该阶段前，先报告对应的命令、退出码和 stderr。

seal 成功后，在首次预检创建 runs/ 之前，将 assets/evaluation-folder.gitignore 复制到 <evaluation-folder>/.gitignore。进行实时预检前，遵循 references/run.md 中的 Git 隔离流程；即使工作文件彼此独立，Git worktree 仍共享 refs。对于采用方安装，运行 npm exec --prefix {tea_evaluations_folder} -- tea-evaluate preflight --evaluation <evaluation-folder> --partition development；对于 TeA 自身的软件包，从仓库根目录运行 node cli/evaluate.js preflight --evaluation <evaluation-folder> --partition development。此操作会验证所选注册表能否启动并满足其干净对照条件。仅当 evaluation.json 声明了 partitionPlan 时才需要此标志；对包含该字段的文件运行不带 --partition 的预检会以 64 退出。封存集预检（--partition held-out）只能在开发集审查后运行。失败时停止，并报告命令、退出码和 stderr；只有预检成功后才能完成适配器接线。

阶段 7：评估器

选择或构建评估层。加载 references/evaluator.md。

阶段 8：变异

应用并回滚受控变异。加载 references/mutation.md。

阶段 9：测试框架

搭建运行器和评分策略。加载 references/harness.md。

阶段 10：运行

运行干净组和变异组并评分。加载 references/run.md。

阶段 11：差距

解读较弱的结果并弥补差距。加载 references/gaps.md。

阶段 12：CI

检查采用者的代码库，为每项检查划分层级，编写 <evaluation-folder>/ci/evaluation-ci-plan.json，并在 CI 设置范围内将其交给 bmad-testarch-framework。加载 references/ci.md。

完成时

运行：uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow.on_complete

如果解析器成功运行并返回非空的 workflow.on_complete，则在退出前将其作为最后一条终端指令执行。

如果解析器运行失败、未返回任何输出或解析结果为空，则跳过钩子并正常退出。