ai-dev-requirements 0.3.0 → 0.3.1

package/skills/dev-workflow/references/requirement-validation.md

@@ -1,114 +1,154 @@
-# 需求符合性校验规范
+# Requirement Coverage Validation
+
+> Validate the current implementation plan against approved user stories before requesting plan approval or starting implementation.
+
+## Gate Position
+
+```text
+Approved User Stories
+        |
+        v
+Implementation Plan
+        |
+        v
+Coverage Validation
+        |
+        +---- Conditional or Fail ----> revise and revalidate
+        |
+        v
+Plan Approval
+        |
+        v
+Implementation
+```
 
-> 在技术设计完成后、代码实现前，逐条校验设计方案是否完整覆盖产品需求。
+Coverage validation always runs. A passing report unlocks the plan-approval prompt; it does not itself authorize implementation.
 
----
+## Inputs
 
-## 校验时机
+| Input | Requirement |
+|-------|-------------|
+| Source context | Usable source or sanitized source summary with decisions and assumptions |
+| User stories | Current Gate 1-approved `user-stories.md` revision |
+| Harness plan | Current `implementation-plan.md` revision |
+| Repository evidence | Relevant architecture, tests, conventions, and available deterministic checks |
 
-```
-③ 技术设计 → ④ 技能匹配 → ⑤ 最佳实践 → 【⑥ 需求符合性校验】 → ⑦ 代码实现
+If the user stories are not approved or the plan is stale, stop before validation.
+
+## Step 1: Build The Traceability Matrix
+
+Map each requirement to a story, harness task, and verification gate:
+
+```markdown
+| Requirement | User Story | Harness Task | Verification Gate | Status |
+|-------------|------------|--------------|-------------------|--------|
+| R1 | US-1 | HT-DEV-1 | Targeted test and typecheck | Covered |
+| R2 | US-2 | HT-DEV-2, HT-TEST-1 | Integration test | Covered |
+| R3 | None | None | None | Missing |
 ```
 
-校验通过后方可进入代码实现阶段。校验不通过则回退到技术设计阶段修正。
+Use anonymized requirement labels in persisted artifacts. Do not reproduce private source text merely to populate the matrix.
 
-## 校验输入
+## Step 2: Evaluate Every Requirement
 
-| 输入 | 来源 |
-|------|------|
-| 原始需求 | `requirements.md` |
-| 用户故事 + 验收标准 | `user-stories.md` |
-| 技术设计方案 | `design.md` |
-| 任务列表 | `tasks.md` |
+Check:
 
-## 校验流程
+| Check | Passing Condition |
+|-------|-------------------|
+| Story coverage | Every core requirement maps to at least one approved user story |
+| Acceptance criteria | Behavior is observable and includes relevant failure or boundary cases |
+| Task coverage | Every acceptance criterion has an implementation, documentation, data, research, or verification owner |
+| Mutation boundary | Each write task declares the files, modules, or external systems it may change |
+| Dependency order | Every prerequisite appears before the task that depends on it |
+| Verification coverage | Every user-visible behavior and critical contract has a deterministic check or explicit review gate |
+| Review coverage | Risk determines an appropriate light, standard, or strict review level |
+| Privacy and safety | No plan artifact requires credentials, full private source bodies, or undeclared mutations |
 
-### Step 1: 构建需求追踪矩阵
+## Step 3: Run Coverage Sensors
 
-逐条提取需求点，建立需求 → 用户故事 → 设计 → 任务的映射关系：
+Use all applicable sensor classes:
 
-```markdown
-| # | 需求点 | 用户故事 | 设计章节 | 实现任务 | 状态 |
-|---|--------|---------|---------|---------|------|
-| R1 | 用户可通过手机号登录 | US-1 | 3.1 认证模块 | Task-1, Task-2 | ✅ 覆盖 |
-| R2 | 登录失败锁定账户 | US-2 | 3.1 认证模块 | Task-3 | ✅ 覆盖 |
-| R3 | 支持第三方 OAuth | — | — | — | ❌ 未覆盖 |
-```
+| Sensor Class | Checks | Examples |
+|--------------|--------|----------|
+| Maintainability | Internal quality and supportability | lint, typecheck, duplication, complexity, documentation consistency |
+| Architecture | Structural and ownership boundaries | dependency direction, package exports, module ownership, public contracts |
+| Behavior | User-visible correctness | unit tests, integration tests, browser checks, acceptance checks |
+| Safety | Authorization and data handling | mutation confirmation, secrets, private-source retention, destructive actions |
+| Change resilience | Requirement and compatibility drift | version invalidation, migration, backward compatibility, stale task decomposition |
+
+When an existing task decomposition materially differs from the current requirement, classify it as a blocking mismatch and notify the developer. Do not silently implement the stale tasks.
+
+## Step 4: Classify The Result
 
-### Step 2: 逐项校验
+| Result | Condition | Next Action |
+|--------|-----------|-------------|
+| `Pass` | Every core requirement is covered and no blocking risk remains | Present the plan and report summary at Gate 2 |
+| `Conditional` | Only low-risk, explicitly described exceptions remain | Pause for a developer decision; update artifacts and revalidate |
+| `Fail` | A core requirement, decision, task, mutation boundary, or verification gate is missing | Return to the earliest affected phase |
 
-对每个需求点检查以下 5 项：
+Rules:
 
-| 校验项 | 说明 | 判定标准 |
-|--------|------|---------|
-| **故事覆盖** | 需求点是否有对应的用户故事 | 每个需求点至少映射到 1 个 US |
-| **验收标准完整** | 用户故事的 AC 是否可验证 | AC 使用 Given/When/Then，无模糊描述 |
-| **设计落地** | 设计方案是否包含该需求的技术实现 | design.md 中有对应章节或说明 |
-| **任务分解** | 是否有具体的实现任务 | tasks.md 中有对应的 task 条目 |
-| **边界覆盖** | 异常流、边界条件是否考虑 | AC 中包含异常场景或设计中有错误处理说明 |
+- Coverage percentage is informative, not authoritative.
+- A missing core requirement always fails.
+- A high-risk ambiguity always fails and returns to `/grill-me`.
+- An accepted low-risk exception must be recorded in the revised plan and report before revalidation.
+- Gate 2 may be requested only after the current report is `Pass`.
 
-### Step 3: 输出校验报告
+## Validation Report Contract
 
-生成 `validation-report.md`，保存到 `docs/plans/{feature-name}/` 目录：
+Write `docs/plans/{feature-name}/validation-report.md`:
 
 ```markdown
-# 需求符合性校验报告
-
-## 基本信息
-- 需求来源: [ONES/Jira/GitHub] #[ID]
-- 校验时间: [timestamp]
-- 校验结果: ✅ 通过 / ❌ 不通过
-
-## 追踪矩阵
-| # | 需求点 | US | 设计 | 任务 | 状态 |
-|---|--------|----|------|------|------|
-| R1 | ... | US-1 | §3.1 | T-1 | ✅ |
-
-## 覆盖统计
-- 需求总数: N
-- 已覆盖: X (X/N)
-- 未覆盖: Y
-- 部分覆盖: Z
-
-## 未覆盖项
-| # | 需求点 | 缺失环节 | 建议处理方式 |
-|---|--------|---------|------------|
-| R3 | 支持第三方 OAuth | 无用户故事、无设计 | 补充 US 和设计，或与产品确认是否本期实现 |
-
-## 风险项
-| # | 需求点 | 风险描述 | 建议 |
-|---|--------|---------|------|
-| R2 | 登录失败锁定 | AC 未定义锁定阈值和解锁方式 | 与产品确认具体规则 |
-
-## 结论
-[通过/不通过，及后续行动]
-```
+# Coverage Validation Report
+
+## Artifact Revisions
+
+- Stories revision: <revision>
+- Plan revision: <revision>
+- Result: Pass | Conditional | Fail
+
+## Traceability Matrix
+
+| Requirement | User Story | Harness Task | Verification Gate | Status |
+|-------------|------------|--------------|-------------------|--------|
+| R1 | US-1 | HT-DEV-1 | <gate> | Covered |
 
-## 校验判定规则
+## Sensor Results
 
-| 结果 | 条件 | 后续动作 |
-|------|------|---------|
-| ✅ 通过 | 所有需求点均已覆盖，无高风险项 | 进入 ⑦ 代码实现 |
-| ⚠️ 有条件通过 | 覆盖率 ≥ 90%，未覆盖项为低优先级且已标记 | 与开发者确认后进入实现，未覆盖项记入 backlog |
-| ❌ 不通过 | 存在未覆盖的核心需求，或高风险项未解决 | 回退到 ③ 技术设计，补充后重新校验 |
+| Sensor Class | Status | Evidence or Gap |
+|--------------|--------|-----------------|
+| Maintainability | Pass | <evidence> |
+| Architecture | Pass | <evidence> |
+| Behavior | Pass | <evidence> |
+| Safety | Pass | <evidence> |
+| Change resilience | Pass | <evidence> |
 
-## 暂停点
+## Exceptions And Risks
+
+- <accepted exception or none>
+
+## Gate Decision
+
+- Gate 2 eligible: Yes | No
+- Required next action: <action or none>
+```
 
-校验完成后 **必须暂停**，将校验报告呈现给开发者：
+The report references artifact revisions so a changed story or plan makes the result visibly stale.
 
-- 如果通过：展示摘要，确认后继续
-- 如果不通过：展示未覆盖项和风险项，等待开发者决策（补充设计 / 与产品沟通 / 标记为后续迭代）
+## Common Omissions
 
-## 常见遗漏模式
+| Area | Validation Question |
+|------|---------------------|
+| Authorization | Who may perform the action, and where is the check verified? |
+| Input validation | Are invalid, empty, oversized, and malformed inputs covered? |
+| Concurrency | Can retries or concurrent writes create duplication, races, or stale state? |
+| Performance | Is a measurable performance requirement mapped to an appropriate check? |
+| Compatibility | Does the plan preserve supported callers, formats, and runtime versions? |
+| Internationalization | Are locale behavior and fallback requirements explicit? |
+| Accessibility | Are keyboard, semantic, contrast, and assistive-technology needs covered? |
+| Requirement change | Do existing tasks and tests still match the current approved stories? |
+| Sensitive data | Could artifacts, fixtures, logs, or examples expose private source content? |
 
-以下是容易被忽略的需求类型，校验时需特别关注：
+## Invalidation
 
-| 类型 | 示例 |
-|------|------|
-| 权限控制 | "仅管理员可操作" — 是否有权限校验设计 |
-| 数据校验 | "手机号格式校验" — 前后端是否都有校验 |
-| 并发/竞态 | "库存扣减" — 是否考虑并发安全 |
-| 性能要求 | "列表页 1s 内加载" — 是否有分页/缓存设计 |
-| 兼容性 | "支持 IE11" — 是否影响技术选型 |
-| 国际化 | "支持中英文" — 是否有 i18n 方案 |
-| 无障碍 | "键盘可操作" — 是否有 a11y 设计 |
+The report becomes stale when any approved story, plan task, mutation boundary, dependency, verification gate, or accepted exception changes. Rerun validation before requesting or reusing Gate 2 approval.

package/skills/dev-workflow/references/service-transform.md

@@ -1,5 +1,9 @@
 # Service Layer Transform
 
+> Optional specialized reference. Load only when the approved plan must reconcile frontend Mock contracts with backend API contracts. This pattern is not a default harness phase and does not authorize implementation by itself.
+
+The current user stories, passing coverage report, approved plan, and repository conventions take precedence over this example.
+
 ## Problem
 
 Frontend uses Mock data during development. On integration, backend fields differ in three ways:
@@ -12,7 +16,7 @@ Frontend uses Mock data during development. On integration, backend fields diffe
 
 ## Solution: Transform in Service Layer
 
-**No separate `adapters/` directory.** Transform functions live inside service files. Components never change.
+When the consuming project uses this pattern, keep transform functions inside service files instead of creating a separate `adapters/` directory. Components consume the stable frontend contract.
 
 ```
 Component → FrontendType ← service function return type
@@ -36,7 +40,7 @@ src/api/{module}/
 ## Implementation Pattern
 
 ```typescript
-// ① Frontend type (component contract, never changes)
+// 1. Frontend type (component contract)
 export interface OrderInfo {
   orderId: string
   carrier: string
@@ -44,7 +48,7 @@ export interface OrderInfo {
   status: string
 }
 
-// ② Backend type (added during integration)
+// 2. Backend type (added during integration)
 interface BackendOrderInfo {
   order_id: string
   carrier_info: { code: string; name: string }
@@ -52,7 +56,7 @@ interface BackendOrderInfo {
   status: number       // numeric enum
 }
 
-// ③ Transform function
+// 3. Transform function
 const STATUS_MAP: Record<number, string> = {
   1: 'Pending', 2: 'Shipped', 3: 'Canceled',
 }
@@ -66,7 +70,7 @@ function transformOrder(raw: BackendOrderInfo): OrderInfo {
   }
 }
 
-// ④ Query: backend → frontend
+// 4. Query: backend to frontend
 export function getOrderList(query: PageParams) {
   return request<PageResponse<BackendOrderInfo>>({
     url: '/api/order/page',
@@ -77,7 +81,7 @@ export function getOrderList(query: PageParams) {
   }))
 }
 
-// ⑤ Submit: frontend → backend
+// 5. Submit: frontend to backend
 function toBackendParams(form: OrderForm): BackendOrderForm {
   return {
     order_id: form.orderId,
@@ -97,7 +101,7 @@ export function createOrder(form: OrderForm) {
 ## Integration Flow
 
 ```
-Backend ready → Add BackendType → Write transform → Add .then(transform) → Components unchanged ✅
+Backend ready -> Add BackendType -> Write transform -> Add `.then(transform)` -> Keep the component contract stable
 ```
 
 ## When Components Must Change

package/skills/dev-workflow/references/task-types.md

@@ -2,6 +2,8 @@
 
 Task types are scheduling primitives for the agent harness. They define how work may run, what isolation is required, and what review level applies before handoff.
 
+Task type does not grant permission to execute. Lifecycle stage, gate state, dependencies, and mutation boundary must all allow the task to run.
+
 ## Task Types
 
 | Type | ID | Scheduler | Review Level | Harness Use |
@@ -32,10 +34,12 @@ Default `parallel_limit`: 5.
 
 ### Control
 - type: code:dev | code:fix | code:refactor | doc:write | doc:translate | research | data | test
+- stage: discovery | planning | implementation | verification | handoff
 - agent_role: implementer | reviewer | researcher | tester | documenter
 - scheduler: parallel | isolated | serial
 - isolation_key: <module-or-file-path>
 - dependencies: []
+- required_gates: [] | [stories_approved] | [stories_approved, coverage_passed, plan_approved]
 - review_level: light | standard | strict
 - feedback_mode: quiet_success | actionable_failure
 - retry_limit: 2
@@ -57,14 +61,28 @@ Default `parallel_limit`: 5.
 | Field | Required | Meaning |
 |-------|:---:|---------|
 | `type` | Yes | Work category and default review expectation |
+| `stage` | Yes | Lifecycle phase in which the task is allowed to run |
 | `agent_role` | Yes | Primary role responsible for the task |
 | `scheduler` | Yes | Execution mode: `parallel`, `isolated`, or `serial` |
 | `isolation_key` | Yes for `isolated`, optional for others | Module, file, data source, or shared contract boundary |
 | `dependencies` | Yes | Task IDs that must finish first; use an empty list when none exist |
+| `required_gates` | Yes | Current approvals and validation states required before execution |
 | `review_level` | Yes | `light`, `standard`, or `strict` |
 | `feedback_mode` | Yes | How verification output is exposed to the agent |
 | `retry_limit` | Yes | Maximum repair attempts before human escalation |
 
+## Gate Preconditions
+
+| Task Stage | Default Required Gates | Mutation Rule |
+|------------|------------------------|---------------|
+| `discovery` | `[]` | Read-only fact gathering only; source mutations are forbidden |
+| `planning` | `[stories_approved]` | May write planning artifacts, not implementation artifacts |
+| `implementation` | `[stories_approved, coverage_passed, plan_approved]` | May mutate only the approved task boundary |
+| `verification` | `[stories_approved, coverage_passed, plan_approved]` | Test-file writes require plan authorization; check execution is read-only |
+| `handoff` | `[stories_approved, coverage_passed, plan_approved]` | May write only declared handoff artifacts |
+
+Gate state is revision-bound. If an upstream artifact changes, affected tasks return to blocked even when an older approval exists.
+
 ## Review Levels
 
 | Level | Applies To | Required Review |
@@ -92,17 +110,19 @@ Verification output should act as backpressure:
 
 ### Control
 - type: doc:write
+- stage: implementation
 - agent_role: documenter
 - scheduler: parallel
 - isolation_key: docs/readme
 - dependencies: []
+- required_gates: [stories_approved, coverage_passed, plan_approved]
 - review_level: light
 - feedback_mode: quiet_success | actionable_failure
 - retry_limit: 2
 
 ### Inputs
 - Requirement: US-DOC-1
-- Context: docs/plans/harness/requirements.md
+- Context: docs/plans/harness/user-stories.md
 
 ### Outputs
 - Artifact: README.md
@@ -119,10 +139,12 @@ Verification output should act as backpressure:
 
 ### Control
 - type: code:dev
+- stage: implementation
 - agent_role: implementer
 - scheduler: isolated
 - isolation_key: src/tools/search-requirements.ts
 - dependencies: [HT-PLAN-1]
+- required_gates: [stories_approved, coverage_passed, plan_approved]
 - review_level: strict
 - feedback_mode: quiet_success | actionable_failure
 - retry_limit: 2
@@ -146,10 +168,12 @@ Verification output should act as backpressure:
 
 ### Control
 - type: code:refactor
+- stage: implementation
 - agent_role: implementer
 - scheduler: serial
 - isolation_key: global
 - dependencies: [HT-COVERAGE-1]
+- required_gates: [stories_approved, coverage_passed, plan_approved]
 - review_level: strict
 - feedback_mode: quiet_success | actionable_failure
 - retry_limit: 2
@@ -168,6 +192,8 @@ Verification output should act as backpressure:
 
 ## Failure Handling
 
+- If a required gate is missing or stale, keep the task blocked and return to the earliest invalidated phase.
+- If execution requires a mutation outside the approved boundary, stop and revise the plan before writing.
 - If a `parallel` task conflicts with another task, stop both tasks and reclassify the boundary as `isolated`.
 - If an `isolated` task conflicts within the same key, serialize that key and continue other keys.
 - If a `serial` task fails, stop the harness and resolve the failure before scheduling more work.

package/skills/dev-workflow/references/templates/code-dev-task.md

@@ -4,10 +4,12 @@
 
 ### Control
 - type: code:dev
+- stage: implementation
 - agent_role: implementer
 - scheduler: isolated
 - isolation_key: src/<module>/
 - dependencies: []
+- required_gates: [stories_approved, coverage_passed, plan_approved]
 - review_level: strict
 - feedback_mode: quiet_success | actionable_failure
 - retry_limit: 2
@@ -18,6 +20,7 @@
 - Plan: docs/plans/<feature-name>/implementation-plan.md
 
 ### Steps
+- Confirm every required gate applies to the current story, plan, and validation revisions.
 - Write or update the failing test that captures the acceptance criterion.
 - Run the targeted test and record the failure.
 - Implement the smallest production change inside the isolation key.
@@ -37,6 +40,7 @@
 - Type safety: `pnpm typecheck`
 
 ### Done When
+- The task stayed inside the approved mutation boundary and used current gate approvals.
 - The user story acceptance criteria are covered by tests or explicit verification.
 - The implementation stays within the declared isolation key unless the plan is revised.
 - The targeted verification gate passes.

package/skills/dev-workflow/references/templates/code-fix-task.md

@@ -4,20 +4,23 @@
 
 ### Control
 - type: code:fix
+- stage: implementation
 - agent_role: implementer
 - scheduler: isolated
 - isolation_key: <file-or-module-path>
 - dependencies: []
+- required_gates: [stories_approved, coverage_passed, plan_approved]
 - review_level: standard
 - feedback_mode: quiet_success | actionable_failure
 - retry_limit: 2
 
 ### Inputs
 - Requirement: BUG-<number> or US-<number>
-- Failure Evidence: docs/plans/<feature-name>/requirements.md
-- Context: docs/plans/<feature-name>/execution-log.md
+- Failure Evidence: sanitized issue context or reproducible local evidence
+- Plan: docs/plans/<feature-name>/implementation-plan.md
 
 ### Steps
+- Confirm every required gate applies to the current story, plan, and validation revisions.
 - Reproduce or describe the failure from evidence.
 - Add a regression test that fails for the defect.
 - Make the smallest fix inside the isolation key.
@@ -37,6 +40,7 @@
 - Quality: `pnpm lint`
 
 ### Done When
+- The fix stayed inside the approved mutation boundary and used current gate approvals.
 - The original failure is covered by a regression test or explicit reproduction check.
 - The fix does not change unrelated behavior.
 - The regression gate passes.

package/skills/dev-workflow/references/templates/code-refactor-task.md

@@ -4,10 +4,12 @@
 
 ### Control
 - type: code:refactor
+- stage: implementation
 - agent_role: implementer
 - scheduler: serial
 - isolation_key: global
 - dependencies: []
+- required_gates: [stories_approved, coverage_passed, plan_approved]
 - review_level: strict
 - feedback_mode: quiet_success | actionable_failure
 - retry_limit: 2
@@ -18,6 +20,7 @@
 - Coverage: docs/plans/<feature-name>/validation-report.md
 
 ### Steps
+- Confirm every required gate applies to the current story, plan, and validation revisions.
 - Identify the public contracts that must remain stable.
 - Add or confirm tests around existing behavior before changing structure.
 - Refactor one bounded area at a time.
@@ -37,6 +40,7 @@
 - Build: `pnpm build`
 
 ### Done When
+- The refactor stayed inside the approved mutation boundary and used current gate approvals.
 - Public behavior and contracts are preserved or intentionally changed in the plan.
 - Full verification gates pass.
 - Strict review has no blocking findings.

package/skills/dev-workflow/references/templates/doc-write-task.md

@@ -4,20 +4,23 @@
 
 ### Control
 - type: doc:write
+- stage: implementation
 - agent_role: documenter
 - scheduler: parallel
 - isolation_key: docs/<artifact-name>
 - dependencies: []
+- required_gates: [stories_approved, coverage_passed, plan_approved]
 - review_level: light
 - feedback_mode: quiet_success | actionable_failure
 - retry_limit: 2
 
 ### Inputs
 - Requirement: US-DOC-<number>
-- Source Context: docs/plans/<feature-name>/requirements.md
+- Source Context: docs/plans/<feature-name>/user-stories.md
 - Plan Context: docs/plans/<feature-name>/implementation-plan.md
 
 ### Steps
+- Confirm every required gate applies to the current story, plan, and validation revisions.
 - Identify the audience and required artifact.
 - Update the target document using the repository's existing style.
 - Keep terminology consistent with related docs.
@@ -36,6 +39,7 @@
 - Repository Gate: `pnpm lint`
 
 ### Done When
+- The documentation stayed inside the approved mutation boundary and used current gate approvals.
 - The document accurately describes the implemented behavior or workflow.
 - Cross-references point to existing files.
 - Light review has no blocking findings.

package/skills/dev-workflow/references/templates/research-task.md

@@ -4,10 +4,12 @@
 
 ### Control
 - type: research
+- stage: discovery
 - agent_role: researcher
 - scheduler: parallel
 - isolation_key: research/<topic>
 - dependencies: []
+- required_gates: []
 - review_level: light
 - feedback_mode: quiet_success | actionable_failure
 - retry_limit: 2
@@ -18,6 +20,7 @@
 - Decision Needed: <specific decision>
 
 ### Steps
+- Keep the task read-only; discovery does not authorize source or external mutations.
 - Identify primary sources and repository-local evidence.
 - Gather only the context needed for the decision.
 - Compare viable options with tradeoffs.
@@ -37,6 +40,7 @@
 - Scope Check: recommendation answers the declared decision.
 
 ### Done When
+- No source, repository, or external system was mutated.
 - The decision can be used directly by the harness plan.
 - Unknowns and assumptions are explicit.
 - Light review has no blocking findings.

package/skills/dev-workflow/references/templates/test-task.md

@@ -4,10 +4,12 @@
 
 ### Control
 - type: test
+- stage: verification
 - agent_role: tester
 - scheduler: parallel
 - isolation_key: tests/<module>/
 - dependencies: []
+- required_gates: [stories_approved, coverage_passed, plan_approved]
 - review_level: standard
 - feedback_mode: quiet_success | actionable_failure
 - retry_limit: 2
@@ -18,6 +20,7 @@
 - Acceptance Criteria: docs/plans/<feature-name>/user-stories.md
 
 ### Steps
+- Confirm every required gate applies to the current story, plan, and validation revisions before writing tests.
 - Identify the behavior, edge case, or regression to verify.
 - Add the smallest test that proves the behavior.
 - Run the test and confirm it fails when the implementation is absent or broken when practical.
@@ -36,6 +39,7 @@
 - Broader Gate: `pnpm test:run`
 
 ### Done When
+- Test changes stayed inside the approved mutation boundary and used current gate approvals.
 - The test maps to an acceptance criterion or documented regression.
 - The targeted gate passes.
 - Standard review has no blocking findings.