回答問題：輸入 → 輸出（一次性）
完成任務：目標 → [計劃 → 執行 → 評估 → 修正] × N → 達成目標

Prompt Engineering：
  Human → [Prompt] → AI → Output（一次）

Workflow Engineering：
  Human → [Step1 → Step2 → Step3] → Output（固定流程）

Agent Engineering：
  Human → [Agent: Observe → Decide → Act] → Output（動態決策）

Loop Engineering：
  Human 設計迴圈
  Agent 在迴圈中執行
  迴圈 = [Agent: Observe → Orient → Decide → Act → Evaluate → Feedback] × N
  直到達成目標或停止條件

錯誤發生 → 錯誤分類 → 策略選擇 → 修正執行 → 驗證修正 → 若仍失敗 → 升級處理

第一層：內部重試（Internal Retry）
  → 同一節點、同一上下文，重新嘗試一次（成本最低）
第二層：本地修補（Local Patch）
  → 重試失敗後，僅調整失敗節點周邊的局部計畫，不影響全局
第三層：全面重規劃（Full Replan）
  → 局部修補仍失敗，才觸發整張圖的重新規劃（成本最高、頻率應最低）

while :; do cat PROMPT.md | claude-code; done

# .github/workflows/loop-engineering.yml
name: Loop Engineering Pipeline

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]
  schedule:
    - cron: '0 2 * * *'  # 每日凌晨 2 點執行

env:
  JAVA_VERSION: '21'
  MAVEN_OPTS: '-Xmx4g'

jobs:
  # 第一階段：程式碼品質分析 Loop
  code-quality-loop:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0  # 完整歷史，供 SonarQube 分析

      - name: Setup Java
        uses: actions/setup-java@v4
        with:
          java-version: ${{ env.JAVA_VERSION }}
          distribution: 'temurin'
          cache: maven

      - name: Build & Test
        run: mvn verify -B --no-transfer-progress

      - name: SonarQube Analysis
        run: |
          mvn sonar:sonar \
            -Dsonar.projectKey=${{ github.repository }} \
            -Dsonar.host.url=${{ secrets.SONAR_HOST_URL }} \
            -Dsonar.login=${{ secrets.SONAR_TOKEN }}

      - name: Quality Gate Check
        run: |
          status=$(curl -s "${{ secrets.SONAR_HOST_URL }}/api/qualitygates/project_status?projectKey=${{ github.repository }}" \
            -H "Authorization: Bearer ${{ secrets.SONAR_TOKEN }}" | jq -r '.projectStatus.status')
          if [ "$status" != "OK" ]; then
            echo "Quality Gate 失敗: $status"
            exit 1
          fi

  # 第二階段：AI Agent 自動修復 Loop
  ai-auto-fix-loop:
    needs: code-quality-loop
    if: failure()
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: AI Auto Fix
        uses: anthropics/claude-code-action@v1
        with:
          anthropic-api-key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: |
            分析本次 CI 失敗的原因，自動修復所有編譯錯誤與測試失敗。
            優先修復安全漏洞。修復完成後建立 Pull Request。
          tools: read,write,bash,github

  # 第三階段：安全掃描 Loop
  security-scan-loop:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Dependency Vulnerability Scan
        run: |
          mvn dependency-check:check \
            -DfailBuildOnCVSS=7 \
            -DsuppressionFile=.github/security/suppressions.xml

      - name: Secret Scan
        uses: trufflesecurity/trufflehog@main
        with:
          path: ./
          base: ${{ github.event.repository.default_branch }}

      - name: Container Scan
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: ${{ github.repository }}:latest
          format: sarif
          output: trivy-results.sarif

      - name: Upload SARIF
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: trivy-results.sarif

// Jenkinsfile — Loop Engineering Pipeline
pipeline {
    agent any

    environment {
        JAVA_HOME = tool 'JDK-21'
        MAVEN_HOME = tool 'Maven-3.9'
        PATH = "${JAVA_HOME}/bin:${MAVEN_HOME}/bin:${PATH}"
        SONAR_URL = credentials('sonar-url')
        ANTHROPIC_KEY = credentials('anthropic-api-key')
    }

    options {
        timeout(time: 60, unit: 'MINUTES')
        buildDiscarder(logRotator(numToKeepStr: '10'))
        timestamps()
    }

    stages {
        stage('Checkout') {
            steps {
                checkout scm
                sh 'git log --oneline -5'
            }
        }

        stage('Build Loop') {
            steps {
                sh 'mvn clean compile -B -q'
            }
            post {
                failure {
                    script {
                        def error = sh(script: 'mvn clean compile -B 2>&1 | tail -50', returnStdout: true)
                        // 觸發 AI 修復迴圈
                        sh """
                            claude-code fix-compilation \
                              --error "${error}" \
                              --auto-commit \
                              --branch fix/auto-${BUILD_NUMBER}
                        """
                    }
                }
            }
        }

        stage('Test Loop') {
            parallel {
                stage('Unit Tests') {
                    steps {
                        sh 'mvn test -B -Dtest=**/*Test.java'
                    }
                }
                stage('Integration Tests') {
                    steps {
                        sh 'mvn verify -B -Dtest=**/*IT.java'
                    }
                }
            }
            post {
                always {
                    junit '**/target/surefire-reports/*.xml'
                    publishHTML(target: [
                        reportDir: 'target/site/jacoco',
                        reportFiles: 'index.html',
                        reportName: 'Code Coverage'
                    ])
                }
            }
        }

        stage('Quality Gate Loop') {
            steps {
                withSonarQubeEnv('SonarQube') {
                    sh 'mvn sonar:sonar'
                }
                timeout(time: 5, unit: 'MINUTES') {
                    waitForQualityGate abortPipeline: true
                }
            }
        }

        stage('Security Loop') {
            steps {
                sh '''
                    mvn dependency-check:check -DfailBuildOnCVSS=8
                    trivy fs --exit-code 1 --severity CRITICAL .
                    gitleaks detect --source=. --report-format=json
                '''
            }
        }

        stage('Deploy Loop') {
            when { branch 'main' }
            steps {
                sh '''
                    podman build -t ${APP_IMAGE}:${BUILD_NUMBER} .
                    podman push ${APP_IMAGE}:${BUILD_NUMBER}
                    kubectl set image deployment/${APP_NAME} \
                      ${APP_NAME}=${APP_IMAGE}:${BUILD_NUMBER} \
                      -n production
                    kubectl rollout status deployment/${APP_NAME} -n production
                '''
            }
        }
    }
}

# .gitlab-ci.yml
stages:
  - build
  - test
  - quality
  - security
  - deploy

variables:
  MAVEN_OPTS: "-Dmaven.repo.local=$CI_PROJECT_DIR/.m2/repository"

build:
  stage: build
  image: eclipse-temurin:21-jdk
  cache:
    paths: [.m2/repository]
  script:
    - mvn clean compile -B -q

test:
  stage: test
  script:
    - mvn verify -B
  artifacts:
    reports:
      junit: target/surefire-reports/TEST-*.xml
      coverage_report:
        coverage_format: jacoco
        path: target/site/jacoco/jacoco.xml

sonarqube-check:
  stage: quality
  script:
    - mvn verify sonar:sonar
      -Dsonar.qualitygate.wait=true
      -Dsonar.host.url=$SONAR_HOST_URL
      -Dsonar.login=$SONAR_TOKEN

# azure-pipelines.yml
trigger:
  branches:
    include: [main, develop]

pool:
  vmImage: ubuntu-latest

variables:
  javaVersion: 21

stages:
  - stage: LoopEngineeringPipeline
    jobs:
      - job: BuildTestLoop
        steps:
          - task: JavaToolInstaller@0
            inputs:
              versionSpec: $(javaVersion)
              jdkArchitectureOption: x64
              jdkSourceOption: PreInstalled
          - task: Maven@4
            inputs:
              mavenPomFile: pom.xml
              goals: verify
              publishJUnitResults: true
              testResultsFiles: '**/TEST-*.xml'
              codeCoverageToolOption: JaCoCo

# Cron Job 設定範例（crontab）
# 每日凌晨 3 點執行程式碼健康檢查 Loop
0 3 * * * /opt/loop-engineering/scripts/daily-health-check.sh >> /var/log/loop-engine.log 2>&1

# 每小時執行安全掃描 Loop
0 * * * * /opt/loop-engineering/scripts/security-scan.sh >> /var/log/security-scan.log 2>&1

# 每週一早上 9 點執行技術債務分析 Loop
0 9 * * 1 /opt/loop-engineering/scripts/tech-debt-analysis.sh >> /var/log/tech-debt.log 2>&1

# 每 15 分鐘檢查生產環境健康狀態
*/15 * * * * /opt/loop-engineering/scripts/prod-health-monitor.sh

# === Git Worktree 完整操作指南 ===

# 查看目前所有 Worktrees
git worktree list
# 輸出範例：
# /home/user/project      a1b2c3d [main]
# /home/user/project-feat d4e5f6a [feature/new-api]
# /home/user/project-fix  g7h8i9b [bugfix/login]

# 新增 Worktree（從現有分支）
git worktree add ../project-feature feature/new-payment

# 新增 Worktree（建立新分支）
git worktree add -b feature/user-profile ../project-profile

# 新增 Worktree（Detached HEAD 模式，用於只讀分析）
git worktree add --detach ../project-analyze v2.1.0

# 新增 Worktree（從遠端分支）
git worktree add ../project-hotfix origin/hotfix/critical-bug

# 移除 Worktree（正常移除）
git worktree remove ../project-feature

# 強制移除（忽略未提交的變更）
git worktree remove --force ../project-feature

# 清理廢棄的 Worktree 記錄
git worktree prune

# 鎖定 Worktree（防止被意外移除）
git worktree lock ../project-feature --reason "Agent 正在使用此 Worktree"

# 解鎖 Worktree
git worktree unlock ../project-feature

# 查看 Worktree 詳細狀態
git worktree list --porcelain

# === 多 Agent 並行開發 SOP ===

# Step 1: 主倉庫設置
REPO_ROOT="/workspace/myproject"
WORKTREE_BASE="/workspace/worktrees"
mkdir -p "$WORKTREE_BASE"

# Step 2: 建立各 Agent 的 Worktree
# Agent 1: 後端 API 開發
git worktree add -b feature/api-v2 "$WORKTREE_BASE/api-development" main

# Agent 2: 前端 UI 開發
git worktree add -b feature/ui-redesign "$WORKTREE_BASE/ui-development" main

# Agent 3: 資料庫 Migration
git worktree add -b feature/db-migration "$WORKTREE_BASE/db-migration" main

# Agent 4: 測試撰寫
git worktree add -b feature/test-coverage "$WORKTREE_BASE/testing" main

# Step 3: 確認所有 Worktrees 狀態
git worktree list

# Step 4: 在各 Worktree 中執行 Agent（並行）
# 每個 Agent 在其 Worktree 中獨立工作
cd "$WORKTREE_BASE/api-development" && claude-code implement-api &
cd "$WORKTREE_BASE/ui-development" && claude-code implement-ui &
cd "$WORKTREE_BASE/testing" && claude-code write-tests &

# Step 5: 等待所有 Agent 完成
wait

# Step 6: 合併所有結果
cd "$REPO_ROOT"
git merge feature/api-v2
git merge feature/ui-redesign
git merge feature/test-coverage

# Step 7: 清理 Worktrees
git worktree remove "$WORKTREE_BASE/api-development"
git worktree remove "$WORKTREE_BASE/ui-development"
git worktree remove "$WORKTREE_BASE/db-migration"
git worktree remove "$WORKTREE_BASE/testing"
git worktree prune

# 建立 Worktree 管理腳本
cat > /usr/local/bin/loop-worktree << 'EOF'
#!/bin/bash
# Loop Engineering Worktree Manager

COMMAND=$1
TASK_NAME=$2
BASE_BRANCH="${3:-main}"

case "$COMMAND" in
  create)
    TIMESTAMP=$(date +%Y%m%d-%H%M%S)
    BRANCH="loop/${TASK_NAME}-${TIMESTAMP}"
    WORKTREE_PATH="../worktree-${TASK_NAME}"
    git worktree add -b "$BRANCH" "$WORKTREE_PATH" "$BASE_BRANCH"
    echo "Worktree 建立於: $WORKTREE_PATH"
    echo "分支: $BRANCH"
    ;;
  cleanup)
    git worktree list | grep "loop/" | awk '{print $1}' | while read wt; do
      git worktree remove "$wt" 2>/dev/null || git worktree remove --force "$wt"
    done
    git worktree prune
    echo "所有 Loop Worktrees 已清理"
    ;;
  list)
    git worktree list
    ;;
esac
EOF
chmod +x /usr/local/bin/loop-worktree

# 使用範例
loop-worktree create payment-feature main
loop-worktree list
loop-worktree cleanup

skills/
├── coding/
│   ├── java-spring-boot.md       # Spring Boot 開發技能
│   ├── vue3-typescript.md         # Vue3 + TypeScript 技能
│   ├── clean-code.md              # Clean Code 技能
│   ├── design-patterns.md         # 設計模式應用技能
│   ├── api-design.md              # RESTful API 設計技能
│   └── database-optimization.md  # 資料庫優化技能
├── architecture/
│   ├── microservices.md           # 微服務架構技能
│   ├── hexagonal-architecture.md  # 六角形架構技能
│   ├── ddd.md                     # DDD 領域驅動設計技能
│   ├── event-driven.md            # 事件驅動架構技能
│   └── cloud-native.md            # Cloud Native 技能
├── testing/
│   ├── unit-testing-junit5.md     # JUnit 5 單元測試技能
│   ├── integration-testing.md     # 整合測試技能
│   ├── e2e-testing-playwright.md  # E2E 測試技能
│   ├── performance-testing.md     # 效能測試技能
│   └── security-testing.md        # 安全測試技能
├── security/
│   ├── owasp-top10.md             # OWASP Top 10 技能
│   ├── sast-analysis.md           # 靜態分析技能
│   ├── dependency-scanning.md     # 相依套件掃描技能
│   ├── secrets-management.md      # 秘密管理技能
│   └── threat-modeling.md         # 威脅建模技能
└── migration/
    ├── java6-to-java21.md          # Java 版本升級技能
    ├── struts-to-spring-boot.md    # Struts 遷移技能
    ├── jsp-to-vue3.md              # JSP 遷移技能
    ├── spring-boot-2-to-3.md       # Spring Boot 升級技能
    └── monolith-to-microservices.md # 單體到微服務技能

---
skill: spring-boot-rest-api
version: 2.0
tags: [java, spring-boot, rest-api, backend]
applicable-models: [claude-3-5-sonnet, claude-opus-4]
---

# Spring Boot REST API 開發技能

## 適用情境
開發符合企業標準的 Spring Boot REST API，包含安全性、效能、可觀測性。

## 核心原則
1. 遵循 REST 語意（正確使用 HTTP 動詞與狀態碼）
2. 使用 DTO 層隔離領域模型與 API 契約
3. 實作統一的錯誤處理（GlobalExceptionHandler）
4. 所有 API 必須有對應的 OpenAPI 文件

## 標準程式碼結構

```java
@RestController
@RequestMapping("/api/v1/customers")
@RequiredArgsConstructor
@Validated
public class CustomerController {
    private final CustomerService customerService;

    @GetMapping("/{id}")
    public ResponseEntity<CustomerDto> findById(
            @PathVariable @Positive Long id) {
        return ResponseEntity.ok(customerService.findById(id));
    }

    @PostMapping
    public ResponseEntity<CustomerDto> create(
            @RequestBody @Valid CreateCustomerRequest request) {
        CustomerDto created = customerService.create(request);
        return ResponseEntity.created(
            URI.create("/api/v1/customers/" + created.id())
        ).body(created);
    }
}
```

## 禁止事項
- 不得在 Controller 直接存取 Repository
- 不得回傳 Entity 物件（必須使用 DTO）
- 不得忽略輸入驗證

// .claude/mcp-config.json — 企業級 MCP 連接器設定
{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
      }
    },
    "jira": {
      "command": "npx",
      "args": ["-y", "@mcp-servers/jira"],
      "env": {
        "JIRA_URL": "${JIRA_URL}",
        "JIRA_USERNAME": "${JIRA_USERNAME}",
        "JIRA_API_TOKEN": "${JIRA_API_TOKEN}"
      }
    },
    "sonarqube": {
      "command": "npx",
      "args": ["-y", "@mcp-servers/sonarqube"],
      "env": {
        "SONAR_URL": "${SONAR_HOST_URL}",
        "SONAR_TOKEN": "${SONAR_TOKEN}"
      }
    },
    "kubernetes": {
      "command": "npx",
      "args": ["-y", "@mcp-servers/kubernetes"],
      "env": {
        "KUBECONFIG": "${HOME}/.kube/config"
      }
    },
    "slack": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-slack"],
      "env": {
        "SLACK_BOT_TOKEN": "${SLACK_BOT_TOKEN}",
        "SLACK_TEAM_ID": "${SLACK_TEAM_ID}"
      }
    },
    "postgresql": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "POSTGRES_CONNECTION_STRING": "${DATABASE_URL}"
      }
    },
    "confluence": {
      "command": "npx",
      "args": ["-y", "@mcp-servers/confluence"],
      "env": {
        "CONFLUENCE_URL": "${CONFLUENCE_URL}",
        "CONFLUENCE_TOKEN": "${CONFLUENCE_API_TOKEN}"
      }
    },
    "snyk": {
      "command": "npx",
      "args": ["-y", "@mcp-servers/snyk"],
      "env": {
        "SNYK_TOKEN": "${SNYK_TOKEN}"
      }
    }
  }
}

# SonarQube 掃描與結果查詢
# 執行掃描
sonar-scanner \
  -Dsonar.projectKey=my-banking-app \
  -Dsonar.sources=src/main/java \
  -Dsonar.tests=src/test/java \
  -Dsonar.java.binaries=target/classes \
  -Dsonar.host.url=https://sonarqube.company.com \
  -Dsonar.login=$SONAR_TOKEN

# 查詢掃描結果
curl -s "https://sonarqube.company.com/api/measures/component?component=my-banking-app&metricKeys=bugs,vulnerabilities,code_smells,coverage,duplicated_lines_density" \
  -H "Authorization: Bearer $SONAR_TOKEN" | jq '.component.measures'

# 查詢 Quality Gate 狀態
curl -s "https://sonarqube.company.com/api/qualitygates/project_status?projectKey=my-banking-app" \
  -H "Authorization: Bearer $SONAR_TOKEN" | jq '.projectStatus.status'

# 建立新的 Quality Gate 規則（via CLI）
curl -X POST "https://sonarqube.company.com/api/qualitygates/create_condition" \
  -H "Authorization: Bearer $SONAR_TOKEN" \
  -d "gateId=1&metric=new_security_rating&op=GT&error=1"

# Claude Code 記憶系統目錄結構
~/.claude/
├── MEMORY.md              # 記憶索引（自動載入）
└── projects/
    └── my-project/
        └── memory/
            ├── user_profile.md          # 使用者偏好記憶
            ├── project_context.md       # 專案背景記憶
            ├── feedback_preferences.md  # 反饋偏好記憶
            ├── tech_decisions.md        # 技術決策記憶
            └── lessons_learned.md       # 教訓記憶

# 記憶管理 CLI 範例

# 查看目前所有記憶
ls ~/.claude/projects/$(basename $PWD)/memory/

# 查看記憶索引
cat ~/.claude/projects/$(basename $PWD)/memory/MEMORY.md

# 手動更新記憶（通常由 AI 自動完成）
echo "# 技術決策記憶
- 2026-06 決定使用 PostgreSQL（理由：需要 JSON 支援與強一致性）
- 2026-06 採用 Hexagonal Architecture（理由：可測試性與可維護性）
" > ~/.claude/projects/$(basename $PWD)/memory/tech_decisions.md

# 查看 CLAUDE.md（全局記憶）
cat CLAUDE.md

<!-- CLAUDE.md — 放在專案根目錄 -->
# 專案背景
這是一個企業網路銀行系統，使用 Java 21 + Spring Boot 3.5 + Vue 3。

# 技術棧
- Backend: Java 21, Spring Boot 3.5, Spring Security 6, Spring Data JPA
- Frontend: Vue 3.5, TypeScript 5.5, TailwindCSS 4
- Database: PostgreSQL 16（主），Redis 7（快取）
- Messaging: Kafka 3.7
- Container: Podman 5 / OpenShift 4.16

# 程式碼規範
- 使用 Lombok，禁止 Getter/Setter 手寫
- 所有 API 回應使用 ApiResponse<T> 包裝
- 禁止在 Service 層直接使用 HttpServletRequest
- 測試覆蓋率要求：≥ 80%
- 所有 Controller 需有對應的整合測試

# 安全性規範
- 所有使用者輸入必須驗證（@Valid + Bean Validation）
- 敏感資料（密碼/帳號）不得出現在日誌
- SQL 必須使用 Prepared Statement（JPA 自動處理）
- 每個功能需要進行 OWASP Top 10 自我審查

# Agent 工作規範
- 不得跳過測試直接提交
- 每次修改後必須執行 mvn verify
- 禁止修改 pom.xml 中的安全相關依賴版本
- 有疑問時優先查詢 skills/ 目錄

// .claude/settings.json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "echo '🔍 執行 Bash 指令前檢查安全性...'"
          }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Write",
        "hooks": [
          {
            "type": "command",
            "command": "if [ -f '*.java' ]; then mvn checkstyle:check -q 2>&1; fi"
          }
        ]
      },
      {
        "matcher": "Edit",
        "hooks": [
          {
            "type": "command",
            "command": "git diff --stat HEAD"
          }
        ]
      }
    ],
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "echo '✅ Claude Code 工作完成，執行最終驗證...' && mvn test -q 2>&1 | tail -5"
          }
        ]
      }
    ],
    "Notification": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "notify-send 'Claude Code' '需要您的注意' 2>/dev/null || true"
          }
        ]
      }
    ]
  },
  "permissions": {
    "allow": [
      "Bash(git *)",
      "Bash(mvn *)",
      "Bash(npm *)",
      "Bash(kubectl get *)",
      "Bash(docker ps)"
    ],
    "deny": [
      "Bash(rm -rf /)",
      "Bash(curl * | sh)"
    ]
  }
}

# === Claude Code CLI 完整指令手冊 ===

# 基本啟動
claude                          # 啟動互動式 REPL
claude "實作登入功能"            # 直接執行任務
claude -p "分析程式碼架構"       # 非互動模式（print）
claude --model claude-opus-4-8  # 指定模型

# 繼續上次工作
claude --continue               # 繼續上次對話
claude --resume <session-id>    # 恢復指定 Session

# 工作模式
claude --dangerously-skip-permissions  # 跳過所有權限確認（自動化腳本用）

# Skills 管理
claude /skills list             # 列出所有 Skills
claude /skills use spring-boot  # 載入特定 Skill
claude /skills update           # 更新 Skill Library

# Memory 管理
claude /memory show             # 顯示目前記憶
claude /memory forget "技術決策記憶"  # 刪除特定記憶

# Sub-agents
claude /agents list             # 列出可用 Sub-agents
claude /agents spawn planner    # 啟動 Planner Sub-agent

# 計劃模式
claude --plan                   # 進入規劃模式（不執行）

# 程式碼審查 Loop
claude /code-review             # 審查當前變更
claude /code-review ultra       # 深度多 Agent 審查
claude /code-review --fix       # 審查並自動修復

# MCP 工具
claude /mcp list                # 列出已連接的 MCP 伺服器
claude /mcp add github          # 新增 GitHub MCP 伺服器

# 執行腳本
echo "實作 CRUD API for Customer entity" | claude --pipe

# 與 CI/CD 整合
claude --model claude-haiku-4-5 \
  --max-tokens 8000 \
  -p "檢查以下 diff 是否有安全問題: $(git diff HEAD~1)" \
  --output-format json > security-report.json

# 批次處理
for file in src/main/java/**/*Service.java; do
  claude -p "為 ${file} 補充缺失的 JavaDoc" \
    --file "$file" \
    --auto-commit \
    --commit-message "docs: add JavaDoc to ${file}"
done

# Claude Code + GitHub 完整工作流程

# 1. 從 Issue 建立分支並實作
claude "根據 GitHub Issue #123 實作功能" \
  --github-issue 123 \
  --create-branch \
  --auto-pr

# 2. PR 自動審查
claude /review --pr 456

# 3. 自動修復 PR 問題
gh pr view 456 --json comments -q '.comments[].body' | \
  claude -p "修復以下 PR 審查意見:" --pipe --auto-commit

# 4. 完整的 Loop：Issue → 實作 → 測試 → PR → 審查 → 合併
claude run-loop \
  --issue 123 \
  --implement \
  --test \
  --create-pr \
  --request-review @team-leads

# 5. 監聽 GitHub 事件並觸發 Loop
# 在 GitHub Actions 中設定：
# on:
#   issues:
#     types: [labeled]
# 當 Issue 加上 "ai-implement" 標籤時自動觸發 Claude Code

# === GitHub Copilot Agent Mode 操作手冊 ===

# 1. 在 VSCode 中啟動 Copilot Agent Mode
# Ctrl+Shift+P → "GitHub Copilot: Open Chat"
# 輸入 "@workspace" 啟動 Workspace 感知模式

# 2. 標準 Agent 指令格式
# @workspace /new <描述>          建立新功能
# @workspace /explain <程式碼>    解釋程式碼
# @workspace /fix <錯誤>          修復問題
# @workspace /tests               產生測試
# @workspace /doc                 產生文件

# 3. Copilot CLI 操作
# 安裝 Copilot CLI
npm install -g @githubnext/github-copilot-cli

# 登入
github-copilot-cli auth login

# 使用自然語言執行指令
ghcs "列出所有 Java 檔案中超過 200 行的類別"
ghcs "找到所有沒有 @Test 的 test 方法"
ghcs "建立 Dockerfile for Java 21 + Spring Boot"

# 解釋指令
ghce "kubectl rollout restart deployment/banking-app -n production"

# 4. Copilot 在 GitHub.com 上的 Agent
# 在 Issue 中 @copilot 自動觸發 Agent
# 格式：
# @copilot 請根據此 Issue 實作功能，使用 Spring Boot + JPA
# 要求：
# - 實作 CRUD 操作
# - 撰寫單元測試（覆蓋率 ≥ 80%）
# - 符合現有程式碼風格
# - 建立 PR 並請 @team-lead 審查

# 5. Copilot PR 審查自動化
gh pr create \
  --title "feat: 新增客戶管理模組" \
  --body "@copilot 請審查這個 PR，重點關注：
  1. 安全性（SQL Injection, XSS）
  2. 效能（N+1 查詢問題）
  3. 程式碼品質（Clean Code 原則）
  4. 測試覆蓋率
  並自動修復所有可修復的問題。"

// .vscode/mcp.json — Copilot MCP 設定
{
  "servers": {
    "github": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${env:GITHUB_TOKEN}"
      }
    },
    "postgres": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "POSTGRES_CONNECTION_STRING": "${env:DATABASE_URL}"
      }
    },
    "jira": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "mcp-server-jira"],
      "env": {
        "JIRA_BASE_URL": "${env:JIRA_URL}",
        "JIRA_API_TOKEN": "${env:JIRA_TOKEN}",
        "JIRA_USER_EMAIL": "${env:JIRA_EMAIL}"
      }
    }
  }
}

# .github/copilot-instructions.md — Copilot 工作指示
# 此檔案讓 Copilot 了解專案上下文

# 專案說明
這是一個企業網路銀行系統（Internet Banking System），服務 100 萬以上用戶。

# 技術規範
- Java 21（使用 Virtual Threads、Records、Pattern Matching）
- Spring Boot 3.5 + Spring Security 6
- PostgreSQL 16（使用 row-level security）
- 所有 API 必須通過 OWASP ZAP 掃描

# AI Agent 指示
1. 所有程式碼必須通過 `mvn verify` 才能提交
2. 安全性問題具有最高優先級，立即修復
3. 使用現有的 BaseEntity 和 AuditEntity 基底類別
4. 遵循 src/main/java/com/bank 的現有套件結構
5. 測試類別命名：`*Test.java`（單元）、`*IT.java`（整合）

// src/main/java/com/company/loopengineering/agent/AgentRuntimeService.java
@Service
@RequiredArgsConstructor
@Slf4j
public class AgentRuntimeService {

    private final AnthropicClient anthropicClient;
    private final SkillService skillService;
    private final MemoryService memoryService;
    private final EvalService evalService;
    private final KafkaTemplate<String, AgentEvent> kafkaTemplate;

    /**
     * 執行 Loop Engineering 任務
     */
    @Transactional
    public Mono<AgentResult> executeLoop(AgentTask task) {
        log.info("開始執行 Loop 任務: {}", task.taskId());

        return Mono.fromCallable(() -> memoryService.loadContext(task.projectId()))
            .flatMap(context -> executeReActLoop(task, context))
            .flatMap(result -> evalService.evaluate(result))
            .doOnSuccess(result -> {
                memoryService.updateContext(task.projectId(), result);
                kafkaTemplate.send("loop-results", AgentEvent.of(result));
                log.info("Loop 任務完成: {}, 品質分數: {}", task.taskId(), result.qualityScore());
            })
            .doOnError(e -> log.error("Loop 任務失敗: {}", task.taskId(), e));
    }

    private Mono<AgentResult> executeReActLoop(AgentTask task, AgentContext context) {
        return Flux.range(0, task.maxIterations())
            .concatMap(iteration -> {
                log.debug("ReAct 迭代 {}/{}", iteration + 1, task.maxIterations());
                return reason(task, context)
                    .flatMap(plan -> act(plan))
                    .flatMap(output -> observe(output))
                    .flatMap(observation -> reflect(observation, task));
            })
            .takeUntil(result -> result.goalAchieved())
            .last()
            .map(AgentResult::fromIterationResult);
    }
}

// src/main/java/com/company/loopengineering/memory/MemoryService.java
@Service
@RequiredArgsConstructor
public class MemoryService {

    private final VectorRepository vectorRepository;
    private final RedisTemplate<String, Object> redisTemplate;
    private final MemoryRepository memoryRepository;

    /**
     * 儲存長期記憶（向量化）
     */
    public void storeMemory(String projectId, Memory memory) {
        // 向量化記憶內容
        float[] embedding = embeddingService.embed(memory.content());
        VectorMemory vectorMemory = VectorMemory.builder()
            .projectId(projectId)
            .content(memory.content())
            .embedding(embedding)
            .type(memory.type())
            .createdAt(Instant.now())
            .build();
        vectorRepository.save(vectorMemory);
    }

    /**
     * 語意搜尋相關記憶
     */
    public List<Memory> searchRelevantMemories(String projectId, String query, int topK) {
        float[] queryEmbedding = embeddingService.embed(query);
        return vectorRepository.findSimilar(projectId, queryEmbedding, topK)
            .stream()
            .map(this::toMemory)
            .toList();
    }
}

<!-- src/components/AgentConsole.vue -->
<template>
  <div class="agent-console bg-gray-900 text-white min-h-screen p-6">
    <div class="max-w-7xl mx-auto">
      <!-- 任務輸入區 -->
      <div class="mb-6 bg-gray-800 rounded-xl p-6">
        <h2 class="text-xl font-bold mb-4 text-blue-400">Loop Engineering 控制台</h2>
        <div class="flex gap-4">
          <textarea
            v-model="taskInput"
            class="flex-1 bg-gray-700 rounded-lg p-3 text-sm resize-none"
            rows="4"
            placeholder="輸入任務描述..."
          />
          <div class="flex flex-col gap-2">
            <button
              @click="executeLoop"
              :disabled="isRunning"
              class="px-6 py-3 bg-blue-600 hover:bg-blue-700 rounded-lg font-medium transition-colors"
            >
              {{ isRunning ? '執行中...' : '啟動 Loop' }}
            </button>
            <select v-model="selectedModel" class="bg-gray-700 rounded-lg p-2 text-sm">
              <option value="claude-sonnet-4-6">Claude Sonnet 4.6</option>
              <option value="claude-opus-4-8">Claude Opus 4.8</option>
            </select>
          </div>
        </div>
      </div>

      <!-- Loop 進度顯示 -->
      <div v-if="currentLoop" class="bg-gray-800 rounded-xl p-6 mb-6">
        <div class="flex items-center justify-between mb-4">
          <h3 class="text-lg font-semibold">迴圈進度</h3>
          <div class="flex items-center gap-2">
            <div class="w-3 h-3 rounded-full animate-pulse"
                 :class="isRunning ? 'bg-green-400' : 'bg-gray-400'" />
            <span class="text-sm text-gray-400">
              迭代 {{ currentLoop.iteration }}/{{ currentLoop.maxIterations }}
            </span>
          </div>
        </div>
        <div class="space-y-3">
          <LoopStepCard
            v-for="step in currentLoop.steps"
            :key="step.id"
            :step="step"
          />
        </div>
      </div>

      <!-- Eval 分數卡 -->
      <div v-if="evalResults" class="grid grid-cols-4 gap-4">
        <EvalScoreCard
          v-for="eval in evalResults"
          :key="eval.dimension"
          :dimension="eval.dimension"
          :score="eval.score"
          :status="eval.status"
        />
      </div>
    </div>
  </div>
</template>

<script setup lang="ts">
import { ref, computed } from 'vue'
import { useAgentStore } from '@/stores/agent'
import type { LoopTask, LoopResult, EvalResult } from '@/types/agent'

const agentStore = useAgentStore()

const taskInput = ref('')
const selectedModel = ref('claude-sonnet-4-6')
const isRunning = ref(false)
const currentLoop = ref<LoopTask | null>(null)
const evalResults = ref<EvalResult[] | null>(null)

async function executeLoop() {
  if (!taskInput.value.trim()) return

  isRunning.value = true
  try {
    const task: LoopTask = {
      description: taskInput.value,
      model: selectedModel.value,
      maxIterations: 10
    }

    // 透過 SSE 即時接收 Loop 進度
    const eventSource = agentStore.executeLoopWithStream(task)
    eventSource.onmessage = (event) => {
      const data = JSON.parse(event.data)
      currentLoop.value = data.loop
      if (data.evals) evalResults.value = data.evals
    }

    eventSource.onerror = () => {
      isRunning.value = false
      eventSource.close()
    }
  } catch (error) {
    console.error('Loop 執行失敗:', error)
    isRunning.value = false
  }
}
</script>

# deploy/openshift/loop-engineering-platform.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: loop-engine-backend
  namespace: ai-platform
  labels:
    app: loop-engine
    tier: backend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: loop-engine
      tier: backend
  template:
    metadata:
      labels:
        app: loop-engine
        tier: backend
    spec:
      containers:
        - name: backend
          image: registry.company.com/loop-engine/backend:latest
          ports:
            - containerPort: 8080
          env:
            - name: SPRING_PROFILES_ACTIVE
              value: production
            - name: ANTHROPIC_API_KEY
              valueFrom:
                secretKeyRef:
                  name: ai-credentials
                  key: anthropic-api-key
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: db-credentials
                  key: url
          resources:
            requests:
              memory: "1Gi"
              cpu: "500m"
            limits:
              memory: "4Gi"
              cpu: "2000m"
          livenessProbe:
            httpGet:
              path: /actuator/health/liveness
              port: 8080
            initialDelaySeconds: 30
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /actuator/health/readiness
              port: 8080
            initialDelaySeconds: 20
            periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  name: loop-engine-backend-svc
  namespace: ai-platform
spec:
  selector:
    app: loop-engine
    tier: backend
  ports:
    - port: 80
      targetPort: 8080
  type: ClusterIP
---
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: loop-engine-route
  namespace: ai-platform
spec:
  to:
    kind: Service
    name: loop-engine-frontend-svc
  tls:
    termination: edge
    insecureEdgeTerminationPolicy: Redirect

# Step 1: 使用 Planner Agent 分析需求
claude -p "
作為 Planner Agent，請分析以下需求並產出：
1. 功能分解結構（WBS）
2. 技術設計要點
3. 風險識別
4. 工作估算

需求：
- 客戶轉帳功能
- 支援同行轉帳與跨行轉帳
- 支援即時到帳與 T+1 到帳
- 每日轉帳限額 100 萬
- 需要 2FA 驗證
- 需要轉帳記錄查詢
"

# Step 2: Architect Agent 產出設計
claude -p "
根據以下需求設計 Spring Boot 轉帳模組架構：
- Domain Model（使用 DDD）
- API 設計（RESTful）
- 資料庫 Schema
- 狀態機設計（轉帳狀態流轉）
- 安全性考量
" --skill architecture/ddd

# Step 3: 產出開發規格書
claude -p "整合以上分析與設計，產出完整的開發規格書" \
  --output docs/transfer-spec.md

// 範例：轉帳服務實作（由 Coder Agent 產生）
@Service
@RequiredArgsConstructor
@Transactional
@Slf4j
public class TransferService {

    private final AccountRepository accountRepository;
    private final TransferRepository transferRepository;
    private final EventPublisher eventPublisher;
    private final TransferLimitService limitService;
    private final TwoFactorAuthService twoFAService;

    /**
     * 執行轉帳（使用分散式鎖保證冪等性）
     */
    @DistributedLock(keyPrefix = "transfer:", keyParam = "#request.requestId")
    public TransferResult execute(TransferRequest request) {
        log.info("開始處理轉帳: requestId={}, amount={}", request.requestId(), request.amount());

        // 1. 驗證 2FA
        twoFAService.verify(request.userId(), request.otpCode());

        // 2. 載入帳戶（悲觀鎖避免並發問題）
        Account source = accountRepository
            .findByIdWithLock(request.sourceAccountId())
            .orElseThrow(() -> new AccountNotFoundException(request.sourceAccountId()));

        Account target = accountRepository
            .findByIdWithLock(request.targetAccountId())
            .orElseThrow(() -> new AccountNotFoundException(request.targetAccountId()));

        // 3. 檢查轉帳限額
        limitService.checkDailyLimit(source.customerId(), request.amount());

        // 4. 執行轉帳
        source.debit(request.amount());
        target.credit(request.amount());

        // 5. 記錄轉帳
        Transfer transfer = Transfer.create(source, target, request);
        transferRepository.save(transfer);

        // 6. 發布事件
        eventPublisher.publish(TransferCompletedEvent.of(transfer));

        log.info("轉帳完成: transferId={}", transfer.id());
        return TransferResult.success(transfer.id());
    }
}

# 執行完整測試 Loop
cd /workspace/banking-app

# Unit Tests
mvn test -Dtest=TransferServiceTest,AccountServiceTest,LoanServiceTest -B
echo "Unit Test 結果: $?"

# Integration Tests
mvn verify -Dtest=TransferIT,AccountIT -P integration-test -B
echo "Integration Test 結果: $?"

# Security Tests (OWASP)
mvn org.owasp:dependency-check-maven:check -DfailBuildOnCVSS=7
echo "安全掃描結果: $?"

# Performance Tests
mvn gatling:test -Dgatling.simulationClass=TransferSimulation
echo "效能測試結果: $?"

# 若任何測試失敗，觸發 AI 修復 Loop
if [ $? -ne 0 ]; then
  claude "修復以下測試失敗，不得跳過或刪除測試" \
    --context "$(mvn test 2>&1 | tail -100)"
fi

# 網銀系統部署 SOP
set -e  # 任何錯誤立即停止

APP_NAME="banking-app"
NAMESPACE="production"
VERSION="$(mvn help:evaluate -Dexpression=project.version -q -DforceStdout)"

echo "🚀 開始部署 ${APP_NAME}:${VERSION}"

# 1. 建置 Image
echo "📦 建置 Container Image..."
podman build \
  --label "version=${VERSION}" \
  --label "git-commit=$(git rev-parse HEAD)" \
  -t "registry.company.com/${APP_NAME}:${VERSION}" .

# 2. 安全掃描 Image
echo "🔒 掃描 Container 安全性..."
trivy image \
  --exit-code 1 \
  --severity CRITICAL,HIGH \
  "registry.company.com/${APP_NAME}:${VERSION}"

# 3. 推送 Image
echo "⬆️ 推送 Image..."
podman push "registry.company.com/${APP_NAME}:${VERSION}"

# 4. 滾動更新（Zero Downtime）
echo "🔄 執行滾動更新..."
kubectl set image deployment/${APP_NAME} \
  ${APP_NAME}=registry.company.com/${APP_NAME}:${VERSION} \
  -n ${NAMESPACE}

# 5. 等待更新完成
kubectl rollout status deployment/${APP_NAME} -n ${NAMESPACE} --timeout=5m

# 6. 煙霧測試（Smoke Test）
echo "💨 執行煙霧測試..."
API_URL="https://banking.company.com"
curl -sf "${API_URL}/actuator/health" | jq '.status' | grep -q '"UP"'
echo "✅ 部署成功！版本：${VERSION}"

# 7. 若部署失敗，自動回滾
trap 'echo "❌ 部署失敗，執行回滾..."; kubectl rollout undo deployment/${APP_NAME} -n ${NAMESPACE}' ERR

# Step 1: 靜態程式碼分析
echo "🔍 開始分析 Legacy 程式碼..."

# 統計程式碼規模
find src/ -name "*.java" | wc -l
find src/ -name "*.jsp" | wc -l
find src/ -name "*.xml" | wc -l

# 找出所有 EJB
grep -r "@Stateless\|@Stateful\|@MessageDriven\|EJBBean" src/ --include="*.java" -l

# 找出所有 Struts Action
grep -r "extends Action\|ActionSupport" src/ --include="*.java" -l

# 找出複雜方法（超過 100 行）
claude -p "分析以下 Java 檔案，找出所有超過 100 行的方法，並評估重構複雜度" \
  --directory src/ --include "*.java"

# Step 2: 業務邏輯萃取
claude -p "
分析這個 Legacy Java EJB 系統，請：
1. 識別所有業務實體（Entity）
2. 提取核心業務規則
3. 繪製業務流程圖
4. 識別外部系統依賴
並輸出為結構化的 Markdown 文件
" --directory src/ --output docs/business-analysis.md

# Step 3: 資料模型逆向
# 從 DB2 Schema 逆向工程
db2 "EXPORT TO schema.sql OF DEL MESSAGES msgs SELECT TABSCHEMA, TABNAME, COLNAME, TYPENAME FROM SYSCAT.COLUMNS WHERE TABSCHEMA = 'BANKING'"

claude -p "
將以下 DB2 Schema 轉換為：
1. JPA Entity 類別（Java 21 Records 風格）
2. PostgreSQL 16 相容的 DDL
3. Flyway Migration 腳本
4. Spring Data JPA Repository 介面
" --file schema.sql

# Step 4: 產出遷移計劃
claude -p "
根據以上分析，制定完整的遷移計劃：
- 遷移優先順序（從最低風險開始）
- 每個模組的預估工時
- 測試策略（A/B 比對）
- 回滾策略
" --output docs/migration-plan.md

// 建立適配器層（Java 21）
// 讓新舊系統共存，逐步替換

@RestController
@RequestMapping("/api/v2/transfers")  // 新 API
@RequiredArgsConstructor
public class ModernTransferController {
    private final ModernTransferService modernService;
    private final LegacyTransferAdapter legacyAdapter;
    private final FeatureFlagService featureFlag;

    @PostMapping
    public ResponseEntity<TransferResponse> transfer(
            @RequestBody @Valid TransferRequest request) {
        // 功能旗標控制：逐步切換到新系統
        if (featureFlag.isEnabled("modern-transfer", request.customerId())) {
            return ResponseEntity.ok(modernService.execute(request));
        } else {
            // 舊系統 Adapter（橋接層）
            return ResponseEntity.ok(legacyAdapter.execute(request));
        }
    }
}

// Legacy Adapter — 呼叫舊 EJB
@Component
@RequiredArgsConstructor
@Slf4j
public class LegacyTransferAdapter {

    @EJB  // 透過 JNDI 呼叫舊 EJB
    private TransferEJBRemote legacyTransferEJB;

    public TransferResponse execute(TransferRequest request) {
        log.warn("使用 Legacy 轉帳系統（customerId={}）", request.customerId());
        // 呼叫舊系統
        LegacyTransferBean legacyRequest = mapToLegacy(request);
        LegacyTransferResult legacyResult = legacyTransferEJB.transfer(legacyRequest);
        return mapFromLegacy(legacyResult);
    }
}

# === Spring Boot 2.x → 3.5.x 升級 Loop ===

# Step 1: 升級前備份與基準建立
git checkout -b upgrade/spring-boot-3.5
git tag pre-upgrade-baseline

# 建立效能基準
mvn gatling:test -Dgatling.simulationClass=BaselineSimulation
cp -r target/gatling/baseline-* docs/performance-baseline/

# 建立測試基準
mvn test 2>&1 | tee docs/test-baseline.txt

# Step 2: 相依套件分析（使用 AI）
claude -p "
分析 pom.xml，識別所有需要更新的套件：
1. spring-boot-starter-* 到 3.5.x
2. jakarta 相依套件更新
3. 不相容的第三方套件
4. 需要刪除的過時依賴
並產出更新後的 pom.xml
" --file pom.xml --output pom-upgraded.xml

# Step 3: 套件名稱遷移（javax → jakarta）
# 自動遷移
find src/main/java -name "*.java" -exec \
  sed -i 's/import javax\.persistence\./import jakarta.persistence./g' {} +

find src/main/java -name "*.java" -exec \
  sed -i 's/import javax\.validation\./import jakarta.validation./g' {} +

find src/main/java -name "*.java" -exec \
  sed -i 's/import javax\.servlet\./import jakarta.servlet./g' {} +

find src/main/java -name "*.java" -exec \
  sed -i 's/import javax\.transaction\./import jakarta.transaction./g' {} +

# 使用 AI 處理複雜案例
claude -p "
找出所有使用 javax.* 但沒有被自動替換的案例，
並提供正確的 Jakarta 相等替換方案。
同時處理以下 Spring Boot 3.x 破壞性變更：
1. Spring Security 6 的 HttpSecurity 設定語法
2. Spring Data JPA 的 sort() 方法變更
3. Spring Web 的 Path Variable 處理變更
" --directory src/

# Step 4: Spring Security 6 設定遷移
cat > src/main/java/com/bank/config/SecurityConfig.java << 'EOF'
@Configuration
@EnableWebSecurity
@RequiredArgsConstructor
public class SecurityConfig {

    private final JwtTokenProvider jwtProvider;

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        return http
            // Spring Boot 3.x 新語法（lambda 風格）
            .csrf(csrf -> csrf.disable())
            .cors(cors -> cors.configurationSource(corsConfigurationSource()))
            .sessionManagement(session ->
                session.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/api/v1/auth/**", "/actuator/health").permitAll()
                .requestMatchers("/api/v1/admin/**").hasRole("ADMIN")
                .anyRequest().authenticated())
            .addFilterBefore(
                new JwtAuthenticationFilter(jwtProvider),
                UsernamePasswordAuthenticationFilter.class)
            .build();
    }
}
EOF

# Step 5: 設定檔遷移（application.properties）
# Spring Boot 3.x 廢棄設定更新
sed -i 's/spring.datasource.initialization-mode/spring.sql.init.mode/g' \
  src/main/resources/application.properties

sed -i 's/spring.jpa.hibernate.ddl-auto/spring.jpa.hibernate.ddl-auto/g' \
  src/main/resources/application.properties

# Step 6: 建置驗證 Loop
echo "🔨 執行建置驗證..."
mvn clean compile -B 2>&1 | tee logs/compile-result.txt

if [ $? -ne 0 ]; then
  echo "❌ 編譯失敗，啟動 AI 修復 Loop..."
  claude "修復以下 Spring Boot 3.5 編譯錯誤，不得降低目標 Java 版本" \
    --context "$(cat logs/compile-result.txt)"
fi

# Step 7: 測試驗證 Loop
echo "🧪 執行測試驗證..."
mvn verify -B 2>&1 | tee logs/test-result.txt

if [ $? -ne 0 ]; then
  echo "❌ 測試失敗，啟動 AI 修復 Loop..."
  claude "修復測試失敗，分析是功能性回退還是測試本身需要更新" \
    --context "$(cat logs/test-result.txt)"
fi

# Step 8: 安全驗證
echo "🔒 執行安全驗證..."
mvn dependency-check:check -DfailBuildOnCVSS=7

# Step 9: 效能回歸測試
echo "📊 執行效能基準對比..."
mvn gatling:test -Dgatling.simulationClass=BaselineSimulation
# 比對新舊效能
claude -p "
比較以下兩個效能報告，識別任何效能回退（>10% 降低）：
並提供優化建議。
" --file docs/performance-baseline/ --directory target/gatling/

echo "✅ Spring Boot 3.5 升級完成！"

// 問題 1: Spring Security 6 - 方法鏈式呼叫廢棄
// 舊寫法（Spring Boot 2.x）
@Override
protected void configure(HttpSecurity http) throws Exception {
    http.csrf().disable()
        .authorizeRequests()
            .antMatchers("/api/public/**").permitAll()
            .anyRequest().authenticated();
}

// 新寫法（Spring Boot 3.x / Spring Security 6）
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    http
        .csrf(AbstractHttpConfigurer::disable)
        .authorizeHttpRequests(auth -> auth
            .requestMatchers("/api/public/**").permitAll()
            .anyRequest().authenticated());
    return http.build();
}

// 問題 2: JPA EntityManager 方法廢棄
// 舊寫法
TypedQuery<Customer> query = em.createQuery(
    "SELECT c FROM Customer c WHERE c.id = :id", Customer.class);
query.setHint("org.hibernate.cacheable", true);  // 廢棄

// 新寫法（Hibernate 6 / JPA 3.1）
TypedQuery<Customer> query = em.createQuery(
    "SELECT c FROM Customer c WHERE c.id = :id", Customer.class);
query.setHint(HibernateHints.HINT_CACHEABLE, true);  // Jakarta 新常數

// 問題 3: Actuator 端點變更
// application.properties 新設定
management.endpoints.web.exposure.include=health,info,metrics,prometheus
management.endpoint.health.show-details=when-authorized
management.endpoint.health.probes.enabled=true  // Kubernetes 探針

// src/test/java/com/bank/eval/FunctionalEvalSuite.java
@TestSuite
@DisplayName("Functional Eval — 轉帳功能評估")
class TransferFunctionalEvalSuite {

    @EvalTest(weight = 0.3, category = "HAPPY_PATH")
    @DisplayName("正常轉帳流程 — 應成功完成")
    void normalTransfer_shouldSucceed() {
        // Given
        Account source = createAccountWithBalance(new BigDecimal("100000.00"));
        Account target = createEmptyAccount();
        TransferRequest request = TransferRequest.builder()
            .sourceAccountId(source.id())
            .targetAccountId(target.id())
            .amount(new BigDecimal("50000.00"))
            .build();

        // When
        TransferResult result = transferService.execute(request);

        // Then
        assertThat(result.status()).isEqualTo(TransferStatus.SUCCESS);
        assertThat(accountRepository.findById(source.id()).get().balance())
            .isEqualByComparingTo("50000.00");
        assertThat(accountRepository.findById(target.id()).get().balance())
            .isEqualByComparingTo("50000.00");
    }

    @EvalTest(weight = 0.2, category = "EDGE_CASE")
    @DisplayName("餘額不足轉帳 — 應拒絕並回滾")
    void insufficientBalance_shouldRejectAndRollback() {
        Account source = createAccountWithBalance(new BigDecimal("100.00"));
        TransferRequest request = createTransferRequest(
            source.id(), new BigDecimal("1000.00"));

        assertThatThrownBy(() -> transferService.execute(request))
            .isInstanceOf(InsufficientBalanceException.class);

        // 確認無資金被扣除
        assertThat(source.balance()).isEqualByComparingTo("100.00");
    }

    @EvalTest(weight = 0.2, category = "SECURITY")
    @DisplayName("超過每日限額 — 應拒絕")
    void exceedDailyLimit_shouldReject() {
        // 當天已轉帳 90 萬
        simulateDailyTransfers(new BigDecimal("900000.00"));
        TransferRequest request = createTransferRequest(new BigDecimal("200000.00"));

        assertThatThrownBy(() -> transferService.execute(request))
            .isInstanceOf(DailyLimitExceededException.class);
    }

    @EvalTest(weight = 0.15, category = "CONCURRENT")
    @DisplayName("並發轉帳 — 應保證資料一致性")
    void concurrentTransfers_shouldMaintainConsistency() throws Exception {
        Account source = createAccountWithBalance(new BigDecimal("100000.00"));
        int threadCount = 10;
        BigDecimal amountPerTransfer = new BigDecimal("5000.00");

        ExecutorService executor = Executors.newFixedThreadPool(threadCount);
        List<Future<TransferResult>> futures = IntStream.range(0, threadCount)
            .mapToObj(i -> executor.submit(() ->
                transferService.execute(createTransferRequest(source.id(), amountPerTransfer))))
            .toList();

        long successCount = futures.stream()
            .map(f -> f.get())
            .filter(r -> r.status() == TransferStatus.SUCCESS)
            .count();

        // 最終餘額必須一致
        BigDecimal expected = new BigDecimal("100000.00")
            .subtract(amountPerTransfer.multiply(BigDecimal.valueOf(successCount)));
        assertThat(accountRepository.findById(source.id()).get().balance())
            .isEqualByComparingTo(expected);
    }
}

# Security Eval 自動化腳本

# 1. OWASP Dependency Check
echo "📦 相依套件安全掃描..."
mvn dependency-check:check \
  -DfailBuildOnCVSS=7 \
  -DsuppressionFile=.github/security/suppressions.xml \
  -Dformats=HTML,JSON

VULN_COUNT=$(jq '.dependencies[].vulnerabilities | length' target/dependency-check-report.json | awk '{sum+=$1}END{print sum}')
echo "發現漏洞數量: $VULN_COUNT"

# 2. SAST 掃描（SpotBugs + FindSecBugs）
echo "🔍 靜態安全分析..."
mvn com.github.spotbugs:spotbugs-maven-plugin:spotbugs \
  -Dspotbugs.plugins=com.h3xstream.findsecbugs:findsecbugs-plugin:1.12.0

# 3. 秘密掃描
echo "🔑 秘密洩漏掃描..."
gitleaks detect \
  --source . \
  --report-format json \
  --report-path gitleaks-report.json
SECRETS_FOUND=$(jq length gitleaks-report.json)
echo "發現秘密數量: $SECRETS_FOUND"

# 4. OWASP ZAP 動態掃描
echo "🌐 動態安全掃描..."
docker run --rm \
  -v $(pwd)/zap-reports:/zap/wrk \
  owasp/zap2docker-stable zap-baseline.py \
  -t http://localhost:8080 \
  -g gen.conf \
  -r zap-report.html

# 5. Eval 結果彙整
cat > security-eval-report.json << EOF
{
  "eval_type": "security",
  "timestamp": "$(date -u +%Y-%m-%dT%H:%M:%SZ)",
  "results": {
    "dependency_vulnerabilities": $VULN_COUNT,
    "secrets_found": $SECRETS_FOUND,
    "sast_issues": $(jq '.BugCollection.BugInstance | length' target/spotbugsXml.xml),
    "overall_score": $([ "$VULN_COUNT" -eq 0 ] && [ "$SECRETS_FOUND" -eq 0 ] && echo "100" || echo "50")
  },
  "pass": $([ "$VULN_COUNT" -eq 0 ] && [ "$SECRETS_FOUND" -eq 0 ] && echo "true" || echo "false")
}
EOF

第一層：自動化 Evals（Automated Evals）        — 快速、低成本、PR 階段即可攔截
第二層：生產監測（Production Monitoring）       — 觀察上線後的真實行為與異常
第三層：A/B 測試（A/B Testing）                — 比較不同版本迴圈的真實效益差異
第四層：使用者反饋（User Feedback）             — 捕捉自動化機制無法量化的真實感受
第五層：人工審查（Human Review）                — 對高風險變更的最終把關

你是一位 CTO-level 的技術決策 Agent。你的職責：
1. 評估重大技術決策的戰略影響
2. 在安全性、效能、開發效率之間做出平衡決策
3. 識別並管理技術風險
4. 確保技術決策符合業務目標

決策框架：
- 所有架構決策必須考慮 3-5 年的演進路徑
- 安全性問題具有最高優先權
- 效能目標：P95 回應時間 < 500ms
- 成本意識：在不犧牲品質的前提下控制基礎設施成本

輸出格式：
- 決策：明確的建議
- 理由：3 個要點
- 風險：主要風險及緩解策略
- 後續行動：具體的 Action Items

你是一位企業級安全 Agent，專精 OWASP、金融業安全規範。

核心職責：
1. 所有程式碼變更的安全審查
2. 識別 OWASP Top 10 漏洞
3. 金融業特定安全要求（PCI-DSS、銀行法規）
4. 秘密與憑證管理審查

審查清單（每次必查）：
□ SQL Injection 防護（使用 Prepared Statement）
□ XSS 防護（輸入驗證 + 輸出編碼）
□ 認證機制（JWT 有效期、刷新策略）
□ 授權控制（Row-level Security、最小權限）
□ 敏感資料保護（加密、日誌遮罩）
□ 依賴套件漏洞（CVE 資料庫）
□ 硬編碼秘密（API Key、密碼）
□ 轉帳金額的精度問題（BigDecimal vs double）

回報格式：SARIF 格式，附上 CVSS 評分與修復建議

# SOP-008: AI Agent Team 任務協作流程

# 使用 Claude Code 的多 Agent 模式
claude run-agent-team \
  --task "實作客戶帳戶模組" \
  --agents "planner,architect,backend,dba,tester,security,devops" \
  --worktrees true \
  --parallel true \
  --eval-threshold 85

# 或者手動協調各 Agent
# Step 1: PM Agent 分解需求
claude --agent pm -p "將以下需求分解為具體的開發任務，並評估優先級和相依關係" \
  --input requirements/customer-module.md \
  --output tasks/customer-module-tasks.json

# Step 2: Architect Agent 設計架構
claude --agent architect -p "根據任務清單設計系統架構，產出：API 設計、DB Schema、元件圖" \
  --input tasks/customer-module-tasks.json \
  --output design/customer-module-design.md

# Step 3: 並行開發（Backend + Frontend + DBA）
git worktree add -b feature/customer-backend ../wt-backend main
git worktree add -b feature/customer-frontend ../wt-frontend main
git worktree add -b feature/customer-db ../wt-db main

# 並行啟動三個 Agent
(cd ../wt-backend && claude --agent backend -p "實作客戶管理後端 API" --skill coding/java-spring-boot) &
(cd ../wt-frontend && claude --agent frontend -p "實作客戶管理前端介面" --skill coding/vue3-typescript) &
(cd ../wt-db && claude --agent dba -p "設計並撰寫資料庫 Migration" --skill coding/database-optimization) &
wait

# Step 4: QA Agent 執行測試
claude --agent tester -p "為客戶管理模組撰寫完整的測試套件（單元 + 整合 + E2E）"

# Step 5: Security Agent 審查
claude --agent security -p "對客戶管理模組進行完整的安全審查，特別注意個資保護"

# Step 6: 整合與部署
git merge feature/customer-backend feature/customer-frontend feature/customer-db
claude --agent devops -p "建立部署 Pipeline 並執行 Canary 部署到 Staging"

# SOP-009: 威脅建模 Loop（使用 AI 輔助）

# Step 1: 生成系統上下文圖
claude -p "
根據以下系統架構，使用 STRIDE 威脅建模方法：
1. 識別所有信任邊界（Trust Boundaries）
2. 識別資料流（Data Flows）
3. 識別威脅（Spoofing/Tampering/Repudiation/Info Disclosure/DoS/EoP）
4. 評估風險等級（CVSS 評分）
5. 提出緩解措施

系統：網路銀行轉帳功能
元件：瀏覽器 → API Gateway → Transfer Service → Account DB
" --output docs/threat-model.md

# Step 2: 自動建立安全測試案例
claude -p "
根據威脅模型，為以下威脅建立自動化安全測試：
1. SQL Injection 攻擊測試
2. JWT Token 偽造測試
3. 並發轉帳競態條件測試
4. 金額精度攻擊測試（BigDecimal）
5. 帳號枚舉攻擊防護測試
" --skill security/owasp-top10 --output src/test/java/security/

# Step 3: 持續安全掃描 Loop
#!/bin/bash
# 每次提交時自動執行安全掃描

echo "🔒 啟動安全掃描 Loop..."

# SAST
mvn spotbugs:spotbugs 2>&1 | tee logs/sast.log
SAST_ISSUES=$(grep -c "Bug" logs/sast.log || echo 0)

# 相依套件
mvn dependency-check:check 2>&1 | tee logs/dep-check.log
CRITICAL_VULNS=$(grep -c "CRITICAL" logs/dep-check.log || echo 0)

# 秘密掃描
gitleaks detect --source . 2>&1 | tee logs/secrets.log
SECRETS=$(grep -c "Finding" logs/secrets.log || echo 0)

# 若有嚴重問題，停止 Pipeline
if [ "$CRITICAL_VULNS" -gt 0 ] || [ "$SECRETS" -gt 0 ]; then
  echo "❌ 安全掃描失敗！"
  echo "嚴重漏洞: $CRITICAL_VULNS"
  echo "秘密洩漏: $SECRETS"
  
  # 啟動 AI 修復 Loop
  claude "立即修復以下安全問題，優先處理 CRITICAL 等級" \
    --context "$(cat logs/dep-check.log logs/secrets.log)" \
    --priority critical
  exit 1
fi

echo "✅ 安全掃描通過！SAST Issues: $SAST_ISSUES"

你是一位 Google Staff Engineer 等級的系統架構師。

請為以下系統設計完整架構：
系統名稱：[系統名稱]
業務背景：[業務描述]
技術約束：[現有技術棧、預算、團隊規模]
非功能需求：[QPS、延遲、可用性、合規]

請輸出：
1. C4 架構圖（Context → Container → Component）
2. 技術選型決策矩陣（含理由）
3. 關鍵設計決策（ADR 格式）
4. 主要風險與緩解策略
5. 12 個月演進路線圖

約束：
- 使用 Mermaid 繪製所有圖表
- 每個決策必須說明「為何不選 X」
- 必須考慮安全性、可觀測性、成本

## 架構決策記錄 (ADR-001)
**決策**：使用 PostgreSQL 作為主要資料庫
**狀態**：已接受
**背景**：需要強一致性、JSON 支援、Row-level Security
**決策理由**：
- PostgreSQL 16 原生 JSON 操作效能優異
- Row-level Security 滿足金融合規要求
- pgvector 擴展支援 AI 向量儲存
**為何不選 MySQL**：缺乏 Row-level Security 原生支援
**為何不選 MongoDB**：事務支援較弱，不符合金融業 ACID 要求

作為 API Design Lead，請審查以下 REST API 設計：

[貼上 API 規格或 OpenAPI YAML]

審查重點：
1. REST 語意正確性（HTTP 方法、狀態碼）
2. 資源命名規範（名詞複數、kebab-case）
3. 版本控制策略
4. 分頁與過濾設計
5. 錯誤回應格式統一性
6. 安全性（認證、授權、輸入驗證）
7. 效能考量（快取、壓縮）
8. 向後相容性

輸出：
- 問題清單（附嚴重程度：CRITICAL/HIGH/MEDIUM/LOW）
- 修改後的 OpenAPI Spec
- 每個修改的說明

我們有一個 Java 單體應用，包含以下模組：
[列出模組清單及相依關係]

請使用 DDD（Domain-Driven Design）方法：
1. 識別 Bounded Context
2. 設計服務邊界（高內聚、低耦合）
3. 識別 Anti-corruption Layer 需求
4. 設計服務間通訊方式（同步/非同步）
5. 評估拆分的優先順序與風險
6. 繪製 Context Map

輸出格式：
- Mermaid Context Map
- 服務清單及職責
- 拆分路線圖（分 3 個 Phase）
- 每個 Phase 的驗收標準

你是一位 Java 21 + Spring Boot 3.5 專家。

請實作以下功能：
功能描述：[描述]
業務規則：[規則清單]
技術約束：[現有框架、限制]

實作要求：
1. 遵循 Hexagonal Architecture（Port & Adapter）
2. 使用 Java 21 Record、Pattern Matching、Virtual Threads
3. 完整的 Bean Validation（@Valid + 自定義 Validator）
4. 使用 Spring Data JPA（禁止 Native SQL，除非必要）
5. 統一的錯誤處理（@ControllerAdvice）
6. 完整的 Swagger/OpenAPI 文件（@Operation, @Schema）
7. 所有方法需有對應的 JUnit 5 測試（覆蓋率 ≥ 80%）

禁止：
- 在 Controller 直接使用 EntityManager
- 回傳 Entity 物件（必須使用 DTO）
- 忽略任何輸入驗證
- 使用 deprecated API

輸出包含：
- 完整的 Java 程式碼（Controller/Service/Repository/Entity/DTO）
- 對應的 JUnit 5 測試
- Liquibase/Flyway Migration 腳本

請重構以下 Java 程式碼：

[貼上程式碼]

重構目標：
1. 降低圈複雜度（目標：< 10）
2. 消除重複程式碼（DRY 原則）
3. 改善命名（符合 DDD Ubiquitous Language）
4. 應用適當的設計模式（說明選擇理由）
5. 提升可測試性（依賴注入、純函數）
6. 消除 Magic Number/String
7. 改善錯誤處理（明確的例外類型）

約束：
- 不得改變外部介面（API 向後相容）
- 不得引入新的第三方依賴
- 重構後所有現有測試必須仍然通過

輸出：
- 重構後的程式碼
- 重構說明（逐點解釋每個改動）
- 若有設計模式應用，說明選擇理由

請分析並優化以下 JPA 查詢效能問題：

現象：[描述效能問題，例如：API 回應時間 3 秒]
資料量：[表格資料量估計]
查詢頻率：[每秒呼叫次數]

現有程式碼：
[貼上 JPA Repository/Service 程式碼]

Slow Query Log：
[貼上資料庫慢查詢日誌]

請分析：
1. 識別 N+1 查詢問題
2. 缺失的索引
3. 不當的 Fetch Type 設定
4. 可以用快取解決的場景
5. 是否需要 CQRS 分離讀寫

輸出：
- 問題根因分析
- 優化後的程式碼（含 @EntityGraph/@BatchSize 等）
- 建議的索引 DDL
- 預期效能改善幅度

請為以下 Java 程式碼產生完整的 JUnit 5 測試套件：

[貼上程式碼]

測試要求：
1. 涵蓋所有 Happy Path（正常流程）
2. 涵蓋所有邊界條件（邊界值分析）
3. 涵蓋所有錯誤場景（例外情況）
4. 並發/線程安全測試（若適用）
5. 效能測試（若有效能要求）

技術要求：
- 使用 JUnit 5 + Mockito 5 + AssertJ
- 使用 @DisplayName 清楚描述測試意圖
- 使用 @ParameterizedTest 減少重複
- 使用 @TestMethodOrder(MethodOrderer.OrderAnnotation.class) 若有依賴
- 整合測試使用 @SpringBootTest + Testcontainers（PostgreSQL）
- 禁止直接 Mock 靜態方法（代表設計問題，需先重構）

目標覆蓋率：
- 行覆蓋率：≥ 80%
- 分支覆蓋率：≥ 75%
- 重要業務邏輯：100%

請為以下使用者故事撰寫 Playwright E2E 測試：

使用者故事：
作為 [角色]，我想要 [功能]，以便 [業務價值]

頁面 URL：[URL]
測試環境：[Staging URL]

測試場景：
1. Happy Path（成功完成所有步驟）
2. 表單驗證（各欄位的驗證規則）
3. 錯誤處理（伺服器錯誤、網路中斷）
4. 無障礙測試（WCAG 2.1 AA）
5. 行動裝置相容性（viewport: 375px）

技術要求：
- TypeScript
- Page Object Model 設計模式
- 使用 expect() 而非 waitForSelector
- 測試資料使用 fixtures，不依賴環境資料
- 失敗時自動截圖並上傳 CI 記錄

請分析以下程式碼的技術債務並提供清償計劃：

[貼上程式碼或提供目錄路徑]

分析維度：
1. 程式碼異味（Code Smells）識別與分類
2. 設計債務（缺乏抽象、違反 SOLID）
3. 測試債務（缺少測試、脆弱測試）
4. 文件債務（缺少說明、過時文件）
5. 相依套件債務（過舊、有漏洞的套件）

輸出：
- 技術債務清單（依優先級排序）
- 每項債務的：業務影響、修復成本、建議時程
- 建議的清償路線圖（分 Sprint 規劃）
- Quick Win（< 1 小時可完成的項目）

分析以下程式碼，識別可以應用設計模式的場景，並提供重構方案：

[貼上程式碼]

請聚焦以下模式（金融系統常用）：
- Strategy：不同的計算策略（利率計算/手續費計算）
- State：狀態機（訂單狀態/交易狀態）
- Observer：事件通知（帳戶餘額變動）
- Builder：複雜物件建立（轉帳請求）
- Factory：物件建立邏輯（不同類型帳戶）
- Decorator：功能增強（日誌/快取/驗證）

對每個建議的模式：
1. 說明當前問題
2. 說明模式如何解決
3. 提供重構前後的程式碼對比
4. 說明權衡（何時不應使用此模式）

請分析以下 pom.xml，制定安全的依賴升級計劃：

[貼上 pom.xml]

分析要求：
1. 識別所有有已知漏洞的依賴（CVE 資料庫）
2. 識別可以升級到新主版本的套件（Breaking Changes 評估）
3. 識別廢棄的套件（建議替代品）
4. 評估升級的相容性風險

升級計劃格式：
- 緊急升級（有 CRITICAL/HIGH CVE）：本週完成
- 重要升級（有 MEDIUM CVE + 功能更新）：本月完成
- 計劃升級（小版本/補丁更新）：下個 Sprint
- 評估升級（主版本升級）：本季評估

對每個升級項目：
- 當前版本 → 目標版本
- 主要變更點（Breaking Changes）
- 測試重點
- 回滾策略

請為以下 Spring Boot 2.7 應用程式提供升級至 3.5 的詳細遷移指南：

[提供 pom.xml + 主要設定檔]

請涵蓋：
1. javax → jakarta 套件遷移（完整對應表）
2. Spring Security 5 → 6 的 API 變更
3. Spring Data 2 → 3 的變更
4. Actuator 端點變更
5. 自動設定變更（spring.factories → AutoConfiguration.imports）
6. 日誌變更（Log4j 2 版本）
7. Java 17 相容性（需要更新的語法）

輸出格式：
- 逐步遷移指令（Shell Scripts）
- 自動化遷移腳本（sed/awk 批次替換）
- 需要手動處理的項目清單
- 驗證清單（升級後的測試重點）

請分析以下 Legacy Java 程式碼庫（Java 6 + Struts + EJB）：

[提供程式碼目錄或關鍵檔案]

分析目標：
1. 識別所有業務功能（建立功能清單）
2. 繪製模組相依關係圖
3. 識別核心業務邏輯（與框架程式碼分離）
4. 識別所有外部系統整合點（DB/MQ/外部 API）
5. 識別隱藏的業務規則（硬編碼在程式碼中的規則）

特別注意：
- 金融計算邏輯（利率/手續費/匯率）
- 狀態轉換邏輯（交易狀態機）
- 授權邏輯（帳號存取控制）
- 批次處理邏輯（夜間結算）

輸出：
- 功能清單（含業務重要性評級）
- 架構圖（Mermaid）
- 業務規則文件（Markdown）
- 高風險遷移項目清單

請為以下 Spring Boot Controller 產生完整的 API 文件：

[貼上 Controller 程式碼]

文件要求：
1. OpenAPI 3.x Annotation（@Operation/@ApiResponse/@Schema）
2. 每個 Endpoint 的：
   - 功能說明（使用業務語言，非技術術語）
   - 請求範例（curl + JSON）
   - 成功回應範例
   - 錯誤回應範例（所有可能的錯誤碼）
3. 認證方式說明（Bearer Token）
4. 速率限制說明
5. Changelog（若有版本歷史）

額外要求：
- 提供 Postman Collection JSON
- 提供 API 測試用的 curl 指令（含各種場景）

你是一位資深安全工程師，專精 OWASP 與金融業安全規範（PCI-DSS）。

請對以下程式碼進行安全審查：

[貼上程式碼]

審查框架：OWASP Top 10 2021

重點關注（金融系統）：
1. 注入攻擊：SQL/JNDI/LDAP Injection
2. 認證：JWT 驗證強度、Session 管理
3. 敏感資料：帳號/密碼/交易資料的加密與日誌遮罩
4. 授權：水平與垂直權限提升
5. 金融特定：BigDecimal 精度、轉帳競態條件、重放攻擊

輸出格式（SARIF 相容）：
{
  "findings": [
    {
      "severity": "CRITICAL|HIGH|MEDIUM|LOW",
      "cwe": "CWE-89",
      "owasp": "A03:2021",
      "location": "檔案:行號",
      "description": "問題描述",
      "code_snippet": "問題程式碼",
      "remediation": "修復方案",
      "fixed_code": "修復後程式碼"
    }
  ]
}

請對以下系統/功能進行 STRIDE 威脅建模：

系統描述：[描述]
資料流圖：[提供 DFD 或系統架構描述]
資產清單：[需要保護的資產]

STRIDE 分析：
S - Spoofing（身份偽造）：攻擊者能否冒充合法使用者？
T - Tampering（資料篡改）：資料在傳輸或儲存中能否被修改？
R - Repudiation（否認）：使用者能否否認其操作？
I - Information Disclosure（資訊洩露）：敏感資料是否可能外洩？
D - Denial of Service（阻斷服務）：服務是否容易被癱瘓？
E - Elevation of Privilege（權限提升）：一般使用者能否獲得管理員權限？

對每個威脅：
- 威脅描述（具體的攻擊場景）
- CVSS v3.1 評分
- 緩解措施（技術 + 管理）
- 驗證方式（如何確認已緩解）

你是一位 Principal Engineer，請審查以下 Pull Request：

PR 標題：[標題]
PR 描述：[描述]
Changed Files：[diff 內容]

審查維度（依重要性排序）：
1. 🔴 正確性：邏輯錯誤、邊界條件、資料一致性
2. 🔴 安全性：OWASP Top 10、敏感資料處理
3. 🟡 效能：N+1 查詢、不必要的計算、記憶體洩漏
4. 🟡 可維護性：複雜度、命名、責任分離
5. 🟢 測試：覆蓋率、測試品質
6. 🟢 文件：JavaDoc、API 文件

輸出格式（每個意見）：
**[嚴重程度] 檔案:行號**
問題：[描述問題]
建議：[具體改進方案]
範例：
  // 修改前
  舊程式碼
  // 修改後
  新程式碼

最後提供：
- 整體評估：APPROVE / REQUEST_CHANGES / COMMENT
- 優先修復項目清單（若有 REQUEST_CHANGES）

請審查以下程式碼是否符合我們的架構規範：

架構規範：
1. 使用 Hexagonal Architecture（Controller → Service → Domain → Repository）
2. 禁止跨層相依（Controller 不得直接呼叫 Repository）
3. Domain 物件不得有 Spring 依賴
4. 所有外部系統呼叫必須透過 Port Interface
5. 禁止在 Service 層拋出 HTTP 狀態碼相關例外

程式碼：
[貼上程式碼]

輸出：
- 違反規範的項目清單（含位置）
- 每個違反項目的修正建議
- 架構合規評分（0-100）

請審查以下程式碼的效能問題：

業務背景：[說明流量規模，如：每秒 1000 TPS]
SLA 要求：[P95 < 200ms, P99 < 500ms]

程式碼：
[貼上程式碼]

請識別：
1. N+1 查詢問題（JPA Lazy Loading）
2. 可以快取的計算（Redis/本地快取）
3. 可以非同步處理的操作（Kafka/Virtual Threads）
4. 不必要的序列化/反序列化
5. 大型物件建立（物件池/重用）
6. 阻塞操作（I/O、外部 API 呼叫）

對每個問題：
- 問題描述與影響量化（延遲增加多少？）
- 修復方案（含程式碼）
- 預期效能改善

請審查以下資料庫 Schema：

[貼上 DDL SQL]

審查項目：
1. 正規化（NF 檢查，避免過度正規化）
2. 索引策略（查詢模式與索引的匹配度）
3. 資料型態選擇（VARCHAR 長度、DECIMAL 精度）
4. 外鍵約束（資料完整性）
5. 金融資料特殊考量：
   - 金額欄位必須使用 DECIMAL(19,4)
   - 時間戳必須含時區（TIMESTAMPTZ）
   - 帳號/卡號需要加密或 Tokenization
6. 效能考量（Partition 策略、大型表格）
7. 稽核欄位（created_at, updated_at, created_by）

輸出：
- 問題清單（嚴重程度分級）
- 修改後的 DDL
- 索引建議
- 效能預估

---
skill: java-spring-boot
version: 1.0
tags: [java, spring-boot, backend]
applicable-to: [Java 21, Spring Boot 3.x]
last-updated: 2026-07-20
---

# Spring Boot 開發技能

## 適用情境
在 Java 21 + Spring Boot 3.x 專案中新增或修改後端功能，包含 Controller、Service、Repository 三層的實作。

## 核心原則
1. 遵循 Hexagonal Architecture：Controller 只負責協定轉換，商業邏輯放在 Service
2. 一律使用建構子注入（Constructor Injection），禁止 Field Injection
3. 使用 Java 21 Record 作為 DTO，搭配 Bean Validation 註解
4. 所有對外行為必須有對應的 JUnit 5 測試

## 標準做法

### Controller 層
```java
@RestController
@RequestMapping("/api/v1/accounts")
@RequiredArgsConstructor
public class AccountController {
    private final AccountService accountService;

    @PostMapping("/{id}/transfer")
    public ResponseEntity<TransferResult> transfer(
            @PathVariable Long id,
            @RequestBody @Valid TransferRequest request) {
        return ResponseEntity.ok(accountService.transfer(id, request));
    }
}
```

### Service 層（商業邏輯與交易邊界）
```java
@Service
@RequiredArgsConstructor
@Transactional
public class AccountService {
    private final AccountRepository accountRepository;

    public TransferResult transfer(Long fromId, TransferRequest request) {
        Account from = accountRepository.findByIdForUpdate(fromId)
            .orElseThrow(() -> new AccountNotFoundException(fromId));
        from.withdraw(request.amount());
        accountRepository.save(from);
        return new TransferResult(from.getId(), from.getBalance());
    }
}
```

## 禁止事項
- 不得在 Controller 直接呼叫 Repository
- 不得使用 `@Autowired` Field Injection
- 不得在 Service 方法簽章外洩漏 JPA Entity（回傳需轉換為 DTO/Record）
- 不得忽略 `@Transactional` 的邊界設計（避免長交易鎖表）

## 驗收標準
- [ ] Controller / Service / Repository 職責邊界清楚，無跨層存取
- [ ] 所有輸入皆有 Bean Validation
- [ ] 對應的 JUnit 5 測試涵蓋 Happy Path 與至少一個例外情境
- [ ] 金額欄位使用 `BigDecimal` 而非 `double`

## 參考資料
- Spring Boot 官方文件－Building RESTful Web Services
- 本手冊 4.3.2 節 Skill 檔案格式範例

---
skill: vue3-typescript
version: 1.0
tags: [vue3, typescript, frontend]
applicable-to: [Vue 3, TypeScript]
last-updated: 2026-07-20
---

# Vue3 + TypeScript 技能

## 適用情境
開發或維護使用 Vue 3 Composition API 與 TypeScript 的前端元件與頁面。

## 核心原則
1. 一律使用 `<script setup lang="ts">`，不使用 Options API
2. 元件 Props / Emits 必須有明確型別定義
3. 共用邏輯抽為 Composable（`useXxx`），不得複製貼上
4. 狀態管理使用 Pinia，禁止跨元件直接存取彼此的內部 ref

## 標準做法

### 型別化的元件
```vue
<script setup lang="ts">
interface Props {
  accountId: string
  readonly?: boolean
}
const props = withDefaults(defineProps<Props>(), { readonly: false })

const emit = defineEmits<{
  (e: 'update', balance: number): void
}>()
</script>
```

### Composable 抽取共用邏輯
```typescript
export function useAccountBalance(accountId: Ref<string>) {
  const balance = ref<number | null>(null)
  const loading = ref(false)

  async function refresh() {
    loading.value = true
    balance.value = await accountApi.getBalance(accountId.value)
    loading.value = false
  }

  watch(accountId, refresh, { immediate: true })
  return { balance, loading, refresh }
}
```

## 禁止事項
- 不得使用 `any` 型別逃避型別檢查
- 不得在元件內直接 `fetch`，一律透過封裝的 API Client
- 不得使用 Options API 混寫在同一專案中造成風格不一致

## 驗收標準
- [ ] `vue-tsc --noEmit` 無型別錯誤
- [ ] Props / Emits 皆有型別，無隱式 `any`
- [ ] 重複超過兩次的邏輯已抽為 Composable

## 參考資料
- Vue 3 官方文件－Composition API FAQ
- Vue 3 官方文件－TypeScript 支援指南

---
skill: clean-code
version: 1.0
tags: [clean-code, readability, maintainability]
applicable-to: [Any Language]
last-updated: 2026-07-20
---

# Clean Code 技能

## 適用情境
撰寫新程式碼或審查既有程式碼的可讀性與可維護性，適用於任何語言。

## 核心原則
1. 命名即文件：變數/函式名稱應清楚表達意圖，不需額外註解
2. 函式只做一件事（Single Responsibility），圈複雜度盡量 < 10
3. 避免超過 3 層的巢狀 if/for，改用早期返回（Early Return）或抽取函式
4. 註解只寫「為什麼」，不寫「做什麼」

## 標準做法

### 早期返回取代巢狀判斷
```java
// Before
public BigDecimal calculateDiscount(Order order) {
    if (order != null) {
        if (order.getCustomer().isVip()) {
            if (order.getTotal().compareTo(THRESHOLD) > 0) {
                return order.getTotal().multiply(VIP_RATE);
            }
        }
    }
    return BigDecimal.ZERO;
}

// After
public BigDecimal calculateDiscount(Order order) {
    if (order == null || !order.getCustomer().isVip()) {
        return BigDecimal.ZERO;
    }
    if (order.getTotal().compareTo(THRESHOLD) <= 0) {
        return BigDecimal.ZERO;
    }
    return order.getTotal().multiply(VIP_RATE);
}
```

## 禁止事項
- 不得使用單字母變數名（迴圈索引 `i`/`j` 除外）
- 不得留下被註解掉的死程式碼
- 不得寫超過 50 行的單一函式（特殊情境需在 PR 說明理由）

## 驗收標準
- [ ] 圈複雜度（Cyclomatic Complexity）< 10
- [ ] 無被註解掉的死程式碼
- [ ] 命名通過「不看實作也能猜到用途」的檢驗

## 參考資料
- Robert C. Martin《Clean Code: A Handbook of Agile Software Craftsmanship》

---
skill: design-patterns
version: 1.0
tags: [design-patterns, architecture, java]
applicable-to: [Java]
last-updated: 2026-07-20
---

# 設計模式應用技能

## 適用情境
面對重複的條件分支、物件建立邏輯複雜、或需要在不修改既有程式碼前提下擴充行為時，評估並套用適當的設計模式。

## 核心原則
1. 模式服務於問題，不為了炫技而套用模式（YAGNI）
2. 優先使用組合（Composition）而非繼承
3. 每次套用模式都必須在 PR 中說明「為何選這個模式、放棄了哪些替代方案」
4. 依賴抽象（Interface），不依賴具體實作

## 標準做法

### Strategy Pattern 取代龐大 switch
```java
public interface FeeCalculator {
    BigDecimal calculate(Transaction tx);
}

@Component
public class WireTransferFeeCalculator implements FeeCalculator {
    public BigDecimal calculate(Transaction tx) {
        return tx.getAmount().multiply(new BigDecimal("0.001"));
    }
}

@Service
@RequiredArgsConstructor
public class FeeService {
    private final Map<TransactionType, FeeCalculator> calculators;

    public BigDecimal calculateFee(Transaction tx) {
        return calculators.get(tx.getType()).calculate(tx);
    }
}
```

## 禁止事項
- 不得為單一情境（只有一種實作）預先套用 Strategy/Factory 等模式
- 不得用繼承達成程式碼重用而忽略里氏替換原則（LSP）
- 不得引入模式後反而增加理解成本卻無實際彈性收益

## 驗收標準
- [ ] PR 描述中說明選用理由與放棄的替代方案
- [ ] 新增分支邏輯時無需修改既有類別（符合開放封閉原則）
- [ ] 單元測試可針對每個策略/實作獨立測試

## 參考資料
- Gang of Four《Design Patterns: Elements of Reusable Object-Oriented Software》

---
skill: api-design
version: 1.0
tags: [api-design, rest, openapi]
applicable-to: [REST API, OpenAPI]
last-updated: 2026-07-20
---

# RESTful API 設計技能

## 適用情境
設計新的 REST API 端點，或審查既有 API 的一致性與向後相容性。

## 核心原則
1. 資源用名詞複數（`/accounts`），動作用 HTTP 動詞表達，不用動詞當路徑
2. 狀態碼語意正確：200/201/204 成功、400/404/409 用戶端錯誤、500 伺服端錯誤
3. 分頁、排序、過濾使用一致的 Query 參數慣例（`page`, `size`, `sort`, `filter`）
4. 每個端點都要有對應的 OpenAPI 描述

## 標準做法

### 資源與版本命名
```
GET    /api/v1/accounts?page=0&size=20&sort=createdAt,desc
POST   /api/v1/accounts
GET    /api/v1/accounts/{id}
PATCH  /api/v1/accounts/{id}
DELETE /api/v1/accounts/{id}
POST   /api/v1/accounts/{id}/transfer   # 動作型端點才允許動詞
```

### 統一錯誤回應格式
```json
{
  "timestamp": "2026-07-20T10:00:00Z",
  "status": 409,
  "error": "INSUFFICIENT_BALANCE",
  "message": "帳戶餘額不足以完成此交易",
  "traceId": "a1b2c3d4"
}
```

## 禁止事項
- 不得在 URL 中放動詞（如 `/getAccountById`）
- 不得讓同一個資源在不同端點回傳不一致的欄位命名風格
- 不得省略版本號（`/v1/`），造成未來無法平滑升級

## 驗收標準
- [ ] 所有端點皆有 OpenAPI/Swagger 文件
- [ ] 錯誤回應格式全站一致
- [ ] 破壞性變更（Breaking Change）皆透過新版本號釋出，不直接修改既有端點

## 參考資料
- Microsoft REST API Guidelines
- OpenAPI 3.x 規範（https://spec.openapis.org/oas/latest.html）

---
skill: database-optimization
version: 1.0
tags: [database, performance, jpa, sql]
applicable-to: [JPA, PostgreSQL, MySQL]
last-updated: 2026-07-20
---

# 資料庫優化技能

## 適用情境
API 回應時間異常、資料庫 CPU 過高、或 JPA 出現 N+1 查詢問題時的分析與優化。

## 核心原則
1. 先量測再優化：以 Slow Query Log／APM 找出真正的瓶頸，不憑感覺猜測
2. 索引服務於查詢模式，而非每個欄位都建索引
3. 讀寫分離：高頻讀取場景優先考慮快取，而非一味加索引
4. 避免過早引入 CQRS／讀寫分離等重量級方案，先確認負載真的需要

## 標準做法

### 解決 N+1 查詢
```java
// Before：每筆 Order 各自查詢一次 Customer（N+1）
List<Order> orders = orderRepository.findAll();

// After：使用 @EntityGraph 一次查完
@EntityGraph(attributePaths = {"customer"})
List<Order> findAllWithCustomer();
```

### 索引設計原則
```sql
-- 依實際查詢條件建立複合索引，欄位順序 = 等值查詢在前、範圍查詢在後
CREATE INDEX idx_transaction_account_created
    ON transactions (account_id, created_at DESC);
```

## 禁止事項
- 不得在沒有量測資料的情況下大量新增索引（索引也有寫入成本）
- 不得用 `SELECT *`，尤其在大表格上
- 不得對高基數（High Cardinality）以外的欄位建立單欄索引卻期待顯著效益

## 驗收標準
- [ ] 優化前後皆有效能量測數據對比
- [ ] N+1 查詢問題已透過 `@EntityGraph`/`JOIN FETCH`/`@BatchSize` 解決
- [ ] 新增索引已確認對應的查詢計畫（EXPLAIN）確實走索引

## 參考資料
- 本手冊 14.2 節 Prompt-006（資料庫查詢優化 Prompt）

---
skill: microservices
version: 1.0
tags: [microservices, architecture, ddd]
applicable-to: [Java, Spring Boot, Microservices]
last-updated: 2026-07-20
---

# 微服務架構技能

## 適用情境
評估單體應用是否該拆分、或設計新微服務的邊界與通訊方式時使用。

## 核心原則
1. 服務邊界依 Bounded Context 劃分，而非依技術層（不要拆成 UI 服務、DB 服務）
2. 每個服務擁有自己的資料庫，禁止跨服務直接存取他人資料表
3. 服務間同步呼叫用 REST/gRPC，非同步事件用訊息佇列，依一致性需求選擇
4. 拆分前先確認組織與團隊結構能對應到服務邊界（Conway's Law）

## 標準做法

### 服務邊界識別（以 Context Map 表達）
```text
Order Context ──(同步 REST)──> Inventory Context
     │
     └──(非同步 Event: OrderPlaced)──> Notification Context
                                   └──> Billing Context
```

### 服務間資料一致性：Saga 模式
```java
@Component
public class OrderSagaOrchestrator {
    public void handle(OrderPlacedEvent event) {
        try {
            inventoryClient.reserve(event.orderId(), event.items());
            billingClient.charge(event.orderId(), event.amount());
        } catch (ReservationFailedException e) {
            billingClient.refund(event.orderId());
        }
    }
}
```

## 禁止事項
- 不得讓兩個服務共用同一張資料表
- 不得在服務間用分散式交易（2PC）取代 Saga，除非已充分評估效能代價
- 不得在尚未有明確 Bounded Context 前就以「未來可能要拆」為由過早拆分

## 驗收標準
- [ ] 每個服務可獨立部署、獨立資料庫
- [ ] 跨服務資料一致性策略（Saga/Event）已文件化
- [ ] Context Map 已繪製並經團隊審閱

## 參考資料
- Sam Newman《Building Microservices》
- 本手冊 3.2 節 Multi-Agent Architecture

---
skill: hexagonal-architecture
version: 1.0
tags: [hexagonal-architecture, ports-and-adapters, clean-architecture]
applicable-to: [Java, Spring Boot]
last-updated: 2026-07-20
---

# 六角形架構技能

## 適用情境
希望核心商業邏輯不被框架、資料庫或外部服務綁死，以利長期維護與測試時採用。

## 核心原則
1. Domain 層不得依賴 Spring/JPA 等框架註解
2. 對外的輸入輸出一律透過 Port（介面）定義，Adapter 實作細節
3. 依賴方向永遠指向內（Adapter → Domain，Domain 不知道 Adapter 的存在）
4. 每個 Adapter 可被替換（例如 REST Adapter 換成 gRPC Adapter）而不動 Domain

## 標準做法

### Port（介面）定義於 Domain
```java
// domain 層，不依賴任何框架
public interface AccountRepositoryPort {
    Optional<Account> findById(AccountId id);
    void save(Account account);
}
```

### Adapter 實作（infrastructure 層）
```java
@Repository
@RequiredArgsConstructor
public class JpaAccountRepositoryAdapter implements AccountRepositoryPort {
    private final AccountJpaRepository jpaRepository;

    public Optional<Account> findById(AccountId id) {
        return jpaRepository.findById(id.value()).map(AccountMapper::toDomain);
    }

    public void save(Account account) {
        jpaRepository.save(AccountMapper.toEntity(account));
    }
}
```

## 禁止事項
- 不得在 Domain 層 import `jakarta.persistence.*` 或 `org.springframework.*`
- 不得讓 Application Service 直接依賴 Adapter 的具體類別
- 不得為求方便讓 Domain 物件與 JPA Entity 共用同一個類別

## 驗收標準
- [ ] Domain 層無框架依賴，可獨立編譯測試
- [ ] 所有外部互動（DB、外部 API、訊息佇列）皆透過 Port 定義
- [ ] 更換 Adapter 實作不需修改 Domain 或 Application 層程式碼

## 參考資料
- Alistair Cockburn — Hexagonal Architecture 原始論文

---
skill: ddd
version: 1.0
tags: [ddd, domain-model, ubiquitous-language]
applicable-to: [Java, Domain Model]
last-updated: 2026-07-20
---

# DDD 領域驅動設計技能

## 適用情境
商業邏輯複雜、規則多變的核心領域（例如帳務、清算、風控），需要建立貼近業務語言的領域模型時使用。

## 核心原則
1. 使用 Ubiquitous Language：程式碼中的類別/方法名稱必須與業務人員使用的詞彙一致
2. Aggregate 是交易一致性的邊界，一次交易只修改一個 Aggregate
3. 商業規則封裝在 Entity/Value Object 內，禁止外洩到 Service 層做「貧血模型」判斷
4. 使用 Domain Event 表達「已發生的業務事實」，供其他 Bounded Context 訂閱

## 標準做法

### Aggregate Root 封裝不變條件
```java
public class Account {
    private AccountId id;
    private Money balance;

    public void withdraw(Money amount) {
        if (balance.isLessThan(amount)) {
            throw new InsufficientBalanceException(id, amount);
        }
        this.balance = balance.subtract(amount);
        registerEvent(new MoneyWithdrawnEvent(id, amount));
    }
}
```

### Value Object 表達領域概念
```java
public record Money(BigDecimal amount, Currency currency) {
    public Money {
        if (amount.scale() > 4) throw new IllegalArgumentException("金額精度過高");
    }
    public Money subtract(Money other) {
        requireSameCurrency(other);
        return new Money(amount.subtract(other.amount), currency);
    }
}
```

## 禁止事項
- 不得寫出「貧血模型」（Entity 只有 getter/setter，規則全部寫在 Service）
- 不得讓一次交易同時修改兩個以上的 Aggregate（應改用 Domain Event + 最終一致性）
- 不得讓 Value Object 有可變狀態（必須是 Immutable）

## 驗收標準
- [ ] 核心業務規則封裝於 Entity/Value Object，Service 只負責協調
- [ ] Aggregate 邊界清楚，跨 Aggregate 一致性透過 Domain Event 處理
- [ ] 程式碼命名與業務詞彙表（Ubiquitous Language）一致

## 參考資料
- Eric Evans《Domain-Driven Design: Tackling Complexity in the Heart of Software》

---
skill: event-driven
version: 1.0
tags: [event-driven, kafka, messaging]
applicable-to: [Kafka, Spring Boot]
last-updated: 2026-07-20
---

# 事件驅動架構技能

## 適用情境
服務間需要解耦、或有多個下游需要對同一業務事實做出反應（通知、報表、稽核）時採用。

## 核心原則
1. 事件是「已發生的事實」，用過去式命名（`OrderPlaced` 而非 `PlaceOrder`）
2. 事件內容應自足（Self-contained），下游不需回查來源服務即可處理
3. 消費端必須具備冪等性，因為訊息佇列多為 At-least-once 語意
4. 事件 Schema 需版本化管理，變更需向下相容

## 標準做法

### 發布事件
```java
@Service
@RequiredArgsConstructor
public class OrderService {
    private final KafkaTemplate<String, OrderPlacedEvent> kafkaTemplate;

    @Transactional
    public void placeOrder(Order order) {
        orderRepository.save(order);
        kafkaTemplate.send("order-events",
            new OrderPlacedEvent(order.getId(), order.getTotal(), Instant.now()));
    }
}
```

### 冪等消費
```java
@KafkaListener(topics = "order-events")
public void handle(OrderPlacedEvent event) {
    if (processedEventRepository.existsById(event.eventId())) {
        return; // 已處理過，避免重複扣款
    }
    billingService.charge(event.orderId(), event.total());
    processedEventRepository.save(new ProcessedEvent(event.eventId()));
}
```

## 禁止事項
- 不得假設訊息只會被消費一次（必須設計冪等）
- 不得讓事件 Schema 變更直接破壞既有消費者（需向下相容或雙版本並行）
- 不得用事件取代所有同步呼叫（強一致性需求場景仍應使用同步 API）

## 驗收標準
- [ ] 事件消費端具備冪等處理（去重機制）
- [ ] 事件 Schema 已版本化並有相容性測試
- [ ] 關鍵事件皆有對應的死信佇列（DLQ）與告警

## 參考資料
- Confluent — Event-Driven Architecture 設計指南

---
skill: cloud-native
version: 1.0
tags: [cloud-native, kubernetes, twelve-factor]
applicable-to: [Kubernetes, Spring Boot]
last-updated: 2026-07-20
---

# Cloud Native 技能

## 適用情境
將應用設計為適合容器化、可水平擴展、可在 Kubernetes 上穩定運行的服務時使用。

## 核心原則
1. 遵循 Twelve-Factor App：設定外部化（環境變數）、無狀態、Log 輸出到 stdout
2. 提供標準的 Liveness/Readiness Probe，讓編排系統知道服務健康狀態
3. 優雅關閉（Graceful Shutdown）：收到 SIGTERM 後完成進行中的請求再結束
4. 資源請求與限制（requests/limits）必須明確設定，避免資源搶佔

## 標準做法

### Health Probe 設定
```yaml
livenessProbe:
  httpGet:
    path: /actuator/health/liveness
    port: 8080
  initialDelaySeconds: 20
readinessProbe:
  httpGet:
    path: /actuator/health/readiness
    port: 8080
  periodSeconds: 5
```

### 優雅關閉設定
```yaml
# application.yml
server:
  shutdown: graceful
spring:
  lifecycle:
    timeout-per-shutdown-phase: 30s
```

## 禁止事項
- 不得把設定值寫死在程式碼或 Docker Image 中（應使用 ConfigMap/Secret）
- 不得省略 resources.requests/limits，導致單一 Pod 可能耗盡節點資源
- 不得將任何本地狀態（Session、暫存檔）存在容器內部而不外部化

## 驗收標準
- [ ] Liveness/Readiness Probe 皆已設定且能正確反映服務狀態
- [ ] 設定全部外部化，Image 可在任何環境重複部署
- [ ] 收到 SIGTERM 時可在時限內完成進行中請求後才結束

## 參考資料
- The Twelve-Factor App（https://12factor.net）

---
skill: unit-testing-junit5
version: 1.0
tags: [junit5, mockito, unit-testing]
applicable-to: [Java, JUnit 5, Mockito]
last-updated: 2026-07-20
---

# JUnit 5 單元測試技能

## 適用情境
為新開發或既有的 Java 類別補充單元測試。

## 核心原則
1. 測試命名描述行為，不描述實作（`should_throw_when_balance_insufficient`）
2. 一個測試只驗證一件事，Assertion 聚焦在單一行為
3. 使用 Mockito 隔離外部依賴，但不 Mock 被測物件本身
4. 涵蓋 Happy Path、邊界值、例外情境三類案例

## 標準做法

### 標準測試結構（Given-When-Then）
```java
@ExtendWith(MockitoExtension.class)
class AccountServiceTest {
    @Mock AccountRepository repository;
    @InjectMocks AccountService service;

    @Test
    @DisplayName("餘額不足時應拋出 InsufficientBalanceException")
    void should_throw_when_balance_insufficient() {
        // Given
        Account account = new Account("A1", Money.of(100));
        given(repository.findById("A1")).willReturn(Optional.of(account));

        // When / Then
        assertThatThrownBy(() -> service.withdraw("A1", Money.of(200)))
            .isInstanceOf(InsufficientBalanceException.class);
    }
}
```

### 參數化測試減少重複
```java
@ParameterizedTest
@CsvSource({"0, false", "-1, false", "100, true"})
void should_validate_amount(int amount, boolean expectedValid) {
    assertThat(AmountValidator.isValid(amount)).isEqualTo(expectedValid);
}
```

## 禁止事項
- 不得 Mock 靜態方法（代表設計問題，應先重構為可注入的依賴）
- 不得讓測試依賴執行順序（每個測試需獨立可重複執行）
- 不得只測 Happy Path 而忽略邊界與例外情境

## 驗收標準
- [ ] 行覆蓋率 ≥ 80%、重要業務邏輯覆蓋率 100%
- [ ] 每個測試方法名稱可讀出測試意圖，不需看內容
- [ ] 測試可獨立執行、可重複執行，無殘留狀態互相影響

## 參考資料
- JUnit 5 使用手冊（User Guide）
- 本手冊 14.3 節 Prompt-007（JUnit 5 測試產生 Prompt）

---
skill: integration-testing
version: 1.0
tags: [integration-testing, testcontainers, spring-boot-test]
applicable-to: [Spring Boot, Testcontainers]
last-updated: 2026-07-20
---

# 整合測試技能

## 適用情境
驗證多個元件（Controller + Service + 真實資料庫）協同運作是否正確時使用。

## 核心原則
1. 使用 Testcontainers 啟動真實資料庫，禁止用 H2 模擬 PostgreSQL/Oracle 行為
2. 每個測試前重置資料狀態，測試之間互不影響
3. 只在關鍵流程（如跨表交易、Migration）使用整合測試，其餘用單元測試涵蓋
4. 整合測試需能在 CI 中穩定執行，避免依賴外部網路服務

## 標準做法

### Testcontainers + SpringBootTest
```java
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
@Testcontainers
class AccountIntegrationTest {
    @Container
    static PostgreSQLContainer<?> postgres =
        new PostgreSQLContainer<>("postgres:16").withDatabaseName("test");

    @DynamicPropertySource
    static void props(DynamicPropertyRegistry registry) {
        registry.add("spring.datasource.url", postgres::getJdbcUrl);
    }

    @Test
    void should_persist_transfer_across_two_accounts() {
        // 呼叫真實 API，驗證真實資料庫狀態
    }
}
```

## 禁止事項
- 不得用記憶體資料庫（H2）取代真實資料庫種類做整合測試
- 不得讓測試相依於固定的外部服務（改用 WireMock/Testcontainers 模擬）
- 不得省略測試後的資料清理，造成測試間互相污染

## 驗收標準
- [ ] 使用與生產環境相同種類的資料庫（透過 Testcontainers）
- [ ] 測試可在 CI 環境穩定重複執行，無 Flaky 現象
- [ ] 涵蓋跨元件的關鍵交易路徑（非僅單一類別）

## 參考資料
- Testcontainers 官方文件（https://testcontainers.com）

---
skill: e2e-testing-playwright
version: 1.0
tags: [e2e-testing, playwright, typescript]
applicable-to: [TypeScript, Playwright]
last-updated: 2026-07-20
---

# E2E 測試技能（Playwright）

## 適用情境
驗證完整使用者流程（跨頁面、跨前後端）是否符合使用者故事時使用。

## 核心原則
1. 使用 Page Object Model 封裝頁面互動，測試案例本身只描述業務流程
2. 優先使用 `expect()` 的自動重試斷言，避免手動 `waitForTimeout`
3. 測試資料使用獨立 Fixture，不依賴共享的環境資料
4. 失敗時自動截圖與錄影，方便除錯

## 標準做法

### Page Object Model
```typescript
export class TransferPage {
  constructor(private page: Page) {}

  async fillAmount(amount: string) {
    await this.page.getByLabel('轉帳金額').fill(amount)
  }

  async submit() {
    await this.page.getByRole('button', { name: '確認轉帳' }).click()
  }
}

test('餘額不足時應顯示錯誤訊息', async ({ page }) => {
  const transferPage = new TransferPage(page)
  await page.goto('/transfer')
  await transferPage.fillAmount('999999')
  await transferPage.submit()
  await expect(page.getByText('餘額不足')).toBeVisible()
})
```

## 禁止事項
- 不得使用 `page.waitForTimeout()` 做固定延遲等待（改用條件式的 `expect`）
- 不得讓測試依賴生產或共享的測試環境資料（用 Fixture 建立獨立資料）
- 不得忽略行動裝置尺寸（viewport）與無障礙（a11y）情境

## 驗收標準
- [ ] 核心使用者故事（Happy Path + 主要錯誤路徑）皆有對應 E2E 測試
- [ ] 測試失敗時自動保留截圖／錄影供除錯
- [ ] 測試資料獨立於共享環境，可重複執行不互相干擾

## 參考資料
- Playwright 官方文件（https://playwright.dev）
- 本手冊 14.3 節 Prompt-008（E2E 測試 Playwright Prompt）

---
skill: performance-testing
version: 1.0
tags: [performance-testing, load-testing, k6]
applicable-to: [REST API, k6]
last-updated: 2026-07-20
---

# 效能測試技能

## 適用情境
上線前驗證 API 在預期流量下的延遲與吞吐量，或定位效能回歸問題時使用。

## 核心原則
1. 先定義明確的效能目標（P95 延遲、QPS），再設計測試腳本
2. 測試環境規格需與生產環境相近，結果才有參考價值
3. 區分負載測試（Load）、壓力測試（Stress）、尖峰測試（Spike）三種情境
4. 每次效能測試結果需與基準線（Baseline）比較，而非只看單次數字

## 標準做法

### k6 負載測試腳本
```javascript
import http from 'k6/http';
import { check } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 100 },
    { duration: '5m', target: 100 },
    { duration: '2m', target: 0 },
  ],
  thresholds: {
    http_req_duration: ['p(95)<300'], // P95 < 300ms
  },
};

export default function () {
  const res = http.get('https://staging.example.com/api/v1/accounts/1');
  check(res, { 'status is 200': (r) => r.status === 200 });
}
```

## 禁止事項
- 不得在沒有預先定義效能目標的情況下就開始測試（無法判斷通過與否）
- 不得直接對生產環境進行壓力測試
- 不得忽略資料庫連線池、快取等下游資源在高壓下的行為

## 驗收標準
- [ ] P95/P99 延遲與目標 QPS 皆有明確門檻並自動判定通過/失敗
- [ ] 測試結果已與前次基準線比較，無明顯回歸
- [ ] 測試涵蓋負載、壓力、尖峰三種情境中與本次變更相關的至少一種

## 參考資料
- Grafana k6 官方文件（https://k6.io/docs）

---
skill: security-testing
version: 1.0
tags: [security-testing, dast, penetration-testing]
applicable-to: [Web API]
last-updated: 2026-07-20
---

# 安全測試技能

## 適用情境
新功能上線前或既有 API 定期安全驗證，涵蓋認證、授權、輸入驗證等面向。

## 核心原則
1. 對照 OWASP Top 10（見 Skill-17）逐項驗證，而非隨機測試
2. 授權測試需涵蓋「水平權限提升」（存取他人資料）與「垂直權限提升」（低權限操作高權限功能）
3. 安全測試案例需納入自動化迴歸測試，避免修復後又回退
4. 高風險發現（如可繞過認證）需立即升級處理，不等排程

## 標準做法

### 水平權限提升測試
```java
@Test
@DisplayName("使用者 A 不應能查詢使用者 B 的帳戶")
void should_reject_access_to_other_users_account() {
    String tokenForUserA = login("userA");
    var response = given()
        .header("Authorization", "Bearer " + tokenForUserA)
        .when().get("/api/v1/accounts/{id}", accountIdOfUserB)
        .then().extract().response();

    assertThat(response.statusCode()).isEqualTo(403);
}
```

## 禁止事項
- 不得只測試「登入後可以做什麼」，忽略「登入後不該做什麼」
- 不得在生產環境執行滲透測試（DAST）除非已取得正式授權窗口
- 不得將發現的安全弱點只記錄不追蹤修復進度

## 驗收標準
- [ ] OWASP Top 10 對應項目皆有自動化測試案例覆蓋
- [ ] 水平/垂直權限提升測試已納入 CI 迴歸測試
- [ ] 高風險（CRITICAL/HIGH）發現皆有對應的修復 Ticket 與時限

## 參考資料
- OWASP Testing Guide
- Skill-17 OWASP Top 10 技能

---
skill: owasp-top10
version: 1.0
tags: [owasp, security, web-security]
applicable-to: [Web Application]
last-updated: 2026-07-20
---

# OWASP Top 10 技能

## 適用情境
程式碼審查或安全掃描時，逐項比對 OWASP Top 10（2021）常見弱點類別。

## 核心原則
1. 每次審查逐項檢查：注入、失效的存取控制、加密機制失效等十大類別
2. 修復需針對根因（如使用參數化查詢），而非表面遮蔽（如過濾特定關鍵字）
3. 高風險類別（注入、存取控制）優先於低風險類別（如組態設定問題）處理
4. 每個發現需標註對應的 OWASP 類別編號，便於追蹤與教育訓練

## 標準做法

### A03 注入攻擊防護（參數化查詢）
```java
// 錯誤：字串拼接易被 SQL Injection
String sql = "SELECT * FROM accounts WHERE id = '" + accountId + "'";

// 正確：使用參數化查詢
@Query("SELECT a FROM Account a WHERE a.id = :accountId")
Optional<Account> findById(@Param("accountId") String accountId);
```

### A01 失效的存取控制檢查清單
```text
- 是否每個端點都驗證了「這個使用者能不能操作這筆資料」，而非只驗證「有沒有登入」？
- 是否所有敏感端點都在伺服端二次驗證權限，而非僅依賴前端隱藏按鈕？
```

## 禁止事項
- 不得用黑名單過濾（Blacklist）取代參數化查詢等根本性防護
- 不得僅在前端做權限控制而伺服端不驗證
- 不得將加密金鑰、密碼等機密資訊寫死在原始碼中（見 Skill-20）

## 驗收標準
- [ ] SAST 掃描（見 Skill-18）無 Critical/High 等級的 OWASP 對應弱點
- [ ] 所有資料庫查詢皆使用參數化查詢或 ORM
- [ ] 所有敏感端點皆有伺服端授權驗證

## 參考資料
- OWASP Top 10 (2021)（https://owasp.org/Top10/）

---
skill: sast-analysis
version: 1.0
tags: [sast, static-analysis, sonarqube]
applicable-to: [Java, SonarQube]
last-updated: 2026-07-20
---

# 靜態分析技能（SAST）

## 適用情境
在 CI/CD 中對程式碼進行靜態安全與品質掃描，或分析掃描報告並提出修復方案時使用。

## 核心原則
1. Quality Gate 是品質門禁，未通過不得合併（見 4.1.1 節 GitHub Actions 範例）
2. 修復需驗證掃描工具的誤判（False Positive），但不得以「誤判」為由忽略真實弱點
3. 新增的 Critical/High 問題優先於既有的技術債務處理
4. 掃描規則集需版本化，避免不同環境掃描結果不一致

## 標準做法

### Quality Gate 檢查（CI 中自動阻擋）
```bash
status=$(curl -s "$SONAR_HOST_URL/api/qualitygates/project_status?projectKey=$PROJECT_KEY" \
  -H "Authorization: Bearer $SONAR_TOKEN" | jq -r '.projectStatus.status')
if [ "$status" != "OK" ]; then
  echo "Quality Gate 未通過: $status"
  exit 1
fi
```

### 誤判標記需附理由（而非直接忽略）
```java
@SuppressWarnings("java:S3776") // 複雜度來自狀態機的窮舉分支，已拆分為子函式，經團隊審查接受
public void handleStateTransition(State from, Event event) { ... }
```

## 禁止事項
- 不得在未經審查的情況下大量 `@SuppressWarnings` 掩蓋掃描結果
- 不得只掃描新增程式碼而放任既有的 Critical 問題累積
- 不得在 CI 中跳過 Quality Gate 檢查（除非有明確的例外審批流程）

## 驗收標準
- [ ] CI 中 Quality Gate 檢查為強制關卡，無法繞過
- [ ] 所有誤判標記皆附有審查理由與簽核紀錄
- [ ] Critical/High 等級問題的平均修復時間（MTTR）有追蹤指標

## 參考資料
- 本手冊 4.1.1 節 GitHub Actions Quality Gate 範例
- SonarQube 官方文件 — Quality Gates

---
skill: dependency-scanning
version: 1.0
tags: [dependency-scanning, sca, cve]
applicable-to: [Maven, npm]
last-updated: 2026-07-20
---

# 相依套件掃描技能

## 適用情境
定期或於 CI 中掃描第三方套件已知漏洞（CVE），並規劃升級或緩解策略。

## 核心原則
1. 依 CVSS 分數分級處理：CVSS ≥ 9 需在 SLA 內立即處理，中低風險排入例行維護
2. 升級套件版本前需確認相容性（Semantic Versioning、Breaking Change）
3. 無法立即升級時需記錄暫時緩解措施與追蹤升級排程，而非永久抑制
4. 掃描範圍需涵蓋直接依賴與傳遞依賴（Transitive Dependency）

## 標準做法

### CI 中設定失敗門檻
```bash
mvn dependency-check:check \
  -DfailBuildOnCVSS=7 \
  -DsuppressionFile=.github/security/suppressions.xml
```

### 暫時抑制需附到期日與理由
```xml
<suppress until="2026-09-30Z">
  <notes>等待上游函式庫發布修復版本，已建立追蹤 Ticket SEC-2201</notes>
  <cve>CVE-2026-12345</cve>
</suppress>
```

## 禁止事項
- 不得永久抑制（Suppress）已知漏洞而不設到期日與追蹤
- 不得只掃描直接依賴而忽略傳遞依賴中的漏洞
- 不得在 CVSS ≥ 9 的漏洞上僅以「暫時抑制」處理超過 SLA 時限

## 驗收標準
- [ ] CI 掃描涵蓋直接與傳遞依賴
- [ ] 所有抑制規則皆有到期日、理由與對應追蹤 Ticket
- [ ] Critical 漏洞的修復時效符合企業 SLA

## 參考資料
- OWASP Dependency-Check 官方文件

---
skill: secrets-management
version: 1.0
tags: [secrets-management, vault, credentials]
applicable-to: [Vault, Kubernetes]
last-updated: 2026-07-20
---

# 秘密管理技能

## 適用情境
處理 API Key、資料庫密碼、憑證等機密資訊的存放、注入與輪換時使用。

## 核心原則
1. 機密資訊一律不進入原始碼、不進入 AI 的上下文（對應 16.4 最佳實務 BP-39）
2. 使用集中式密鑰管理服務（Vault/KMS/Secret Manager），而非環境變數明文散落各處
3. 機密資訊需定期輪換，且輪換流程需自動化以降低人工疏漏風險
4. 稽核所有機密存取行為，異常存取需觸發告警

## 標準做法

### 從 Vault 注入機密（而非寫死於設定檔）
```yaml
spring:
  config:
    import: "vault://secret/data/my-banking-app"
  cloud:
    vault:
      uri: https://vault.company.com
      authentication: KUBERNETES
```

### .gitignore 與掃描防止機密外洩
```bash
# pre-commit hook：提交前掃描是否誤入機密
trufflehog filesystem . --only-verified --fail
```

## 禁止事項
- 不得把任何 API Key／密碼／Token 提交進版本控制（即使之後刪除也已留在歷史紀錄中）
- 不得讓 AI Agent 的 Prompt 或 Context 中包含明文機密（應以參考路徑代替實際值）
- 不得讓多個環境（Dev/Staging/Prod）共用同一組機密

## 驗收標準
- [ ] 所有機密透過集中式密鑰管理服務注入，程式碼與版本控制中無明文機密
- [ ] Pre-commit／CI 皆有機密掃描關卡（如 TruffleHog）
- [ ] 機密輪換與存取皆有稽核紀錄

## 參考資料
- HashiCorp Vault 官方文件（https://developer.hashicorp.com/vault）

---
skill: threat-modeling
version: 1.0
tags: [threat-modeling, stride, security-design]
applicable-to: [System Design]
last-updated: 2026-07-20
---

# 威脅建模技能

## 適用情境
新系統設計階段或既有系統重大變更前，系統性識別潛在威脅與對應防護措施。

## 核心原則
1. 使用 STRIDE 模型逐一檢視：Spoofing、Tampering、Repudiation、Information Disclosure、Denial of Service、Elevation of Privilege
2. 威脅建模應在設計階段進行，而非上線後才補做（成本差異可達數十倍）
3. 每個識別出的威脅都需要對應的緩解措施與負責人
4. 資料流圖（DFD）是威脅建模的基礎，需先畫出信任邊界（Trust Boundary）

## 標準做法

### STRIDE 分析表
```text
| 威脅類別 | 範例情境 | 緩解措施 |
|---|---|---|
| Spoofing | 偽造使用者身分呼叫轉帳 API | mTLS + JWT 簽章驗證 |
| Tampering | 竄改傳輸中的交易金額 | HTTPS + 訊息簽章 |
| Repudiation | 使用者事後否認曾發起轉帳 | 不可竄改的稽核日誌 + 電子簽章 |
| Information Disclosure | 錯誤訊息洩漏內部堆疊 | 統一錯誤格式，隱藏內部細節 |
| Denial of Service | 高頻請求耗盡連線池 | Rate Limiting + 熔斷器 |
| Elevation of Privilege | 一般使用者呼叫管理端點 | 伺服端角色驗證（RBAC） |
```

## 禁止事項
- 不得在系統上線後才第一次進行威脅建模
- 不得只列出威脅而無對應的緩解措施與驗收方式
- 不得忽略信任邊界內部（如內部服務間）的威脅，假設內網一定安全

## 驗收標準
- [ ] 資料流圖（DFD）已標示所有信任邊界
- [ ] STRIDE 六大類別皆有對應分析，無跳過類別
- [ ] 每個識別出的威脅皆有負責人與緩解措施驗收紀錄

## 參考資料
- Microsoft STRIDE 威脅建模方法論

---
skill: java6-to-java21
version: 1.0
tags: [java-migration, java21, legacy]
applicable-to: [Java]
last-updated: 2026-07-20
---

# Java 版本升級技能（Java 6 → Java 21）

## 適用情境
將執行於 Java 6/7/8 的遺留系統升級至 Java 21 LTS。

## 核心原則
1. 分階段升級（6→8→11→17→21），不跨過多個 LTS 版本一次到位
2. 每個階段升級後皆需完整跑過既有測試套件，確認行為未變
3. 優先替換已被移除或棄用的 API（如 `sun.misc.*`），而非等到編譯失敗才處理
4. 升級後才評估是否導入新語法（Record、Pattern Matching、Virtual Threads），不與版本升級同一批次混雜風險

## 標準做法

### 分階段升級路線圖
```text
Phase 1：Java 6 → Java 8   （Lambda、Stream 可選用，非強制重寫既有程式碼）
Phase 2：Java 8 → Java 11  （移除 Java EE 模組依賴，改用獨立套件）
Phase 3：Java 11 → Java 17 （處理 Strong Encapsulation 對反射的影響）
Phase 4：Java 17 → Java 21 （評估導入 Virtual Threads 於高並發服務）
```

### 常見阻塞點：反射存取內部 API
```java
// Java 8 可行，Java 17+ 因 Strong Encapsulation 需加開放模組
// 需在 module-info.java 或啟動參數加入：
// --add-opens java.base/java.lang=ALL-UNNAMED
```

## 禁止事項
- 不得一次直接從 Java 6 跳到 Java 21（風險無法分階段驗證）
- 不得在升級的同一個 PR 中混雜大量新語法重寫（無法區分「升級破壞」與「重構破壞」）
- 不得忽略第三方函式庫的相容性（部分舊函式庫可能不支援新版 JVM）

## 驗收標準
- [ ] 每個升級階段後既有測試套件 100% 通過
- [ ] 第三方相依套件皆已確認支援目標 Java 版本
- [ ] 升級與語法現代化（Record/Pattern Matching）為分開的 PR

## 參考資料
- Oracle Java SE 支援路線圖（JDK 8/11/17/21 LTS）

---
skill: struts-to-spring-boot
version: 1.0
tags: [struts, spring-boot, migration]
applicable-to: [Struts, Spring Boot]
last-updated: 2026-07-20
---

# Struts 遷移技能（Struts → Spring Boot）

## 適用情境
將 Struts 1/2 的 Action/Form 架構遷移至 Spring Boot Controller/Service 架構。

## 核心原則
1. 使用 Strangler Fig 模式漸進遷移：新舊系統並存，逐路由切換，而非一次性重寫
2. Struts Action 中混雜的商業邏輯，遷移時同步拆分到 Service 層（見 Skill-08 六角形架構）
3. ActionForm 對應為 Spring 的 DTO/Record，並補上 Bean Validation
4. 每遷移一個模組即建立對應測試，確保行為與舊系統一致（Characterization Test）

## 標準做法

### Strangler Fig：反向代理依路由分流
```nginx
location /api/v2/ {
    proxy_pass http://spring-boot-service;
}
location / {
    proxy_pass http://legacy-struts-service;
}
```

### Struts Action → Spring Controller 對應
```java
// Struts Action（舊）：doGet 中混雜驗證、查詢、格式轉換
// 遷移後：Controller 只做協定轉換，邏輯移至 Service
@GetMapping("/api/v2/accounts/{id}")
public AccountDto getAccount(@PathVariable String id) {
    return accountService.findById(id); // 對應舊 Action 中的查詢邏輯
}
```

## 禁止事項
- 不得一次性切斷所有舊路由（應以 Strangler Fig 漸進切換，保留回退能力）
- 不得直接複製 Struts Action 中的商業邏輯到 Controller（違反六角形架構原則）
- 不得在無 Characterization Test 保護的情況下遷移含複雜業務規則的模組

## 驗收標準
- [ ] 每個遷移模組皆有遷移前後行為一致的 Characterization Test
- [ ] 新舊系統可並存運行，可依路由灰度切換與回退
- [ ] 商業邏輯已從 Action 層搬移至獨立 Service 層

## 參考資料
- Martin Fowler — Strangler Fig Application

---
skill: jsp-to-vue3
version: 1.0
tags: [jsp, vue3, frontend-migration]
applicable-to: [JSP, Vue 3]
last-updated: 2026-07-20
---

# JSP 遷移技能（JSP → Vue3）

## 適用情境
將伺服端渲染的 JSP 頁面遷移至前後端分離的 Vue3 SPA 架構。

## 核心原則
1. 先盤點 JSP 頁面中混雜的邏輯：純顯示、表單驗證、商業規則，分別對應遷移策略
2. JSP 中內嵌的 Java Scriptlet 商業邏輯需先抽成後端 API，前端只負責顯示與互動
3. 依頁面重要度與變動頻率排序遷移優先級，而非依技術難度
4. 遷移期間新舊頁面共存，透過共用版型（Layout）維持一致的使用者體驗

## 標準做法

### JSP 內嵌邏輯 → 後端 API + 前端元件
```jsp
<%-- Before: JSP Scriptlet 內嵌商業邏輯 --%>
<% if (account.getBalance().compareTo(new BigDecimal(1000)) > 0) { %>
    <span>VIP 會員</span>
<% } %>
```
```vue
<!-- After: 邏輯移至後端 API，前端只做顯示 -->
<script setup lang="ts">
const { data: account } = await useAccountApi().getAccount(accountId)
</script>
<template>
  <span v-if="account.isVip">VIP 會員</span>
</template>
```

## 禁止事項
- 不得把 JSP 中的商業邏輯原封不動搬到前端 JavaScript（前端不應持有授權/計算等商業規則）
- 不得在遷移過程中讓同一功能同時存在兩套互相衝突的實作而未標明過渡狀態
- 不得忽略 SEO 或首屏效能需求就直接改為純 CSR（視情況評估 SSR/預渲染）

## 驗收標準
- [ ] JSP 中的商業邏輯已抽離至後端 API，前端不含授權或計算類商業規則
- [ ] 已遷移頁面與待遷移頁面共用一致的版型與導覽體驗
- [ ] 遷移後頁面之核心功能已通過 E2E 測試（見 Skill-14）

## 參考資料
- 本手冊第八章 Web Application 開發實戰

---
skill: spring-boot-2-to-3
version: 1.0
tags: [spring-boot, migration, jakarta-ee]
applicable-to: [Spring Boot]
last-updated: 2026-07-20
---

# Spring Boot 升級技能（2.x → 3.x）

## 適用情境
將 Spring Boot 2.x（`javax.*`）專案升級至 Spring Boot 3.x（`jakarta.*` + Java 17+）。

## 核心原則
1. 先確認執行環境已達 Java 17+（Spring Boot 3 最低需求），對應 Skill-22 的升級路線圖
2. `javax.*` → `jakarta.*` 的命名空間遷移可先用自動化工具批次處理，再人工複查
3. 第三方函式庫需逐一確認是否已釋出對應 Jakarta EE 9+ 相容版本
4. 升級後需重新檢視 Actuator、Security 等模組的組態變更（版本間常有預設值調整）

## 標準做法

### 命名空間批次遷移
```bash
# 使用 OpenRewrite 自動化遷移 javax → jakarta
mvn org.openrewrite.maven:rewrite-maven-plugin:run \
  -Drewrite.activeRecipes=org.openrewrite.java.migrate.jakarta.JavaxMigrationToJakarta
```

### 常見組態差異（需人工複查）
```yaml
# Spring Boot 2.x 預設 management.endpoints.web.exposure.include=info,health
# Spring Boot 3.x 起建議明確列出，避免預設值變動造成非預期端點曝露
management:
  endpoints:
    web:
      exposure:
        include: health,info,metrics
```

## 禁止事項
- 不得跳過 Java 版本前置需求直接嘗試升級 Spring Boot（會導致編譯失敗）
- 不得只做字串取代（`javax` → `jakarta`）而不確認語意是否正確（部分套件命名空間規則不同）
- 不得忽略升級後 Actuator/Security 預設組態的變化就直接上線

## 驗收標準
- [ ] 專案已運行於 Java 17+（Spring Boot 3 最低需求）
- [ ] 所有第三方相依套件皆已確認 Jakarta EE 相容版本
- [ ] 升級後 Actuator/Security 相關組態已人工複查並明確設定

## 參考資料
- Spring Boot 3.0 Migration Guide

---
skill: monolith-to-microservices
version: 1.0
tags: [monolith, microservices, strangler-fig]
applicable-to: [Java, Microservices]
last-updated: 2026-07-20
---

# 單體到微服務技能

## 適用情境
評估單體應用是否該拆分為微服務，並規劃漸進式拆分路線圖時使用（與 Skill-07 微服務架構搭配使用）。

## 核心原則
1. 先確認拆分動機（團隊擴張、獨立部署需求、局部擴展需求），而非為拆而拆
2. 使用 Strangler Fig 模式：先拆最獨立、變動最頻繁的模組作為第一個微服務
3. 拆分前先在單體內部劃清 Bounded Context 邊界（模組化單體），驗證邊界正確後再實體拆分
4. 每個拆分階段都需定義明確的回退（Rollback）計畫

## 標準做法

### 拆分優先順序評估矩陣
```text
| 模組 | 變動頻率 | 與其他模組耦合度 | 獨立擴展需求 | 拆分優先級 |
|---|---|---|---|---|
| 通知服務 | 高 | 低 | 低 | 高（先拆） |
| 帳務核心 | 低 | 高 | 中 | 低（最後拆，需最謹慎） |
```

### 拆分前先模組化單體（驗證邊界）
```java
// 先用套件（package）邊界模擬未來的服務邊界，並禁止跨邊界直接呼叫內部類別
// com.bank.notification（對外只暴露 NotificationFacade）
// com.bank.account（對外只暴露 AccountFacade）
```

## 禁止事項
- 不得在沒有驗證 Bounded Context 邊界前就直接進行實體拆分（邊界錯誤會造成頻繁跨服務呼叫）
- 不得一次拆分多個高耦合模組（應從低耦合、高變動頻率的模組開始）
- 不得拆分後才發現沒有回退計畫，導致問題只能硬著頭皮往前修

## 驗收標準
- [ ] 已完成拆分優先順序評估矩陣，優先拆分模組有明確理由
- [ ] 拆分前已在模組化單體內驗證邊界（跨邊界呼叫僅透過 Facade）
- [ ] 每個拆分階段皆有明確的回退計畫與判斷指標

## 參考資料
- 本手冊第九章 Legacy System 逆向工程
- Skill-07 微服務架構技能

現在：AI 輔助診斷 + 人工修復
近期：AI 自動修復 + 人工驗證
未來：AI 自動修復 + 自動驗證 + 自動部署

my-enterprise-project/
├── .claude/                          # Claude Code 設定
│   ├── settings.json                 # Hooks & 權限設定
│   ├── settings.local.json           # 個人設定（不提交）
│   └── skills/                       # 自定義 Skills
│       ├── banking-domain.md
│       └── company-standards.md
├── .github/
│   ├── copilot-instructions.md       # Copilot 工作指示
│   ├── workflows/                    # GitHub Actions
│   │   ├── loop-engineering.yml      # 主要 Loop Pipeline
│   │   ├── security-scan.yml         # 安全掃描 Loop
│   │   └── ai-auto-fix.yml           # AI 自動修復 Loop
│   ├── prompts/                      # 標準 Prompt Library
│   │   ├── architecture/
│   │   ├── coding/
│   │   ├── security/
│   │   └── testing/
│   └── 教學/
│       └── AI開發/                   # 教學手冊目錄
├── docs/
│   ├── architecture/                 # 架構決策記錄
│   ├── threat-models/                # 威脅模型
│   └── api/                          # API 文件
├── skills/                           # Skill Library（版本控制）
│   ├── coding/
│   ├── architecture/
│   ├── testing/
│   ├── security/
│   └── migration/
├── src/
│   ├── main/java/
│   └── test/java/
├── CLAUDE.md                         # 專案知識（Claude Code）
└── pom.xml

---
skill: [skill-id]
version: [1.0]
tags: [tag1, tag2]
applicable-to: [Java, Spring Boot, etc.]
last-updated: [日期]
---

# [技能名稱]

## 適用情境
[說明何時使用此技能]

## 核心原則
1. [原則 1]
2. [原則 2]

## 標準做法

### [子場景 1]
[說明 + 程式碼範例]

### [子場景 2]
[說明 + 程式碼範例]

## 禁止事項
- [禁止 1]
- [禁止 2]

## 驗收標準
- [ ] [標準 1]
- [ ] [標準 2]

## 參考資料
- [連結或說明]

---
name: [kebab-case-slug]
description: [一行摘要，供相關性判斷使用]
metadata:
  type: [user | feedback | project | reference]
---

[記憶內容]

**Why:** [原因或背景]

**How to apply:** [如何在未來使用]

{
  "eval_id": "EVAL-TRANSFER-001",
  "timestamp": "2026-06-17T10:00:00Z",
  "version": "v2.3.1",
  "results": {
    "functional": { "score": 96, "pass": true, "details": "..." },
    "security": { "score": 100, "pass": true, "details": "..." },
    "performance": { "score": 88, "pass": true, "details": "P95=180ms" },
    "architecture": { "score": 82, "pass": true, "details": "..." },
    "coding_standard": { "score": 91, "pass": true, "details": "..." },
    "regression": { "score": 100, "pass": true, "details": "全通過" }
  },
  "overall_score": 93.4,
  "overall_pass": true,
  "action_taken": "允許合併至 main"
}

# Step 1: 安裝 Claude Code
npm install -g @anthropic-ai/claude-code

# Step 2: 驗證安裝
claude --version

# Step 3: 登入（使用瀏覽器 OAuth）
claude login

# Step 4: 驗證登入
claude whoami

# Step 5: 在專案中初始化
cd /path/to/your/project
claude init

# Step 6: 檢視生成的 CLAUDE.md
cat CLAUDE.md

# Step 7: 設定 MCP 伺服器（GitHub 整合）
claude mcp add github -- \
  npx -y @modelcontextprotocol/server-github
# 輸入 GitHub Token

# Step 8: 驗證 MCP 連線
claude mcp list
claude mcp get github

# Step 9: 設定 Hooks（自動化品質檢查）
cat > .claude/settings.json << 'EOF'
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "mvn checkstyle:check -q 2>&1 || true"
          }
        ]
      }
    ]
  }
}
EOF

# Step 10: 測試 Loop Engineering 基本功能
claude "列出專案中所有 Java 類別，並識別最複雜的三個"

# Step 11: 啟動互動式 REPL
claude

# Step 12: 常用快捷鍵
# Escape    中斷目前操作
# Ctrl+C    取消
# /help     顯示說明
# /memory   管理記憶
# /skills   管理技能

# Step 13: 設定模型（依需求）
export ANTHROPIC_MODEL=claude-opus-4-8    # 複雜任務
export ANTHROPIC_MODEL=claude-sonnet-4-6  # 一般任務（預設）
export ANTHROPIC_MODEL=claude-haiku-4-5-20251001  # 簡單任務

# Step 14: 進階 — 設定全局 CLAUDE.md
cat > ~/.claude/CLAUDE.md << 'EOF'
# 全局 Claude Code 設定

## 偏好設定
- 使用繁體中文回覆
- 程式碼優先使用 Java 21 語法
- 永遠執行測試驗證修改
- 安全問題立即標示

## 禁止行為
- 不得跳過測試
- 不得使用 deprecated API
- 不得 hardcode 秘密
EOF

# Step 1: 安裝 GitHub Copilot CLI
npm install -g @githubnext/github-copilot-cli

# Step 2: 驗證安裝
github-copilot-cli --version

# Step 3: 認證
github-copilot-cli auth login

# Step 4: 啟用 Copilot CLI 別名
# 在 ~/.bashrc 或 ~/.zshrc 加入
eval "$(github-copilot-cli alias -- "$0")"

# Step 5: 使用 ghcs（shell 指令建議）
ghcs "列出最近修改的 Java 檔案"
ghcs "找出所有有安全問題的 SQL 查詢"
ghcs "建立 Dockerfile for Java 21 Spring Boot"

# Step 6: 使用 ghce（解釋指令）
ghce "kubectl rollout restart deployment/banking -n prod"

# Step 7: 設定 VSCode 中的 Copilot
# 安裝 GitHub Copilot Extension
code --install-extension GitHub.copilot
code --install-extension GitHub.copilot-chat

# Step 8: 設定 copilot-instructions.md
mkdir -p .github
cat > .github/copilot-instructions.md << 'EOF'
# GitHub Copilot 工作指示

## 專案背景
企業網路銀行系統，Java 21 + Spring Boot 3.5

## 程式碼規範
- 使用 Java 21 Records 和 Pattern Matching
- 所有 API 必須有 @Operation 文件
- 測試覆蓋率要求 ≥ 80%

## 安全規範
- 禁止 SQL 字串拼接
- 所有密碼使用 BCrypt 雜湊
- 敏感欄位使用 @JsonIgnore
EOF

# Step 9: 驗證 Copilot Agent 模式
# 在 VSCode 中：Ctrl+Shift+P → "GitHub Copilot: Open Chat"
# 輸入：@workspace 請說明這個專案的架構

# Step 10: 設定 Copilot MCP（VSCode）
mkdir -p .vscode
cat > .vscode/mcp.json << 'EOF'
{
  "servers": {
    "github": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${env:GITHUB_TOKEN}"
      }
    }
  }
}
EOF

請設計以下業務場景的 Event-Driven 架構：

業務場景：[例如：轉帳完成後觸發通知、帳單產生、風控分析]

請提供：
1. 事件清單（Event Catalog）
   - 事件名稱（過去式動詞：TransferCompleted）
   - 事件負載（Payload Schema）
   - 觸發者與訂閱者
2. Kafka Topic 設計
   - Topic 命名規範
   - Partition 策略
   - Retention 設定
3. Consumer Group 設計
4. 錯誤處理（Dead Letter Queue）
5. 事件溯源（Event Sourcing）考量
6. 冪等性保證方案

程式碼輸出：
- Spring Boot Kafka Producer/Consumer 範例
- Event Schema（Java Record）
- 重試策略設定

// 轉帳完成事件
public record TransferCompletedEvent(
    String transferId,
    String sourceAccount,
    String targetAccount,
    BigDecimal amount,
    Instant completedAt,
    String correlationId
) implements DomainEvent {}

// Kafka Producer
@Component
public class TransferEventPublisher {
    private final KafkaTemplate<String, TransferCompletedEvent> kafkaTemplate;

    public void publish(TransferCompletedEvent event) {
        kafkaTemplate.send("banking.transfers.completed",
            event.transferId(), event);
    }
}

請為以下業務模組設計 CQRS（Command Query Responsibility Segregation）架構：

模組：[例如：帳戶查詢 vs 帳戶操作]
讀取頻率：[每秒查詢次數]
寫入頻率：[每秒寫入次數]
一致性要求：[強一致性/最終一致性]

設計要求：
1. Command 側設計
   - Command 物件定義（Java Record）
   - CommandHandler 實作
   - Domain Event 發布
2. Query 側設計
   - Read Model（投影）設計
   - Query Repository（分離讀取資料庫）
   - 快取策略（Redis）
3. 同步機制
   - Event Store 設計
   - Read Model 更新策略
4. API 設計（Command API vs Query API 分離端點）

請提供完整的 Spring Boot 實作程式碼

請設計以下跨服務場景的分散式交易方案：

場景：[例如：轉帳涉及 Account Service + Ledger Service + Notification Service]
一致性要求：[強一致性/最終一致性]
允許的最大不一致時間：[秒/分鐘]

請比較並選擇適合的方案：
1. 2PC（Two-Phase Commit）— 說明適用場景與缺點
2. Saga Pattern（Choreography）— 事件驅動 Saga
3. Saga Pattern（Orchestration）— 協調者 Saga
4. Outbox Pattern — 保證事件發布可靠性

選定方案後，提供：
- 完整的狀態機設計
- 補償交易（Compensating Transaction）設計
- 失敗場景的處理方式
- Spring Boot + Kafka 實作範例

請為以下 Spring Boot 應用程式設計 Redis 快取策略：

應用場景：[描述業務場景]
資料特性：[更新頻率、資料大小、一致性要求]

設計要求：
1. 快取策略選擇（Cache-aside/Write-through/Write-behind）
2. 快取 Key 命名規範
3. TTL（Time-To-Live）策略
4. 快取穿透、擊穿、雪崩防護
5. 快取一致性保證（雙刪策略/Canal Binlog）
6. 本地快取 + Redis 二級快取設計

程式碼輸出：
- Spring Cache @Cacheable/@CacheEvict 設定
- Redis Key 設計文件
- 快取預熱策略

請為 Spring Boot 3.5 應用程式設計完整的可觀測性方案：

業務場景：[系統描述]
SLA：[可用性目標，例如 99.9%]
告警時間要求：[從異常到告警的最大時間]

三大支柱設計：
1. Metrics（指標）
   - 業務指標（TPS/成功率/金額）
   - 技術指標（JVM/DB/HTTP）
   - Prometheus + Grafana 儀表板
   - AlertManager 告警規則

2. Logs（日誌）
   - 結構化日誌（JSON）
   - Correlation ID 串聯
   - 敏感資料遮罩（帳號/密碼）
   - ELK Stack 設定

3. Traces（追蹤）
   - OpenTelemetry 整合
   - Spring Boot Actuator 設定
   - 分散式追蹤（Jaeger/Zipkin）

程式碼輸出：
- Spring Boot Actuator 設定
- Micrometer 自定義指標
- Log4j2 JSON 格式設定
- Kubernetes Prometheus ServiceMonitor

請為以下 Spring Boot 應用程式設計完整的 Kubernetes 部署設定：

應用程式特性：
- 無狀態服務
- 啟動時間：[秒數]
- 記憶體需求：[MB]
- CPU 需求：[cores]
- 外部依賴：[PostgreSQL/Redis/Kafka]

請提供：
1. Deployment（含資源限制、Health Check、Anti-affinity）
2. Service（ClusterIP + LoadBalancer）
3. ConfigMap（應用程式設定）
4. Secret（敏感設定）
5. HorizontalPodAutoscaler（CPU/Memory 觸發）
6. PodDisruptionBudget（零停機更新）
7. NetworkPolicy（網路隔離）
8. OpenShift Route（含 TLS 終止）

特別要求：
- 設定 Liveness/Readiness/Startup Probe
- 使用 Rolling Update 策略
- 設定資源 Request/Limit（避免 OOMKilled）

請設計一個完整的 GitHub Actions CI/CD Pipeline，實現 Loop Engineering 理念：

專案類型：Java 21 + Spring Boot 3.5 + Vue 3
部署目標：OpenShift（Staging + Production）
品質要求：
  - 測試覆蓋率 ≥ 80%
  - SonarQube Quality Gate 通過
  - 無 CRITICAL/HIGH 安全漏洞
  - 效能基準不得回退 > 10%

Pipeline 設計要求：
1. Build Loop（編譯 + 打包）
2. Test Loop（Unit + Integration + E2E）
3. Quality Loop（SonarQube + Checkstyle）
4. Security Loop（SAST + Dependency Check + Secret Scan）
5. Container Loop（Build + Scan + Push）
6. Deploy Loop（Staging → Smoke Test → Production → Canary）
7. AI Auto-Fix Loop（失敗時自動觸發 Claude Code 修復）

請提供完整的 .github/workflows/ YAML 設定

請為以下 Spring Boot 3.5 應用程式建立最佳化的容器化方案：

應用特性：
- 啟動時間要求：< 3 秒（Kubernetes 探針需求）
- Image 大小目標：< 200MB
- 需要支援 GraalVM Native Image（可選）

請提供：
1. 多階段建置 Dockerfile（Multi-stage Build）
2. Buildpacks 替代方案（比較優缺點）
3. JVM 調優參數（容器感知 GC 設定）
4. 啟動時間優化技巧
   - Spring Boot Lazy Initialization
   - JVM CDS（Class Data Sharing）
   - Spring AOT 預編譯
5. 安全加固
   - 非 root 用戶執行
   - Read-only 檔案系統
   - 移除不必要的工具
6. .dockerignore 設定

特別提供：GraalVM Native Image 設定（若需要）

請設計以下資料庫變更的安全 Migration 策略：

變更說明：[例如：為 Customer 表新增欄位、重命名欄位]
資料庫：PostgreSQL 16
資料量：[表格大小，例如：1億筆]
服務要求：零停機時間

請考慮並設計：
1. Flyway Migration Script 設計
   - 命名規範（V{版本}__{描述}.sql）
   - 向後相容性（舊程式碼能執行新 Schema）
2. 大型表格的安全變更方式
   - 使用 CONCURRENTLY 建立索引
   - 分批更新大量資料
   - 避免長時間表鎖
3. Schema 版本與 Application 版本的協調（Expand-Contract Pattern）
4. Rollback 策略
5. Flyway repair 使用場景

提供：
- Flyway Migration SQL 範例
- Spring Boot Flyway 設定（application.properties）
- 適合 Canary 部署的 Schema 演進策略

請為以下 REST API 設計完整的效能測試方案：

API：[描述 API 功能]
SLA：
  - P50 回應時間：< 100ms
  - P95 回應時間：< 500ms
  - P99 回應時間：< 1000ms
  - 目標 TPS：[例如：1000 TPS]
  - 錯誤率：< 0.1%

測試設計要求：
1. Gatling 壓力測試腳本設計
   - 基準測試（正常負載）
   - 壓力測試（2x 正常負載）
   - 尖峰測試（突發流量）
   - 耐久測試（持續 1 小時）
2. 測試資料準備（避免影響生產資料）
3. 效能基準建立（與 CI/CD 整合）
4. 效能瓶頸分析指南
   - JVM GC 分析
   - 資料庫 Slow Query
   - 執行緒阻塞分析

程式碼輸出：完整的 Gatling Scala/Java 測試腳本

請設計並實作企業級 Spring Security 6 OAuth2 / JWT 認證方案：

要求：
- JWT Token（Access Token 15分鐘 + Refresh Token 7天）
- 多角色 RBAC（ADMIN/MANAGER/USER/VIEWER）
- Row-level Security（使用者只能存取自己的資料）
- Rate Limiting（防暴力破解）
- 2FA（TOTP 支援）
- 稽核日誌（所有認證事件）

請提供：
1. SecurityConfig 完整設定
2. JWT Provider（簽發/驗證/刷新）
3. 自定義 UserDetailsService
4. 方法層級安全（@PreAuthorize）
5. Row-level Security Filter
6. Rate Limiting Filter（Redis 計數）
7. 2FA 整合（Google Authenticator 相容）
8. 安全稽核 Log Aspect

請示範 Spring Boot 3.5 完整的測試策略：

測試目標：[描述被測試的功能]

測試層次設計：
1. 單元測試
   - Service 層（Mock Repository）
   - Domain 邏輯（純 Java，無框架）
   - 工具類別測試
2. 整合測試
   - Repository 層（Testcontainers PostgreSQL）
   - Controller 層（@WebMvcTest + MockMvc）
   - Kafka 整合（Embedded Kafka）
3. 合約測試（Spring Cloud Contract）
4. 效能測試基準（JMH）

技術要求：
- 使用 @TestConstructor(autowireMode = ALL)
- 使用 AssertJ 流暢斷言
- Testcontainers 共享容器（減少啟動時間）
- 使用 @MockBean 的注意事項與替代方案
- 測試資料工廠（Test Data Builder）

請提供完整的測試程式碼範例

請展示 Java 21 Virtual Threads（Project Loom）在 Spring Boot 應用中的最佳實踐：

應用場景：
1. HTTP 請求處理（Tomcat 改用 Virtual Threads）
2. 資料庫查詢（HikariCP + Virtual Threads）
3. 外部 API 呼叫（多個平行呼叫）
4. Kafka 消費者

請提供：
1. Spring Boot application.properties 設定（啟用 Virtual Threads）
2. 適合 Virtual Threads 的程式設計模式
3. 不適合 Virtual Threads 的場景（Pinning 問題）
4. 效能測試對比（Thread Pool vs Virtual Threads）
5. 監控 Virtual Threads 的 JFR 設定

特別注意 Synchronized 的 Pinning 問題及解決方案

請展示 Spring Data JPA 在高效能場景下的進階技巧：

場景：[描述業務場景，例如：帳戶查詢、轉帳記錄分頁]
效能目標：[回應時間要求]

請涵蓋：
1. @EntityGraph 避免 N+1（多種策略比較）
2. Projections（Interface/Class/Dynamic Projection）
3. Specification API（複雜動態查詢）
4. 自定義 Repository（BaseRepository）
5. Pagination 最佳實踐（Slice vs Page vs Keyset）
6. Hibernate L2 Cache（EHCache/Redis）
7. @BatchSize 批次載入
8. Native Query + DTO 投影

效能陷阱說明：
- 錯誤的 FetchType 設定
- 過度使用 EAGER 載入
- 長事務（Long Transaction）問題
- JPA Open Session in View（反模式）

請示範 Spring WebFlux + Project Reactor 在以下場景的應用：

場景：[例如：即時市場報價推送、多個外部 API 聚合查詢]

請涵蓋：
1. Mono/Flux 基礎操作
2. 響應式資料庫（R2DBC）
3. Backpressure 處理
4. 錯誤處理（onErrorResume/retry/timeout）
5. 測試（StepVerifier）
6. 與傳統 MVC 的混合使用場景
7. Virtual Threads vs WebFlux — 選擇指南

程式碼包含：完整的 Controller/Service/Repository 響應式鏈
注意事項：說明 Blocking 程式碼在響應式中的危險性

請展示 Vue 3 Composition API + TypeScript 5.5 的企業級最佳實踐：

功能需求：[描述 UI 功能，例如：帳戶交易列表 with 無限滾動]

請涵蓋：
1. Composable 設計（useAccount/useTransfer）
2. Pinia Store 設計（型別安全）
3. 元件通訊（Props/Emits/Provide-Inject）
4. 非同步資料取得（useAsyncData/Suspense）
5. 表單驗證（Vuelidate/VeeValidate）
6. 錯誤邊界處理（Error Boundary）
7. 效能優化（v-memo/defineAsyncComponent）
8. TypeScript 泛型組件

程式碼要求：
- 使用 <script setup> 語法
- 使用 TypeScript 嚴格模式
- 單元測試（Vitest + Vue Test Utils）

請為 Vue 3 企業應用程式設計前端安全方案：

安全威脅：XSS/CSRF/Clickjacking/Sensitive Data Exposure

請提供：
1. XSS 防護
   - Vue 自動 HTML 編碼機制
   - v-html 的危險使用場景
   - Content Security Policy（CSP）設定
2. CSRF 防護
   - SameSite Cookie 設定
   - CSRF Token 整合 Spring Security
3. JWT 安全儲存
   - LocalStorage vs Cookie 比較
   - 推薦方案：HttpOnly Cookie
4. 敏感資料遮罩（帳號/卡號顯示）
5. 路由守衛（Navigation Guard）
6. 環境變數安全管理（VITE_開頭的限制）

程式碼：完整的 axios 攔截器（token 自動附加 + 401 刷新）

請為企業應用程式建立 TailwindCSS 4 設計系統：

品牌要求：[提供主要色彩、字體偏好]
元件需求：
  - Button（Primary/Secondary/Danger/Ghost）
  - Input/Select/Textarea（含驗證狀態）
  - Table（分頁/排序/篩選）
  - Modal/Dialog
  - Alert/Toast 通知
  - Loading Skeleton
  - Badge/Tag

請提供：
1. tailwind.config.js 企業主題設定
2. 可複用元件（Vue 3 SFC）
3. 深色模式支援
4. 無障礙設計（ARIA + 鍵盤導航）
5. 響應式設計斷點策略

注意：元件需要 Storybook 文件

請設計一個自訂 MCP Server，整合以下企業工具：

整合目標：[例如：公司內部 Wiki 系統 / 核心銀行系統 API]
操作需求：[讀取文件 / 查詢帳戶 / 提交工單]

MCP Server 設計：
1. Tool 定義（可被 AI Agent 呼叫的操作）
2. Resource 定義（可被讀取的資源）
3. Prompt 定義（預設 Prompt 範本）
4. 認證機制（API Key / OAuth）
5. 錯誤處理與超時設定

技術棧：TypeScript / Node.js
請提供：
- 完整的 MCP Server 程式碼
- package.json 相依設定
- .claude/mcp-config.json 整合設定
- 測試方式（使用 MCP Inspector）

請設計企業級 AI Gateway（統一 LLM 存取層）：

需求：
- 支援多個 LLM 提供商（Anthropic/Azure OpenAI/企業私有模型）
- 統一的認證與計費
- Token 使用量追蹤
- Prompt 稽核日誌
- Rate Limiting（防止濫用）
- Fallback 機制（主要模型失敗時切換）
- 資料脫敏（敏感欄位不送至外部 LLM）

技術棧：Java 21 + Spring Boot 3.5

請提供：
1. AI Gateway 架構圖（Mermaid）
2. API 設計（統一的 /api/v1/ai/chat 端點）
3. 多模型路由策略
4. 敏感資料偵測與遮罩
5. 稽核日誌設計
6. Spring Boot 實作程式碼

請設計企業金融系統的資料脫敏（Data Masking）策略：

敏感欄位：
- 身分證字號
- 信用卡號
- 銀行帳號
- 電話號碼
- 電子郵件

應用場景：
1. API 回應中的動態脫敏（顯示 ****）
2. 日誌中的自動脫敏
3. 測試環境的靜態脫敏
4. 備份資料的脫敏

請提供：
- Spring Boot AOP 實作（@MaskSensitive 注解）
- Jackson 序列化脫敏（@JsonMask）
- Log4j2 / Logback 脫敏設定（PatternLayout）
- 測試資料產生器（Faker + 符合台灣格式）

請為以下業務場景設計 GraphQL API：

業務場景：[例如：行動銀行 App 需要彈性查詢帳戶 + 交易資料]
現有 REST API：[描述現有 API]

GraphQL 設計要求：
1. Schema 設計（types/queries/mutations/subscriptions）
2. DataLoader（解決 N+1 問題）
3. 授權（@PreAuthorize 整合）
4. 分頁設計（Cursor-based Pagination）
5. 錯誤處理（統一 Error Format）
6. 訂閱（Subscription for 即時通知）

技術棧：Spring Boot + Netflix DGS（Domain Graph Service）
請提供完整的 Spring Boot DGS 實作程式碼

請設計以下高資料量場景的資料庫分片（Sharding）策略：

業務場景：交易記錄表，預計每年 10 億筆資料
查詢模式：
  - 按帳號查詢最近 N 筆交易
  - 按日期範圍查詢報表

分片方案比較：
1. 按帳號分片（Hash Sharding）— 優缺點
2. 按時間分片（Range Sharding）— 優缺點
3. 複合分片策略 — 建議方案

PostgreSQL 實作：
- Declarative Partitioning（按月分表）
- pg_partman 自動管理
- 跨分片查詢優化
- 分片遷移策略

Spring Boot 整合：JPA + 分片路由設定

請展示 Redis 7 在以下企業場景的進階應用：

場景清單：
1. Session 管理（Spring Session + Redis）
2. 分散式鎖（Redisson）
3. Rate Limiting（Sliding Window）
4. 排行榜（Sorted Set）
5. 地理位置查詢（GEO）
6. Pub/Sub 即時通知
7. Bloom Filter（防快取穿透）

針對每個場景提供：
- 使用時機說明
- Redis 命令與 Java Spring Boot 程式碼
- 注意事項（TTL 設計、記憶體估算）
- 失效場景的 Fallback 策略

特別注意：Redis 叢集模式下的 MULTI/EXEC 限制

請展示 Testcontainers 在 Spring Boot 整合測試的進階應用：

測試場景：
- PostgreSQL 16（含 pgvector 擴展）
- Redis 7（含 Cluster 模式）
- Kafka 3.7
- WireMock（外部 API 模擬）

進階技巧：
1. 共享容器（@Container + @ClassRule）減少啟動次數
2. Ryuk 停用（CI 環境特殊設定）
3. 自定義 Wait Strategy
4. 容器資源限制（模擬生產環境）
5. Testcontainers Cloud 整合（加速 CI）

Spring Boot 3.5 特性：
- @ServiceConnection 自動設定
- spring.testcontainers.beans.reuse 設定

請提供完整的測試基底類別（AbstractIntegrationTest）

請設計 Spring Cloud Contract 合約測試方案：

場景：Transfer Service 呼叫 Account Service

設計要求：
1. Consumer 端合約定義（Groovy DSL / YAML）
2. Provider 端驗證設定
3. Stub Server 自動產生
4. CI/CD 整合（合約更新觸發 Provider 驗證）
5. 版本管理（Stub Runner + Maven Repository）

請提供：
- 合約 YAML 定義
- Consumer 測試程式碼（使用 WireMock Stub）
- Provider 驗證測試
- Maven/Gradle 設定
- GitHub Actions 合約驗證流程

請設計 Spring Boot 應用程式的混沌工程測試方案：

測試目標：驗證系統在以下故障場景的韌性：
1. 資料庫連線中斷
2. Redis 服務不可用
3. Kafka 網路延遲（高延遲注入）
4. 外部 API 超時
5. 記憶體壓力
6. CPU 過載

工具選擇：
- Chaos Monkey for Spring Boot
- Resilience4j（Circuit Breaker/Retry/RateLimiter）
- Toxiproxy（網路故障注入）

請提供：
1. Resilience4j 完整設定（Spring Boot application.yml）
2. Circuit Breaker 降級策略
3. Chaos Monkey 設定（開發/Staging 環境）
4. 混沌實驗設計文件（Game Day Playbook）

請分析並優化以下 Spring Boot 應用程式的效能問題：

症狀：[描述效能問題，例如：在 500 TPS 時 P99 超過 2 秒]

請提供完整的效能診斷流程：

1. JVM 效能分析
   - JFR（Java Flight Recorder）設定
   - Heap Dump 分析（記憶體洩漏）
   - Thread Dump 分析（執行緒阻塞）
   - GC 日誌分析

2. 應用層分析
   - Spring Boot Actuator /metrics 關鍵指標
   - 慢端點識別（Micrometer Timer）
   - HikariCP 連接池監控

3. 資料庫層分析
   - Slow Query Log 分析
   - EXPLAIN ANALYZE 解讀
   - 索引使用狀況

4. 程式碼級優化建議
   （根據分析結果提供具體修改）

請包含完整的 CLI 診斷指令

請對以下系統進行金融業法規合規審查：

適用法規：
- PCI-DSS（若處理支付卡資料）
- 台灣金融監理要求
- GDPR（若有歐洲用戶）

審查範圍：[系統描述]

合規要求清單：
1. 資料分類與保護
   - 持卡人資料環境（CDE）隔離
   - 資料加密（傳輸中/靜止中）
   - 最小化資料保存
2. 存取控制
   - 多因素認證
   - 最小權限原則
   - 特權帳號管理（PAM）
3. 稽核日誌
   - 不可篡改日誌
   - 90 天以上保存
   - 即時異常偵測
4. 漏洞管理
   - 定期掃描（至少每季）
   - 修補時程要求
5. 事件回應計劃

輸出：合規差距分析報告（Gap Analysis）+ 修補優先順序

請為以下 Java 應用程式建立軟體物料清單（SBOM）並評估供應鏈安全：

應用程式：[pom.xml 貼上]

SBOM 分析需求：
1. 產生 SPDX / CycloneDX 格式 SBOM
2. 識別所有直接和間接依賴
3. 評估每個依賴的：
   - 授權相容性（GPL/LGPL/MIT/Apache）
   - 已知 CVE 漏洞
   - 維護狀態（是否已廢棄）
   - 供應商風險（是否單一維護者）
4. 識別依賴混淆攻擊風險
5. 建立依賴更新政策

工具設定：
- CycloneDX Maven Plugin
- GitHub Dependency Review
- Snyk SBOM 分析

請提供 Maven Plugin 設定和 CI/CD 整合方式

請為以下系統設計滲透測試計劃：

系統範圍：[系統描述，例如：網路銀行 Web Application + API]
測試類型：Black Box / Grey Box（選擇並說明理由）
法規要求：[例如：金管會要求每年至少一次滲透測試]

測試計劃設計：
1. 測試範圍定義（In-scope / Out-of-scope）
2. 測試方法論（OWASP Testing Guide v4）
3. 測試案例清單（OWASP Top 10 + 金融業特定）
   - SQL Injection
   - XSS（Stored/Reflected/DOM）
   - Authentication Bypass
   - 授權提升（IDOR/Privilege Escalation）
   - API 安全（OWASP API Top 10）
   - 業務邏輯漏洞（金額篡改/重放攻擊）
4. 工具清單（Burp Suite/OWASP ZAP/sqlmap）
5. 回報格式與修復流程
6. 修復驗證（Re-test）計劃

輸出：測試計劃書（符合金管會要求格式）

請設計以下安全事件的回應 Playbook（AI 輔助版）：

事件類型：
1. 資料外洩（Data Breach）
2. DDoS 攻擊
3. 內部帳號入侵
4. 勒索軟體
5. API 遭受大量爬取

針對每種事件提供：
1. 偵測指標（IOC / Anomaly Signals）
2. 分級標準（P1/P2/P3/P4）
3. 回應步驟（含 AI 工具輔助的自動化步驟）
4. 通報程序（內部/法規單位/用戶）
5. 遏制措施
6. 復原步驟
7. 事後分析（Post-mortem）

AI 輔助部分：
- 使用 Claude Code 進行日誌分析和根因調查
- 自動化修補建議
- 事件報告草稿產生

請評估現有系統並設計 Zero Trust 架構遷移方案：

現有架構：[描述現有網路架構，例如：傳統 VPN + 防火牆邊界安全]
痛點：[描述問題，例如：WFH 後安全邊界難以維護]

Zero Trust 原則評估：
1. 永不信任，始終驗證（Never Trust, Always Verify）
2. 最小權限存取
3. 假設已被入侵（Assume Breach）

遷移路線圖：
1. 身份驗證強化（MFA + Conditional Access）
2. 設備信任（Device Compliance Check）
3. 應用程式存取（ZTNA 取代 VPN）
4. 資料保護（DLP + 加密）
5. 網路分段（Microsegmentation）

技術選型：
- IdP：Keycloak（企業自建）
- ZTNA：Cloudflare Access / Azure AD
- 監控：SIEM 整合

輸出：Zero Trust 成熟度評估 + 分 Phase 實施計劃

請審查以下系統的密碼學應用是否符合現代安全標準：

[提供程式碼或描述加密使用場景]

審查項目：
1. 對稱加密
   - AES-256-GCM（推薦）vs AES-CBC（問題）
   - IV 重用風險
   - Key Management（金鑰輪換）
2. 非對稱加密
   - RSA-OAEP vs RSA-PKCS1v1.5（問題）
   - EC 曲線選擇（P-256/P-384）
3. 雜湊函數
   - SHA-256/SHA-3（推薦）vs MD5/SHA-1（禁用）
   - 密碼雜湊：bcrypt/Argon2（推薦）vs SHA-1（禁用）
4. TLS 設定
   - TLS 1.3（推薦）vs TLS 1.0/1.1（禁用）
   - Cipher Suite 安全性
5. 隨機數生成
   - SecureRandom vs Math.random（危險）

輸出：
- 問題清單（含風險等級）
- 修復後的 Java 程式碼
- Java Cryptography Architecture（JCA）最佳實踐

請為企業設計 AI Coding Assistant 使用治理框架：

企業背景：
- 產業：金融業（受嚴格法規監管）
- 規模：[人數]
- 主要 AI 工具：Claude Code / GitHub Copilot
- 關注點：資料外洩、程式碼品質、IP 問題

治理框架設計：
1. 使用政策
   - 允許/禁止的使用場景
   - 敏感資料不得輸入 AI 的規範
   - AI 產生程式碼的智慧財產權處理

2. 品質管控
   - AI 產生程式碼的審查要求
   - 不得降低測試覆蓋率的規定
   - 安全掃描的強制要求

3. 稽核追蹤
   - AI 工具使用日誌
   - AI 產生程式碼的標記
   - 異常使用偵測

4. 培訓要求
   - 最低培訓時數
   - 認證要求
   - 年度複訓

5. 事件回應
   - AI 工具相關安全事件的處理程序

輸出：完整的企業 AI 使用政策文件（PDF 格式規格）

SOP 名稱：新功能開發 Loop 標準流程
版本：v1.0 | 適用範圍：所有功能開發
========================================

【前置條件】
□ GitHub Issue 已建立並有明確驗收標準
□ 分支已從 main 建立（feature/ISSUE-XXX-描述）
□ CLAUDE.md 為最新版本
□ 相關 Skills 已確認

【Step 1】需求確認（5 分鐘）
$ claude "請確認你理解以下 Issue 的需求，並列出實作要點和潛在風險" \
    --github-issue $ISSUE_NUMBER

【Step 2】設計 Loop（10-30 分鐘）
$ claude --plan "設計實作方案，包含 API 設計、DB Schema、測試策略"

【Step 3】實作 Loop（主要工作）
$ claude "實作 Issue #$ISSUE_NUMBER 的功能，遵循 CLAUDE.md 中的所有規範"
# Loop 中 AI 自動執行：編碼 → 測試 → 修正 → 再測試

【Step 4】品質驗證
$ mvn verify -B                          # 完整測試
$ mvn sonar:sonar                        # 程式碼品質
$ mvn dependency-check:check             # 安全掃描

【Step 5】PR 建立
$ gh pr create \
    --title "feat: 功能描述 (#$ISSUE_NUMBER)" \
    --body "$(cat .github/PULL_REQUEST_TEMPLATE.md)"
    
【驗收標準】
□ 所有測試通過（覆蓋率 ≥ 80%）
□ SonarQube Quality Gate 通過
□ 安全掃描無 CRITICAL/HIGH
□ AI Eval 分數 ≥ 85
□ PR 獲得 2 個 Approve

SOP 名稱：Bug 修復 Loop 流程
版本：v1.0 | 適用範圍：所有 Bug 修復
========================================

【緊急程度分級】
P1 生產環境影響大量用戶 → 立即處理，< 2 小時
P2 生產環境影響部分用戶 → < 4 小時
P3 Staging 環境問題 → < 24 小時
P4 非生產問題 → 下個 Sprint

【P1/P2 緊急修復流程】
Step 1: 建立 Hotfix 分支
$ git checkout -b hotfix/P1-$TICKET_ID main

Step 2: 啟動 Bug 分析 Loop
$ claude "緊急！分析以下 Bug 的根本原因並立即修復：
  錯誤訊息：$(cat logs/error.log | tail -100)
  影響範圍：生產環境
  優先修復，安全問題優先"

Step 3: 快速驗證
$ mvn test -Dtest=相關測試類別 -B

Step 4: Hotfix 部署
$ git tag hotfix-$DATE
$ kubectl set image deployment/app app=$IMAGE:hotfix-$BUILD_NUM -n production
$ kubectl rollout status deployment/app -n production

Step 5: 事後分析（24 小時內）
$ claude "撰寫此次 Bug 的 Post-mortem 報告，包含根因、修復方案、預防措施"

【驗收標準】
□ Bug 已重現並確認修復
□ 相關回歸測試通過
□ 生產環境監控確認正常
□ Post-mortem 已撰寫並分享給團隊

SOP 名稱：每日 AI 開發狀態報告
執行時間：每日早上 9:00 AM（自動執行）
========================================

#!/bin/bash
# .github/scripts/daily-ai-standup.sh

DATE=$(date +%Y-%m-%d)

echo "=== AI 開發每日狀態報告 $DATE ==="

# 1. Git 活動摘要
echo "📊 昨日 Git 活動："
git log --since="1 day ago" --oneline --all | head -20

# 2. CI/CD 狀態
echo "🔄 Pipeline 狀態："
gh run list --limit 5 --json status,name,conclusion \
  | jq '.[] | "\(.name): \(.conclusion)"'

# 3. Open PR 狀態
echo "📋 待處理 PR："
gh pr list --state open --json title,author,reviewDecision \
  | jq '.[] | "\(.title) [\(.reviewDecision)]"'

# 4. Security 狀態
echo "🔒 安全問題："
gh api /repos/$REPO/code-scanning/alerts?state=open \
  | jq 'length' | xargs echo "開放的安全告警："

# 5. AI 使用統計
echo "🤖 AI 工具使用："
cat ~/.claude/usage-$(date +%Y-%m).json 2>/dev/null | \
  jq '.total_tokens' | xargs echo "本月 Token 使用："

# 6. 發送到 Slack
curl -X POST $SLACK_WEBHOOK \
  -H 'Content-type: application/json' \
  --data "{\"text\": \"$STANDUP_CONTENT\"}"

SOP 名稱：月度技術債務清償 Loop
執行頻率：每月第一個星期一
執行時間：全天（Team Debt Day）
========================================

Step 1: 技術債務盤點（AM 09:00-10:00）
$ claude "分析整個 Codebase，識別 Top 20 技術債務項目：
  1. 高複雜度方法（圈複雜度 > 15）
  2. 重複程式碼（相似度 > 80%）
  3. 過時的依賴套件
  4. 缺失測試的核心邏輯
  5. TODO/FIXME 評論
  並依照業務影響和修復成本排序" \
  --output docs/tech-debt-$(date +%Y-%m).md

Step 2: 快速修復 Loop（AM 10:00-12:00）
# 處理所有 < 1 小時的 Quick Win 項目
while IFS= read -r item; do
  claude "修復以下技術債務項目（Quick Win，< 1 小時）：$item" \
    --auto-commit \
    --branch "debt/$(date +%Y%m)-quick-fix"
done < docs/tech-debt-quick-wins.txt

Step 3: 中型重構 Loop（PM 14:00-17:00）
# 一個 Agent 負責一個中型重構任務
git worktree add -b debt/refactor-service-a ../wt-debt-a
cd ../wt-debt-a
claude "重構 CustomerService，應用 Single Responsibility Principle"

Step 4: 成果報告（PM 17:00-17:30）
$ claude "整合今日技術債務清償成果，計算：
  - 消除的程式碼行數
  - 降低的圈複雜度平均值
  - 新增的測試覆蓋率
  - 升級的套件數量
  產出報告發送給技術主管"

SOP 名稱：新進工程師 Loop Engineering Onboarding
適用對象：新進工程師（前 2 週）
========================================

【Week 1：基礎工具】

Day 1: 環境設定
$ git clone $REPO_URL
$ cd $PROJECT_NAME
$ mvn verify  # 確認環境正確

# 安裝 AI 工具
$ npm install -g @anthropic-ai/claude-code
$ claude login
$ claude init

# 閱讀專案 CLAUDE.md
$ cat CLAUDE.md

Day 2-3: 理解 Loop Engineering 概念
# 閱讀教學手冊
$ cat .github/教學/AI開發/"Loop Engineering 教學手冊.md"

# 完成第一個 AI 輔助任務（低風險 Bug Fix）
$ claude "找出所有 TODO 評論，選擇最簡單的一個並修復"

Day 4-5: Skills & Memory 系統
# 探索 Skill Library
$ ls .claude/skills/
$ cat .claude/skills/coding/java-spring-boot.md

# 練習使用 Memory
$ claude "告訴我關於這個專案的技術決策"

【Week 2：進階應用】

Day 6-8: 完整 Loop 流程實作
# 負責一個完整的小功能開發
$ gh issue create --title "新人練習：[功能名稱]" --label "good-first-issue"
$ claude "實作 Issue #XXX 的功能，完整展示 Loop Engineering 流程"

Day 9-10: 程式碼審查 Loop
# 學習使用 AI 輔助審查
$ claude /code-review  # 審查自己的程式碼
$ claude /code-review ultra  # 深度審查

【驗收標準】
□ 完成一個完整的 Loop Engineering 開發循環
□ PR 通過所有自動化檢查
□ 完成 Loop Engineering 教學手冊閱讀
□ 通過技術主管驗收面談

SOP 名稱：CI 失敗自動修復 Loop
觸發條件：CI Pipeline 失敗
========================================

#!/bin/bash
# .github/scripts/auto-fix-ci.sh

FAILURE_TYPE=$1  # build|test|lint|security

case $FAILURE_TYPE in
  "build")
    echo "🔨 Build 失敗，啟動 AI 修復 Loop..."
    ERROR_LOG=$(cat logs/build.log | tail -200)
    claude "修復以下 Java 編譯錯誤，不得降低 Java 版本：
    $ERROR_LOG" \
      --auto-commit \
      --commit-msg "fix: auto-fix build errors [CI]"
    ;;
    
  "test")
    echo "🧪 測試失敗，啟動 AI 修復 Loop..."
    FAILED_TESTS=$(mvn test 2>&1 | grep "FAILED\|ERROR" | head -50)
    claude "修復以下測試失敗。
    重要：不得刪除測試、不得降低斷言強度。
    若測試本身有誤，修正測試邏輯。
    若是程式碼問題，修正程式碼：
    $FAILED_TESTS" \
      --auto-commit \
      --commit-msg "fix: auto-fix test failures [CI]"
    ;;
    
  "lint")
    echo "📏 Lint 失敗，啟動 AI 修復 Loop..."
    LINT_ISSUES=$(mvn checkstyle:check 2>&1 | tail -100)
    claude "自動修復所有 Checkstyle 問題（不改變邏輯）：
    $LINT_ISSUES" \
      --auto-commit \
      --commit-msg "style: auto-fix lint issues [CI]"
    ;;
    
  "security")
    echo "🔒 安全掃描失敗！需要人工審查..."
    # 安全問題不自動修復，建立 Issue 並通知
    gh issue create \
      --title "🔒 安全告警：CI 安全掃描失敗" \
      --label "security,critical" \
      --assignee "$SECURITY_TEAM" \
      --body "$(cat logs/security.log)"
    # 傳送 Slack 告警
    curl -X POST $SLACK_SECURITY_WEBHOOK \
      -d "{\"text\": \"🚨 安全告警！請立即查看 GitHub Issue\"}"
    exit 1
    ;;
esac

# 修復後重新執行 CI
echo "✅ 修復完成，重新觸發 CI..."
git push origin HEAD
gh run rerun --failed

SOP 名稱：季度安全評估 Loop
執行頻率：每季（Q1/Q2/Q3/Q4 第一週）
========================================

Step 1: 準備階段（1 天）
$ git clone $REPO security-audit-$(date +%Y-Q$(( ($(date +%-m)-1)/3+1 )))
$ cd security-audit-*

Step 2: 全面安全掃描
# SAST
$ mvn spotbugs:spotbugs -Dspotbugs.plugins=findsecbugs 2>&1 | tee sast-report.txt

# 相依套件
$ mvn dependency-check:check -DfailBuildOnCVSS=0 2>&1 | tee dep-report.txt

# 秘密掃描
$ gitleaks detect --source . --report-path secrets-report.json

# Container
$ trivy image $APP_IMAGE:latest --format json > container-report.json

# IaC
$ checkov -d deploy/ --output json > iac-report.json

Step 3: AI 綜合分析
$ claude "請分析以下所有安全掃描報告，
  提供：
  1. 高風險問題排序（CVSS 評分）
  2. 趨勢分析（與上季比較）
  3. 修復優先順序建議
  4. 下季度安全改善計劃
" \
  --file sast-report.txt dep-report.txt secrets-report.json \
  --output reports/security-$(date +%Y-Q)$(( ($(date +%-m)-1)/3+1 )).md

Step 4: 提交安全報告
$ gh issue create \
    --title "季度安全評估報告 $(date +%Y-Q)$(( ($(date +%-m)-1)/3+1 ))" \
    --label "security,quarterly-review" \
    --body "$(cat reports/security-*.md)"

SOP 名稱：AI 輔助程式碼審查標準流程
觸發條件：PR 建立時
========================================

【自動化審查階段（< 10 分鐘）】

Step 1: CI 自動品質檢查
- SonarQube Quality Gate
- CheckStyle
- SpotBugs
- 測試覆蓋率

Step 2: AI 自動審查（Claude Code）
$ claude /code-review --pr $PR_NUMBER

審查重點（依優先級）：
1. 安全性問題（CRITICAL — 阻擋合併）
2. 功能正確性（HIGH — 需修正）
3. 效能問題（MEDIUM — 建議修正）
4. 程式碼品質（LOW — 自行判斷）

Step 3: AI 審查結果動作
- CRITICAL: 自動拒絕 PR + 指派安全工程師
- HIGH: 自動留言要求修正
- MEDIUM/LOW: 自動留言作為建議

【人工審查階段（< 24 小時）】

Step 4: 人工審查人員確認 AI 審查結果
- 確認 CRITICAL/HIGH 已修正
- 審查 AI 可能漏掉的業務邏輯問題
- 架構決策的最終判斷

Step 5: 合併條件
□ 2 個 Reviewer Approve
□ AI Eval 分數 ≥ 85
□ 所有 CI 通過
□ 無未解決的 CRITICAL/HIGH 評論

SOP 名稱：生產事件 AI 輔助處理流程
========================================

【事件偵測（自動）】
監控系統觸發告警 → PagerDuty 通知 On-call → 開啟事件 Channel

【事件分析 Loop（AI 輔助）】

Step 1: 立即診斷
$ claude "緊急！生產事件！
  告警訊息：$ALERT_MESSAGE
  近期部署：$(git log --oneline -5)
  
  請立即分析：
  1. 最可能的根本原因
  2. 影響範圍估計
  3. 建議的立即緩解措施（不需要程式碼變更）
  4. 若需要回滾，評估回滾的安全性"

Step 2: 日誌分析
$ # 收集最近 30 分鐘的錯誤日誌
  kubectl logs -n production \
    -l app=$APP_NAME \
    --since=30m \
    | grep "ERROR\|EXCEPTION" | head -500 | \
  claude -p "分析以下日誌，找出錯誤模式和根本原因"

Step 3: 緩解措施執行
$ # 若需要回滾
  kubectl rollout undo deployment/$APP_NAME -n production

Step 4: 事後分析（24 小時後）
$ claude "撰寫生產事件 Post-mortem，包含：
  - 事件時間線
  - 根本原因
  - 影響範圍
  - 修復措施
  - 預防措施（包含哪些 Eval/監控需要加強）
  - Action Items（負責人/完成時間）" \
  --template .github/templates/postmortem.md

SOP 名稱：效能調優 Loop 標準流程
觸發條件：效能指標下降 > 10% 或 P95 超過 SLA
========================================

Step 1: 效能問題確認
$ # 查詢 Grafana 指標
  curl -s "http://grafana:3000/api/datasources/proxy/1/api/v1/query_range" \
    --data-urlencode 'query=histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))' \
    --data-urlencode "start=$(date -d '1 hour ago' +%s)" \
    --data-urlencode "end=$(date +%s)" \
    --data-urlencode "step=60" \
  | jq '.data.result[].values[] | .[1]' | tail -10

Step 2: 啟用效能剖析
$ # 啟用 Java Flight Recorder
  kubectl exec -n production deploy/$APP_NAME -- \
    jcmd 1 JFR.start duration=120s filename=/tmp/perf.jfr

$ # 等待 2 分鐘後收集
  kubectl cp production/$POD_NAME:/tmp/perf.jfr ./perf-$(date +%Y%m%d).jfr

Step 3: AI 效能分析
$ claude "分析以下效能數據，識別瓶頸：
  - JFR 分析結果：$(jfr print --events CPULoad,ThreadSleep perf-*.jfr | head -200)
  - Slow Query：$(cat logs/slow-query.log | tail -50)
  - GC 日誌：$(cat logs/gc.log | tail -100)
  
  請提供：
  1. Top 5 效能瓶頸
  2. 每個瓶頸的優化方案（含程式碼）
  3. 預期改善幅度"

Step 4: 效能修復 Loop
$ claude "實作以下效能優化：$OPTIMIZATION_LIST
  要求：
  - 必須有對應的 JMH 效能基準測試
  - 不得改變功能行為
  - 修復後執行效能對比測試"

Step 5: 驗證效能改善
$ mvn jmh:benchmark -Dinclude=$BENCHMARK_CLASS
$ # 比較 Before/After 結果
$ claude "比較以下效能測試結果，確認改善是否達到目標：
  Before: $(cat benchmarks/before.json)
  After: $(cat benchmarks/after.json)"

SOP 名稱：依賴套件安全更新 Loop
觸發條件：發現新 CVE 或定期週一執行
========================================

Step 1: 掃描安全漏洞
$ mvn dependency-check:check \
    -Dformat=JSON \
    -DfailBuildOnCVSS=0 \
    --output-directory target/dc-reports

Step 2: AI 分析與排優先
$ VULN_REPORT=$(cat target/dc-reports/dependency-check-report.json)
$ claude "分析以下 CVE 漏洞報告：
  1. 按 CVSS 評分排序
  2. 評估每個漏洞的實際可利用性（非所有 CVE 都需立即修復）
  3. 提供升級建議（安全版本號）
  4. 識別需要程式碼修改的 Breaking Changes
  5. 輸出格式：CRITICAL（本週）/ HIGH（2週）/ MEDIUM（月）" \
  --context "$VULN_REPORT"

Step 3: 自動升級安全版本
$ # 只升級有 CVE 的套件到安全版本
$ mvn versions:use-next-releases -DallowMinorUpdates=false
$ mvn versions:use-latest-releases -Dincludes="安全相關套件清單"

Step 4: 驗證升級
$ mvn verify -B
$ mvn dependency-check:check -DfailBuildOnCVSS=7

Step 5: 建立 PR
$ git add pom.xml
$ git commit -m "chore: security dependency updates [automated]

CVE 修復：
$(cat security-updates.txt)

Co-Authored-By: Loop Engineering Bot <loop-bot@company.com>"

$ gh pr create \
    --title "chore: security dependency updates $(date +%Y-%m-%d)" \
    --label "security,dependencies,automated" \
    --reviewer "$SECURITY_TEAM"