universal-dev-standards 5.17.0 → 6.0.0

package/bundled/locales/zh-CN/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) | [繁體中文](../../zh-TW/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-CN/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: ed870e072b63
+status: current
+---
+
+# Flaky 测试管理标准
+
+> **Language**: [English](../../../core/flaky-test-management.md) | [繁體中文](../../zh-TW/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-CN/core/flow-based-testing.md

@@ -0,0 +1,284 @@
+---
+source: ../../../core/flow-based-testing.md
+source_version: 1.3.0
+translation_version: 1.3.0
+last_synced: 2026-06-10
+source_hash: a8838e95f84e
+status: stale
+---
+
+# 流程式测试（Flow-Based Testing）
+
+> **语言**: [English](../../../core/flow-based-testing.md) | [繁體中文](../../zh-TW/core/flow-based-testing.md) | 简体中文
+
+**版本**: 1.3.0
+**最后更新**: 2026-05-05
+**适用性**: 所有具备多步骤工作流程的软件项目
+**范围**: 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**：维度 9（Flow Completeness）与维度 10（Branch Coverage）在此定义
+- **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-CN/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-23
-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 用户有无效凭证