universal-dev-standards 5.3.2 → 5.5.0

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

@@ -0,0 +1,240 @@
+# Flow-Based Testing Standards - AI Optimized
+# Source: core/flow-based-testing.md
+
+id: flow-based-testing
+meta:
+  version: "1.0.0"
+  updated: "2026-05-04"
+  source: core/flow-based-testing.md
+  description: Flow decomposition methodology for testing multi-step processes with branch coverage
+
+core_concepts:
+  problem: >
+    AC-centric tests verify individual behaviors in isolation but miss integration gaps
+    between steps and leave decision-point branches untested.
+    A flow where AC-1 passes and AC-2 passes independently does NOT guarantee
+    the AC-1 → AC-2 → AC-3 sequential flow works correctly.
+  solution: >
+    Decompose each workflow into flows, identify all decision points,
+    expand into a scenario matrix, then write journey tests with shared state threading.
+
+# ─────────────────────────────────────────────────────────
+# Step 1: Flow Identification
+# ─────────────────────────────────────────────────────────
+flow_identification:
+  description: Extract testable flows from SPEC/AC before writing any test code
+  activities:
+    - name: Define Preconditions
+      description: Document the system's initial state before the flow begins
+      examples:
+        - User is authenticated (token present)
+        - Database has seed data
+        - External services are available
+    - name: List Ordered Action Sequence
+      description: List all steps in the exact execution order
+      examples:
+        - Step 1: Validate input
+        - Step 2: Check quota
+        - Step 3: Call external service
+        - Step 4: Persist result
+        - Step 5: Return response
+    - name: Extract Decision Points
+      description: Identify every if/else/conditional in the flow
+      examples:
+        - "Is the user authorized? [yes → continue | no → 401]"
+        - "Is quota sufficient? [yes → continue | no → 429]"
+        - "Did external service respond? [200 → success | timeout → retry | error → fail]"
+    - name: Define Terminal States
+      description: List all possible end states (success + each distinct failure)
+      examples:
+        - "SUCCESS: Resource created, 201 returned"
+        - "FAIL_AUTH: 401 with error code AUTH_INVALID"
+        - "FAIL_QUOTA: 429 with error code QUOTA_EXCEEDED"
+        - "FAIL_EXTERNAL: 504 with error code EXTERNAL_TIMEOUT"
+  output: Flow definition (decision point list + terminal state map)
+
+# ─────────────────────────────────────────────────────────
+# Step 2: Decision Table Expansion
+# ─────────────────────────────────────────────────────────
+decision_table_expansion:
+  description: Expand decision points into a scenario matrix using a coverage strategy
+  coverage_strategies:
+    - name: Each-Choice
+      description: Each decision value appears in at least one scenario
+      formula: "Minimum scenarios = sum of unique values across all decision points"
+      use_when: Low-risk flows, fast feedback cycles, initial coverage
+      example: "3 values + 2 values + 3 values = 8 minimum scenarios"
+    - name: Pairwise
+      description: All pairs of decision values are covered (OWASP T-way testing)
+      formula: Approximately N × max_values scenarios (N = decision points)
+      use_when: Medium-risk flows, balance between coverage and test count
+      tools: [allpairs, pairwiseJS]
+    - name: All-Combinations
+      description: Full Cartesian product of all decision values
+      formula: "Scenarios = product of value counts per decision point"
+      use_when: Critical flows (auth, payment, license validation, security controls)
+      warning: Can grow exponentially; only use for flows with < 4 decision points or < 3 values each
+
+  decision_table_template: |
+    Flow: [Flow Name]
+
+    Decision Points:
+    | Point          | Values                          |
+    |----------------|---------------------------------|
+    | Authorization  | valid / expired / missing       |
+    | Quota          | sufficient / exceeded           |
+    | ExternalSvc    | available / timeout / error     |
+
+    Each-Choice Scenarios (minimum coverage):
+    | Scenario | Auth     | Quota      | ExternalSvc | Expected          |
+    |----------|----------|------------|-------------|-------------------|
+    | S1       | valid    | sufficient | available   | success           |
+    | S2       | expired  | sufficient | available   | 401_expired       |
+    | S3       | missing  | sufficient | available   | 401_missing       |
+    | S4       | valid    | exceeded   | available   | 429_quota         |
+    | S5       | valid    | sufficient | timeout     | 504_retry         |
+    | S6       | valid    | sufficient | error       | 502_external_fail |
+
+# ─────────────────────────────────────────────────────────
+# Step 3: Journey Test Structure
+# ─────────────────────────────────────────────────────────
+journey_test_structure:
+  description: Write flow tests with shared state threading — state accumulates across steps
+  key_principle: >
+    Each test step inherits state from previous steps through a shared context object.
+    Never reset the context between steps in a journey test.
+
+  happy_path_pattern: |
+    describe("Flow: [Flow Name]", () => {
+      // Shared context — state accumulates, NOT reset between steps
+      const ctx: {
+        token?: string;
+        resourceId?: string;
+        result?: ResponseType;
+      } = {}
+
+      it("Step 1: [Precondition setup]", async () => {
+        ctx.token = await setupAuth()
+        expect(ctx.token).toBeTruthy()
+      })
+
+      it("Step 2: [Core action using Step 1 state]", async () => {
+        ctx.resourceId = await createResource(ctx.token!, inputData)
+        expect(ctx.resourceId).toMatch(/^[a-z0-9-]+$/)
+      })
+
+      it("Step 3: [Verification using accumulated state]", async () => {
+        ctx.result = await getResource(ctx.token!, ctx.resourceId!)
+        expect(ctx.result.status).toBe("active")
+        expect(ctx.result.id).toBe(ctx.resourceId)
+      })
+    })
+
+  branch_pattern: |
+    // Each branch outcome gets its own describe block
+    describe("Flow Branch: [Decision Point] → [Outcome]", () => {
+      it("should [expected behavior] when [condition]", async () => {
+        // Setup: put the system into the branch condition
+        const expiredToken = buildExpiredJwt()
+
+        // Act: trigger the flow with branch condition
+        const response = await callApi(expiredToken)
+
+        // Assert: verify BOTH the response AND any side effects
+        expect(response.status).toBe(401)
+        expect(response.body.code).toBe("AUTH_TOKEN_EXPIRED")
+        // Verify NO side effects occurred (resource not created)
+        const count = await getResourceCount()
+        expect(count).toBe(0)
+      })
+    })
+
+  anti_patterns_in_structure:
+    - "Using beforeEach to reset ctx — breaks state threading between steps"
+    - "Putting all steps in a single it() block — hides which step failed"
+    - "Asserting only on the final state — intermediate step bugs go undetected"
+    - "Using arbitrary delays between steps — use proper async/await"
+
+# ─────────────────────────────────────────────────────────
+# Feature Type Mapping
+# ─────────────────────────────────────────────────────────
+feature_type_mapping:
+  - type: Workflow / Multi-step Process
+    requires: flow_decomposition
+    minimum_coverage: Each-Choice
+    test_structure: journey-chained-test
+    dimensions: [1, 3, 4, 5, 9, 10]
+    with_ai: [1, 3, 4, 5, 9, 10, 8]
+    note: Apply flow-based-testing standard; use shared ctx; Each-Choice minimum branch coverage
+
+# ─────────────────────────────────────────────────────────
+# Rules
+# ─────────────────────────────────────────────────────────
+rules:
+  - id: flow-identification-required
+    trigger: feature has 3 or more sequential steps
+    instruction: Apply 3-step flow decomposition (identify → decision table → journey structure) before writing tests
+    priority: required
+
+  - id: decision-table-for-branches
+    trigger: flow has any if/else or conditional logic
+    instruction: Create decision table with all decision values; apply Each-Choice minimum coverage
+    priority: required
+
+  - id: shared-state-in-journey
+    trigger: writing multi-step flow test
+    instruction: Use shared context object (ctx); never reset it between steps within the same flow
+    priority: required
+
+  - id: separate-branch-describes
+    trigger: decision point has 2 or more outcome values
+    instruction: Each distinct outcome gets its own describe block with a clear name
+    priority: required
+
+  - id: all-combinations-for-critical
+    trigger: flow involves authentication, payment, license validation, or security controls
+    instruction: Apply All-Combinations coverage strategy; test every value combination
+    priority: required
+
+  - id: verify-side-effects-in-branches
+    trigger: writing branch test for failure path
+    instruction: Assert BOTH the error response AND that no unintended side effects occurred
+    priority: required
+
+# ─────────────────────────────────────────────────────────
+# Anti-Patterns
+# ─────────────────────────────────────────────────────────
+anti_patterns:
+  - Testing only the happy path flow (missing failure terminal states)
+  - Resetting shared state between steps in a journey test (breaks state threading)
+  - Testing each step in isolation without verifying accumulated state
+  - Using a single test case for a flow with multiple decision points (hides which branch failed)
+  - Applying Pairwise or All-Combinations to every flow (creates unmaintainable test counts; reserve for critical flows)
+  - Not verifying side effects (or absence of side effects) in branch tests
+  - Starting flow test from midpoint without establishing preconditions
+
+# ─────────────────────────────────────────────────────────
+# Quick Reference
+# ─────────────────────────────────────────────────────────
+quick_reference:
+  flow_test_checklist: |
+    Flow: ___________________
+
+    □ Step 1 — Flow Identification
+      □ Preconditions documented
+      □ Ordered step sequence listed (Step 1 → Step N)
+      □ All decision points extracted (every if/else/condition)
+      □ All terminal states defined (success + each distinct failure)
+
+    □ Step 2 — Decision Table
+      □ Decision table created with all values per decision point
+      □ Coverage strategy chosen (Each-Choice / Pairwise / All-Combinations)
+      □ Critical flows (auth/payment/security) use All-Combinations
+      □ Minimum scenario count = sum of unique values (Each-Choice)
+
+    □ Step 3 — Journey Test Structure
+      □ Happy path journey test exists (shared ctx, all steps in sequence)
+      □ Each branch outcome has its own describe block
+      □ Step assertions verify accumulated ctx state, not just final result
+      □ Branch tests verify both error response AND absence of side effects
+      □ No beforeEach resetting ctx between steps

package/bundled/ai/standards/iac-design-principles.ai.yaml

@@ -0,0 +1,83 @@
+# IaC Design Principles - AI Optimized
+# Source: XSPEC-065 Wave 4 IaC Pack
+
+id: iac-design-principles
+title: Infrastructure as Code Design Principles
+version: "1.0.0"
+status: Active
+tags: [iac, infrastructure, terraform, pulumi, cloudformation, immutable-infrastructure]
+summary: |
+  Defines the four foundational principles for Infrastructure as Code (IaC)
+  authoring: reproducible, immutable, idempotent, and versioned. Covers state
+  management requirements including remote state with locking, drift detection
+  categories, and CI/CD integration. Designed to ensure infrastructure changes
+  are traceable, reversible, and safe to apply repeatedly without unintended
+  side effects.
+
+requirements:
+  - id: REQ-001
+    title: IaC Four Principles
+    description: |
+      All infrastructure definitions MUST adhere to four foundational principles:
+      (1) Reproducible — given the same inputs and state, applying IaC produces
+      identical infrastructure. (2) Immutable — infrastructure changes are
+      applied by replacing resources, not mutating them in-place; blue/green or
+      rolling replacement patterns are preferred over in-place mutations.
+      (3) Idempotent — applying the same IaC configuration multiple times
+      produces the same result without error or unintended side effects.
+      (4) Versioned — all IaC definitions are stored in version control with
+      meaningful commit messages; no infrastructure change is made outside the
+      VCS workflow.
+    level: MUST
+    examples:
+      - "Terraform modules pinned to specific provider versions for reproducibility"
+      - "EC2 instance replacement via launch template version bump, not in-place AMI update"
+      - "`terraform apply` is safe to re-run; no manual pre-checks needed for idempotency"
+      - "All Pulumi programs committed to git; no ad-hoc CLI changes accepted"
+
+  - id: REQ-002
+    title: State Management
+    description: |
+      IaC state MUST be stored in a remote backend with locking enabled to
+      prevent concurrent modifications. Local state files MUST NOT be committed
+      to version control or used in CI/CD pipelines. Recommended backends:
+      Terraform Cloud / S3+DynamoDB (Terraform), Pulumi Service / S3 (Pulumi),
+      CloudFormation native stack state. State access MUST be restricted to
+      authorized principals via IAM or equivalent. State encryption at rest
+      is REQUIRED.
+    level: MUST
+    examples:
+      - "Terraform S3 backend with DynamoDB lock table; `.terraform/` in .gitignore"
+      - "Pulumi state stored in Pulumi Cloud with team access controls"
+      - "CI pipeline uses OIDC to assume role with state bucket access; no static credentials"
+      - "State file encrypted using AWS KMS customer-managed key"
+
+  - id: REQ-003
+    title: Drift Detection
+    description: |
+      Teams MUST run `plan` (or equivalent) in CI on every pull request to
+      detect configuration drift. Drift outcomes MUST be classified into one
+      of three categories and handled accordingly: (1) rollback-to-code —
+      actual infra deviates from code due to manual change; revert actual to
+      match code on next apply. (2) update-code-from-actual — actual reflects
+      intentional change not yet codified; update IaC to match, then apply.
+      (3) manual-reconcile — drift requires human judgment (e.g., data volume
+      changes); escalate to infra owner with documented decision. Drift reports
+      SHOULD be published to a team channel on a scheduled cadence (e.g., daily).
+    level: MUST
+    examples:
+      - "CI runs `terraform plan` on PR; plan output posted as PR comment"
+      - "Security group rule added via console → classified rollback-to-code; removed on next apply"
+      - "RDS storage autoscaled → classified update-code-from-actual; IaC updated to new size"
+      - "Daily drift scan via scheduled CI job; report posted to #infra-alerts Slack channel"
+
+anti_patterns:
+  - "Committing local state files (terraform.tfstate) to version control"
+  - "Applying mutable in-place changes (e.g., sed-patching running VMs) instead of replacing resources"
+  - "Making manual console changes without updating the corresponding IaC definition"
+  - "Using no remote locking, allowing concurrent applies that corrupt state"
+  - "Pinning to `latest` provider or module versions, breaking reproducibility"
+
+related_standards:
+  - containerization-standards
+  - secret-management-standards

package/bundled/ai/standards/incident-response.ai.yaml

@@ -0,0 +1,107 @@
+# Incident Response Standards - AI Optimized
+# Source: XSPEC-063 Wave 3 SRE Pack
+
+id: incident-response
+title: Incident Response Standards
+version: "1.0.0"
+status: Active
+tags: [sre, incident, oncall, postmortem, severity]
+summary: |
+  Defines the end-to-end incident response lifecycle: severity classification,
+  response time SLAs, roles and responsibilities, communication protocols,
+  escalation paths, and blameless postmortem requirements. Designed to reduce
+  MTTR, ensure consistent stakeholder communication during incidents, and
+  drive systemic reliability improvements through structured postmortems.
+
+requirements:
+  - id: REQ-001
+    title: Severity Classification
+    description: |
+      Every incident MUST be classified at declaration using a 4-level
+      severity scale. SEV-1 (Critical): complete service outage or data
+      breach affecting all users, response within 15 minutes, C-suite
+      notification. SEV-2 (High): major feature unavailable or significant
+      performance degradation >25% users, response within 30 minutes.
+      SEV-3 (Medium): minor feature unavailable or degradation <25% users,
+      response within 4 hours. SEV-4 (Low): cosmetic issue or very minor
+      impact, response within 24 hours.
+    level: MUST
+    examples:
+      - "SEV-1: Payment processing completely down → IC declared, bridge opened in <5min"
+      - "SEV-2: Checkout latency >10s for 30% of users → on-call paged, IC assigned"
+      - "SEV-3: Search autocomplete broken → ticket created, fix in next sprint"
+
+  - id: REQ-002
+    title: Incident Commander Role
+    description: |
+      Every SEV-1 and SEV-2 incident MUST have a designated Incident
+      Commander (IC) assigned within 10 minutes of declaration. The IC is
+      responsible for: coordinating the response bridge, assigning roles
+      (scribe, comms lead, technical leads), driving timeline, making
+      go/no-go decisions on fixes, and initiating postmortem. The IC does
+      NOT directly troubleshoot — their sole focus is coordination.
+    level: MUST
+    examples:
+      - "IC assignment: 'I'm taking IC for this SEV-2, @alice please scribe, @bob comms'"
+      - "IC checklist: bridge open, roles assigned, status page updated, stakeholders notified"
+      - "IC does not debug code; delegates to technical leads who report findings"
+
+  - id: REQ-003
+    title: Stakeholder Communication Protocol
+    description: |
+      During SEV-1/SEV-2 incidents, stakeholder updates MUST be sent on a
+      defined cadence: initial notification within 15 minutes of declaration,
+      updates every 30 minutes until resolution, immediate update on any
+      severity change or major development. Updates MUST include: current
+      status, known impact, what is being done, next update time. Status
+      page MUST be updated simultaneously with internal communications.
+    level: MUST
+    examples:
+      - "T+15min: 'We are investigating elevated error rates on checkout. ~500 users affected. Next update in 30min.'"
+      - "T+45min: 'Root cause identified as database connection pool exhaustion. Fix in progress. Next update in 30min.'"
+      - "Resolution: 'Service restored at 14:32 UTC. Postmortem scheduled for 2026-05-02.'"
+
+  - id: REQ-004
+    title: Blameless Postmortem Requirements
+    description: |
+      Every SEV-1 incident MUST have a blameless postmortem completed within
+      5 business days. SEV-2 incidents MUST have a postmortem within 10
+      business days. Postmortems MUST be blameless — focusing on systemic
+      causes, not individual mistakes. Required sections: timeline, impact,
+      root cause (5 Whys), contributing factors, action items with owners
+      and due dates, lessons learned. Action items MUST be tracked to
+      completion.
+    level: MUST
+    examples:
+      - "Timeline: 14:00 Alert fired → 14:05 IC assigned → 14:23 RCA found → 14:32 resolved"
+      - "Root cause: 5 Whys tracing alert → connection pool exhaustion → missing timeout config → no review gate"
+      - "Action item: INFRA-2341 Add connection pool monitoring, owner: @dave, due: 2026-05-15"
+
+  - id: REQ-005
+    title: On-Call Rotation and Handoff
+    description: |
+      Every production service MUST have a documented on-call rotation with
+      at least 2 engineers. Rotation schedules MUST be published at least
+      2 weeks in advance. On-call handoff MUST include a written summary of:
+      active incidents, recent incidents still under investigation,
+      known flaky alerts, upcoming planned maintenance, and any service
+      health concerns. Handoff MUST be acknowledged by incoming on-call.
+    level: MUST
+    examples:
+      - "Handoff doc: 3 active flaky alerts (JIRA links), 1 ongoing SEV-3, maintenance window Friday 02:00 UTC"
+      - "Rotation: 1-week shifts, 2 primary + 1 secondary, published monthly in PagerDuty"
+      - "Handoff acknowledgment: incoming engineer replies 'Handoff received, I have the pager'"
+
+  - id: REQ-006
+    title: Incident Retrospective Metrics
+    description: |
+      Teams SHOULD track and review incident metrics monthly: MTTD (Mean
+      Time To Detect), MTTR (Mean Time To Resolve), incident frequency by
+      severity, repeat incidents (same root cause within 90 days), and
+      postmortem action item completion rate. These metrics SHOULD be
+      reviewed in monthly reliability reviews with engineering leadership.
+    level: SHOULD
+    examples:
+      - "Monthly metrics: MTTD 8min, MTTR 42min, 3 SEV-2s, 0 SEV-1s, 0 repeat incidents"
+      - "Repeat incident flag: same DB timeout root cause in March and April → escalate to reliability sprint"
+      - "Action item completion rate: 85% of previous month's items closed on time"

package/bundled/ai/standards/license-compliance.ai.yaml

@@ -0,0 +1,106 @@
+# License Compliance Standards - AI Optimized
+# Source: XSPEC-066 Wave 3 Compliance Pack
+
+id: license-compliance
+title: License Compliance Standards
+version: "1.0.0"
+status: Active
+tags: [compliance, licensing, open-source, legal, supply-chain]
+summary: |
+  Defines how teams identify, track, and manage open-source and third-party
+  software licenses throughout the software development lifecycle. Covers
+  license classification (permissive vs. copyleft), prohibited licenses,
+  SBOM generation, license scanning in CI/CD, and remediation processes
+  for license violations. Designed to prevent legal exposure from
+  incompatible license combinations and ensure supply-chain transparency.
+
+requirements:
+  - id: REQ-001
+    title: License Classification and Allowlist
+    description: |
+      Every project MUST maintain a documented license policy classifying
+      licenses into three tiers. APPROVED: MIT, Apache 2.0, BSD-2-Clause,
+      BSD-3-Clause, ISC, CC0 — can be used without review. REVIEW-REQUIRED:
+      LGPL-2.1, LGPL-3.0, MPL-2.0, CDDL — requires legal/architecture
+      review before adoption. PROHIBITED: GPL-2.0 (without exception),
+      GPL-3.0, AGPL-3.0, SSPL, Commons Clause additions — MUST NOT be
+      included in proprietary or commercial products.
+    level: MUST
+    examples:
+      - "MIT dependency lodash → auto-approved, no review needed"
+      - "LGPL-3.0 dependency → open GitHub issue tagged 'license-review' before merging"
+      - "GPL-3.0 dependency found in PR → PR blocked by CI until dependency replaced"
+
+  - id: REQ-002
+    title: Automated License Scanning in CI
+    description: |
+      Every repository MUST run automated license scanning on every pull
+      request and on a daily scheduled basis. The scan MUST fail the build
+      if any PROHIBITED license is detected in direct or transitive
+      dependencies. REVIEW-REQUIRED licenses MUST generate a warning that
+      blocks merge until manually approved and documented. Scan results
+      MUST be stored as build artifacts for 1 year.
+    level: MUST
+    examples:
+      - "CI step: `npx license-checker --onlyAllow 'MIT;Apache-2.0;BSD-2-Clause;BSD-3-Clause;ISC'`"
+      - "Daily scheduled scan via GitHub Actions: runs license-checker across all repos"
+      - "Build artifact: license-report-2026-04-30.json retained for 1 year"
+
+  - id: REQ-003
+    title: Software Bill of Materials (SBOM) Generation
+    description: |
+      Every production release MUST include a Software Bill of Materials
+      (SBOM) in SPDX 2.3 or CycloneDX 1.5 format. The SBOM MUST list all
+      direct and transitive dependencies with: package name, version,
+      license identifier (SPDX), and supplier. SBOMs MUST be generated
+      automatically as part of the release pipeline and stored alongside
+      release artifacts.
+    level: MUST
+    examples:
+      - "SBOM generated via: `syft . -o spdx-json > sbom-v1.2.0.spdx.json`"
+      - "SBOM uploaded to release: GitHub Release v1.2.0 includes sbom-v1.2.0.spdx.json"
+      - "SBOM SPDX entry: {name: 'lodash', version: '4.17.21', licenseConcluded: 'MIT'}"
+
+  - id: REQ-004
+    title: License Attribution and Notices
+    description: |
+      Products distributed to external users MUST include a NOTICES or
+      LICENSE-THIRD-PARTY file listing all open-source components and their
+      license texts. This file MUST be auto-generated from the SBOM data.
+      For web applications, attribution MUST be accessible via a dedicated
+      page or endpoint (e.g., /licenses or /legal/notices).
+    level: MUST
+    examples:
+      - "NOTICES file auto-generated: `npx generate-license-file --input package.json --output NOTICES`"
+      - "Web app: GET /legal/notices returns HTML page with all dependency licenses"
+      - "Mobile app: 'Open Source Licenses' screen in Settings menu"
+
+  - id: REQ-005
+    title: License Violation Remediation Process
+    description: |
+      When a license violation is detected, teams MUST follow the remediation
+      process: (1) immediately block merge/release if PROHIBITED license;
+      (2) create a tracking issue within 1 business day; (3) remediate
+      within 5 business days for PROHIBITED, 30 days for REVIEW-REQUIRED;
+      (4) document decision and alternative chosen; (5) update SBOM and
+      re-scan to verify clean. Unresolved violations MUST be reported to
+      the engineering lead monthly.
+    level: MUST
+    examples:
+      - "Violation: transitive dep uses GPL-3.0 → PR blocked, issue COMP-112 created same day"
+      - "Remediation: replaced dep with MIT-licensed alternative within 3 days"
+      - "Monthly report: 0 open violations as of 2026-04-30"
+
+  - id: REQ-006
+    title: License Review for New Technology Adoption
+    description: |
+      Before adopting any new framework, library, or tool, engineers SHOULD
+      verify its license tier as part of the technology evaluation. License
+      status SHOULD be documented in the relevant ADR or technical spike
+      document. For REVIEW-REQUIRED licenses, architecture review board
+      approval MUST be obtained before adoption.
+    level: SHOULD
+    examples:
+      - "ADR-042 notes: 'Library X uses Apache 2.0 — approved tier, no legal review needed'"
+      - "ADR-043 notes: 'Library Y uses LGPL-3.0 — review-required, legal approved 2026-03-10'"
+      - "Technology radar entry includes license classification for each evaluated tool"