Back to Details

verification-driven-delivery

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Verification-Driven Delivery

验证驱动交付

Purpose

目标

Bridge delivery orchestration with 
design-high-value-tests
. Preserve a compact verification contract as work moves from specification to tickets, implementation, and review. Do not duplicate the testing corpus or replace the active phase skill.
衔接交付编排与
design-high-value-tests
技能。在工作从需求规格推进到工单、开发实现及评审的全流程中，保留简洁的验证契约。请勿重复测试用例集或替代当前阶段的核心技能。

Establish Ownership

明确权责

Apply instructions in this order:
  1. Follow the user's directions and repository instructions.
  2. Treat approved specification and ticket decisions as binding unless repository evidence makes them impossible or contradictory.
  3. Let the active phase skill own its workflow, approvals, tracker operations, implementation sequence, review shape, and publication actions.
  4. Let 
    design-high-value-tests
    own test-design judgment: protected behavior, test level, observation boundary, dependency fidelity, meaningful-red evidence, and the test-value quality gate.
  5. Use this skill only to carry those decisions between phases and resolve the overlaps below.
Use 
design-high-value-tests
when a test-design decision remains. Load only the references it routes to for that decision. If it is unavailable, preserve existing verification decisions and report the missing dependency instead of silently reconstructing its full guidance.
Work only in the phase the user invoked or requested. Do not silently start another user-invoked skill. Reopen an approved decision only when new repository evidence materially invalidates it; explain the evidence and ask before making a consequential change.
按以下顺序执行指令：
  1. 遵循用户指示及仓库说明。
  2. 已获批的规格与工单决策具有约束力，除非仓库证据显示其不可行或存在矛盾。
  3. 由当前阶段的核心技能掌控工作流、审批流程、追踪操作、实现顺序、评审形式及发布动作。
  4. 由
    design-high-value-tests
    技能掌控测试设计判断：受保护行为、测试级别、观测边界、依赖保真度、有意义的失败证据，以及测试价值质量 gate。
  5. 仅使用本技能在各阶段间传递上述决策，并解决以下重叠问题。
当测试设计决策尚未确定时，调用
design-high-value-tests
技能。仅加载该技能针对此决策指向的参考内容。若该技能不可用，则保留现有验证决策，并报告缺失的依赖，而非自行重构其完整指引。
仅在用户调用或请求的阶段开展工作。请勿擅自启动另一项用户调用的技能。仅当新的仓库证据实质性推翻已获批决策时，才重新开启决策流程；做出重大变更前，需说明相关证据并征求用户同意。

Preserve the Verification Contract

保留验证契约

Specification contract

规格契约

Record the following under 
## Testing Decisions
:
  • Protected behaviors: observable scenarios and outcomes worth preserving.
  • Risks and evidence: each distinct risk, its sufficient test level, and why that level retains the risk.
  • Approved observation seams: stable public interfaces through which behavior is exercised and observed.
  • Boundary fidelity: dependencies kept real, boundaries replaced, and where compatibility with a real provider is proved.
  • Meaningful-red approach: what should fail at the starting revision or when the production change is reversed.
  • Prior art and constraints: relevant repository test shapes, runners, and infrastructure.
  • Residual risks: intentionally deferred or separately owned evidence.
Keep this contract architectural. Avoid commands, file paths, framework APIs, and code shapes that implementation must rediscover from the current repository.
在
## Testing Decisions
下记录以下内容：
  • 受保护行为：值得保留的可观测场景及结果。
  • 风险与证据：每一项独特风险、对应的充足测试级别，以及选择该级别可管控风险的原因。
  • 已获批观测接口：用于执行及观测行为的稳定公共接口。
  • 边界保真度：保留真实的依赖项、替换的边界，以及证明与真实提供商兼容性的方式。
  • 有意义的失败验证方法：初始版本或回滚生产变更时应触发失败的场景。
  • 既有实践与约束：仓库中相关的测试形式、运行器及基础设施。
  • 剩余风险：有意推迟或由其他方负责验证的风险。
契约需聚焦架构层面。避免包含实现阶段需从当前仓库重新探索的命令、文件路径、框架API及代码形式。

Ticket contract

工单契约

Give each behavior-changing ticket a compact 
## Verification contract
:
  • Protected behavior: 
    When <observable scenario>, the system <observable outcome>.
  • Risk and evidence: the risk owned by this ticket and the chosen test level.
  • Observation seam: the approved public interface used by the test.
  • Boundary fidelity: which relevant dependencies are real or replaced.
  • Meaningful red: the false observation at the starting revision or after reversing the change, or alternate evidence when direct red is impractical.
  • Success evidence: the observable result that proves the ticket complete.
  • Residual risk: relevant behavior or infrastructure this ticket does not exercise.
Acceptance criteria and success evidence must be false before this ticket, become true because of this ticket, and remain owned by this ticket rather than one of its blockers.
For a behavior-preserving prefactor or refactor, replace artificial red evidence with the existing green baseline and any necessary characterization evidence. Do not invent a failing behavior test when observable behavior must remain unchanged.
<verification-contract-example>
  • Protected behavior: When the same payment event is delivered twice, the system records one charge.
  • Risk and evidence: Transactional idempotency; integration test with the real managed database.
  • Observation seam: Public event-handling operation, followed by a fresh durable read because persistence is the protected risk.
  • Boundary fidelity: Real application and database; external payment provider replaced at the owned adapter.
  • Meaningful red: Reversing the idempotency guard creates a second durable charge.
  • Success evidence: Two deliveries complete with one durable charge.
  • Residual risk: Provider protocol compatibility is covered separately.
</verification-contract-example>
为每个涉及行为变更的工单添加简洁的
## Verification contract
：
  • 受保护行为：
    当<可观测场景>时，系统<可观测结果>。
  • 风险与证据：本工单负责管控的风险及选定的测试级别。
  • 观测接口：测试使用的已获批公共接口。
  • 边界保真度：相关依赖项是保留真实实例还是使用替代方案。
  • 有意义的失败验证：初始版本或回滚变更时的错误观测结果；若直接触发失败不可行，则提供替代证据。
  • 成功证据：可证明工单完成的可观测结果。
  • 剩余风险：本工单未覆盖的相关行为或基础设施。
验收标准及成功证据在工单启动前应为不成立状态，因本工单的实施变为成立状态，且归属于本工单，而非其前置依赖工单。
对于不改变行为的重构或预优化工作，将人为失败证据替换为现有正常基线及必要的特征化证据。当可观测行为必须保持不变时，请勿虚构失败的行为测试。
<verification-contract-example>
  • 受保护行为：当同一支付事件被送达两次时，系统仅记录一次扣费。
  • 风险与证据：事务幂等性；使用真实托管数据库的集成测试。
  • 观测接口：公共事件处理操作，随后执行全新的持久化读取（因持久化是需保护的风险点）。
  • 边界保真度：保留真实应用及数据库；外部支付提供商在自有适配器层被替换。
  • 有意义的失败验证：移除幂等性防护后，会产生第二次持久化扣费记录。
  • 成功证据：两次事件送达完成后，仅存在一条持久化扣费记录。
  • 剩余风险：提供商协议兼容性由其他环节负责。
</verification-contract-example>

Apply the Contract by Phase

按阶段应用契约

With 
to-spec

搭配
to-spec
使用

  • Inspect repository seams, prior test art, and relevant architecture decisions before proposing the contract.
  • Ask the user to approve materially new seams, as the active skill requires.
  • Observe behavior through the highest stable public interface while choosing the narrowest test boundary that still contains each protected risk.
  • Record distinct evidence for domain rules, managed dependencies, external compatibility, and deployed journeys only when each protects a distinct risk.
  • 在提出契约前，检查仓库接口、既有测试实践及相关架构决策。
  • 如涉及实质性新接口，需按核心技能要求请求用户批准。
  • 选择能涵盖各受保护风险的最窄测试边界，同时通过最高级别的稳定公共接口观测行为。
  • 仅当领域规则、托管依赖、外部兼容性及部署流程各自对应独特风险时，才分别记录相关证据。

With 
to-tickets

搭配
to-tickets
使用

  • Consume the specification contract without redesigning it during decomposition.
  • Make every vertical slice own the verification needed for the behavior it introduces.
  • Keep test infrastructure with the first slice that needs it unless the infrastructure is independently valuable and verifiable.
  • Allow several focused tests when they protect distinct risks. A vertical product slice does not require one end-to-end test or one test at every layer.
  • Verify that every acceptance criterion belongs to the ticket and is false at its starting revision before publishing.
  • Keep observable completion in acceptance criteria and test mechanics in the verification contract. Do not duplicate every contract field as an acceptance criterion.
  • 直接沿用规格契约，分解过程中无需重新设计。
  • 每个垂直切片需负责其引入行为所需的验证工作。
  • 测试基础设施随首个需要它的切片一同交付，除非该基础设施具备独立价值且可验证。
  • 若需保护不同风险，可设置多个聚焦的测试。垂直产品切片无需强制设置一个端到端测试或每层一个测试。
  • 发布前需验证：每个验收标准归属于对应工单，且在工单启动前为不成立状态。
  • 验收标准聚焦可观测的完成状态，测试机制记录在验证契约中。请勿将契约的每个字段都重复为验收标准。

With 
implement
or 
tdd

搭配
implement
或
tdd
使用

  • Treat the ticket contract as the implementation boundary; rediscover exact files, APIs, and commands from the current repository.
  • Let the active TDD workflow own red-green sequencing. Use 
    design-high-value-tests
    to decide what evidence is worth retaining.
  • Demonstrate meaningful red for behavior changes, then implement the smallest coherent slice and run broader affected verification before completion.
  • Follow the active workflow's refactoring stage while applying the high-value test quality gate before handoff.
  • Escalate a required seam, level, or fidelity change when it materially alters approved evidence; record the approved change in the ticket or specification.
  • 将工单契约作为实现边界；从当前仓库重新探索具体的文件、API及命令。
  • 由当前TDD工作流掌控红-绿测试序列。使用
    design-high-value-tests
    技能判断哪些证据值得保留。
  • 针对行为变更展示有意义的失败验证，然后实现最小的连贯切片，完成前运行更全面的关联验证。
  • 遵循当前工作流的重构阶段，交接前应用高价值测试质量 gate。
  • 若接口、级别或保真度的变更会实质性改变已获批证据，需升级处理；并在工单或规格中记录获批的变更。

With 
code-review

搭配
code-review
使用

  • Preserve the review skill's separate Standards and Spec axes.
  • Pass the relevant verification contract and checks into the owning sub-agent brief; do not assume a sub-agent can infer omitted context.
  • Under Standards, evaluate retained tests for regression protection, refactoring resistance, feedback speed, maintainability, and adherence to repository conventions.
  • Under Spec, verify that each promised behavior and verification contract is fulfilled without unrequested test layers or scope.
  • Report missing evidence and inaccurate residual-risk claims within the owning axis. Do not add a third axis or rerank the review skill's findings.
  • 保留评审技能独立的标准轴与规格轴。
  • 将相关验证契约及检查内容传递给对应的子Agent简报；请勿假设子Agent能自行推断遗漏的上下文。
  • 在标准轴下，评估保留的测试是否具备回归防护能力、抗重构能力、反馈速度、可维护性，以及是否符合仓库约定。
  • 在规格轴下，验证每个承诺的行为及验证契约是否已满足，且无额外的未请求测试层或范围。
  • 在对应轴下报告缺失的证据及不准确的剩余风险声明。请勿新增第三轴或重新排序评审技能的发现结果。

Resolve Common Overlaps

解决常见重叠问题

  • Highest seam versus narrowest level: use the highest stable public interface that expresses the behavior, at the narrowest execution boundary that includes the relevant risk.
  • Public observation versus durable inspection: prefer a public retrieval operation for consumer behavior. Use a fresh direct persistence read only in a scoped integration test when durable mapping, transactions, or constraints are themselves the protected risk.
  • Vertical delivery versus test duplication: make the ticket end-to-end in delivered behavior, not in test topology. Assign each risk to the cheapest sufficient evidence instead of repeating an assertion at every level.
  • Workflow order versus test quality: let the active phase skill decide when activities occur; let 
    design-high-value-tests
    decide whether the resulting evidence is valuable.
  • 最高级接口与最窄测试级别：使用能表达行为的最高级别稳定公共接口，同时选择涵盖相关风险的最窄执行边界。
  • 公共观测与持久化检查：优先使用公共检索操作验证消费者行为。仅当持久化映射、事务或约束本身是受保护风险时，才在限定的集成测试中使用全新的直接持久化读取。
  • 垂直交付与测试重复：工单需覆盖交付行为的端到端范围，但无需统一测试拓扑。为每个风险分配成本最低的充足证据，而非在每个层级重复断言。
  • 工作流顺序与测试质量：由当前阶段的核心技能决定活动顺序；由
    design-high-value-tests
    技能判断最终证据是否具备价值。

Hand Off Explicitly

明确交接

At the end of the active phase, report only what the next fresh context needs:
  • the verification contract created, followed, or changed;
  • the evidence for any approved deviation;
  • verification commands and results, when commands were actually run;
  • dependencies or environments not exercised;
  • residual risks and their owner or intended test level.
Name the next appropriate user-invoked phase without starting it automatically.
当前阶段结束时，仅报告下一全新上下文所需的内容：
  • 创建、遵循或变更的验证契约；
  • 任何获批偏差的证据；
  • 实际执行的验证命令及结果；
  • 未覆盖的依赖项或环境；
  • 剩余风险及其负责人或计划测试级别。
指明下一合适的用户调用阶段，但请勿自动启动该阶段。