draftgo-cli 3.0.39 → 3.0.41

package/README.md

@@ -16,6 +16,9 @@ CLI 不再依赖 Python 同步脚本，也不会创建 DraftGo 业务资源的
 ## 工作模型
 
 ```text
+draftgo context -> 精确读取本地 Skill / Reference 章节
+                -> 复用一个 MCP 会话并行查询实时上下文
+
 AI 宿主 -> draftgo mcp serve -> DraftGo /mcp
                                      |
                                      +-> 结构化资源、元数据、搜索和正文片段
@@ -24,21 +27,29 @@ draftgo checkout/commit -> DraftGo 专用 HTTP 正文端点
                            （完整 HTML/Markdown 不经过 MCP 上下文）
 ```
 
+- `draftgo context` 是 CLI 聚合编排命令，不是 MCP 工具；它输出 Reference 原文、原始结构化实时结果和每项来源。
 - MCP 用于项目概览、资源搜索/列表、元数据、正文片段和实时 API 调用。
 - `pages`、`navigations` 和 `docs/articles` 的完整正文使用 `checkout` / `commit`。
 - `db_meta`、AIHub、`system_config`、角色、用户、文档分类、自定义服务等结构化资源直接通过 MCP/API 操作，不生成本地索引。
 - `.draftgo/pages/`、`.draftgo/navigations/` 等旧 `index.json` 缓存只视为 legacy 数据；CLI 不删除它们，但 `map` 和 `check` 会忽略它们。
 - DraftGo Skill 继续提供资源关系、页面规范、数据和权限、安全规则、自定义服务经验以及验证流程；MCP 不替代 Skill。
+- CLI 不提供页面模板，也不替 Agent 选择页面结构或视觉风格。
 
 ## Agent 阅读顺序
 
-DraftGo Skill 不能被 MCP 替代。根 `SKILL.md` 会在 Skill 触发时自动加载；Agent 随后按任务读取相关领域资料，再查询实时状态：
+DraftGo Skill 不能被 MCP 替代。根 `SKILL.md` 会在 Skill 触发时自动加载；开发任务默认运行一次匹配领域的 context：
 
 ```text
-已加载的 SKILL.md -> 按任务读取 references/ 中的领域规则 -> MCP 查询当前状态 -> 必要时 checkout 正文
+已加载的 SKILL.md
+-> draftgo context --task frontend --output json
+-> 精确 Reference 原文 + MCP 当前状态
+-> 按需继续调用 MCP
+-> 必要时 checkout 正文
 ```
 
-例如，盘点页面或判断业务模块前先读 `references/architecture.md` 和 `references/modules.md`。页面或导航的分析、修改、交互和 UI 任务先读 `references/frontend.md`；只有涉及路由、会话、`App` API、iframe/全局注入或运行时行为时才追加 `references/runtime.md`，涉及外部资产/CDN、认证、用户输入或不可信内容、敏感数据或配置时才追加 `references/security.md`。静态资源须先区分：平台内置目录直接由 `frontend.md` 说明，指定页面依赖经 MCP 定位、checkout 后本地搜索，服务器全量文件则不能凭现有 Skill、MCP 摘要或 checkout 声称已枚举。`mcp test` 是连接诊断，不是每次资源查询的前置步骤。
+`context` 先验证并逐字提取当前 CLI 随包 Reference 的固定任务章节，再用同一 MCP 会话并行查询项目、资源、API 和 `db_meta` 数据结构；它不做摘要，也不限制后续 MCP 调用。输出中的 `reference_bundle` 会报告 CLI bundle 与项目已安装 Skill 的版本及同步状态，不同步时先运行 `draftgo update`。页面或导航任务使用 `frontend`，数据、自定义服务、AIHub、正文和项目清点分别可用 `data`、`custom-service`、`aihub`、`content`、`project`。`mcp test` 是连接诊断，不是每次资源查询的前置步骤。
+
+只回答无需实时状态的本地规则问题，或需要 context 路由之外的专项资料时，Agent 继续按根 Skill 表格手工补读。静态资源须先区分：平台内置目录由 `frontend.md` 说明，指定页面依赖经 MCP 定位、checkout 后本地搜索，服务器全量文件不能凭现有 Skill、MCP 摘要或 checkout 声称已枚举。
 
 Skill 说明产品约束、内置能力和操作规则；MCP 说明当前远端状态；checkout 正文才能证明某个页面完整引用了哪些静态资源。汇报时应明确标注这三类证据，不能互相替代。
 
@@ -133,27 +144,42 @@ DraftGo MCP 预期提供以下工具：
 
 ## 标准工作流
 
-陌生项目先通过 MCP 获取概览，再按需搜索、列出或读取资源元数据：
-
 ```text
-project_overview -> resource_search/resource_list -> get_metadata/read_fragment
+context 一次准备信息
+→ Agent 自主设计并批量 checkout
+→ 独立资源按需并行开发
+→ 主 Agent 一次统一验证
+→ commit
+→ draftgo changelog add "<完成结果>"
+```
+
+无依赖且修改不同资源的工作可以并行；同一文件或 DraftGo 资源全程只分配给一个 Agent。开始并行实现前先确定共享 schema、接口、权限和路由。单页面、强依赖或仍共享主要资源的任务由一个 Agent 完成。主 Agent 负责 context、资源 owner、汇总回读、统一验证、commit 和最终 changelog。
+
+前端任务先准备上下文并按需补充 MCP 定位：
+
+```bash
+draftgo context --task frontend --output json
 ```
 
-编辑完整页面、导航或文档正文：
+确定全部正文资源后批量 checkout，自主设计并按唯一 owner 编辑，最后统一验证和交付：
 
 ```bash
-draftgo checkout pages 42
-# 编辑 .draftgo/worktree/pages/page_42.html
+draftgo checkout pages 42 43
+# 独立资源可并行编辑；同一资源只由一个 Agent 修改
 draftgo check
 draftgo verify-ui http://localhost:5173       # UI 变更时
 draftgo diff pages 42
-draftgo commit pages 42
+draftgo diff pages 43
+draftgo commit pages 42 43
+draftgo changelog add "完成文档管理系统及角色权限"
 ```
 
 只查询长内容时，优先使用 MCP 搜索和片段工具；需要全文分析或编辑时才 checkout。不要要求 MCP 返回完整 HTML 或 Markdown。
 
 结构化资源使用 `draftgo_api_search` / `draftgo_api_describe` 查实时契约，再用 `draftgo_api_call` 操作。AIHub Agent、Prompt、MCP、Skill、供应商和模型路由也属于实时结构化资源，不写本地快照；供应商密钥或 header 值不得出现在 Agent 输出中。
 
+只有整个任务统一验证并且所有 commit/MCP 写入成功后才执行一次 `changelog add`。验证失败、409/412 或任一交付失败时不得写入。
+
 ## 命令清单
 
 ### Skill 与连接
@@ -171,6 +197,7 @@ draftgo commit pages 42
 
 | 命令 | 说明 |
 |---|---|
+| `draftgo context --task <task> --output json` | 精确读取任务 Reference 章节，并复用一个 MCP 会话并行查询项目、资源、API 和数据结构；保留原始结果及来源。 |
 | `draftgo map` | 通过 MCP 读取远端项目概览和资源列表，再叠加本地 checkout 状态。 |
 | `draftgo checkout <pages|nav|docs> <id...>` | 下载完整正文和 base，校验 hash 后原子落盘；`--force` 可显式覆盖已修改的本地正文。 |
 | `draftgo check` | 只检查 checkout manifest、worktree 文件、base/hash、扩展名、HTML 结构和已 checkout 导航引用。 |
@@ -193,6 +220,7 @@ draftgo commit pages 42
 | `draftgo delete <operation_id> [id]` | 描述并确认后调用实时 MCP `api_call`；支持 `--params JSON`、`--input file` 和 `--yes`。 |
 | `draftgo deploy [<type> <id...>]` | 先 `check`，再按 delivery 模式检查 diff 或 commit。仅 `--delivery local` 可省略 type/id。 |
 | `draftgo auto-push [<type> <id...>]` | `auto_push: true` 时检查并 commit 已 checkout 的变更；有冲突立即停止。 |
+| `draftgo changelog add "<完成结果>"` | 在整个任务统一验证并全部交付成功后追加一条完成结果。 |
 | `draftgo pull` | 仅输出迁移提示并返回非零；永不下载资源。 |
 | `draftgo push <type> <id...>` | 已弃用；仅对 pages/nav/docs 显示提示后转发到 `commit`。不支持 push-all 或结构化资源。 |
 
@@ -200,6 +228,23 @@ draftgo commit pages 42
 
 `auto-push` 不传 id 时只处理 manifest 中已修改的 checkout；项目未连接或 `auto_push` 未启用时安全跳过。
 
+### 更新日志
+
+`draftgo changelog add` 写入 `.draftgo/changelog.md`。同一天继续编号；本地日期变化后追加新区块并从 `1` 开始。命令只接受单行、非空的完成结果；现有文件不符合固定格式时拒绝改写。
+
+```markdown
+2026-07-31
+===
+1. 完成文档管理系统及角色权限
+2. 修复文档编辑权限问题
+
+2026-08-01
+===
+1. 增加文档分类功能
+```
+
+只记录已完成结果，不记录排查过程。统一验证、409/412 或任一交付失败时不运行该命令。
+
 ### 本地 DraftGo
 
 | 命令 | 说明 |
@@ -282,7 +327,7 @@ checkout 会通过 MCP 获取元数据和专用下载地址，流式写入临时
 前端和自定义服务的关键约定仍然适用：
 
 - 壳层源码使用 React 19 + Vite 8 + Tailwind CSS 4；数据库页面和导航使用原生 HTML，不写入 TSX、ESM import 或 npm 构建产物。
-- 内置 UI、图标、Chat SDK、AIHub 结构化输出和页面布局规则见 `resources/skill/references/`。
+- 内置 UI、图标、Chat SDK、AIHub 结构化输出以及前端运行、交互和验收规则见 `resources/skill/references/`；CLI 和 Skill 不提供页面模板。
 - 自定义服务使用 Go `draftgo/sdk`，通过 `Register(app *sdk.App)` 注册 Route、事件和定时任务；管理权限、调用权限、并发和出站请求约束见 `resources/skill/references/custom-services.md`。
 - 自定义服务、数据、AIHub、权限和系统配置通过实时 MCP/API 操作，不从 `.draftgo/*/index.json` 推断远端状态。
 
@@ -291,7 +336,8 @@ checkout 会通过 MCP 获取元数据和专用下载地址，流式写入临时
 ## 常用选项
 
 - `--project <dir>`：操作指定项目目录，默认当前目录。
-- `--output json`：为 map、check、checkout、commit、diff、conflicts、conflict、api 或 delete 输出 JSON。
+- `--output json`：为 context、map、check、checkout、commit、diff、conflicts、conflict、api 或 delete 输出 JSON。
+- `--task <task>`：选择 context 路由；支持 frontend、data、custom-service、aihub、content、project。
 - `--strict`：check/deploy/auto-push 将 warnings 视为失败。
 - `--force`：init 覆盖已有 Skill；checkout 显式覆盖已修改的本地正文。update 始终刷新目标 Skill。
 - `--purge`：uninstall 时同时删除整个 `.draftgo/` 运行时目录。
@@ -304,7 +350,7 @@ checkout 会通过 MCP 获取元数据和专用下载地址，流式写入临时
 - `--mobile-check auto|always|never`：控制 `verify-ui` 是否执行。
 - `--screenshot on-failure|always|never`：控制 UI 截图。
 - `--delivery local|preview|deploy`：控制 deploy 行为。
-- `--timeout <ms>`：控制 connect/MCP test 超时。
+- `--timeout <ms>`：控制 connect、MCP test 或 context 的远端请求超时。
 
 设置 `DRAFTGO_NO_UPDATE_CHECK=1` 可关闭 npm 版本检查，适用于离线或 CI 环境。
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "draftgo-cli",
-  "version": "3.0.39",
+  "version": "3.0.41",
   "description": "Install and manage the DraftGo skill across AI coding agents (Claude Code, Codex, Cursor, Windsurf, Antigravity, Copilot, Gemini, Kiro).",
   "bin": {
     "draftgo": "bin/draftgo.js"
@@ -45,8 +45,10 @@
     "lint": "node scripts/check-syntax.js",
     "validate:skill": "node scripts/validate-skill.js",
     "verify:package": "node scripts/verify-package.js",
-    "test": "npm run lint && npm run validate:skill && npm run verify:package && npm run test:unit && npm run test:mcp && npm run test:worktree && npm run test:migration && npm run test:local && npm run test:e2e",
+    "test": "npm run lint && npm run validate:skill && npm run verify:package && npm run test:unit && npm run test:context && npm run test:changelog && npm run test:mcp && npm run test:worktree && npm run test:migration && npm run test:local && npm run test:e2e",
     "test:unit": "node tests/unit.js",
+    "test:context": "node tests/context.test.js",
+    "test:changelog": "node tests/changelog.test.js",
     "test:mcp": "node tests/mcp.test.js",
     "test:worktree": "node tests/worktree.test.js",
     "test:migration": "node tests/migration.test.js",

package/resources/skill/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: draftgo
-description: Use this skill before inspecting, developing, maintaining, debugging, or delivering a DraftGo application. It covers project/page/navigation inventories, business-page classification, frontend/static-asset questions, long-form docs, dynamic data, custom services, AIHub, MCP integrations, and local runtime. Read the relevant bundled reference before calling DraftGo MCP; use MCP for live state and checkout/commit for complete page/nav/docs bodies.
+description: Use this skill before inspecting, developing, maintaining, debugging, or delivering a DraftGo application. Start development tasks with draftgo context so exact local Reference sections are read before live MCP discovery; use checkout/commit for complete page/nav/docs bodies and write the changelog only after unified verification and delivery succeed.
 ---
 
 # DraftGo 开发助手
@@ -9,15 +9,29 @@ description: Use this skill before inspecting, developing, maintaining, debuggin
 
 DraftGo CLI 是工作区工具，不是全量云端镜像器。
 
+- 规则：本地 Skill / Reference。
+- 实时数据：MCP。
+- 完整正文：checkout。
+- 聚合编排：`draftgo context`。
 - 用 DraftGo MCP 查询实时资源、API 契约、权限和结构化数据。
 - 只对 pages、nav/navigations 和 docs/articles 的长正文使用 checkout、本地编辑和 commit。
 - 完整 HTML、Markdown 或其他长正文不得作为 MCP 工具参数或 MCP 上下文传输；使用 CLI 的专用 HTTP 流式通道。
+- `draftgo context` 是确定性的 CLI 编排命令，不注册为 MCP 工具；它精确返回相关 Reference 原文及来源，并复用一个 MCP 会话并行查询实时状态。
+- CLI 不提供或生成页面模板，也不替 Agent 选择页面结构或视觉风格；Agent 根据任务、受众和现有资源自主设计。
 - MCP 不可用时报告连接、协议或 SAT 问题；不得自动回退到 pull --all 或旧索引镜像。
 - 本地 Docker、MySQL、Redis、Milvus 和 draftgo local ... 能力与 MCP 工作流相互独立，必须保留。
 
 ## 强制预读：Reference 优先于 MCP
 
-根 `SKILL.md` 会在 Skill 触发时自动加载。调用任何 DraftGo MCP 工具、`draftgo mcp test`、`draftgo map` 或 checkout 前，先按任务路由读取下表中相关的 `references/`；不得仅凭 MCP 的元数据推断产品规则、模块归属或前端能力。前端任务的共同规则：任何页面或导航的分析、修改、交互和 UI 任务都先读 `references/frontend.md`；涉及路由、会话、`App` API、iframe/全局注入或运行时行为时加读 `references/runtime.md`；涉及外部资产/CDN、认证、用户输入或不可信内容、敏感数据或配置时加读 `references/security.md`。静态资源只是该规则的一种专门场景。对于较长 reference，先用 `rg -n` 定位指定标题，再读取该节及其明确要求的安全或运行时约束；不要无目的地加载整份资料。
+根 `SKILL.md` 会在 Skill 触发时自动加载。开发、修改或交付任务默认先运行一次与领域匹配的 `draftgo context --task <task> --output json`；前端任务使用：
+
+```bash
+draftgo context --task frontend --output json
+```
+
+该命令先校验并逐字读取当前 CLI 随包的本地 Reference 章节，再在同一个 MCP 会话中并行查询项目、资源、API 和数据结构；输出保留原始结构化结果、实际工具名、参数和来源，不做有损总结。`reference_bundle` 同时报告 CLI bundle 版本、项目已安装 Skill 版本和同步状态；不同步时先运行 `draftgo update`。它不限制 Agent 后续继续直接调用 MCP。只回答无需实时状态的本地规则问题，或 context 未覆盖的专项章节时，按下表手工补读；context 失败时报告原始问题，不得跳过 Reference 直接猜测。
+
+不得仅凭 MCP 的元数据推断产品规则、模块归属或前端能力。前端任务的共同规则：任何页面或导航的分析、修改、交互和 UI 任务都先读 `references/frontend.md`；涉及路由、会话、`App` API、iframe/全局注入或运行时行为时加读 `references/runtime.md`；涉及外部资产/CDN、认证、用户输入或不可信内容、敏感数据或配置时加读 `references/security.md`。静态资源只是该规则的一种专门场景。
 
 | 用户问题或任务 | MCP 前必须读取的 Skill 材料 | 然后才可取得的实时证据 |
 |---|---|---|
@@ -34,24 +48,42 @@ DraftGo CLI 是工作区工具，不是全量云端镜像器。
 
 汇报时明确区分三类证据：Skill 给出的产品约束和内置能力、MCP 返回的当前远端状态、以及 checkout 正文中确认的精确页面依赖。不能把其中任一类冒充为另一类。例如，Skill 列出的 `/assets/` 能力不是当前服务器文件清单，MCP 的页面摘要也不是完整 HTML 依赖清单。最终答复列出具体已读取的 reference，不能只笼统声称“已读 Skill”。
 
+## 并行开发与所有权
+
+- 无依赖且修改不同文件或 DraftGo 资源的任务并行开发。
+- 同一文件或 DraftGo 资源全程只能由一个 Agent 修改；其他 Agent 只能只读分析并向唯一 owner 回传建议。
+- 分发实现前先确定共享的数据结构、接口、权限和路由，再并行开发消费者。
+- 主 Agent 负责执行一次 context、分配资源 owner、汇总回读、统一验证、commit，并仅在全部交付成功后写 changelog。
+- 单页面、强依赖任务或拆分后仍共享主要资源的任务不强行并行，避免协调成本拖慢开发。
+
+详细工作单元和 wave 规则见 `references/parallel.md`。
+
 ## 标准工作流
 
+```text
+context 一次准备信息
+→ Agent 自主设计并批量 checkout
+→ 独立资源按需并行开发
+→ 主 Agent 一次统一验证
+→ commit
+→ draftgo changelog add "<完成结果>"
+```
+
 ### 项目清点与陌生项目
 
-1. 先按上表读取领域 reference。仅需判断页面、导航、业务模块或静态资产时，不要跳过此步。
-2. 若需要当前远端状态，通过 MCP 的 `project_overview`、`resource_search`/`resource_list` 获取摘要。
-3. 只按需调用 describe 或元数据工具；不要为了建立上下文下载所有正文。
-4. 运行 `draftgo map` 叠加本地 checkout 状态，再决定资源范围。
-5. `draftgo mcp test` 只用于 connect 后验证、配置变更或 MCP 调用失败后的诊断；普通资源查询不应先执行它。
+1. 运行匹配领域的 `draftgo context --task <task> --output json`，一次取得规则原文及实时基础信息。
+2. 根据 context 的来源和原始结果确认资源范围；按需继续调用 MCP search、describe 或 metadata，不把 context 当成后续查询限制。
+3. 需要叠加本地 checkout 状态时运行 `draftgo map`。
+4. `draftgo mcp test` 只用于 connect 后验证、配置变更或 MCP 调用失败后的诊断；普通资源查询不应先执行它。
 
 ### 页面、导航和文档正文
 
-1. 通过 MCP 定位资源并取得元数据、content_type、版本和哈希。
-2. 运行 draftgo checkout pages <id...>、draftgo checkout nav <id...> 或 draftgo checkout docs <id...>。
-3. 读取、搜索和编辑 .draftgo/worktree/ 中的正式文件；保留原始内容类型和编码。
-4. 运行 draftgo check，页面布局或交互变化时再运行 draftgo verify-ui。
-5. 用 draftgo diff <type> <id> 检查 base 与 local 差异。
-6. 运行对应的 draftgo commit ...。提交遇到 409/412 时停止，保留冲突材料并等待 Agent 或用户解决。
+1. 运行 frontend 或 content context，并按需继续通过 MCP 定位资源、取得元数据。
+2. Agent 根据任务自主设计；对已确定的 pages/nav/docs 批量 checkout。
+3. 按唯一资源 owner 读取、搜索和编辑 `.draftgo/worktree/` 正文；独立资源可并行。
+4. 主 Agent 汇总回读后统一运行一次 `draftgo check`，页面布局或交互变化时再统一运行 `draftgo verify-ui`。
+5. 用 `draftgo diff <type> <id>` 检查全部 base/local 差异，再运行对应的 `draftgo commit ...`。
+6. 全部验证和 commit 成功后执行一次 `draftgo changelog add "<完成结果>"`。任何验证失败、409/412 或交付失败都停止且不写 changelog。
 
 详细 manifest、扩展名、哈希和冲突规则见 references/checkout.md。
 
@@ -64,6 +96,7 @@ DraftGo CLI 是工作区工具，不是全量云端镜像器。
 db_meta、AIHub、system_config、roles、users、doc_categories、普通配置和自定义服务元数据直接使用 MCP 的 api_search、api_describe、api_call 或语义化工具。
 
 不要为这些资源创建全量本地镜像，也不要读取旧 .draftgo/*/index.json 作为事实来源。领域 schema、权限和实践约束仍可从本 Skill 的 references 读取。
+按唯一资源 owner 完成修改，主 Agent 回读并验证全部副作用；只有所有结构化资源交付成功后才执行一次 `draftgo changelog add`。
 
 ## CLI 场景路由
 
@@ -74,9 +107,11 @@ db_meta、AIHub、system_config、roles、users、doc_categories、普通配置
 | 配置或诊断 MCP | draftgo mcp setup [target...]、draftgo mcp test；细节见 references/mcp.md |
 | 连接基座 | draftgo connect；保存 server/SAT、验证 /mcp 和关键工具，不拉取业务资源 |
 | 本地基座 | draftgo local setup，然后 draftgo local start/stop/logs/status；兼容 local-dev、local up/down |
+| 一次准备任务上下文 | draftgo context --task frontend\|data\|custom-service\|aihub\|content\|project --output json |
 | 远端摘要或资源定位 | MCP project_overview、resource_search、resource_list、按需 metadata 工具 |
-| 页面、导航、文档正文 | checkout → 本地编辑 → check/verify-ui → diff → commit |
+| 页面、导航、文档正文 | context → 批量 checkout → 按资源 owner 编辑 → 统一 check/verify-ui → diff → commit |
 | 结构化资源读写 | MCP api_search、api_describe、api_call 或语义化工具 |
+| 完成结果日志 | 全部验证和交付成功后 draftgo changelog add "<完成结果>"；失败时禁止写入 |
 | 删除资源 | 使用实时 MCP/API 删除；不得从本地旧索引推断目标或清理正文 |
 | 兼容旧命令 | draftgo pull 只显示迁移提示并返回非零；draftgo push pages/nav/docs 显示弃用提示后转发到 commit。其他 push 类型引导使用 MCP。 |
 
@@ -111,6 +146,8 @@ db_meta、AIHub、system_config、roles、users、doc_categories、普通配置
 
 draftgo deploy、auto-push 等旧交付入口必须遵循当前 CLI 的 commit 语义；不把它们当作旧全量 push 的回退路径。
 
+主 Agent 必须汇总全部修改和验证证据后再交付。只有任务统一验证并且所有 commit/MCP 写入成功时，才运行一次 `draftgo changelog add "<完成结果>"`；日志只写完成结果，不写排查过程。验证失败、冲突或任一交付失败时不得写入。
+
 ## 参考路由
 
 - MCP、宿主配置和 bridge：references/mcp.md
@@ -133,4 +170,5 @@ draftgo deploy、auto-push 等旧交付入口必须遵循当前 CLI 的 commit
 | .draftgo/worktree/.base/ | checkout 时保存的 base；必须 gitignore |
 | .draftgo/conflicts/ | 409/412 冲突材料；必须 gitignore |
 | .draftgo/worktree/manifest.json | checkout 的版本、路径、内容类型和哈希；必须 gitignore |
-| .draftgo/story.yaml、Task/、lessons/、changelog.md | 项目决策、任务和经验；按项目策略保留 |
+| .draftgo/story.yaml、Task/、lessons/ | 项目决策、任务和经验；按项目策略保留 |
+| .draftgo/changelog.md | 完成结果日志；统一验证和全部交付成功后必须写入，失败时禁止写入 |

package/resources/skill/init/SKILL.md

@@ -17,7 +17,7 @@ description: Install or refresh the DraftGo skill, connect a project to a DraftG
    - 已有 DraftGo 服务器：运行 draftgo connect。
    - 需要本地 Docker 基座：运行 draftgo local setup。
 6. 连接后运行 draftgo mcp setup（或指定目标），再运行 draftgo mcp test 验证 initialize、tools/list 和关键工具。
-7. 运行 draftgo map 获取远端摘要和本地 checkout 状态；MCP 不可用时报告原因，不回退到 pull --all。
+7. 运行 `draftgo context --task project --output json`，一次取得本地规则原文与远端实时上下文；只有需要叠加本地 checkout 状态时再运行 `draftgo map`。MCP 不可用时报告原因，不回退到 pull --all。
 
 draftgo init 只负责 Skill 安装；draftgo connect 负责保存并验证 server/SAT；draftgo mcp setup 负责宿主配置。不要混用职责。
 
@@ -31,9 +31,11 @@ draftgo init 只负责 Skill 安装；draftgo connect 负责保存并验证 serv
 ## 后续动作
 
 - 宿主配置和诊断：draftgo mcp setup/status/test，详见 ../references/mcp.md。
-- 远端资源摘要：MCP project_overview、resource_search、resource_list。
-- 正文编辑：draftgo checkout <pages|nav|docs> <id...>，本地修改后 draftgo check、draftgo diff、draftgo commit ...。
+- 开发上下文：先运行匹配领域的 `draftgo context --task <task> --output json`；context 后仍可按需直接调用 MCP。
+- 远端资源补充定位：MCP project_overview、resource_search、resource_list。
+- 正文编辑：自主设计并批量 checkout，不同资源按唯一 owner 并行修改，由主 Agent 统一运行 check/必要的 verify-ui、diff 和 commit。
 - 结构化资源：直接使用 MCP 的 api_search、api_describe、api_call；不 checkout、不生成本地镜像。
+- 完成日志：只有整个任务统一验证且全部 commit/MCP 交付成功后，由主 Agent 执行一次 `draftgo changelog add "<完成结果>"`；验证、冲突或交付失败时不得写入。
 - 管理本地基座：draftgo local start|stop|logs|status；local-dev、local up/down 仍可用。
 - 移除指定目标：draftgo uninstall <target>；完整移除所有目标只在用户明确要求时运行 draftgo uninstall all，--purge 会删除 .draftgo/。
 

package/resources/skill/manifest.json

@@ -2,12 +2,14 @@
   "schema_version": "1.0",
   "id": "draftgo",
   "name": "DraftGo 开发助手",
-  "version": "3.0.39",
+  "version": "3.0.41",
   "entry": "SKILL.md",
-  "description": "以 Skill/reference 优先路由、MCP 实时发现、长正文 checkout/commit、验证、本地运行与 Skill 分发的 DraftGo 工作流。",
+  "description": "以 context 聚合编排、Skill/reference 原文、MCP 实时发现、长正文 checkout/commit、统一验证和完成日志为边界的 DraftGo 工作流。",
   "license": "MIT",
   "capabilities": [
     "draftgo-development",
+    "context-orchestration",
+    "completion-changelog",
     "custom-service-ai-sdk",
     "mcp-bridge",
     "content-checkout-commit",

package/resources/skill/push/SKILL.md

@@ -42,6 +42,8 @@ commit 是长正文的唯一正式交付动作。push pages/nav/docs 仅是兼
 5. 成功后原子更新 manifest、base、版本和哈希，并回读清晰的提交结果。
 6. 发生 409/412 时返回非零，停止重试和 auto-commit，保留 local/base 并生成 remote 及冲突 manifest。
 
+单个 commit 成功不自动写 changelog。主 Agent 只有在全部资源统一验证和交付成功后，才显式执行一次 `draftgo changelog add "<完成结果>"`；409/412、验证失败或其他交付失败时不得写入。
+
 ## 冲突
 
 冲突目录必须包含可定位的 base、local、remote 三份材料。不要覆盖任一份，也不要手写不可靠的 HTML 合并器。Agent 或用户完成合并后，重新运行 check/verify-ui，确认最新 base，再执行 commit。

package/resources/skill/references/architecture.md

@@ -55,7 +55,7 @@ App.isAdmin       // 是否管理员
 App.theme         // 'light' | 'dark'
 ```
 
-完整 API 速查表见 `{{SKILL_DIR}}/references/app-api.md`
+完整 API 速查表见 `references/app-api.md`
 
 ---
 

package/resources/skill/references/checkout.md

@@ -91,8 +91,9 @@ base 已变化时必须拒绝覆盖。
 4. 完整正文不得作为 MCP tool 参数发送。
 5. 底座确认 hash 和新版本后，CLI 原子更新 `.base` 与 manifest。返回 hash 不一致时不得推进基线。
 
-推荐编辑顺序：完成相关 `references/` 的任务预读 -> MCP 定位 -> checkout -> 本地编辑 -> `draftgo check` -> 必要时 `draftgo verify-ui`
--> `draftgo diff` -> commit。
+推荐编辑顺序：主 Agent 执行一次 context -> MCP 按需补充定位 -> Agent 自主设计并批量 checkout -> 独立资源按唯一 owner 并行编辑 -> 主 Agent 汇总回读 -> 统一运行一次 `draftgo check` 和必要的 `draftgo verify-ui` -> `draftgo diff` -> commit。
+
+单个 commit 成功不自动写 changelog。只有整个任务统一验证且全部 commit/MCP 交付成功后，主 Agent 才执行一次 `draftgo changelog add "<完成结果>"`。任何检查失败、409/412 或交付失败都不得写入。
 
 ## 409 / 412 冲突