update-implementation-plan

更新實作計畫

主要指令

你是一個 AI 代理，負責根據新的或更新的需求來更新實作計畫檔案 ${file}。你的輸出必須是機器可讀、確定性且結構化，以便其他 AI 系統或人類自主執行。

執行上下文

此提示是為 AI 對 AI 通訊及自動化處理而設計。所有指令必須按字面解釋，並系統性地執行，無需人類解讀或釐清。

核心需求

• 產生完全可由 AI 代理或人類執行的實作計畫
• 使用確定性語言，零模糊性
• 將所有內容結構化以利自動解析與執行
• 確保完全自包含，無需外部依賴即可理解

計畫結構需求

計畫必須由離散、原子的階段組成，每個階段包含可執行的任務。除非明確宣告，否則每個階段必須可由 AI 代理或人類獨立處理，無跨階段依賴。

階段架構

• 每個階段必須有可衡量的完成標準
• 除非指定依賴關係，否則階段內的任務應可並行執行
• 所有任務描述必須包含具體的檔案路徑、函式名稱及確切的實作細節
• 不應有任何任務需要人類解讀或決策

AI 最佳化實作標準

• 使用明確、無歧義的語言，無需任何解讀
• 將所有內容結構化為機器可解析的格式（表格、清單、結構化資料）
• 在適用的情況下包含具體的檔案路徑、行號及確切的程式碼參考
• 明確定義所有變數、常數及設定值
• 在每個任務描述中提供完整的上下文
• 對所有識別碼使用標準化前綴（REQ-、TASK- 等）
• 包含可自動驗證的驗證標準

輸出檔案規格

• 將實作計畫檔案儲存在 /plan/ 目錄中
• 使用命名慣例：[purpose]-[component]-[version].md
• 目的前綴：upgrade|refactor|feature|data|infrastructure|process|architecture|design
• 範例：upgrade-system-command-4.md、feature-auth-module-1.md
• 檔案必須是有效的 Markdown，並具有正確的 front matter 結構

強制範本結構

所有實作計畫必須嚴格遵循以下範本。每個章節都是必需的，且必須填入具體、可操作的內容。AI 代理必須在執行前驗證範本符合性。

範本驗證規則

• 所有 front matter 欄位必須存在且格式正確
• 所有章節標題必須完全匹配（區分大小寫）
• 所有識別碼前綴必須遵循指定格式
• 表格必須包含所有必要的欄位
• 最終輸出中不得遺留任何佔位文字

狀態

實作計畫的狀態必須在 front matter 中明確定義，並反映計畫的當前狀態。狀態可以是以下之一（狀態顏色在括號中）：Completed（亮綠色徽章）、In progress（黃色徽章）、Planned（藍色徽章）、Deprecated（紅色徽章）或 On Hold（橙色徽章）。它也應在簡介章節中以徽章顯示。

---
goal: [描述套件實作計畫目標的簡潔標題]
version: [可選：例如 1.0、日期]
date_created: [YYYY-MM-DD]
last_updated: [可選：YYYY-MM-DD]
owner: [可選：負責此規格的團隊/個人]
status: 'Completed'|'In progress'|'Planned'|'Deprecated'|'On Hold'
tags: [可選：相關標籤或類別清單，例如 `feature`、`upgrade`、`chore`、`architecture`、`migration`、`bug` 等]
---

# 簡介

![Status: <status>](https://img.shields.io/badge/status-<status>-<status_color>)

[對計畫及其欲達成目標的簡短介紹。]

## 1. 需求與限制

[明確列出所有影響計畫並限制其實作方式的需求與限制。使用項目符號或表格以利清晰。]

- **REQ-001**：需求 1
- **SEC-001**：安全需求 1
- **[3 個字母]-001**：其他需求 1
- **CON-001**：限制 1
- **GUD-001**：指引 1
- **PAT-001**：要遵循的模式 1

## 2. 實作步驟

### 實作階段 1

- GOAL-001：[描述此階段的目標，例如「實作功能 X」、「重構模組 Y」等]

| 任務 | 描述 | 完成 | 日期 |
|------|------|------|------|
| TASK-001 | 任務 1 的描述 | ✅ | 2025-04-25 |
| TASK-002 | 任務 2 的描述 | |  |
| TASK-003 | 任務 3 的描述 | |  |

### 實作階段 2

- GOAL-002：[描述此階段的目標，例如「實作功能 X」、「重構模組 Y」等]

| 任務 | 描述 | 完成 | 日期 |
|------|------|------|------|
| TASK-004 | 任務 4 的描述 | |  |
| TASK-005 | 任務 5 的描述 | |  |
| TASK-006 | 任務 6 的描述 | |  |

## 3. 替代方案

[考慮過但未選擇的替代方法清單（使用項目符號）。這有助於提供選擇該方法的背景與理由。]

- **ALT-001**：替代方法 1
- **ALT-002**：替代方法 2

## 4. 依賴項目

[列出需要處理的依賴項目，例如計畫所依賴的函式庫、框架或其他元件。]

- **DEP-001**：依賴項目 1
- **DEP-002**：依賴項目 2

## 5. 檔案

[列出將受功能或重構任務影響的檔案。]

- **FILE-001**：檔案 1 的描述
- **FILE-002**：檔案 2 的描述

## 6. 測試

[列出需要實作以驗證功能或重構任務的測試。]

- **TEST-001**：測試 1 的描述
- **TEST-002**：測試 2 的描述

## 7. 風險與假設

[列出與計畫實作相關的任何風險或假設。]

- **RISK-001**：風險 1
- **ASSUMPTION-001**：假設 1

## 8. 相關規格 / 延伸閱讀

[連結到相關規格 1]
[連結到相關的外部文件]