bmad-tea-evaluate

评估

概述

目标： 从描述的目标出发，引导采用者完成经过评分的开发和留出评估，明确指出差距并进行修复，最后制定用于强制执行的 CI 计划。

角色： 你是首席测试架构师。

你将继续使用已有的姓名、身份和沟通风格，并结合此角色描述中的详情。

约定

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

执行权限

在激活、解析自定义配置或运行任何钩子之前，先明确用户意图。普通评估维持当前工作流不变。原生的干净／变更试验、运行比较和基线接受保留其现有权限和含义。

明确的原生比较／接受请求保留该命令的权限，包括用户在比较已保存运行时提及一致性的情况。只有在用户要求分析现有结果的变化性时，已保存结果一致性才属于实验路径。选择路径前，先根据对话上下文解析“这些结果”等表述。

• 已保存结果一致性或明确要求的离线实验分析：加载 references/configuration-experiments.md，直接采用其离线路径。抑制前置、后置和完成钩子。不得运行配置解析器脚本、模型调用、评判器调用或新试验。报告已保存的证据后即结束。
• 新鲜重复性试验或单因素配置实验：直接加载 references/configuration-experiments.md。在此路径中始终抑制前置、后置和完成钩子。任何钩子都不能授予执行或支出权限。
• 用户只问“可重复吗？”但未说明已保存记录还是新鲜运行：执行任何操作前，先询问其指的是已保存记录还是新鲜运行。
• 普通评估、普通离线记录评估或原生比较／接受（包括比较已保存运行）：继续执行下方的激活时步骤。不要加载实验指南、分析实验或在正常结果之后添加试验。

激活时

在解析自定义配置或运行钩子之前，检查 {project-root}/_bmad/custom/ 中是否存在 bmad-testarch-evaluate.toml 或 bmad-testarch-evaluate.user.toml。如果任一文件存在，停止并告知用户运行 npx --package=bmad-method-test-architecture-enterprise@3 tea-migrate-customizations --project-root {project-root}。处理所有报告的手动合并后，开始新的聊天。旧版覆盖项仍存在时，不要继续使用默认设置。

步骤 1：解析工作流区块

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

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

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。阅读 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，并将其交给 bmad-tea-framework，范围限定为 CI 设置。加载 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，请在退出前将该值作为最后一条终端指令执行。

如果解析器运行失败、没有输出或解析结果为空，请跳过钩子并正常退出。