architext 0.0.2

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

@@ -0,0 +1,160 @@
+<protocol_revise>
+  **Trigger**: `/archi.revise [context]`
+  **Goal**: 执行项目级全局变更（技术栈、架构、愿景等），分析影响范围，经用户确认后修改全局资产并级联更新受影响的 Task 文档。
+
+<constraints_cursor>
+    **Mode Lock**: 本协议须在 **Agent Mode (Normal Mode)** 下执行。禁切换到 Plan Mode 或其他只读模式。
+</constraints_cursor>
+
+<meta>
+    <style>Strategic, Analytical, Cautious, Traceable</style>
+    <language>简体中文</language>
+    <principles>
+      1.  **User Gate**: 全局变更须经用户逐项确认后才执行。禁擅自修改。
+      2.  **Impact First**: 先输出完整影响分析，后执行修改。
+      3.  **Doc Cascade**: 全局资产变更后，须按 edit 标准同步更新受影响的 Task 文档。
+      4.  **Traceability**: 每项变更须可追溯 — 说明变更理由和影响范围。
+    </principles>
+</meta>
+
+<step_1_load>
+    **Role**: 系统分析师
+    **Action**:
+    1.  **Read Global Assets**:
+        - `[[__DOCS_DIR__]]/global/vision.md`
+        - `[[__DOCS_DIR__]]/global/roadmap.json`
+        - `[[__DOCS_DIR__]]/global/map.json`
+        - `[[__DOCS_DIR__]]/global/dictionary.json`
+        - `[[__DOCS_DIR__]]/global/error_codes.json`
+        - `02_tech_stack.md`
+        - [?UI] `[[__DOCS_DIR__]]/global/design_tokens.json`
+        - [?Data] `[[__DOCS_DIR__]]/global/data_snapshot.json`
+    2.  **Scan Task Index**: 扫描 `[[__DOCS_DIR__]]/tasks/` 目录，建立 Task 索引（ID、名称、状态）。
+    3.  **Intent Analysis**: 根据用户 `[context]`，初步定位受影响的全局资产类别。
+
+    **Output**: 变更意图摘要 — 列出初步判断涉及的全局文件，进入 step_2。
+</step_1_load>
+
+<step_2_interview>
+    **Role**: 首席架构师
+    **Action**:
+    根据用户描述和已加载上下文，澄清变更边界:
+
+    | 澄清维度 | 说明 |
+    |:---|:---|
+    | 变更范围 | 精确定位哪些全局文件、哪些规则受影响 |
+    | 变更动机 | 为什么要做此变更，期望达到什么结果 |
+    | 排除清单 | 是否有不应被影响的 Task |
+
+    - 上下文足够清晰时 → 合并到 step_3 直接输出影响分析。
+    - 存在歧义或多种可行方向时 → 向用户提问确认（A/B/C/D 选项）。
+</step_2_interview>
+
+<step_3_impact>
+    **Role**: 影响分析师
+    **Constraint**: **纯输出，禁修改任何文件**。此步骤为「变更影响评估书」。
+
+    **Output Format**:
+    ```
+    ## 变更影响评估: [变更主题]
+
+    ### 1. 全局资产变更清单
+    | 文件 | 变更内容 | 类型 |
+    |:---|:---|:---|
+    | vision.md | [具体改什么，或"无需变更"] | 修改/无变更 |
+    | 02_tech_stack.md | [...] | ... |
+    | roadmap.json | [...] | ... |
+    | map.json | [...] | ... |
+    | dictionary.json | [...] | ... |
+    | data_snapshot.json | [...] | ... |
+    | design_tokens.json | [...] | ... |
+    | error_codes.json | [...] | ... |
+
+    ### 2. 受影响 Task 清单
+    | Task ID | 名称 | 影响点 | 程度 |
+    |:---|:---|:---|:---|
+    | INF-001 | [名称] | [spec/ui/plan 的哪些部分受影响] | 高/中/低 |
+
+    ### 3. 需用户决策的项目（如有）
+    - [?] [不确定项描述 + 选项]
+    - [?] ...
+
+    ---
+    > 回复 **OK** 确认全部；或标注需调整的部分。
+    ```
+
+    **Gate**: 等待用户确认。未确认禁进入 step_4。
+</step_3_impact>
+
+<step_3_5_refinement>
+    **Role**: 咨询顾问
+    **Trigger**: 用户回复非 OK，含修正、否决或追加意见。
+    **Action**: 不执行修改。融入用户反馈，刷新影响评估书重新输出，等待再次确认。
+</step_3_5_refinement>
+
+<step_4_execute>
+    **Role**: 执行工程师
+    **Action**:
+
+    **Safety Checkpoint** (执行前须完成):
+    1. 检查 Git 工作区状态（建议执行 `git status`）。
+    2. 如有未提交变更 → 提示用户先 commit 或 stash，再继续执行。
+    3. 工作区干净后，告知用户：如需回滚，可执行 `git checkout -- .` 恢复到变更前状态。
+
+    **Phase 1 — 修改全局资产**:
+    按用户确认的清单修改全局文件。每个文件修改后输出变更摘要。
+
+    **[?UI] Phase 1.5 — 设计系统变更检查**:
+    若 `design_tokens.json` 有以下变更，须在 Phase 2 完成后执行对应操作：
+
+    | 变更范围 | 影响 | 处理方式 |
+    |:---|:---|:---|
+    | `primitivePalette.brand` / `semanticTokens.colors` | 品牌色/语义色变化 | 通知用户：需重跑 `archi-ui-wireframe` Phase 2（全量重着色） |
+    | `semanticTokens.typography` | 字体变化 | 通知用户：需重跑 Phase 2 |
+    | `motion.preference` / `motion.patterns` | 动效变化 | 通知用户：需重跑 Phase 2 |
+    | `illustration.iconLibrary` | 图标库变化 | 通知用户：需重跑 Phase 2 |
+    | `layout` (radius/spacing/shadow) | 组件尺寸/圆角变化 | 通知用户：需重跑 Phase 2 |
+
+    > 如上述字段未变动（如仅改 `mode.default`），无需重跑 Phase 2。
+
+    **Phase 2 — 级联更新 Task 文档**:
+    对每个受影响的 Task，按 `/archi.edit` 标准执行:
+    1.  更新 `spec.md`（逻辑/规则因全局变更而需调整的部分）。
+    2.  [?UI] 更新 `ui.md`（范围/交互因全局变更而需调整的部分）；如屏幕结构受影响，运行 `archi-ui-wireframe` Skill（局部更新模式）同步更新 `ui_concept.html` + `ui_context.md`。
+    3.  在 `plan.json` 的 `phases` 中追加新 Phase: `Phase X: Global Revision — [变更主题] (<Date>)`，列出落地任务。
+
+    **Output**: 每个文件的变更摘要（全局 + Task）。
+</step_4_execute>
+
+<step_5_summary>
+    **Role**: 审计官
+    **Checklist**:
+    1.  全局资产间一致性（vision ↔ tech_stack ↔ roadmap ↔ map）。
+    2.  Task 文档与更新后的全局资产对齐。
+    3.  无孤立引用（dictionary/map 中旧术语/路径是否已清理）。
+
+    **Terminal Gate** (禁止跳过，须在输出总结前全部完成):
+    | 步骤 | 命令 | 通过条件 |
+    |:---|:---|:---|
+    | 1 | `npx archi task --check` | 无 ERROR 级问题 |
+    | 2 | `npx archi render` | `.md` 视图生成完成 |
+
+    **Action** (Gate 通过后):
+    1.  输出变更总结。
+
+    **Output**:
+    ```
+    ## Global Revision Summary: [变更主题]
+
+    **全局资产变更**: [已修改文件列表]
+    **Task 更新**: [已更新 Task 列表 + 各自影响摘要]
+    **审计结果**: [通过/有风险项]
+
+    ### Next Steps
+    | 优先级 | 动作 | 说明 |
+    |:---|:---|:---|
+    | ... | ... | ... |
+    ```
+</step_5_summary>
+
+</protocol_revise>

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

@@ -0,0 +1,198 @@
+<protocol_scope>
+  **Trigger**: `/archi.scope [file_path]`
+  **Phase**: Requirement Decomposition
+  **Goal**: 读取 Scope Brief，将大需求分解为多个 Roadmap 任务并建立依赖关系。
+
+<meta>
+    <style>Strategic, Analytical, Structured</style>
+    <language>简体中文</language>
+    <principles>
+      1.  **Brief-Driven**: 以用户提供的 Scope Brief 为核心输入源，禁凭空脑暴任务。
+      2.  **Incremental**: 在已有 Roadmap 上追加，禁重写已有任务。
+      3.  **User Agency First**: Brief 中用户已填写的选择须直接采纳，禁质疑或替换。
+      4.  **Minimal Questions**: 仅针对信息缺口提问，Brief 充分时可跳过提问直接分解。
+      5.  **Option Z Everywhere**: 补充提问须包含 `[Z] 自定义`。
+    </principles>
+</meta>
+
+<step_0_ingest>
+    **Role**: 情报分析官
+    **Action**:
+    1. 解析触发命令中的 `[file_path]`：
+       - 如提供了路径 → 读取该文件
+       - 如未提供路径 → 依次查找 `scope-brief.md`（项目根）、`[[__DOCS_DIR__]]/scope-brief.md`
+       - 如均不存在或为空 → 跳转 `<fallback_interview>`
+
+    2. 解析 Brief 各 Section，提取：
+       - 需求名称和描述
+       - 任务清单
+       - 已有设计决策
+       - 边界与约束（不做的事、时间、依赖、技术限制）
+       - 受影响的已有任务
+       - 参考资料
+
+    > Brief 是一次性输入文件，处理完成后用户可自行删除。
+
+    **Output**: 内部摘要（不输出给用户），进入 `<step_1_load>`。
+</step_0_ingest>
+
+<step_1_load>
+    **Role**: 系统分析师
+    **Action**:
+    1.  **Read Vision**: `[[__DOCS_DIR__]]/global/vision.md` — 仅读北极星指标和 Boundaries 段落；其余章节跳过。
+    2.  **Read Roadmap**: `[[__DOCS_DIR__]]/global/roadmap.json` — 仅提取每个 task 的 `id/title/status/deps/tag` 字段（跳过 `goal/notes`，需求分解不需要这些详情）；读取当前最大 ID 水位用于新任务编号。
+    3.  **Read Tech Stack**: `02_tech_stack.md` — 技术约束。
+    4.  **Read Map**: `[[__DOCS_DIR__]]/global/map.json` — 仅读 `directoryMapping` 和 `featureRelations`；`logicalTopology` 和 `criticalUserJourneys` 跳过。
+    5.  **Scan Tasks**: 扫描 `[[__DOCS_DIR__]]/tasks/` 目录 — 了解已有 Task 概要（标题 + 关键流程，无需全文）。
+
+    **Output**: 内部上下文摘要，进入 `<step_2_analysis>`。
+</step_1_load>
+
+<step_2_analysis>
+    **Role**: 首席产品战略官 (CPO)
+    **Input**: Step 0 Brief 解析结果 + Step 1 项目上下文。
+
+    **Action**:
+
+    1. **Vision 对齐检查**: Brief 需求是否与 vision.md 的北极星指标一致？如有偏离 → 在输出中标注 `[Vision 偏离警告]`。
+    2. **任务清单完整性**: Brief 任务清单是否足以支撑需求目标？
+    3. **影响评估**: Brief 中"受影响的已有任务" → 对照 roadmap/tasks 验证是否存在、状态如何。
+    4. **缺口识别**: 检查 Brief 是否有关键信息缺失。
+    5. **联动检查**: 读取 `map.json.featureRelations`，将新任务的描述与各条 `sources` 字段做语义对比，判断新任务是否属于某聚合方的覆盖范围。命中时在摘要中输出联动提示。
+
+    **缺口分级**:
+    - **必须**: 缺失则无法合理分解（如任务清单为空）
+    - **可补**: AI 可推导但建议确认（如依赖关系不明确）
+    - **建议**: AI 可自行决定（如任务分组方式）
+
+    **Decision**:
+    - 无"必须"级缺口 + 无"可补"级缺口 → 跳过 Step 2.5，直接进入 Step 3
+    - 有缺口 → 进入 Step 2.5
+
+    **Output**: 向用户输出 Brief 分析摘要：
+    ```
+    ### SCOPE BRIEF 分析报告
+    > **需求**: [名称] | **规模**: 预估 [N] 个任务
+
+    **Vision 对齐**: [一致 / ⚠️ 偏离 — 原因]
+
+    **已确认信息**:
+    - [列表]
+
+    **受影响的已有任务**:
+    | 任务 | 状态 | 预估影响 |
+    |:---|:---|:---|
+    | [ID: 名称] | [done/active/stub] | [需修改/需扩展/无影响] |
+
+    **[?有命中] 联动提示**:
+    | 聚合方 | checkNote |
+    |:---|:---|
+    | [aggregator ID/路径] | [checkNote 内容] |
+
+    **信息缺口** (须补充):
+    - [缺口列表]
+
+    **AI 将自动决定** (无需操作):
+    - [列表]
+    ```
+</step_2_analysis>
+
+<step_2_5_supplementary>
+    **Role**: 产品顾问
+    **Trigger**: 仅当 Step 2 发现"必须"或"可补"级缺口时执行。
+    **Input**: Step 2 的缺口列表。问题数上限 3 题。
+
+    [[SKILL: 按 `archi-interview-protocol` Skill 的核心规则和标准输出格式提问。]][[NO-SKILL: （Skill 未安装：请阅读 `[[__DOCS_DIR__]]/skills/archi-interview-protocol/SKILL.md` 并遵循其规则）]]
+</step_2_5_supplementary>
+
+<step_3_decompose>
+    **Role**: 首席架构师
+    **Input**: Brief 全文 + 项目上下文 + 补充回答（如有）。
+
+    **Action**: [[SKILL: 按 `archi-decompose-roadmap` Skill 的协议，基于 Scope Brief 任务清单生成增量任务数据]][[NO-SKILL: （Skill 未安装：请阅读 `[[__DOCS_DIR__]]/skills/archi-decompose-roadmap/SKILL.md` 并遵循其协议执行）]]
+
+    **展示格式**（将 Skill 产出的任务数据转换为以下格式，向用户呈现后等待确认）：
+
+    ```
+    #### Phase 1: Infrastructure
+    | ID | 标题 | 描述摘要 | 标签 |
+
+    #### Phase 2: Core Features
+    | ID | 标题 | 描述摘要 | 依赖 | 标签 |
+
+    #### Execution Batches（并行执行批次）
+    （从 deps 拓扑排序推导，列出每批可同时开工的任务）
+    Batch 1（立即可开工）: ...
+    Batch 2（等 Batch 1 全完）: ...
+
+    #### NFR 横切关注点（已归并，不入 Roadmap）
+    （来自 Skill 的 NFR 归并清单）
+    - [NFR 名称] → 注入 [任务 ID] | 影响：[其他任务 ID]
+    ```
+
+    **Gate**: 用户回复 **OK** 后进入 step_4；未确认禁写入 Roadmap。用户可在确认前修正方案（合并/拆分/调整依赖）。
+</step_3_decompose>
+
+<step_3_5_refinement>
+    **Role**: 咨询顾问
+    **Trigger**: 用户回复非 OK，含合并/拆分/增删/依赖调整等修正。
+    **Action**: 融入用户反馈，刷新分解方案重新输出，等待再次确认。
+</step_3_5_refinement>
+
+<step_4_roadmap_update>
+    **Role**: 系统管理员
+    **Input**: 用户确认的分解方案。
+
+    **Action**:
+    1.  将新任务追加到 `[[__DOCS_DIR__]]/global/roadmap.json` 对应 Phase 的 `tasks` 数组中。
+    2.  如需新增 Phase → 追加到 `phases` 数组。
+    3.  更新 `lastUpdated` 字段。
+    4.  [?新模块] 更新 `[[__DOCS_DIR__]]/global/map.json` 的 `directoryMapping`：为新增任务预注册推断的模块路径（基于 tech_stack 架构模式和任务描述推断，仅目录级别；详细内容在 `/archi.plan` 时完善）。
+
+    **Terminal Gate** (禁止跳过，须在输出总结前全部完成):
+    | 步骤 | 命令 | 通过条件 |
+    |:---|:---|:---|
+    | 1 | `npx archi task --check` | 无 ERROR 级问题 |
+    | 2 | `npx archi render` | `.md` 视图生成完成 |
+
+    **Output**: 写入确认。
+</step_4_roadmap_update>
+
+<step_5_signoff>
+    **Action** (Gate 须在 step_4 完成):
+    1.  运行 `npx archi task` 输出任务进度概览。
+    2.  输出总结。
+
+    **Output**: 需求分解摘要，含：
+    - **Brief 来源确认**: 需求名称和核心目标
+    - **新增任务**: 数量和 Phase 分布
+    - **对已有任务的影响**: 影响列表（如有）
+    - **Next Steps**:
+
+    | 优先级 | 动作 | 说明 |
+    |:---|:---|:---|
+    | [?UI] 推荐 | 运行 `archi-ui-wireframe` Skill（追加模式） | 为新增任务追加屏幕到 `ui_concept.html`，同步更新 `ui_context.md` |
+    | 1 | `/archi.plan <第一个 pending 任务 ID>` | 对首个可执行任务做深度规划 |
+    | 2 | 审查 roadmap | 确认依赖关系和优先级 |
+</step_5_signoff>
+
+<fallback_interview>
+    **Trigger**: Brief 文件不存在或为空。
+    **Role**: 产品顾问
+
+    **Action**:
+    1. 告知用户 `scope-brief.md` 未找到。建议：
+       - 运行 `npx archi template scope-brief` 获取模板到项目根目录
+       - 填写后重新运行 `/archi.scope scope-brief.md`
+       - 或继续对话，通过访谈方式提供信息
+    2. 如用户选择继续对话，按以下顺序引导：
+       a. 这次要做什么？（需求名称、一句话描述、动机）
+       b. 包含哪些任务？（具体任务列表）
+       c. 有什么约束？（不做的事、依赖、技术限制）
+       d. 会影响哪些已有任务？
+    3. 收集完毕后，将信息写入 `scope-brief.md`（项目根目录），然后跳转 `<step_1_load>`。
+
+    > 此模式为向后兼容，核心流程仍以 Brief 为准。
+</fallback_interview>
+
+</protocol_scope>

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

@@ -0,0 +1,258 @@
+<protocol_kickoff>
+  **Trigger**: `/archi.start [file_path]`
+  **Phase**: Strategic Initialization
+  **Goal**: 基于 Project Brief 建立项目宪法 (Vision/Tech/Roadmap)。
+
+<meta>
+    <style>Strict, Professional, CLI-Like</style>
+    <language>简体中文</language>
+    <principles>
+      1.  **Brief-Driven**: 以用户提供的 Brief 文件为核心输入源，禁凭空脑暴任务。
+      2.  **AI-Native Perspective**: 所有推荐/补全从 AI Agent 视角撰写。关注：Context Locality、Type Safety、Hallucination Risk、Self-Correction。
+      3.  **User Agency First**: Brief 中用户已填写的选择须直接采纳，禁质疑或替换。
+      4.  **Minimal Questions**: 仅针对信息缺口提问，Brief 充分时可跳过提问直接生成。
+      5.  **Option Z Everywhere**: 补充提问须包含 `[Z] 自定义`。
+    </principles>
+</meta>
+
+<step_0_ingest>
+    **Role**: 情报分析官
+    **Action**:
+    1. 解析触发命令中的 `[file_path]`：
+       - 如提供了路径 → 读取该文件
+       - 如未提供路径 → 依次查找 `project-brief.md`（项目根）、`[[__DOCS_DIR__]]/project-brief.md`
+       - 如均不存在或为空 → 跳转 `<fallback_interview>`
+
+    2. **资源可达性检查**（须在解析前完成）：
+       扫描 Brief 全文，识别所有外部引用（URL、文件路径、图片）。逐一尝试访问，将结果分为三类：
+
+       | 状态 | 处理 |
+       |:---|:---|
+       | 可访问 | 读取内容，纳入后续分析 |
+       | 不可访问（需认证/404/私有链接） | 标记为 `[不可读]`，后续向用户报告 |
+       | 非链接的描述性引用（如"参考 Linear 的交互"） | 正常处理，无需访问 |
+
+       > 此步骤的目的：避免 AI 假装已读取实际未能访问的资源，导致后续产出与用户预期脱节。
+
+    3. 解析 Brief 各 Section，提取：
+       - 项目特征标签 (UI/Data/CLI/Lib/API — 由 Brief 中存在的技术偏好字段和段落推断)
+       - 核心任务列表
+       - 已有设计决策（用户对特定任务/页面/流程的预定设计）
+       - 技术偏好（区分"已确定"与"留空/推荐"）
+       - 已有资源与上下文
+       - 边界与约束
+       - 参考项目
+       - 补充说明（规则/术语/背景信息）
+
+    > Brief 是一次性输入文件，处理完成后用户可自行删除。
+
+    **Output**:
+    - 如有不可访问的资源 → **立即向用户输出资源可达性报告**，列出无法读取的链接，请用户提供替代方式（如截图、粘贴内容、文字描述）。等待用户回复后再继续。
+    - 如所有资源可达或无外部引用 → 内部摘要（不输出给用户），进入 `<step_1_gap_analysis>`。
+</step_0_ingest>
+
+<step_1_gap_analysis>
+    **Role**: 首席产品战略官 (CPO)
+    **Input**: Step 0 解析结果。
+
+    **Action**: 逐项检查 Brief 完整性，识别信息缺口。
+
+    **检查清单**:
+
+    | 检查项 | 判定标准 | 缺口级别 |
+    |:---|:---|:---|
+    | 项目身份 | 名称 + 一句话描述 + 问题陈述均已填写 | 必须 |
+    | 目标用户 | 至少描述了核心用户角色 | 必须 |
+    | 核心任务 | 至少列出 2 个具体任务且每项有描述 | 必须 |
+    | 技术栈-核心 | 语言/运行时 + 核心框架已填写（非留空） | 必须 |
+    | 技术栈-选填 | 数据库/ORM/CSS方案/部署等留空项 | 可补 |
+    | 项目起点 | 全新 or 已有代码（影响架构决策） | 必须 |
+    | 已有资源 | 设计稿/品牌/已有API/第三方服务是否明确 | 可补 |
+    | 风格调性 | [?UI] 视觉关键词 / [?CLI] 输出风格 / [?API] 文档方案 | 可补 |
+    | 边界 | 至少声明了 1 个反目标或硬性约束 | 建议 |
+    | 成功指标 | 已填写具体可量化指标 | 建议 |
+    | 参考项目 | 至少列出 1 个参照 | 建议 |
+
+    **缺口分级**:
+    - **必须**: 缺失则无法生成产物，须在 Step 2 提问
+    - **可补**: AI 可基于上下文推荐，但最好确认
+    - **建议**: AI 可自行推导，不阻塞流程
+
+    **Decision**:
+    - 无"必须"级缺口 + 无"可补"级缺口 → 跳过 Step 2，直接进入 Step 3
+    - 有缺口 → 进入 Step 2
+
+    **Output**: 向用户输出 Brief 分析摘要：
+    ```
+    ### BRIEF 分析报告
+    > **项目**: [名称] | **特征**: [UI/Data/CLI/Lib/API 中已激活的标签]
+
+    **已确认信息**:
+    - [已填写的关键信息列表]
+
+    **信息缺口** (须补充):
+    - [缺口 1]
+    - [缺口 2]
+
+    **AI 将自动补全** (无需操作):
+    - [AI 可自行推导的项]
+    ```
+</step_1_gap_analysis>
+
+<step_2_supplementary>
+    **Role**: 产品顾问
+    **Trigger**: 仅当 Step 1 发现"必须"或"可补"级缺口时执行。
+    **Input**: Step 1 的缺口列表。问题数上限 3-6 题。
+
+    [[SKILL: 按 `archi-interview-protocol` Skill 的核心规则和标准输出格式提问。]][[NO-SKILL: （Skill 未安装：请阅读 `[[__DOCS_DIR__]]/skills/archi-interview-protocol/SKILL.md` 并遵循其规则）]]
+</step_2_supplementary>
+
+<step_3_constitution>
+    **Role**: 首席架构师
+    **Input**: Brief 全文 + Step 2 补充回答（如有）。
+
+    **Action**: 一次性生成项目宪法文件。Brief 中的所有信息须被消化并路由到对应文件，禁遗漏。
+
+    ### 信息路由规则
+
+    > 规则文件（`02_tech_stack`、`90_custom_rules` 等）已由 IDE 注入当前上下文，AI 已知其路径，直接写入即可。
+
+    | Brief 内容 | 目标文件 |
+    |:---|:---|
+    | 项目身份、目标用户、成功指标、参考灵感 | `[[__DOCS_DIR__]]/global/vision.md` |
+    | 技术栈、部署目标、第三方库/服务 | 规则文件 `02_tech_stack` |
+    | 风格调性（UI/CLI/API）— 审美方向/信息密度/动效偏好 | 规则文件 `02_tech_stack` (UI Protocol) + `design_tokens.json` aestheticDirection + motion.preference + illustration |
+    | [?UI] **审美方向** (saas-dark/saas-light/dashboard/marketing/mobile-app/editorial/brutalist/custom) | `design_tokens.json` `aestheticDirection.preset` + `aestheticDirection.customDescription` |
+    | [?UI] **视觉参考**（品牌色板/字体/图标库/竞品截图/禁用风格） | `design_tokens.json` primitivePalette.brand + illustration + motion; 截图/URL 存入 `vision.md` Visual Reference |
+    | 核心任务列表 | `[[__DOCS_DIR__]]/global/roadmap.json` |
+    | **已有设计决策** | Roadmap 对应任务的 `goal` 字段中注入，并在 `/archi.plan` 时作为硬约束 |
+    | 边界与反目标 | `[[__DOCS_DIR__]]/global/vision.md` Boundaries |
+    | 已有资源（设计稿/品牌/已有API） | `[[__DOCS_DIR__]]/global/vision.md` + 规则文件 `02_tech_stack` 按内容归属 |
+    | 补充说明中的**规则/约定/偏好** | 规则文件 `90_custom_rules` |
+    | 补充说明中的**领域术语** | `[[__DOCS_DIR__]]/global/dictionary.json` |
+    | 补充说明中的**其他背景信息** | `[[__DOCS_DIR__]]/global/vision.md` Context |
+
+    > 关键: 用户在"补充说明"中写的任何规则性内容（如"代码注释用英文"、"禁止使用 any"）须写入规则文件 `90_custom_rules`，而非丢弃。
+
+    ### 3.1 Vision (`[[__DOCS_DIR__]]/global/vision.md`)
+    - 从 Brief 项目概述填充 Core Vision 和 Target Audience
+    - 从 Brief 边界与约束填充 Boundaries
+    - 从 Brief 风格调性（如有）填充 Design & Experience
+    - 从 Brief 参考与灵感推导 Product Principles
+    - 从 Brief 已有资源、补充说明提取背景上下文
+    - 须填满所有 `[ ]` 占位符，禁保留模板示例文字
+
+    ### 3.2 Tech Stack (规则文件 `02_tech_stack`)
+    - Brief 中已确定的技术选择 → 直接写入
+    - Brief 中留空/写"推荐"的 → AI 基于项目特征推荐，须在输出中标注 `(AI 推荐)` 并简述理由
+    - Brief 中已有的第三方服务/API → 写入对应 Section
+    - **AX Optimization**: 推荐时优先 AI 友好型技术 (Static Typing, Popular Frameworks, Convention-over-Configuration)
+    - 须填充完整的 Section 1-9（Global Mandates、Technology Selection、Coding Standards、UI Protocol[?UI]、Testing、Deployment、Architecture、Anti-Patterns、**Project Conventions**）
+    - `Section 5 Testing` 中的 Environment Scripts 定义须完整
+    - **Section 9 Project Conventions**: 基于 Brief 和项目特征确立全局架构约定，`/archi.plan` 将自动继承这些约定而非逐任务重复提问：
+      - **Error Handling**: 根据项目类型推断 — [?UI] Fail Fast + Form Validation; [?CLI] Fail Fast (stderr); [?API] Schema Validation + Fail Fast; 多选时空格分隔
+      - [?UI] **Data Flow**: 根据实时性需求 — 无实时需求 → Standard Request (+ SWR/React Query if applicable); Brief 提及实时/协作 → Realtime
+      - [?Web/API] **Auth & Access**: 根据 Brief 用户角色 — 单角色 → Authenticated; 多角色 → RBAC; 无权限描述 → 留空待 Plan 阶段逐任务确认
+      - 每项须填写 Strategy/Default + Rationale（理由须结合此项目的具体场景）
+
+    ### 3.3 Custom Rules (规则文件 `90_custom_rules`)
+    - 从 Brief 补充说明中提取规则性内容写入
+    - 从 Brief 技术红线转化为具体禁止规则
+    - 如用户未提供任何自定义规则，保持模板默认内容
+
+    ### 3.4 Roadmap (`[[__DOCS_DIR__]]/global/roadmap.json`)
+    [[SKILL: 按 `archi-decompose-roadmap` Skill 的协议，基于 Brief 任务列表生成任务链，写入 roadmap.json]][[NO-SKILL: （Skill 未安装：请阅读 `[[__DOCS_DIR__]]/skills/archi-decompose-roadmap/SKILL.md` 并遵循其协议执行）]]，生成后直接进入下一步，无需用户确认。
+
+    ### 3.5 其他全局文档 (按需)
+    - `dictionary.json`: 从 Brief 提取领域术语
+    - [?Data] `data_snapshot.json`: 基于 Brief 中的数据描述，初始化核心实体骨架（实体名 + 主键字段）；无数据描述时写入空模板
+    - [?UI] `design_tokens.json`: 基于 Brief「风格与调性」和「视觉参考」填充：
+      - `aestheticDirection.preset`: 从 Brief 审美方向字段填入；Brief 未填时基于项目特征推断（Web SaaS 默认 saas-light，Dashboard 默认 dashboard 等）
+      - `aestheticDirection.customDescription`: 仅 custom 时填入用户描述
+      - `primitivePalette.brand`: 从品牌色板提取 Hex 值；无则留空
+      - `mode`: 从审美方向推断 default + support 数组（saas-dark → default:"dark"，saas-light → default:"light" 等）
+      - `motion.preference` / `motion.patterns`: 从动效偏好填写 (subtle / rich / none)；rich 时扩充 patterns
+      - `illustration.style` / `illustration.iconLibrary`: 从图示风格和图标库填写
+      - `semanticTokens.colors`: 如有品牌色则以 Brand-600/Brand-500 等 key 填充 Primary
+    - `error_codes.json`: 基于任务列表预定义核心错误码
+
+    ### 3.6 Map (`[[__DOCS_DIR__]]/global/map.json`)
+    - `directoryMapping`: 基于 tech_stack 中声明的架构模式，预注册核心目录骨架
+      （如 `src/commands/`, `src/core/`, `src/utils/` 等）；各目录附一句话用途说明
+    - `logicalTopology`: 暂为空数组，待 `/archi.plan` 时按需补充
+    - `criticalUserJourneys`: 暂为空数组
+    - `featureRelations`: 暂为空数组
+
+    **Output**: 写入所有文件，然后运行 `npx archi render` 生成可视化 `.md`。
+</step_3_constitution>
+
+<step_4_audit>
+    **Role**: 首席审计官
+    **Checklist**:
+    1.  **Vision 完整性**: `vision.md` 含北极星指标和设计哲学？
+    2.  **Tech Stack 一致性**: 规则文件 `02_tech_stack` 与 Brief 技术偏好一致？含完整技术栈声明？
+    3.  **Custom Rules**: Brief 补充说明/技术红线中的规则是否已写入规则文件 `90_custom_rules`？
+    4.  **Roadmap 合规**: 运行 `npx archi task --check` 验证一致性。
+    5.  [?UI] **Design Tokens**: `design_tokens.json` 含基础颜色/字体/间距定义？
+    6.  **Brief 对齐**: 所有 Brief 中声明的核心任务均已映射到 Roadmap 任务？
+    7.  **信息零遗漏**: Brief 中所有用户填写的内容均已路由到对应文件？
+
+    如有问题则静默修正；严重问题标记 `Risk Warning`。
+</step_4_audit>
+
+<step_4_5_ui_wireframe>
+    **Trigger**: 仅当项目特征含 [?UI] 时执行。
+    **Action**: 自动调用 `archi-ui-wireframe` Skill（Phase 1 线框图）。
+    - 无需用户确认即开始生成
+    - 读取刚写入的 vision.md + roadmap.json + design_tokens.json + 02_tech_stack
+    - 写入 `ui_concept.html` + `ui_context.md`
+    - 输出 Phase 1 线框图摘要，等待用户确认后再进入 Phase 2 着色
+
+    > 此步骤将 UI 线框图生成从"建议的下一步"变为"start 自动完成"，减少用户手动操作。
+</step_4_5_ui_wireframe>
+
+<step_5_signoff>
+    **Terminal Gate** (禁止跳过，须在输出总结前全部完成):
+    | 步骤 | 命令 | 通过条件 |
+    |:---|:---|:---|
+    | 1 | `npx archi task --check` | 无 ERROR 级问题 |
+    | 2 | `npx archi render` | `.md` 视图生成完成 |
+
+    **Action** (Gate 通过后):
+    1.  运行 `npx archi task` 输出任务进度概览。
+    2.  输出总结。
+
+    **Output**: 项目初始化摘要，含：
+    - **Brief 来源确认**: 列出从 Brief 中采纳的关键决策
+    - **AI 补全项**: 列出 AI 自动推荐的技术/决策及理由
+    - **Roadmap 概览**: 任务数量和阶段分布
+    - **Next Steps 表格**:
+
+    | 优先级 | 行动 | 说明 |
+    |:---|:---|:---|
+    | [?UI] 推荐 | 回复 **OK** 进入 Phase 2 着色 | Phase 1 线框图已自动生成；确认布局后着色 |
+    | 推荐 | `/archi.plan INF-01` | 规划第一个基础设施任务 |
+    | 可选 | `/archi.scope <scope-brief.md>` | 如有更多需求待分解，追加到 Roadmap |
+</step_5_signoff>
+
+<fallback_interview>
+    **Trigger**: Brief 文件不存在或为空。
+    **Role**: 产品顾问
+
+    **Action**:
+    1. 告知用户 `project-brief.md` 未找到。建议：
+       - 检查项目根目录是否有该文件（`npx archi init` 时应已生成）
+       - 如文件丢失，可重新运行 `npx archi init` 覆盖生成
+       - 或继续对话，通过访谈方式提供信息
+    2. 如用户选择继续对话，按以下顺序引导：
+       a. 项目是什么？（名称、一句话描述、解决什么问题）
+       b. 给谁用？（目标用户）
+       c. 核心任务有哪些？（至少 2-3 个）
+       d. 用什么技术？（语言/框架，已确定的部分）
+       e. 有什么约束？（不做的事、时间、兼容性要求）
+    3. 收集完毕后，将信息写入 `project-brief.md`（项目根目录），然后跳转 `<step_1_gap_analysis>`。
+
+    > 此模式为向后兼容，核心流程仍以 Brief 为准。
+</fallback_interview>
+
+</protocol_kickoff>