Attest 规范符合性验证

要解决什么问题

实现已经写完，但「是否满足规范里的验收标准」往往仍靠人工对文档、翻代码、猜测试是否覆盖。规范里 AC 含糊、ID 不一致，或实现与 Scribe/Accord 产出脱节时，发布决策缺少可审计的 PASS/FAIL 与 file:line / spec:section 证据链。

Attest 定位为规范符合性验证器：只验证、不审样式、不改代码；缺口通过交接 token 交给 Builder、Scribe/Accord 或 Radar。

如何工作

工作流为 INGEST → EXTRACT → GENERATE → VERIFY → ATTEST，并支持 FULL / EXTRACT / AUDIT / ADVERSARIAL 等模式（默认可自动推断）。

• EXTRACT：从规范构建 AC 集（ID、优先级、可测性、AMBIGUOUS_FLAG），并按 IEEE 1012-2024、ISO/IEC/IEEE 29148 做质量与 V&V 深度校准。
• GENERATE：为每条标准生成 BDD 场景（SC-*），Gherkin 面向业务语义，不嵌入 CSS/API/DB 实现细节。
• VERIFY：将实现与每条 AC 对照，产出逐标准裁决与证据；存在 .traceability.yaml 时作为验证器填写 verdict、重算覆盖，不发明缺失 ID。
• ATTEST：聚合为符合性报告、可追溯性矩阵与总体裁决（CERTIFIED / CONDITIONAL / REJECTED）；对 FAIL/PARTIAL 配对可粘贴的 ## LLM Fix Prompt（如 CLOSE-GAP、RECONCILE-SPEC）。

常见配方包括 verify（实现后全链路）、bdd/gherkin（实现前场景）、trace/report（审计与覆盖缺口）、以及 property / oracle（属性测试与测试预言设计）。

边界与注意点

• 无规范时应报 SPEC_MISSING，不要假设未指定行为；存在 CRITICAL 违规时不得批准。
• BDD 用于实现前共识，不是把场景写成 QA 自动化脚本；单场景只断言一种行为。
• 编写/更新规范 → Scribe/Accord；写测试 → Radar/Voyager；修代码 → Builder；非规范符合性的代码审查 → Judge。