architext 0.0.3 → 0.0.5

package/dist/templates/zh/docs/prompts/code.md

@@ -1,6 +1,6 @@
 <protocol_code>
-  **Trigger**: `/archi.code <id>`
-  **Goal**: 基于 `tasks/<id>_<Slug>/plan.json` 任务清单，完成功能开发；遵循 `02_tech_stack.md`（[?UI] 同时遵循 `design_tokens.json`）；通过构建、类型、Lint、格式化、测试与审计。
+  **Trigger**: `/archi.code <id>` | 自然语言触发时由 Workflow Dispatch 自动加载
+  **Goal**: 基于 `tasks/<id>_<Slug>/plan.json` 任务清单，完成功能开发；遵循 `02_tech_stack.md`（仅ui项目: 同时遵循 `design_tokens.json`）；通过构建、类型、Lint、格式化、测试与审计。
 
 <meta>
     <style>Deterministic, Type-Safe, SOTA-First</style>
@@ -13,37 +13,28 @@
       5.  **No Commit Policy**: 未经授权不提交；以补丁呈现变更。
       6.  **Static Check First**: 须通过所有静态检查(类型/Lint/格式化)。
       7.  **Plan Completion Gate**: 结束前验证 Plan 完成度。AI 可完成的任务须全部完成，仅豁免「人工介入」和「不可抗力」类。
+      8.  **IDE-Native First**: 利用 IDE 原生能力驱动执行节奏，本协议定义质量标准和检查点，不对抗 IDE 的规划/执行机制。
     </principles>
 </meta>
 
 <step_1_resolve>
-    **Role**: 系统分析师
     **Action**:
-    1.  **Resolve ID**: 从 `[[__DOCS_DIR__]]/global/roadmap.json` 解析 `<id>` → Task Name、Slug、阶段/状态。
+    1.  **Resolve ID**: 从 roadmap.json 解析 `<id>` → Task Name、Slug、阶段/状态。
     2.  **Status Gate** — 仅 `active` 可进入 code 流程:
 
         | 状态 | 处理 |
         |:---|:---|
-        | `active` 🟢 | 通过，继续 |
-        | `pending` ⏳ | 拒绝 — 提示先运行 `/archi.plan <ID>` |
-        | `blocked` 🧱 | 拒绝 — 前置依赖未完成 |
-        | `done` ✅ | 拒绝 — 已完成，如需修改用 `/archi.edit <ID>` |
-
-    3.  **Load Context** (用 Roadmap `📁 Slug` 定位):
-        - `[[__DOCS_DIR__]]/tasks/<id>_<Slug>/spec.md` — 逻辑与场景
-        - `[[__DOCS_DIR__]]/tasks/<id>_<Slug>/ui.md` — 本任务 UI 范围声明(如存在)
-        - [?UI] `[[__DOCS_DIR__]]/global/ui_context.md` — AI 屏幕索引（屏幕 ID/路由/状态/导航关系/共享组件）
-        - [?UI] `[[__DOCS_DIR__]]/global/ui_concept.html` — 只读视觉参考（实现时以此校准布局结构，禁基于此重新设计，设计已在 ui.md 确定）
-        - `[[__DOCS_DIR__]]/tasks/<id>_<Slug>/plan.json` — 任务拆解（含 `notes` 速记，执行时须参照）
-        - `02_tech_stack.md` — 技术红线
-        - [?UI] `[[__DOCS_DIR__]]/global/design_tokens.json`
-        - [?Data] `[[__DOCS_DIR__]]/global/data_snapshot.json`
+        | `active` | 通过，继续 |
+        | `pending` | 拒绝 — 提示先运行 `/archi.plan <ID>` |
+        | `blocked` | 拒绝 — 前置依赖未完成 |
+        | `done` | 拒绝 — 已完成，如需修改用 `/archi.edit <ID>` |
+
+    3.  **Load**: task docs (spec/ui/design/plan) + project context (tech_stack/design_tokens/data_snapshot/ui_context/ui_concept) + refs（按 tags 匹配，仅读命中文件）。
 
     **Output**: 待实施任务的原子清单，标注依赖与顺序。
 </step_1_resolve>
 
 <step_2_plan>
-    **Role**: Tech Lead
     **Action**:
     生成执行蓝图（根据项目类型动态调整）：
     - **Phase A (Domain/Data/API)**: 数据模型/接口/校验
@@ -56,31 +47,30 @@
 </step_2_plan>
 
 <step_3_implement>
-    **Role**: 资深工程师
     **Protocol**:
     - **Read First**: 修改前须读取目标文件；遵循项目现有代码风格。
     - **Use Existing Stack**: 仅用 `02_tech_stack.md` 声明的技术与库。
-    - [?UI] **Design Tokens Only**: 样式严格使用 Token/Preset 定义的视觉模式；禁硬编码魔法值（颜色、尺寸、间距等）。
+    - （本任务涉及ui时） **Design Tokens Only**: 样式严格使用 Token/Preset；禁硬编码魔法值。
     - **Type-Safe**: 补齐类型定义；用项目技术栈的类型系统守护边界。
-    - **Code Organization**: 遵循 `02_tech_stack.md` 中定义的架构模式与文件归位策略。
-    - **Comments**: 解释 Why 而非 What；拒绝废话注释。
-    - **Naming**: 自解释命名；拒绝 `a`, `b`, `tmp` 等无意义名（循环变量 `i` 除外）。
-    - **Error Handling**: 禁吞错/禁静默失败；须正确传播错误并给调用方可观测反馈（UI: Toast；CLI: Exit Code；API: Status Code + Body）。
+    - **Code Organization**: 遵循 `02_tech_stack.md` 架构模式与文件归位策略。
+    - **Comments**: 解释 Why 而非 What。
+    - **Naming**: 自解释命名；拒绝无意义名。
+    - 仅Complex任务: **Design Adherence**: 存在 `design.md` 时，实现须严格遵循其状态机/流水线/协议；参数引用 § 3 的值；须满足 § 4 所有 Invariants。
+    - **Error Handling**: 禁吞错/禁静默失败；须正确传播并给调用方可观测反馈。
     - **Robustness**: 显式处理边界(Loading/Error/Empty/Timeout)；禁只写 Happy Path。
-    - **SOTA**: 遵循 tech_stack 定义的最佳实践；拒绝明确禁止的过时模式。
-    - **Scaffold Safety**: 脚手架在非空目录可能覆盖文件 — 须在新目录生成并保护 `[[__DOCS_DIR__]]/`；删除/覆盖操作须先列清单并确认。
-    - **.gitkeep Cleanup**: 空目录可用 `.gitkeep` 占位以便 Git 跟踪；向目录新增其他文件时须删除该目录下的 `.gitkeep`。
+    - **SOTA**: 遵循 tech_stack 最佳实践；拒绝明确禁止的过时模式。
+    - **Scaffold Safety**: 非空目录须保护 `[[__DOCS_DIR__]]/`。
+    - **.gitkeep Cleanup**: 向目录新增文件时删除 `.gitkeep`。
     - **Patch Output**: 以补丁形式输出变更，附 Code Reference。
-    - **Progress Tracking**: 每完成一个 task 后，立即更新 `plan.json` 对应 task 的 `done: true`；禁在 signoff 时批量更新（会话中断后进度将丢失）。
+    - **Progress Tracking**: 每完成一个 task 后，立即更新 `plan.json` 对应 `done: true`；禁 signoff 时批量更新。
 
-    **Action**: 按 Phase A/B/C 逐项实施；每项产出完整、工程化的代码（含必要测试）；新增文件/目录须与 tech_stack 一致。
+    **Action**: 按 Phase A/B/C 逐项实施；产出完整、工程化的代码（含必要测试）。
 </step_3_implement>
 
 <step_4_validate>
-    **Role**: 验证工程师
     **Action** (失败须修复后重跑；命令以 `02_tech_stack.md` Section 5 为准):
 
-    **Automated Check**: 运行 `[[__DOCS_DIR__]]/scripts/validate`（如存在）；否则按以下清单逐项手动执行。
+    **Automated Check**: 运行 `[[__DOCS_DIR__]]/scripts/validate`（如存在）；否则按以下清单逐项执行。
 
     | Phase | 检查项 | 要求 |
     |:---|:---|:---|
@@ -88,73 +78,74 @@
     | | Type Check | 零类型错误 |
     | | Lint | 零 Lint 错误（警告须说明原因） |
     | | Format | 符合格式规范（失败则自动修复后重检） |
-    | **Test** | Existing Tests | 运行已有测试套件全部通过；禁因新代码破坏旧测试 |
-    | | New Coverage | 为新增/修改的关键逻辑补充测试；纯样式调整可豁免 |
+    | **Test** | Existing Tests | 全部通过；禁破坏旧测试 |
+    | | New Coverage | 为新增/修改的关键逻辑补充测试 |
 
     **Task Verification (硬性要求)**
 
-    > 禁仅通过代码审查或自动化测试就标记完成；须实际运行目标功能并验证。
-    > 如 dev server 未启动，先执行 `[[__DOCS_DIR__]]/scripts/dev-up`。
-    > **优先读取 `notes.验证`**: 先读当前 task 的 `notes` 字段末尾 `验证: [...]` 部分，以其指定操作执行具体 e2e；`notes` 无验证字段时按下表类型兜底。
+    > 禁仅通过代码审查就标记完成；须实际运行目标功能并验证。
+    > **优先读取 `notes.验证`**: 先读当前 task `notes` 末尾 `验证: [...]` 部分执行 e2e；无验证字段时按下表类型兜底。
 
     | 项目类型 | 验证动作 | 通过标准 |
     |:---|:---|:---|
-    | [?Web] | 浏览器操作目标功能路径 | 渲染正常，交互无报错，控制台无异常 |
-    | [?API] | 调用新增/修改的 endpoint | 状态码与 Body 符合 spec |
-    | [?CLI] | 执行目标命令（含正常参数 + 边界参数） | stdout 符合预期，exit code 正确 |
-    | [?Lib] | 运行示例代码或 playground 验证导出 API | 无运行时错误，返回值正确 |
-    | [?Mobile] | 模拟器/真机操作目标功能 | 界面正常，交互响应 |
-    | [?Desktop] | 启动应用操作目标功能 | 窗口正常，功能可用 |
+    | 本任务涉及ui时 | 浏览器操作目标功能路径 | 渲染正常，交互无报错 |
+    | 本任务涉及api时 | 调用新增/修改的 endpoint | 状态码与 Body 符合 spec |
+    | 本任务涉及cli时 | 执行目标命令（含正常+边界参数） | stdout 符合预期，exit code 正确 |
+    | 本任务涉及lib时 | 运行示例代码验证导出 API | 无运行时错误，返回值正确 |
+    | 本任务涉及mobile时 | 模拟器/真机操作 | 界面正常，交互响应 |
+    | 本任务涉及desktop时 | 启动应用操作 | 窗口正常，功能可用 |
 
-    **Evidence**: Output 须附验证结果（命令输出摘要 / 截图 / 错误日志）。
-    **Fallback**: 验证持续失败且怀疑环境问题 → `[[__DOCS_DIR__]]/scripts/dev-reset` → `[[__DOCS_DIR__]]/scripts/dev-up` → 重试。
+    **Evidence**: 须附验证结果（命令输出摘要/截图/错误日志）。
+    **Fallback**: 验证持续失败 → `scripts/dev-reset` → `scripts/dev-up` → 重试。
 
     **Output**: 每项检查 ✅/❌ 状态与原因；Task Verification 证据。
 </step_4_validate>
 
-<step_5_audit>
-    **Role**: 首席审计官
-    **Checklist**:
-    1.  **Tech Consistency**: 与 `02_tech_stack.md` 一致（库/模式/API 风格）。
-    2.  [?UI] **Design Compliance**: 样式仅用 Token/Preset 视觉模式；无硬编码魔法值。
-    3.  [?Data] **Data Integrity**: 符合 `data_snapshot.json`；字段名/类型一致。
-    4.  **SOTA**: 拒绝过时模式；采用 tech_stack 最佳实践。
-    5.  [?UI] **Accessibility**: 含必要无障碍属性。
-    6.  [?I18n] **I18n**: 无硬编码字符串；须用 Key/字典引用。
-    7.  **Performance**: 避免不必要大依赖/全量导入/无用计算/内存泄漏。
-    8.  **Security**: 无敏感信息泄露；输入有校验。
-    9.  **Static Check Zero**: 所有静态检查问题已解决。
-    10. **step_4 Gate**: 确认 step_4 所有检查（Static + Test + Task Verification）已通过。
-    11. **联动检查**: 读取 `[[__DOCS_DIR__]]/global/map.json` 中的 `featureRelations` 数组，将本次实现的功能与各条 `sources` 字段做语义对比。命中时输出提示：`⚠️ 联动: [aggregator] — [checkNote]`，提醒在当前实现完成后确认聚合方是否需要同步。`featureRelations` 为空则跳过。
-    12. **数据治理**: 本次实现引入新内容时，须直接写入对应全局索引：
-
-        | 触发条件 | 文件 | 动作 |
-        |:---|:---|:---|
-        | 新业务实体 · 动作 · 共享工具 | `dictionary.json` | 直接追加写入 |
-        | 新错误场景 | `error_codes.json` | 直接追加写入 |
-        | [?Data] Schema 实际变更 | `data_snapshot.json` | 直接同步 |
-
-    细节问题可 Auto-Fix 并说明；重大风险标注 `⚠️ Risk` 并提出替代方案。
-</step_5_audit>
+<step_5_verify>
+    **Role**: 独立审查官
+
+    **5A. 代码质量审查**:
+    [[SUBAGENT: archi-silent-audit|mode: code-impl, context: 审查 step_3 实现的代码（Tech/SOTA/Security/Performance + 条件维度）]][[NO-SKILL: （Skill 未安装：请阅读 `[[__DOCS_DIR__]]/skills/archi-silent-audit/SKILL.md`，按 mode: code-impl 的审查维度表逐项检查）]]
+
+    **5B. 联动检查**:
+    [[SUBAGENT: archi-feature-relations|mode: check, context: 将本次实现的功能与 featureRelations sources 做语义对比]][[NO-SKILL: （Skill 未安装：请阅读 `[[__DOCS_DIR__]]/skills/archi-feature-relations/SKILL.md`，按 mode: check 的逻辑执行）]]
+
+    **5C. 数据治理同步**:
+    [[SUBAGENT: archi-data-sync|context: 扫描本次实现引入的新业务实体/错误码/Schema，按 03_data_governance.md 规则增量同步]][[NO-SKILL: （Skill 未安装：请阅读 `[[__DOCS_DIR__]]/skills/archi-data-sync/SKILL.md`，按其执行协议操作）]]
+
+    [[INCLUDE: shared/verify-result-handling.md]]
+</step_5_verify>
 
 <step_6_signoff>
-    **Terminal Gate** (禁止跳过，须在输出总结前全部完成):
+    **Terminal Gate** (禁止跳过):
     | 步骤 | 命令 | 通过条件 |
     |:---|:---|:---|
     | 1 | `npx archi plan <ID>` | 全部完成或仅豁免项；未通过禁签收，回到 step_3 |
     | 2 | `npx archi task <ID> --status done` | 任务状态已更新 |
-    | 3 | `npx archi task --check` | 无 ERROR 级问题 |
-    | 4 | `npx archi render` | `.md` 视图生成完成 |
+    | 3 | 标准检查 (task --check + render) | 无 ERROR + 视图生成 |
 
     **Action** (Gate 通过后):
-    1.  确认 `plan.json` 各 task `done` 标记已全部更新（应在 step_3 实时完成，此处做最终校验）。
-    2.  **Drift Warning**: 对比本次代码变更与 `spec.md` 的关键点位（接口签名、返回类型、Gherkin 场景关键操作）。如发现代码超出 spec 覆盖范围 → 标注 `⚠️ Spec 漂移`，建议运行 `/archi.edit <ID>` 同步文档。
-    3.  输出完成任务清单与补丁链接(Code Reference)。
+    1.  确认 `plan.json` 各 task `done` 标记已全部更新。
+    2.  **Drift Warning**: 对比代码变更与 `spec.md` 关键点位。发现超出 spec 覆盖范围 → 标注 `⚠️ Spec 漂移`，建议 `/archi.edit <ID>`。
+    3.  输出完成任务清单与补丁链接。
     4.  提供下一步建议与 Git Commit Suggestion（Conventional Commits）。
 
-    **Checkpoint** (Output 前须确认): □ Terminal Gate 全部执行
+    **Pre-signoff Checklist** (Output 前须逐项确认):
+    □ plan.json — 每个 task done 标记已实时更新（非 signoff 时批量操作）
+    □ Step 4 — 构建/类型检查/Lint/格式化 全部通过
+    □ Step 4 — 每种项目类型的 Task Verification 已执行并附 Evidence
+    □ Step 5A Silent Audit — 已执行，所有 CRITICAL 问题已修复
+    □ Step 5B featureRelations 联动检查 — 已执行
+    □ Step 5C 数据治理同步 — 已执行
+    □ Terminal Gate — npx archi plan <ID> 全部完成（仅豁免项除外）
+
+    **Output**: 完成摘要，含已完成任务、豁免项(如有)、Git Commit 建议、Next Steps：
 
-    **Output**: 完成摘要，含已完成任务、豁免项(如有)、Git Commit 建议、Next Steps 表格。
+    | 优先级 | 动作 | 说明 |
+    |:---|:---|:---|
+    | 推荐 | `/archi.audit <ID>` | 对实现做独立审查 |
+    | （有 Spec 漂移时） | `/archi.edit <ID>` | 先更新文档再继续 |
+    | （有后续 pending 任务时） | `/archi.plan <下一个 pending ID>` | 规划下一个任务 |
 </step_6_signoff>
 
 </protocol_code>

package/dist/templates/zh/docs/prompts/edit.md

@@ -1,5 +1,5 @@
 <protocol_edit>
-  **Trigger**: `/archi.edit <id> [context]`
+  **Trigger**: `/archi.edit <id> [context]` | 自然语言触发时由 Workflow Dispatch 自动加载
   **Goal**: 基于新需求/修改意见，更新已纳管模块的 Spec/UI 文档，并追加开发计划。
 
 <meta>
@@ -10,78 +10,83 @@
       2.  **Incremental**: 仅追加新 Task 到 Plan，保留已完成历史（除非需回滚）。
       3.  **Conflict Check**: 检查新需求是否与 tech_stack / design_tokens 冲突。
       4.  **Frontmatter Preservation**: 禁破坏现有文档 Metadata。
+      5.  **IDE-Native First**: 利用 IDE 原生能力驱动执行节奏，本协议定义质量标准和检查点，不对抗 IDE 的规划/执行机制。
     </principles>
 </meta>
 
 <step_1_load>
-    **Role**: 产品经理
     **Action**:
     - 读取 `[[__DOCS_DIR__]]/tasks/<ID>_<Slug>/` 下的 spec.md、ui.md、plan.json。
-    - [?UI] 读取 `[[__DOCS_DIR__]]/global/ui_context.md`（定位本功能对应的屏幕范围及导航关系）。
-    - 检测 spec.md 中的 `Spec-Status` 字段：
-      - `Full` → 正常流程，进入 step_2。
-      - `Stub` → 进入 step_1_5_enrich。
-    - [?重大 UX 变更] 快速搜索同类产品最佳实践。
+    - （仅ui项目） 读取 ui_context.md（定位本功能对应的屏幕范围及导航关系）。
+    - 检测 spec.md 中的 `Spec-Status`：`Full` → 正常流程 step_2 | `Stub` → step_1_5_enrich。
+    - （重大UX变更） 快速搜索同类产品最佳实践。
 </step_1_load>
 
 <step_1_5_enrich>
-    **Role**: 逆向工程师
     **Trigger**: spec.md 中 `Spec-Status: Stub`（由 `/archi.inherit` 生成的轻量快照）。
 
     **Action**:
     1. 告知用户："该功能仅有轻量快照，须先补全完整 spec 才能执行修改。"
-    2. 从 stub 的"关联文件"section 提取源码路径。
-    3. 逐一读取关联文件，中度扫描（入口 + 核心逻辑）。
-    4. 基于代码分析，将 stub 补全为完整 spec：
-       - 保留原有概述和关键流程
-       - 补充 Gherkin Scenarios（覆盖正常流程 + 异常路径）
-       - 补充接口/类型定义（如该功能是其他功能的上游）
-    5. 更新 `Spec-Status: Stub → Full`。
-    6. [?UI] 如模块有 UI → 同步生成或更新 `ui.md`（范围声明）；如须新增屏幕，提示用户运行 `archi-ui-wireframe` Skill（Skill 会同步更新 `ui_concept.html` + `ui_context.md`）。
-    7. 生成 `plan.json`（全部 task 为 done，记录已实现内容）。
-    8. 向用户输出补全后的 spec 摘要。
-
-    **Gate**: 用户确认补全内容正确后，继续 step_2_refine_docs。
+    2. 从 stub"关联文件"提取源码路径，逐一读取（入口+核心逻辑）。
+    3. 基于代码分析补全为完整 spec：保留原有概述和流程，补充 Gherkin Scenarios + 接口/类型定义。
+    4. 更新 `Spec-Status: Stub → Full`。
+    5. （仅ui项目） 如模块有 UI → 同步生成 `ui.md`；须新增屏幕时，[[SKILL: archi-ui-wireframe|调用 skill]][[NO-SKILL: （Skill 未安装：请阅读 `[[__DOCS_DIR__]]/skills/archi-ui-wireframe/SKILL.md`）]]。
+    6. 生成 `plan.json`（全部 task 为 done）。
+    7. 向用户输出补全后的 spec 摘要。
+
+    **Gate**: 用户确认后继续 step_2_refine_docs。
     **异常**: 关联文件不存在/已移动 → 提示用户更新路径。
 </step_1_5_enrich>
 
 <step_2_refine_docs>
-    **Role**: 需求分析师 & 设计师
     **Action**:
-    - 根据 `[context]` 修改 spec.md（逻辑/规则变更）和 ui.md（结构/交互变更）。
-    - [?UI 修改] 按以下规则同步更新 `ui_concept.html` + `ui_context.md`（Skill 作为唯一写者）：
+    - 根据 `[context]` 修改 spec.md 和 ui.md。
+    - （ui有修改） [[SKILL: archi-ui-wireframe|按 skill 的协议同步更新 `ui_concept.html` + `ui_context.md`]][[NO-SKILL: （Skill 未安装：请阅读 `[[__DOCS_DIR__]]/skills/archi-ui-wireframe/SKILL.md`）]]：
 
       | 变更类型 | 判定标准 | 处理方式 |
       |:---|:---|:---|
-      | 无屏幕影响 | 仅逻辑/数据变更，无视觉差异 | 仅改 spec.md，`ui_concept.html` / `ui_context.md` 不动 |
-      | 轻微 UI 调整 | 新增/修改状态、弹窗、局部区域，不改整体布局 | 调用 Skill（修改屏幕模式）更新两个文件，输出 `MODIFIED: S-XX` |
-      | 屏幕结构变更 | 布局重构、新增独立屏幕、导航路径变化 | 调用 Skill（修改屏幕模式）更新两个文件，输出 `MODIFIED: S-XX`；若已完成 Phase 2 着色，同步重新着色 |
-      | 功能缩减 | 屏幕/区域整体移除 | 调用 Skill（删除屏幕模式）更新两个文件，输出 `REMOVED: S-XX` |
+      | 无屏幕影响 | 仅逻辑/数据变更 | 仅改 spec.md |
+      | 轻微 UI 调整 | 新增/修改状态、弹窗、局部区域 | 调用 skill 更新，输出 `MODIFIED: S-XX` |
+      | 屏幕结构变更 | 布局重构、新增屏幕、导航变化 | 调用 skill 更新 |
+      | 功能缩减 | 屏幕/区域整体移除 | 调用 skill 删除，输出 `REMOVED: S-XX` |
 
-    - 需求模糊时向用户提问 (A/B/C/D 选项) 确认细节。
+    - 需求模糊时向用户提问确认。
 
-    **Output**: 更新后的 Spec、UI 文档及 `ui_concept.html` / `ui_context.md` 变更摘要。
+    **Output**: 更新后的文档及变更摘要。
 </step_2_refine_docs>
 
 <step_3_update_plan>
-    **Role**: Tech Lead
     **Action**:
-    - 在 `plan.json` 的 `phases` 数组中追加新 Phase 对象。
-    - 列出具体 Tasks (API update, UI tweak, Test update)；每项须可验证。
-    - **状态转换**: 若当前任务 status=`done`，追加 Phase 后须将状态重置为 `active`（否则后续 `/archi.code` 将被 Status Gate 拒绝）。
+    - 在 `plan.json` 追加新 Phase，列出具体 Tasks；每项须可验证。
+    - **状态转换**: status=`done` 时追加 Phase 后须重置为 `active`。
 
-    **Terminal Gate** (禁止跳过，须在 step_4 输出前全部完成):
+    **Terminal Gate** (禁止跳过): 标准检查 (task --check + render)。
     | 步骤 | 命令 | 通过条件 |
     |:---|:---|:---|
-    | 1 | `npx archi render` | `.md` 视图生成完成 |
-    | 2 | [当前 status=done] `npx archi task <ID> --status active` | 任务状态已重置为 active |
+    | 3 | [当前 status=done] `npx archi task <ID> --status active` | 状态已重置 |
 
-    **Output**: 追加了新任务的 plan.json；若执行了状态转换，输出 `MODIFIED: roadmap.json <ID>.status done→active`。
+    **Output**: 追加了新任务的 plan.json；若执行状态转换，输出 `MODIFIED: roadmap.json <ID>.status done→active`。进入 step_4_verify。
 </step_3_update_plan>
 
-<step_4_summary>
+<step_4_verify>
+    **Role**: 独立审查官
+
+    [[SUBAGENT: archi-silent-audit|mode: plan-docs, context: 审查 step_2 更新的 spec.md/ui.md 与 step_3 追加的 plan.json 新 Phase]][[NO-SKILL: （Skill 未安装：请阅读 `[[__DOCS_DIR__]]/skills/archi-silent-audit/SKILL.md`，按 mode: plan-docs 审查）]]
+
+    [[INCLUDE: shared/verify-result-handling.md]]
+</step_4_verify>
+
+<step_5_summary>
+    **Pre-signoff Checklist** (输出前须逐项确认):
+    □ spec.md — 已按 context 更新，变更已追踪
+    □ （ui有修改）ui.md + ui_concept.html + ui_context.md — 已同步更新
+    □ plan.json — 新 Phase 已追加（历史任务完整保留）
+    □ （原 status=done）roadmap.json — status 已重置为 active
+    □ Step 4 Silent Audit — 已执行，所有 CRITICAL 问题已修复
+    □ Terminal Gate — task --check 无 ERROR（step_3 中已执行）
+
     **Action** (Gate 须在 step_3 完成):
     **Output**: Task 更新摘要，含 Spec/UI/Plan 变更概要和 Next Steps 表格。推荐运行 `/archi.code <ID>`。
-</step_4_summary>
+</step_5_summary>
 
 </protocol_edit>

package/dist/templates/zh/docs/prompts/fix.md

@@ -1,5 +1,5 @@
 <protocol_fix>
-  **Trigger**: `/archi.fix [id] <context>`
+  **Trigger**: `/archi.fix [id] <context>` | 自然语言触发时由 Workflow Dispatch 自动加载
   **Goal**: 针对 Bug 进行诊断并直接执行修复。若未提供 `[id]`，自动定位相关功能模块。
 
 <meta>
@@ -11,6 +11,7 @@
       3.  **Root Cause**: 须分析根因，而非修补表面。
       4.  **Test-Driven**: 修复计划须含新增测试用例。
       5.  **Auto-Discovery**: 若未指定 ID，通过 Context 语义搜索定位 Task。
+      6.  **IDE-Native First**: 利用 IDE 原生能力驱动执行节奏，本协议定义质量标准和检查点，不对抗 IDE 的规划/执行机制。
     </principles>
 </meta>
 
@@ -21,8 +22,8 @@
         - 有 `<id>`: 锁定 `tasks/<ID>_<Slug>/`。
         - 无 `<id>`: 分析 `[context]` 搜索最相关模块。
           唯一匹配 → 自动锁定 | 多个匹配 → 列出候选询问 | 无法定位 → 报错请求指定 ID。
-    2.  读取目标目录下所有文档 (`spec.md`, `ui.md`, `plan.json`) 与相关代码。
-    3.  读取 `02_tech_stack.md`（确保修复方式不违反技术红线）和 `[[__DOCS_DIR__]]/global/vision.md`（确保修复方向不偏离项目愿景）。
+    2.  读取目标目录下所有文档与相关代码。
+    3.  读取 02_tech_stack.md（技术红线）和 vision.md（方向基准）。
     4.  分析 `[context]`，结合代码逻辑定位潜在故障点。
     5.  **Hypothesis**: 提出 1-3 个根因假设。
 
@@ -30,30 +31,23 @@
 </step_1_diagnose>
 
 <step_2_plan_fix>
-    **Role**: Tech Lead
     **Action**:
-    - 更新 `[[__DOCS_DIR__]]/tasks/<ID>_<Slug>/plan.json`，在 `phases` 数组中追加 phase 对象，`name` 为 `Bugfix: <Bug Title>`。
+    - 更新 plan.json，追加 phase `Bugfix: <Bug Title>`。
     - Tasks: 1) 创建复现测试(Red) 2) 修复(Green) 3) 回归测试。
 
-    **Terminal Gate** (禁止跳过，须在 step_5 输出前全部完成):
-    | 步骤 | 命令 | 通过条件 |
-    |:---|:---|:---|
-    | 1 | `npx archi render` | `.md` 视图生成完成 |
+    **Terminal Gate** (禁止跳过): 标准检查 (task --check + render)。
 
     **Output**: 追加了修复任务的 plan.json。
 </step_2_plan_fix>
 
 <step_3_execute_fix>
-    **Role**: 资深工程师 (Surgical Fix — 仅改 Bug，禁扩散)
     **Action**:
-    - 根据 Plan 直接修改代码。
-    - 仅修复 Bug，禁借机重构或改无关代码。
-    - 错误处理遵循 `code.md` 规范（禁吞错/禁静默失败）。
+    - 根据 Plan 直接修改代码。仅修复 Bug，禁借机重构。
+    - 错误处理遵循 `code.md` 规范。
 </step_3_execute_fix>
 
 <step_4_verify>
-    **Role**: QA 工程师
-    **Terminal Gate** (禁止跳过，须在 step_5 输出前全部完成):
+    **Terminal Gate** (禁止跳过):
     | 步骤 | 命令 | 通过条件 |
     |:---|:---|:---|
     | 1 | 运行构建命令 | 构建成功 |
@@ -62,25 +56,38 @@
     | 4 | 运行测试 | 复现测试 + 回归测试通过 |
 
     任何失败须修复至通过。
+
+    **代码质量审查**:
+    [[SUBAGENT: archi-silent-audit|mode: code-impl, context: 审查修复代码，重点 Tech/Security/Performance + Spec Immutable]][[NO-SKILL: （Skill 未安装：请阅读 `[[__DOCS_DIR__]]/skills/archi-silent-audit/SKILL.md`，按 mode: code-impl 检查）]]
+
+    [[INCLUDE: shared/verify-result-handling.md]]
 </step_4_verify>
 
-<step_4_5_plan_update>
-    **Role**: Tech Lead
+<step_5_plan_update>
     **Action**:
-    1. 更新 `plan.json`：将 Bugfix Phase 中已完成的 tasks 的 `done` 设为 `true`。
-    2. [当前 status=`done` 且 Bugfix Phase 全部通过] → 保持 `done` 不变。
-    3. [Bugfix Phase 有未通过项] → 运行 `npx archi task <ID> --status active`；signoff 输出中标注须重新 `/archi.code` 完成剩余修复。
+    1. 更新 plan.json Bugfix Phase 中已完成 tasks 的 `done: true`。
+    2. [status=`done` 且 Bugfix 全通过] → 保持 `done`。
+    3. [Bugfix 有未通过项] → `npx archi task <ID> --status active`；signoff 标注须重新 `/archi.code`。
+
+    **Output**: `MODIFIED: plan.json Bugfix Phase done 标记`。进入 step_6_summary。
+</step_5_plan_update>
 
-    **Output**: `MODIFIED: plan.json Bugfix Phase done 标记`（如状态变更，附 `MODIFIED: roadmap.json <ID>.status`）。
-</step_4_5_plan_update>
+<step_6_summary>
+    **Pre-signoff Checklist** (输出前须逐项确认):
+    □ 根因已分析（非表面修补），Hypothesis 已在 step_1 输出
+    □ plan.json — Bugfix Phase 已追加（step_2）
+    □ 复现测试已创建并验证（Red → Green）
+    □ 代码修复仅针对 Bug，无借机重构
+    □ Step 4 Terminal Gate — 构建/类型检查/Lint/测试全部通过
+    □ Step 4 Silent Audit — 已执行，所有 CRITICAL 问题已修复
+    □ plan.json Bugfix Phase — done 标记已更新（step_5）
 
-<step_5_summary>
     **Output**: Bug 修复摘要，含 Root Cause 分析、修复内容、新增测试，以及 Next Steps 表格：
 
     | 优先级 | 动作 | 说明 |
     |:---|:---|:---|
-    | 推荐 | `/archi.audit <ID>` | 重新审查，确认修复完整且无新引入问题 |
-    | 可选 | `/archi.code <ID>` | 如有 Bugfix Phase 未完成项，继续实现 |
-</step_5_summary>
+    | 推荐 | `/archi.audit <ID>` | 重新审查，确认修复完整 |
+    | 可选 | `/archi.code <ID>` | 如有未完成项，继续实现 |
+</step_6_summary>
 
 </protocol_fix>

package/dist/templates/zh/docs/prompts/help.md

@@ -14,17 +14,15 @@
 </meta>
 
 <step_1_load_context>
-    **Role**: 项目观察员
     **Action**:
-    1.  读取 `[[__DOCS_DIR__]]/global/roadmap.json` — 仅提取每个 task 的 `id/title/status/deps/tag` 字段；`goal/notes` 字段跳过（导航和状态聚合不需要这些详情）。
-    2.  扫描 `[[__DOCS_DIR__]]/tasks/` 目录 — 获取已有 Task 及其文档完整度（有无 spec.md / ui.md / plan.json）。
-    3.  [?question] 若用户带了问题，根据问题语义定位相关文件（spec / plan / vision / tech_stack / data_snapshot 等），按需读取。
+    1.  **Load**: roadmap.json（仅 id/title/status/deps/tag，跳过 goal/notes）。
+    2.  **Scan Tasks**: 扫描 tasks/ 目录 — 获取已有 Task 及其文档完整度（有无 spec.md / ui.md / plan.json）。
+    3.  [?question] 若用户带了问题，根据语义定位相关文件按需读取。
 
-    **Output**: 内部上下文（不直接输出给用户）。
+    **Output**: 内部上下文（不输出给用户）。
 </step_1_load_context>
 
 <step_2_route>
-    **Role**: 路由器
     **Action**: 根据输入分支：
 
     | 输入 | 分支 |
@@ -35,33 +33,27 @@
 </step_2_route>
 
 <step_3_navigate>
-    **Role**: 项目导航员
     **Action**:
     1.  **判断项目阶段**:
 
         | 信号 | 阶段 | 建议 |
         |:---|:---|:---|
         | roadmap.json 不存在 | 未初始化 | 新项目 → `/archi.start`；已有代码 → `/archi.inherit` |
-        | 有 roadmap 但无 Task 目录 | 已启动，未规划 | 运行 `/archi.scope` 规划新任务 |
-        | 有 Legacy stub (Spec-Status: Stub) | 已继承，未补全 | 运行 `/archi.edit LEG-xx` 补全 spec |
-        | 有 active 任务且 plan.json 完整 | 可编码 | 运行 `/archi.code <ID>` |
-        | 有 active 任务但缺 spec/plan | 规划未完成 | 运行 `/archi.plan <ID>` 补全 |
-        | 所有任务 done | 已完成 | 运行 `/archi.scope` 规划新任务或发布 |
+        | 有 roadmap 但无 Task 目录 | 已启动，未规划 | `/archi.scope` 规划新任务 |
+        | 有 Legacy stub (Spec-Status: Stub) | 已继承，未补全 | `/archi.edit LEG-xx` 补全 spec |
+        | 有 active 任务且 plan.json 完整 | 可编码 | `/archi.code <ID>` |
+        | 有 active 任务但缺 spec/plan | 规划未完成 | `/archi.plan <ID>` 补全 |
+        | 所有任务 done | 已完成 | `/archi.scope` 规划新任务或发布 |
         | 有 blocked 任务 | 存在阻塞 | 提示阻塞原因与前置依赖 |
 
-    2.  **输出格式**:
-        - 一句话总结当前状态
-        - 推荐的下一步操作（含具体命令）
-        - 如有多个可选路径，列出优先级排序（最多 3 个）
+    2.  **Output**: 一句话总结状态 + 推荐下一步（含命令）+ 可选路径（≤3 个，按优先级）。
 </step_3_navigate>
 
 <step_4_answer>
-    **Role**: 项目顾问
     **Action**:
-    1.  解析 `[question]` 语义，定位相关项目文件。
-    2.  读取相关文件，综合回答。
-    3.  若问题涉及操作（如"怎么做 X"），回答须包含具体命令建议。
-    4.  若信息不足以回答，明确告知缺少什么，而非编造。
+    1.  解析 `[question]` 语义，定位相关项目文件并读取。
+    2.  综合回答；涉及操作的问题须包含具体命令建议。
+    3.  信息不足以回答时，明确告知缺少什么，禁编造。
 
     **Output**: 基于项目上下文的简洁回答 + 相关文件引用。
 </step_4_answer>