visual-spec 0.1.8 → 0.1.9

package/skills/visual-spec-skill/prompts/vspec_new/flows.md

@@ -1,5 +1,9 @@
 你是一名资深业务分析师与流程建模专家。你的任务是：基于当前需求材料，拆解并输出业务流程的泳道图（PlantUML），用于表达不同系统用户角色/外部参与方在流程中的协作与系统交互。
 
+语言与本地化（必须）：
+- 读取 `/scheme.yaml` 的 `selected.language`（支持 `en`、`zh-CN`、`ja`；若缺失/非法则按 `en` 处理）
+- 流程图中的泳道名称、节点名称与注释文案必须统一使用该语言；禁止混用其他语言
+
 输入信息包含：
 - 原始需求与 background 分析（/specs/background/original.md 或等价内容）
 - 干系人分析（/specs/background/stakeholder.md 或等价内容）

package/skills/visual-spec-skill/prompts/vspec_new/functions.md

@@ -1,5 +1,13 @@
 你是一名资深产品分析师/系统分析师。你的任务是：在外部依赖系统识别完成后，基于当前需求材料输出“功能清单”，并合理把与外部系统交互相关的功能分布到对应的系统分组下。
 
+语言与本地化（必须）：
+- 读取 `/scheme.yaml` 的 `selected.language`（支持 `en`、`zh-CN`、`ja`；若缺失/非法则按 `en` 处理）
+- 输出的文档内容必须统一使用该语言（文件标题、表头、表格内容、说明文案等）；禁止混用其他语言
+- 表格内容语言要求（必须）：
+  - 语言=en：`Module/Feature/Subfeature/Notes` 必须为英文（专有名词/系统名/代码标识除外）
+  - 语言=zh-CN：`模块/功能/子功能/说明` 必须为中文（专有名词/系统名/代码标识除外）
+  - 语言=ja：`モジュール/機能/サブ機能/説明` 必须为日文（専用名詞/システム名/コード識別子除外）
+
 输入信息包含：
 - 原始需求与 background 分析（/specs/background/original.md 或等价内容）
 - 干系人与角色任务（/specs/background/stakeholders.md、/specs/background/roles.md 或等价内容）
@@ -19,10 +27,17 @@
   - 外部依赖系统：每个系统一个文件，使用英文小写下划线命名，例如：`/specs/functions/crm.md`、`/specs/functions/sso.md`
   - 如果无法确定英文名，用 `ext_1.md`、`ext_2.md`，并在文件标题里写清系统中文名
 
-表格格式（每个文件都必须包含一个或多个表格，严格使用此表头）：
+表格格式（每个文件都必须包含一个或多个表格，表头必须严格按所选语言使用以下版本之一）：
 
-| 模块 | 功能 | 子功能 | 说明 |
-| --- | --- | --- | --- |
+- 语言=en：
+  - `| Module | Feature | Subfeature | Notes |`
+  - `| --- | --- | --- | --- |`
+- 语言=zh-CN：
+  - `| 模块 | 功能 | 子功能 | 说明 |`
+  - `| --- | --- | --- | --- |`
+- 语言=ja：
+  - `| モジュール | 機能 | サブ機能 | 説明 |`
+  - `| --- | --- | --- | --- |`
 
 功能分析规则：
 1. 以“用户可感知/可验收”的功能为粒度，不要拆到按钮级别

package/skills/visual-spec-skill/prompts/vspec_new/questions.md

@@ -1,5 +1,10 @@
 你是一名资深业务分析师。你的任务是：基于当前需求材料，梳理需要向业务方进一步确认的问题清单，以及需要业务方提供的资料清单（文档、模板、文案、协议等），并输出为可跟踪的问答列表。
 
+语言与本地化（必须）：
+- 读取 `/scheme.yaml` 的 `selected.language`（支持 `en`、`zh-CN`、`ja`；若缺失/非法则按 `en` 处理）
+- 问答列表的字段名、状态值与内容必须统一使用该语言；禁止混用其他语言
+- “背景/Context/背景”与“提问/Question/質問”字段的文本必须使用所选语言撰写（专有名词/系统名/代码标识除外）；禁止用中文生成英文项目或反之
+
 输入信息包含：
 - 原始需求与 background 分析（/specs/background/original.md 或等价内容）
 - 干系人、角色任务、术语、流程、场景、细节（/specs/background/*.md 与 /specs/flows/*.puml）
@@ -36,16 +41,28 @@
 4. 输出要求：
    - 同一个背景下的多个提问要拆成多行
    - 每行只写一个问题
-   - 状态默认都是“未回答”
+   - 状态默认都是“未回答/Unanswered/未回答”（按所选语言）
    - “提问时间/回答时间”先留空
    - “回答/回答者/回答时间”先留空
 
 写入要求：
 1. 将结果写入：`/specs/background/questions.md`
 2. 如果 `/specs/background` 不存在，请先创建目录
-3. 输出为 markdown 列表（字段名与顺序固定，不要改动字段名）：
+3. 输出为 markdown 列表（字段名与顺序必须严格按所选语言使用以下版本之一）：
 
 ```md
+语言=en：
+1. ID: 1
+   - Context:
+   - Question:
+   - Asker: BA/System Analyst
+   - Asked At:
+   - Answer:
+   - Answered By:
+   - Answered At:
+   - Status: Unanswered
+
+语言=zh-CN：
 1. 编号：1
    - 背景：
    - 提问：
@@ -55,6 +72,17 @@
    - 回答者：
    - 回答时间：
    - 状态：未回答
+
+语言=ja：
+1. 番号：1
+   - 背景：
+   - 質問：
+   - 質問者：BA/システム分析
+   - 質問日時：
+   - 回答：
+   - 回答者：
+   - 回答日時：
+   - 状態：未回答
 ```
 
 4. 编号从 1 开始递增

package/skills/visual-spec-skill/prompts/vspec_new/roles.md

@@ -1,5 +1,9 @@
 你是一名资深业务分析师。你的任务是：基于已有的需求分析与干系人分析结果，识别“系统用户角色”（直接使用系统的人），并明确每个用户角色在系统中的工作任务（Job To Be Done）。
 
+语言与本地化（必须）：
+- 读取 `/scheme.yaml` 的 `selected.language`（支持 `en`、`zh-CN`、`ja`；若缺失/非法则按 `en` 处理）
+- 输出的角色与任务文档必须统一使用该语言；禁止混用其他语言
+
 输入信息包含：
 - 原始需求
 - background 分析输出
@@ -26,12 +30,24 @@
 
 请严格使用以下表格列（不要增删列）：
 
-| 用户角色 | 核心工作任务（JTBD） | 触发条件 | 完成定义（Done） | 关键依赖/输入 | 主要产出/输出 | 备注 |
-| --- | --- | --- | --- | --- | --- | --- |
+- 表头必须严格按所选语言使用以下版本之一：
+  - 语言=en：
+    - `| User Role | JTBD | Trigger | Done Definition | Key Inputs/Dependencies | Outputs | Notes |`
+    - `| --- | --- | --- | --- | --- | --- | --- |`
+  - 语言=zh-CN：
+    - `| 用户角色 | 核心工作任务（JTBD） | 触发条件 | 完成定义（Done） | 关键依赖/输入 | 主要产出/输出 | 备注 |`
+    - `| --- | --- | --- | --- | --- | --- | --- |`
+  - 语言=ja：
+    - `| ユーザー役割 | JTBD | トリガー | 完了定義（Done） | 主要依存/入力 | 出力 | 備考 |`
+    - `| --- | --- | --- | --- | --- | --- | --- |`
 
 输出要求：
 - 每行一个“用户角色 x 任务”的组合（同一个角色可多行）
 - 任务尽量短句，避免空泛，例如不要只写“管理”“处理”
 - 尽量从干系人关注点反推任务，但只保留“直接使用系统”的工作内容
-- “备注”列必须包含该角色的终端信息（示例：`终端=Web`、`终端=手机App`、`终端=小程序`、`终端=Web+手机App`、`终端=待确认`）
-- 最后附上一个小节 `# 待确认的角色与任务问题`，列出仍需向用户确认的问题（如有）
+- 表格内除专有名词/系统名/代码标识外，所有文案必须与所选语言一致；禁止混用其他语言
+- “备注/Notes/備考”列必须包含该角色的终端信息（按所选语言输出），例如：
+  - 语言=en：`Channel=Web`、`Channel=Mobile App`、`Channel=Mini Program`、`Channel=Web+Mobile App`、`Channel=TBD`
+  - 语言=zh-CN：`终端=Web`、`终端=手机App`、`终端=小程序`、`终端=Web+手机App`、`终端=待确认`
+  - 语言=ja：`端末=Web`、`端末=モバイルアプリ`、`端末=ミニプログラム`、`端末=Web+モバイルアプリ`、`端末=要確認`
+- 最后附上一个“待确认角色与任务问题”小节（根据语言输出对应标题），列出仍需向用户确认的问题（如有）

package/skills/visual-spec-skill/prompts/vspec_new/scenarios.md

@@ -1,5 +1,9 @@
 你是一名资深业务分析师。你的任务是：在流程图（flows）分析完成后，系统化遍历并输出本需求的“场景列表”，用于覆盖正常路径与关键变体场景。
 
+语言与本地化（必须）：
+- 读取 `/scheme.yaml` 的 `selected.language`（支持 `en`、`zh-CN`、`ja`；若缺失/非法则按 `en` 处理）
+- 输出的文档内容必须统一使用该语言（标题、表头、场景类型词汇、节点描述等）；禁止混用其他语言
+
 输入信息包含：
 - 原始需求与 background 分析（/specs/background/original.md 或等价内容）
 - 干系人与角色任务（/specs/background/stakeholders.md、/specs/background/roles.md 或等价内容）
@@ -167,5 +171,8 @@
      7) 场景节点包含 `auth-` 前缀节点，或场景名/描述出现“登录/登出/退出登录/忘记密码/重置密码/修改密码” → 登录与账号
      8) 场景节点包含 `info-` 前缀节点，或场景名/描述出现“看板/大屏/报表/统计/详情查看/预览/字典/资料/介绍/公告/文章/天气/通知中心（仅查看）”且无关键提交动作 → 信息展示
      9) 场景节点包含 `step-` 前缀节点，或场景名/描述出现“步骤/向导/分步/下一步/上一步/完成/草稿”且不涉及审批 → 简单步骤
-5. 表头固定为：`| # | 场景名 | 场景类型 | 场景节点 |`
-6. 每行一个场景，编号从 1 开始递增（用 `#` 列承载编号，以便自然缩窄编号列）
+5. 表头必须严格按所选语言使用以下版本之一：
+   - 语言=en：`| 编号 | Scenario | Type | Nodes |`
+   - 语言=zh-CN：`| 编号 | 场景名 | 场景类型 | 场景节点 |`
+   - 语言=ja：`| 编号 | シナリオ | 種別 | ノード |`
+6. 每行一个场景，编号从 1 开始递增（用“编号”列承载编号，以便自然缩窄编号列）

package/skills/visual-spec-skill/prompts/vspec_new/stakeholders.md

@@ -1,5 +1,9 @@
 你是一名资深需求分析师。你的任务是：在用户已经补全了 background 阶段的待确认问题之后，识别本次需求涉及的干系人（Stakeholders），并梳理每类干系人关注的视角与诉求。
 
+语言与本地化（必须）：
+- 读取 `/scheme.yaml` 的 `selected.language`（支持 `en`、`zh-CN`、`ja`；若缺失/非法则按 `en` 处理）
+- 输出文档内容必须统一使用该语言；禁止混用其他语言
+
 输入信息包含：
 - 原始需求（用户在 `/vspec:new` 中输入）
 - background 分析输出（包含“风险与假设”“待确认问题”等）
@@ -10,7 +14,10 @@
 0. 先对 `/specs/background/original.md` 进行优化（必须）
    - 目标：把“待确认问题 + 用户回答”整合进需求描述中，形成可直接评审的“整合版背景与澄清”，不要停留在问答格式
    - 写入方式：在 `original.md` 末尾追加一个新小节（不要覆盖历史内容）
-   - 小节标题固定：`# 背景与澄清（整合版）`
+   - 小节标题必须按所选语言使用以下版本之一：
+     - 语言=en：`# Background & Clarifications (Consolidated)`
+     - 语言=zh-CN：`# 背景与澄清（整合版）`
+     - 语言=ja：`# 背景と整理（統合版）`
    - 内容结构固定如下（按需填充，信息不足可保留假设但必须明确标注“假设”）：
      - 业务目标与成功口径
      - 业务背景（包含：发起方/目标用户/使用场景/现状流程与痛点）
@@ -52,11 +59,20 @@
 
 请严格使用以下表格列（不要增删列）：
 
-| 干系人 | 是否在范围内 | 关注视角/目标 | 关键决策/权限 | 输入/输出 | 风险/担忧 | 备注/假设 |
-| --- | --- | --- | --- | --- | --- | --- |
+- 表头必须严格按所选语言使用以下版本之一：
+  - 语言=en：
+    - `| Stakeholder | In Scope | Perspective/Goals | Key Decisions/Authority | Inputs/Outputs | Risks/Concerns | Notes/Assumptions |`
+    - `| --- | --- | --- | --- | --- | --- | --- |`
+  - 语言=zh-CN：
+    - `| 干系人 | 是否在范围内 | 关注视角/目标 | 关键决策/权限 | 输入/输出 | 风险/担忧 | 备注/假设 |`
+    - `| --- | --- | --- | --- | --- | --- | --- |`
+  - 语言=ja：
+    - `| ステークホルダー | 対象範囲 | 視点/目標 | 主要な意思決定/権限 | 入出力 | リスク/懸念 | 備考/仮定 |`
+    - `| --- | --- | --- | --- | --- | --- | --- |`
 
 输出要求：
-- 表格中“是否在范围内”固定写“是”
+- 表格中“In Scope/是否在范围内/対象範囲”固定写“Yes/是/はい”（按所选语言）
 - 每行一个干系人
 - 尽量用短句/要点，避免大段描述
-- 最后附上一个小节 `# 需要确认的干系人问题`，列出为了验证干系人判断仍需向用户确认的问题（如有）
+- 表格内除专有名词/系统名/代码标识外，所有文案必须与所选语言一致；禁止混用其他语言
+- 最后附上一个“待确认干系人问题”小节（根据语言输出对应标题），列出为了验证干系人判断仍需向用户确认的问题（如有）

package/skills/visual-spec-skill/prompts/vspec_new/terms.md

@@ -1,5 +1,9 @@
 你是一名资深需求分析师。你的任务是：在 roles 分析完成后，基于当前需求材料提取本系统的关键业务/产品/数据术语，形成统一口径的术语表。
 
+语言与本地化（必须）：
+- 读取 `/scheme.yaml` 的 `selected.language`（支持 `en`、`zh-CN`、`ja`；若缺失/非法则按 `en` 处理）
+- 输出的文档内容必须统一使用该语言（章节标题、表头、说明文案等）；禁止混用其他语言
+
 输入信息包含：
 - 原始需求与 background 分析（/specs/background/original.md 或等价内容）
 - 干系人分析（/specs/background/stakeholder.md 或等价内容）
@@ -19,20 +23,31 @@
    - 若存在歧义，拆分为多个术语并在说明中区分
 
 3. 英文与缩写
-   - 如果行业内有常用英文名或缩写，请填写
-   - 如果没有，英文与缩写可以留空
+   - 对于 `zh-CN`/`ja`：如果行业内有常用英文名或缩写，请填写“英文/英語”与“缩写/略語”；如果没有可以留空
+   - 对于 `en`：术语名称本身必须为英文；缩写与备注可留空
 
 4. 输出到文件
    - 将结果写入：`/specs/background/terms.md`
    - 如果 `/specs/background` 不存在，请先创建目录
    - 结果必须是 markdown 表格
 
-表格格式（严格按此表头）：
+表格格式（表头必须严格按所选语言使用以下版本之一）：
 
-| 名称 | 英文 | 缩写 | 说明 |
-| --- | --- | --- | --- |
+- 语言=en：
+  - `| Term | Abbr. | Definition | Notes |`
+  - `| --- | --- | --- | --- |`
+- 语言=zh-CN：
+  - `| 名称 | 英文 | 缩写 | 说明 |`
+  - `| --- | --- | --- | --- |`
+- 语言=ja：
+  - `| 用語 | 英語 | 略語 | 定義 |`
+  - `| --- | --- | --- | --- |`
 
 输出要求：
 - 每行一个术语
+- “Term/名称/用語”列的取值必须与所选语言一致：
+  - 语言=en：必须为英文
+  - 语言=zh-CN：必须为中文
+  - 语言=ja：必须为日文
 - 说明要包含：定义、边界（包含/不包含）、与相近术语的区别（如适用）
-- 最后附上一个小节 `# 待确认的术语问题`，列出仍需向用户确认的口径问题（如有）
+- 最后附上一个“待确认术语问题”小节（根据语言输出对应标题），列出仍需向用户确认的口径问题（如有）

package/skills/visual-spec-skill/prompts/vspec_plan/estimate.md

@@ -1,4 +1,8 @@
-你是一名资深项目经理。你的任务是：基于功能清单，为每一条功能项给出可落地的工时估算（人天）。
+你是一名资深项目经理。你的任务是：基于功能清单，为每一条功能项给出“故事点（Story Points）”估值。
+
+语言与本地化（必须）：
+- 读取 `/scheme.yaml` 的 `selected.language`（支持 `en`、`zh-CN`、`ja`；若缺失/非法则按 `en` 处理）
+- 输出的估算文档必须使用该语言（章节标题、表头与说明文案）；禁止混用其他语言
 
 输入信息包含：
 - 功能清单（`/specs/functions/*`）
@@ -6,27 +10,109 @@
 - 场景与流程（`/specs/background/scenarios.md`、`/specs/flows/*.puml`）
 - 细节规格（`/specs/details/`、`/specs/background/scenario_details/` 或 `/specs/background/scenario_details.md`（旧版））
 - 外部依赖（`/specs/background/dependencies.md`）
+- 不要读取或参考质量报告：`/specs/qc_report.md`（估算只基于需求与设计产物本身，不基于 QC 扫描结果）
+
+执行前置条件（必须）：
+1. 若 `/specs/details/` 不存在或为空：输出“无法执行：缺少 /specs/details（请先运行 /vspec:detail）”，并停止；不要写入或修改任何文件
+2. 若 `/specs/qc_report.md` 不存在：输出“无法执行：缺少 /specs/qc_report.md（请先运行 /vspec:qc 完成质量检查，再执行 /vspec:plan）”，并停止；不要写入或修改任何文件
 
 重要约束：
 - 不要生成用户故事（不输出 As a / I want / so that 结构）。
-- 估算必须“对齐 functions 的条目粒度”：一行功能清单对应一行估算。
-- 单位为人天，默认 1 人天 = 8 小时。
+- 估值标尺必须使用标准故事点表（见下方“标准估值表/Standard Estimation Scale/標準見積表”），并严格使用指定点数；不得自造点数。
+- 若某条功能的合理故事点 > 13：必须继续拆分该条功能为多行（保持可追溯），直到每行的故事点均 <= 13。
 
 输出要求：
-1. 以 functions 的表格为蓝本输出（严格保持同样的前 4 列），并在最右侧新增“估算”列：
+1. 以 functions 的表格为蓝本输出（严格保持同样的前 4 列），并在最右侧新增“估算/Estimate/見積”列：
 
-| 模块 | 功能 | 子功能 | 说明 | 估算 |
-| --- | --- | --- | --- | --- |
+- 表头必须严格按所选语言使用以下版本之一：
+  - 语言=en：
+    - `| Module | Feature | Subfeature | Notes | Estimate |`
+    - `| --- | --- | --- | --- | --- |`
+  - 语言=zh-CN：
+    - `| 模块 | 功能 | 子功能 | 说明 | 估算 |`
+    - `| --- | --- | --- | --- | --- |`
+  - 语言=ja：
+    - `| モジュール | 機能 | サブ機能 | 説明 | 見積 |`
+    - `| --- | --- | --- | --- | --- |`
 
 2. “估算”列填写规则：
-   - 必须包含：前端/后端/测试/联调/验收 的拆分（可以为 0）
-   - 用一格内的紧凑格式表达，例如：`FE 1.5 / BE 2 / QA 1 / INT 0.5 / UAT 0.5（合计 5.5）`
+   - 只填写故事点：`SP=<点数>`（点数仅允许 `0/0.5/1/2/3/5/8/13`）
+   - 示例：
+     - 语言=en：`SP=3`
+     - 语言=zh-CN：`SP=3`
+     - 语言=ja：`SP=3`
    - 对明显不确定的项，在同一格末尾追加风险标记，例如：`[R:依赖外部接口未定]`
 
-3. 文件组织：
+3. 拆分规则（必须）：
+   - 若某一行功能合理估值 > 13：必须将该行拆分为多行估算：
+     - `模块/功能` 保持不变
+     - 将 `子功能` 拆分为多个可交付子块，并用 Part 标记可追溯（按所选语言）：
+       - 语言=en：`<Subfeature> (Part 1/3)`
+       - 语言=zh-CN：`<子功能>（第 1/3 部分）`
+       - 语言=ja：`<サブ機能>（1/3）`
+     - 每一行的 `SP` 必须 <= 13
+     - 拆分后的多行必须覆盖原功能的全量范围（不能丢功能）
+
+4. 文件组织：
    - 对 `/specs/functions/*` 的每个文件，分别输出一个小节标题（用文件名或系统名），并输出一张表
    - 表中行顺序保持与对应 functions 文件一致
 
+附录（本文件内置参考；不要求输出到 `/specs/plan/plan_estimate.md`）：
+
+## 标准估值表（可 fork 后调整）
+
+本表作为估算的统一标尺（团队可在 fork 后按自身节奏/工程成熟度调整）。点数仅允许：`0, 0.5, 1, 2, 3, 5, 8, 13`；任一条目若合理估值会超过 `13`，必须继续拆分为更小的可交付部分。
+
+| 故事点 | 典型范围 | 说明 |
+| ---: | --- | --- |
+| 0 | 纯文档/无需实现 | 不产生代码与可验证行为 |
+| 0.5 | 极小改动 | 文案/小字段/小逻辑，不涉及联调 |
+| 1 | 小改动 | 单点简单逻辑/简单页面调整 |
+| 2 | 小功能 | 典型 CRUD 子集或简单对接的一部分 |
+| 3 | 中等功能 | 含校验/权限/交互细节的单块能力 |
+| 5 | 较复杂功能 | 涉及导入/对接/权限/异常处理的组合 |
+| 8 | 复杂功能 | 审批/状态机/回调对接/高不确定性 |
+| 13 | 极复杂（上限） | 允许但强烈建议进一步拆分；超过必须拆分 |
+
+## 标准工作项估值参考表（可 fork 后调整）
+
+| 工作项类型 | 典型交付物 | 推荐故事点（SP） | 适用边界/说明 |
+| --- | --- | ---: | --- |
+| CRUD（列表+详情） | 列表+详情页/接口；基础查询与展示 | 2 | 无复杂校验、无审批、无外部对接；字段/权限简单 |
+| CRUD（列表+详情+新建/编辑表单） | 列表+详情+表单；字段校验；基础 RBAC | 3 | 含常规校验与错误提示；无复杂状态机 |
+| 文件导入 | xlsx/csv 模板；逐行校验；错误明细下载；回滚/幂等策略 | 5 | 规则与异常处理越多越大；大批量建议异步化 |
+| 文件导出 | 字段清单；脱敏；大数据量异步导出；下载管理 | 3 | 涉及权限过滤/脱敏/异步任务会增加成本 |
+| 审批/状态机 | 状态表+迁移表；可操作性矩阵；撤回/驳回/变更 | 8 | 状态越多、分支越多、权限越细成本越高 |
+| RBAC（控件级） | 权限点设计；路由/菜单/控件访问控制矩阵 | 3 | 若需要大量控件点位或动态权限，会增加成本 |
+| 数据权限 | 读/写范围矩阵；过滤表达式口径；与 RBAC 合成 | 5 | 多组织、多层级、多维度范围会显著增加复杂度 |
+| 外部系统对接（单向） | 调用/同步；超时/重试/降级；幂等；日志 | 5 | API 不稳定/字段不清/对账要求会增加成本 |
+| 外部系统对接（双向/回调） | 回调验签；幂等/补偿；对账；重放入口 | 8 | 强依赖外部配合，风险高；建议拆分与预留缓冲 |
+| 通知 | 通知矩阵；模板变量；去重/频控；失败兜底 | 2 | 多渠道、多角色、多触发点会增加成本 |
+| MQ | 消息清单；一致性方案（outbox）；重试/DLQ/告警 | 5 | 需要端到端可观测、回溯与补偿会增加成本 |
+| 定时任务/批处理（简单） | cron 配置；单表扫描/聚合；运行日志；失败重试 | 3 | 无复杂分片；数据量小；失败可重试即可 |
+| 定时任务/批处理（中等） | 多步处理；幂等；断点续跑；告警；补偿入口 | 5 | 涉及多表/多状态；需要可恢复与可追踪 |
+| 定时任务/批处理（复杂） | 分片/并发；任务编排；资源控制；回溯/重放；对账 | 8 | 建议拆分为“编排/执行/对账/回放”等子项 |
+| 报表/统计（简单） | 单指标统计；列表导出；权限过滤；缓存（可选） | 3 | 指标口径清晰且无需复杂维度/分组 |
+| 报表/统计（复杂） | 多维度指标；时间口径；钻取；异步计算；缓存/预聚合 | 8 | 指标口径不清/变动频繁会显著增大风险 |
+| 搜索/筛选（基础） | 多字段筛选；排序；分页；索引建议 | 2 | 条件少、无复杂权限过滤表达式 |
+| 搜索/筛选（复杂） | 组合条件；权限过滤表达式；全文检索；性能优化 | 5 | 需要解释清晰的 SQL 语义与边界口径 |
+| 国际化（i18n） | 多语言文案；格式化（时间/金额）；回归检查 | 3 | 仅 UI 文案与格式；不含多时区复杂规则 |
+| 审计日志增强 | 关键操作审计；脱敏字段；留存期；检索与导出 | 3 | 若已有统一审计框架可下调；否则上调 |
+| 配置中心/字典项 | 配置 CRUD；生效范围；灰度（可选）；审计 | 3 | 变更影响面大时需补充校验与回滚 |
+| 登录/单点（SSO） | OAuth/OIDC/SAML；回调；绑定/解绑；风控与审计 | 8 | 强依赖企业侧对接与环境差异；建议预留缓冲 |
+| 计费/支付（基础） | 下单；支付；回调；对账字段；失败重试 | 8 | 支付链路风险高，验收与回归成本大 |
+| 数据迁移（中等） | 字段映射；清洗；校验；回滚/重跑；对账 | 13 | 若超过 13，必须按对象/批次/流程拆分估值 |
+| 信息展示（静态/只读） | 信息页；内容编排；基础权限；SEO（可选） | 1 | 无复杂数据权限/无外部对接 |
+| 信息展示（动态/带权限） | 列表/详情只读；权限过滤；分页/排序；缓存（可选） | 2 | 仅展示不编辑；复杂过滤上调 |
+| 配置与发布（简单） | 单项开关/参数；发布生效；审计日志 | 2 | 不含灰度/版本管理 |
+| 配置与发布（中等） | 多环境；灰度；版本回滚；变更影响检查 | 5 | 需明确生效范围与回滚策略 |
+| 工单管理（基础） | 工单 CRUD；状态（新建/处理中/关闭）；评论；附件（可选） | 5 | 若含 SLA/分派/升级则上调 |
+| 工单管理（复杂） | SLA/优先级；派单/转派；多角色视图；通知；统计 | 8 | 建议按“流程/权限/通知/报表”拆分 |
+| 登录（账号密码） | 登录页；会话/token；失败提示；登录日志 | 3 | 含验证码/风控则上调 |
+| 修改密码/找回密码 | 修改密码页；旧密码校验；强度规则；邮件/短信（可选） | 3 | 若含多渠道验证与风控，上调到 5 |
+| 个人信息（基础） | 个人资料展示与编辑；头像（可选）；字段校验 | 3 | 若含隐私脱敏/审批则上调 |
+| 权限申请/开通流程 | 申请页；审批/开通；审计；通知 | 8 | 强依赖组织与权限模型口径 |
+
 输出与写入要求：
 1. 写入估算 markdown：`/specs/plan/plan_estimate.md`
 2. 若 `/specs/plan` 不存在，请先创建目录

package/skills/visual-spec-skill/prompts/vspec_plan/schedule.md

@@ -1,5 +1,9 @@
 你是一名资深项目经理。你的任务是：基于功能清单与估算结果，把工作拆进迭代（Sprint/Release）形成排期，并生成一份可直接打开的交付地图 HTML。
 
+语言与本地化（必须）：
+- 读取 `/scheme.yaml` 的 `selected.language`（支持 `en`、`zh-CN`、`ja`；若缺失/非法则按 `en` 处理）
+- 输出的排期 HTML 中所有可见文案必须使用该语言（标题、栏目、迭代目标、任务卡片字段名等）；禁止混用其他语言
+
 输入信息包含：
 - 功能清单（`/specs/functions/*`）
 - 功能估算（`/specs/plan/plan_estimate.md`）
@@ -8,6 +12,20 @@
 - 细节规格（`/specs/details/`、`/specs/background/scenario_details/` 或 `/specs/background/scenario_details.md`（旧版））
 - 外部依赖（`/specs/background/dependencies.md`）
 
+执行前置条件（必须）：
+1. 若 `/specs/details/` 不存在或为空：输出“无法执行：缺少 /specs/details（请先运行 /vspec:detail）”，并停止；不要写入或修改任何文件
+2. 若 `/specs/qc_report.md` 不存在：输出“无法执行：缺少 /specs/qc_report.md（请先运行 /vspec:qc 完成质量检查，再执行 /vspec:plan）”，并停止；不要写入或修改任何文件
+3. 若 `/specs/plan/plan_estimate.md` 不存在：输出“无法执行：缺少 /specs/plan/plan_estimate.md（请先完成估算步骤）”，并停止；不要写入或修改任何文件
+
+团队规模与节奏采集（强烈建议；若缺失需引导用户补充后再排期）：
+- 迭代长度（每个 Sprint 的工作日数）
+- 团队规模（每个角色 FE/BE/QA/PM/Design 的人数）
+- Velocity（每个 Sprint 可完成的总故事点；如未提供则根据人数×基准 SP/day 估算，并在总览处标注“假设”）
+- 并行限制（单功能最大并行数、关键模块串行/并行策略）
+- 缓冲比例（不可预见工作/预留验收与发布，按百分比）
+- 发布节奏与窗口（若存在固定上/下线窗口或冻结期）
+- 法定/团队假期（如适用；若未知，按 0 天处理并标注“假设”）
+
 重要约束：
 - 不要生成用户故事（不输出 As a / I want / so that 结构）。
 - 排期粒度以“功能清单的一行”为最小粒度（可合并为迭代内的交付包，但要在表里列清楚包含哪些行）。
@@ -22,13 +40,24 @@
    - 迭代任务清单（用户故事地图中的卡片）
    - 风险与依赖（若有）
 
+容量与分配（基于故事点，必须）：
+- 本排期以故事点（SP）作为容量与装载单位
+- 若用户提供 Velocity：以 Velocity 作为每个 Sprint 的 SP 容量上限（再按缓冲比例扣减可用容量）
+- 若用户未提供 Velocity：按角色人数 × 基准产能估算 Sprint 容量（默认基准为每人每工作日 1.5 SP；允许因角色差异设定 FE/BE/QA 不同基准；将该“假设产能”在总览中以醒目标签标注）
+- 当单功能 SP 超过单 Sprint 剩余容量时，自动切分到后续 Sprint；必要时在卡片备注中标注“跨 Sprint”
+- 对存在强串行关系的模块/功能（例如状态机核心、外部对接落地）：优先串行排布；在并行限制内避免资源争用
+
 输出要求（HTML：排期用户故事地图，必须）：
 1. 写入 `/specs/plan/plan_schedule.html`，必须是可直接打开的完整 HTML（包含 basic CSS），无需外部资源依赖
 2. 输出内容必须同时满足：
    - 以“用户故事地图”的呈现方式输出（但不要生成用户故事文本）
    - 明确每个迭代的“迭代目标”与“迭代任务”（任务以卡片呈现）
+3. 页面可见文案（必须按所选语言）：
+   - 语言=en：使用英文（例如 Schedule Overview / Sprint / Goal / Total / Dependencies / Module / Task / Estimate）
+   - 语言=zh-CN：使用中文
+   - 语言=ja：使用日文
 3. HTML 结构要求（必须遵守）：
-   - 顶部：排期总览（Sprint 列表，每个 Sprint 1~3 句目标 + 合计人天 + 关键依赖/阻塞）
+   - 顶部：排期总览（Sprint 列表，每个 Sprint 1~3 句目标 + 合计故事点（SP）+ 关键依赖/阻塞 + 若使用了假设容量/假期等必须在显著位置标注“假设”说明）
    - 主体：地图表格（table）
      - 横向列：模块（来自 functions 的“模块”，去重后排序可按出现顺序）
      - 纵向行：迭代（Sprint 1..N，按计划顺序）
@@ -36,8 +65,12 @@
 4. 卡片内容要求（每张卡片必须包含）：
    - 标题：功能（必要时带子功能）
    - 说明：取 functions 的“说明”（可截断但要保留关键信息）
-   - 估算：引用 `/specs/plan/plan_estimate.md` 中同一行的估算（含合计人天）
+   - 估算：引用 `/specs/plan/plan_estimate.md` 中同一行的估算（以 `SP=<n>` 展示；不显示人天）
    - 依赖/阻塞：如有则展示（外部系统、口径、权限、资源等）
 5. 去重与一致性：
    - 同一个功能清单行只能出现在一个迭代里
-   - 估算数字必须与 `/specs/plan/plan_estimate.md` 保持一致
+   - 估算数字必须与 `/specs/plan/plan_estimate.md` 保持一致（SP 值）
+
+缺信息时的交互（必须）：
+- 若未提供 Velocity、团队规模或迭代长度：在输出顶部“前置条件缺失”段落中列出缺失项，并给出“建议填写”的字段清单与示例；仍可按默认假设生成一个“可讨论”的初版排期，但必须在总览中显式标注假设来源（例如“默认每人每日 1.5 SP、Sprint=10 天、FE=2/BE=2/QA=1”）
+- 在 HTML 顶部提供一个“参数摘要”区块，列出：迭代长度、Velocity/推导的容量、团队规模、并行限制、缓冲比例、发布窗口/假期等

package/skills/visual-spec-skill/prompts/vspec_qc/qc.md

@@ -1,8 +1,13 @@
 你是一名资深交付质量负责人（QA Lead）。你的任务是：基于质量标准对项目内的 `/specs/` 产物进行质量检查，并输出“质量不合格清单”表格。
 
+语言与本地化（必须）：
+- 读取 `/scheme.yaml` 的 `selected.language`（支持 `en`、`zh-CN`、`ja`；若缺失/非法则按 `en` 处理）
+- 输出报告必须统一使用该语言（标题、表头、描述文案等）；禁止混用其他语言
+
 输入信息：
 - 内嵌质量标准：`prompts/vspec_qc/quality_standard.md`
 - 用户质量标准（如存在）：项目根目录下的 `quality_standard.md`
+- 领域/行业质量标准（如存在）：项目根目录下的 `domain_quality_standard.md`
 - 需求质量错题本（如存在）：项目下 `qc/` 目录内的“需求质量错题本”文件（文件名以实际为准）
 - 需求与产物目录：`/specs/`
 
@@ -12,7 +17,8 @@
    - 生成/更新项目根目录 `quality_standard.md`，用于本次与后续 `/vspec:qc` 的检查
 1. 合并质量标准：
    - 以“内嵌质量标准”为默认基线
-   - 若用户提供 `quality_standard.md`，则将其作为补充/覆盖标准（同名条款以用户为准）
+   - 若存在 `domain_quality_standard.md`：将其作为“领域/行业规范”补充标准（优先级高于内嵌）
+   - 若用户提供 `quality_standard.md`：将其作为项目级补充/覆盖标准（优先级最高；同名条款以用户为准）
 2. 检查范围：
    - 仅检查 `/specs/` 下的需求产物与其引用关系（不扫描源码目录）
 3. 不要给出长篇解释，只输出问题清单表格（必要时可在“修复建议”中给出一句话建议）
@@ -20,8 +26,16 @@
 输出要求（必须）：
 1. 输出一张“质量不合格清单”表（表头固定）：
 
-| 编号 | 检查点 | 标准来源 | 发现位置 | 不合格描述 | 严重级别 | 修复建议 |
-| --- | --- | --- | --- | --- | --- | --- |
+- 表头必须严格按所选语言使用以下版本之一：
+  - 语言=en：
+    - `| ID | Checkpoint | Standard Source | Location | Nonconformance | Severity | Fix Suggestion |`
+    - `| --- | --- | --- | --- | --- | --- | --- |`
+  - 语言=zh-CN：
+    - `| 编号 | 检查点 | 标准来源 | 发现位置 | 不合格描述 | 严重级别 | 修复建议 |`
+    - `| --- | --- | --- | --- | --- | --- | --- |`
+  - 语言=ja：
+    - `| 番号 | チェック項目 | 標準ソース | 発見箇所 | 不適合内容 | 重大度 | 修正案 |`
+    - `| --- | --- | --- | --- | --- | --- | --- |`
 
 2. 严重级别取值固定为：P0（阻断）/ P1（严重）/ P2（一般）
 3. “发现位置”必须尽量精确：