universal-dev-standards 5.4.0 → 5.6.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/policy-as-code-testing.ai.yaml

@@ -0,0 +1,227 @@
+# Policy as Code Testing Standards - AI Optimized
+# Source: core/policy-as-code-testing.md
+
+id: policy-as-code-testing
+meta:
+  version: "1.0.0"
+  updated: "2026-05-05"
+  source: core/policy-as-code-testing.md
+  description: >
+    Standards for unit testing Open Policy Agent (OPA) Rego policies and
+    other Policy as Code (PaC) engines. Ensures that AI agent authorization
+    policies are tested with the same rigor as application code.
+
+# ─────────────────────────────────────────────────────────
+# Core Concepts
+# ─────────────────────────────────────────────────────────
+core_concepts:
+  definition: >
+    Policy as Code (PaC) means security and authorization policies are expressed
+    as code (Rego, Cedar, CEL) rather than manual configuration. This enables
+    version control, code review, and automated testing of policies.
+
+  opa_test_framework:
+    overview: >
+      OPA's built-in test framework allows unit testing Rego policies with
+      `opa test`. Tests are Rego rules with names prefixed by `test_`.
+      Tests pass if they evaluate to `true`, fail if `false` or undefined.
+    run_command: "opa test <policy_directory> -v"
+    file_convention: "<policy_name>_test.rego in the same directory as the policy"
+
+  why_test_policies:
+    - reason: Policies encode security decisions — untested policies create silent security holes
+    - reason: Policy logic can have edge cases (reversible vs. irreversible, env-specific rules)
+    - reason: Policy changes must be validated against both allowed and denied cases
+    - reason: OPA Rego syntax errors are only caught at runtime without tests
+
+# ─────────────────────────────────────────────────────────
+# OPA Rego Test Structure
+# ─────────────────────────────────────────────────────────
+rego_test_structure:
+  file_naming: "<policy_module>_test.rego"
+  package_naming: "<policy_package>_test"
+
+  test_rule_format: |
+    # Each test is a Rego rule with `test_` prefix
+    # Test passes if rule body evaluates to true
+    test_<description> if {
+        <rule_under_test> with input as { <test_input> }
+    }
+
+    # Negative test (assert rule does NOT fire)
+    test_<description>_is_not_violated if {
+        not <rule_under_test> with input as { <test_input> }
+    }
+
+  required_test_categories:
+    - category: ALLOW cases
+      description: Inputs that must NOT trigger the policy violation
+      minimum: 2
+      example: |
+        test_safe_select_is_allowed if {
+            not data.my_pkg.has_violation with input as {
+                "plan": [{"command_type": "sql", "command": "SELECT * FROM t"}]
+            }
+        }
+
+    - category: DENY cases
+      description: Inputs that MUST trigger the policy violation
+      minimum: 3
+      example: |
+        test_drop_database_is_forbidden if {
+            data.my_pkg.has_forbidden_pattern with input as {
+                "plan": [{"command_type": "sql", "command": "DROP DATABASE prod"}]
+            }
+        }
+
+    - category: Boundary cases
+      description: Edge cases at the boundary of the policy condition
+      minimum: 1
+      example: |
+        # reversible=false triggers but reversible=true does not
+        test_irreversible_triggers if {
+            data.my_pkg.prod_violation with input as {
+                "target_env": "prod",
+                "plan": [{"reversible": false, "command": "DELETE FROM users"}]
+            }
+        }
+        test_reversible_does_not_trigger if {
+            not data.my_pkg.prod_violation with input as {
+                "target_env": "prod",
+                "plan": [{"reversible": true, "command": "SELECT * FROM users"}]
+            }
+        }
+
+    - category: Integration test (main policy)
+      description: Test the full policy chain via the main/root package
+      minimum: 2
+
+# ─────────────────────────────────────────────────────────
+# Policy Module Design Rules
+# ─────────────────────────────────────────────────────────
+policy_design_rules:
+  - rule: fail_closed_default
+    description: >
+      The root policy package MUST have `default allow = false`.
+      Any evaluation error or undefined result should deny, not allow.
+    example: |
+      default allow = false
+      allow if {
+          not data.my_pkg.forbidden.has_violation
+          not data.my_pkg.env.prod_violation
+      }
+
+  - rule: no_free_text_in_security_decisions
+    description: >
+      Policy rules MUST NOT parse user-controlled free-text fields (intent,
+      description, annotations) for security decisions. Only structured,
+      typed fields (command_type, reversible, target_env) should drive policy.
+    rationale: Free-text parsing creates prompt injection attack surface (OWASP LLM01)
+
+  - rule: set_not_array_for_violations
+    description: >
+      Use partial set rules (`violations[reason] if {...}`) to aggregate
+      violation reasons, not array rules. Arrays cannot be used with partial rules.
+    example: |
+      # CORRECT: partial set rule
+      violations[reason] if {
+          has_violation
+          reason := "VIOLATION_TYPE"
+      }
+      # INCORRECT: array.concat on sets causes type errors in OPA ≥ 0.40
+      # deny_reasons := array.concat(violations1, violations2)  ← DO NOT USE
+
+  - rule: module_per_concern
+    description: >
+      Each policy concern should be a separate Rego module (file).
+      E.g., forbidden_patterns.rego / env_policy.rego / risk_gate.rego.
+      Main.rego aggregates all modules via data references.
+    benefit: Enables per-module testing and cleaner separation of concerns
+
+# ─────────────────────────────────────────────────────────
+# CI Integration
+# ─────────────────────────────────────────────────────────
+ci_integration:
+  github_actions_step: |
+    - name: Test OPA Rego Policies
+      run: |
+        docker run --rm \
+          -v "${{ github.workspace }}/src/guardian/policies:/policies:ro" \
+          openpolicyagent/opa:latest-static \
+          test /policies -v
+
+  npm_script: |
+    "test:policy": "docker run --rm -v \"$(pwd)/src/guardian/policies:/policies:ro\" openpolicyagent/opa:latest-static test /policies -v"
+
+  local_opa_binary: |
+    # If OPA binary is installed:
+    opa test src/guardian/policies/ -v
+
+# ─────────────────────────────────────────────────────────
+# Quality Gates
+# ─────────────────────────────────────────────────────────
+quality_gates:
+  - gate: OPA policy tests (CI)
+    threshold: "100% of Rego tests pass"
+    enforcement: Block merge
+    automated: true
+    note: Run via `opa test` on every PR that touches *.rego files
+
+  - gate: Policy coverage
+    threshold: "Each policy module has ≥ 2 ALLOW + ≥ 3 DENY test cases"
+    enforcement: Advisory (reviewer checklist)
+
+  - gate: Integration tests
+    threshold: "Root policy (main.rego) has tests for both allow and deny paths"
+    enforcement: Block merge
+
+# ─────────────────────────────────────────────────────────
+# Rules
+# ─────────────────────────────────────────────────────────
+rules:
+  - id: rego-unit-test-per-module
+    trigger: creating or modifying a Rego policy module
+    instruction: >
+      Every Rego module MUST have a corresponding _test.rego file with at minimum:
+      2 ALLOW cases, 3 DENY cases, and 1 boundary case.
+    priority: required
+
+  - id: fail-closed-default
+    trigger: creating a root OPA policy package
+    instruction: >
+      Root policy MUST include `default allow = false`.
+      Any undefined evaluation must result in DENY.
+    priority: required
+
+  - id: no-free-text-in-policy
+    trigger: writing Rego rules
+    instruction: >
+      Never parse intent, description, or annotation fields in Rego rules.
+      Use only structured fields: command_type, command, reversible, target_env,
+      target_resource, risk_score.
+    priority: required
+
+  - id: policy-test-on-rego-change
+    trigger: modifying any *.rego file
+    instruction: >
+      Re-run `opa test` on the entire policy directory after any change.
+      CI must block merge if OPA tests fail.
+    priority: required
+
+anti_patterns:
+  - Using array.concat() on set-type violation rules (type error in OPA ≥ 0.40)
+  - Parsing intent/user-input fields in security policy logic
+  - Missing `default allow = false` in root policy
+  - Policy modules without corresponding _test.rego files
+  - Testing only DENY cases (no ALLOW cases means you can't tell if the policy is too restrictive)
+  - Running OPA tests only locally, not in CI
+
+quick_reference:
+  policy_test_checklist: |
+    □ Each policy module has a _test.rego file
+    □ Tests cover: ALLOW cases (≥ 2), DENY cases (≥ 3), boundary cases (≥ 1)
+    □ main.rego / root policy tested via integration tests
+    □ `default allow = false` present in root policy
+    □ No free-text field parsing in Rego rules
+    □ `opa test <policies_dir> -v` passes locally
+    □ CI step: `opa test` runs on every PR touching *.rego

package/bundled/ai/standards/prd-standards.ai.yaml

@@ -0,0 +1,88 @@
+# PRD Standards - AI Optimized
+# Source: XSPEC-069 Wave 4 Product Layer Pack
+
+id: prd-standards
+title: Product Requirements Document Standards
+version: "1.0.0"
+status: Active
+tags: [product, prd, requirements, user-research, planning]
+summary: |
+  Defines the structure, content requirements, and lifecycle governance for
+  Product Requirements Documents (PRDs). Covers five mandatory PRD sections
+  (Problem Statement, Target User/Persona, Success Metrics, Scope in/out,
+  Constraints), the bridge from PRD requirements to traceable user stories,
+  and the revision policy for changes after kickoff. Designed to ensure product
+  intent is clearly communicable to engineering, design, and stakeholders with
+  measurable success criteria.
+
+requirements:
+  - id: REQ-001
+    title: PRD Five Sections
+    description: |
+      Every PRD MUST contain five sections in the following order:
+      (1) Problem Statement — describes the user pain point or opportunity
+      in observable terms; includes quantitative data where available (e.g.,
+      support ticket volume, user research findings, funnel drop-off rates).
+      (2) Target User / Persona — identifies who is affected; references
+      named personas with role, context, and goals; at minimum one primary
+      persona and one secondary persona.
+      (3) Success Metrics — defines 2–4 measurable outcomes that indicate
+      the problem is solved; each metric must include current baseline,
+      target value, and measurement method.
+      (4) Scope In / Out — explicitly lists what is included and excluded
+      from this PRD; out-of-scope items may reference future PRDs.
+      (5) Constraints — technical, regulatory, time, budget, or dependency
+      constraints that bound the solution space.
+    level: MUST
+    examples:
+      - "Problem: 34% of users abandon checkout at payment step (Mixpanel, Q1 2026)"
+      - "Primary persona: Mid-market SaaS buyer; Secondary: IT admin approver"
+      - "Success metric: Checkout completion rate ≥ 72% (baseline 66%) measured via Amplitude"
+      - "Out of scope: saved payment methods (deferred to PRD-2026-Q3-payments)"
+
+  - id: REQ-002
+    title: PRD to User Story Bridge
+    description: |
+      Each PRD requirement MUST be broken down into one or more user stories
+      following the INVEST criteria defined in requirement-engineering.ai.yaml.
+      Every user story derived from a PRD MUST be traceable to at least one
+      PRD success metric — stories that cannot be linked to a success metric
+      MUST be flagged for PM review before inclusion in the backlog. The
+      traceability link (PRD section ID → User Story ID → Success Metric) MUST
+      be maintained in the backlog tool or as a traceability matrix in the PRD.
+    level: MUST
+    examples:
+      - "PRD-REQ-003 → US-042 'As a buyer, I want to pay with Apple Pay' → metric: checkout rate"
+      - "Story without metric link flagged with label `needs-metric-trace` in Jira"
+      - "Traceability matrix table in PRD section 6: REQ ↔ Stories ↔ Metrics"
+      - "Stories use INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable"
+
+  - id: REQ-003
+    title: Revision Policy
+    description: |
+      PRD changes requested after the development kickoff meeting MUST follow
+      a formal revision process: (1) Proposed change documented with rationale
+      and impact assessment. (2) Stakeholder sign-off obtained from PM, Tech
+      Lead, and Design Lead. (3) Scope impact assessed — if change adds scope,
+      a corresponding item must be moved to out-of-scope or timeline adjusted.
+      (4) Version history updated in the PRD with date, author, change summary,
+      and approver. PRDs without version history that have been modified after
+      kickoff are considered non-compliant.
+    level: MUST
+    examples:
+      - "PRD v1.2 (2026-04-15, @alice): Added biometric auth requirement; approved by @bob, @carol"
+      - "Scope impact: biometric auth added → saved cards feature deferred to v2"
+      - "Change log table at PRD top: Version | Date | Author | Summary | Approvers"
+      - "Minor editorial changes (typos, formatting) exempt from sign-off requirement"
+
+anti_patterns:
+  - "PRD without measurable success metrics (qualitative goals only, e.g., 'improve UX')"
+  - "Scope creep without change log: adding requirements mid-sprint without documented approval"
+  - "Solution-first PRD: describing implementation details before establishing user problem"
+  - "PRD with no explicit out-of-scope section, causing boundary disputes during development"
+  - "Success metrics defined after development starts, making them unverifiable"
+
+related_standards:
+  - requirement-engineering
+  - user-story-mapping
+  - product-metrics-standards