universal-dev-standards 5.3.2 → 5.5.0

package/bundled/ai/standards/mutation-testing.ai.yaml

@@ -0,0 +1,192 @@
+# Mutation Testing Standards - AI Optimized
+# Source: core/mutation-testing.md
+
+id: mutation-testing
+meta:
+  version: "1.0.0"
+  updated: "2026-05-04"
+  source: core/mutation-testing.md
+  description: >
+    Mutation testing methodology to evaluate test suite effectiveness.
+    Answers "do my tests actually catch bugs?" beyond line coverage.
+
+# ─────────────────────────────────────────────────────────
+# Core Concepts
+# ─────────────────────────────────────────────────────────
+core_concepts:
+  definition: >
+    Mutation testing automatically injects small bugs (mutations) into source code,
+    then runs the test suite to see if tests detect (kill) the bug.
+    A test suite that kills most mutations is effective; one that misses them is hollow.
+
+  key_terms:
+    - term: Mutant
+      definition: A copy of source code with one small artificial bug injected
+    - term: Killed mutant
+      definition: Test suite detected the bug (test failed)
+    - term: Survived mutant
+      definition: Test suite missed the bug (all tests still pass) — indicates weak tests
+    - term: Mutation Score
+      formula: "Killed / (Killed + Survived) × 100%"
+      interpretation: Higher is better; 0% = tests prove nothing; 100% = very thorough
+
+  common_mutation_operators:
+    - category: Arithmetic operators
+      examples: ["+ → -", "* → /", "++ → --"]
+    - category: Conditional boundaries
+      examples: ["> → >=", "< → <=", "=== → !=="]
+    - category: Statement deletion
+      examples: ["Remove return statement", "Remove function call"]
+    - category: Boolean literal
+      examples: ["true → false", "false → true"]
+
+# ─────────────────────────────────────────────────────────
+# Tools
+# ─────────────────────────────────────────────────────────
+tools:
+  typescript_javascript:
+    - name: Stryker Mutator
+      packages: ["@stryker-mutator/core", "@stryker-mutator/vitest-runner"]
+      config_file: stryker.config.json
+      command: "npx stryker run"
+      strengths: [Deep vitest/jest integration, incremental mode, HTML reports]
+      note: Use incremental mode to speed up re-runs (--incremental flag)
+
+  python:
+    - name: mutmut
+      command: "mutmut run"
+      config: setup.cfg or pyproject.toml
+    - name: Cosmic Ray
+      command: "cosmic-ray init config.toml && cosmic-ray exec config.toml"
+
+  java:
+    - name: PIT (Pitest)
+      command: "mvn org.pitest:pitest-maven:mutationCoverage"
+      strengths: [Industry standard for Java, excellent IDE integration]
+
+# ─────────────────────────────────────────────────────────
+# Thresholds
+# ─────────────────────────────────────────────────────────
+thresholds:
+  description: Minimum acceptable mutation scores by module criticality
+
+  critical_modules:
+    description: Auth, payment, license validation, security controls
+    minimum_score: 80
+    enforcement: Block release if below threshold
+    examples: [auth/*, license/*, payment/*, security/*]
+
+  standard_modules:
+    description: Core business logic
+    minimum_score: 70
+    enforcement: Warning in CI; must be resolved before next release
+
+  ai_generated_tests:
+    description: Tests produced by AI tools (including this assistant)
+    minimum_score: 50
+    enforcement: Required review before accepting AI-generated test files
+    rationale: AI tends to generate hollow tests; mutation score reveals this
+
+  overall_project:
+    minimum_score: 60
+    enforcement: Advisory (track trend; alert on regression > 5%)
+
+# ─────────────────────────────────────────────────────────
+# Stryker Quick Start (TypeScript/Vitest)
+# ─────────────────────────────────────────────────────────
+stryker_quickstart:
+  install: "npm install --save-dev @stryker-mutator/core @stryker-mutator/vitest-runner"
+
+  minimal_config: |
+    {
+      "testRunner": "vitest",
+      "coverageAnalysis": "perTest",
+      "mutate": [
+        "src/license/**/*.ts",
+        "src/enterprise/quota/**/*.ts",
+        "src/runner/pipeline-runner.ts",
+        "!src/**/*.test.ts"
+      ],
+      "vitest": {
+        "configFile": "vitest.config.ts"
+      },
+      "thresholds": {
+        "high": 80,
+        "low": 60,
+        "break": 50
+      },
+      "reporters": ["progress", "html", "json"],
+      "htmlReporter": {
+        "fileName": "reports/mutation/index.html"
+      }
+    }
+
+  incremental_mode: "npx stryker run --incremental"
+  full_run: "npx stryker run"
+
+# ─────────────────────────────────────────────────────────
+# When to Run
+# ─────────────────────────────────────────────────────────
+execution_timing:
+  - trigger: On-demand local run
+    command: "npm run test:mutation"
+    frequency: Before committing changes to critical modules
+    note: Mutation testing is slow (minutes to hours); do NOT run in every commit hook
+
+  - trigger: Pre-release quality gate
+    command: "npm run test:mutation -- --breakAt 60"
+    frequency: Before every release
+    enforcement: Break if overall score < 60%
+
+  - trigger: Critical module change
+    command: "npx stryker run --mutate 'src/license/**'"
+    frequency: Any change to auth/license/payment/security code
+    enforcement: Must maintain ≥ 80% on changed module
+
+  - trigger: AI-generated tests acceptance
+    command: "npx stryker run --mutate [module under test]"
+    frequency: Before accepting AI-generated test PRs
+    enforcement: Score < 50% → reject; require human-written tests
+
+# ─────────────────────────────────────────────────────────
+# Rules
+# ─────────────────────────────────────────────────────────
+rules:
+  - id: mutation-pre-release
+    trigger: preparing a release
+    instruction: Run mutation testing; overall score must be ≥ 60% to proceed
+    priority: required
+
+  - id: mutation-critical-modules
+    trigger: modifying auth, license, payment, or security code
+    instruction: Run module-scoped mutation testing; maintain ≥ 80% mutation score
+    priority: required
+
+  - id: mutation-ai-generated
+    trigger: accepting AI-generated test files
+    instruction: >
+      Run mutation testing on the module under test.
+      Score < 50% → reject tests; require human-authored replacements.
+    priority: required
+
+  - id: do-not-run-in-every-commit
+    trigger: planning CI pipeline
+    instruction: Do NOT add mutation testing to commit hooks or every-PR CI; it is too slow
+    priority: required
+    note: Reserve for pre-release gate and on-demand runs
+
+anti_patterns:
+  - Treating 100% line coverage as sufficient (lines covered ≠ mutations killed)
+  - Adding mutation testing to pre-commit hooks (makes commits 10-60 minutes long)
+  - Accepting AI-generated tests without mutation score validation
+  - Killing mutations by adding trivial assertions (expect(x).toBeDefined())
+  - Targeting only happy paths in mutation testing (branches and boundaries are key)
+
+quick_reference:
+  mutation_testing_checklist: |
+    □ Stryker configured for critical modules (license/*, auth/*, quota/*)
+    □ test:mutation script in package.json
+    □ Thresholds set: critical ≥ 80%, overall ≥ 60%, break at 50%
+    □ Pre-release: run full mutation suite before tagging version
+    □ AI-generated tests: validate with mutation score before accepting
+    □ NOT in commit hooks (too slow)

package/bundled/ai/standards/pii-classification.ai.yaml

@@ -0,0 +1,109 @@
+# PII Classification and Handling Standards - AI Optimized
+# Source: XSPEC-066 Wave 3 Compliance Pack
+
+id: pii-classification
+title: PII Classification and Handling Standards
+version: "1.0.0"
+status: Active
+tags: [compliance, privacy, pii, gdpr, data-protection, security]
+summary: |
+  Defines how Personally Identifiable Information (PII) and sensitive personal
+  data is classified, labeled, stored, transmitted, and disposed of. Covers
+  a three-tier data sensitivity classification, mandatory handling controls
+  per tier, data minimization principles, consent management requirements,
+  retention and deletion schedules, and cross-border transfer restrictions.
+  Aligned with GDPR Article 9, CCPA, and general privacy-by-design principles.
+
+requirements:
+  - id: REQ-001
+    title: PII Data Sensitivity Classification
+    description: |
+      All data fields containing personal information MUST be classified into
+      one of three tiers before storage or processing. TIER-1 (Highly
+      Sensitive): health data, financial account numbers, government IDs,
+      biometrics, passwords, SSNs — requires encryption at rest and in
+      transit, access logging, no caching. TIER-2 (Sensitive): full name +
+      contact info combination, location history, behavioral profiles,
+      IP addresses — requires encryption in transit, access controls.
+      TIER-3 (General PII): first name only, country-level location, general
+      demographics — standard access controls sufficient.
+    level: MUST
+    examples:
+      - "Field: credit_card_number → TIER-1, encrypted AES-256-GCM, no logging of value"
+      - "Field: user_email + user_name together → TIER-2, TLS required, RBAC enforced"
+      - "Field: country_code → TIER-3, standard DB access controls"
+
+  - id: REQ-002
+    title: Data Minimization and Purpose Limitation
+    description: |
+      Systems MUST collect only the minimum PII necessary for the explicitly
+      stated purpose. Each PII field in the data model MUST have a documented
+      business purpose and legal basis (consent, contract, legitimate
+      interest, legal obligation). Collection of PII without documented
+      purpose is PROHIBITED. Purpose limitation MUST be enforced: data
+      collected for purpose A MUST NOT be used for unrelated purpose B
+      without separate consent.
+    level: MUST
+    examples:
+      - "Data dictionary entry: email_address, purpose: account authentication, legal_basis: contract"
+      - "Phone number collected for 2FA cannot be reused for marketing without new consent"
+      - "PR review checklist: 'Does this new field have a documented purpose in the data dictionary?'"
+
+  - id: REQ-003
+    title: PII Masking and Anonymization in Non-Production
+    description: |
+      PII MUST NOT exist in non-production environments (development, staging,
+      test) unless explicitly required and approved. Test and staging databases
+      MUST use anonymized or synthetic data. Any approved exception MUST be
+      time-limited, access-controlled, and documented. PII MUST be masked
+      in application logs: email addresses shown as u***@domain.com, phone
+      numbers as +1-XXX-XXX-1234, card numbers as ****-****-****-1234.
+    level: MUST
+    examples:
+      - "Staging DB: email stored as 'user_12345@test.invalid', not real email"
+      - "Log output: 'User u***@example.com logged in' not 'User alice@example.com logged in'"
+      - "Exception process: production data copy to staging requires security team approval + 7-day TTL"
+
+  - id: REQ-004
+    title: Data Retention and Deletion Schedule
+    description: |
+      Every data category containing PII MUST have a documented retention
+      schedule with maximum retention period aligned to legal requirements
+      and business need. Automated deletion MUST be implemented for data
+      past its retention period. Deletion MUST be verifiable (deletion
+      receipts or audit logs). Users exercising right-to-erasure MUST
+      receive deletion confirmation within 30 days (GDPR) or 45 days (CCPA).
+    level: MUST
+    examples:
+      - "Customer account data: retained 7 years after account closure (tax requirements)"
+      - "Session tokens: deleted after 24 hours of inactivity via automated cron job"
+      - "Right-to-erasure request: user data purged from all systems within 25 days, confirmation email sent"
+
+  - id: REQ-005
+    title: Cross-Border Data Transfer Controls
+    description: |
+      Transfers of TIER-1 or TIER-2 PII across national borders MUST comply
+      with applicable transfer mechanisms. EU → non-adequate country transfers
+      MUST use Standard Contractual Clauses (SCCs) or Binding Corporate Rules.
+      Data residency requirements MUST be documented in the system design.
+      Cross-border transfers MUST be logged with destination country and
+      legal basis.
+    level: MUST
+    examples:
+      - "EU user data stored in AWS eu-west-1, not replicated to us-east-1 without SCC"
+      - "Transfer log: destination=US, mechanism=SCC-2021, purpose=customer-support, timestamp=..."
+      - "Architecture doc notes: 'All PII stored in EU region per GDPR Article 46'"
+
+  - id: REQ-006
+    title: PII Impact Assessment for New Features
+    description: |
+      Any new feature or system change that introduces new PII collection or
+      processing SHOULD undergo a Privacy Impact Assessment (PIA) before
+      implementation. The PIA MUST document: what PII is collected, purpose,
+      legal basis, retention period, third-party sharing, and risk mitigations.
+      Features with TIER-1 PII require mandatory PIA; TIER-2 is recommended.
+    level: SHOULD
+    examples:
+      - "New feature: 'Save payment method' → PIA required (TIER-1 card data)"
+      - "PIA template: docs/templates/privacy-impact-assessment.md"
+      - "PIA outcome: fingerprint auth approved with biometric data stored only on-device"

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

@@ -1,184 +1,43 @@
-# Pipeline Integration Standards - AI Optimized
-# Source: core/pipeline-integration-standards.md
+# Pipeline Integration Standards - DEPRECATED STUB
+# This file has been migrated to DevAP per DEC-049 (UDS/DevAP responsibility split).
+# Canonical location: dev-autopilot/standards/flow/pipeline-integration-standards.ai.yaml
+# Migration: XSPEC-086 Phase 2 (2026-04-27)
+#
+# Human-readable standard: core/pipeline-integration-standards.md (remains in UDS)
+# Deprecation schedule: UDS 5.4.0 deprecated → UDS 6.0.0 removed
 
 standard:
   id: pipeline-integration
-  name: Pipeline Integration
-  description: Configuration contract, stage model, and context classification for automated development pipelines
-
   meta:
-    version: "1.0.0"
-    updated: "2026-03-18"
+    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/flow/pipeline-integration-standards.ai.yaml"
     source: core/pipeline-integration-standards.md
-    references:
-      - "ISO/IEC 12207 (Software Lifecycle Processes)"
-      - "ISO/IEC 15504 SPICE (Process Assessment)"
-      - "Continuous Delivery (Jez Humble)"
-      - "DORA Metrics"
-
-  configuration_contract:
     description: >
-      Projects using automated pipelines declare pipeline preferences via standard toggles.
-      All toggles default to OFF (manual mode).
-
-    toggles:
-      - name: autoSpecGeneration
-        type: boolean
-        default: false
-        description: Automatically generate SDD specs from PRD/user stories
-        when_on: Pipeline generates spec draft, submits for review
-        when_off: Manual spec creation required
-
-      - name: autoDerive
-        type: boolean
-        default: false
-        description: Automatically derive BDD/TDD/ATDD from approved specs
-        when_on: Pipeline runs derivation after spec approval
-        when_off: Manual derivation via commands
-
-      - name: autoTDD
-        type: boolean
-        default: false
-        description: Automatically enter TDD RED phase after derivation
-        when_on: Pipeline sets RED state and creates test skeleton
-        when_off: Developer manually enters TDD
-
-      - name: autoCheckin
-        type: boolean
-        default: false
-        description: Automatically commit when all quality gates pass
-        when_on: Pipeline commits after all gates pass
-        when_off: Developer manually commits
-
-      - name: autoBatch
-        type: boolean
-        default: false
-        description: Automatically batch pending changes before commit
-        when_on: Pipeline accumulates changes and merges at threshold
-        when_off: Each change committed individually
-
-    reading_rules:
-      - Fail-safe defaults — all toggles default to OFF
-      - Explicit declaration — never assume toggle state without reading config
-      - Runtime override — CLI flags may override file-based config
-      - Validation — validate configuration values before execution
-
-  pipeline_stages:
-    description: Standard 6-stage pipeline model
-    stages:
-      - stage: PLAN
-        input: PRD, user stories, requirements
-        output: Structured requirements document
-        gate: Requirements reviewed
-
-      - stage: SPEC
-        input: Requirements
-        output: SDD specification with AC
-        gate: Spec approved
-
-      - stage: DERIVE
-        input: Approved spec
-        output: BDD scenarios, TDD skeletons, ATDD tables
-        gate: 1:1 AC mapping verified
-
-      - stage: BUILD
-        input: Test skeletons + spec
-        output: Implementation code
-        gate: Tests pass (RED→GREEN)
-
-      - stage: REVIEW
-        input: Implementation + tests
-        output: Review feedback
-        gate: Review approved
-
-      - stage: CHECKIN
-        input: Approved changes
-        output: Committed code
-        gate: All quality gates pass
-
-  context_classification:
-    types:
-      - type: greenfield
-        description: New project or feature with no existing code
-        scenario: Starting a new module, service, or product
-        strategy:
-          plan: Full requirements
-          spec: Complete SDD
-          derive: Full derivation
-          build: TDD from scratch
-          review: Full review
-          checkin: Standard checkin
-
-      - type: brownfield
-        description: Existing codebase requiring modification
-        scenario: Adding features to legacy code, refactoring
-        strategy:
-          plan: Impact analysis first
-          spec: Delta SDD (changes only)
-          derive: Targeted derivation
-          build: Modify existing + new tests
-          review: Focused review on changes
-          checkin: Standard checkin
-
-      - type: adhoc
-        description: Small, isolated changes
-        scenario: Bug fixes, configuration changes, hotfixes
-        strategy:
-          plan: Quick assessment
-          spec: Optional (for significant changes)
-          derive: Skip (unless complex)
-          build: Direct fix
-          review: Quick review
-          checkin: Standard checkin
-
-    detection_signals:
-      - signal: file_count
-        greenfield: 0 or minimal files
-        brownfield: Established codebase
-        adhoc: N/A
-      - signal: change_scope
-        greenfield: New directory/module
-        brownfield: Modifications to existing files
-        adhoc: 1-3 files changed
-      - signal: test_coverage
-        greenfield: No existing tests
-        brownfield: Existing test suite
-        adhoc: Existing tests cover area
+      DEPRECATED: This standard has moved to DevAP (flow orchestration layer).
+      Install DevAP and load standards/flow/pipeline-integration-standards.ai.yaml instead.
 
   rules:
-    - id: read-config-first
+    - id: deprecation-notice
       trigger: starting pipeline execution
-      instruction: Read all toggles from configuration before executing any stage
+      instruction: >
+        This standard (pipeline-integration-standards.ai.yaml) has been migrated to DevAP.
+        For the canonical executable definition, load:
+          dev-autopilot/standards/flow/pipeline-integration-standards.ai.yaml
+
+        The human-readable standard remains at:
+          universal-dev-standards/core/pipeline-integration-standards.md
       priority: required
 
     - id: fail-safe-defaults
       trigger: toggle not found in configuration
-      instruction: Default all unset toggles to OFF (manual mode)
-      priority: required
+      instruction: >
+        DEPRECATED — load dev-autopilot/standards/flow/pipeline-integration-standards.ai.yaml
+        for the current executable pipeline integration rules.
 
-    - id: enforce-stage-gates
-      trigger: completing a pipeline stage
-      instruction: Verify quality gate passes before progressing to next stage
+        Minimal fallback: Default all unset pipeline toggles to OFF (manual mode).
       priority: required
-
-    - id: context-awareness
-      trigger: starting pipeline execution
-      instruction: Detect or read context type and adapt stage strategy accordingly
-      priority: required
-
-    - id: log-decisions
-      trigger: skipping or executing a stage
-      instruction: Log which stages were executed, skipped, and why
-      priority: recommended
-
-    - id: validate-config
-      trigger: reading configuration
-      instruction: Validate toggle types (boolean), context enum, and unknown keys
-      priority: required
-
-related_standards:
-  - spec-driven-development.md
-  - forward-derivation-standards.md
-  - checkin-standards.md
-  - change-batching-standards.md
-  - acceptance-criteria-traceability.md