universal-dev-standards 5.4.0 → 5.6.0

package/bundled/ai/standards/product-metrics-standards.ai.yaml

@@ -0,0 +1,111 @@
+# Product Metrics Standards - AI Optimized
+# Source: XSPEC-069 Wave 4 Product Layer Pack
+
+id: product-metrics-standards
+title: Product Metrics Framework Standards
+version: "1.0.0"
+status: Active
+tags: [product, metrics, kpi, aarrr, heart, north-star, analytics]
+summary: |
+  Defines how teams select, structure, and govern product metrics. Covers
+  a framework selection matrix (AARRR for growth products, HEART for
+  experience products, custom North Star for platforms), North Star metric
+  criteria, a three-level metric hierarchy (North Star → L1 drivers →
+  L2 diagnostics), and an anti-vanity rule that rejects metrics decoupled
+  from revenue or retention impact. Designed to align teams around metrics
+  that drive meaningful product decisions rather than activity tracking.
+
+requirements:
+  - id: REQ-001
+    title: Framework Selection Matrix
+    description: |
+      Teams MUST select a primary metrics framework appropriate to their
+      product type. Selection criteria: (1) Growth products (consumer apps,
+      marketplaces, viral products focused on user acquisition and monetization)
+      → use AARRR framework (Acquisition, Activation, Retention, Referral,
+      Revenue). (2) Experience products (productivity tools, B2B SaaS, apps
+      where user satisfaction and task completion drive retention) → use
+      HEART framework (Happiness, Engagement, Adoption, Retention, Task
+      Success). (3) Platform products (developer platforms, APIs, infrastructure
+      products with diverse use cases) → define a custom North Star metric
+      that reflects platform value delivered, supplemented by AARRR or HEART
+      components as applicable. Framework selection MUST be documented in the
+      PRD or product strategy document.
+    level: MUST
+    examples:
+      - "Consumer social app → AARRR; primary focus on D7 retention and referral coefficient"
+      - "B2B project management tool → HEART; primary focus on Task Success and Retention"
+      - "Developer API platform → custom North Star: 'API calls per active developer per week'"
+      - "Framework documented in product-metrics.md: 'We use HEART because...'"
+
+  - id: REQ-002
+    title: North Star Criteria
+    description: |
+      Every product MUST define exactly one North Star metric that satisfies
+      all four criteria: (1) Leading indicator — it predicts future business
+      health (revenue, retention) rather than measuring past outcomes.
+      (2) Measurable and trackable — it can be calculated from existing or
+      easily obtainable data with a defined measurement cadence (weekly
+      or monthly). (3) Actionable by the team — the product team has direct
+      levers to influence it through feature development and UX decisions.
+      (4) Explainable in one sentence — any team member can describe what
+      it measures and why it matters without needing additional context.
+      North Star MUST be reviewed and reconfirmed at each annual product
+      planning cycle.
+    level: MUST
+    examples:
+      - "Spotify: 'Time spent listening per user per week' (leading, measurable, actionable)"
+      - "Airbnb: 'Nights booked per month' (explainable, predicts revenue)"
+      - "Weak North Star: 'Total revenue' (lagging, not directly actionable by product team)"
+      - "Annual review: North Star unchanged but L1 driver metrics updated for new product area"
+
+  - id: REQ-003
+    title: Metric Hierarchy
+    description: |
+      Teams MUST structure metrics in a three-level hierarchy with a maximum
+      of three levels. Level 1 (North Star): one metric representing overall
+      product value delivered. Level 2 (L1 Driver Metrics): 3–5 metrics that
+      directly influence the North Star; each driver metric must have a
+      documented causal hypothesis linking it to the North Star. Level 3
+      (L2 Diagnostic Metrics): per-feature or per-team metrics that explain
+      movements in L1 drivers; maximum 3 diagnostics per driver. Metrics
+      beyond three levels of hierarchy are PROHIBITED — they indicate
+      measurement fragmentation rather than focus.
+    level: MUST
+    examples:
+      - "North Star: weekly active users completing core action"
+      - "L1 drivers: new user activation rate, 7-day retention, feature adoption breadth"
+      - "L2 diagnostic for activation: onboarding step completion rates (step 1/2/3)"
+      - "Prohibited: L4 sub-diagnostic metrics that obscure rather than explain"
+
+  - id: REQ-004
+    title: Anti-Vanity Rule
+    description: |
+      Teams MUST apply the anti-vanity test before adding any metric to the
+      official metrics dashboard. A metric fails the anti-vanity test if it
+      can increase while revenue and retention remain flat or decrease. Such
+      metrics MUST NOT appear in official product reviews or be used as
+      success criteria for features. Examples of vanity metrics that commonly
+      fail this test: total registered users (without active usage filter),
+      raw pageviews (without session quality filter), total API calls
+      (without unique active customer filter), press mentions, app store
+      downloads without activation. When a vanity metric is useful for
+      operational monitoring, it MUST be clearly labeled as "operational
+      indicator, not success metric."
+    level: MUST
+    examples:
+      - "Reject: 'Total signups this month' → replace with 'Signups who completed activation'"
+      - "Reject: 'Total pageviews' → replace with 'Sessions with ≥2 meaningful interactions'"
+      - "Allowed with label: 'Total API calls (operational indicator)' on infra dashboard"
+      - "Feature success metric: 'Users who used feature X and retained at D30' not 'feature clicks'"
+
+anti_patterns:
+  - "Tracking vanity metrics (total signups, raw pageviews) as primary success indicators"
+  - "No North Star defined — teams optimize for different local metrics, creating misalignment"
+  - "Conflicting team metrics where one team's optimization harms another team's metric"
+  - "Metric hierarchy deeper than 3 levels, creating measurement complexity without insight"
+  - "Changing the North Star quarterly, preventing year-over-year trend analysis"
+
+related_standards:
+  - prd-standards
+  - slo-sli

package/bundled/ai/standards/prompt-regression.ai.yaml

@@ -0,0 +1,94 @@
+# SPDX-License-Identifier: MIT
+name: Prompt Regression Standards
+nameZh: Prompt 回歸測試標準
+id: prompt-regression
+version: "1.0.0"
+category: testing
+scope: ai-agent-systems
+summary: >
+  Prevent unintended prompt changes from silently degrading AI agent behaviour.
+  Golden checksum tests detect modifications; snapshot diff confirms intent.
+
+requirements:
+  - id: REQ-01
+    title: Prompt Versioning
+    titleZh: Prompt 版本化
+    level: MUST
+    description: >
+      Every AI agent MUST have a versioned prompt file (e.g. prompt.md with
+      frontmatter `version: "x.y.z"`). Changes require explicit version bump.
+
+  - id: REQ-02
+    title: Golden Checksum Test
+    titleZh: 黃金校驗和測試
+    level: MUST
+    description: >
+      A CI-enforced checksum test MUST store the SHA-256 hash of each agent's
+      prompt file. A mismatch fails the build and requires updating the golden
+      value with a comment confirming intent ("intentional change for X").
+    implementation: |
+      const GOLDEN = { "planner": "abc123...", ... }
+      it("prompt has not changed unexpectedly", () => {
+        const actual = sha256(readFileSync("agents/planner/prompt.md"))
+        expect(actual).toBe(GOLDEN["planner"])
+      })
+
+  - id: REQ-03
+    title: Snapshot Diff
+    titleZh: 快照差異比對
+    level: SHOULD
+    description: >
+      On CI failure, the system SHOULD output a unified diff between the
+      recorded snapshot and current prompt content to aid review.
+
+  - id: REQ-04
+    title: Change Review Gate
+    titleZh: 變更審查閘門
+    level: MUST
+    description: >
+      Prompt changes MUST be reviewed as code changes. Checksum updates require
+      a comment in the test file explaining why the prompt changed (e.g.
+      "Updated system role to include new Guardian policy reference XSPEC-160").
+
+  - id: REQ-05
+    title: Coverage
+    titleZh: 覆蓋範圍
+    level: MUST
+    description: >
+      The golden checksum test MUST cover ALL production agent prompt files.
+      New agents added to the system MUST be added to the test within the same
+      PR that introduces the agent.
+
+examples:
+  - name: "SHA-256 checksum test in Vitest"
+    code: |
+      import { createHash } from "crypto"
+      import { readFileSync } from "fs"
+      import { describe, it, expect } from "vitest"
+
+      const GOLDEN_CHECKSUMS: Record<string, string> = {
+        planner: "dd0d086d...",
+        guardian: "f56555...",
+      }
+
+      describe("Agent prompt regression", () => {
+        for (const [agent, expected] of Object.entries(GOLDEN_CHECKSUMS)) {
+          it(`agents/${agent}/prompt.md has not changed unexpectedly`, () => {
+            const content = readFileSync(`agents/${agent}/prompt.md`)
+            const actual = createHash("sha256").update(content).digest("hex")
+            expect(actual).toBe(expected)
+          })
+        }
+      })
+
+anti_patterns:
+  - description: >
+      Skipping checksums for "stable" agents — all prompts require regression
+      coverage regardless of perceived stability.
+  - description: >
+      Updating checksums in bulk without per-agent comments explaining intent.
+
+related_standards:
+  - llm-output-validation
+  - adversarial-test
+  - testing

package/bundled/ai/standards/property-based-testing.ai.yaml

@@ -0,0 +1,105 @@
+# SPDX-License-Identifier: MIT
+name: Property-Based Testing Standards
+nameZh: 屬性基礎測試標準
+id: property-based-testing
+version: "1.0.0"
+category: testing
+scope: correctness-validation
+summary: >
+  Property-based testing generates hundreds of random inputs to verify that
+  invariants (properties) hold for all valid inputs, not just the examples
+  a developer thought to write. Especially valuable for pure functions,
+  parsers, and security-critical logic.
+
+requirements:
+  - id: REQ-01
+    title: Property Identification
+    titleZh: 屬性識別
+    level: MUST
+    description: >
+      For each module under property-based test, developers MUST explicitly
+      identify the invariants to test. Examples: idempotency, monotonicity,
+      round-trip (encode/decode), boundary clamping, determinism.
+
+  - id: REQ-02
+    title: Generator Coverage
+    titleZh: 生成器覆蓋
+    level: MUST
+    description: >
+      Property tests MUST use appropriate generators: bounded integers for
+      array indices, valid enum values for type-constrained fields,
+      arbitrary strings for fuzz targets. Generators MUST cover the full
+      valid input space, not just a curated subset.
+
+  - id: REQ-03
+    title: Shrinking
+    titleZh: 最小化反例
+    level: SHOULD
+    description: >
+      When a property test fails, the framework SHOULD shrink the
+      counterexample to its minimal form. Libraries like fast-check (JS/TS)
+      and Hypothesis (Python) do this automatically.
+
+  - id: REQ-04
+    title: Run Count
+    titleZh: 執行次數
+    level: MUST
+    description: >
+      Property tests MUST run at least 100 samples per property in CI.
+      For security-critical functions (hash chains, token validation,
+      policy evaluation), run at least 1000 samples.
+
+  - id: REQ-05
+    title: Seed Persistence
+    titleZh: 種子持久化
+    level: SHOULD
+    description: >
+      When a property test fails, the failing seed SHOULD be saved and
+      re-run in CI until the fix is confirmed. This ensures regressions
+      are caught even after the random seed changes.
+
+examples:
+  - name: "fast-check idempotency property for score clamping"
+    code: |
+      import fc from "fast-check"
+      import { describe, it } from "vitest"
+
+      describe("scoreReviewable idempotency", () => {
+        it("score is always in [0, 100]", () => {
+          fc.assert(
+            fc.property(
+              fc.record({
+                target_env: fc.constantFrom("prod", "staging", "dev"),
+                command_type: fc.constantFrom("query", "mutate", "exec", "delete"),
+                reversible: fc.boolean(),
+              }),
+              ({ target_env, command_type, reversible }) => {
+                const result = scoreReviewable({
+                  session_id: "prop-001",
+                  source_agent: "operator",
+                  intent: "test",
+                  plan: [{ command: "ls", command_type, reversible }],
+                  target_env,
+                  reversible,
+                })
+                return result.score >= 0 && result.score <= 100
+              }
+            ),
+            { numRuns: 1000 }
+          )
+        })
+      })
+
+anti_patterns:
+  - description: >
+      Using fc.anything() for domain-specific inputs — unguided random
+      strings will mostly generate invalid inputs that get rejected early.
+      Use constrained generators (fc.constantFrom, fc.integer with bounds).
+  - description: >
+      Setting numRuns: 10 — too few samples to find edge cases. Use at
+      least 100 for regular code and 1000 for security-critical functions.
+
+related_standards:
+  - mutation-testing
+  - testing
+  - adversarial-test

package/bundled/ai/standards/release-quality-manifest.ai.yaml

@@ -0,0 +1,135 @@
+# Release Quality Manifest Standards - AI Optimized
+# Source: core/release-quality-manifest.md
+
+id: release-quality-manifest
+meta:
+  version: "1.0.0"
+  updated: "2026-05-05"
+  source: core/release-quality-manifest.md
+  description: Automated per-release Quality Manifest that aggregates all quality gate results into a single machine-readable artifact
+
+requirements:
+  REQ-1:
+    id: REQ-RQM-001
+    title: Machine-Readable Format
+    rule: >
+      Every release MUST produce a Quality Manifest in YAML or JSON format that
+      aggregates the results of all defined quality gates. The manifest MUST be
+      committed to source control or attached to the release artifact.
+    rationale: >
+      Machine-readable manifests enable automated release gates and customer audits;
+      prose-only release notes cannot be parsed by downstream tooling.
+
+  REQ-2:
+    id: REQ-RQM-002
+    title: Gate Coverage
+    rule: >
+      The Quality Manifest MUST include at minimum: unit test coverage %, mutation
+      score %, SCA CVE counts (critical/high), SAST finding counts (high/medium),
+      E2E pass rate %, container CVE scan status, image signature status, SBOM
+      presence, and (if applicable) LLM hallucination rate and prompt injection
+      resistance score.
+    rationale: >
+      Partial manifests create false confidence; a complete manifest proves end-to-end
+      quality rather than cherry-picked metrics.
+
+  REQ-3:
+    id: REQ-RQM-003
+    title: Pass/Warn/Fail Status per Gate
+    rule: >
+      Each gate entry MUST carry a status field: "pass" (meets target), "warn"
+      (within acceptable deviation from target), or "fail" (blocks release).
+      The manifest MUST have an overall status field derived from the worst gate.
+    rationale: >
+      Binary pass/fail per gate plus an aggregate status enables release go/no-go
+      automation without human judgment on individual metrics.
+
+  REQ-4:
+    id: REQ-RQM-004
+    title: Automated Generation in CI
+    rule: >
+      The Quality Manifest MUST be generated automatically by CI (not manually
+      authored). Each gate's value MUST be extracted from the corresponding tool
+      output (vitest coverage JSON, stryker JSON, trivy SARIF, etc.).
+    rationale: >
+      Manually authored manifests are unreliable; CI-generated manifests are the
+      only form of evidence that meets audit requirements.
+
+  REQ-5:
+    id: REQ-RQM-005
+    title: Customer-Facing Summary
+    rule: >
+      A human-readable summary of the Quality Manifest (e.g., Markdown table)
+      MUST be generated alongside the machine-readable format and included in
+      the release notes or documentation.
+    rationale: >
+      Customers and auditors need a scannable summary; the machine-readable format
+      alone does not satisfy human review requirements.
+
+manifest_schema:
+  release: "string — semver tag e.g. v1.2.0"
+  generated_at: "ISO 8601 timestamp"
+  commit: "git SHA"
+  gates:
+    unit_coverage:
+      actual: "percentage string e.g. '73%'"
+      target: "threshold e.g. '80%'"
+      status: "pass | warn | fail"
+    mutation_score:
+      actual: "percentage string"
+      target: "threshold"
+      status: "pass | warn | fail"
+    sca_critical_cve:
+      actual: "integer"
+      target: "0"
+      status: "pass | fail"
+    sca_high_cve:
+      actual: "integer"
+      target: "0"
+      status: "pass | warn | fail"
+    sast_high:
+      actual: "integer"
+      target: "0"
+      status: "pass | warn | fail"
+    e2e_pass_rate:
+      actual: "percentage string"
+      target: "threshold"
+      status: "pass | warn | fail"
+    container_cve_critical:
+      actual: "integer"
+      target: "0"
+      status: "pass | fail"
+    image_signed:
+      actual: "boolean"
+      target: "true"
+      status: "pass | fail"
+    sbom_present:
+      actual: "boolean"
+      target: "true"
+      status: "pass | fail"
+  overall: "PASS | WARN | FAIL"
+
+generation_guidance: >
+  Extract coverage from vitest --coverage --reporter=json (summary.total.lines.pct).
+  Extract mutation score from stryker's mutation-testing-report.json (metrics.mutationScore).
+  Extract CVE counts from trivy JSON output (Results[].Vulnerabilities filtered by Severity).
+  Extract SAST from CodeQL SARIF (runs[].results filtered by level=error).
+  Combine into manifest YAML via a CI shell script or Node.js release script.
+
+anti_patterns:
+  - description: >
+      Generating the manifest after all gates have passed — gates should use
+      the manifest values, not precede them.
+  - description: >
+      Hardcoding metric values in the manifest generation script — all values
+      MUST be extracted from tool outputs to remain accurate.
+  - description: >
+      Using 'warn' status for critical security gates (sca_critical_cve,
+      container_cve_critical) — critical security gates are binary pass/fail.
+
+related_standards:
+  - testing
+  - security-testing
+  - supply-chain-attestation
+  - verification-evidence
+  - deployment-standards

package/bundled/ai/standards/release-readiness-gate.ai.yaml

@@ -0,0 +1,77 @@
+# Release Readiness Gate Standards - AI Optimized
+# Source: core/release-readiness-gate.md
+
+id: release-readiness-gate
+meta:
+  version: "1.0.0"
+  updated: "2026-05-05"
+  source: core/release-readiness-gate.md
+  description: Single aggregated release gate covering 16 quality dimensions with tiered sign-off template and RQM integration
+
+requirements:
+  REQ-1:
+    id: REQ-RRG-001
+    title: 16-Dimension Coverage
+    rule: >
+      Every production release MUST evaluate all 16 quality dimensions defined in
+      core/release-readiness-gate.md. Tier-1 dimensions block release if FAIL.
+      Tier-2 dimensions require documented rationale if WARN. Tier-3 dimensions
+      require rationale if N/A.
+    rationale: >
+      Without explicit multi-dimension coverage, teams pass individual gate checks
+      but ship with unverified quality dimensions, creating systematic blind spots.
+
+  REQ-2:
+    id: REQ-RRG-002
+    title: Release Readiness Sign-off
+    rule: >
+      A Release Readiness Sign-off document MUST be created from the template in
+      core/release-readiness-gate.md for every release tag. It must be stored at
+      .release-readiness/<version>.md. The Overall Decision field must be explicitly
+      set to GO or NO-GO by a named release owner.
+    rationale: >
+      Anonymous or implicit GO decisions remove accountability; the sign-off creates
+      a named, dated, auditable record of the go/no-go decision and its evidence.
+
+  REQ-3:
+    id: REQ-RRG-003
+    title: Tier-1 Hard Block
+    rule: >
+      ANY Tier-1 dimension at FAIL status MUST block production deployment.
+      Tier-1 dimensions are: Security (Dim 2), DB Migration (Dim 5), Operational
+      Readiness (Dim 7), Rollback/DR (Dim 13), Production Smoke (Dim 14).
+    rationale: >
+      Tier-1 dimensions represent existential risks: security vulnerabilities,
+      broken rollback, misconfigured monitoring. No business justification
+      overrides a Tier-1 FAIL.
+
+  REQ-4:
+    id: REQ-RRG-004
+    title: RQM Alignment
+    rule: >
+      The machine-readable Release Quality Manifest (release-quality-manifest.md)
+      MUST include entries for all automated dimensions (a11y_critical, contract_drift,
+      cross_flow_cuj_pass_rate, browser_tier1_pass_rate, capacity_headroom_cpu_pct,
+      smoke_pass_rate, flow_gate_report). The RQM overall field must be PASS or WARN
+      (never FAIL) before deployment.
+    rationale: >
+      Human sign-off and machine manifest are complementary; the manifest enables
+      automated enforcement while the sign-off provides human accountability.
+
+  REQ-5:
+    id: REQ-RRG-005
+    title: Incremental Collection
+    rule: >
+      Release Readiness Sign-off evidence MUST be collected incrementally throughout
+      the release cycle (Gate 0 at PRD, Gate 3 pre-UAT, Gate 4 post-UAT). Creating
+      the sign-off on the day of deployment is an anti-pattern.
+    rationale: >
+      Last-minute sign-offs are rubber stamps; evidence collected late cannot
+      be acted upon without delaying the release.
+
+quick_reference:
+  tier_1_dimensions: "Security, DB Migration, Operational Readiness, Rollback/DR, Production Smoke"
+  tier_2_dimensions: "Performance, a11y, Cross-flow Regression, i18n, Docs, Feature Flags, Multi-Gate Flow"
+  tier_3_dimensions: "Contract Testing, Browser Compat, Capacity, Compliance/Privacy"
+  sign_off_location: ".release-readiness/<version>.md"
+  rqm_integration: "flow_gate_report.json → release-quality-manifest.yaml field flow_gate_report"

package/bundled/ai/standards/replay-test.ai.yaml

@@ -0,0 +1,111 @@
+# SPDX-License-Identifier: MIT
+name: Replay Test Standards
+nameZh: 回放測試標準
+id: replay-test
+version: "1.0.0"
+category: testing
+scope: ai-agent-systems
+summary: >
+  Golden fixture recording and deterministic replay for AI agent pipelines.
+  Enables customer bug reproduction, verdict regression detection, and
+  on-site incident investigation without requiring a live LLM.
+
+requirements:
+  - id: REQ-01
+    title: Golden Fixture Format
+    titleZh: 黃金 fixture 格式
+    level: MUST
+    description: >
+      Each replay fixture MUST be a JSON file containing: (1) the exact input
+      that triggered the behaviour, (2) the expected output (decision/verdict),
+      (3) metadata (date recorded, source — customer report / CI regression /
+      incident, description). Fixtures MUST be deterministic (same input always
+      produces same output for pure-function components).
+
+  - id: REQ-02
+    title: Replay Test Suite
+    titleZh: 回放測試套件
+    level: MUST
+    description: >
+      A dedicated replay test file MUST load each fixture and assert that
+      re-running the component under test produces the recorded expected output.
+      For AI components with LLM dependencies, replay MUST mock the LLM layer
+      and test only the deterministic logic (scoring, routing, policy evaluation).
+
+  - id: REQ-03
+    title: Bug Regression Capture
+    titleZh: Bug 回歸捕捉
+    level: MUST
+    description: >
+      When a production bug is reported, a fixture MUST be created from the
+      failing input within the same PR that fixes the bug. The fixture prevents
+      the bug from being reintroduced silently.
+
+  - id: REQ-04
+    title: Fixture Coverage
+    titleZh: Fixture 覆蓋
+    level: SHOULD
+    description: >
+      The fixture set SHOULD include at least one representative for each
+      decision outcome (e.g. ALLOW / REQUIRE_HITL / DENY for Guardian).
+      Edge cases reported by customers or from red-team exercises SHOULD be
+      added as separate fixtures.
+
+  - id: REQ-05
+    title: Fixture Naming Convention
+    titleZh: Fixture 命名規範
+    level: MUST
+    description: >
+      Fixture files MUST follow the pattern:
+      `<component>-<outcome>-<short-description>.json`
+      e.g. `guardian-deny-prod-drop-table.json`,
+           `guardian-allow-dev-npm-install.json`
+
+examples:
+  - name: "Guardian replay fixture file"
+    code: |
+      {
+        "meta": {
+          "recorded": "2026-05-05",
+          "source": "red-team-exercise",
+          "description": "DROP TABLE in prod should DENY"
+        },
+        "input": {
+          "session_id": "replay-001",
+          "source_agent": "operator",
+          "intent": "Clean up test data",
+          "plan": [{"command": "DROP TABLE users;", "command_type": "mutate", "target_resource": "db_schema", "reversible": false}],
+          "target_env": "prod",
+          "reversible": false
+        },
+        "expected": {
+          "decision": "DENY"
+        }
+      }
+
+  - name: "Replay test loading fixtures"
+    code: |
+      const fixtures = readdirSync('src/guardian/__fixtures__')
+        .filter(f => f.endsWith('.json'))
+        .map(f => JSON.parse(readFileSync(join('src/guardian/__fixtures__', f), 'utf-8')))
+
+      for (const { meta, input, expected } of fixtures) {
+        it(meta.description, () => {
+          const result = scoreReviewable(input)
+          const decision = deriveDecision(result.score)
+          expect(decision).toBe(expected.decision)
+        })
+      }
+
+anti_patterns:
+  - description: >
+      Fixtures without metadata fields — without source and date, it's
+      impossible to know why a fixture exists or when it was added.
+  - description: >
+      Creating fixtures only for the happy path — the most valuable fixtures
+      are customer-reported failures and red-team findings.
+
+related_standards:
+  - adversarial-test
+  - testing
+  - verification-evidence