universal-dev-standards 5.4.0 → 5.5.0

package/bundled/core/disaster-recovery-drill.md

@@ -0,0 +1,73 @@
+# Disaster Recovery Drill Standards
+
+## Overview
+
+An untested DR plan is a false sense of security. Teams that have never executed their recovery runbook under pressure will discover gaps at the worst possible time. DR drills expose these gaps safely.
+
+## RTO/RPO Targets
+
+Define these before writing the runbook:
+
+| Metric | Definition | VibeOps Commercial Target |
+|--------|-----------|--------------------------|
+| RTO (Recovery Time Objective) | Max acceptable downtime | < 1 hour |
+| RPO (Recovery Point Objective) | Max acceptable data loss | < 24 hours (daily backup) |
+
+## Backup Restore Script
+
+```bash
+#!/usr/bin/env bash
+# scripts/backup-restore.sh — DR drill backup restore verification
+set -euo pipefail
+
+BACKUP_DIR="${BACKUP_DIR:-/var/backups/vibeops}"
+RESTORE_DIR="${RESTORE_DIR:-/tmp/dr-restore}"
+DB_FILE="${DB_FILE:-vibeops.db}"
+
+echo "=== DR Drill: Backup Restore Verification ==="
+echo "Source: ${BACKUP_DIR}/${DB_FILE}.backup"
+echo "Target: ${RESTORE_DIR}/${DB_FILE}"
+
+mkdir -p "$RESTORE_DIR"
+
+# Find latest backup
+LATEST=$(ls -t "${BACKUP_DIR}"/*.backup 2>/dev/null | head -1)
+if [[ -z "$LATEST" ]]; then
+  echo "FAIL: No backup found in ${BACKUP_DIR}"
+  exit 1
+fi
+
+# Restore
+cp "$LATEST" "${RESTORE_DIR}/${DB_FILE}"
+
+# Verify integrity (SQLite)
+if command -v sqlite3 >/dev/null 2>&1; then
+  sqlite3 "${RESTORE_DIR}/${DB_FILE}" "PRAGMA integrity_check;" | grep -q "ok" && \
+    echo "OK: Database integrity check passed" || \
+    { echo "FAIL: Integrity check failed"; exit 1; }
+fi
+
+BACKUP_AGE=$(( ($(date +%s) - $(stat -c %Y "$LATEST" 2>/dev/null || stat -f %m "$LATEST")) / 3600 ))
+echo "OK: Backup age: ${BACKUP_AGE} hours (RPO target: 24h)"
+
+echo "=== PASS: Restore complete ==="
+```
+
+## Game Day Protocol
+
+1. **Announce**: Notify team 1 week in advance, define scope
+2. **Baseline**: Document current system state
+3. **Inject**: Simulate failure (rename/delete DB, kill process, etc.)
+4. **Execute**: Team follows runbook from scratch — no shortcuts
+5. **Measure**: Record RTO, RPO, issues encountered
+6. **Retrospective**: What was unclear? What was missing?
+
+## Runbook Template
+
+See `docs/DR-RUNBOOK.md` for the full runbook template.
+
+## Related Standards
+
+- [Deployment Standards](deployment-standards.md) — deployment pipeline
+- [Chaos Engineering Standards](chaos-engineering-standards.md) — failure injection
+- [Verification Evidence Standards](verification-evidence.md) — drill records

package/bundled/core/flaky-test-management.md

@@ -0,0 +1,73 @@
+# Flaky Test Management Standards
+
+## Overview
+
+A single flaky test in a 3000-test suite can erode CI confidence enough that developers start ignoring failures. Once developers learn to "just re-run CI", real bugs slip through. The cost of eliminating flaky tests is always lower than the cost of the false sense of security they create.
+
+## Definition
+
+A test is **flaky** if it produces different results (pass/fail) on consecutive runs with the same code. The 2% threshold: if a test fails ≥ 2% of runs on `main` without code changes, it is flaky.
+
+## Detection
+
+Most CI systems can detect flakiness automatically:
+
+- **GitHub Actions**: Look for `Flaky tests detected` annotations
+- **Manual**: Run `npx vitest run --reporter=verbose` 5 times, look for non-deterministic results
+- **Vitest**: `vitest run --repeat=5` (runs each test 5 times)
+
+## Quarantine Workflow
+
+```
+Detected → Quarantine (< 48h) → Track → Fix or Delete (< 30 days)
+```
+
+### Quarantine Annotation
+
+```typescript
+// TODO: quarantined 2026-05-05 — flaky race condition, see issue #42
+it.skip("reconnects after WebSocket disconnect", async () => {
+  // ... test body preserved for reference
+})
+```
+
+### Tracking Issue Template
+
+```markdown
+**Flaky Test**: `describe > test name`
+**File**: `src/path/to/test.ts`
+**Quarantined**: 2026-05-05
+**Failure rate**: ~5% on main
+**Known failure mode**: `Cannot read property 'socket' of undefined`
+**Root cause hypothesis**: Race condition in WebSocket teardown
+**Deadline**: 2026-06-05
+```
+
+## Common Root Causes
+
+| Root Cause | Fix |
+|-----------|-----|
+| Race condition | Use `waitFor()`, `vi.waitFor()`, proper async coordination |
+| Shared state | Reset state in `beforeEach`/`afterEach` |
+| External service | Mock the dependency |
+| File system ordering | Use deterministic sort |
+| Random without seed | Set fixed seed in test |
+| Timing-dependent | Fake timers (`vi.useFakeTimers()`) |
+
+## Vitest Configuration
+
+```typescript
+// vitest.config.ts
+export default defineConfig({
+  test: {
+    retry: 2,              // retry failed tests up to 2 times
+    testTimeout: 10000,    // 10s timeout prevents infinite hangs
+    hookTimeout: 5000,     // 5s hook timeout
+  }
+})
+```
+
+## Related Standards
+
+- [Testing Standards](testing.md) — overall test pyramid
+- [Test Governance Standards](test-governance.md) — CI policies

package/bundled/core/flow-based-testing.md

@@ -0,0 +1,142 @@
+# Flow-Based Testing
+
+**Version**: 1.0.0
+**Last Updated**: 2026-05-04
+**Applicability**: All software projects with multi-step workflows
+**Scope**: universal
+**Industry Standards**: ISO/IEC/IEEE 29119-4 (Test Techniques), ISTQB Foundation Syllabus
+**References**: Decision Table Testing (ISTQB), Pairwise Testing, State Transition Testing
+
+[English](.) | [繁體中文](../locales/zh-TW/core/flow-based-testing.md)
+
+---
+
+## Purpose
+
+This document defines a systematic methodology for testing multi-step processes. It addresses the gap between AC-centric tests (which verify individual behaviors in isolation) and flow-level tests (which verify sequential behavior with accumulated state and branch coverage).
+
+---
+
+## The Core Problem: AC-Centric vs. Flow-Centric Testing
+
+AC-centric tests verify that each acceptance criterion works in isolation. However, they miss two critical categories of bugs:
+
+1. **Step interaction bugs**: A bug that only manifests when Step 1's output becomes Step 2's input
+2. **Branch coverage gaps**: Decision points that are never exercised with all possible values
+
+**Example**: A pipeline has 8 steps. Each AC passes independently. But when the quota check in Step 3 depends on state accumulated in Steps 1 and 2, the interaction is never tested.
+
+---
+
+## Three-Step Flow Decomposition
+
+### Step 1: Flow Identification
+
+Before writing any test code, document:
+
+- **Preconditions**: The system's initial state
+- **Step sequence**: The ordered list of actions (Step 1 → Step N)
+- **Decision points**: Every if/else/condition in the flow
+- **Terminal states**: All possible end states (success + each distinct failure)
+
+### Step 2: Decision Table Expansion
+
+For each decision point, list all possible values. Then apply a coverage strategy:
+
+| Strategy | When to Use | Scenario Count |
+|----------|-------------|---------------|
+| **Each-Choice** (minimum) | Low-risk flows, fast feedback | Sum of unique values |
+| **Pairwise** | Medium-risk flows | ~N × max_values |
+| **All-Combinations** | Auth, payment, security | Product of value counts |
+
+**Decision Table Example**:
+
+| Decision Point | Values |
+|----------------|--------|
+| Authorization | valid / expired / missing |
+| Quota | sufficient / exceeded |
+| External Service | available / timeout / error |
+
+Each-Choice minimum: 3 + 2 + 3 = 8 scenarios (vs. the typical 1-2 that teams actually write).
+
+### Step 3: Journey Test Structure
+
+Write tests with shared state threading — a `ctx` object accumulates state across steps:
+
+```typescript
+describe("Flow: Create Order", () => {
+  const ctx: { token?: string; orderId?: string } = {}
+
+  it("Step 1: Login", async () => {
+    ctx.token = await login(credentials)
+    expect(ctx.token).toBeTruthy()
+  })
+
+  it("Step 2: Create order (uses Step 1 token)", async () => {
+    ctx.orderId = await createOrder(ctx.token!, orderData)
+    expect(ctx.orderId).toMatch(/^ord-/)
+  })
+
+  it("Step 3: Verify order state (uses Step 2 orderId)", async () => {
+    const order = await getOrder(ctx.token!, ctx.orderId!)
+    expect(order.status).toBe("pending")
+  })
+})
+
+describe("Flow Branch: Quota exceeded path", () => {
+  it("should return 429 and NOT create order when quota is exhausted", async () => {
+    await exhaustQuota(testUser)
+    const response = await attemptCreateOrder(testToken, orderData)
+    expect(response.status).toBe(429)
+    expect(response.body.code).toBe("QUOTA_EXCEEDED")
+    // Verify side effects: no order was created
+    const orders = await getOrders(testUser)
+    expect(orders.length).toBe(0)
+  })
+})
+```
+
+---
+
+## Anti-Patterns
+
+- Testing only the happy path flow (missing failure terminal states)
+- Resetting shared state between steps (breaks state threading)
+- Testing each step in isolation without verifying accumulated state
+- Using a single test for a flow with multiple decision points
+- Applying All-Combinations to every flow (reserve for critical paths only)
+- Not verifying side effects (or absence thereof) in branch tests
+
+---
+
+## Relationship to Other Standards
+
+- **test-completeness-dimensions**: Dimensions 9 (Flow Completeness) and 10 (Branch Coverage) are defined here
+- **behavior-driven-development**: BDD Scenario Outline tables map to decision table expansion
+- **mock-boundary**: Flow tests must respect mock boundary rules (no mocking own module logic)
+- **e2e-testing**: Journey tests run at ST or E2E level; flow tests can run at IT level with real DB
+
+---
+
+## Quick Reference Checklist
+
+```
+Flow: ___________________
+
+□ Step 1 — Flow Identification
+  □ Preconditions documented
+  □ Ordered step sequence listed
+  □ All decision points extracted
+  □ All terminal states defined
+
+□ Step 2 — Decision Table
+  □ Decision table created
+  □ Coverage strategy chosen (Each-Choice / Pairwise / All-Combinations)
+  □ Critical flows (auth/payment/security) → All-Combinations
+
+□ Step 3 — Journey Test Structure
+  □ Happy path journey test (shared ctx, sequential steps)
+  □ Each branch outcome has its own describe block
+  □ Branch tests verify both response AND absence of side effects
+  □ No beforeEach resetting ctx between steps
+```

package/bundled/core/llm-output-validation.md

@@ -0,0 +1,178 @@
+# LLM 輸出驗證標準
+
+> 標準 ID：`llm-output-validation`
+> 版本：v1.0.0
+> 最後更新：2026-05-05
+
+---
+
+## 為什麼需要 LLM 輸出驗證？
+
+LLM 輸出具有**不確定性**：同一個 prompt 在不同時間、不同模型版本下可能產生格式不一致的輸出。如果不加以驗證，這些輸出可能在下游管線中造成靜默失敗（silent failure）——不是報錯，而是用了一個錯誤的預設值或 `undefined`。
+
+LLM 輸出驗證包含三個層次：
+
+| 層次 | 問題 | 工具 |
+|------|------|------|
+| 結構驗證 | 輸出格式是否正確？ | JSON Schema、Zod、Pydantic |
+| 語意驗證 | 宣稱的事實是否有根據？ | NLI probe、Grounding check |
+| 行為驗證 | Agent 是否正確拒絕越界請求？ | 紅隊語料庫、拒絕評估 |
+
+---
+
+## 一、Schema Contract Test（結構驗證）
+
+### 核心概念
+
+每個 AI Agent 應宣告一份 `output-schema.json`（JSON Schema 格式），並提供對應的 contract test。
+
+**Contract test 的目的**：
+- 確認 schema 本身是合法的 JSON Schema
+- 確認 valid fixtures 通過驗證
+- 確認 invalid fixtures（缺少必填欄位、型別錯誤、enum 違規）被拒絕
+
+### 推薦目錄結構
+
+```
+agents/<agent-name>/
+  output-schema.json       ← JSON Schema 定義
+  __tests__/
+    contract.test.ts       ← Contract test suite
+  __fixtures__/
+    valid.json             ← 真實 LLM 輸出 golden fixture
+    invalid-missing-id.json ← 缺少必填欄位的 fixture
+```
+
+### TypeScript 範例（使用 Ajv）
+
+```typescript
+import Ajv from "ajv"
+import schema from "../output-schema.json"
+import validFixture from "../__fixtures__/valid.json"
+
+const ajv = new Ajv({ strict: false })
+const validate = ajv.compile(schema)
+
+// 測試 1：Schema 本身是合法的 JSON Schema
+it("schema is valid JSON Schema", () => {
+  expect(ajv.validateSchema(schema)).toBe(true)
+})
+
+// 測試 2：Valid fixture 通過驗證
+it("valid fixture passes schema", () => {
+  expect(validate(validFixture)).toBe(true)
+})
+
+// 測試 3：空 object 被拒絕
+it("empty object is rejected", () => {
+  expect(validate({})).toBe(false)
+})
+
+// 測試 4：缺少 source_agent 被拒絕
+it("object missing source_agent is rejected", () => {
+  const { source_agent, ...without } = validFixture
+  expect(validate(without)).toBe(false)
+})
+```
+
+### Python 範例（使用 Pydantic）
+
+```python
+from pydantic import ValidationError
+from your_module import AgentOutput
+
+# 測試 valid fixture
+valid_data = { "version": "1.0.0", "source_agent": "planner", ... }
+output = AgentOutput(**valid_data)  # 不拋出 exception
+
+# 測試 invalid fixture
+try:
+    AgentOutput(version="bad-format", source_agent="planner")
+    assert False, "Should have raised"
+except ValidationError:
+    pass  # 預期行為
+```
+
+---
+
+## 二、幻覺偵測（Semantic Validation）
+
+### 什麼是幻覺？
+
+LLM 產生「聽起來正確但實際上沒有根據」的內容。例如：
+- 虛構的 API 文件 URL
+- 不存在的資料庫欄位名稱
+- 未在 context 中出現的 dependency 版本
+
+### 偵測策略
+
+| 策略 | 適用場景 | 自動化程度 |
+|------|---------|-----------|
+| **Schema 結構化輸出** | Agent 輸出 JSON，enum 限制可能值 | 高（自動） |
+| **Grounding Check** | RAG 系統，回答需引用 context | 中（需 NLI 模型） |
+| **信心度標記** | Agent 在輸出中包含 `confidence` 分數 | 中（需 prompt 設計） |
+| **紅隊語料庫** | 主動測試越界請求的拒絕行為 | 高（自動） |
+
+### 幻覺率目標
+
+| Agent 類型 | Schema 合規率 | 事實幻覺率 |
+|-----------|-------------|----------|
+| 結構化 JSON Agent | ≥ 99% | ≤ 5% |
+| RAG Agent | ≥ 95% | ≤ 5% |
+| 對話 Agent | ≥ 90% | ≤ 10% |
+
+---
+
+## 三、Prompt 回歸測試
+
+### 何時需要跑 Prompt 回歸測試？
+
+- 修改任何 `agents/*/prompt.md`
+- 模型版本升級（相同 prompt，不同 model）
+- Schema 新增 required field
+
+### 回歸測試流程
+
+```bash
+# 1. 修改前：用 temperature=0 記錄 golden output
+vibeops run planner --input fixtures/planner-input.json --temp 0 > golden.json
+
+# 2. 修改後：重跑並比對
+vibeops run planner --input fixtures/planner-input.json --temp 0 > after.json
+
+# 3. 用 contract test 驗證 after.json 仍符合 schema
+npx vitest run agents/__tests__/contract.test.ts
+```
+
+---
+
+## 四、品質閘門（Quality Gates）
+
+| 閘門 | 閾值 | 強制程度 |
+|------|------|---------|
+| Schema 合規（CI） | 100% | Block merge |
+| 空 object 拒絕（CI）| 100% | Block merge |
+| Prompt 修改後回歸（CI）| schema 合規維持 | Block merge |
+| 幻覺率（pre-release）| ≤ 5% | Advisory |
+
+---
+
+## 五、工具推薦
+
+| 工具 | 語言 | 用途 |
+|------|------|------|
+| [Ajv](https://ajv.js.org/) | TypeScript/JS | JSON Schema contract test |
+| [Zod](https://zod.dev/) | TypeScript | Runtime type validation |
+| [Pydantic](https://docs.pydantic.dev/) | Python | Schema + type validation |
+| [DeepEval](https://deepeval.com/) | Python | LLM 幻覺率、faithfulness 評分 |
+| [Ragas](https://docs.ragas.io/) | Python | RAG grounded answer rate |
+
+---
+
+## 參考標準
+
+- NIST AI RMF (AI 100-1, 2023) — AI 風險管理框架
+- OWASP Top 10 for LLM Applications v1.1 — LLM01: Prompt Injection
+- ISO/IEC 42001:2023 — AI 管理系統
+- [UDS `security-testing.ai.yaml`](./security-testing.md) — SAST + DAST 整合
+- [UDS `adversarial-test.ai.yaml`](./adversarial-test.md) — Prompt injection 紅隊標準

package/bundled/core/mock-boundary.md

@@ -0,0 +1,100 @@
+# Mock Boundary Standards
+
+**Version**: 1.0.0
+**Last Updated**: 2026-05-04
+**Applicability**: All software projects with unit and integration tests
+**Scope**: universal
+**Industry Standards**: ISTQB Foundation (Test Doubles), xUnit Patterns (Gerard Meszaros)
+**References**: "Working Effectively with Legacy Code" (Feathers), "Growing Object-Oriented Software" (Freeman & Pryce)
+
+[English](.) | [繁體中文](../locales/zh-TW/core/mock-boundary.md)
+
+---
+
+## Purpose
+
+This document defines rules for what can and cannot be mocked in tests. Its goal is to prevent **hollow tests** — tests that always pass but fail to detect real bugs because they replace the system's logic with stubs.
+
+---
+
+## The Hollow Test Problem
+
+A hollow test mocks so much of the system that the test becomes a specification of mock wiring rather than system behavior. The classic symptom: you can delete the implementation file and the test still passes.
+
+**Real example (VibeOps SPEC-002.test.ts)**:
+
+```typescript
+vi.mock('../../src/runner/agent-runner.js')      // Core logic replaced
+vi.mock('../../src/runner/guardian-hooks.js')     // Core logic replaced
+vi.mock('../../src/runner/prototyper.js')         // Core logic replaced
+vi.mock('../../src/runner/iteration-report.js')   // Core logic replaced
+vi.mock('../../src/memory/memory-store.js')       // Core logic replaced
+vi.mock('node:fs/promises', ...)                  // I/O replaced
+
+// All assertions verify mock call counts — not actual outputs.
+// runPipeline() touches zero real code.
+```
+
+---
+
+## What You CAN Mock
+
+| Category | Examples | Reason |
+|----------|----------|--------|
+| External HTTP services | LLM APIs, payment gateways, email services | Prevents flaky tests; controls response scenarios |
+| Time functions | `Date.now()`, `new Date()`, `setTimeout` | Makes tests deterministic |
+| Environment variables | `process.env.NODE_ENV`, `process.env.LICENSE_KEY` | Enables config variation |
+| File system (unit tests only) | `fs.readFile`, `fs.writeFile` | Avoids I/O in fast unit tests |
+| Cross-module boundaries (with IT counterpart) | Other modules' public APIs | Isolates unit under test |
+
+---
+
+## What You CANNOT Mock
+
+| Category | Example Violation | Why Forbidden |
+|----------|-------------------|---------------|
+| Own module's core logic | `vi.mock('./pipeline-runner.js')` in pipeline-runner tests | Makes the test a no-op |
+| Database in IT/flow/E2E tests | `vi.mock('./db/client.js')` in integration tests | Hides query bugs, schema issues |
+| HTTP framework internals | `vi.mock('express')` | Real routing may be broken |
+| Security controls | Always-pass auth middleware stub | Security regressions invisible |
+
+---
+
+## Hollow Test Detection
+
+Before submitting a test file, check:
+
+1. **Mock count ≥ import count** → Review: at least one assertion must verify actual output
+2. **All assertions are `.toHaveBeenCalled()` variants** → Add output-value assertions
+3. **Mock path matches test subject directory** → Self-referential mock; remove it
+4. **More mock setup lines than assertion lines** → Likely hollow
+
+---
+
+## Anti-Patterns
+
+- **Total Mock Isolation**: Every import mocked; only mock interactions asserted
+- **Mock the World**: External + internal + DB + FS all mocked in one test
+- **Orphan Mock**: Cross-module mock with no integration test counterpart
+- **Security Bypass Mock**: Auth/permission logic replaced with pass-through stub
+- **Database Mock Cascade**: DB returns hardcoded data, hiding real query errors
+
+---
+
+## Rules Summary
+
+| Rule | Trigger | Action |
+|------|---------|--------|
+| No self-mock | Test file mocks its own module | Remove mock; let real code run |
+| Real DB in IT/flow | Writing IT or flow test | Use in-memory SQLite or test schema |
+| IT counterpart | Mocking cross-module boundary | Ensure corresponding IT exists |
+| No security mock | Test involves auth/permissions | Use real test user + real token |
+| Hollow review | Mock count ≥ import count | Add output-value assertion |
+
+---
+
+## Relationship to Other Standards
+
+- **testing**: Mock boundary rules apply to all test levels in the testing pyramid
+- **test-completeness-dimensions**: Dimension 8 (AI Test Quality) references these rules
+- **flow-based-testing**: Flow tests must follow mock boundary rules

package/bundled/core/mutation-testing.md

@@ -0,0 +1,97 @@
+# Mutation Testing Standards
+
+**Version**: 1.0.0
+**Last Updated**: 2026-05-04
+**Applicability**: All software projects with unit/integration tests
+**Scope**: universal
+**Industry Standards**: ISTQB Foundation Syllabus (test effectiveness metrics)
+**References**: "Introduction to Software Testing" (Ammann & Offutt), Stryker Mutator docs
+
+[English](.) | [繁體中文](../locales/zh-TW/core/mutation-testing.md)
+
+---
+
+## Purpose
+
+Mutation testing evaluates test suite effectiveness by injecting artificial bugs and checking whether tests detect them. It answers the question that line coverage cannot: **"Do my tests actually verify correct behavior?"**
+
+---
+
+## Key Concept: Mutation Score
+
+```
+Mutation Score = Killed Mutants / (Killed + Survived) × 100%
+```
+
+- **Killed**: Test suite detected the artificial bug (test failed) ✅
+- **Survived**: Test suite missed the bug (tests still pass) ❌
+
+A test with `expect(x).toBeDefined()` can achieve 100% line coverage but survive many mutations (because `x` being `null`, `0`, or `"wrong"` all satisfy `.toBeDefined()`).
+
+---
+
+## Tools
+
+| Language | Tool | Command |
+|----------|------|---------|
+| TypeScript/JS | Stryker Mutator | `npx stryker run` |
+| Python | mutmut | `mutmut run` |
+| Java | PIT (Pitest) | `mvn pitest:mutationCoverage` |
+
+---
+
+## Thresholds
+
+| Module Type | Minimum Score | Enforcement |
+|-------------|--------------|-------------|
+| Auth/License/Payment/Security | 80% | Block release |
+| Standard business logic | 70% | Warning; resolve before next release |
+| AI-generated tests | 50% | Required; reject if below |
+| Overall project | 60% | Track trend; alert on regression |
+
+---
+
+## When to Run
+
+| Trigger | Command | Enforcement |
+|---------|---------|-------------|
+| Pre-release gate | `npm run test:mutation` | ≥ 60% overall |
+| Critical module change | `npx stryker run --mutate 'src/auth/**'` | ≥ 80% |
+| AI-generated test review | `npx stryker run` | ≥ 50% |
+
+**Never** add mutation testing to commit hooks — it's too slow (10-60 minutes).
+
+---
+
+## Stryker Quick Start (TypeScript + Vitest)
+
+```bash
+npm install --save-dev @stryker-mutator/core @stryker-mutator/vitest-runner
+```
+
+```json
+// stryker.config.json
+{
+  "testRunner": "vitest",
+  "coverageAnalysis": "perTest",
+  "mutate": ["src/license/**/*.ts", "!src/**/*.test.ts"],
+  "thresholds": { "high": 80, "low": 60, "break": 50 }
+}
+```
+
+---
+
+## Anti-Patterns
+
+- Treating line coverage as a proxy for test effectiveness
+- Adding mutation testing to CI for every PR (too slow)
+- Accepting AI-generated tests without mutation score validation
+- Killing mutations by adding `toBeDefined()` assertions
+
+---
+
+## Relationship to Other Standards
+
+- `test-completeness-dimensions`: Dimension 8 (AI Test Quality) references mutation score
+- `mock-boundary`: Hollow tests survive many mutations; mock boundary rules prevent hollow tests
+- `testing`: Mutation testing is the quality gate on top of the test pyramid