推導路徑：
Route/Endpoint → 功能入口
Request Model → 輸入欄位與驗證
Response Model → 輸出結果
HTTP Status → 錯誤處理邏輯
Authorization → 權限需求

請分析這段 C# Web API Controller，告訴我：
1. 提供了哪些 API 端點（含 HTTP Method 與 Route）
2. 每個端點的輸入參數與驗證規則
3. 回傳的資料結構
4. 權限控制機制
5. 推導這些端點對應的業務功能

推導路徑：
Method Signature → 業務操作名稱
Parameters → 業務輸入條件
If/Switch 判斷 → 商業規則
Exception → 業務例外情境
Transaction → 資料一致性需求

請分析這段 Service 類別，針對每個 public 方法：
1. 用商業術語描述這個方法在做什麼
2. 列出所有商業規則（if/else 條件判斷）
3. 標記資料驗證邏輯
4. 說明交易範圍（Transaction Scope）
5. 列出例外處理代表的業務情境

推導路徑：
Query → 資料讀取需求
Insert/Update/Delete → 資料異動需求
Join → 資料關聯
Where 條件 → 篩選邏輯

推導路徑：
Input Parameters → 業務輸入
Cursor/Loop → 批次處理邏輯
CASE/IF → 商業規則
INSERT INTO / MERGE → 資料產出
Output Parameters / Result Set → 業務輸出

請分析這段 SQL Server Stored Procedure：
1. 用商業術語描述此 SP 的目的
2. 列出所有輸入參數及其業務意義
3. 解析核心邏輯（特別是 CASE/IF 判斷中的商業規則）
4. 說明資料來源與目標表的關係
5. 標記效能相關的設計（如 Index Hint、Partition）
6. 推導這個 SP 對應的業務需求

推導路徑：
Schedule/Trigger → 執行頻率需求
Input Source → 資料來源需求
Processing Steps → 批次處理邏輯
Error Handling → 異常處理需求
Output/Report → 產出需求

你是一位熟悉銀行核心系統的資深架構師。
你的任務是從程式碼中推導出業務需求。
請用商業術語（非技術術語）描述你的分析結果。
如果遇到不確定的商業邏輯，請標記為「待確認」。

## 分析任務
[明確說明要做什麼]

## 程式碼上下文
[說明程式碼屬於哪個系統/模組]

## 分析重點
1. [第一個分析面向]
2. [第二個分析面向]
3. [第三個分析面向]

## 輸出格式
[指定期望的輸出格式]

操作步驟：
1. 在 VS Code 中打開目標檔案
2. 選取要分析的程式碼片段
3. 按 Ctrl+I（Inline Chat）或開啟 Copilot Chat 面板
4. 輸入分析 Prompt
5. 將結果複製到 SRS 工作文件中

請分析以下 C# Web API Controller。
系統背景：這是一個銀行的轉帳系統。

請以如下格式輸出：
### API 清單
| 端點 | HTTP Method | 功能說明 | 輸入參數 | 輸出 | 權限 |

### 商業規則
- 每個端點對應的業務規則

### 推導需求
- FR-001: [需求描述]

這段 C# Service 程式碼屬於銀行的「帳戶管理」模組。
請用非技術人員能理解的語言，分析此段程式碼：

1. 這段程式碼在做什麼？（用一句話描述）
2. 有哪些商業規則？（列出每個 if/switch 的商業意義）
3. 有哪些例外情境？（什麼情況會拋出錯誤）
4. 涉及哪些資料表？（推測用途）
5. 轉為功能需求描述（FR 格式）

以下是 C# 的 Entity 類別，請分析：
1. 對應的資料庫表結構（含欄位名稱、型別、是否必填）
2. 表之間的關聯（一對一、一對多、多對多）
3. 推導出 ER Diagram（使用 Mermaid erDiagram 語法）
4. 用商業術語描述每張表的用途

以下是一段 SQL Server Stored Procedure，屬於銀行的「利息計算」模組。

請用以下結構分析：

## SP 概述
- 用途（一句話）
- 執行頻率（推測：即時 / 日批 / 月批）

## 輸入參數分析
| 參數名稱 | 型別 | 業務意義 |

## 核心邏輯
- 第一步：[做什麼]
- 第二步：[做什麼]
...

## 商業規則
- BR-001: [如果條件A，則...]
- BR-002: [如果條件B，則...]

## 資料影響
- 讀取的表：[表名 → 用途]
- 寫入的表：[表名 → 用途]

## 推導需求
- FR-XXX: [功能需求描述]

這段 SQL 查詢涉及多表 JOIN。
請分析：
1. 用白話文描述這段 SQL 在做什麼
2. 畫出涉及的表關聯圖（Mermaid erDiagram）
3. 每個 JOIN 的商業意義
4. WHERE 條件代表的篩選邏輯（用商業術語描述）
5. 最終結果集代表什麼業務資料

以下是一個排程批次程式，請分析：

## 批次概述
- 用途
- 推測執行頻率
- 推測執行時間點

## 處理流程
```mermaid
graph TD
    A[開始] --> B[...] --> C[結束]

### 2.7 從技術描述轉換為商業需求描述

這是逆向工程中最關鍵的步驟。以下是轉換模板：

#### Prompt 7 — 技術→商業語言轉換

**期望輸出範例**：

```markdown
### 用戶故事
作為一位銀行客戶，我希望能夠進行轉帳交易，
以便將資金從我的帳戶轉到指定帳戶。

### 功能需求
FR-TXN-001：系統應支援帳戶轉帳功能
- 系統應檢查轉出帳戶餘額是否充足
- 若餘額不足，系統應拒絕交易並顯示「餘額不足」訊息
- 若餘額充足，系統應：
  a. 自轉出帳戶扣除轉帳金額
  b. 記錄交易明細（含時間戳記）
  
### 驗收條件
Given 帳戶餘額為 10,000 元
When 使用者發起 5,000 元轉帳
Then 帳戶餘額應更新為 5,000 元
And 應產生一筆轉帳交易記錄

[HttpPost("transfer")]
[Authorize(Roles = "Teller,Manager")]
public async Task<IActionResult> Transfer([FromBody] TransferRequest request)
{
    if (request.Amount <= 0)
        return BadRequest("Invalid amount");
    
    if (request.Amount > 1000000)
        return BadRequest("Amount exceeds daily limit");
    
    var sourceAccount = await _accountRepo.GetByIdAsync(request.SourceAccountId);
    if (sourceAccount == null)
        return NotFound("Source account not found");
    
    if (sourceAccount.Status != AccountStatus.Active)
        return BadRequest("Source account is not active");
    
    if (sourceAccount.Balance < request.Amount)
        return BadRequest("Insufficient balance");
    
    var destAccount = await _accountRepo.GetByIdAsync(request.DestAccountId);
    if (destAccount == null)
        return NotFound("Destination account not found");
    
    using var transaction = await _dbContext.Database.BeginTransactionAsync();
    try
    {
        sourceAccount.Balance -= request.Amount;
        destAccount.Balance += request.Amount;
        
        var txnRecord = new TransactionRecord
        {
            SourceAccountId = request.SourceAccountId,
            DestAccountId = request.DestAccountId,
            Amount = request.Amount,
            Type = TransactionType.Transfer,
            Timestamp = DateTime.UtcNow,
            OperatorId = User.Identity.Name
        };
        
        await _txnRepo.AddAsync(txnRecord);
        await _dbContext.SaveChangesAsync();
        await transaction.CommitAsync();
        
        return Ok(new { TransactionId = txnRecord.Id });
    }
    catch
    {
        await transaction.RollbackAsync();
        throw;
    }
}

你是一位銀行系統分析師。請分析以下轉帳 API 的程式碼，
產出功能需求規格（SRS 片段），包含：
1. 功能描述
2. 前置條件
3. 商業規則
4. 處理流程
5. 驗收條件

## FR-TXN-001 帳戶轉帳

### 功能描述
系統提供帳戶間轉帳功能，允許授權人員（櫃員、主管）
執行資金轉移作業。

### 前置條件
- 操作人員已登入系統
- 操作人員具備「櫃員」或「主管」角色

### 商業規則
| 規則編號 | 規則描述 |
|----------|----------|
| BR-TXN-001 | 轉帳金額必須大於 0 |
| BR-TXN-002 | 單筆轉帳金額不得超過 1,000,000 元 |
| BR-TXN-003 | 轉出帳戶必須存在且狀態為「啟用中」 |
| BR-TXN-004 | 轉出帳戶餘額必須大於等於轉帳金額 |
| BR-TXN-005 | 轉入帳戶必須存在 |
| BR-TXN-006 | 轉帳為原子性操作（全部成功或全部回滾） |

### 處理流程
1. 驗證轉帳金額有效性
2. 驗證轉出帳戶存在性與可用狀態
3. 驗證轉出帳戶餘額充足
4. 驗證轉入帳戶存在性
5. 執行資金轉移（扣款與入款）
6. 建立交易紀錄（含操作人員、時間戳記）
7. 回傳交易編號

### 驗收條件
| 情境 | Given | When | Then |
|------|-------|------|------|
| 正常轉帳 | 帳戶 A 餘額 50,000 | 轉帳 10,000 到帳戶 B | A 餘額 40,000；B 餘額增加 10,000；產生交易記錄 |
| 餘額不足 | 帳戶 A 餘額 5,000 | 轉帳 10,000 | 交易拒絕；餘額不變 |
| 超過限額 | 任意帳戶 | 轉帳 2,000,000 | 交易拒絕；顯示超過限額 |
| 帳戶停用 | 帳戶狀態為停用 | 嘗試轉帳 | 交易拒絕；顯示帳戶非啟用 |

請分析 src/Controllers/ 目錄下所有 Controller，並產出以下報告：

1. 每個 Controller 的 API 端點清單（含 HTTP Method、Route、權限）
2. 每個端點呼叫的 Service 層方法
3. 端點之間的依賴關係圖（Mermaid）
4. 推導每個端點對應的業務功能
5. 將結果輸出為 docs/analysis/api-inventory.md

注意：
- 追蹤到 Service 層即可，不需深入 Repository
- 標記可能是「管理端」vs.「客戶端」的 API
- 標記已標註 [Obsolete] 的端點

我需要對一個 .NET Framework 4.8 的銀行核心系統進行逆向工程，產出 SRS 文件。

系統規模：
- 25 個 Controller（約 200 支 API）
- 150 個 Stored Procedure
- 8 支 Batch Job
- 3 個外部系統介接

請制定逆向工程執行計劃：
1. 分析優先順序（依業務重要性）
2. 每個階段的工作項目與預估產出
3. 人力配置建議
4. 風險項目與緩解措施
5. 品質檢查點（Gate）

## 逆向分析任務：帳戶管理模組

### 分析範圍
- `src/Controllers/AccountController.cs`
- `src/Services/AccountService.cs`
- `src/Repositories/AccountRepository.cs`
- 相關 SP：`sp_Account_*`

### 產出要求
請在 `docs/srs/module-account.md` 產出以下內容：
1. 模組概述
2. 功能需求清單（FR-ACC-001 起始）
3. 商業規則彙整
4. Use Case Diagram（Mermaid）
5. 資料模型描述

### 格式規範
- 遵循 `docs/srs/template.md` 的 SRS 模板
- 使用繁體中文
- 每條需求標記信心度（高/中/低）

### 注意事項
- 不要在分析中包含任何客戶真實資料
- 標註 [Obsolete] 的方法請標記為「待確認是否廢棄」

{
  "mcpServers": {
    "database-schema": {
      "command": "npx",
      "args": ["@mcp/sql-server", "--connection-string", "${env:DB_CONNECTION}"],
      "description": "連接 SQL Server 取得 Schema 與 SP 定義"
    },
    "jira-issues": {
      "command": "npx",  
      "args": ["@mcp/jira", "--base-url", "${env:JIRA_URL}"],
      "description": "存取 JIRA Issue 作為需求上下文"
    },
    "confluence-docs": {
      "command": "npx",
      "args": ["@mcp/confluence", "--base-url", "${env:CONFLUENCE_URL}"],
      "description": "存取 Confluence 上的既有系統文件"
    }
  }
}

請使用 database-schema 工具取得以下 SP 的完整定義：
- sp_Account_Transfer
- sp_Account_GetBalance
- sp_Account_Close

然後使用 jira-issues 工具搜尋與「帳戶管理」相關的 Issue，
作為業務上下文參考。

綜合以上資訊，產出帳戶管理模組的需求分析報告。

---
name: "reverse-engineer"
description: "專門進行逆向工程分析的自定義代理"
tools:
  - "read_file"
  - "search"
  - "mcp:database-schema"
  - "mcp:jira-issues"
---

# 逆向工程分析師代理

## 角色定位
你是一位資深的逆向工程分析師，專精於從企業系統程式碼中推導業務需求。

## 分析原則
1. 區分「技術實作」與「業務需求」，僅輸出業務需求
2. 對每條推導出的需求標記信心度（高/中/低）
3. 使用 IEEE 830 SRS 格式
4. 使用繁體中文撰寫
5. 需求編號使用 FR-[模組]-XXX 格式

## 安全規範
- 不在輸出中包含密碼、金鑰等機敏資訊
- 不包含客戶真實個資（帳號、姓名）
- 分析結果中的範例資料使用虛構資料

## 輸出格式
每個模組分析必須包含：
1. 模組概述
2. 功能需求清單
3. 商業規則表
4. 非功能需求
5. Use Case Diagram（Mermaid）
6. 待確認事項清單

在 Jira Issue 中：

標題：逆向分析 — 帳戶管理模組
描述：
請分析 GitHub 儲存庫 bank-core-system 中的帳戶管理模組：
- src/Controllers/AccountController.cs
- src/Services/AccountService.cs
- 相關 SP：sp_Account_*

產出 SRS 分析文件至 docs/srs/module-account.md

→ 使用 GitHub for Jira 整合，Copilot Coding Agent 將自動開始分析並開 PR

[Background Session]

請分析 src/Services/ 目錄下所有 Service 類別：

1. 每個 Service 的功能摘要（一句話）
2. 每個 public 方法的商業規則清單
3. Service 之間的依賴關係圖（Mermaid）
4. 將結果存入 docs/analysis/services-summary.md

完成後通知我。

請掃描當前專案目錄結構，提供以下分析：

1. 專案架構概覽（分層說明）
2. 主要模組清單（按業務功能分類）
3. 技術棧摘要（使用的框架、元件庫）
4. 預估系統規模（小型 / 中型 / 大型）
5. 關鍵設定檔說明

請以表格形式呈現。

請分析以下目錄中的所有 C# 類別檔案：
/src/Services/AccountService/

對每個檔案提供：
| 檔案名稱 | 類型 | 主要功能 | 關聯模組 | 複雜度(高/中/低) |

最後彙整為模組功能摘要（不超過 200 字）。

# 快速盤點 C# 專案結構
# 列出所有 Controller
Get-ChildItem -Path . -Recurse -Filter "*Controller.cs" | 
    Select-Object Name, DirectoryName |
    Format-Table -AutoSize

# 列出所有 Service
Get-ChildItem -Path . -Recurse -Filter "*Service.cs" | 
    Select-Object Name, DirectoryName |
    Format-Table -AutoSize

# 統計程式碼行數（按檔案類型）
Get-ChildItem -Path . -Recurse -Include "*.cs","*.sql","*.config" |
    Group-Object Extension |
    Select-Object Name, Count, @{N='TotalLines';E={
        ($_.Group | ForEach-Object { (Get-Content $_.FullName).Count } | Measure-Object -Sum).Sum
    }} |
    Format-Table -AutoSize

-- 盤點 SQL Server Stored Procedure
SELECT 
    s.name AS SchemaName,
    o.name AS ProcedureName,
    o.create_date,
    o.modify_date,
    DATALENGTH(sm.definition) / 1024 AS SizeKB
FROM sys.objects o
JOIN sys.schemas s ON o.schema_id = s.schema_id
JOIN sys.sql_modules sm ON o.object_id = sm.object_id
WHERE o.type = 'P'
ORDER BY s.name, o.name;

請追蹤以下 API 的完整呼叫鏈路：
POST /api/v1/loans/apply

從 Controller → Service → Repository → Database，
逐層分析：
1. 每一層做了什麼
2. 資料如何流動（Input → Transform → Output）
3. 在哪一層有商業規則
4. 資料庫讀寫操作清單
5. 畫出呼叫序列圖（Mermaid sequenceDiagram）

這是一個每日凌晨 2:00 執行的批次程式（利息計算）。
請分析此批次程式的完整流程：

1. 觸發條件與前置依賴
2. 處理步驟（按順序列出）
3. 每個步驟的輸入與輸出
4. 錯誤處理機制（重試？跳過？中斷？）
5. 完成後的通知機制
6. 用 Mermaid flowchart 畫出完整流程圖

請分析以下 Stored Procedure 的完整依賴：

1. 此 SP 讀取了哪些資料表？
2. 此 SP 寫入了哪些資料表？
3. 此 SP 呼叫了哪些其他 SP / Function？
4. 有哪些 SP 會呼叫此 SP？
5. 畫出依賴關係圖（Mermaid graph）

以下程式碼包含許多 if/else 判斷。
請將每個條件判斷轉換為商業規則：

格式要求：
| 規則編號 | 程式碼位置 | 技術條件 | 商業規則（白話文） | 分類 |

分類包含：
- 資料驗證（Validation）
- 權限控制（Authorization）
- 業務邏輯（Business Logic）
- 流程控制（Flow Control）

請根據以下已分析的程式碼清單，
建立「需求追溯矩陣（Requirement Traceability Matrix）」：

格式：
| 需求編號 | 需求描述 | 來源程式碼 | 來源 SP | 相關表 | 優先級 | 狀態 |

狀態包含：已確認 / 待確認 / 待PM驗證

請根據以下分析結果，生成符合 IEEE 830 標準的 SRS 文件章節：

分析結果：
[貼上之前的所有分析結果]

請輸出：
1. 功能需求（每個需求包含編號、描述、前置條件、處理流程、後置條件）
2. 非功能需求（效能、安全、可用性）
3. 資料需求（資料字典）
4. 使用者介面需求（如果能從程式碼推導）

請審查以下 SRS 文件片段，檢查：
1. 需求是否完整（有無遺漏的功能）
2. 需求是否一致（有無矛盾）
3. 需求是否可測試（能否寫出測試案例）
4. 需求描述是否清晰（非技術人員能否理解）
5. 是否有隱含需求未被明確記載

請列出所有發現的問題與改善建議。

SRS 文件結構：
├── 1. 文件資訊
│   ├── 版本歷程
│   ├── 審查紀錄
│   └── 術語定義
├── 2. 系統概述
│   ├── 系統背景
│   ├── 系統目標
│   └── 使用者角色
├── 3. Use Case
│   ├── Use Case 清單
│   ├── Use Case 描述
│   └── Use Case Diagram
├── 4. 功能需求
│   ├── 模組 A
│   ├── 模組 B
│   └── ...
├── 5. 非功能需求
│   ├── 效能
│   ├── 安全性
│   ├── 可用性
│   └── 合規性
├── 6. 資料規格
│   ├── 資料流程圖（DFD）
│   ├── ER Model
│   └── 資料字典
├── 7. 批次流程
│   ├── 批次清單
│   └── 批次流程圖
├── 8. 介面規格
│   ├── 外部系統介面
│   └── API 規格
└── 附錄

## 2. 系統概述

### 2.1 系統背景
[系統名稱] 為 [公司名稱] 之 [業務領域] 核心系統，
自 [上線年份] 年上線至今，主要處理 [業務描述]。

### 2.2 系統目標
本系統之主要業務目標包含：
1. [目標一]
2. [目標二]
3. [目標三]

### 2.3 使用者角色
| 角色 | 說明 | 主要功能 | 估計人數 |
|------|------|----------|----------|
| 櫃員 | 分行臨櫃服務人員 | 帳戶查詢、轉帳、繳費 | ~500 |
| 主管 | 分行主管 | 大額交易核准、報表查詢 | ~100 |
| 系統管理員 | IT 維運人員 | 系統設定、權限管理 | ~10 |

### 2.4 系統範圍

根據以下程式碼專案的分析結果，請撰寫 SRS 的「系統概述」章節：

專案資訊：
- 使用 C# / .NET Framework 4.8
- 包含 Web API 和 Windows Service
- 資料庫為 SQL Server 2019
- 涉及 42 個 API Controller

請包含：系統背景、系統目標、使用者角色、系統範圍
使用正式的企業文件語氣撰寫。

### UC-001 帳戶轉帳

| 項目 | 內容 |
|------|------|
| **名稱** | 帳戶轉帳 |
| **主要參與者** | 櫃員 |
| **前置條件** | 櫃員已登入系統 |
| **後置條件** | 轉帳完成，帳戶餘額更新 |
| **觸發事件** | 櫃員選擇「轉帳」功能 |

**主要流程**：
1. 櫃員輸入轉出帳號
2. 系統驗證帳號有效性
3. 櫃員輸入轉入帳號
4. 系統驗證轉入帳號有效性
5. 櫃員輸入轉帳金額
6. 系統驗證餘額充足
7. 系統執行轉帳
8. 系統顯示交易結果

**替代流程**：
- 2a. 帳號不存在 → 顯示錯誤訊息
- 6a. 餘額不足 → 顯示餘額不足訊息
- 7a. 系統錯誤 → 交易回滾、顯示系統錯誤

**商業規則**：
- BR-001: 單筆轉帳上限 1,000,000 元
- BR-002: 僅啟用帳戶可進行轉帳

請從以下 Controller + Service 程式碼，
推導出完整的 Use Case 描述。

格式需包含：
- 名稱、參與者、前置/後置條件
- 主要流程（逐步描述）
- 替代流程（異常情境）
- 相關商業規則
- Use Case Diagram（Mermaid 語法）

### FR-ACC-001 帳戶開戶

**需求描述**：
系統應提供帳戶開戶功能，允許授權人員為客戶建立新帳戶。

**前置條件**：
- 操作人員具備「櫃員」角色
- 客戶已完成 KYC 程序

**處理流程**：
1. 系統驗證客戶身分證號碼格式
2. 系統檢查是否已有相同身分證號的帳戶
3. 系統產生新帳戶編號（規則：分行碼 + 序號）
4. 系統建立帳戶資料（初始餘額為 0）
5. 系統記錄開戶交易日誌

**商業規則**：
| 規則 | 描述 |
|------|------|
| BR-ACC-001 | 每位客戶在同一分行最多開立 3 個帳戶 |
| BR-ACC-002 | 帳號格式：3 碼分行碼 + 10 碼序號 |
| BR-ACC-003 | 初始帳戶狀態為「啟用」 |

**輸入資料**：
| 欄位 | 型別 | 必填 | 說明 |
|------|------|------|------|
| 身分證字號 | String(10) | Y | 驗證格式 |
| 客戶姓名 | String(50) | Y | |
| 聯絡電話 | String(20) | Y | |
| 通訊地址 | String(200) | Y | |
| 帳戶類型 | Enum | Y | 活儲/定儲/外幣 |

**輸出資料**：
| 欄位 | 型別 | 說明 |
|------|------|------|
| 帳戶編號 | String(13) | 新開立的帳號 |
| 開戶日期 | DateTime | 系統日期 |
| 操作結果 | Boolean | 成功/失敗 |

根據以下程式碼中的技術實作細節，推導非功能需求：

1. 效能需求（Response Time、Throughput、Concurrency）
   - 從 async/await、Cache、Connection Pool 推導
2. 安全性需求
   - 從 Authentication、Authorization、Encryption 推導
3. 可用性需求
   - 從 Retry、Circuit Breaker、Fallback 推導
4. 可擴展性需求
   - 從架構設計推導

請以 NFR-XXX 格式輸出。

### NFR 非功能需求

#### NFR-PERF-001 回應時間
- 一般查詢：< 2 秒（95th percentile）
- 交易處理：< 5 秒（95th percentile）
- 報表產出：< 30 秒

#### NFR-SEC-001 身份驗證
- 系統應採用 JWT Token 驗證機制
- Token 有效期限不超過 30 分鐘
- 密碼長度至少 12 碼，包含大小寫英文、數字與特殊字元

#### NFR-AVL-001 系統可用性
- 線上服務可用性 ≥ 99.9%
- 計畫性維護時段：每週日 02:00 ~ 06:00
- RTO（Recovery Time Objective）：< 4 小時
- RPO（Recovery Point Objective）：< 1 小時

#### NFR-AUD-001 稽核日誌
- 所有交易操作必須記錄完整稽核軌跡
- 日誌保留期限：至少 7 年
- 日誌應包含：操作人員、操作時間、操作內容、操作結果

請根據以下系統分析結果，
繪製 Level 0 和 Level 1 的資料流程圖（DFD）。

使用 Mermaid 語法，標示：
- 外部實體
- 處理程序
- 資料儲存
- 資料流

請從以下 Entity 類別集合，生成 ER Diagram：

1. 使用 Mermaid erDiagram 語法
2. 標示 PK、FK
3. 標示關聯 Type（一對一、一對多、多對多）
4. 每張表加上中文說明
5. 列出資料字典（欄位名稱、型別、說明、是否必填）

### BATCH-001 每日利息計算批次

| 項目 | 內容 |
|------|------|
| **批次編號** | BATCH-001 |
| **批次名稱** | 每日利息計算 |
| **執行頻率** | 每日 |
| **執行時間** | 02:00 AM |
| **前置批次** | BATCH-000 (日終結帳) |
| **後續批次** | BATCH-002 (利息入帳) |
| **預估執行時間** | 45 分鐘 |
| **資料量** | ~200 萬帳戶 |

# [系統名稱] 軟體需求規格書（SRS）

## 文件資訊
- 版本：1.0
- 日期：YYYY-MM-DD
- 作者：[團隊名稱]
- 審查者：[審查者名稱]

## 版本歷程
| 版本 | 日期 | 變更說明 | 作者 |
|------|------|----------|------|
| 0.1 | YYYY-MM-DD | 初稿（逆向工程自動產出）| AI + [人名] |
| 0.2 | YYYY-MM-DD | 人工審查修正 | [人名] |
| 1.0 | YYYY-MM-DD | PM 驗證通過、正式發佈 | [人名] |

---

## 1. 導論
### 1.1 目的
### 1.2 範圍
### 1.3 定義與縮寫
### 1.4 參考資料

## 2. 系統概述
### 2.1 系統背景
### 2.2 系統目標
### 2.3 使用者角色與權限
### 2.4 系統架構概覽

## 3. Use Case
### 3.1 Use Case 總覽
### 3.2 UC-001 [名稱]
### 3.3 UC-002 [名稱]
...

## 4. 功能需求
### 4.1 模組 A
#### FR-A-001 [功能名稱]
#### FR-A-002 [功能名稱]
### 4.2 模組 B
...

## 5. 非功能需求
### 5.1 效能需求
### 5.2 安全性需求
### 5.3 可用性需求
### 5.4 合規性需求

## 6. 資料規格
### 6.1 ER Model
### 6.2 資料字典
### 6.3 資料流程圖

## 7. 批次流程
### 7.1 批次清單
### 7.2 BATCH-001 [名稱]
...

## 8. 介面規格
### 8.1 外部系統介面
### 8.2 API 清單

## 9. 附錄
### 9.1 需求追溯矩陣
### 9.2 術語表

[ApiController]
[Route("api/v1/[controller]")]
[Authorize]
public class LoanController : ControllerBase
{
    private readonly ILoanService _loanService;
    private readonly ILogger<LoanController> _logger;
    
    public LoanController(ILoanService loanService, ILogger<LoanController> logger)
    {
        _loanService = loanService;
        _logger = logger;
    }
    
    /// <summary>
    /// 提交貸款申請
    /// </summary>
    [HttpPost("apply")]
    [Authorize(Roles = "Teller,LoanOfficer")]
    public async Task<IActionResult> ApplyLoan([FromBody] LoanApplicationRequest request)
    {
        // 驗證年齡
        var age = DateTime.Today.Year - request.BirthDate.Year;
        if (age < 20 || age > 65)
            return BadRequest(new { Code = "LOAN_AGE_INVALID", Message = "申請人年齡需介於 20-65 歲" });
        
        // 驗證貸款金額
        if (request.LoanAmount < 100000 || request.LoanAmount > 50000000)
            return BadRequest(new { Code = "LOAN_AMOUNT_INVALID", Message = "貸款金額需介於 10 萬至 5,000 萬" });
        
        // 驗證貸款期限
        if (request.LoanTermMonths < 12 || request.LoanTermMonths > 360)
            return BadRequest(new { Code = "LOAN_TERM_INVALID", Message = "貸款期限需介於 12-360 個月" });
        
        // 檢查是否有未結清貸款
        var existingLoans = await _loanService.GetActiveLoansByCustomerIdAsync(request.CustomerId);
        if (existingLoans.Count >= 3)
            return BadRequest(new { Code = "LOAN_LIMIT_EXCEEDED", Message = "同一客戶最多持有 3 筆貸款" });
        
        // 計算月付金
        var monthlyPayment = CalculateMonthlyPayment(
            request.LoanAmount, request.InterestRate, request.LoanTermMonths);
        
        // 檢查還款能力 (月付金不得超過月收入 1/3)
        if (monthlyPayment > request.MonthlyIncome / 3)
            return BadRequest(new { Code = "LOAN_CAPACITY_INSUFFICIENT", 
                Message = "月付金超過月收入三分之一，不符合還款能力要求" });
        
        try
        {
            var result = await _loanService.CreateLoanApplicationAsync(request, User.Identity.Name);
            _logger.LogInformation("貸款申請建立成功: {ApplicationId}", result.ApplicationId);
            return Ok(result);
        }
        catch (Exception ex)
        {
            _logger.LogError(ex, "貸款申請失敗: {CustomerId}", request.CustomerId);
            return StatusCode(500, new { Code = "SYSTEM_ERROR", Message = "系統異常，請稍後重試" });
        }
    }
    
    /// <summary>
    /// 核准貸款
    /// </summary>
    [HttpPost("{applicationId}/approve")]
    [Authorize(Roles = "LoanManager")]
    public async Task<IActionResult> ApproveLoan(
        string applicationId, [FromBody] LoanApprovalRequest request)
    {
        var application = await _loanService.GetApplicationByIdAsync(applicationId);
        if (application == null)
            return NotFound("申請書不存在");
        
        if (application.Status != "PENDING")
            return BadRequest("僅待審核的申請可以核准");
        
        // 大額貸款需要更高層級核准
        if (application.LoanAmount > 10000000 && !User.IsInRole("SeniorManager"))
            return Forbid();
        
        var result = await _loanService.ApproveApplicationAsync(
            applicationId, request.ApprovalNote, User.Identity.Name);
        
        return Ok(result);
    }
    
    /// <summary>
    /// 查詢貸款申請狀態
    /// </summary>
    [HttpGet("{applicationId}")]
    public async Task<IActionResult> GetLoanApplication(string applicationId)
    {
        var application = await _loanService.GetApplicationByIdAsync(applicationId);
        if (application == null)
            return NotFound();
        return Ok(application);
    }
    
    private decimal CalculateMonthlyPayment(decimal principal, decimal annualRate, int months)
    {
        var monthlyRate = annualRate / 12 / 100;
        var payment = principal * monthlyRate * (decimal)Math.Pow((double)(1 + monthlyRate), months) 
                      / ((decimal)Math.Pow((double)(1 + monthlyRate), months) - 1);
        return Math.Round(payment, 0);
    }
}

你是一位銀行系統分析師，請分析以下 C# 貸款申請 API Controller。

請輸出以下內容：
1. API 端點清單（表格）
2. 每個端點的完整商業規則
3. 角色與權限矩陣
4. 功能需求清單（FR 格式）
5. 資料輸入/輸出規格
6. 例外處理情境

### API 端點清單

| # | Method | Route | 功能 | 權限 |
|---|--------|-------|------|------|
| 1 | POST | /api/v1/loan/apply | 提交貸款申請 | 櫃員、放款專員 |
| 2 | POST | /api/v1/loan/{id}/approve | 核准貸款 | 放款主管 |
| 3 | GET | /api/v1/loan/{id} | 查詢申請狀態 | 已授權用戶 |

### 商業規則

| 規則編號 | 規則描述 | 程式碼位置 |
|----------|----------|-----------|
| BR-LN-001 | 申請人年齡須介於 20~65 歲 | ApplyLoan:L6-8 |
| BR-LN-002 | 貸款金額範圍：10 萬 ~ 5,000 萬 | ApplyLoan:L10-12 |
| BR-LN-003 | 貸款期限範圍：12 ~ 360 個月 | ApplyLoan:L14-16 |
| BR-LN-004 | 同一客戶最多持有 3 筆未結清貸款 | ApplyLoan:L18-20 |
| BR-LN-005 | 月付金不得超過月收入的 1/3（還款能力檢核） | ApplyLoan:L25-27 |
| BR-LN-006 | 貸款金額超過 1,000 萬須由資深主管核准 | ApproveLoan:L10-11 |
| BR-LN-007 | 僅「待審核」狀態的申請可被核准 | ApproveLoan:L7-8 |

### 角色權限矩陣

| 功能 | 櫃員 | 放款專員 | 放款主管 | 資深主管 |
|------|------|---------|---------|---------|
| 提交申請 | ✅ | ✅ | ❌ | ❌ |
| 核准（≤ 1,000 萬） | ❌ | ❌ | ✅ | ✅ |
| 核准（> 1,000 萬） | ❌ | ❌ | ❌ | ✅ |
| 查詢狀態 | ✅ | ✅ | ✅ | ✅ |

### FR-LN-001 貸款申請提交

**需求描述**：
系統應提供貸款申請功能，允許櫃員或放款專員為客戶提交貸款申請。

**前置條件**：
- 操作人員已登入系統，具備「櫃員」或「放款專員」角色
- 客戶資料已存在系統中

**商業規則**：
1. 申請人年齡須介於 20 至 65 歲
2. 貸款金額須介於新台幣 10 萬元至 5,000 萬元
3. 貸款期限須介於 12 個月至 360 個月（30 年）
4. 同一客戶同時持有的未結清貸款不得超過 3 筆
5. 系統應自動計算月付金額
6. 月付金額不得超過申請人月收入的三分之一

**處理流程**：
1. 系統接收貸款申請資料
2. 驗證申請人年齡（依據出生日期計算）
3. 驗證貸款金額範圍
4. 驗證貸款期限範圍
5. 查詢申請人現有貸款筆數
6. 計算月付金金額（本息平均攤還法）
7. 驗證還款能力（月付金 vs. 月收入）
8. 建立貸款申請記錄
9. 回傳申請編號

**異常處理**：
| 異常代碼 | 說明 | 處理方式 |
|----------|------|----------|
| LOAN_AGE_INVALID | 年齡不符 | 拒絕申請 |
| LOAN_AMOUNT_INVALID | 金額範圍不符 | 拒絕申請 |
| LOAN_TERM_INVALID | 期限範圍不符 | 拒絕申請 |
| LOAN_LIMIT_EXCEEDED | 超過貸款筆數上限 | 拒絕申請 |
| LOAN_CAPACITY_INSUFFICIENT | 還款能力不足 | 拒絕申請 |
| SYSTEM_ERROR | 系統異常 | 記錄錯誤日誌，回傳系統錯誤 |

### FR-LN-002 貸款核准

**需求描述**：
系統應提供貸款核准功能，允許放款主管審核通過貸款申請。

**商業規則**：
1. 僅「待審核」狀態的申請可被核准
2. 貸款金額超過 1,000 萬元須由「資深主管」角色核准
3. 核准時須記錄核准備註與核准人員

### FR-LN-003 貸款申請狀態查詢

**需求描述**：
系統應提供貸款申請狀態查詢功能，允許已授權用戶查詢指定申請的詳細資訊。

CREATE PROCEDURE [dbo].[sp_CalculateMonthlyInterest]
    @ProcessDate DATE,
    @BatchId BIGINT OUTPUT
AS
BEGIN
    SET NOCOUNT ON;
    
    DECLARE @ErrorCount INT = 0;
    DECLARE @SuccessCount INT = 0;
    DECLARE @TotalInterest DECIMAL(18,2) = 0;
    
    -- 產生批次編號
    INSERT INTO BatchLog (BatchName, StartTime, Status)
    VALUES ('MONTHLY_INTEREST', GETDATE(), 'RUNNING');
    SET @BatchId = SCOPE_IDENTITY();
    
    BEGIN TRY
        BEGIN TRANSACTION;
        
        -- 建立暫存表儲存計算結果
        CREATE TABLE #InterestCalc (
            AccountId VARCHAR(13),
            Balance DECIMAL(18,2),
            InterestRate DECIMAL(8,4),
            DaysInMonth INT,
            InterestAmount DECIMAL(18,2),
            TaxAmount DECIMAL(18,2),
            NetInterest DECIMAL(18,2)
        );
        
        -- 計算每個帳戶的利息
        INSERT INTO #InterestCalc
        SELECT 
            a.AccountId,
            a.Balance,
            CASE 
                WHEN a.AccountType = 'SAVINGS' AND a.Balance >= 1000000 
                    THEN r.HighTierRate
                WHEN a.AccountType = 'SAVINGS' AND a.Balance >= 100000 
                    THEN r.MidTierRate
                WHEN a.AccountType = 'SAVINGS' 
                    THEN r.BaseTierRate
                WHEN a.AccountType = 'CHECKING' 
                    THEN r.CheckingRate
                ELSE 0
            END AS InterestRate,
            DAY(EOMONTH(@ProcessDate)) AS DaysInMonth,
            -- 利息 = 餘額 × 年利率 / 365 × 當月天數
            ROUND(a.Balance * 
                CASE 
                    WHEN a.AccountType = 'SAVINGS' AND a.Balance >= 1000000 
                        THEN r.HighTierRate
                    WHEN a.AccountType = 'SAVINGS' AND a.Balance >= 100000 
                        THEN r.MidTierRate
                    WHEN a.AccountType = 'SAVINGS' 
                        THEN r.BaseTierRate
                    WHEN a.AccountType = 'CHECKING' 
                        THEN r.CheckingRate
                    ELSE 0
                END / 100 / 365 * DAY(EOMONTH(@ProcessDate)), 2) AS InterestAmount,
            -- 利息所得稅 (超過 20,000 才課稅，稅率 10%)
            CASE 
                WHEN ROUND(a.Balance * 
                    CASE 
                        WHEN a.AccountType = 'SAVINGS' AND a.Balance >= 1000000 
                            THEN r.HighTierRate
                        WHEN a.AccountType = 'SAVINGS' AND a.Balance >= 100000 
                            THEN r.MidTierRate
                        WHEN a.AccountType = 'SAVINGS' 
                            THEN r.BaseTierRate
                        WHEN a.AccountType = 'CHECKING' 
                            THEN r.CheckingRate
                        ELSE 0
                    END / 100 / 365 * DAY(EOMONTH(@ProcessDate)), 2) > 20000
                THEN ROUND(a.Balance * 
                    CASE 
                        WHEN a.AccountType = 'SAVINGS' AND a.Balance >= 1000000 
                            THEN r.HighTierRate
                        WHEN a.AccountType = 'SAVINGS' AND a.Balance >= 100000 
                            THEN r.MidTierRate
                        WHEN a.AccountType = 'SAVINGS' 
                            THEN r.BaseTierRate
                        WHEN a.AccountType = 'CHECKING' 
                            THEN r.CheckingRate
                        ELSE 0
                    END / 100 / 365 * DAY(EOMONTH(@ProcessDate)), 2) * 0.1
                ELSE 0
            END AS TaxAmount,
            0 AS NetInterest  -- 稍後更新
        FROM Account a
        CROSS JOIN InterestRate r
        WHERE a.Status = 'ACTIVE'
          AND a.Balance > 0
          AND r.EffectiveDate = (
              SELECT MAX(EffectiveDate) FROM InterestRate WHERE EffectiveDate <= @ProcessDate
          );
        
        -- 計算淨利息
        UPDATE #InterestCalc
        SET NetInterest = InterestAmount - TaxAmount;
        
        -- 寫入利息明細表
        INSERT INTO InterestDetail (AccountId, ProcessDate, Balance, InterestRate, 
            DaysInMonth, InterestAmount, TaxAmount, NetInterest, BatchId)
        SELECT AccountId, @ProcessDate, Balance, InterestRate,
            DaysInMonth, InterestAmount, TaxAmount, NetInterest, @BatchId
        FROM #InterestCalc;
        
        -- 更新帳戶餘額（加上淨利息）
        UPDATE a
        SET a.Balance = a.Balance + ic.NetInterest,
            a.LastInterestDate = @ProcessDate
        FROM Account a
        JOIN #InterestCalc ic ON a.AccountId = ic.AccountId;
        
        -- 統計
        SELECT @SuccessCount = COUNT(*), @TotalInterest = SUM(NetInterest) 
        FROM #InterestCalc;
        
        COMMIT TRANSACTION;
        
        -- 更新批次日誌
        UPDATE BatchLog 
        SET EndTime = GETDATE(), 
            Status = 'COMPLETED',
            SuccessCount = @SuccessCount,
            ErrorCount = @ErrorCount,
            TotalAmount = @TotalInterest
        WHERE BatchId = @BatchId;
        
    END TRY
    BEGIN CATCH
        IF @@TRANCOUNT > 0
            ROLLBACK TRANSACTION;
        
        SET @ErrorCount = 1;
        
        UPDATE BatchLog 
        SET EndTime = GETDATE(), 
            Status = 'FAILED',
            ErrorCount = @ErrorCount,
            ErrorMessage = ERROR_MESSAGE()
        WHERE BatchId = @BatchId;
        
        THROW;
    END CATCH
    
    DROP TABLE IF EXISTS #InterestCalc;
END;

你是一位銀行存款業務的系統分析師。
請分析以下「每月利息計算」Stored Procedure，並產出：

1. SP 概述（目的、執行頻率、影響範圍）
2. 完整的利息計算公式與分級規則
3. 稅務處理邏輯
4. 資料流圖（輸入的表、輸出的表）
5. 完整的商業規則清單
6. 功能需求（FR 格式）
7. 批次流程圖（Mermaid）

### FR-INT-001 每月利息計算

**需求描述**：
系統應每月自動計算所有啟用帳戶的利息，並直接入帳。

**執行條件**：
- 月底結息日觸發（人工或排程）
- 需傳入處理日期

**利率分級規則**：
| 帳戶類型 | 餘額條件 | 適用利率層級 |
|----------|----------|-------------|
| 活期儲蓄 (SAVINGS) | ≥ 100 萬 | 高額利率 (HighTierRate) |
| 活期儲蓄 (SAVINGS) | ≥ 10 萬 且 < 100 萬 | 中額利率 (MidTierRate) |
| 活期儲蓄 (SAVINGS) | < 10 萬 | 基本利率 (BaseTierRate) |
| 活期存款 (CHECKING) | 不限 | 活存利率 (CheckingRate) |

**利息計算公式**：
$$
\text{利息} = \text{帳戶餘額} \times \frac{\text{年利率}}{365} \times \text{當月天數}
$$

**稅務處理**：
| 條件 | 稅率 | 說明 |
|------|------|------|
| 利息 > 20,000 元 | 10% | 利息所得稅 |
| 利息 ≤ 20,000 元 | 0% | 免稅 |

$$
\text{淨利息} = \text{利息} - \text{稅額}
$$

**處理流程**：
1. 建立批次執行紀錄
2. 取得適用利率（以處理日期為準，取最新生效的利率）
3. 篩選符合條件的帳戶（狀態 = 啟用，餘額 > 0）
4. 根據帳戶類型與餘額，決定適用利率
5. 計算每帳戶利息金額
6. 計算稅額（超過 2 萬元部分課稅 10%）
7. 計算淨利息（利息 - 稅額）
8. 寫入利息明細表
9. 更新帳戶餘額（加上淨利息）
10. 統計筆數與總金額
11. 更新批次日誌

**異常處理**：
- 若任何帳戶計算失敗，整批回滾
- 記錄錯誤訊息於批次日誌

**涉及資料表**：
| 表名 | 操作 | 說明 |
|------|------|------|
| Account | READ | 讀取帳戶餘額與狀態 |
| Account | UPDATE | 更新餘額與最後計息日 |
| InterestRate | READ | 讀取利率參數 |
| InterestDetail | INSERT | 寫入利息明細 |
| BatchLog | INSERT/UPDATE | 批次執行紀錄 |

public class OverdueNotificationJob : IJob
{
    public async Task Execute(IJobExecutionContext context)
    {
        var overdueAccounts = await _repo.GetOverdueAccountsAsync(
            DateTime.Today, gracePeriodDays: 7);
        
        foreach (var account in overdueAccounts)
        {
            var daysPastDue = (DateTime.Today - account.DueDate).Days;
            
            NotificationType notifType;
            if (daysPastDue <= 30)
                notifType = NotificationType.FirstReminder;
            else if (daysPastDue <= 60)
                notifType = NotificationType.SecondWarning;
            else if (daysPastDue <= 90)
                notifType = NotificationType.FinalNotice;
            else
            {
                notifType = NotificationType.CollectionTransfer;
                await _loanService.TransferToCollectionAsync(account.AccountId);
            }
            
            // 避免重複發送
            if (!await _notifRepo.HasSentTodayAsync(account.AccountId, notifType))
            {
                await _notifService.SendAsync(account, notifType);
                await _notifRepo.LogNotificationAsync(account.AccountId, notifType);
            }
        }
    }
}

分析此批次程式，以商業需求角度產出：
1. 批次功能描述
2. 通知分級規則
3. 催收移轉邏輯
4. 完整流程圖

### FR-NOTIF-001 逾期帳款通知批次

**需求描述**：
系統應每日自動檢查逾期帳戶，根據逾期天數發送不同等級的通知。

**通知分級規則**：
| 逾期天數 | 通知類型 | 動作 |
|----------|----------|------|
| 7 ~ 30 天 | 第一次催繳提醒 | 發送提醒通知 |
| 31 ~ 60 天 | 第二次警告 | 發送警告通知 |
| 61 ~ 90 天 | 最終通知 | 發送最終通知 |
| > 90 天 | 催收移轉 | 移轉至催收部門 + 發送通知 |

**防重複機制**：
- 同一帳戶同一類型的通知，每日只發送一次

**寬限期**：
- 到期日後 7 天內不列入逾期（寬限期）

請將以下三組分析結果，組裝為符合 IEEE 830 標準的 SRS 文件：
1. 貸款申請（FR-LN-001 ~ 003）
2. 每月利息計算（FR-INT-001）
3. 逾期通知（FR-NOTIF-001）

請：
- 統一編號
- 加入系統概述
- 加入非功能需求
- 加入資料模型
- 加入需求追溯矩陣

請評估以下已推導出的需求列表，為每條需求標記信心度（高/中/低），
並說明理由。

特別關注：
1. 是否有 Dead Code 被誤判為需求？
2. 是否有技術限制被誤判為業務需求？
3. 是否有遺漏的隱含需求？

## 逆向工程需求驗證會議

**日期**：YYYY-MM-DD
**與會者**：[工程師]、[PM]、[使用者代表]

### 議程
1. 模組概述（5 分鐘）
2. 逐條需求確認（每條 3-5 分鐘）
3. 待確認事項彙整
4. 後續行動（Action Items）

### 需求確認記錄
| 需求編號 | 需求描述 | 狀態 | 備註 |
|----------|----------|------|------|
| FR-001 | 帳戶轉帳 | ✅ 確認 | |
| FR-002 | 大額交易核准 | ⚠️ 需修正 | 金額門檻應為 500 萬，非 1,000 萬 |
| FR-003 | 國際匯款 | ❌ 刪除 | 此功能已不使用 |
| FR-004 | ??? | 📝 新增 | 使用者提出遺漏的功能 |

repository/
├── docs/
│   ├── srs/
│   │   ├── v0.1-auto-generated/    # Copilot 自動產出版本
│   │   │   ├── module-account.md
│   │   │   ├── module-loan.md
│   │   │   └── module-batch.md
│   │   ├── v0.2-reviewed/          # 人工審查版本
│   │   └── v1.0-approved/          # 正式核准版本
│   ├── analysis/
│   │   ├── code-inventory.md       # 程式碼盤點清單
│   │   ├── business-rules.md       # 商業規則彙整
│   │   └── traceability-matrix.md  # 追溯矩陣
│   └── meeting-notes/              # 驗證會議記錄

# 分析階段
analysis(account): 帳戶管理模組程式碼盤點
analysis(account): 帳戶開戶 API 需求推導
analysis(loan): sp_CalculateInterest SP 分析

# 文件產出階段
docs(srs): 新增帳戶管理 FR-ACC-001 ~ FR-ACC-010
docs(srs): 新增非功能需求 NFR-001 ~ NFR-005

# 審查修正階段
review(account): 修正 FR-ACC-003 金額上限（500萬→1000萬）
review(loan): 刪除 FR-LN-005（已廢棄功能）

# 驗證通過
approved(srs): PM 確認帳戶模組需求 v1.0

請檢查已產出的 SRS 文件，找出以下問題：
1. 是否有技術實作細節被誤當為業務需求？
2. 是否有明顯遺漏的功能（從 API 端點數量推估）？
3. 同一條需求是否在不同地方有衝突的描述？
4. 是否有功能的互動關係未被記錄？

請列出所有發現，並提供修正建議。

# .github/copilot-code-review.yml
reviews:
  - path: "docs/srs/**/*.md"
    instructions: |
      這是逆向工程產出的 SRS 文件。請審查以下項目：
      1. 需求編號是否連續且格式正確（FR-[模組]-XXX）
      2. 每條功能需求是否包含：描述、前置條件、商業規則、驗收條件
      3. 商業規則數值是否前後一致
      4. 是否有模糊描述（如「適當的」、「足夠的」等無法量化的用語）
      5. 是否有技術實作細節被誤當成業務需求
      6. Mermaid 圖表語法是否正確

[使用 RE-系統概覽 Space 作為上下文]

根據此系統的架構概覽，請分析以下新發現的 Service 類別
屬於哪個業務模組，並與已分析的模組清單交叉比對是否有遺漏。

請根據以下 SRS 需求，設計 Spring Boot REST API：

需求：FR-LN-001 貸款申請提交
[貼上 FR 內容]

請產出：
1. Controller 類別（包含完整 Annotation）
2. Request DTO
3. Response DTO
4. Service 介面
5. 商業規則驗證邏輯
6. API 文件（OpenAPI / Swagger）

使用 Clean Architecture 分層。

// Controller 層
@RestController
@RequestMapping("/api/v1/loans")
@RequiredArgsConstructor
public class LoanController {
    
    private final LoanApplicationService loanService;
    
    @PostMapping("/apply")
    @PreAuthorize("hasAnyRole('TELLER', 'LOAN_OFFICER')")
    public ResponseEntity<LoanApplicationResponse> applyLoan(
            @Valid @RequestBody LoanApplicationRequest request,
            @AuthenticationPrincipal UserDetails user) {
        
        var result = loanService.createApplication(request, user.getUsername());
        return ResponseEntity.ok(result);
    }
    
    @PostMapping("/{applicationId}/approve")
    @PreAuthorize("hasRole('LOAN_MANAGER')")
    public ResponseEntity<LoanApprovalResponse> approveLoan(
            @PathVariable String applicationId,
            @Valid @RequestBody LoanApprovalRequest request,
            @AuthenticationPrincipal UserDetails user) {
        
        var result = loanService.approveApplication(
            applicationId, request, user.getUsername());
        return ResponseEntity.ok(result);
    }
}

// Request DTO（含驗證）
public record LoanApplicationRequest(
    @NotBlank String customerId,
    @NotNull LocalDate birthDate,
    @DecimalMin("100000") @DecimalMax("50000000") BigDecimal loanAmount,
    @Min(12) @Max(360) int loanTermMonths,
    @Positive BigDecimal interestRate,
    @Positive BigDecimal monthlyIncome
) {}

根據以下 SRS 的功能需求清單，請建議微服務拆分方案：

1. 識別 Bounded Context（限界上下文）
2. 定義每個微服務的職責
3. 識別服務間的通訊模式（同步 API / 非同步 Event）
4. 定義每個服務獨立的資料庫 Schema
5. 畫出微服務架構圖（Mermaid）

根據以下 SRS 文件，請用 DDD 方法建模：

1. 識別 Ubiquitous Language（統一語言）
2. 定義 Bounded Context（限界上下文）
3. 識別 Aggregate（聚合）與 Aggregate Root（聚合根）
4. 識別 Entity 與 Value Object
5. 定義 Domain Event（領域事件）
6. 設計 Context Map（上下文映射圖）

請用 Mermaid 畫出 Context Map 與 Aggregate 圖。

src/main/java/com/bank/loan/
├── domain/                          # Enterprise Business Rules
│   ├── model/
│   │   ├── LoanApplication.java     # Aggregate Root
│   │   ├── LoanStatus.java          # Enum
│   │   └── Money.java               # Value Object
│   ├── service/
│   │   └── InterestCalculator.java   # Domain Service
│   └── event/
│       └── LoanApprovedEvent.java    # Domain Event
├── application/                     # Application Business Rules
│   ├── port/
│   │   ├── in/
│   │   │   └── ApplyLoanUseCase.java
│   │   └── out/
│   │       └── LoanRepository.java
│   └── service/
│       └── LoanApplicationService.java
├── adapter/                         # Interface Adapters
│   ├── in/
│   │   └── web/
│   │       ├── LoanController.java
│   │       ├── LoanRequest.java
│   │       └── LoanResponse.java
│   └── out/
│       └── persistence/
│           ├── LoanJpaEntity.java
│           ├── LoanJpaRepository.java
│           └── LoanPersistenceAdapter.java
└── config/                          # Configuration
    └── BeanConfig.java

## 自動生成：帳戶管理模組 Spring Boot 骨架

### 任務描述
根據 `docs/srs/module-account.md` 中的 SRS 文件，
自動生成帳戶管理模組的 Spring Boot 程式碼骨架。

### 生成範圍
1. Controller 層（含完整 Annotation、Swagger 文件）
2. Service 介面（含 JavaDoc）
3. Request / Response DTO（含 Validation）
4. Repository 介面
5. Domain Entity
6. 單元測試骨架

### 技術規範
- Java 21 + Spring Boot 3.2
- 使用 Clean Architecture 分層（參考 `docs/architecture.md`）
- 需求編號標記在對應方法的 JavaDoc 中
- 使用 `@Tag` 標記對應的 FR 編號

### 品質要求
- 所有 Controller 方法必須有 `@Operation` 描述
- 所有 DTO 欄位必須有 Validation Annotation
- 所有 Service 方法必須有對應的測試方法（空實作）

## 自動遷移：sp_Account_Transfer → TransferService

### 來源
SP 定義：`docs/analysis/sp/sp_Account_Transfer.md`
SRS 需求：FR-TXN-001 ~ FR-TXN-006

### 目標
將 SP 邏輯遷移至 `account-service` 的 Domain Service

### 遷移規則
1. SQL 查詢 → JPA Repository 方法
2. IF/ELSE 邏輯 → Domain Service 方法
3. Transaction 控制 → @Transactional
4. Error Code → 自定義 Exception + ErrorCode Enum
5. 保留所有商業規則，加上 BR 編號註解

### 驗證
- 執行 `mvn test` 確保編譯通過
- 檢查所有 FR 需求都有對應程式碼

# .github/hooks/copilot-setup.sh 中配置的驗證步驟

# 1. 編譯檢查
mvn compile -q

# 2. SRS 追溯檢查（自定義腳本）
python scripts/check_srs_traceability.py \
  --srs docs/srs/ \
  --source src/main/java/

# 3. 格式檢查
npx markdownlint docs/srs/**/*.md

請用不超過 100 字摘要以下 [語言] 類別的功能。
系統背景：[背景說明]
類別名稱：[ClassName]

請回答：
1. 這個類別的主要職責是什麼？
2. 它屬於系統的哪個模組/功能？
3. 它有幾個公開方法，各做什麼？

以下檔案清單屬於同一模組。
請分析整個模組的功能範圍：

檔案清單：
[列出檔案名稱]

請提供：
1. 模組功能概述（一段話）
2. 核心功能清單（表格）
3. 模組與其他模組的依賴關係
4. 推估的業務功能範圍

請分析此專案的完整目錄結構，提供系統全景摘要：

1. 專案類型（Web API / Console / Service）
2. 技術棧（Framework、Library、Database）
3. 模組清單與估算規模
4. 架構模式（MVC / MVVM / Clean Architecture）
5. 推估的業務領域

請逐行分析以下方法的邏輯：

方法名稱：[MethodName]
系統背景：[背景]

對每一段邏輯，提供：
| 行號範圍 | 技術動作 | 商業意義 | 類型(驗證/計算/查詢/更新) |

請列出以下程式碼中所有的條件分支（if/else/switch/三元運算）：

格式：
| # | 條件表達式 | True 分支動作 | False 分支動作 | 商業規則（白話文） |

請追蹤以下程式碼中資料的完整流動路徑：

從方法輸入 → 內部處理 → 資料庫操作 → 方法輸出

格式：
[輸入] → [轉換1] → [轉換2] → ... → [輸出]

特別標記：
- 資料驗證點
- 資料轉換點
- 資料持久化點

請將以下技術分析結果轉換為功能需求：

技術分析：
[貼上分析結果]

每條需求需包含：
- 需求編號（FR-[MODULE]-XXX）
- 需求名稱
- 需求描述（用非技術語言）
- 前置條件
- 處理步驟
- 商業規則
- 驗收條件（Given-When-Then）

請將以下 Stored Procedure 的分析結果，
轉換為批次處理需求規格：

需包含：
- 批次名稱
- 執行頻率
- 前置依賴
- 處理流程（含流程圖）
- 輸入/輸出
- 計算公式
- 異常處理
- 預估執行時間

請根據以下功能需求，生成 User Story：

格式：
**作為** [角色]
**我希望** [功能]
**以便** [商業價值]

**驗收條件**：
- Given [前提]
- When [操作]
- Then [預期結果]

請根據以下已分析的需求清單，
生成 SRS 文件的 [章節名稱] 章節。

格式要求：
- 使用 IEEE 830 結構
- 需求編號按模組分類
- 每條需求包含完整描述
- 商業規則以表格呈現
- 提供 Use Case Diagram（Mermaid）

請根據以下 Entity 類別 / 資料表定義，
生成 ER Diagram（Mermaid erDiagram 語法）。

需包含：
- 所有表的 PK、FK
- 表之間的關聯類型
- 每個欄位的中文說明
- 資料字典（獨立表格）

請根據以下 Controller 分析結果，
生成 OpenAPI 3.0 規格的 API 文件（YAML 格式）。

需包含：
- 端點清單
- Request / Response Schema
- 錯誤碼定義
- 權限要求
- 範例值

請檢查以下 SRS 文件是否完整：

1. 所有 Controller 是否都有對應的 FR？
2. 所有 SP 是否都有對應的需求？
3. 所有 Batch Job 是否都有對應的需求？
4. 是否有遺漏的非功能需求？
5. 是否有遺漏的介面需求？
6. 資料模型是否涵蓋所有表？

列出所有缺口與建議。

請檢查以下 SRS 文件的一致性：

1. 相同概念是否使用一致的術語？
2. 不同需求之間是否有矛盾？
3. 商業規則數值是否前後一致？
4. 角色權限定義是否一致？
5. 資料欄位名稱是否與 ER Model 一致？

請檢查以下需求是否都可測試：

針對每條需求：
- 能否定義明確的測試案例？
- 驗收條件是否可量化？
- 是否有模糊描述需要釐清？

對不可測試的需求，提供修改建議。

<#
.SYNOPSIS
    自動盤點 C# 專案結構，產出 Markdown 報告
.DESCRIPTION
    掃描指定目錄的所有 C# 檔案，分類為 Controller / Service / Repository / Entity
#>
param(
    [Parameter(Mandatory)]
    [string]$ProjectPath,
    [string]$OutputFile = "code-inventory.md"
)

$report = @"
# 程式碼盤點報告

> 產出日期：$(Get-Date -Format 'yyyy-MM-dd HH:mm')
> 掃描路徑：$ProjectPath

## 1. Controller 清單

| # | 檔案名稱 | 路徑 | 行數 |
|---|----------|------|------|
"@

$controllers = Get-ChildItem -Path $ProjectPath -Recurse -Filter "*Controller.cs"
$i = 1
foreach ($file in $controllers) {
    $lineCount = (Get-Content $file.FullName).Count
    $relativePath = $file.FullName.Replace($ProjectPath, ".")
    $report += "`n| $i | $($file.Name) | $relativePath | $lineCount |"
    $i++
}

$report += @"

## 2. Service 清單

| # | 檔案名稱 | 路徑 | 行數 |
|---|----------|------|------|
"@

$services = Get-ChildItem -Path $ProjectPath -Recurse -Filter "*Service.cs"
$i = 1
foreach ($file in $services) {
    $lineCount = (Get-Content $file.FullName).Count
    $relativePath = $file.FullName.Replace($ProjectPath, ".")
    $report += "`n| $i | $($file.Name) | $relativePath | $lineCount |"
    $i++
}

$report += @"

## 3. 統計摘要

| 類型 | 數量 |
|------|------|
| Controller | $($controllers.Count) |
| Service | $($services.Count) |
| 總計 | $($controllers.Count + $services.Count) |
"@

$report | Out-File -FilePath $OutputFile -Encoding utf8
Write-Host "盤點報告已產出：$OutputFile"

-- 產出 SP 盤點清單（可匯出為 CSV）
SELECT 
    ROW_NUMBER() OVER (ORDER BY s.name, o.name) AS '#',
    s.name AS [Schema],
    o.name AS [SP名稱],
    CAST(o.create_date AS DATE) AS [建立日期],
    CAST(o.modify_date AS DATE) AS [最後修改],
    LEN(sm.definition) AS [字元數],
    CASE 
        WHEN LEN(sm.definition) > 10000 THEN '高'
        WHEN LEN(sm.definition) > 3000 THEN '中'
        ELSE '低'
    END AS [複雜度],
    CASE 
        WHEN sm.definition LIKE '%INSERT%' AND sm.definition LIKE '%CURSOR%' THEN '批次寫入'
        WHEN sm.definition LIKE '%INSERT%' THEN '寫入'
        WHEN sm.definition LIKE '%UPDATE%' THEN '更新'
        WHEN sm.definition LIKE '%DELETE%' THEN '刪除'
        ELSE '查詢'
    END AS [操作類型]
FROM sys.objects o
JOIN sys.schemas s ON o.schema_id = s.schema_id
JOIN sys.sql_modules sm ON o.object_id = sm.object_id
WHERE o.type = 'P'
ORDER BY s.name, o.name;

## 逆向工程分析任務分配

### Sprint 1（Week 1-2）：核心交易模組
| 任務 | 負責人 | 範圍 | 預估時間 | 狀態 |
|------|--------|------|----------|------|
| 帳戶管理 API (10 支) | 工程師 A | AccountController | 3 天 | 進行中 |
| 帳戶相關 SP (15 支) | 工程師 B | sp_Account_* | 4 天 | 未開始 |
| 交易處理 API (8 支) | 工程師 C | TransactionController | 3 天 | 未開始 |

### Sprint 2（Week 3-4）：批次與報表
| 任務 | 負責人 | 範圍 | 預估時間 | 狀態 |
|------|--------|------|----------|------|
| 日批程式 (5 支) | 工程師 A | BatchJobs/* | 3 天 | 未開始 |
| 月批程式 (3 支) | 工程師 B | MonthlyBatch/* | 2 天 | 未開始 |
| 報表 SP (20 支) | 工程師 C | sp_Report_* | 5 天 | 未開始 |

<#
.SYNOPSIS
    將分散的分析結果自動組裝為完整 SRS 文件
#>
param(
    [string]$AnalysisDir = "./docs/analysis",
    [string]$TemplateFile = "./docs/srs/template.md",
    [string]$OutputFile = "./docs/srs/SRS_v0.1.md"
)

# 讀取模板
$template = Get-Content $TemplateFile -Raw

# 組裝各模組的分析結果
$modules = Get-ChildItem -Path $AnalysisDir -Filter "FR-*.md" | Sort-Object Name

$functionalRequirements = ""
foreach ($module in $modules) {
    $content = Get-Content $module.FullName -Raw
    $functionalRequirements += "`n`n$content"
}

# 替換模板占位符
$srs = $template -replace '{{FUNCTIONAL_REQUIREMENTS}}', $functionalRequirements
$srs = $srs -replace '{{GENERATION_DATE}}', (Get-Date -Format 'yyyy-MM-dd')
$srs = $srs -replace '{{VERSION}}', 'v0.1 (Auto-generated)'

# 輸出
$srs | Out-File -FilePath $OutputFile -Encoding utf8
Write-Host "SRS 文件已組裝完成：$OutputFile"

<#
.SYNOPSIS
    檢查 SRS 文件的完整性
#>
param(
    [Parameter(Mandatory)]
    [string]$SrsFile
)

$content = Get-Content $SrsFile -Raw
$issues = @()

# 檢查是否有「待確認」標記
$pendingCount = ([regex]::Matches($content, '待確認|TODO|TBD|待釐清')).Count
if ($pendingCount -gt 0) {
    $issues += "⚠️ 發現 $pendingCount 處待確認項目"
}

# 檢查 FR 編號連續性
$frNumbers = [regex]::Matches($content, 'FR-\w+-(\d+)') | 
    ForEach-Object { [int]$_.Groups[1].Value } | Sort-Object
# （簡化檢查）

# 檢查是否有空的章節
$emptyChapters = [regex]::Matches($content, '#{2,3}\s+.+\n\s*\n#{2,3}')
if ($emptyChapters.Count -gt 0) {
    $issues += "⚠️ 發現 $($emptyChapters.Count) 個空章節"
}

# 輸出報告
if ($issues.Count -eq 0) {
    Write-Host "✅ SRS 文件品質檢查通過" -ForegroundColor Green
} else {
    Write-Host "⚠️ SRS 文件品質問題：" -ForegroundColor Yellow
    $issues | ForEach-Object { Write-Host "  $_" }
}

# .github/workflows/srs-assembly.yml
name: SRS Auto-Assembly

on:
  push:
    branches:
      - 'analysis/**'
    paths:
      - 'docs/analysis/FR-*.md'

jobs:
  assemble-srs:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: 組裝 SRS 文件
        run: |
          pwsh scripts/assemble-srs.ps1 \
            -AnalysisDir docs/analysis \
            -TemplateFile docs/srs/template.md \
            -OutputFile docs/srs/SRS_latest.md
      
      - name: 品質檢查
        run: |
          pwsh scripts/check-srs-quality.ps1 \
            -SrsFile docs/srs/SRS_latest.md
      
      - name: Markdown Lint
        run: npx markdownlint docs/srs/SRS_latest.md
      
      - name: 建立 SRS 更新 PR
        uses: peter-evans/create-pull-request@v6
        with:
          title: "docs(srs): 自動組裝 SRS 更新"
          body: |
            ## SRS 自動更新
            
            觸發原因：analysis 分支有新的分析結果合併
            
            ### 變更模組
            ${{ steps.changes.outputs.modules }}
            
            ### 品質報告
            ${{ steps.quality.outputs.report }}
          branch: srs/auto-assembly
          labels: srs, auto-generated

#!/bin/bash
# scripts/create-analysis-issues.sh
# 根據程式碼盤點結果，批次建立分析 Issue

MODULES=("Account" "Loan" "Transaction" "Batch" "Report")

for module in "${MODULES[@]}"; do
  gh issue create \
    --title "逆向分析：${module} 模組" \
    --body-file "docs/templates/analysis-issue-${module}.md" \
    --label "reverse-engineering,srs" \
    --assignee "@copilot"
  
  echo "✅ 已建立 ${module} 模組分析 Issue 並指派給 Copilot"
  sleep 2  # 避免 Rate Limiting
done

#!/usr/bin/env python3
"""
從 SRS 文件自動生成需求追溯矩陣 (RTM)
"""
import re
import os
from pathlib import Path

def extract_requirements(srs_dir: str) -> list[dict]:
    """從 SRS Markdown 檔案中擷取需求編號與描述"""
    requirements = []
    for md_file in Path(srs_dir).glob("**/*.md"):
        content = md_file.read_text(encoding="utf-8")
        # 匹配 FR-XXX-NNN 格式
        pattern = r'(FR-\w+-\d+)\s*[：:]\s*(.+?)(?:\n|$)'
        for match in re.finditer(pattern, content):
            requirements.append({
                "id": match.group(1),
                "description": match.group(2).strip(),
                "source_file": str(md_file.relative_to(srs_dir)),
            })
    return requirements

def find_source_references(src_dir: str, req_id: str) -> list[str]:
    """在原始碼中尋找需求編號的引用"""
    references = []
    for src_file in Path(src_dir).rglob("*.*"):
        if src_file.suffix in ('.cs', '.java', '.sql'):
            try:
                content = src_file.read_text(encoding="utf-8")
                if req_id in content:
                    references.append(str(src_file))
            except (UnicodeDecodeError, PermissionError):
                pass
    return references

def generate_rtm(srs_dir: str, src_dir: str, output: str):
    """生成追溯矩陣 Markdown"""
    reqs = extract_requirements(srs_dir)
    
    lines = [
        "# 需求追溯矩陣 (RTM)",
        "",
        f"> 自動生成日期：{__import__('datetime').date.today()}",
        "",
        "| 需求編號 | 需求描述 | SRS 來源 | 程式碼引用 | 狀態 |",
        "|----------|----------|----------|-----------|------|",
    ]
    
    for req in sorted(reqs, key=lambda x: x["id"]):
        refs = find_source_references(src_dir, req["id"])
        ref_str = ", ".join(refs[:3]) if refs else "—"
        status = "✅ 已追溯" if refs else "⚠️ 待追溯"
        lines.append(
            f"| {req['id']} | {req['description'][:40]} | "
            f"{req['source_file']} | {ref_str} | {status} |"
        )
    
    Path(output).write_text("\n".join(lines), encoding="utf-8")
    print(f"✅ RTM 已生成：{output}")

if __name__ == "__main__":
    generate_rtm("docs/srs", "src", "docs/srs/traceability-matrix.md")