architext 0.0.4 → 0.0.5

package/dist/templates/zh/briefs/_base.md

@@ -6,7 +6,7 @@
 
 ## 项目概述
 
-**项目名称**: 
+**项目名称**:
 **一句话描述**: [项目是什么、为谁服务、解决什么问题]
 **问题陈述**: [目标用户遇到的核心痛点？现有方案哪里不足？]
 
@@ -20,12 +20,27 @@
 
 ## 核心任务
 
-> MVP 必须实现的任务（建议 3-7 个），每项一句话描述预期行为。
+> 必须实现的任务，每项一段话描述预期行为。
 > 详细 Spec 在 `/archi.plan` 阶段定义，此处只需明确"做什么"。
 
-1. 
-2. 
-3. 
+1.
+2.
+3.
+
+---
+
+## 业务流程
+
+> 如果你的项目有明确的用户旅程或核心工作流，在此描述。
+> 不需要画图——用文字描述步骤即可，AI 会据此理解系统行为。
+> 没有的话留空，AI 会从核心任务中推导。
+
+<!-- 写法参考：
+### [流程名称]
+1. 用户 [动作] → 系统 [响应]
+2. 用户 [动作] → 系统 [响应]
+3. ...
+-->
 
 ---
 
@@ -36,7 +51,7 @@
 >
 > 写法参考：
 > - **[任务/页面名]**: 描述具体行为、流程、约束
-> - 可附截图/草图链接
+> - 可附截图/草图（见下方"设计资产"）
 
 ---
 
@@ -62,7 +77,7 @@
 
 ## 工程规范
 
-> 团队已有的工程约定。不确定的留空，AI 会基于技术栈推荐合理默认值。
+> 已有的工程约定。不确定的留空，AI 会基于技术栈推荐合理默认值。
 
 **仓库形态**: [Monorepo (Turborepo/Nx/pnpm workspaces) / 单体仓库]
 **架构模式**: [例：MFA / FSD / Clean Architecture / 分层架构 / 无偏好（AI 推荐）]
@@ -78,14 +93,33 @@
 > AI 需要知道哪些东西已经存在——避免重复造轮子或做出冲突决策。
 
 **项目起点**: [全新项目 / 基于已有代码库（简述现状和技术债）]
-**设计资产**: [Figma 链接 / 设计稿截图 / 无（AI 自行设计）]
-**品牌规范**: [已有 Logo/配色/字体 → 描述或附链接 / 无]
 **已有 API/后端**: [接口文档链接 / 简述可用端点 / 无（需从零搭建）]
 **第三方服务**: [已确定使用的服务，例：Auth0, Stripe, AWS S3, Resend...]
 **现有数据**: [已有数据库/数据源？格式？需要迁移？/ 无]
 
 ---
 
+## 设计资产
+
+> 为 AI 提供视觉/设计输入，直接影响项目的 UI 和架构决策质量。
+> 两种方式提供文件：
+> 1. **本地文件**: 将文件放入 `brief-assets/` 目录，按下方格式引用
+> 2. **外部链接**: 直接填写 URL
+>
+> 引用格式: `- [语义标签] ./brief-assets/文件名`
+>
+> 写法参考:
+> - [竞品参考-首页] ./brief-assets/linear-dashboard.png
+> - [我的草图] ./brief-assets/sketch-v1.png
+> - [品牌色板] ./brief-assets/brand-colors.pdf
+> - [API 文档] ./brief-assets/api-spec.yaml
+> - [数据库 Schema] ./brief-assets/schema.sql
+
+**设计稿/截图**: [按上方格式引用本地文件 / Figma 链接 / 无（AI 自行设计）]
+**品牌规范**: [已有 Logo/配色/字体 → 引用文件或描述 / 无]
+
+---
+
 <!-- @slot:style -->
 
 ## 边界与约束
@@ -94,7 +128,6 @@
 - [例：本期不做国际化 / 不做移动端适配 / 不做付费功能]
 
 **硬性约束**:
-- **时间**: [例：4 周 MVP / 无硬性 deadline]
 - **兼容性**: [例：Chrome 90+ / Node 18+ / iOS 15+]
 - **性能**: [例：首屏 < 2s / API P99 < 500ms / 无特殊要求]
 - **合规/无障碍**: [例：WCAG 2.1 AA / GDPR / 无]
@@ -112,5 +145,4 @@
 
 ## 补充说明
 
-> 任何上述未涵盖的信息：背景故事、特殊需求、已有决策的原因、团队技术偏好等。
-
+> 任何上述未涵盖的信息：背景故事、特殊需求、已有决策的原因等。

package/dist/templates/zh/briefs/_modules.md

@@ -5,10 +5,37 @@
 <!-- @tech:data -->
 **数据库**: [例：PostgreSQL / MongoDB / SQLite]
 **ORM / Query Builder**: [例：Prisma / Drizzle / TypeORM]
+
+### 数据模型草案
+
+> 如果你已经知道核心数据实体和关系，在此描述。不需要写完整 Schema——列出实体名和关键字段即可。
+> AI 会在 `/archi.plan` 阶段据此生成详细的数据模型，此处只需明确"有什么数据"。
+> 没有的话留空，AI 会从核心任务中推导。
+
+<!-- 写法参考：
+- **用户 (User)**: email, name, role (admin/user), avatar
+- **文章 (Post)**: title, content, status (draft/published), author → User
+- **评论 (Comment)**: body, author → User, post → Post
+- User 1:N Post, Post 1:N Comment
+-->
+
 <!-- @end -->
 
 <!-- @tech:api -->
 **API 风格**: [例：RESTful / GraphQL / gRPC / tRPC]
+
+### 已有 API 端点
+
+> 如果已有后端 API（自建或第三方），在此列出核心端点。也可将完整文档放入 `brief-assets/`。
+> 没有的话留空。
+
+<!-- 写法参考：
+- `POST /auth/login` → 返回 JWT token
+- `GET /users/:id` → 用户详情
+- `POST /posts` → 创建文章（需认证）
+- 完整文档: [API 文档] ./brief-assets/api-spec.yaml
+-->
+
 <!-- @end -->
 
 <!-- @tech:cli -->

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

@@ -1,5 +1,5 @@
 <protocol_audit>
-  **Trigger**: `/archi.audit [id]`
+  **Trigger**: `/archi.audit [id]` | 自然语言触发时由 Workflow Dispatch 自动加载
   **Goal**: 独立深度代码审查。带 `<id>` 审查该任务的代码实现；无 `<id>` 执行项目级体检。不修改代码，仅输出审查报告与修复工单。
 
 <meta>
@@ -10,52 +10,40 @@
       2.  **Evidence-Based**: 每个发现须附文件路径、行号、代码片段。
       3.  **Actionable Output**: 每个问题须附推荐修复命令（`/archi.fix`, `/archi.edit` 等）。
       4.  **Vision Anchored**: 始终以 `vision.md` 为方向基准，检测偏离。
-      5.  **Report Persistence**: 审查结果须写入文件 — 任务级 → `tasks/<id>_*/audit.md`（覆盖），项目级 → `audits/YYYY-MM-DD.md`（按日期存档，同日覆盖）。
+      5.  **Report Persistence**: 审查结果须写入文件 — 任务级 → `tasks/<id>_*/audit.md`（覆盖），项目级 → `audits/YYYY-MM-DD.md`（按日期存档）。
+      6.  **IDE-Native First**: 利用 IDE 原生能力驱动执行节奏，本协议定义质量标准和检查点，不对抗 IDE 的规划/执行机制。
     </principles>
 </meta>
 
 <step_1_resolve>
-    **Role**: 系统分析师
     **Mode Gate**:
 
     | 输入 | 模式 | 后续步骤 |
     |:---|:---|:---|
-    | `/archi.audit <id>` | 任务级深度审查 | step_2_task → step_3_report |
-    | `/archi.audit` | 项目级体检 | step_2_project → step_3_report |
+    | `/archi.audit <id>` | 任务级深度审查 | step_2a_task → step_3_report |
+    | `/archi.audit` | 项目级体检 | step_2b_project → step_3_report |
 
     **任务级 — Resolve ID**:
-    1.  从 `[[__DOCS_DIR__]]/global/roadmap.json` 解析 `<id>` → Task Name、Slug、状态。
+    1.  从 roadmap.json 解析 `<id>` → Task Name、Slug、状态。
     2.  **Status Gate** — 仅 `active` 或 `done` 可审查:
 
         | 状态 | 处理 |
         |:---|:---|
         | `active` / `done` | 通过 |
-        | `pending` | 拒绝 — 无代码可审查，先运行 `/archi.plan` + `/archi.code` |
+        | `pending` | 拒绝 — 无代码可审查 |
         | `blocked` | 拒绝 — 前置依赖未完成 |
 
-    3.  **Load Context**:
-        - `[[__DOCS_DIR__]]/global/vision.md` — 项目方向基准
-        - `[[__DOCS_DIR__]]/tasks/<id>_<Slug>/spec.md` — 功能逻辑
-        - `[[__DOCS_DIR__]]/tasks/<id>_<Slug>/plan.json` — 任务清单
-        - `[[__DOCS_DIR__]]/tasks/<id>_<Slug>/ui.md` — 任务 UI 范围声明(如存在)
-        - （仅ui项目） `[[__DOCS_DIR__]]/global/ui_context.md` — AI 屏幕索引（定位对应屏幕 ID）
-        - （仅ui项目） `[[__DOCS_DIR__]]/global/ui_concept.html` — 只读视觉参考（#10 合规对比的视觉标准源）
-        - `[[__DOCS_DIR__]]/tasks/<id>_<Slug>/audit.md` — 上次审计报告(如存在，用于对比)
-        - `02_tech_stack.md` — 技术红线
-        - （仅ui项目） `[[__DOCS_DIR__]]/global/design_tokens.json`
-        - （仅data项目） `[[__DOCS_DIR__]]/global/data_snapshot.json`
-    4.  读取该任务对应的所有代码文件。
+    3.  **Load**: vision.md（方向基准）+ task docs (spec/plan/ui) + 前次 audit.md（对比用）+ project context (tech_stack/design_tokens/data_snapshot/ui_context/ui_concept)。读取该任务对应的所有代码文件。
 
     **项目级 — Load Overview**:
-    1.  读取 `[[__DOCS_DIR__]]/global/vision.md`、`roadmap.json`、`map.json`。
-    2.  读取 `02_tech_stack.md`。
-    3.  扫描 `[[__DOCS_DIR__]]/tasks/` 目录结构。
-    4.  读取项目代码入口文件与关键模块。
+    1.  读取 vision.md、roadmap.json、map.json、02_tech_stack.md。
+    2.  扫描 tasks/ 目录结构。
+    3.  读取项目代码入口文件与关键模块。
 
-    **Output**: 审查范围与上下文清单。
+    **Output**: 审查范围与上下文清单。进入 step_2a_task 或 step_2b_project。
 </step_1_resolve>
 
-<step_2_task>
+<step_2a_task>
     **Role**: 首席审计官
     **Scope**: 任务级深度代码审查（仅 `/archi.audit <id>` 时执行）。
 
@@ -72,17 +60,17 @@
     | 7 | **Tech Stack 合规** | 对照 `02_tech_stack.md`：违禁模式、过时 API、硬编码 |
     | 8 | **安全性** | 敏感信息泄露、输入未校验、注入风险、权限检查 |
     | 9 | **性能** | 不必要全量导入/大循环/无用计算/内存泄漏/N+1 查询 |
-    | 10 | （本任务涉及ui时） **Design 合规** | 样式是否用 Token 定义的视觉模式；无硬编码魔法值；实现与 `ui_concept.html` 对应屏幕视觉一致 |
-    | 11 | （本任务涉及data时） **数据一致性** | 字段名/类型与 `data_snapshot.json` 是否一致 |
+    | 10 | （本任务涉及ui时） **Design 合规** | Token 使用；无硬编码魔法值；与 `ui_concept.html` 视觉一致 |
+    | 11 | （本任务涉及data时） **数据一致性** | 字段名/类型与 `data_snapshot.json` 一致 |
     | 12 | （仅i18n项目） **I18n 合规** | 无硬编码字符串；须用 Key/字典引用 |
     | 13 | **Orphan .gitkeep** | 目录已有其他文件时仍存在 `.gitkeep` — 须删除 |
-    | 14 | **Spec-Code 漂移** | 代码中的接口/类型/行为是否与 `spec.md` 一致；手动变更是否已同步到文档 |
-    | 15 | （本任务涉及ui时） **UI 引用完整性** | `ui.md` 中的 `ref: ui_concept.html#S-XX` 指针是否仍然有效；被引用的屏幕/组件是否因 edit/revise 后已改名或删除 |
+    | 14 | **Spec-Code 漂移** | 接口/类型/行为与 `spec.md` 一致；手动变更已同步文档 |
+    | 15 | （本任务涉及ui时） **UI 引用完整性** | `ui.md` 中 `ref: ui_concept.html#S-XX` 指针是否仍有效 |
 
-    **Output**: 按维度分组的发现列表，每项含级别、位置、描述。
-</step_2_task>
+    **Output**: 按维度分组的发现列表，每项含级别、位置、描述。进入 step_3_report。
+</step_2a_task>
 
-<step_2_project>
+<step_2b_project>
     **Role**: 首席审计官
     **Scope**: 项目级健康体检（仅 `/archi.audit` 无参数时执行）。
 
@@ -90,22 +78,18 @@
     |:---|:---|:---|
     | 1 | **Vision 漂移** | `roadmap.json` 任务方向与 `vision.md` 是否一致 |
     | 2 | **架构一致性** | `map.json` vs 实际目录结构，有无漂移或未注册模块 |
-    | 3 | **Roadmap 健康度** | 一致性 + 进度统计 + 长期 blocked 任务 + 依赖环检测 |
+    | 3 | **Roadmap 健康度** | 一致性 + 进度统计 + 长期 blocked + 依赖环检测 |
     | 4 | **文档完整度** | 各 Task 是否有 spec.md + plan.json；有无孤儿目录 |
-    | 5 | **Tech Stack 全局合规** | 抽查关键入口与模块，检测全局性违规 |
+    | 5 | **Tech Stack 全局合规** | 抽查关键入口与模块 |
     | 6 | **跨 Task 一致性** | 重复逻辑、命名冲突、接口不一致 |
-    | 7 | **Orphan .gitkeep** | 目录已有其他文件时仍存在 `.gitkeep` — 须删除 |
+    | 7 | **Orphan .gitkeep** | 目录已有其他文件时仍存在 `.gitkeep` |
 
-    扫描后标注优先级，推荐需深度审查的 Task：
-    - `done` 但 plan 未全部完成的
-    - 代码量大但无测试的
-    - 长期 `active` 未推进的
+    扫描后推荐需深度审查的 Task（`done` 但 plan 未全完成 / 代码量大无测试 / 长期 `active`）。
 
-    **Output**: 项目健康概览 + 深度审查推荐列表。
-</step_2_project>
+    **Output**: 项目健康概览 + 深度审查推荐列表。进入 step_3_report。
+</step_2b_project>
 
 <step_3_report>
-    **Role**: 报告撰写员
     **Action**:
 
     **Issue Classification**:
@@ -123,26 +107,28 @@
       -> 推荐修复：/archi.fix <ID> <描述> 或 /archi.edit <ID> <描述>
     ```
 
-    **Action Routing** (根据问题类型推荐命令):
+    **Action Routing**:
 
     | 问题类型 | 推荐命令 |
     |:---|:---|
-    | Bug（逻辑错误、边界遗漏） | `/archi.fix <ID> <描述>` |
-    | Spec 缺漏（功能未完整实现） | `/archi.edit <ID> <补充描述>` |
-    | 架构级问题（全局违规） | `/archi.revise <描述>` |
-    | 功能未完成（plan 虚标 done） | `/archi.code <ID>` |
-    | 小问题（命名、注释、简化） | 下次 `/archi.code` 时一并处理 |
-
-    **Report Structure**:
-    1.  审查概要（模式、范围、日期）
-    2.  发现列表（按级别排序：CRITICAL → WARNING → INFO）
-    3.  统计摘要（各级别数量）
-    4.  修复工单汇总（可直接执行的命令列表）
-    5.  Next Steps 表格
+    | Bug | `/archi.fix <ID> <描述>` |
+    | Spec 缺漏 | `/archi.edit <ID> <补充描述>` |
+    | 架构级问题 | `/archi.revise <描述>` |
+    | 功能未完成 | `/archi.code <ID>` |
+    | 小问题 | 下次 `/archi.code` 时一并处理 |
+
+    **Pre-signoff Checklist** (写入文件前须逐项确认):
+    □ （任务级）15 个审查维度全部覆盖，不适用项标注 N/A（非静默跳过）
+    □ （项目级）7 个检查项全部评估
+    □ 每个 CRITICAL/WARNING 发现已附 `文件:行号` + 代码片段
+    □ 每个发现已附推荐修复命令（/archi.fix / /archi.edit 等）
+    □ 报告已写入对应文件（任务级: tasks/<id>/audit.md；项目级: audits/YYYY-MM-DD.md）
+
+    **Report Structure**: 审查概要 → 发现列表（CRITICAL → WARNING → INFO）→ 统计摘要 → 修复工单汇总 → Next Steps。
 
     **Write Report File**:
     - 任务级 → `[[__DOCS_DIR__]]/tasks/<id>_<Slug>/audit.md`（覆盖式）
-    - 项目级 → `[[__DOCS_DIR__]]/audits/YYYY-MM-DD.md`（按日期存档，同日覆盖）
+    - 项目级 → `[[__DOCS_DIR__]]/audits/YYYY-MM-DD.md`（按日期存档）
 
     **Output**: 完整审查报告（同时输出到对话和写入文件）。
 </step_3_report>

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

@@ -1,5 +1,5 @@
 <protocol_code>
-  **Trigger**: `/archi.code <id>`
+  **Trigger**: `/archi.code <id>` | 自然语言触发时由 Workflow Dispatch 自动加载
   **Goal**: 基于 `tasks/<id>_<Slug>/plan.json` 任务清单，完成功能开发；遵循 `02_tech_stack.md`（仅ui项目: 同时遵循 `design_tokens.json`）；通过构建、类型、Lint、格式化、测试与审计。
 
 <meta>
@@ -13,13 +13,13 @@
       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 流程:
 
         | 状态 | 处理 |
@@ -29,23 +29,12 @@
         | `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 范围声明(如存在)
-        - 仅Complex任务: `[[__DOCS_DIR__]]/tasks/<id>_<Slug>/design.md` — 技术方案设计(如存在)：状态机/流水线/协议定义、参数表、不变量
-        - 仅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`
-        - **Read Refs** (如有): 读取 `[[__DOCS_DIR__]]/refs/index.json`（如存在），根据 tags 与 spec.md 中涉及的技术域语义匹配，仅读取命中的 ref 文件作为补充上下文；`refs/` 不存在或为空时跳过。
+    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)**: 数据模型/接口/校验
@@ -58,32 +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` 除外）。
-    - 仅Complex任务: **Design Adherence**: 存在 `design.md` 时，实现须严格遵循其定义的状态机/流水线/协议；参数须引用 design.md § 3 的值（禁硬编码其他值）；须满足 § 4 所有 Invariants（可用 assert 或运行时检查守护）。
-    - **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 | 检查项 | 要求 |
     |:---|:---|:---|
@@ -91,26 +78,25 @@
     | | 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；无验证字段时按下表类型兜底。
 
     | 项目类型 | 验证动作 | 通过标准 |
     |:---|:---|:---|
-    | 本任务涉及ui时 | 浏览器操作目标功能路径 | 渲染正常，交互无报错，控制台无异常 |
+    | 本任务涉及ui时 | 浏览器操作目标功能路径 | 渲染正常，交互无报错 |
     | 本任务涉及api时 | 调用新增/修改的 endpoint | 状态码与 Body 符合 spec |
-    | 本任务涉及cli时 | 执行目标命令（含正常参数 + 边界参数） | stdout 符合预期，exit code 正确 |
-    | 本任务涉及lib时 | 运行示例代码或 playground 验证导出 API | 无运行时错误，返回值正确 |
-    | 本任务涉及mobile时 | 模拟器/真机操作目标功能 | 界面正常，交互响应 |
-    | 本任务涉及desktop时 | 启动应用操作目标功能 | 窗口正常，功能可用 |
+    | 本任务涉及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>
@@ -131,23 +117,35 @@
 </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,87 +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。
+    - （仅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`（范围声明）；如须新增屏幕，[[SKILL: archi-ui-wireframe|调用 skill 或提示用户运行]][[NO-SKILL: （Skill 未安装：请阅读 `[[__DOCS_DIR__]]/skills/archi-ui-wireframe/SKILL.md` 并提示用户按该文档执行）]]（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有修改） [[SKILL: archi-ui-wireframe|按 skill 的协议，按以下规则同步更新 `ui_concept.html` + `ui_context.md`（Skill 作为唯一写者）]][[NO-SKILL: （Skill 未安装：请阅读 `[[__DOCS_DIR__]]/skills/archi-ui-wireframe/SKILL.md` 并遵循其协议执行）]]：
+    - 根据 `[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_3_5 开始前全部完成):
+    **Terminal Gate** (禁止跳过): 标准检查 (task --check + render)。
     | 步骤 | 命令 | 通过条件 |
     |:---|:---|:---|
-    | 1 | `npx archi task --check` | 无 ERROR 级问题 |
-    | 2 | `npx archi render` | `.md` 视图生成完成 |
-    | 3 | [当前 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_3_5_verify>
+<step_4_verify>
     **Role**: 独立审查官
 
-    [[SUBAGENT: archi-silent-audit|mode: plan-docs, context: 审查 step_2 更新的 spec.md/ui.md 与 step_3 追加的 plan.json 新 Phase，确保文档逻辑自洽、新 Phase tasks 可验证]][[NO-SKILL: （Skill 未安装：请阅读 `[[__DOCS_DIR__]]/skills/archi-silent-audit/SKILL.md`，按 mode: plan-docs 的审查维度表逐项检查）]]
+    [[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_3_5_verify>
+</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 中已执行）
 
-<step_4_summary>
     **Action** (Gate 须在 step_3 完成):
     **Output**: Task 更新摘要，含 Spec/UI/Plan 变更概要和 Next Steps 表格。推荐运行 `/archi.code <ID>`。
-</step_4_summary>
+</step_5_summary>
 
 </protocol_edit>