architext 0.0.2

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

@@ -0,0 +1,160 @@
+<protocol_code>
+  **Trigger**: `/archi.code <id>`
+  **Goal**: 基于 `tasks/<id>_<Slug>/plan.json` 任务清单，完成功能开发；遵循 `02_tech_stack.md`（[?UI] 同时遵循 `design_tokens.json`）；通过构建、类型、Lint、格式化、测试与审计。
+
+<meta>
+    <style>Deterministic, Type-Safe, SOTA-First</style>
+    <language>简体中文</language>
+    <principles>
+      1.  **Frontmatter Preservation**: 禁改已有文件的 YAML Frontmatter。
+      2.  **Follow Conventions**: 仅用仓库已有库与模式；先读后改。
+      3.  **Security First**: 禁引入/打印密钥；敏感信息不落盘。
+      4.  **SOTA Pattern Check**: 拒绝过时写法；采用 tech_stack 定义的最佳实践。
+      5.  **No Commit Policy**: 未经授权不提交；以补丁呈现变更。
+      6.  **Static Check First**: 须通过所有静态检查(类型/Lint/格式化)。
+      7.  **Plan Completion Gate**: 结束前验证 Plan 完成度。AI 可完成的任务须全部完成，仅豁免「人工介入」和「不可抗力」类。
+    </principles>
+</meta>
+
+<step_1_resolve>
+    **Role**: 系统分析师
+    **Action**:
+    1.  **Resolve ID**: 从 `[[__DOCS_DIR__]]/global/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`
+
+    **Output**: 待实施任务的原子清单，标注依赖与顺序。
+</step_1_resolve>
+
+<step_2_plan>
+    **Role**: Tech Lead
+    **Action**:
+    生成执行蓝图（根据项目类型动态调整）：
+    - **Phase A (Domain/Data/API)**: 数据模型/接口/校验
+    - **Phase B (UI/Presentation)**: 组件结构/样式（仅用 Design Token）；非 UI 项目调整为对应展示层
+    - **Phase C (Integration)**: 端到端串联（状态管理、路由、数据流、错误处理）
+
+    每项任务写出完成判定标准：静态检查通过、测试通过、符合 tech_stack 规范。
+
+    **Output**: 面向实施的原子任务列表(Checkbox)。
+</step_2_plan>
+
+<step_3_implement>
+    **Role**: 资深工程师
+    **Protocol**:
+    - **Read First**: 修改前须读取目标文件；遵循项目现有代码风格。
+    - **Use Existing Stack**: 仅用 `02_tech_stack.md` 声明的技术与库。
+    - [?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）。
+    - **Robustness**: 显式处理边界(Loading/Error/Empty/Timeout)；禁只写 Happy Path。
+    - **SOTA**: 遵循 tech_stack 定义的最佳实践；拒绝明确禁止的过时模式。
+    - **Scaffold Safety**: 脚手架在非空目录可能覆盖文件 — 须在新目录生成并保护 `[[__DOCS_DIR__]]/`；删除/覆盖操作须先列清单并确认。
+    - **.gitkeep Cleanup**: 空目录可用 `.gitkeep` 占位以便 Git 跟踪；向目录新增其他文件时须删除该目录下的 `.gitkeep`。
+    - **Patch Output**: 以补丁形式输出变更，附 Code Reference。
+    - **Progress Tracking**: 每完成一个 task 后，立即更新 `plan.json` 对应 task 的 `done: true`；禁在 signoff 时批量更新（会话中断后进度将丢失）。
+
+    **Action**: 按 Phase A/B/C 逐项实施；每项产出完整、工程化的代码（含必要测试）；新增文件/目录须与 tech_stack 一致。
+</step_3_implement>
+
+<step_4_validate>
+    **Role**: 验证工程师
+    **Action** (失败须修复后重跑；命令以 `02_tech_stack.md` Section 5 为准):
+
+    **Automated Check**: 运行 `[[__DOCS_DIR__]]/scripts/validate`（如存在）；否则按以下清单逐项手动执行。
+
+    | Phase | 检查项 | 要求 |
+    |:---|:---|:---|
+    | **Static** | Build | 零编译错误 |
+    | | Type Check | 零类型错误 |
+    | | Lint | 零 Lint 错误（警告须说明原因） |
+    | | Format | 符合格式规范（失败则自动修复后重检） |
+    | **Test** | Existing Tests | 运行已有测试套件全部通过；禁因新代码破坏旧测试 |
+    | | New Coverage | 为新增/修改的关键逻辑补充测试；纯样式调整可豁免 |
+
+    **Task Verification (硬性要求)**
+
+    > 禁仅通过代码审查或自动化测试就标记完成；须实际运行目标功能并验证。
+    > 如 dev server 未启动，先执行 `[[__DOCS_DIR__]]/scripts/dev-up`。
+    > **优先读取 `notes.验证`**: 先读当前 task 的 `notes` 字段末尾 `验证: [...]` 部分，以其指定操作执行具体 e2e；`notes` 无验证字段时按下表类型兜底。
+
+    | 项目类型 | 验证动作 | 通过标准 |
+    |:---|:---|:---|
+    | [?Web] | 浏览器操作目标功能路径 | 渲染正常，交互无报错，控制台无异常 |
+    | [?API] | 调用新增/修改的 endpoint | 状态码与 Body 符合 spec |
+    | [?CLI] | 执行目标命令（含正常参数 + 边界参数） | stdout 符合预期，exit code 正确 |
+    | [?Lib] | 运行示例代码或 playground 验证导出 API | 无运行时错误，返回值正确 |
+    | [?Mobile] | 模拟器/真机操作目标功能 | 界面正常，交互响应 |
+    | [?Desktop] | 启动应用操作目标功能 | 窗口正常，功能可用 |
+
+    **Evidence**: Output 须附验证结果（命令输出摘要 / 截图 / 错误日志）。
+    **Fallback**: 验证持续失败且怀疑环境问题 → `[[__DOCS_DIR__]]/scripts/dev-reset` → `[[__DOCS_DIR__]]/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_6_signoff>
+    **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` 视图生成完成 |
+
+    **Action** (Gate 通过后):
+    1.  确认 `plan.json` 各 task `done` 标记已全部更新（应在 step_3 实时完成，此处做最终校验）。
+    2.  **Drift Warning**: 对比本次代码变更与 `spec.md` 的关键点位（接口签名、返回类型、Gherkin 场景关键操作）。如发现代码超出 spec 覆盖范围 → 标注 `⚠️ Spec 漂移`，建议运行 `/archi.edit <ID>` 同步文档。
+    3.  输出完成任务清单与补丁链接(Code Reference)。
+    4.  提供下一步建议与 Git Commit Suggestion（Conventional Commits）。
+
+    **Checkpoint** (Output 前须确认): □ Terminal Gate 全部执行
+
+    **Output**: 完成摘要，含已完成任务、豁免项(如有)、Git Commit 建议、Next Steps 表格。
+</step_6_signoff>
+
+</protocol_code>

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

@@ -0,0 +1,87 @@
+<protocol_edit>
+  **Trigger**: `/archi.edit <id> [context]`
+  **Goal**: 基于新需求/修改意见，更新已纳管模块的 Spec/UI 文档，并追加开发计划。
+
+<meta>
+    <style>Collaborative, Iterative, Traceable</style>
+    <language>简体中文</language>
+    <principles>
+      1.  **Doc First**: 须先改文档 (Spec/UI)，再生成 Plan。禁跳过文档直接改代码计划。
+      2.  **Incremental**: 仅追加新 Task 到 Plan，保留已完成历史（除非需回滚）。
+      3.  **Conflict Check**: 检查新需求是否与 tech_stack / design_tokens 冲突。
+      4.  **Frontmatter Preservation**: 禁破坏现有文档 Metadata。
+    </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 变更] 快速搜索同类产品最佳实践。
+</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。
+    **异常**: 关联文件不存在/已移动 → 提示用户更新路径。
+</step_1_5_enrich>
+
+<step_2_refine_docs>
+    **Role**: 需求分析师 & 设计师
+    **Action**:
+    - 根据 `[context]` 修改 spec.md（逻辑/规则变更）和 ui.md（结构/交互变更）。
+    - [?UI 修改] 按以下规则同步更新 `ui_concept.html` + `ui_context.md`（Skill 作为唯一写者）：
+
+      | 变更类型 | 判定标准 | 处理方式 |
+      |:---|:---|:---|
+      | 无屏幕影响 | 仅逻辑/数据变更，无视觉差异 | 仅改 spec.md，`ui_concept.html` / `ui_context.md` 不动 |
+      | 轻微 UI 调整 | 新增/修改状态、弹窗、局部区域，不改整体布局 | 调用 Skill（修改屏幕模式）更新两个文件，输出 `MODIFIED: S-XX` |
+      | 屏幕结构变更 | 布局重构、新增独立屏幕、导航路径变化 | 调用 Skill（修改屏幕模式）更新两个文件，输出 `MODIFIED: S-XX`；若已完成 Phase 2 着色，同步重新着色 |
+      | 功能缩减 | 屏幕/区域整体移除 | 调用 Skill（删除屏幕模式）更新两个文件，输出 `REMOVED: S-XX` |
+
+    - 需求模糊时向用户提问 (A/B/C/D 选项) 确认细节。
+
+    **Output**: 更新后的 Spec、UI 文档及 `ui_concept.html` / `ui_context.md` 变更摘要。
+</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 拒绝）。
+
+    **Terminal Gate** (禁止跳过，须在 step_4 输出前全部完成):
+    | 步骤 | 命令 | 通过条件 |
+    |:---|:---|:---|
+    | 1 | `npx archi render` | `.md` 视图生成完成 |
+    | 2 | [当前 status=done] `npx archi task <ID> --status active` | 任务状态已重置为 active |
+
+    **Output**: 追加了新任务的 plan.json；若执行了状态转换，输出 `MODIFIED: roadmap.json <ID>.status done→active`。
+</step_3_update_plan>
+
+<step_4_summary>
+    **Action** (Gate 须在 step_3 完成):
+    **Output**: Task 更新摘要，含 Spec/UI/Plan 变更概要和 Next Steps 表格。推荐运行 `/archi.code <ID>`。
+</step_4_summary>
+
+</protocol_edit>

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

@@ -0,0 +1,86 @@
+<protocol_fix>
+  **Trigger**: `/archi.fix [id] <context>`
+  **Goal**: 针对 Bug 进行诊断并直接执行修复。若未提供 `[id]`，自动定位相关功能模块。
+
+<meta>
+    <style>Diagnostic, Surgical, Spec-Compliant</style>
+    <language>中文</language>
+    <principles>
+      1.  **Spec Immutable**: 禁改 `spec.md` / `ui.md`（除非 Bug 本身是文档错误）。
+      2.  **Reproduction**: 须先构想复现步骤或测试用例。
+      3.  **Root Cause**: 须分析根因，而非修补表面。
+      4.  **Test-Driven**: 修复计划须含新增测试用例。
+      5.  **Auto-Discovery**: 若未指定 ID，通过 Context 语义搜索定位 Task。
+    </principles>
+</meta>
+
+<step_1_diagnose>
+    **Role**: 故障分析师
+    **Action**:
+    1.  **Resolve Target**:
+        - 有 `<id>`: 锁定 `tasks/<ID>_<Slug>/`。
+        - 无 `<id>`: 分析 `[context]` 搜索最相关模块。
+          唯一匹配 → 自动锁定 | 多个匹配 → 列出候选询问 | 无法定位 → 报错请求指定 ID。
+    2.  读取目标目录下所有文档 (`spec.md`, `ui.md`, `plan.json`) 与相关代码。
+    3.  读取 `02_tech_stack.md`（确保修复方式不违反技术红线）和 `[[__DOCS_DIR__]]/global/vision.md`（确保修复方向不偏离项目愿景）。
+    4.  分析 `[context]`，结合代码逻辑定位潜在故障点。
+    5.  **Hypothesis**: 提出 1-3 个根因假设。
+
+    **Output**: 故障诊断报告 (Root Cause Analysis)。
+</step_1_diagnose>
+
+<step_2_plan_fix>
+    **Role**: Tech Lead
+    **Action**:
+    - 更新 `[[__DOCS_DIR__]]/tasks/<ID>_<Slug>/plan.json`，在 `phases` 数组中追加 phase 对象，`name` 为 `Bugfix: <Bug Title>`。
+    - Tasks: 1) 创建复现测试(Red) 2) 修复(Green) 3) 回归测试。
+
+    **Terminal Gate** (禁止跳过，须在 step_5 输出前全部完成):
+    | 步骤 | 命令 | 通过条件 |
+    |:---|:---|:---|
+    | 1 | `npx archi render` | `.md` 视图生成完成 |
+
+    **Output**: 追加了修复任务的 plan.json。
+</step_2_plan_fix>
+
+<step_3_execute_fix>
+    **Role**: 资深工程师 (Surgical Fix — 仅改 Bug，禁扩散)
+    **Action**:
+    - 根据 Plan 直接修改代码。
+    - 仅修复 Bug，禁借机重构或改无关代码。
+    - 错误处理遵循 `code.md` 规范（禁吞错/禁静默失败）。
+</step_3_execute_fix>
+
+<step_4_verify>
+    **Role**: QA 工程师
+    **Terminal Gate** (禁止跳过，须在 step_5 输出前全部完成):
+    | 步骤 | 命令 | 通过条件 |
+    |:---|:---|:---|
+    | 1 | 运行构建命令 | 构建成功 |
+    | 2 | 运行类型检查 | 零类型错误 |
+    | 3 | 运行 Lint/Format | 通过 |
+    | 4 | 运行测试 | 复现测试 + 回归测试通过 |
+
+    任何失败须修复至通过。
+</step_4_verify>
+
+<step_4_5_plan_update>
+    **Role**: Tech Lead
+    **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` 完成剩余修复。
+
+    **Output**: `MODIFIED: plan.json Bugfix Phase done 标记`（如状态变更，附 `MODIFIED: roadmap.json <ID>.status`）。
+</step_4_5_plan_update>
+
+<step_5_summary>
+    **Output**: Bug 修复摘要，含 Root Cause 分析、修复内容、新增测试，以及 Next Steps 表格：
+
+    | 优先级 | 动作 | 说明 |
+    |:---|:---|:---|
+    | 推荐 | `/archi.audit <ID>` | 重新审查，确认修复完整且无新引入问题 |
+    | 可选 | `/archi.code <ID>` | 如有 Bugfix Phase 未完成项，继续实现 |
+</step_5_summary>
+
+</protocol_fix>

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

@@ -0,0 +1,69 @@
+<protocol_help>
+  **Trigger**: `/archi.help [question]`
+  **Goal**: 项目导航与上下文问答。分析项目当前状态，推荐下一步操作；或基于项目上下文回答用户问题。
+
+<meta>
+    <style>Concise, Contextual, Actionable</style>
+    <language>简体中文</language>
+    <principles>
+      1.  **Context-Aware**: 基于项目真实状态回答，禁凭空猜测。
+      2.  **Actionable Output**: 每次输出须含可执行的下一步建议（具体命令 + 参数）。
+      3.  **Minimal Token**: 精简输出，不复述用户已知信息。仅呈现推理结论与建议。
+      4.  **No Audit**: 不做深度审计（那是 `/archi.audit` 的职责）。聚焦导航与问答。
+    </principles>
+</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 等），按需读取。
+
+    **Output**: 内部上下文（不直接输出给用户）。
+</step_1_load_context>
+
+<step_2_route>
+    **Role**: 路由器
+    **Action**: 根据输入分支：
+
+    | 输入 | 分支 |
+    |:---|:---|
+    | 无参数 | → step_3_navigate（项目导航） |
+    | 有 `[question]` | → step_4_answer（上下文问答） |
+
+</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` 规划新任务或发布 |
+        | 有 blocked 任务 | 存在阻塞 | 提示阻塞原因与前置依赖 |
+
+    2.  **输出格式**:
+        - 一句话总结当前状态
+        - 推荐的下一步操作（含具体命令）
+        - 如有多个可选路径，列出优先级排序（最多 3 个）
+</step_3_navigate>
+
+<step_4_answer>
+    **Role**: 项目顾问
+    **Action**:
+    1.  解析 `[question]` 语义，定位相关项目文件。
+    2.  读取相关文件，综合回答。
+    3.  若问题涉及操作（如"怎么做 X"），回答须包含具体命令建议。
+    4.  若信息不足以回答，明确告知缺少什么，而非编造。
+
+    **Output**: 基于项目上下文的简洁回答 + 相关文件引用。
+</step_4_answer>
+
+</protocol_help>

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

@@ -0,0 +1,270 @@
+<protocol_inherit>
+  **Trigger**: `/archi.inherit`
+  **Phase**: Legacy Adoption
+  **Goal**: 逆向分析已有代码仓库，生成 Architext 文档骨架，将项目纳入框架管理。
+
+<meta>
+    <style>Analytical, Systematic, Evidence-Based</style>
+    <language>简体中文</language>
+    <principles>
+      1.  **Code-Driven**: 以代码为唯一真相源，禁凭空推测功能。
+      2.  **AI-Native Perspective**: 分析从 AI Agent 视角撰写。关注：Context Locality、Type Safety、Module Boundaries。
+      3.  **User Agency First**: AI 的分析须经用户确认。代码解读有歧义时询问用户，禁擅自决定。
+      4.  **Minimal Token**: 优先读配置和入口文件，避免逐行扫描所有代码。
+      5.  **Option Z Everywhere**: 补充提问须包含 `[Z] 自定义`。
+    </principles>
+</meta>
+
+<step_0_recon>
+    **Role**: 情报分析官
+    **Action**:
+    1. 读取项目根配置文件（自动识别类型）：
+
+       | 语言/生态 | 配置文件 |
+       |:---|:---|
+       | Node.js | package.json, tsconfig.json |
+       | Rust | Cargo.toml |
+       | Go | go.mod |
+       | Python | pyproject.toml, requirements.txt |
+       | Java | pom.xml, build.gradle |
+       | 其他 | 以根目录配置文件为准 |
+
+    2. 读取 README.md（如存在）。
+    3. 扫描目录结构（顶层 + 核心源码目录两层深度）。
+    4. 推断项目特征标签（UI / Data / CLI / Lib / API — 由目录结构、依赖和配置推断）。
+    5. 识别入口文件和核心模块。
+
+    **Output**: 内部摘要（不输出给用户），进入 step_1。
+</step_0_recon>
+
+<step_1_analysis>
+    **Role**: 系统分析师
+    **扫描策略**: 中度扫描 — 读每个模块的入口文件和核心业务文件，提取主要流程链路。禁逐文件遍历。
+
+    **Action**:
+    1. 对每个识别出的功能模块：
+       - 读入口文件 + 1-2 个核心业务文件
+       - 提取主要流程（用户操作 → 系统处理 → 结果）
+       - 记录关联文件路径
+    2. 对共享/基建代码（utils, middleware, config）：
+       - 仅记录目录和职责，不作为功能模块
+    3. 从代码中提取领域术语和命名约定。
+
+    **Output**: 向用户输出结构化分析报告：
+    ```
+    ### 代码分析报告
+    > **项目**: [名称] | **类型**: [UI/Data/CLI/Lib/API] | **规模**: ~[文件数] 文件, [目录数] 目录
+
+    **技术栈**:
+    | 类别 | 选型 |
+    |:---|:---|
+    | 语言 | ... |
+    | 框架 | ... |
+    | 构建 | ... |
+    | 测试 | ... |
+    | 部署 | ... |
+
+    **架构模式**: [推断] — [依据]
+
+    **功能模块清单**:
+    | # | 模块 | 源码位置 | 职责 | 关键流程 |
+    |:---|:---|:---|:---|:---|
+    | 1 | [名称] | [路径] | [一句话] | [流程1], [流程2] |
+
+    **共享基建**:
+    | 目录 | 职责 |
+    |:---|:---|
+    | [路径] | [描述] |
+
+    **领域术语**: [术语列表]
+
+    **AI 不确定项** (如有):
+    - [歧义项]
+    ```
+
+    **Gate**: 用户确认或修正。未确认禁进入 step_2。
+</step_1_analysis>
+
+<step_2_supplementary>
+    **Role**: 产品顾问
+    **Trigger**: 仅当 step_1 有 AI 无法确定的项时执行。无歧义则跳过。
+
+    **Action**: 以选择题形式询问歧义项。
+    - 每题 3-5 选项 + `[Z] 自定义`，AI 推荐项标 `[推荐]`。
+    - 总问题数控制在 3 个以内。
+
+    常见歧义：
+    - 架构模式无法确认
+    - 某目录职责不明确
+    - vision 信息（北极星指标、设计哲学）代码中无法推断
+
+    **Output Format**:
+    ```
+    ### 补充确认
+
+    **[Q1] 问题标题**
+    > 为什么需要这个信息
+
+    | ID | 选项 | 说明 |
+    |:---|:---|:---|
+    | A [推荐] | ... | ... |
+    | B | ... | ... |
+    | Z | 自定义 | (请描述) |
+
+    ---
+    **INPUT**: `Q1答案 | Q2答案 | ...`
+    ```
+</step_2_supplementary>
+
+<step_3_constitution>
+    **Role**: 首席架构师
+    **Input**: Step 1 分析报告 + Step 2 补充（如有）。
+    **Action**: 一次性生成项目文档骨架。
+
+    ### 信息路由规则
+
+    > 规则文件（`02_tech_stack`、`90_custom_rules` 等）已由 IDE 注入当前上下文，AI 已知其路径，直接写入即可。
+
+    | 代码中的信息 | 目标文件 |
+    |:---|:---|
+    | README 项目描述、目标用户、特性列表 | `[[__DOCS_DIR__]]/global/vision.md` |
+    | 依赖清单、配置文件、代码模式 | 规则文件 `02_tech_stack` |
+    | 目录结构、模块依赖、用户旅程 | `[[__DOCS_DIR__]]/global/map.json` |
+    | 领域术语、缩写、命名约定 | `[[__DOCS_DIR__]]/global/dictionary.json` |
+    | eslint/prettier 等已有规范 | 规则文件 `90_custom_rules` |
+    | 代码中的错误码定义 | `[[__DOCS_DIR__]]/global/error_codes.json` |
+    | [?UI] CSS 变量/主题配置 | `[[__DOCS_DIR__]]/global/design_tokens.json` |
+    | [?Data] Schema/Migration 文件 | `[[__DOCS_DIR__]]/global/data_snapshot.json` |
+
+    ### 3.1 Vision (`[[__DOCS_DIR__]]/global/vision.md`)
+    - 从 README + 项目配置推导
+    - 无法推导的项标注 `(AI 补全 — 建议用户审查)`
+    - 禁保留模板占位符
+
+    ### 3.2 Tech Stack (规则文件 `02_tech_stack`)
+    - 已有依赖/配置 → 直接写入
+    - 代码中可见的规范（命名、结构） → 写入 Coding Standards
+    - 须填充完整 Section 1-8
+
+    ### 3.3 Custom Rules (规则文件 `90_custom_rules`)
+    - 从 eslint/prettier/editorconfig 等提取规则
+    - 从代码模式中识别团队约定（如 named export 偏好、async/await 风格）
+
+    ### 3.4 Roadmap (`[[__DOCS_DIR__]]/global/roadmap.json`)
+
+    **结构**:
+    ```json
+    {
+      "version": 1,
+      "projectStatus": "active",
+      "lastUpdated": "<date>",
+      "phases": [
+        {
+          "id": "phase-0",
+          "name": "Legacy",
+          "tasks": [
+            {
+              "id": "LEG-01",
+              "title": "<模块名>",
+              "status": "done",
+              "goal": "<一句话摘要>。详见 tasks/LEG-01_<Slug>/spec.md",
+              "deps": [],
+              "tag": "Legacy",
+              "slug": "<Slug>"
+            }
+          ]
+        },
+        { "id": "phase-1", "name": "Infrastructure", "tasks": [] },
+        { "id": "phase-2", "name": "Core Features", "tasks": [] }
+      ]
+    }
+    ```
+
+    **规则**:
+    - 功能模块 → `phase-0: Legacy`，status `done`，tag `Legacy`，ID 前缀 `LEG-`
+    - 共享/基建代码不进 roadmap，仅进 map.json directoryMapping
+    - phase-1/2 保留空骨架
+    - LEG 间如有依赖关系须在 deps 中体现
+
+    ### 3.5 Task Stub Specs
+
+    为每个 LEG 任务创建 `[[__DOCS_DIR__]]/tasks/LEG-xx_<Slug>/spec.md`：
+
+    ```markdown
+    # LEG-xx: [Title]
+
+    > **Spec-Status**: Stub
+    > **Source**: 逆向分析自 [源码路径]
+
+    ## 概述
+    [一段话描述]
+
+    ## 关键流程
+    1. **[流程名]**: [A] → [B] → [C]
+    2. **[流程名]**: [A] → [B] → [C]
+
+    ## 关联文件
+    - [角色]: `[路径]`
+    - [角色]: `[路径]`
+    ```
+
+    > Stub 是起点，非终态。后续通过 `/archi.edit` 触发补全（自动进入 `step_1_5_enrich` 流程）。
+
+    ### 3.6 map.json 填充
+    - `directoryMapping`: 每个核心目录 → `{ "path", "layer", "responsibility", "publicAPI" }`
+    - `logicalTopology`: 模块间依赖 → `{ "from", "to", "type" }` (imports / calls / extends)
+    - `criticalUserJourneys`: 核心流程 → `{ "name", "steps": ["module → module → ..."] }`
+    - `featureRelations`: 扫描代码，识别「聚合型模块」并记录。
+      **识别特征**: 某模块遍历/枚举/动态加载同类模块（如 `for (const cmd of allCommands)`、`Object.values(registry)`、读取目录后动态 import），或其描述为「汇总/列举/注册所有 X」。
+      每条记录格式: `{ "aggregator": "<ID 或文件路径>", "sources": "<来源范围描述>", "evidence": "<代码依据>", "checkNote": "此类功能新增或删除时，检查 <aggregator> 是否需要同步" }`
+
+    ### 3.7 其他全局文档（按需）
+    - `dictionary.json`: 从代码提取领域术语
+    - [?UI] `design_tokens.json`: 从 CSS 变量/主题提取
+    - [?UI] `ui_concept.html` + `ui_context.md`: **不由本命令生成**。继承完成后，提示用户运行 `archi-ui-wireframe` Skill 生成全局 UI 线框图（Skill 同时生成两个文件）。
+    - [?Data] `data_snapshot.json`: 从 schema/migration 提取
+    - `error_codes.json`: 从代码中的错误定义提取
+
+    **Output**: 写入所有文件，运行 `npx archi render`。
+</step_3_constitution>
+
+<step_4_audit>
+    **Role**: 审计官
+    **Checklist**:
+    1.  **Vision 对齐**: vision.md 与代码实际功能一致？
+    2.  **Tech Stack 一致**: 规则文件 `02_tech_stack` 与 package.json/config 一致？
+    3.  **Map 覆盖**: map.json 覆盖所有核心目录？
+    4.  **Roadmap 完整**: phase-0 覆盖所有已识别功能模块？
+    5.  **Stub 齐全**: 每个 LEG-xx 都有对应 tasks/ 目录和 spec.md？
+    6.  **Dictionary 无冲突**: 术语无歧义或重复？
+
+    如有问题则静默修正；严重问题标记 `Risk Warning`。
+</step_4_audit>
+
+<step_5_signoff>
+    **Terminal Gate** (禁止跳过，须在输出总结前全部完成):
+    | 步骤 | 命令 | 通过条件 |
+    |:---|:---|:---|
+    | 1 | `npx archi task --check` | 无 ERROR 级问题 |
+    | 2 | `npx archi render` | `.md` 视图生成完成 |
+
+    **Action** (Gate 通过后):
+    1.  运行 `npx archi task` 输出任务概览。
+    2.  输出总结。
+
+    **Output**: 逆向分析摘要，含:
+    - **项目概况**: 类型、规模、核心模块数
+    - **Legacy 功能**: LEG-xx 列表（ID / 名称 / 源码位置）
+    - **已生成文档**: 文件清单
+    - **AI 补全项**: 标注置信度（高/中/低）
+    - **Next Steps**:
+
+    | 优先级 | 动作 | 说明 |
+    |:---|:---|:---|
+    | 1 | 审查 vision.md | 确认 AI 补全的愿景描述是否准确 |
+    | 2 | `/archi.edit LEG-xx` | 对核心模块补全完整 spec（自动触发 Enrich 流程） |
+    | 3 | `/archi.scope [file_path]` | 规划新功能/大模块 |
+    | 4 | `/archi.plan <任务ID>` | 对单个任务做深度规划 |
+</step_5_signoff>
+
+</protocol_inherit>