universal-dev-standards 5.3.2 → 5.5.0

package/bundled/ai/standards/audit-trail.ai.yaml

@@ -0,0 +1,113 @@
+# Audit Trail Standards - AI Optimized
+# Source: XSPEC-066 Wave 3 Compliance Pack
+
+id: audit-trail
+title: Audit Trail Standards
+version: "1.0.0"
+status: Active
+tags: [compliance, audit, logging, security, governance, traceability]
+summary: |
+  Defines the requirements for creating, storing, and managing immutable
+  audit trails across systems handling sensitive data, financial transactions,
+  access control changes, and compliance-relevant operations. Covers mandatory
+  event types, audit record schema, tamper-evidence requirements, retention
+  periods, query and export capabilities, and integration with SIEM systems.
+  Designed to satisfy SOC 2, ISO 27001, GDPR, and financial regulatory
+  requirements.
+
+requirements:
+  - id: REQ-001
+    title: Mandatory Auditable Event Types
+    description: |
+      Systems MUST capture audit records for the following event categories
+      without exception: (1) Authentication events — login success/failure,
+      logout, MFA events, password changes; (2) Authorization events — access
+      granted/denied, privilege escalation, role changes; (3) Data access —
+      read/write/delete of TIER-1 and TIER-2 PII, bulk data exports;
+      (4) Configuration changes — system settings, security policy changes,
+      user/role management; (5) Financial transactions — payment processing,
+      refunds, balance changes; (6) Compliance-relevant actions — consent
+      changes, data erasure requests, legal holds.
+    level: MUST
+    examples:
+      - "Auth event: {type: 'LOGIN_FAILURE', user_id: 'u123', ip: '1.2.3.4', timestamp: '...'}"
+      - "Data access: {type: 'PII_READ', user_id: 'admin1', record_id: 'customer:456', fields: ['ssn']}"
+      - "Config change: {type: 'ROLE_GRANTED', admin_id: 'u789', target_user: 'u123', role: 'payments-admin'}"
+
+  - id: REQ-002
+    title: Audit Record Schema
+    description: |
+      Every audit record MUST contain the following mandatory fields:
+      event_id (UUID v4), event_type (enumerated string), timestamp (ISO 8601
+      UTC with milliseconds), actor_id (user or service account), actor_ip
+      (for user actions), resource_type, resource_id, action, outcome
+      (success/failure), and environment (production/staging). SHOULD also
+      include: session_id, request_id for correlation, before/after state
+      for mutations, and geographic region.
+    level: MUST
+    examples:
+      - "{event_id: 'a1b2c3d4-...', event_type: 'USER_LOGIN', timestamp: '2026-04-30T14:23:01.456Z', actor_id: 'u123', actor_ip: '1.2.3.4', outcome: 'success'}"
+      - "Mutation record includes: before_state: {role: 'viewer'}, after_state: {role: 'admin'}"
+      - "Service account action: actor_id: 'svc:payment-processor', actor_ip: omitted (internal)"
+
+  - id: REQ-003
+    title: Immutability and Tamper Evidence
+    description: |
+      Audit logs MUST be written to an append-only store that prevents
+      modification or deletion by application-level principals. Audit
+      records MUST include a cryptographic hash of the previous record
+      (chaining) to detect tampering. Write access to the audit log store
+      MUST be restricted to the audit service only — no engineer or
+      application service should have direct write access. Log integrity
+      MUST be verifiable on demand.
+    level: MUST
+    examples:
+      - "Audit log stored in append-only S3 with Object Lock (WORM) enabled"
+      - "Each record includes: prev_hash: SHA-256 of previous record's canonical JSON"
+      - "Integrity check: `audit-tool verify --from 2026-04-01 --to 2026-04-30` returns 'Chain intact'"
+
+  - id: REQ-004
+    title: Audit Log Retention Periods
+    description: |
+      Audit logs MUST be retained according to the following minimums by
+      category: authentication/authorization events — 1 year hot, 6 years
+      cold (SOC 2 / ISO 27001); financial transaction events — 7 years
+      (financial regulations); PII access events — 3 years; configuration
+      changes — 3 years; all other audit events — 1 year. Deletion of
+      audit records before their retention period expires is PROHIBITED.
+      Logs approaching expiry MUST be automatically archived to cold storage.
+    level: MUST
+    examples:
+      - "Auth logs: S3 lifecycle rule → Standard 1 year → Glacier 5 years additional → delete"
+      - "Financial events: Glacier Deep Archive after 1 year, retained 7 years total"
+      - "Automated alert: 'Audit log retention policy violation detected in logs/auth/2019/'"
+
+  - id: REQ-005
+    title: Audit Log Query and Export Capability
+    description: |
+      The audit system MUST provide query capabilities supporting: filter by
+      event_type, actor_id, resource_id, time range, and outcome. Query
+      results MUST be exportable in JSON and CSV formats. Queries returning
+      PII MUST themselves be logged as audit events. Audit data MUST be
+      accessible to authorized compliance and security teams within 4 hours
+      of a data request, and to regulators within 24 hours.
+    level: MUST
+    examples:
+      - "Query: GET /audit?actor_id=u123&from=2026-04-01&to=2026-04-30&event_type=PII_READ"
+      - "Export: POST /audit/export {format: 'csv', query: {...}} → download link in 5 minutes"
+      - "Query-of-query logged: {type: 'AUDIT_QUERY', queried_by: 'compliance-team', params: {...}}"
+
+  - id: REQ-006
+    title: SIEM Integration and Alerting
+    description: |
+      Audit logs SHOULD be forwarded in real-time to a SIEM (Security
+      Information and Event Management) system. SIEM SHOULD have automated
+      detection rules for: brute-force login patterns (>5 failures in 5min),
+      privilege escalation outside business hours, bulk PII exports (>1000
+      records in 1 hour), and access from new geographic regions. Alerts
+      SHOULD trigger on-call notification for high-severity detections.
+    level: SHOULD
+    examples:
+      - "Splunk/Elastic forwarding: audit events streamed via Kafka to SIEM in <30 seconds"
+      - "Detection rule: 5+ login failures same user in 5min → PagerDuty P2 alert"
+      - "Geo-anomaly: login from new country after 30+ days of consistent region → security review"

package/bundled/ai/standards/branch-completion.ai.yaml

@@ -1,82 +1,46 @@
-# Branch Completion Workflow - AI Optimized
-# Source: core/branch-completion.md
-# Inspired by Superpowers finishing-a-development-branch (MIT)
+# Branch Completion Workflow - DEPRECATED STUB
+# This file has been migrated to DevAP per DEC-049 (UDS/DevAP responsibility split).
+# Canonical location: dev-autopilot/standards/flow/branch-completion.ai.yaml
+# Migration: XSPEC-086 Phase 2 (2026-04-27)
+#
+# Human-readable standard: core/branch-completion.md (remains in UDS)
+# Deprecation schedule: UDS 5.4.0 deprecated → UDS 6.0.0 removed
 
 standard:
   id: branch-completion
-  name: Branch Completion Workflow
-  description: 分支完成工作流標準
-
   meta:
-    version: "1.0.0"
-    updated: "2026-03-20"
+    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/branch-completion.ai.yaml"
     source: core/branch-completion.md
-    description: 分支完成決策與清理標準
-    inspired_by: superpowers/finishing-a-development-branch
+    description: >
+      DEPRECATED: This standard has moved to DevAP (flow orchestration layer).
+      Install DevAP and load standards/flow/branch-completion.ai.yaml instead.
 
-  guidelines:
-    - "測試全過才能談完成"
-    - "提供 4 個完成選項讓使用者選擇"
-    - "Discard 需要明確確認，防止誤刪"
-    - "Worktree 對應分支完成後必須清理"
+  rules:
+    - id: deprecation-notice
+      trigger: any branch completion operation
+      instruction: >
+        This standard (branch-completion.ai.yaml) has been migrated to DevAP.
+        For the canonical executable definition, load:
+          dev-autopilot/standards/flow/branch-completion.ai.yaml
 
-  prerequisites:
-    - "所有測試通過"
-    - "lint 通過"
-    - "type check 通過"
-    - "無未提交的變更"
+        The human-readable standard remains at:
+          universal-dev-standards/core/branch-completion.md
 
-  options:
-    - id: merge_locally
-      description: "合併到目標分支"
-      steps:
-        - "git checkout <target>"
-        - "git merge --no-ff <branch>"
-        - "刪除分支"
-        - "清理 worktree（若有）"
-    - id: create_pr
-      description: "建立 Pull Request"
-      steps:
-        - "推送分支到 remote"
-        - "建立 PR（含描述與測試計畫）"
-        - "等待審查"
-    - id: keep_as_is
-      description: "保持現狀不動"
-      steps:
-        - "記錄分支狀態"
-        - "提醒使用者稍後處理"
-    - id: discard
-      description: "丟棄所有變更"
-      steps:
-        - "要求使用者明確確認（輸入分支名稱）"
-        - "刪除分支（git branch -D）"
-        - "清理 worktree（若有）"
+        To install DevAP: npm install -g @devap/cli
+      priority: required
 
-  rules:
-    - id: BC-001
-      trigger: "使用者選擇 discard"
-      action: "要求輸入分支名稱確認，防止誤刪"
-      priority: critical
-    - id: BC-002
-      trigger: "分支有 worktree"
-      action: "完成後自動清理 worktree"
-      priority: high
     - id: BC-003
       trigger: "前置條件未滿足"
-      action: "阻止完成，顯示失敗的檢查項目"
-      priority: high
-    - id: BC-004
-      trigger: "分支閒置超過 14 天"
-      action: "通知使用者完成或丟棄"
-      priority: medium
+      instruction: >
+        DEPRECATED — load dev-autopilot/standards/flow/branch-completion.ai.yaml
+        for the current executable branch completion flow.
 
-physical_spec:
-  type: checklist
-  validator:
-    type: ai_review
-    rule: "檢查分支完成是否遵循前置條件檢查和四選項流程"
-  checks:
-    - "完成前是否通過所有前置條件（測試、lint、type check）"
-    - "是否提供完成選項供使用者選擇"
-    - "Discard 操作是否要求明確確認"
-    - "關聯的 worktree 是否被清理"
+        Minimal fallback: Block branch completion when prerequisites (tests, lint,
+        type check, no uncommitted changes) are not met.
+      priority: high

package/bundled/ai/standards/change-batching-standards.ai.yaml

@@ -1,195 +1,46 @@
-# Change Batching Standards - AI Optimized
-# Source: core/change-batching-standards.md
+# Change Batching Standards - DEPRECATED STUB
+# This file has been migrated to DevAP per DEC-049 (UDS/DevAP responsibility split).
+# Canonical location: dev-autopilot/standards/flow/change-batching-standards.ai.yaml
+# Migration: XSPEC-086 Phase 2 (2026-04-27)
+#
+# Human-readable standard: core/change-batching-standards.md (remains in UDS)
+# Deprecation schedule: UDS 5.4.0 deprecated → UDS 6.0.0 removed
 
 standard:
   id: change-batching-standards
-  name: Change Batching Standards
-  description: Pending changes state machine, threshold strategies, and atomicity guarantees for batch commits
-
   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/change-batching-standards.ai.yaml"
     source: core/change-batching-standards.md
-    references:
-      - "SWEBOK v4.0 Chapter 6 (Software Configuration Management)"
-      - "ISO/IEC 12207 (Configuration Management Process)"
-      - "Continuous Delivery (Jez Humble) — Small batch sizes"
-      - "Lean Software Development — Batch size optimization"
-
-  state_machine:
-    description: Pending changes lifecycle
-    states:
-      - state: PENDING
-        description: Change recorded, waiting for threshold
-      - state: READY
-        description: Threshold met, batch prepared for merge
-      - state: MERGED
-        description: Batch successfully committed
-      - state: FAILED
-        description: Merge attempt failed
-      - state: ARCHIVED
-        description: Post-commit record for audit
-
-    transitions:
-      - from: PENDING
-        to: PENDING
-        trigger: New change added
-        action: Increment counters, re-evaluate thresholds
-      - from: PENDING
-        to: READY
-        trigger: Threshold met
-        action: Prepare merge batch, run pre-merge validation
-      - from: READY
-        to: MERGED
-        trigger: Merge succeeds
-        action: Create commit, clear batch, archive
-      - from: READY
-        to: FAILED
-        trigger: Merge fails
-        action: Log failure, preserve changes
-      - from: FAILED
-        to: PENDING
-        trigger: Reset
-        action: Re-queue changes, clear failure state
-      - from: MERGED
-        to: ARCHIVED
-        trigger: Post-commit
-        action: Record batch metadata for audit
-
-  threshold_strategies:
-    strategies:
-      - name: count
-        parameter: maxChanges
-        default: 5
-        description: Merge after N individual changes accumulated
-
-      - name: score
-        parameter: maxScore
-        default: 10
-        description: Merge when cumulative change score >= M
-
-      - name: time
-        parameter: maxAge
-        default: "30m"
-        description: Merge when oldest pending change exceeds TTL
-
-      - name: manual
-        parameter: null
-        default: null
-        description: Merge only on explicit user request
-
-    change_scoring:
-      - type: trivial
-        score: 1
-        example: Typo fix, whitespace, comment update
-      - type: minor
-        score: 2
-        example: Single function change, variable rename
-      - type: standard
-        score: 3
-        example: New function, modified logic flow
-      - type: complex
-        score: 5
-        example: Multi-file change, API modification
-      - type: critical
-        score: 8
-        example: Schema change, breaking change
-
-    composite_rule: "Multiple thresholds combine with OR logic (first met triggers merge)"
-
-  merge_rules:
-    priority_order:
-      - Same-spec affinity — changes referencing same SPEC-ID merge first
-      - Same-file grouping — changes to same files merge together
-      - Dependency order — changes with dependencies merge in order
-      - Chronological — within same priority, merge by creation time
-
-    conflict_resolution:
-      - type: Same line, same file
-        strategy: Latest change wins
-        fallback: Manual resolution
-      - type: Overlapping functions
-        strategy: Semantic merge if possible
-        fallback: Manual resolution
-      - type: Dependency conflict
-        strategy: Resolve dependency first
-        fallback: Reject batch, split
-
-    pre_merge_validation:
-      - check: All tests pass
-        required: true
-      - check: No lint errors
-        required: true
-      - check: No conflicts
-        required: true
-      - check: AC coverage maintained
-        required: false
-        note: Recommended
-
-  atomicity:
-    principle: All-or-nothing
-    rules:
-      - Single commit — each merged batch produces exactly one commit
-      - No partial merge — any change failure rejects entire batch
-      - Rollback support — failed merges restore all changes to PENDING
-      - Isolation — batch merge does not affect changes outside batch
-
-  rollback:
-    on_failure:
-      - Log failure with batch details
-      - Return all changes to PENDING state
-      - Diagnose failing change(s)
-      - Options — fix and retry, remove failing change, split batch
-
-    triggers:
-      - trigger: Test failure
-        action: Reject entire batch
-        automatic: true
-      - trigger: Lint error
-        action: Reject entire batch
-        automatic: true
-      - trigger: Merge conflict
-        action: Reject and notify
-        automatic: true
-      - trigger: Build failure
-        action: Reject entire batch
-        automatic: true
-      - trigger: Manual rejection
-        action: Return to PENDING
-        automatic: false
+    description: >
+      DEPRECATED: This standard has moved to DevAP (flow orchestration layer).
+      Install DevAP and load standards/flow/change-batching-standards.ai.yaml instead.
 
   rules:
-    - id: set-thresholds
-      trigger: configuring batch pipeline
-      instruction: Set explicit thresholds; do not accumulate changes indefinitely
-      priority: required
+    - id: deprecation-notice
+      trigger: any batch change operation
+      instruction: >
+        This standard (change-batching-standards.ai.yaml) has been migrated to DevAP.
+        For the canonical executable definition, load:
+          dev-autopilot/standards/flow/change-batching-standards.ai.yaml
 
-    - id: group-by-spec
-      trigger: batching changes
-      instruction: Group changes by specification or feature for cohesive commits
-      priority: recommended
+        The human-readable standard remains at:
+          universal-dev-standards/core/change-batching-standards.md
 
-    - id: validate-before-merge
-      trigger: batch reaches READY state
-      instruction: Run full validation (tests, lint, conflicts) before merging
+        To install DevAP: npm install -g @devap/cli
       priority: required
 
     - id: atomic-commits
       trigger: merging a batch
-      instruction: Enforce all-or-nothing — either all changes commit or none do
-      priority: required
+      instruction: >
+        DEPRECATED — load dev-autopilot/standards/flow/change-batching-standards.ai.yaml
+        for the current executable batch orchestration rules.
 
-    - id: preserve-on-failure
-      trigger: batch merge fails
-      instruction: Return all changes to PENDING state; never lose changes
+        Minimal fallback: Enforce all-or-nothing batch merging — either all changes
+        commit or none do.
       priority: required
-
-    - id: log-batch-decisions
-      trigger: any batch state transition
-      instruction: Log batch decisions (threshold met, merge result) for auditability
-      priority: recommended
-
-related_standards:
-  - checkin-standards.md
-  - pipeline-integration-standards.md
-  - commit-message-guide.md

package/bundled/ai/standards/chaos-injection-tests.ai.yaml

@@ -0,0 +1,91 @@
+# Chaos Injection Test Standards - AI Optimized
+# Source: core/chaos-injection-tests.md
+
+id: chaos-injection-tests
+meta:
+  version: "1.0.0"
+  updated: "2026-05-05"
+  source: core/chaos-injection-tests.md
+  description: Executable chaos injection tests for AI agent systems — DB disconnect, LLM timeout, policy engine failure
+
+requirements:
+  REQ-1:
+    id: REQ-CIT-001
+    title: Dependency Failure Isolation Test
+    rule: >
+      Each external dependency (database, LLM API, policy engine, queue) MUST have at
+      least one chaos test that simulates its complete unavailability and verifies the
+      system fails gracefully (returns a well-defined error, does not panic, does not
+      corrupt state).
+    rationale: >
+      AI agent systems have more external dependencies than traditional software;
+      a single dependency failure should not cascade to full system failure.
+
+  REQ-2:
+    id: REQ-CIT-002
+    title: LLM Timeout and Rate-Limit Chaos Test
+    rule: >
+      The LLM client MUST be tested under simulated timeout (response after deadline)
+      and rate-limit (429 status) conditions. The system MUST: surface a typed error,
+      respect retry-with-backoff policy, and not hang indefinitely.
+    rationale: >
+      LLM APIs are the highest-latency and most rate-limited dependency in AI systems;
+      timeout handling is safety-critical for any real-time pipeline.
+
+  REQ-3:
+    id: REQ-CIT-003
+    title: Policy Engine Fail-Closed Test
+    rule: >
+      When the policy engine (e.g., OPA sidecar) is unavailable, the system MUST
+      default to DENY (fail-closed), not to ALLOW (fail-open). A chaos test MUST
+      simulate policy engine unavailability and assert DENY behavior.
+    rationale: >
+      Fail-open on policy engine failure is a security vulnerability; the chaos test
+      makes this invariant machine-verifiable.
+
+  REQ-4:
+    id: REQ-CIT-004
+    title: Database Disconnect Recovery Test
+    rule: >
+      The system MUST be tested under database disconnect mid-operation. The test MUST
+      verify: transaction is rolled back (no partial write), connection pool recovers
+      within N seconds, and subsequent operations succeed after reconnect.
+    rationale: >
+      Database disconnects happen during maintenance windows and network partitions;
+      partial writes without rollback are the primary source of data corruption.
+
+  REQ-5:
+    id: REQ-CIT-005
+    title: Blast Radius Containment Test
+    rule: >
+      Chaos tests MUST verify that a failure in one agent or subsystem does not
+      propagate to unrelated agents. Inter-agent failure isolation MUST be tested
+      via simulated agent crash mid-pipeline.
+    rationale: >
+      In multi-agent pipelines, unchecked error propagation is the primary cause of
+      full pipeline failure when only one component fails.
+
+injection_patterns:
+  lm_timeout:
+    technique: "Mock LLM client to delay response beyond timeout deadline"
+    assertions: ["Error type is TimeoutError", "Retry count equals policy", "No deadlock"]
+  db_disconnect:
+    technique: "Close DB connection mid-transaction via test hook or jest.spyOn"
+    assertions: ["Transaction rolled back", "No partial rows written", "Pool reconnects"]
+  policy_engine_down:
+    technique: "Mock OPA HTTP client to return connection refused (ECONNREFUSED)"
+    assertions: ["Decision is DENY", "Error is logged at WARN+", "No state mutation"]
+  rate_limit:
+    technique: "Mock LLM client to return 429 with Retry-After header"
+    assertions: ["Backoff respects Retry-After", "Final error surfaces to caller"]
+
+safety_rules:
+  - "Never run chaos tests against production or shared staging databases"
+  - "Chaos tests MUST clean up injected faults in afterEach/finally blocks"
+  - "Tag chaos tests with a dedicated suite marker to exclude from fast unit test runs"
+
+related_standards:
+  - chaos-engineering-standards
+  - testing
+  - security-standards
+  - secure-op

package/bundled/ai/standards/container-image-standards.ai.yaml

@@ -0,0 +1,88 @@
+# Container Image Standards - AI Optimized
+# Source: XSPEC-065 Wave 4 IaC Pack
+
+id: container-image-standards
+title: Container Image Build and Security Standards
+version: "1.0.0"
+status: Active
+tags: [container, docker, dockerfile, sbom, security, supply-chain]
+summary: |
+  Defines security and compliance requirements for container image build
+  pipelines. Covers five Dockerfile authoring principles (multi-stage builds,
+  non-root execution, minimal base images, secret-free build args, SBOM
+  metadata), SBOM generation and embedding using syft or trivy, and image
+  scanning policies that block Critical/High CVEs. Complements the existing
+  containerization-standards (layer ordering and tagging) by focusing on
+  supply-chain security and compliance attestation.
+
+requirements:
+  - id: REQ-001
+    title: Dockerfile Five Principles
+    description: |
+      Every production Dockerfile MUST follow five principles:
+      (1) Multi-stage build — use separate builder and runtime stages to
+      minimize final image size and attack surface.
+      (2) Non-root final user — the runtime stage MUST set a non-root USER
+      (UID ≥ 1000); running as root in production containers is prohibited.
+      (3) Distroless or Alpine base — use distroless (gcr.io/distroless) or
+      Alpine-based images as the final stage to minimize CVE exposure; avoid
+      full Debian/Ubuntu unless justified and documented.
+      (4) No hardcoded secrets — build ARGs and ENV variables MUST NOT contain
+      secrets; secrets are injected at runtime via volume mounts or secret
+      managers.
+      (5) SBOM metadata label — the final image MUST include an OCI label
+      `org.opencontainers.image.source` and a build-time label
+      `org.opencontainers.image.revision` containing the git commit SHA.
+    level: MUST
+    examples:
+      - "FROM node:20-alpine AS builder ... FROM gcr.io/distroless/nodejs20 AS runtime"
+      - "RUN addgroup -S app && adduser -S app -G app ... USER app"
+      - "LABEL org.opencontainers.image.revision=$GIT_SHA"
+      - "Secrets passed via `--mount=type=secret` in BuildKit, not ENV"
+
+  - id: REQ-002
+    title: SBOM Embedding
+    description: |
+      Every production container image MUST have a Software Bill of Materials
+      (SBOM) generated during the CI build step. SBOM MUST be generated using
+      syft or trivy in CycloneDX or SPDX format. The SBOM MUST be either:
+      (a) embedded as an OCI image annotation (preferred for OCI-compliant
+      registries), or (b) attached as a cosign attestation to the image digest.
+      SBOM artifacts MUST be stored alongside the image in the container
+      registry and retained for at least 12 months for compliance audits.
+    level: MUST
+    examples:
+      - "`syft packages docker:myapp:latest -o spdx-json > sbom.spdx.json`"
+      - "`cosign attest --type spdx --predicate sbom.spdx.json myregistry/myapp@sha256:...`"
+      - "SBOM attached to image in ECR; lifecycle policy retains for 365 days"
+      - "OCI annotation `org.opencontainers.image.sbom` pointing to SBOM digest"
+
+  - id: REQ-003
+    title: Image Scanning
+    description: |
+      All container images MUST be scanned for known CVEs before being pushed
+      to a production registry. Scanning MUST be integrated into the CI pipeline
+      using trivy, grype, or equivalent. Severity policy: Critical and High CVEs
+      MUST block the build and prevent image promotion to production; Medium CVEs
+      MUST generate a warning and create a tracked ticket; Low and Negligible CVEs
+      are informational only. Base image updates MUST be triggered automatically
+      when upstream images receive CVE patches (e.g., via Dependabot or Renovate
+      for Dockerfile base image pins).
+    level: MUST
+    examples:
+      - "`trivy image --exit-code 1 --severity CRITICAL,HIGH myapp:latest`"
+      - "CI step fails with exit code 1 on Critical CVE; build blocked from promotion"
+      - "Medium CVE detected → Jira ticket auto-created with CVE ID and affected package"
+      - "Renovate configured to auto-PR Dockerfile base image updates weekly"
+
+anti_patterns:
+  - "Using `latest` tag for base images in production Dockerfiles (non-reproducible builds)"
+  - "Running container processes as root (UID 0) in the final runtime stage"
+  - "Embedding secrets in Docker build ARGs or ENV variables that persist in image layers"
+  - "Skipping SBOM generation to save CI time, losing supply-chain traceability"
+  - "Pushing images to production without CVE scanning results"
+
+related_standards:
+  - containerization-standards
+  - secret-management-standards
+  - iac-design-principles