universal-dev-standards 5.3.2 → 5.5.0

package/bundled/ai/standards/data-pipeline.ai.yaml

@@ -0,0 +1,113 @@
+# Data Pipeline Standards - AI Optimized
+# Source: XSPEC-068 Wave 3 Data Engineering Pack
+
+id: data-pipeline
+title: Data Pipeline Standards
+version: "1.0.0"
+status: Active
+tags: [data-engineering, pipeline, etl, data-quality, orchestration, idempotency]
+summary: |
+  Defines engineering standards for building reliable, observable, and
+  maintainable data pipelines. Covers idempotency and exactly-once semantics,
+  error handling and dead-letter queues, checkpoint and recovery patterns,
+  data lineage tracking, pipeline observability (metrics, alerting), testing
+  requirements, and deployment practices. Applicable to batch ETL, streaming
+  pipelines, and ML feature pipelines.
+
+requirements:
+  - id: REQ-001
+    title: Idempotency and Exactly-Once Processing
+    description: |
+      Every data pipeline MUST be designed for idempotent execution:
+      re-running the same pipeline for the same time window or batch MUST
+      produce identical output without duplication or data loss. Pipelines
+      MUST use deterministic keys for deduplication. Batch pipelines MUST
+      support re-processing historical partitions cleanly. Streaming pipelines
+      MUST implement exactly-once or at-least-once with deduplication using
+      unique event IDs. Overwrites of output partitions are preferred over
+      appends for batch jobs.
+    level: MUST
+    examples:
+      - "Batch: pipeline writes to date-partitioned output and overwrites the partition on re-run"
+      - "Streaming: dedup using Kafka message key + consumer group offset tracking"
+      - "Test: running pipeline twice for 2026-04-01 produces same row count both times"
+
+  - id: REQ-002
+    title: Error Handling and Dead-Letter Queues
+    description: |
+      Data pipelines MUST implement structured error handling with
+      categorized failure modes. Transient errors (network timeout, API
+      rate limit) MUST use exponential backoff retry (max 3 attempts).
+      Permanent errors (schema violation, invalid data) MUST route records
+      to a Dead-Letter Queue (DLQ) with the original record, error type,
+      error message, and processing timestamp. DLQ records MUST be
+      monitored and addressed within the pipeline's SLA.
+    level: MUST
+    examples:
+      - "Transient retry: retry_policy: {max_attempts: 3, backoff_base: 2s, max_backoff: 30s}"
+      - "DLQ record: {original_record: {...}, error_type: 'SCHEMA_VIOLATION', error_msg: 'field amount is null', ts: '...'}"
+      - "DLQ alert: >100 DLQ messages in 1 hour → PagerDuty alert to data-oncall"
+
+  - id: REQ-003
+    title: Checkpoint and Recovery
+    description: |
+      Long-running batch pipelines and stateful streaming pipelines MUST
+      implement checkpointing to enable recovery from mid-run failures
+      without full reprocessing. Checkpoints MUST record: last successfully
+      processed partition/offset/watermark, job run ID, and timestamp.
+      Recovery MUST resume from the last checkpoint, not from the beginning.
+      Checkpoint state MUST be stored in durable external storage (not
+      local disk).
+    level: MUST
+    examples:
+      - "Batch: checkpoint stores {last_processed_date: '2026-04-28', last_id: 12345678} in S3"
+      - "Streaming: Flink checkpoint interval 5 minutes, stored in S3 with 3 checkpoints retained"
+      - "Recovery test: kill job mid-run, restart, verify output matches full run with no duplicates"
+
+  - id: REQ-004
+    title: Data Lineage Tracking
+    description: |
+      Every data pipeline MUST emit lineage metadata describing its data
+      flow: source datasets (with versions/timestamps), transformation logic
+      applied, and output datasets produced. Lineage MUST be machine-readable
+      and ingested into a central lineage store or data catalog. Lineage
+      enables root-cause analysis of data quality issues and impact assessment
+      of upstream changes.
+    level: MUST
+    examples:
+      - "Lineage emit: {job: 'orders-aggregator', inputs: ['raw_orders@2026-04-30'], outputs: ['daily_order_summary@2026-04-30'], transform_version: 'v1.3.2'}"
+      - "OpenLineage event emitted to Marquez or DataHub on job start and completion"
+      - "Lineage query: 'Which pipelines read from raw_orders?' returns 5 downstream jobs"
+
+  - id: REQ-005
+    title: Pipeline Observability and SLOs
+    description: |
+      Every production data pipeline MUST expose the following metrics:
+      records processed (counter), processing latency (histogram), error
+      rate (gauge), DLQ depth (gauge), and last successful run timestamp.
+      Pipelines MUST define SLOs for: freshness (data available within N
+      hours of source), completeness (≥ X% records successfully processed),
+      and latency (p95 processing time within threshold). SLO violations
+      MUST trigger alerts.
+    level: MUST
+    examples:
+      - "Metric: pipeline_records_processed_total{pipeline='orders-agg',status='success'}"
+      - "Freshness SLO: daily_order_summary available by 03:00 UTC — alert if missing by 04:00 UTC"
+      - "Completeness alert: processed_records / expected_records < 0.99 → P2 alert"
+
+  - id: REQ-006
+    title: Pipeline Testing Requirements
+    description: |
+      Data pipelines MUST have automated tests covering: unit tests for
+      transformation logic (test with sample input/output DataFrames),
+      integration tests validating end-to-end flow with synthetic data,
+      and schema conformance tests validating output matches declared
+      data contract. Pipelines SHOULD have regression tests for historically
+      problematic edge cases (nulls in key fields, negative amounts,
+      duplicate records). Test coverage MUST be ≥ 80% for transformation
+      logic.
+    level: MUST
+    examples:
+      - "Unit test: test_calculate_order_total() — asserts discount applied correctly on sample rows"
+      - "Integration test: runs full pipeline on 1000 synthetic orders, validates output row count and schema"
+      - "Edge case test: pipeline handles duplicate order_id gracefully, deduplication logic verified"

package/bundled/ai/standards/disaster-recovery-drill.ai.yaml

@@ -0,0 +1,89 @@
+# SPDX-License-Identifier: MIT
+name: Disaster Recovery Drill Standards
+nameZh: 災難恢復演練標準
+id: disaster-recovery-drill
+version: "1.0.0"
+category: operations
+scope: reliability
+summary: >
+  Structured DR drill standards: quarterly runbook execution, RTO/RPO
+  measurement, backup restore verification, and Game Day protocols.
+  Untested recovery plans fail at the worst moment.
+
+requirements:
+  - id: REQ-01
+    title: RTO/RPO Targets Defined
+    titleZh: RTO/RPO 目標定義
+    level: MUST
+    description: >
+      Each system MUST have documented RTO (Recovery Time Objective) and RPO
+      (Recovery Point Objective) targets. These must be agreed with stakeholders
+      before any DR drill can be considered meaningful.
+    examples:
+      - "VibeOps commercial: RTO < 1 hour, RPO < 24 hours (daily backup)"
+
+  - id: REQ-02
+    title: Backup Restore Test
+    titleZh: 備份還原測試
+    level: MUST
+    description: >
+      At minimum quarterly, a full backup restore MUST be executed in an
+      isolated environment and verified for data integrity. The restore time
+      MUST be measured and compared to the RTO target.
+
+  - id: REQ-03
+    title: Runbook Completeness
+    titleZh: 運行手冊完整性
+    level: MUST
+    description: >
+      A DR runbook MUST exist covering: (1) detection (how do we know disaster
+      occurred?), (2) decision (who declares DR?), (3) recovery steps
+      (step-by-step, executable commands), (4) verification (how do we confirm
+      recovery?), (5) communication plan.
+
+  - id: REQ-04
+    title: Game Day Exercise
+    titleZh: Game Day 演練
+    level: SHOULD
+    description: >
+      At minimum annually, a Game Day exercise SHOULD be conducted where the
+      team simulates a realistic failure scenario and executes the runbook from
+      scratch. Results SHOULD be documented and used to improve the runbook.
+
+  - id: REQ-05
+    title: Drill Record
+    titleZh: 演練記錄
+    level: MUST
+    description: >
+      Every DR drill MUST produce a written record including: date, participants,
+      scenario tested, RTO achieved, RPO achieved, issues found, remediation
+      actions. Records MUST be retained for 12 months.
+
+examples:
+  - name: "DR drill record template"
+    code: |
+      date: 2026-05-05
+      participants: [alice, bob]
+      scenario: "Database total loss — restore from daily backup"
+      rto_target: "1 hour"
+      rto_achieved: "42 minutes"
+      rpo_target: "24 hours"
+      rpo_achieved: "23 hours 15 minutes"
+      issues_found:
+        - "backup script path was stale — fixed in XSPEC-170"
+      remediation:
+        - "Update backup path in backup-restore.sh"
+      status: PASS
+
+anti_patterns:
+  - description: >
+      Only verifying that a backup file exists — always restore it and
+      verify data integrity. An untested backup is not a backup.
+  - description: >
+      Running DR drills in production — always use an isolated environment
+      to avoid turning a drill into an actual disaster.
+
+related_standards:
+  - deployment-standards
+  - chaos-engineering-standards
+  - verification-evidence

package/bundled/ai/standards/execution-history.ai.yaml

@@ -1,302 +1,44 @@
-# Execution History Repository Standards - AI Optimized
-# Source: cross-project/specs/XSPEC-003-execution-history-standard-sdd.md
+# Execution History Repository Standards - DEPRECATED STUB
+# This file has been migrated to DevAP per DEC-049 (UDS/DevAP responsibility split).
+# Canonical location: dev-autopilot/standards/orchestration/execution-history.ai.yaml
+# Migration: XSPEC-086 Phase 2 (2026-04-27)
+#
+# Source spec: cross-project/specs/XSPEC-003-execution-history-standard-sdd.md
+# Deprecation schedule: UDS 5.4.0 deprecated → UDS 6.0.0 removed
 
 standard:
   id: execution-history
-  name: "Execution History Repository Standards"
-  description: "Structured system for persisting agent execution artifacts with L1/L2/L3 tiered access model"
-  guidelines:
-    - "每次 agent 任務執行完畢後，必須產出 required artifacts"
-    - "歷史以檔案系統目錄結構組織，支援直接路徑存取"
-    - "提供 L1/L2/L3 三層存取，平衡資訊量與 token 成本"
-    - "敏感資訊在寫入時自動 redact"
-    - "跨專案僅共享 L1 層級，遵守授權隔離"
-    - "歷史保留策略確保 L1/L2 索引永久保留，L3 artifacts 依 max_runs 設定自動清理以控制儲存空間"
-
   meta:
-    version: "1.0.0"
-    updated: "2026-04-02"
+    version: "1.0.1"
+    updated: "2026-04-27"
+    deprecated: true
+    deprecated_since: "5.4.0"
+    removal_version: "6.0.0"
+    canonical_owner: devap
+    canonical_path: "dev-autopilot/standards/orchestration/execution-history.ai.yaml"
     source: cross-project/specs/XSPEC-003-execution-history-standard-sdd.md
-    description: "基於 Meta-Harness 論文洞見，建立跨專案執行歷史標準"
-
-  schema:
-    storage:
-      description: "執行歷史為 append-only log，支援兩種儲存後端"
-      backends:
-        local:
-          description: "儲存在 repo 內的 .execution-history/ 目錄"
-          git_policy: |
-            L3 artifacts 不追蹤（納入 .gitignore），L1 index.json 可選追蹤。
-            歷史本質是寫入後不變動的 log，不適合 git 追蹤大量變動。
-          gitignore_rules: |
-            .execution-history/*/           # L3 artifacts 不追蹤
-            !.execution-history/index.json  # L1 索引可選追蹤
-            !.execution-history/index-archive.json  # L1 歸檔索引可選追蹤
-          when_to_use: "個人開發、小型專案、或不需跨環境共享歷史時"
-        file_server:
-          description: "儲存在外部 FileServer（如 S3、MinIO、NAS、共享磁碟）"
-          config_file: ".execution-history/storage.json"
-          config_schema:
-            backend: { type: string, enum: [local, file_server] }
-            file_server_url: { type: string, description: "FileServer 端點 URL" }
-            auth_method: { type: string, enum: [none, api_key, oauth], default: none }
-            sync_l1_to_local: { type: boolean, default: true, description: "是否將 L1 索引同步到本地" }
-          when_to_use: "團隊協作、跨環境共享、歷史量大、或需要長期保存時"
-          rules:
-            - "L1 索引始終同步到本地（sync_l1_to_local: true），確保離線可讀"
-            - "L2/L3 按需從 FileServer 拉取"
-            - "寫入走 FileServer API，本地不留 L3 副本"
-      default_backend: local
-
-    directory_structure:
-      root: ".execution-history/"
-      layout: |
-        .execution-history/
-        ├── storage.json                        # 儲存後端配置（可選，預設 local）
-        ├── index.json                          # L1: 最近 50 個活躍 tasks 索引
-        ├── index-archive.json                  # L1-ext: 歸檔 tasks 索引（> 90 天無新 run）
-        ├── {task-id}/
-        │   ├── manifest.json                   # L2: 任務層級摘要
-        │   ├── {run-number}/                   # 三位數字（001-999）
-        │   │   ├── manifest.json               # L2: 單次執行摘要
-        │   │   ├── task-description.md          # Required: 任務描述
-        │   │   ├── code-diff.patch              # Required: 程式碼變更
-        │   │   ├── test-results.json            # Required: 測試結果
-        │   │   ├── execution-log.jsonl          # Required: 執行日誌
-        │   │   ├── token-usage.json             # Required: Token 使用量
-        │   │   ├── final-status.json            # Required: 最終狀態
-        │   │   ├── error-analysis.md            # Optional: 錯誤分析
-        │   │   └── agent-reasoning.md           # Optional: Agent 推理過程
-        │   └── ...
-        └── ...
-      index_strategy:
-        description: "分層索引策略，平衡即時性與歷史完整性"
-        active_index: "index.json — 最近 50 個活躍 tasks（< 200 tokens 目標）"
-        archive_index: "index-archive.json — 超過 90 天無新 run 的 tasks 自動歸檔"
-        archive_trigger: "task 最後一次 run 距今 > 90 天"
-        reactivate_trigger: "歸檔 task 有新 run 時自動移回 active index"
-
-    artifacts:
-      required:
-        - id: task-description
-          file: "task-description.md"
-          format: markdown
-          description: "任務目標、輸入、預期產出"
-          max_size: "2KB"
-        - id: code-diff
-          file: "code-diff.patch"
-          format: "unified diff"
-          description: "本次執行產生的程式碼變更"
-          max_size: "50KB"
-        - id: test-results
-          file: "test-results.json"
-          format: json
-          description: "測試執行結果（通過/失敗/跳過數量、失敗詳情）"
-          schema_ref: "#/definitions/test-results"
-        - id: execution-log
-          file: "execution-log.jsonl"
-          format: jsonl
-          description: "結構化執行日誌（每行一個事件）"
-          schema_ref: "#/definitions/log-entry"
-        - id: token-usage
-          file: "token-usage.json"
-          format: json
-          description: "Token 使用量明細（input/output/total，按步驟分）"
-          schema_ref: "#/definitions/token-usage"
-        - id: final-status
-          file: "final-status.json"
-          format: json
-          description: "最終狀態（success/failure/partial，含摘要）"
-          schema_ref: "#/definitions/final-status"
-      optional:
-        - id: error-analysis
-          file: "error-analysis.md"
-          format: markdown
-          description: "失敗時的根因分析"
-          condition: "status != success"
-        - id: agent-reasoning
-          file: "agent-reasoning.md"
-          format: markdown
-          description: "Agent 的推理過程與決策紀錄"
-
-    access_layers:
-      L1:
-        name: "索引層"
-        files:
-          active: "index.json"
-          archive: "index-archive.json"
-        target_tokens: "< 200 (active), 按需 (archive)"
-        fields:
-          - task_id
-          - task_name
-          - tags
-          - latest_run
-          - latest_status
-          - latest_date
-          - total_runs
-        cross_project_access: true
-      L2:
-        name: "摘要層"
-        file: "manifest.json"
-        target_tokens: "< 1,000 per task"
-        fields:
-          - task_description_summary
-          - run_history
-          - key_metrics
-          - artifacts_available
-          - failure_summary
-        cross_project_access: false
-      L3:
-        name: "完整紀錄層"
-        file: "各 artifact 檔案"
-        target_tokens: "不限"
-        description: "直接讀取 run 目錄下的個別 artifact 檔案"
-        cross_project_access: false
-
-    retention_policy:
-      configurable: true
-      defaults:
-        max_runs_per_task: 50
-        max_total_size_mb: 500
-        cleanup_strategy: "oldest_l3_first"
-      rules:
-        - "超過 max_runs 時，最舊的 run 的 L3 artifacts 被刪除"
-        - "L1 和 L2 索引永久保留（除非手動刪除）"
-        - "cleanup 以 task 為單位，不跨 task 清理"
-
-    sensitive_data:
-      redact_on_write: true
-      sensitive_patterns:
-        - pattern: "sk-[a-zA-Z0-9_-]{20,}"
-          label: "API_KEY"
-        - pattern: "ghp_[a-zA-Z0-9]{36}"
-          label: "GITHUB_TOKEN"
-        - pattern: "password\\s*[:=]\\s*\\S+"
-          label: "PASSWORD"
-        - pattern: "-----BEGIN .* PRIVATE KEY-----"
-          label: "PRIVATE_KEY"
-      redact_format: "[REDACTED:{label}]"
-
-  definitions:
-    test-results:
-      type: object
-      required: [timestamp, summary, details]
-      properties:
-        timestamp:
-          type: string
-          format: "ISO 8601"
-        summary:
-          type: object
-          properties:
-            total: { type: integer }
-            passed: { type: integer }
-            failed: { type: integer }
-            skipped: { type: integer }
-        details:
-          type: array
-          items:
-            type: object
-            properties:
-              test_name: { type: string }
-              status: { type: string, enum: [passed, failed, skipped] }
-              duration_ms: { type: integer }
-              error_message: { type: string }
-
-    log-entry:
-      type: object
-      required: [timestamp, level, event]
-      properties:
-        timestamp: { type: string, format: "ISO 8601" }
-        level: { type: string, enum: [debug, info, warn, error] }
-        event: { type: string }
-        details: { type: object }
-        tool_call: { type: string }
-        tokens: { type: integer }
-
-    token-usage:
-      type: object
-      required: [total, breakdown]
-      properties:
-        total:
-          type: object
-          properties:
-            input_tokens: { type: integer }
-            output_tokens: { type: integer }
-        breakdown:
-          type: array
-          items:
-            type: object
-            properties:
-              step: { type: string }
-              input_tokens: { type: integer }
-              output_tokens: { type: integer }
-
-    final-status:
-      type: object
-      required: [status, summary, timestamp]
-      properties:
-        status: { type: string, enum: [success, failure, partial] }
-        summary: { type: string }
-        timestamp: { type: string, format: "ISO 8601" }
-        duration_seconds: { type: number }
-        error: { type: string }
+    description: >
+      DEPRECATED: This standard has moved to DevAP (orchestration layer).
+      Install DevAP and load standards/orchestration/execution-history.ai.yaml instead.
 
   rules:
-    - id: record-on-completion
-      trigger: "Agent 任務執行完畢（無論成功或失敗）"
+    - id: deprecation-notice
+      trigger: any execution history operation
       instruction: >
-        在任務完成後，依據 storage.json 配置的後端（預設 local），
-        將所有 required artifacts 寫入 .execution-history/{task-id}/{run-number}/ 目錄，
-        並更新 task manifest.json 和根 index.json。
-        若使用 file_server 後端，寫入走 FileServer API，
-        同時將 L1 索引同步到本地。
-      priority: required
-
-    - id: use-l1-first
-      trigger: "Agent 需要參考先前執行歷史"
-      instruction: >
-        先讀取 .execution-history/index.json（L1）篩選相關任務，
-        再讀取相關任務的 manifest.json（L2）了解脈絡，
-        僅在需要深入診斷時才讀取 L3 完整 artifacts。
-      priority: required
+        This standard (execution-history.ai.yaml) has been migrated to DevAP.
+        For the canonical executable definition, load:
+          dev-autopilot/standards/orchestration/execution-history.ai.yaml
 
-    - id: redact-sensitive
-      trigger: "寫入任何 artifact 到 .execution-history/"
-      instruction: >
-        在寫入前，掃描內容中的 sensitive_patterns，
-        將匹配內容替換為 [REDACTED:{label}] 格式。
+        Note: DevAP's packages/core already implements execution history (ExecutionHistoryStorage).
+        The YAML standard is now co-located with the implementation.
       priority: required
 
-    - id: respect-retention
-      trigger: "新 run 寫入後，檢查 retention_policy"
-      instruction: >
-        檢查該 task 的 run 數量是否超過 max_runs_per_task，
-        若超過則刪除最舊 run 的 L3 artifacts，保留 L1/L2 索引。
-      priority: recommended
-
-    - id: archive-stale-tasks
-      trigger: "index.json 更新時，檢查是否有 task 需要歸檔"
+    - id: record-on-completion
+      trigger: "Agent 任務執行完畢"
       instruction: >
-        若 index.json 中某 task 的 latest_date 距今超過 90 天，
-        將該 task 從 index.json 移至 index-archive.json。
-        若歸檔 task 有新 run 寫入，自動移回 index.json。
-        index.json 最多保留 50 個活躍 tasks。
-      priority: recommended
+        DEPRECATED — load dev-autopilot/standards/orchestration/execution-history.ai.yaml
+        for the current executable history protocol.
 
-    - id: cross-project-l1-only
-      trigger: "從其他專案讀取執行歷史"
-      instruction: >
-        跨專案存取僅限 L1 層級（index.json），
-        不得讀取 L2/L3 層級以遵守授權隔離。
+        Minimal fallback: Write required artifacts to .execution-history/{task-id}/{run-number}/
+        after each agent task completes.
       priority: required
-
-  storage:
-    directory: ".execution-history/"
-    format: "JSON + Markdown + JSONL + Patch"
-
-  architecture:
-    classification: always-on-protocol
-    note: >
-      Execution History 是 Always-On Protocol，
-      與 developer-memory、project-context-memory 同層級。
-      AI 自動遵循所有 rules，不需要 slash command。

package/bundled/ai/standards/flaky-test-management.ai.yaml

@@ -0,0 +1,89 @@
+# SPDX-License-Identifier: MIT
+name: Flaky Test Management Standards
+nameZh: 不穩定測試管理標準
+id: flaky-test-management
+version: "1.0.0"
+category: testing
+scope: test-reliability
+summary: >
+  Policies and tooling for detecting, quarantining, and eliminating flaky
+  tests. Flaky tests erode CI confidence, cause false failures, and mask
+  real bugs.
+
+requirements:
+  - id: REQ-01
+    title: Flaky Test Definition
+    titleZh: 不穩定測試定義
+    level: MUST
+    description: >
+      A test is considered flaky if it produces different results (pass/fail)
+      on consecutive runs with the same code. Teams MUST define a flakiness
+      threshold: a test that fails ≥ 2% of runs on main branch without code
+      changes is flaky.
+
+  - id: REQ-02
+    title: Quarantine Protocol
+    titleZh: 隔離協議
+    level: MUST
+    description: >
+      Flaky tests MUST be quarantined within 48 hours of detection by:
+      (1) adding a `.skip` or `.todo` annotation, (2) opening a tracking
+      issue, (3) adding a comment with the issue link and known failure mode.
+      Quarantined tests MUST NOT block CI merges.
+
+  - id: REQ-03
+    title: Retry Policy
+    titleZh: 重試策略
+    level: SHOULD
+    description: >
+      CI SHOULD allow a maximum of 2 retries for tests in the quarantine list.
+      Retries SHOULD be applied only to known-flaky tests, not the entire suite.
+      A test that passes after retry is still considered flaky and MUST be fixed.
+
+  - id: REQ-04
+    title: Flaky Test Elimination SLA
+    titleZh: 修復 SLA
+    level: MUST
+    description: >
+      Quarantined tests MUST be either fixed or permanently removed within
+      30 days of quarantine. Tests left quarantined for > 30 days with no
+      activity SHOULD be automatically deleted.
+
+  - id: REQ-05
+    title: Root Cause Categories
+    titleZh: 根因分類
+    level: SHOULD
+    description: >
+      When eliminating a flaky test, the root cause SHOULD be documented in
+      the fixing PR. Common root causes: timing/race conditions, test isolation
+      failures (shared state), external service dependencies, random seed
+      dependence, file system ordering.
+
+examples:
+  - name: "Quarantine annotation (Vitest)"
+    code: |
+      // TODO: flaky test quarantined 2026-05-05 — see issue #42
+      // Root cause: race condition in WebSocket reconnection
+      it.skip("reconnects after disconnect", async () => { ... })
+
+  - name: "Vitest retry config for known flaky tests"
+    code: |
+      // vitest.config.ts
+      export default defineConfig({
+        test: {
+          retry: 2,  // global retry for all tests
+        }
+      })
+
+anti_patterns:
+  - description: >
+      Allowing flaky tests to block CI without quarantine — developers learn
+      to ignore CI failures, which hides real bugs.
+  - description: >
+      Using arbitrary sleeps (setTimeout/sleep) to fix race conditions —
+      this makes tests slower and more fragile. Use proper async coordination.
+
+related_standards:
+  - testing
+  - test-governance
+  - ci-cd-standards