universal-dev-standards 5.2.0 → 5.3.1

package/bundled/ai/options/release/publish-mode-github-actions.ai.yaml

@@ -0,0 +1,65 @@
+# Release Option: GitHub Actions Publish Mode - AI Optimized
+# Parent: release-standards
+# Source: options/release/publish-mode-github-actions.md
+
+id: publish-mode-github-actions
+meta:
+  parent: release-standards
+  version: "1.0.0"
+  updated: "2026-04-24"
+  source: options/release/publish-mode-github-actions.md
+  description: CD publish pattern for npm packages — publish is triggered automatically by GitHub Release, not by manual `npm publish`
+
+best_for:
+  - npm packages hosted in GitHub repositories
+  - Projects with GitHub Actions publish workflow (publish.yml or similar)
+  - Single-owner or small-team repos using GitHub Actions CD
+  - Projects where NPM_TOKEN is stored as a GitHub Actions secret
+
+configuration:
+  publish_mode: github-actions
+  publish_trigger: gh_release_create
+  publish_command: none  # npm publish is handled by GitHub Actions
+  tag_format: "v{semver}"
+
+behaviors:
+  release_finish_sequence:
+    steps:
+      - bump_version      # scripts/bump-version.sh or npm version
+      - update_changelog  # add [X.Y.Z] section, remove from [Unreleased]
+      - commit_and_tag    # git commit + git tag vX.Y.Z
+      - push_with_tag     # git push origin main vX.Y.Z
+      - create_gh_release # gh release create vX.Y.Z --title "vX.Y.Z" --notes "..."
+    note: >
+      DO NOT run `npm publish` manually. The `gh release create` command triggers
+      the publish workflow via `release: published` event. GitHub Actions handles
+      the actual npm publish using NPM_TOKEN stored as a repository secret.
+
+  gh_release_create:
+    command: 'gh release create v{version} --title "v{version}" --notes "{changelog_entry}"'
+    triggers: publish_workflow
+    publishes_to_npm_tag:
+      stable: latest       # versions without pre-release suffix (e.g. 5.2.0)
+      prerelease: next      # versions with beta/alpha/rc suffix (e.g. 5.2.0-beta.1)
+
+  publish_workflow:
+    trigger_event: "release: published"
+    secret_required: NPM_TOKEN
+    runs_on: github_actions
+    note: >
+      Workflow file is typically `.github/workflows/publish.yml`.
+      It runs `npm publish` with `NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}`.
+
+  local_verification:
+    before_release:
+      - run_tests         # npm test / vitest
+      - verify_build      # npm run build (if applicable)
+      - check_version     # confirm package.json version matches intended tag
+    note: All local gates must pass before `gh release create`
+
+comparison_with_manual_mode:
+  publish_command: "not run locally"    # manual: npm publish
+  publish_trigger: gh_release_create   # manual: direct npm publish
+  npm_token_location: github_secret    # manual: local .npmrc or env var
+  audit_trail: github_actions_log      # manual: none (local terminal)
+  reproducibility: full_ci_isolation   # manual: depends on local environment

package/bundled/ai/standards/cd-deployment-strategies.ai.yaml

@@ -0,0 +1,73 @@
+# CD Deployment Strategies (AI-Optimized v1)
+# Source: core/cd-deployment-strategies.md
+
+standard:
+  id: cd-deployment-strategies
+  name: CD Deployment Strategies
+  description: Strategy selection matrix for blue-green, canary, rolling, and recreate deployments
+  guidelines:
+    - "Choose strategy based on: traffic volume × risk tolerance × infrastructure cost"
+    - "High traffic + low risk tolerance → blue-green (instant rollback)"
+    - "Medium traffic + medium risk → canary (progressive validation)"
+    - "Low traffic + low risk → rolling (resource efficient)"
+    - "Dev/internal only → recreate (simplest, acceptable downtime)"
+    - "Never deploy directly to production without staging validation"
+
+  meta:
+    version: "1.0.0"
+    updated: "2026-04-26"
+    source: core/cd-deployment-strategies.md
+    parent: deployment-standards.ai.yaml
+
+strategy_matrix:
+  blue_green:
+    traffic: high
+    risk_tolerance: low
+    infrastructure_cost: high
+    downtime: zero
+    rollback_time: "<30s"
+    use_cases: ["stateful services", "database-compatible changes", "high-SLA APIs"]
+    prerequisites: ["dual environment", "load balancer", "health checks"]
+  canary:
+    traffic: medium_to_high
+    risk_tolerance: medium
+    infrastructure_cost: medium
+    downtime: zero
+    rollback_time: "<2min"
+    use_cases: ["feature validation", "A/B testing", "high-risk changes"]
+    traffic_stages: ["1%", "5%", "25%", "50%", "100%"]
+    prerequisites: ["traffic splitting", "observability", "auto-promotion rules"]
+  rolling:
+    traffic: any
+    risk_tolerance: medium
+    infrastructure_cost: low
+    downtime: minimal
+    rollback_time: "minutes"
+    use_cases: ["stateless services", "standard updates", "batch workers"]
+    prerequisites: ["multiple instances", "health checks"]
+  recreate:
+    traffic: low
+    risk_tolerance: high
+    infrastructure_cost: minimal
+    downtime: "seconds to minutes"
+    rollback_time: "minutes"
+    use_cases: ["dev/staging", "internal tools", "single-instance services"]
+    prerequisites: ["none"]
+
+decision_tree:
+  step_1: "Is zero-downtime required? No → recreate; Yes → continue"
+  step_2: "Is traffic > 10k req/min? Yes → blue-green or canary; No → rolling"
+  step_3: "Is change high-risk? Yes → canary; No → blue-green or rolling"
+  step_4: "Is infrastructure budget constrained? Yes → rolling; No → blue-green"
+
+no_cicd_compatibility:
+  blue_green: "See no-cicd-deployment.ai.yaml for script-based implementation"
+  canary: "Requires Nginx split_clients or HAProxy for script-based canary"
+  rolling: "Achievable with sequential rsync + health check loop"
+  recreate: "Simplest — stop, deploy, start"
+
+physical_spec:
+  type: custom_script
+  validator:
+    command: "grep -r 'deployment_strategy\\|deploy.*strategy' . --include='*.yaml' --include='*.json' -l 2>/dev/null | head -1"
+    rule: "deployment_strategy_documented"

package/bundled/ai/standards/no-cicd-deployment.ai.yaml

@@ -0,0 +1,134 @@
+# No-CI/CD Deployment Strategy (AI-Optimized v1)
+# Source: core/no-cicd-deployment.md
+
+standard:
+  id: no-cicd-deployment
+  name: No-CI/CD Deployment Strategy
+  description: Reliable deployment without CI/CD platforms using shell scripts, smoke tests, Blue-Green switching, and deploy.lock protection
+  guidelines:
+    - "Use set -euo pipefail in all deploy scripts — fail fast, stop on first error"
+    - "Always verify deployment after completion — check version endpoint, never assume success"
+    - "Maintain Blue-Green slots for instant rollback — recovery time must be <30 seconds"
+    - "Enforce deploy.lock to prevent concurrent deployments"
+    - "Only deploy commits with semantic version tags — no untagged HEAD deployments"
+    - "Log every deployment with timestamp, version, operator, and result (JSON Lines)"
+
+  meta:
+    version: "1.0.0"
+    updated: "2026-04-26"
+    source: core/no-cicd-deployment.md
+    description: Reliable deployment strategy for environments without CI/CD platforms
+    complements: deployment-standards.ai.yaml
+
+  principles:
+    core:
+      - fail_fast: "set -euo pipefail stops execution at first failure — no silent partial deploys"
+      - verify_always: "Post-deploy smoke test is mandatory, not optional"
+      - instant_recovery: "Blue-Green rollback must complete in <30 seconds"
+      - concurrent_protection: "deploy.lock prevents race conditions from simultaneous deployments"
+      - version_discipline: "Only semver-tagged commits are deployable"
+      - audit_trail: "Every deploy produces a machine-readable log entry"
+
+  architecture:
+    three_layer:
+      layer_1_prevent:
+        name: "Prevent Wrong Deployments"
+        mechanisms:
+          - "set -euo pipefail in deploy.sh"
+          - "Mandatory test pass before deploy"
+          - "Semver tag enforcement"
+          - "deploy.lock concurrency guard"
+      layer_2_verify:
+        name: "Verify Deployment Correctness"
+        mechanisms:
+          - "HTTP /health endpoint check"
+          - "Version number comparison with VERSION file"
+          - "Auto-rollback on verification failure"
+      layer_3_recover:
+        name: "Fast Recovery Capability"
+        mechanisms:
+          - "Blue-Green slot switching"
+          - "Nginx upstream pointer swap"
+          - "Single-command rollback.sh"
+
+  deploy_script:
+    required_header: "#!/usr/bin/env bash\nset -euo pipefail"
+    mandatory_steps:
+      - step: test
+        order: 1
+        description: "Run full test suite before any deployment"
+      - step: build
+        order: 2
+        description: "Produce deployment artifact"
+      - step: deploy
+        order: 3
+        description: "Transfer artifact to target server"
+      - step: verify
+        order: 4
+        description: "Run smoke test; auto-rollback on failure"
+    lock_pattern:
+      file: "/tmp/deploy.lock"
+      create: "echo $$ > $LOCK_FILE"
+      cleanup: "trap 'rm -f $LOCK_FILE' EXIT"
+      check: "[ -f $LOCK_FILE ] && echo 'Deploy in progress' && exit 1"
+    version_enforcement:
+      command: "git describe --exact-match --tags HEAD"
+      format: "v[0-9]+\\.[0-9]+\\.[0-9]+"
+      failure_message: "No semver tag on HEAD — tag before deploying"
+
+  smoke_test:
+    endpoint: "/health"
+    required_fields:
+      - field: "version"
+        source: "VERSION file"
+        comparison: "exact match"
+      - field: "status"
+        expected: "ok"
+    failure_action: "auto_rollback"
+    timeout_seconds: 30
+
+  blue_green:
+    slots:
+      - name: blue
+        port: 3001
+        state: "active (stable)"
+      - name: green
+        port: 3002
+        state: "inactive (staging)"
+    switch_mechanism: "nginx upstream pointer"
+    rollback_time_sla: "30 seconds"
+    rollback_command: "./rollback.sh"
+
+  deployment_log:
+    format: "JSON Lines"
+    required_fields:
+      - "timestamp (ISO 8601)"
+      - "version"
+      - "git_commit"
+      - "operator (whoami)"
+      - "result (success|failure)"
+      - "duration_seconds"
+    location: "/var/log/deployments.jsonl"
+
+  checklist:
+    pre_deploy:
+      - "Tests pass"
+      - "Artifact built successfully"
+      - "No deploy.lock present"
+      - "HEAD has semver tag"
+      - "Previous deployment log reviewed"
+    post_deploy:
+      - "Health check HTTP 200"
+      - "Version matches expected"
+      - "Service responds to basic requests"
+      - "Deployment log entry written"
+    rollback_readiness:
+      - "Blue slot running previous stable version"
+      - "rollback.sh tested and functional"
+      - "Nginx upstream reload works"
+
+  physical_spec:
+    type: custom_script
+    validator:
+      command: "test -f deploy.sh && grep -q 'set -euo pipefail' deploy.sh && test -f rollback.sh && test -f verify.sh"
+      rule: "no_cicd_deployment_scripts_configured"

package/bundled/ai/standards/pipeline-security-gates.ai.yaml

@@ -0,0 +1,71 @@
+# Pipeline Security Gates (AI-Optimized v1)
+# Source: core/pipeline-security-gates.md
+
+standard:
+  id: pipeline-security-gates
+  name: Pipeline Security Gates
+  description: Security checkpoints embedded in CI pipeline — SAST, DAST, SCA, secrets scan with block/warn/log behavior
+  guidelines:
+    - "Secrets scan at pre-commit — block ALL commits containing secrets"
+    - "SAST after build — block Critical/High findings"
+    - "SCA + SBOM generation at package stage"
+    - "DAST after staging deploy — warn on findings, require approval for Critical"
+    - "Never skip security gates with --force or emergency bypass without audit trail"
+    - "Treat security gate failures as pipeline failures, not warnings"
+
+  meta:
+    version: "1.0.0"
+    updated: "2026-04-26"
+    source: core/pipeline-security-gates.md
+    complements: security-standards.ai.yaml
+
+gate_positions:
+  pre_commit:
+    type: secrets_scan
+    tools: ["gitleaks", "trufflehog", "detect-secrets"]
+    scope: "staged files"
+    block_on: ["any secret pattern match"]
+    never_skip: true
+  post_build:
+    type: sast
+    tools: ["semgrep", "codeql", "sonarqube"]
+    scope: "source code + build output"
+    block_on: ["Critical", "High"]
+    warn_on: ["Medium"]
+    log_only: ["Low", "Info"]
+  post_staging_deploy:
+    type: dast
+    tools: ["zap", "nuclei", "burpsuite-enterprise"]
+    scope: "running staging application"
+    block_on: ["Critical"]
+    require_approval: ["High"]
+    warn_on: ["Medium"]
+  package_stage:
+    type: sca_and_sbom
+    tools: ["trivy", "syft", "grype", "dependabot"]
+    scope: "dependencies + container image"
+    block_on: ["Critical CVE with fix available"]
+    warn_on: ["High CVE", "outdated dependencies"]
+    sbom_format: ["spdx", "cyclonedx"]
+
+bypass_policy:
+  allowed: false
+  exception_process: "written security approval + audit log entry"
+  emergency_bypass: "time-limited token + mandatory post-incident review"
+
+failure_behavior:
+  Critical: {action: "block pipeline", notify: "security-team", sla: "immediate"}
+  High: {action: "block pipeline", notify: "team-lead", sla: "same-day"}
+  Medium: {action: "warn + require approval", notify: "developer", sla: "next-sprint"}
+  Low: {action: "log only", notify: "none", sla: "backlog"}
+
+integration_points:
+  secrets_vault: "Integrate with HashiCorp Vault or AWS Secrets Manager for secrets injection"
+  sbom_registry: "Upload SBOM to dependency-track or grype-db for continuous monitoring"
+  incident_response: "Critical findings automatically create incident tickets"
+
+physical_spec:
+  type: custom_script
+  validator:
+    command: "grep -r 'secrets\\|sast\\|sca\\|dast' .github/workflows/ .gitlab-ci.yml Jenkinsfile 2>/dev/null | head -1 || echo 'no-ci-pipeline'"
+    rule: "security_gates_in_pipeline"

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

@@ -0,0 +1,105 @@
+id: push-standards
+meta:
+  version: "1.0.0"
+  updated: "2026-04-23"
+  source: skills/push/SKILL.md
+  description: "Git push safety gates, protected branch detection, force-push guardrails, and push receipt audit trail"
+
+config:
+  protected_branches:
+    default: ["main", "master", "release/*", "hotfix/*"]
+    description: "Branches requiring explicit confirmation before push"
+
+  push_gates:
+    default: ["lint", "test"]
+    optional: ["ac-coverage", "type-check", "security-scan"]
+    description: "Quality gates to run before pushing"
+
+  receipt:
+    output:
+      default: "console"
+      choices: ["console", "file", "both"]
+    file_path: "~/.uds/push-history.jsonl"
+
+  auto_pr:
+    default: true
+    description: "Prompt to create PR after pushing to non-protected branch"
+
+  repo_mode:
+    default: "team"
+    choices: ["team", "single-owner"]
+    description: "single-owner skips PR prompts and reduces collaboration guardrails"
+
+rules:
+  - id: detect-protected-branch
+    trigger: "executing /push"
+    priority: required
+    instruction: |
+      Before pushing, detect the target branch name.
+      If the target matches any protected_branches pattern:
+      1. Display a warning with the branch name
+      2. Show what commits will be pushed
+      3. Require explicit user confirmation before proceeding
+      4. If user does not confirm, abort without pushing
+
+  - id: force-push-guardrail
+    trigger: "push with --force flag detected"
+    priority: required
+    instruction: |
+      When force push is detected:
+      1. Calculate commits that will be overwritten on remote
+      2. Show the count and authors of overwritten commits
+      3. Require the user to type a confirmation string (e.g., "yes, force push")
+      4. Record force_push: true in the push receipt
+
+  - id: pre-push-gates
+    trigger: "before executing git push"
+    priority: required
+    instruction: |
+      Run all configured push_gates in sequence:
+      - lint: run project lint command (from uds.project.yaml or detected)
+      - test: run project test command
+      If any gate fails: abort push, display which gate failed, suggest fix.
+      If --skip-gates flag: run push without gates, mark gates_skipped: true in receipt.
+
+  - id: push-receipt
+    trigger: "after successful push"
+    priority: required
+    instruction: |
+      Output a structured push receipt containing:
+      - branch: target branch name
+      - commit_sha: HEAD commit SHA (short)
+      - gates_passed: list of gates that ran and passed
+      - gates_skipped: boolean
+      - force_push: boolean
+      - timestamp: ISO 8601 format
+      If receipt.output includes "file": append to ~/.uds/push-history.jsonl as JSON line.
+
+  - id: pr-integration
+    trigger: "after successful push to non-protected branch"
+    priority: suggested
+    instruction: |
+      If auto_pr is true AND repo_mode is "team":
+      Check if an open PR exists for this branch on the remote.
+      If no open PR: prompt user whether to run pr-automation-assistant.
+      If user confirms: invoke pr-automation-assistant.
+      If auto_pr is false OR repo_mode is "single-owner": skip this step.
+
+  - id: single-owner-mode
+    trigger: "repo_mode: single-owner is configured"
+    priority: recommended
+    instruction: |
+      In single-owner mode, skip all collaboration-specific steps:
+      - No PR prompts
+      - Reduced force-push warnings (still warn, but no confirmation text required)
+      Protected branch detection remains active.
+
+schema:
+  push_receipt:
+    branch: string
+    commit_sha: string
+    gates_passed: "string[]"
+    gates_skipped: boolean
+    force_push: boolean
+    timestamp: "ISO 8601 string"
+    target_remote: string

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

@@ -0,0 +1,68 @@
+# Rollback Standards (AI-Optimized v1)
+# Source: core/rollback-standards.md
+
+standard:
+  id: rollback-standards
+  name: Rollback Standards
+  description: Rollback trigger conditions, auto vs manual decisions, and error budget integration
+  guidelines:
+    - "Define rollback triggers with measurable thresholds — never subjective 'it looks bad'"
+    - "Auto-rollback on error rate > 2× baseline sustained 5 minutes"
+    - "Assisted rollback when SLO violated but non-critical"
+    - "Manual rollback for latency degradation within SLO bounds"
+    - "Error budget < 10% automatically escalates assisted to auto-rollback"
+    - "Every rollback event must be logged and trigger incident response flow"
+
+  meta:
+    version: "1.0.0"
+    updated: "2026-04-26"
+    source: core/rollback-standards.md
+    parent: deployment-standards.ai.yaml
+
+trigger_conditions:
+  auto_rollback:
+    error_rate: ">2× baseline sustained 5min"
+    health_check_failures: "3 consecutive"
+    p99_latency: ">5× baseline sustained 3min"
+  assisted_rollback:
+    slo_violated: "non-critical path"
+    error_budget_remaining: "<10%"
+  manual_rollback:
+    latency_degraded: "within SLO bounds"
+    cosmetic_issues: "user-visible but non-functional"
+
+severity_matrix:
+  P0: {trigger: auto, timeline: "<2min", notify: "all-hands"}
+  P1: {trigger: auto, timeline: "<5min", notify: "on-call"}
+  P2: {trigger: assisted, timeline: "<15min", notify: "team-lead"}
+  P3: {trigger: manual, timeline: "<1hr", notify: "developer"}
+
+error_budget_integration:
+  threshold: "10% remaining"
+  escalation: "assisted → auto"
+  incident_event: true
+  pause_deploys: "when budget exhausted"
+
+rollback_methods:
+  blue_green: {time: "<30s", risk: low, prerequisite: "dual-slot infrastructure"}
+  feature_flag: {time: "<5s", risk: minimal, prerequisite: "flag system in place"}
+  dns_switch: {time: "60-120s", risk: medium, prerequisite: "multi-region setup"}
+  code_revert: {time: "minutes", risk: medium, prerequisite: "clean git history"}
+  database_restore: {time: "hours", risk: high, prerequisite: "backup verified"}
+
+checklist:
+  pre_rollback:
+    - "Confirm rollback target version is healthy"
+    - "Verify database migration is backward compatible"
+    - "Notify stakeholders of rollback"
+  post_rollback:
+    - "Confirm health checks pass at target version"
+    - "Write rollback event to deployment log"
+    - "Open incident ticket for root cause analysis"
+    - "Update error budget tracking"
+
+physical_spec:
+  type: custom_script
+  validator:
+    command: "test -f rollback.sh && grep -q 'set -euo pipefail' rollback.sh"
+    rule: "rollback_script_configured"

package/bundled/core/cd-deployment-strategies.md

@@ -0,0 +1,121 @@
+# CD Deployment Strategies（CD 部署策略）
+
+## 概述
+
+本標準定義四種主要部署策略的選用矩陣：Blue-Green、Canary、Rolling、Recreate。幫助團隊根據流量規模、風險容忍度和基礎設施成本，做出一致且有據可查的策略選擇。
+
+---
+
+## 核心原則
+
+- **三維決策**：根據流量規模 × 風險容忍度 × 基礎設施成本選擇策略
+- **禁止直接推產**：任何變更都必須先通過 staging 環境驗證
+- **零停機目標**：除非為內部工具或開發環境，否則應追求零停機部署
+
+---
+
+## 策略選用矩陣
+
+| 策略 | 流量規模 | 風險容忍度 | 基礎設施成本 | 停機時間 | 回滾時間 |
+|------|---------|----------|------------|---------|---------|
+| Blue-Green | 高 | 低 | 高 | 零 | < 30 秒 |
+| Canary | 中至高 | 中 | 中 | 零 | < 2 分鐘 |
+| Rolling | 任意 | 中 | 低 | 極少 | 數分鐘 |
+| Recreate | 低 | 高 | 極低 | 數秒至數分鐘 | 數分鐘 |
+
+---
+
+## 各策略詳細說明
+
+### Blue-Green
+
+**適用場景**：有狀態服務、資料庫相容性變更、高 SLA API
+
+**運作方式**：
+- 維護兩個完全相同的環境（Blue = 現有線上版，Green = 新版本）
+- 完整部署並驗證 Green 環境後，切換 Load Balancer 流量
+- 問題發生時立即切回 Blue
+
+**前置條件**：雙環境基礎設施、Load Balancer、健康檢查
+
+---
+
+### Canary
+
+**適用場景**：功能驗證、A/B 測試、高風險變更
+
+**流量漸進比例**：1% → 5% → 25% → 50% → 100%
+
+**運作方式**：
+- 先將少量流量導向新版本
+- 監控指標，符合自動晉升規則則繼續擴大
+- 發現問題立即縮回 0%
+
+**前置條件**：流量切分機制、可觀測性、自動晉升規則
+
+---
+
+### Rolling
+
+**適用場景**：無狀態服務、標準更新、批次工作者
+
+**運作方式**：
+- 依序更新每個實例，更新前進行健康檢查
+- 允許新舊版本短暫共存
+- 資源效率最佳，但回滾需時較長
+
+**前置條件**：多個服務實例、健康檢查
+
+---
+
+### Recreate
+
+**適用場景**：開發/測試環境、內部工具、單一實例服務
+
+**運作方式**：
+- 停止所有現有實例，部署新版本，重新啟動
+- 最簡單，但有停機時間
+
+**前置條件**：無（最低門檻）
+
+---
+
+## 決策樹
+
+```
+Q1: 需要零停機時間？
+  → 否 → Recreate
+  → 是 → Q2
+
+Q2: 流量 > 10k req/min？
+  → 是 → Q3（Blue-Green 或 Canary）
+  → 否 → Rolling
+
+Q3: 變更屬於高風險？
+  → 是 → Canary
+  → 否 → Q4
+
+Q4: 基礎設施預算有限？
+  → 是 → Rolling
+  → 否 → Blue-Green
+```
+
+---
+
+## 無 CI/CD 環境的替代做法
+
+| 策略 | 替代方案 |
+|------|---------|
+| Blue-Green | 參見 no-cicd-deployment.ai.yaml 的 Shell Script 實作 |
+| Canary | 使用 Nginx `split_clients` 或 HAProxy 做流量切分 |
+| Rolling | 使用順序式 rsync + 健康檢查迴圈 |
+| Recreate | 最簡單 — 停止、部署、啟動 |
+
+---
+
+## 相關標準
+
+- [deployment-standards.md](deployment-standards.md) — 部署基礎原則
+- [rollback-standards.md](rollback-standards.md) — 回滾觸發條件矩陣
+- [no-cicd-deployment.md](no-cicd-deployment.md) — 無 CI/CD 部署策略
+- AI 格式：[../ai/standards/cd-deployment-strategies.ai.yaml](../ai/standards/cd-deployment-strategies.ai.yaml)