universal-dev-standards 5.17.0 → 6.1.0

package/bundled/locales/zh-TW/core/feature-manifest-standard.md

@@ -0,0 +1,222 @@
+---
+source: ../../../core/feature-manifest-standard.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-06-10
+source_hash: 501a97944fd0
+status: current
+---
+
+# Feature Manifest 標準
+
+> **Language**: [English](../../../core/feature-manifest-standard.md) | 繁體中文
+
+**適用範圍**: 將既有系統移植或重組的遷移與重構專案
+**Scope**: universal
+
+---
+
+## 概述
+
+Feature Manifest 標準定義一種機器可讀格式（`feature-manifest.yaml`），用於在遷移或重構開始前，盤點既有系統的所有功能。它在舊系統的能力與新系統的驗收標準之間提供結構化的橋樑，讓工具（VibeOps `/vo-pipeline --variant migration`）能自動強制執行完整性閘門。
+
+## 參考資料
+
+| 標準/來源 | 內容 |
+|----------------|---------|
+| XSPEC-200 | 遷移功能盤點與完整性閘門 |
+| XSPEC-201 | 重構/遷移完整性協議 |
+| XSPEC-199 | AC `not_implemented` 狀態擴充 |
+
+---
+
+## 何時使用
+
+在以下情況使用 `feature-manifest.yaml`：
+- 將系統從一種語言/框架遷移到另一種（例如 PHP → C# .NET）
+- 將舊系統移植到新架構
+- 啟動必須保留既有行為的大型重構
+
+**請勿用於** greenfield 開發——manifest 是既有系統的映照，不是設計文件。
+
+---
+
+## Feature Manifest 格式
+
+### 檔案位置
+
+```
+artifacts/feature-manifest.yaml
+```
+
+### 頂層結構
+
+```yaml
+manifest_version: "1.0"
+source_system:
+  language: php
+  framework: laravel
+  scan_date: "2026-05-12"
+  scan_coverage: "47/47 routes (100%)"
+
+features:
+  - id: FM-001
+    name: UserLogin
+    # ... (see Feature Entry below)
+```
+
+### Feature Entry 結構描述
+
+| 欄位 | 型別 | 必填 | 說明 |
+|-------|------|----------|-------------|
+| `id` | string | 是 | `FM-NNN`（補零） |
+| `name` | string | 是 | PascalCase 業務功能名稱 |
+| `description` | string | 是 | 以白話描述業務目的 |
+| `http_method` | string | 否 | `GET`、`POST`、`PUT`、`PATCH`、`DELETE`；CLI/背景作業為 `null` |
+| `route` | string | 否 | URL 路徑；CLI/背景作業為 `null` |
+| `controller` | string | 是 | `ClassName::methodName` |
+| `confidence` | float | 是 | 0.0–1.0（見 Confidence 評分） |
+| `side_effects` | list | 是 | `DB_READ`、`DB_WRITE`、`EMAIL`、`QUEUE`、`HTTP_CALL`、`FILE` |
+| `migration_risks` | list | 否 | 風險標籤（見遷移風險） |
+| `ac_id` | string | 否 | 初始為 `null`；manifest 建立後由 Planner 設定 |
+| `status` | string | 是 | 初始一律為 `not_implemented` |
+
+### 完整 Feature Entry 範例
+
+```yaml
+features:
+  - id: FM-007
+    name: OrderCancellation
+    description: 取消訂單並觸發退款流程
+    http_method: POST
+    route: /api/orders/{id}/cancel
+    controller: OrderController::cancel
+    confidence: 0.9
+    side_effects:
+      - DB_WRITE
+      - QUEUE
+    migration_risks:
+      - ORM_DIFFERENCES
+    ac_id: null
+    status: not_implemented
+```
+
+---
+
+## Confidence 評分
+
+| 數值 | 意義 | 動作 |
+|-------|---------|--------|
+| 1.0 | 功能名稱與業務目的明確無歧義 | 進入 AC 產生階段 |
+| 0.8 | 功能名稱合理，目的需要推斷 | 附註後繼續 |
+| 0.5 | 可能是基礎設施/工具程式，非主要業務功能 | 標記供人工審查 |
+| 0.3 | 不明——無法判斷業務目的 | **暫停；必須由人工確認** |
+
+**規則**：所有 `confidence < 0.5` 的功能，必須先經人工審查，Planner 才能產生 AC。
+
+---
+
+## 遷移風險
+
+### PHP → C# .NET
+
+| 標籤 | 說明 |
+|-------|-------------|
+| `SESSION_HANDLING` | PHP `$_SESSION` → ASP.NET Core Session/Cookie middleware |
+| `ORM_DIFFERENCES` | Eloquent ORM 與 Entity Framework 的行為差異 |
+| `TIMEZONE_HANDLING` | PHP 時區函式 → .NET `DateTimeOffset` |
+| `FILE_UPLOAD_PATH` | PHP `$_FILES` → ASP.NET Core `IFormFile` |
+| `REGEX_DIFFERENCES` | PHP PCRE 語法與 .NET `System.Text.RegularExpressions` 的差異 |
+| `ARRAY_FUNCTIONS` | PHP `array_*` 函式 → LINQ 對應寫法 |
+| `EXCEPTION_HIERARCHY` | PHP 例外階層與 .NET 例外階層的差異 |
+
+### 通用
+
+| 標籤 | 說明 |
+|-------|-------------|
+| `ASYNC_MODEL` | 同步程式碼 → async/await 遷移 |
+| `NULL_SEMANTICS` | Null 處理差異 |
+| `STRING_ENCODING` | 字串編碼/定序（collation）差異 |
+
+---
+
+## FEATURE_STUB 標記協議
+
+在目標程式碼庫中實作 manifest 內的功能時，使用 `FEATURE_STUB:` 標記作為占位符：
+
+### 格式
+
+```
+// FEATURE_STUB: <FM-ID> <FeatureName> — <AC-ID> pending
+```
+
+### 範例（C#）
+
+```csharp
+// FEATURE_STUB: FM-007 OrderCancellation — AC-007 pending
+public async Task<Result<OrderDto>> CancelOrderAsync(string orderId, CancellationReason reason)
+{
+    throw new NotImplementedException();
+}
+```
+
+### FEATURE_STUB 與 WARNING:STUB 的差異
+
+| 標記 | 語義 | 使用時機 |
+|--------|----------|-------------|
+| `// WARNING: STUB` | 暫時的假邏輯（程式可執行但行為錯誤） | 帶有錯誤業務邏輯的占位符 |
+| `// FEATURE_STUB:` | 功能尚未實作（完全沒有邏輯） | manifest 中尚未撰寫程式碼的功能 |
+
+**兩種標記都會阻擋 CI**（main 分支 push 與 UAT/production 部署）。
+
+### 生命週期
+
+1. 功能加入 manifest，`status: not_implemented`
+2. 開發人員在目標程式碼中加入 `FEATURE_STUB:` 占位符
+3. 開發人員實作該功能，移除 `FEATURE_STUB:` 標記
+4. 更新 manifest `status` → `implemented`
+5. 更新 AC traceability `status` → `uncovered` 或 `covered`
+
+---
+
+## 完整性閘門
+
+### Gate 1（Pre-Pipeline）
+
+在 `/vo-pipeline --variant migration` 開始前：
+- `artifacts/feature-manifest.yaml` 必須存在
+- `.snapshots/` 目錄必須存在且至少含一個 JSON 檔案
+
+### 功能完整性閘門（Pre-UAT）
+
+CI 在以下條件同時成立時阻擋 UAT 部署：
+- manifest 中有任何功能的 `status: not_implemented`，且
+- 程式碼庫中存在對應的 `FEATURE_STUB:`
+
+---
+
+## 反模式
+
+| 反模式 | 影響 | 正確做法 |
+|--------------|--------|------------------|
+| 沒有 manifest 就開始遷移 | 功能缺口到 UAT 才被發現 | 一律先產生 manifest |
+| 跳過低 confidence 的功能 | 功能被靜默遺漏 | 審查並確認所有功能 |
+| 用 `uncovered` 取代 `not_implemented` | CI 不會因缺少功能而阻擋 | 程式碼不存在時使用 `not_implemented` |
+| 實作後未移除 `FEATURE_STUB:` | CI 出現「未完成」的假訊號 | 實作後一律清除標記 |
+
+---
+
+## 相關標準
+
+- [Acceptance Criteria Traceability](acceptance-criteria-traceability.md) — `not_implemented` AC 狀態
+- [Behavior Snapshot Standard](behavior-snapshot.md) — HTTP parity 基準記錄
+- [Refactoring Standards](refactoring-standards.md) — 重構用的 Characterization 測試
+- [Spec-Driven Development](spec-driven-development.md) — AC 產生工作流程
+
+---
+
+## 版本歷史
+
+| 版本 | 日期 | 變更 |
+|---------|------|---------|
+| 1.0.0 | 2026-05-12 | 初始版本——FM-NNN schema、confidence 評分、FEATURE_STUB 協議（XSPEC-200） |

package/bundled/locales/zh-TW/core/flaky-test-management.md

@@ -0,0 +1,87 @@
+---
+source: ../../../core/flaky-test-management.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-06-10
+source_hash: 04c9ce181011
+status: current
+---
+
+# Flaky 測試管理標準
+
+> **Language**: [English](../../../core/flaky-test-management.md) | 繁體中文
+
+## 概述
+
+在一個 3000 個測試的套件中，只要有一個 flaky 測試，就足以侵蝕 CI 的可信度，讓開發人員開始忽略失敗。一旦開發人員學會「重跑 CI 就好」，真正的 bug 就會悄悄溜過。消除 flaky 測試的成本，永遠低於它們所製造的虛假安全感的成本。
+
+## 定義
+
+若一個測試在相同程式碼下連續執行卻產生不同結果（pass/fail），即為 **flaky**。2% 門檻：若一個測試在 `main` 上未變更程式碼的情況下失敗率 ≥ 2%，即屬 flaky。
+
+## 偵測
+
+大多數 CI 系統可自動偵測 flakiness：
+
+- **GitHub Actions**：尋找 `Flaky tests detected` 標註
+- **手動**：執行 `npx vitest run --reporter=verbose` 5 次，觀察是否有非確定性結果
+- **Vitest**：`vitest run --repeat=5`（每個測試各執行 5 次）
+
+## 隔離（Quarantine）工作流程
+
+```
+Detected → Quarantine (< 48h) → Track → Fix or Delete (< 30 days)
+```
+
+### 隔離標註
+
+```typescript
+// TODO: quarantined 2026-05-05 — flaky race condition, see issue #42
+it.skip("reconnects after WebSocket disconnect", async () => {
+  // ... test body preserved for reference
+})
+```
+
+### 追蹤 Issue 範本
+
+```markdown
+**Flaky Test**: `describe > test name`
+**File**: `src/path/to/test.ts`
+**Quarantined**: 2026-05-05
+**Failure rate**: ~5% on main
+**Known failure mode**: `Cannot read property 'socket' of undefined`
+**Root cause hypothesis**: Race condition in WebSocket teardown
+**Deadline**: 2026-06-05
+```
+
+## 常見根本原因
+
+| 根本原因 | 修法 |
+|-----------|-----|
+| Race condition | 使用 `waitFor()`、`vi.waitFor()`、正確的 async 協調 |
+| 共享狀態 | 在 `beforeEach`/`afterEach` 中重置狀態 |
+| 外部服務 | Mock 該依賴 |
+| 檔案系統排序 | 使用確定性排序 |
+| 未設 seed 的隨機值 | 在測試中設定固定 seed |
+| 時序相依 | 使用假計時器（`vi.useFakeTimers()`） |
+
+## Vitest 設定
+
+```typescript
+// vitest.config.ts
+export default defineConfig({
+  test: {
+    retry: 2,              // retry failed tests up to 2 times
+    testTimeout: 10000,    // 10s timeout prevents infinite hangs
+    hookTimeout: 5000,     // 5s hook timeout
+  }
+})
+```
+
+## 相關標準
+
+- [Testing Standards](testing-standards.md) — 整體測試金字塔
+- [Test Governance Standards](test-governance.md) — CI 政策
+
+
+**Scope**: universal

package/bundled/locales/zh-TW/core/flow-based-testing.md

@@ -0,0 +1,284 @@
+---
+source: ../../../core/flow-based-testing.md
+source_version: 1.3.1
+translation_version: 1.3.1
+last_synced: 2026-07-08
+source_hash: afadaebc0f49
+status: current
+---
+
+# 流程式測試（Flow-Based Testing）
+
+> **Language**: [English](../../../core/flow-based-testing.md) | 繁體中文
+
+**版本**: 1.3.1
+**最後更新**: 2026-06-18
+**適用範圍**: 所有具備多步驟工作流程的軟體專案
+**Scope**: universal
+**產業標準**: ISO/IEC/IEEE 29119-4（測試技術）、ISTQB Foundation Syllabus
+**參考資料**: Decision Table Testing（ISTQB）、Pairwise Testing、State Transition Testing
+
+---
+
+## 目的
+
+本文件定義測試多步驟流程的系統化方法論。它填補了 AC 中心式測試（孤立驗證個別行為）與流程層級測試（驗證帶有累積狀態與分支覆蓋的序列行為）之間的落差。
+
+---
+
+## 核心問題：AC 中心式 vs. 流程中心式測試
+
+AC 中心式測試驗證每個驗收條件在孤立情況下可正常運作。然而，它們會漏掉兩類關鍵 bug：
+
+1. **步驟互動 bug**：只有當 Step 1 的輸出成為 Step 2 的輸入時才會顯現的 bug
+2. **分支覆蓋缺口**：從未以所有可能值演練過的決策點
+
+**範例**：某 pipeline 有 8 個步驟。每個 AC 都獨立通過。但當 Step 3 的配額檢查依賴 Step 1 與 Step 2 累積的狀態時，這個互動從未被測試到。
+
+---
+
+## 三步驟流程分解
+
+### Step 1: 流程辨識（Flow Identification）
+
+在撰寫任何測試程式碼之前，先記錄：
+
+- **前置條件（Preconditions）**：系統的初始狀態
+- **步驟序列（Step sequence）**：依序排列的動作清單（Step 1 → Step N）
+- **決策點（Decision points）**：流程中的每一個 if/else/條件
+- **終止狀態（Terminal states）**：所有可能的結束狀態（成功 + 每一種不同的失敗）
+
+### Step 2: 決策表展開（Decision Table Expansion）
+
+針對每個決策點，列出所有可能的值。然後套用覆蓋策略：
+
+| 策略 | 使用時機 | 場景數量 |
+|----------|-------------|---------------|
+| **Each-Choice**（最小） | 低風險流程、快速回饋 | 各唯一值的總和 |
+| **Pairwise** | 中風險流程 | ~N × max_values |
+| **All-Combinations** | 認證、付款、安全 | 各值數量的乘積 |
+
+**決策表範例**：
+
+| 決策點 | 值 |
+|----------------|--------|
+| Authorization | valid / expired / missing |
+| Quota | sufficient / exceeded |
+| External Service | available / timeout / error |
+
+Each-Choice 最小值：3 + 2 + 3 = 8 個場景（相較於團隊實際上通常只寫 1-2 個）。
+
+### Step 3: 旅程測試結構（Journey Test Structure）
+
+以共享狀態串接（shared state threading）撰寫測試——以 `ctx` 物件跨步驟累積狀態：
+
+```typescript
+describe("Flow: Create Order", () => {
+  const ctx: { token?: string; orderId?: string } = {}
+
+  it("Step 1: Login", async () => {
+    ctx.token = await login(credentials)
+    expect(ctx.token).toBeTruthy()
+  })
+
+  it("Step 2: Create order (uses Step 1 token)", async () => {
+    ctx.orderId = await createOrder(ctx.token!, orderData)
+    expect(ctx.orderId).toMatch(/^ord-/)
+  })
+
+  it("Step 3: Verify order state (uses Step 2 orderId)", async () => {
+    const order = await getOrder(ctx.token!, ctx.orderId!)
+    expect(order.status).toBe("pending")
+  })
+})
+
+describe("Flow Branch: Quota exceeded path", () => {
+  it("should return 429 and NOT create order when quota is exhausted", async () => {
+    await exhaustQuota(testUser)
+    const response = await attemptCreateOrder(testToken, orderData)
+    expect(response.status).toBe(429)
+    expect(response.body.code).toBe("QUOTA_EXCEEDED")
+    // Verify side effects: no order was created
+    const orders = await getOrders(testUser)
+    expect(orders.length).toBe(0)
+  })
+})
+```
+
+---
+
+## 反模式（Anti-Patterns）
+
+- 只測試 happy path 流程（漏掉失敗終止狀態）
+- 在步驟之間重設共享狀態（破壞狀態串接）
+- 孤立測試每個步驟而不驗證累積狀態
+- 對含多個決策點的流程只用單一測試
+- 對每個流程都套用 All-Combinations（應保留給關鍵路徑）
+- 在分支測試中不驗證副作用（或副作用的不存在）
+
+---
+
+## 與其他標準的關係
+
+- **test-completeness-dimensions**：定義了 **8** 個維度。Flow Completeness 與 Branch Coverage（決策表）的細節在本標準中說明——它們並非該標準中編號的維度 9/10（該標準僅有 8 個維度）
+- **behavior-driven-development**：BDD Scenario Outline 表格對應到決策表展開
+- **mock-boundary**：流程測試必須遵守 mock boundary 規則（不 mock 自身模組邏輯）
+- **e2e-testing**：旅程測試在 ST 或 E2E 層級執行；流程測試可在 IT 層級搭配真實 DB 執行
+
+---
+
+## 多閘門流程驗證模型（Multi-Gate Flow Verification Model）
+
+流程覆蓋不是單一的發布前檢查——它是橫跨整個 SDLC 的**漸進式驗證鏈**。有兩個本質上不同的問題，必須在不同階段回答：
+
+| 驗證類型 | 問題 | 執行者 | 時機 |
+|------------------|----------|----------|--------|
+| **覆蓋（Coverage）** | 所有終止狀態都測試了嗎？ | 自動化 CI | Dev → Staging → Pre-UAT |
+| **正確性（Correctness）** | 終止狀態的定義正確嗎？ | 人工 UAT | UAT 階段 |
+
+混淆這兩者會把 UAT 週期浪費在 CI 早該抓到的技術覆蓋問題上。
+
+### Gate 0 — PRD 簽核（實作開始之前）
+
+三項可測試性要素必須在寫下任何一行程式碼之前寫入 PRD。使用 `templates/requirement-template.md` 的 §2.4 與 §9.4：
+
+| 要素 | PRD 章節 | 何時必須 |
+|---------|-------------|---------------|
+| 前置條件 + 有序步驟 | §2.4 | ≥ 3 步驟的流程 |
+| 決策點清單 | §2.4 | 每一個分支條件 |
+| 終止狀態清單 | §2.4 | 所有不同的結束狀態 |
+| 決策表（Each-Choice） | §9.4 | 所有流程 |
+| 升級到 All-Combinations | §9.4 | 認證 / 付款 / 安全 |
+| UAT 驗收腳本（預先填寫） | §9.4 | PRD 核准之前 |
+
+> **為什麼在 PRD 階段？** 測試工程師無法從只描述 happy path 的規格推導出分支覆蓋。在測試設計階段才發現缺漏的決策點會浪費整整一個 sprint。
+
+### Gate 1 — PR 合併（每個功能分支）
+
+任何觸及 ≥ 3 步驟流程的 PR 必須包含覆蓋該 PR 所引入或修改之終止狀態的自動化測試。若終止狀態被加入 §2.4 而沒有對應的測試，審查者應阻擋合併。
+
+### Gate 3 — Pre-UAT 部署（自動化 + QA Lead 簽核）
+
+CI 必須在 UAT 開始**之前**證明覆蓋完整性。UAT 用於正確性驗證，不是技術測試。
+
+必要的 CI 檢查：
+- 所有決策表場景都有通過的自動化測試
+- 沒有任何終止狀態缺乏測試覆蓋
+- 分支覆蓋率 ≥ 90%（或專案自定義門檻）
+- 認證 / 付款 / 安全流程的 All-Combinations 全數通過
+
+> 未通過 Gate 3 就部署到 UAT，等於強迫業務利害關係人充當技術 QA——這是對 UAT 時間既昂貴又打擊士氣的濫用。
+
+### Gate 4 — UAT 簽核（業務正確性，上線前）
+
+UAT 驗證的是終止狀態的**定義是否正確**地對應真實業務規則，而不是它們是否被覆蓋。使用 §9.4 的 UAT 驗收腳本（直接從決策表推導——不需要另外建立腳本）：
+
+- 業務利害關係人逐列（終止狀態）簽核
+- 若 UAT 揭露先前未定義的終止狀態：將其加入 §2.4 + 決策表 + 自動化測試，重跑 Gate 3，然後恢復 UAT
+- UAT 期間沒有發現新的終止狀態 = §2.4 足夠周延的強烈訊號
+
+### 閘門模型總覽
+
+```
+PRD Sign-off
+    │ Gate 0: §2.4 + §9.4 complete (Decision Points, Terminal States,
+    │         Decision Table, UAT script pre-filled)
+    ▼
+Implementation + PR Reviews
+    │ Gate 1: Each PR covering a flow includes terminal state tests
+    ▼
+Staging / Integration
+    │ (no formal gate — CI green is sufficient)
+    ▼
+Pre-UAT Deployment
+    │ Gate 3: CI proves 100% terminal state coverage + branch coverage ≥ 90%
+    ▼
+UAT Execution
+    │ Gate 4: Business sign-off on terminal state correctness
+    │         New terminal states → back to Gate 3 before proceeding
+    ▼
+Production
+```
+
+---
+
+## RQM 整合
+
+Gate 3（Pre-UAT CI 覆蓋閘門）必須產出 **`flow_gate_report.json`** 產物，供 Release Quality Manifest（`release-quality-manifest.md`，欄位 `flow_gate_report`）消費。
+
+### flow_gate_report.json Schema
+
+```json
+{
+  "generated_at": "2026-05-05T04:00:00Z",
+  "commit": "abc1234",
+  "flows": [
+    {
+      "flow_id": "login-authentication",
+      "spec_ref": "docs/specs/SPEC-001.md#2.4",
+      "decision_points": 3,
+      "terminal_states": 7,
+      "gate_0_complete": true,
+      "gate_1_pr_coverage": true,
+      "gate_3": {
+        "all_scenarios_green": true,
+        "terminal_states_covered": 7,
+        "terminal_states_defined": 7,
+        "branch_coverage_pct": 94,
+        "coverage_target": 90,
+        "all_combinations_required": false,
+        "status": "pass"
+      },
+      "gate_4_uat_signoff": true
+    }
+  ],
+  "summary": {
+    "total_flows": 5,
+    "gate_0_complete": true,
+    "gate_1_pr_coverage": true,
+    "gate_3_ci_pass": true,
+    "gate_4_uat_signoff": true,
+    "status": "pass"
+  }
+}
+```
+
+### 產生腳本掛鉤（Generation Script Hook）
+
+在 CI 測試執行之後加入（Gate 3）：
+
+```bash
+# scripts/generate-flow-gate-report.sh
+node scripts/generate-flow-gate-report.mjs \
+  --coverage-report coverage/coverage-summary.json \
+  --flow-specs "docs/specs/**/*.md" \
+  --uat-signoffs ".release-readiness/*.md" \
+  --output flow_gate_report.json
+```
+
+`summary.status` 欄位會餵入 `release-quality-manifest.yaml` 的 `flow_gate_report.status`。
+
+---
+
+## 快速參考檢查清單
+
+```
+Flow: ___________________
+
+□ Step 1 — Flow Identification
+  □ Preconditions documented
+  □ Ordered step sequence listed
+  □ All decision points extracted
+  □ All terminal states defined
+
+□ Step 2 — Decision Table
+  □ Decision table created
+  □ Coverage strategy chosen (Each-Choice / Pairwise / All-Combinations)
+  □ Critical flows (auth/payment/security) → All-Combinations
+
+□ Step 3 — Journey Test Structure
+  □ Happy path journey test (shared ctx, sequential steps)
+  □ Each branch outcome has its own describe block
+  □ Branch tests verify both response AND absence of side effects
+  □ No beforeEach resetting ctx between steps
+```

package/bundled/locales/zh-TW/core/forward-derivation-standards.md

@@ -3,7 +3,7 @@ source: ../../../core/forward-derivation-standards.md
 source_version: 1.2.0
 translation_version: 1.2.0
 last_synced: 2026-03-18
-status: current
+status: stale
 ---
 
 # 正向推演標準 | Forward Derivation Standards
@@ -182,20 +182,19 @@ describe('AC-1: 使用者以有效憑證登入', () => {
 # Generator: forward-derivation v1.0.0
 # Generated at: 2026-01-19T10:00:00Z
 
-@SPEC-001
 Feature: 使用者認證
   作為使用者
   我想要登入系統
   以便存取我的儀表板
 
-  @AC-1 @happy-path
+  @SPEC-001 @AC-1 @happy-path
   Scenario: 使用者以有效憑證登入
     # [來源] 來自 SPEC-001 AC-1
     Given 已註冊的使用者有有效憑證
     When 使用者提交登入表單
     Then 使用者被導向儀表板
 
-  @AC-2 @error-handling
+  @SPEC-001 @AC-2 @error-handling
   Scenario: 無效憑證登入失敗
     # [來源] 來自 SPEC-001 AC-2
     Given 使用者有無效憑證

package/bundled/locales/zh-TW/core/frontend-design-standards.md

@@ -3,7 +3,7 @@ source: ../../../core/frontend-design-standards.md
 source_version: 1.0.0
 translation_version: 1.0.0
 last_synced: 2026-04-20
-status: current
+status: stale
 ---
 
 # 前端設計標準