universal-dev-standards 5.14.0 → 5.16.0

package/bundled/locales/zh-TW/skills/journey-test-assistant/SKILL.md

@@ -0,0 +1,222 @@
+---
+name: journey-test-assistant
+source: ../../../../skills/journey-test-assistant/SKILL.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-05-28
+scope: partial
+description: "[UDS] 從專案描述生成連貫使用者旅程測試計畫（TESTPLAN）與 E2E 骨架"
+allowed-tools: Read, Write, Grep, Glob
+argument-hint: "[專案描述 | --analyze | --archetype A1|A2|A3]"
+status: stable
+---
+
+# 旅程測試助手
+
+> **語言**: [English](../../../../skills/journey-test-assistant/SKILL.md) | 繁體中文
+
+從專案描述生成連貫的使用者旅程測試計畫（TESTPLAN-NNN.md）與對應的 E2E 骨架，讓每個新專案從第一天起就擁有完整測試旅程。
+
+## 選擇正確的測試 Skill
+
+| 需求 | 使用 |
+|------|------|
+| 單元測試 / TDD 紅綠重構 | `/tdd-assistant` |
+| BDD 場景 / Given-When-Then | `/bdd-assistant` |
+| 驗收測試 / ATDD / 使用者故事 | `/atdd-assistant` |
+| E2E / Playwright / 瀏覽器測試 | `/e2e-assistant` |
+| 合約測試 / API consumer-driven | `/contract-test-assistant` |
+| 測試覆蓋率差距分析 | `/test-coverage-assistant` |
+| 使用者旅程測試計畫 | `/journey-test-assistant` |
+| 一般測試策略 / 測試金字塔 | `/testing-guide` |
+
+## 與 /e2e 的差異
+
+| 維度 | /e2e | /journey-test |
+|------|------|--------------|
+| 組織單位 | 單一 XSPEC / AC | 跨 Story 的使用者旅程 |
+| 測試結構 | 隔離、獨立 | 連貫、狀態共享 |
+| 產物 | `*.spec.ts` 骨架 | `TESTPLAN.md` + `*.journey.spec.ts` |
+| 觸發時機 | 功能完成後 | 專案建立時（Journey-First） |
+| 偵測目標 | 單一 AC 是否正確 | 跨步驟狀態傳遞是否連貫 |
+
+## 工作流程
+
+```
+輸入：專案描述 / 現有 TESTPLAN / --analyze
+    ↓
+Phase 1：定義 Persona
+    分析專案描述 → 識別所有使用者角色 → 定義 Actor / Role / Key Permissions
+    ↓
+Phase 2：設計旅程地圖
+    列出主要業務目標 → 拆解為 T-NNN 群組 → 宣告依賴鏈
+    ↓
+Phase 3：生成 TESTPLAN
+    按格式輸出 test-plans/TESTPLAN-001.md（含 Personas、步驟、依賴圖）
+    ↓
+Phase 4：生成 E2E 骨架
+    從 TESTPLAN T-NNN 生成 *.journey.spec.ts（含 skipIf + 共享 state）
+```
+
+## 模式
+
+### 1. 生成模式（預設）
+
+從專案描述生成完整的 TESTPLAN + E2E 骨架。
+
+```
+/journey-test "電商平台，需要 buyer/seller/admin 三個角色"
+```
+
+產物：
+- `test-plans/TESTPLAN-001.md`：含 Personas、T-000 環境重置、T-001 ~ T-NNN 步驟群組、執行順序依賴圖
+- `src/e2e/journey/main-flow.journey.spec.ts`：含 `describe.skipIf` + 共享 state + T-NNN 對應的完整骨架
+
+### 2. 分析模式（--analyze）
+
+掃描現有測試，找出旅程覆蓋缺口。
+
+```
+/journey-test --analyze
+```
+
+執行步驟：
+1. 讀取 `test-plans/TESTPLAN-NNN.md`（若存在）
+2. 掃描 `src/e2e/` 下所有 `*.journey.spec.ts` 與 `*.journey.e2e.test.ts`
+3. 比對 TESTPLAN T-NNN 與自動化測試中的 T-NNN 引用
+4. 輸出覆蓋缺口報告：列出 TESTPLAN 中缺乏自動化對應的 T-NNN 步驟
+
+### 3. Archetype 模式（--archetype）
+
+使用預設旅程模板，適合已知類型的專案快速啟動。
+
+```
+/journey-test --archetype A1    # Spec-driven 旅程
+/journey-test --archetype A2    # UI-driven 旅程
+/journey-test --archetype A3    # Brownfield 旅程
+```
+
+| Archetype | 模板 | 適用場景 |
+|-----------|------|---------|
+| A1 | Spec-driven | 需求 → Spec → Code → Test，適合 API / Backend 專案 |
+| A2 | UI-driven | 設計稿 → UI → 視覺回歸，適合前端 / 全端專案 |
+| A3 | Brownfield | 現有程式碼 → 分析 → 重構驗證，適合既有專案補測試 |
+
+## TESTPLAN 格式（T-NNN）
+
+以下為完整的 TESTPLAN 範本，展示所有必要區段：
+
+```markdown
+# TESTPLAN-001 <ProjectName> 主線旅程
+
+## Personas
+
+| Actor          | Role           | Key Permissions                |
+|----------------|----------------|--------------------------------|
+| platform_admin | Platform Admin | 建立 Org、管理使用者、查看所有資源 |
+| org_member     | Org Member     | 讀取專案、執行 Pipeline          |
+
+## Environment
+
+- BASE_URL：`http://localhost:3000`（本機） / `$JOURNEY_BASE_URL`（CI）
+- 驗證指令：`curl $BASE_URL/health`
+- 必要帳號：`ADMIN_EMAIL`、`ADMIN_PASSWORD` 環境變數
+
+## T-000 環境重置（optional）
+
+前置條件：無
+depends_on：無
+
+| 步驟    | 操作                          | 預期結果      |
+|---------|-------------------------------|---------------|
+| T-000-1 | [API] GET /health            | 回傳 200 OK   |
+| T-000-2 | [CHECK] 資料庫連線正常        | 無錯誤日誌    |
+
+## T-001 Platform Admin 登入
+
+前置條件：環境正常運行（T-000 通過）
+depends_on：T-000
+
+| 步驟    | 操作                                       | 預期結果                |
+|---------|--------------------------------------------|-------------------------|
+| T-001-1 | [API] POST /api/auth/login（admin 帳號）   | 回傳 200 + authToken    |
+| T-001-2 | [CHECK] authToken 存入共享 state           | let authToken 有值      |
+
+## T-010 主要功能操作
+
+前置條件：authToken 已取得（T-001 通過）
+depends_on：T-001
+
+| 步驟    | 操作                                       | 預期結果                |
+|---------|--------------------------------------------|-------------------------|
+| T-010-1 | [API] POST /api/resources（帶 authToken）  | 回傳 201 + resourceId ★ |
+| T-010-2 | [CHECK] resourceId 存入共享 state          | let resourceId 有值     |
+
+## 執行順序依賴圖
+
+T-000 → T-001 → T-010
+```
+
+## E2E 骨架格式（.journey.spec.ts）
+
+生成的骨架展示三個核心模式：`describe.skipIf` 環境保護、共享 `let` 狀態、T-NNN 識別碼對應。
+
+```typescript
+import { describe, it, expect } from "vitest"
+
+// Journey E2E：需要真實後端，不設定 JOURNEY_BASE_URL 則全部 skip
+const BASE_URL = process.env.JOURNEY_BASE_URL || ""
+
+describe.skipIf(!BASE_URL)("Platform Admin Journey — T-001 → T-010", () => {
+  // 共享 state：每個步驟從前一步驟的結果取值
+  let authToken: string
+  let resourceId: string
+
+  it("T-001: Platform Admin 登入並取得 authToken", async () => {
+    const res = await fetch(`${BASE_URL}/api/auth/login`, {
+      method: "POST",
+      headers: { "Content-Type": "application/json" },
+      body: JSON.stringify({
+        email: process.env.ADMIN_EMAIL,
+        password: process.env.ADMIN_PASSWORD,
+      }),
+    })
+    expect(res.status, "T-001 失敗：登入應回傳 200").toBe(200)
+    const data = await res.json()
+    expect(data.token, "T-001 失敗：應有 token").toBeTruthy()
+    authToken = data.token  // ← 傳遞給後續步驟
+  })
+
+  it("T-010: 執行主要操作（depends on T-001）", async () => {
+    // 若 T-001 失敗，authToken 為 undefined，此步驟的錯誤訊息會清楚說明
+    expect(authToken, "T-010 前置失敗：T-001 的 authToken 不存在").toBeTruthy()
+
+    const res = await fetch(`${BASE_URL}/api/resources`, {
+      method: "POST",
+      headers: {
+        "Content-Type": "application/json",
+        Authorization: `Bearer ${authToken}`,
+      },
+      body: JSON.stringify({ name: "journey-test-resource" }),
+    })
+    expect(res.status, `T-010 失敗：預期 201，實際 ${res.status}`).toBe(201)
+    const data = await res.json()
+    resourceId = data.id  // ← 傳遞給後續步驟
+  })
+})
+```
+
+## 後續步驟
+
+完成後建議：
+
+> **TESTPLAN 與 Journey E2E 骨架已生成。建議下一步：**
+> - 執行 `/e2e` 生成各功能的 AC 層測試（補充旅程測試的細節覆蓋）
+> - 執行 `/atdd` 定義各 T-NNN 步驟對應的驗收條件
+> - 執行 `/journey-test --analyze` 定期檢查自動化覆蓋缺口
+
+## 參考
+
+- 標準：[user-journey-testing.ai.yaml](../../../../.standards/user-journey-testing.ai.yaml)
+- 相關 XSPEC：XSPEC-128（UDS 標準定義）
+- 相關 Skill：`/e2e`（AC 層測試）、`/atdd`（驗收條件定義）

package/bundled/locales/zh-TW/skills/knowledge-graph/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: knowledge-graph
+source: ../../../../skills/knowledge-graph/SKILL.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-05-30
+status: current
+description: "[UDS] 透過知識圖追蹤規格／決策／程式碼的影響鏈（引擎或 Markdown 後備）"
+---
+
+# 知識圖
+
+> **語言**: [English](../../../../skills/knowledge-graph/SKILL.md) | 繁體中文
+
+依據[知識圖記憶標準](../../../../core/knowledge-graph-memory.md)的關係 schema，回答橫跨規格、決策與程式碼的結構性問題——*「XSPEC-205 的完整影響鏈是什麼？」*。有無圖引擎皆可運作。
+
+> **Implements**: XSPEC-237 Phase 5 — knowledge-graph skill（EngramGraph opt-in）
+
+## 模式選擇
+
+回答**前**先判斷使用哪種模式：
+
+| 條件 | 模式 |
+|------|------|
+| 設定了 `ENGRAM_URL`，或本機圖引擎 `/health` 有回應 | 服務模式（引擎）|
+| 否則 | 降級模式（Markdown）|
+
+## 工作流程
+
+1. **解析目標**——將參數正規化為標準 id（`XSPEC-205`、`DEC-062`、函式名）。
+2. **選擇模式**——探測圖引擎（服務）否則後備（降級）。
+3. **服務模式（AC-5b）**——送出單一多跳查詢，呈現回傳的鏈（含跨域連結 code → spec → decision）：
+   ```bash
+   curl -s -X POST "$ENGRAM_URL/graph/impact-analysis" \
+     -H 'content-type: application/json' \
+     -d '{"nodeId":"XSPEC-205","maxHops":3}'
+   ```
+4. **降級模式（AC-5a）**——無引擎時，讀取目標文件，沿其 `impacts`/`impacted_by`/`supersedes`/`related` front-matter 與內文 `[[ref]]` 連結讀取被連結檔案，手動組出鏈（受讀取深度限制）。
+5. **呈現鏈**——列出相連的 Spec 與 Decision、每跳的邊型別、以及（若有）各節點的 `confidence`，高者在前。
+6. **說明使用的模式**——務必告知答案來自引擎或 Markdown 後備，以明確完整度。
+
+## 關係 schema
+
+見[知識圖記憶標準](../../../../core/knowledge-graph-memory.md)。front-matter 欄位：`related`、`impacts`、`impacted_by`、`supersedes`、`implements`。
+
+## 下一步引導
+
+- 降級模式若觸及讀取深度上限，告知使用者圖引擎（如 EngramGraph）可給出完整鏈，以及如何設定 `ENGRAM_URL`。
+- 若參照的 id 找不到，標示為待修的懸空參照。
+- 主動提議為遍歷過的文件補上缺漏的 `impacts`/`impacted_by` front-matter。
+
+## 參考
+
+- 標準：[core/knowledge-graph-memory.md](../../../../core/knowledge-graph-memory.md)
+- 引擎（opt-in）：[EngramGraph](https://github.com/AsiaOstrich/EngramGraph) — `engramgraph`
+- 詳細指南：[guide.md](guide.md)

package/bundled/locales/zh-TW/skills/knowledge-graph/guide.md

@@ -0,0 +1,74 @@
+---
+source: ../../../../skills/knowledge-graph/guide.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-06-02
+source_hash: 9c86b5a2a71d
+status: current
+---
+
+# Knowledge Graph — 詳細指南
+
+[SKILL.md](SKILL.md) 的配套說明。兩種運作模式的範例與引擎 API。
+
+---
+
+## 1. 服務模式（graph 引擎）
+
+當有相容於 EngramGraph 的引擎可連線時，單次查詢即可回傳完整影響鏈。
+
+### 影響分析
+
+```bash
+curl -s -X POST "$ENGRAM_URL/graph/impact-analysis" \
+  -H 'content-type: application/json' \
+  -d '{"nodeId":"XSPEC-205","maxHops":3}'
+# => { "nodeId": "XSPEC-205",
+#      "decisions": [ {"id":"DEC-062","title":"...","via":"direct"},
+#                     {"id":"DEC-069","title":"...","via":"supersedes"} ] }
+```
+
+`via: "direct"` 表示該決策直接 IMPACTS 此 spec；`via: "supersedes"` 表示它透過 SUPERSEDES 影響鏈（≤ `maxHops`）連到此 spec。
+
+### 信心回饋（SAGE）
+
+```bash
+curl -s -X POST "$ENGRAM_URL/graph/ingest" \
+  -H 'content-type: application/json' \
+  -d '{"type":"test_fail","functionId":"src/a.ts#execute"}'
+```
+
+降低該節點的信心值；之後讀取時會優先浮現信心較高的節點。
+
+---
+
+## 2. 降級模式（僅 Markdown）
+
+不需要引擎。透過讀取檔案重建影響鏈：
+
+1. 讀取目標文件（例如 `XSPEC-205`）。
+2. 從其 front-matter（`impacts`、`impacted_by`、`supersedes`、`related`）與行內 `[[ref]]` 連結蒐集 id。
+3. 對每個 id，讀取該文件並重複此過程，直到所需的跳數深度。
+4. 依前綴分類每個 id（`XSPEC-*`/`SPEC-*` → Spec；`DEC-*`/`ADR-*` → Decision）並回報邊。
+
+```bash
+# find the documents
+grep -rl "id: XSPEC-205" --include='*.md' .
+# discover outbound references
+grep -nE "(impacts|impacted_by|supersedes|related):|\[\[(XSPEC|DEC|ADR)-" path/to/XSPEC-205.md
+```
+
+降級模式永遠正確，但受限於你讀取了多少檔案；跨領域的程式碼連結（function → spec）通常只在服務模式中可用。
+
+---
+
+## 3. 等價性
+
+兩種模式產生**相同形狀的答案**（一份相連的 Specs/Decisions 清單，附帶邊類型）。服務模式更快且更完整（可包含 code→spec→decision 的跳轉）；降級模式則是通用後備。務必告知使用者答案來自哪種模式。
+
+---
+
+## 參考
+
+- [core/knowledge-graph-memory.md](../../core/knowledge-graph-memory.md)
+- [EngramGraph](https://github.com/AsiaOstrich/EngramGraph)

package/bundled/locales/zh-TW/skills/migration-assistant/SKILL.md

@@ -2,8 +2,9 @@
 name: migration-assistant
 source: ../../../../skills/migration-assistant/SKILL.md
 source_version: 1.0.0
+source_hash: 67b6f33f825e
 translation_version: 1.0.0
-last_synced: 2026-03-24
+last_synced: 2026-06-01
 status: current
 description: "[UDS] 引導程式碼遷移、框架升級與技術現代化"
 ---
@@ -21,19 +22,19 @@ description: "[UDS] 引導程式碼遷移、框架升級與技術現代化"
 | `/migrate` | 啟動互動式遷移引導 |
 | `/migrate --assess` | 僅風險評估 |
 | `/migrate "Vue 2 to 3"` | 引導特定遷移 |
-| `/migrate --deps` | 依賴升級分析 |
+| `/migrate --deps` | 相依升級分析 |
 | `/migrate --rollback` | 規劃回滾策略 |
 
 ## 遷移類型
 
 | 類型 | 範例 | 風險 |
 |------|------|------|
-| **框架升級** | React 17→18, Vue 2→3 | 中高 |
-| **語言遷移** | JS→TS, Python 2→3 | 高 |
-| **API 版本** | REST v1→v2, GraphQL 更新 | 中 |
-| **資料庫遷移** | MySQL→PostgreSQL | 極高 |
-| **建構工具** | Webpack→Vite | 低中 |
-| **套件管理器** | npm→pnpm | 低 |
+| **框架升級** | React 17→18, Vue 2→3, Angular 15→17 | 中高 |
+| **語言遷移** | JS→TS, Python 2→3, Java 8→17 | 高 |
+| **API 版本** | REST v1→v2, GraphQL schema 更新 | 中 |
+| **資料庫遷移** | MySQL→PostgreSQL, SQL→NoSQL | 極高 |
+| **建構工具** | Webpack→Vite, Grunt→ESBuild | 低中 |
+| **套件管理器** | npm→pnpm, pip→poetry | 低 |
 
 ## 風險評估矩陣
 
@@ -46,11 +47,97 @@ description: "[UDS] 引導程式碼遷移、框架升級與技術現代化"
 ## 工作流程
 
 1. **評估** - 評估現狀、識別破壞性變更
-2. **規劃** - 建立含依賴關係的遷移清單
+2. **規劃** - 建立含相依關係的遷移清單
 3. **準備** - 設定 codemods、相容層、功能旗標
 4. **遷移** - 分階段執行遷移並測試
 5. **驗證** - 執行完整測試套件、檢查回歸
-6. **清理** - 移除相容層、舊依賴
+6. **清理** - 移除相容層、舊相依
+
+## API 遷移合約測試
+
+當 API endpoint 從一個技術棧遷至另一個（PHP → .NET、Express → Spring、Python → Go），對**新**實作的單元測試只驗證**新 DTO**——無法捕捉「舊版有但新版漏掉的欄位」。欄位缺漏、欄位 rename、型別漂移，以及頂層 vs nested 層級漂移等問題會靜默流入生產，導致仍預期舊版 shape 的既有前端失靈。
+
+**僅靠單元測試、整合測試或 code review 無法防止**。2026-05-24 真實 PROD 事故：67/67 測試全綠流入正式環境，由客戶發現缺漏。
+
+### 強制規則
+
+每個被遷移的 API endpoint **必須**至少有一份 contract test，比對新實作的 response 與從 legacy 實作捕獲的 fixture。驗證的是結構性等價（keys、type、層級位置），而非值等價。
+
+### Fixture 捕獲協議
+
+**Legacy 仍運行（典型遷移窗口）：**
+
+```bash
+# 1. Capture ≥3 representative inputs (happy path, edge case, empty result)
+curl -X POST $LEGACY_BASE/endpoint -d @input1.json \
+  > tests/fixtures/migration/endpoint/scenario1.json
+curl -X POST $LEGACY_BASE/endpoint -d @input2_empty.json \
+  > tests/fixtures/migration/endpoint/scenario2_empty.json
+curl -X POST $LEGACY_BASE/endpoint -d @input3_edge.json \
+  > tests/fixtures/migration/endpoint/scenario3_edge.json
+
+# 2. Scrub PII and volatile values (timestamps, generated IDs)
+jq 'walk(if type == "string" and test("@") then "redacted@example.com" else . end)' \
+  tests/fixtures/migration/endpoint/scenario1.json > tmp && mv tmp ...
+
+# 3. Commit fixtures
+git add tests/fixtures/migration/endpoint/
+```
+
+**Legacy 已退役但 source 可讀：**
+
+- 追蹤 legacy source code，手動建構預期的 response shape
+- 將每個欄位的來源（SQL 欄位、計算式、hardcoded）記錄於同位置的 `.notes.md` 檔案
+
+### Contract test 範本
+
+**C# / xUnit：**
+
+```csharp
+[Theory]
+[InlineData("scenario1")]
+[InlineData("scenario2_empty")]
+[InlineData("scenario3_edge")]
+public async Task Endpoint_ResponseShape_MatchesLegacyFixture(string scenario)
+{
+    var fixture = LoadFixture($"migration/endpoint/{scenario}");
+    var response = await CallNewImpl(fixture.Input);
+    // StructuralEquivalence checks keys + types + placement, ignores values
+    StructuralEquivalence.Assert(response, fixture.ExpectedShape);
+}
+```
+
+**TypeScript / Jest：**
+
+```typescript
+import { structuralEquivalence } from "./test-utils/structural-equivalence";
+
+describe.each([
+  ["scenario1"],
+  ["scenario2_empty"],
+  ["scenario3_edge"],
+])("Endpoint response shape vs legacy fixture (%s)", (scenario) => {
+  test("matches", async () => {
+    const fixture = loadFixture(`migration/endpoint/${scenario}.json`);
+    const response = await callNewImpl(fixture.input);
+    structuralEquivalence(response, fixture.expectedShape);
+  });
+});
+```
+
+`structuralEquivalence` / `StructuralEquivalence.Assert` 規則：每一層具備相同的 key 集合（不可缺漏、不可多出，除非明確 opt in）、每個 key 具相同的基本型別、相同的層級位置（頂層 vs nested）。值可以不同（timestamps、IDs）；型別與結構不可不同。
+
+### 逐欄位遷移稽核清單
+
+合併任何被遷移的 endpoint 前：
+
+- [ ] 所有 legacy response 欄位皆 mapping 至新 DTO（無 silent drop）
+- [ ] 儘量保留命名（避免將 `TotalX` rename 而丟失「per-member」語意）
+- [ ] 保留頂層 vs nested 層級位置
+- [ ] 已驗證型別相容性（string→int 轉換為明確而非巧合）
+- [ ] Error path return code 與 legacy 一致（`509` 而非 `506`；`404` 而非 `400`）
+- [ ] Contract test fixture 已 commit 至 `tests/fixtures/migration/`
+- [ ] Cross-link 至 [contract-test-assistant](../contract-test-assistant/SKILL.md) 做持續的消費端驗證
 
 ## 回滾策略
 
@@ -61,15 +148,45 @@ description: "[UDS] 引導程式碼遷移、框架升級與技術現代化"
 | **雙運行** | 關鍵系統、零停機 |
 | **分支凍結** | 一次性完整遷移 |
 
+## 使用範例
+
+```
+User: /migrate "Vue 2 to 3"
+AI: Migration Assessment: Vue 2 → Vue 3
+    Breaking changes found: 12
+    - Options API → Composition API (47 components)
+    - Filters removed (8 usages)
+    - Event bus removed (3 usages)
+    Risk: Medium-High
+    Estimated effort: 2-3 weeks
+    Recommended: Staged migration with @vue/compat
+```
+
 ## 下一步引導
 
 `/migrate` 完成後，AI 助手應建議：
 
 > **遷移分析完成。建議下一步：**
 > - 執行 `/reverse` 深入理解現有程式碼
-> - 執行 `/testing` 確保遷移後測試通過
+> - 執行 `/testing` 確保遷移後測試通過 ⭐ **推薦**
 > - 執行 `/commit` 提交遷移變更
 
 ## 參考
 
 - 核心規範：[refactoring-standards.md](../../../../core/refactoring-standards.md)
+- 相關：[contract-test-assistant](../contract-test-assistant/SKILL.md) — 遷移後持續合約驗證的策略
+
+## 版本歷史
+
+| 版本 | 日期 | 變更 |
+|------|------|------|
+| 1.1.0 | 2026-05-26 | 新增：API 遷移合約測試章節——強制 fixture 捕獲協議、C#/TS 範本、逐欄位稽核清單（XSPEC-233 / closes #112） |
+| 1.0.0 | 2026-03-24 | 初始版本 |
+
+## AI 代理行為
+
+> 完整的 AI 行為定義請參閱對應的命令文件：[`/migrate`](../commands/migrate.md#ai-agent-behavior--ai-代理行為)
+
+## 授權
+
+CC BY 4.0