draftgo-cli 2.0.3 → 2.0.9

package/resources/skill/rules/dev-workflow.md

@@ -13,9 +13,9 @@ version: 1.0.0
 ## 总则：四档开发流程
 
 ```
-小修       直接定位 → 改 → check → push
-轻功能     范围复述 → 直接做 → 主路径验证 → push
-标准功能   轻量确认 → Task → TDR
+小修       直接定位 → 改 → 轻量证据
+轻功能     范围复述 → 直接做 → 凭证据闭环
+标准功能   轻量确认 → 内部短计划 → 执行闭环
 高风险     完整 Story / 计划 / 验证 / 人工确认
 ```
 
@@ -23,6 +23,33 @@ version: 1.0.0
 
 ---
 
+## 交付追求（强制但不模板化）
+
+DraftGo-CLI 的目标不是只把页面写出来，而是让 AI 基于基座快速交付高质量项目：
+
+- **开发的急速感**：优先用本地 index、目标文件、现有资源和最小必要规则快速建立上下文；资源关系不清时再用 `draftgo map`。小修和轻功能不要被表格化流程拖慢。
+- **逻辑与实现的完整**：优先考虑真实落地闭环、高可用；默认真实数据、真实入口、真实反馈和必要证据。页面、导航、DB、脚本、权限和后台维护按用户路径闭环推断。
+- **迭代性强**：文件命名、route、数据 schema、组件结构、changelog、Task/lessons 记录要让下一次 AI 或开发者能继续接手。
+- **前端 UI 交给 shadcn 能力**：平台壳层默认 React + shadcn/ui + Tailwind；数据库 HTML 页面中的 `dg-*` 必须理解为 shadcn 的 DraftGo HTML 协议表达。若本地 Agent 环境存在 shadcn / 前端 UI 相关 Skills，前端界面开发时优先调用；DraftGo-CLI 提供运行时、资源、数据、路由、入口绑定和验证方法。
+
+判断一版交付是否合格：用户路径、数据和操作能真实落地，后续继续改不用重猜结构。
+
+---
+
+## 真实落地默认原则（强制）
+
+除非用户明确要求“静态 / 纯页面 / demo / mock / 假数据 / 伪功能 / 先看效果”，任何开发任务都优先考虑真实落地闭环、高可用。
+
+- 不要把功能降级成只有前端展示的假页面；按钮、表单、搜索、筛选、分页、提交、保存、删除、发布、管理等交互默认要有真实效果。
+- 不要用写死数组、静态卡片、空点击事件、只弹 toast 的按钮伪装业务能力；演示数据只能用于加载态、空态或用户明确要求的原型/demo。
+- 如果需求涉及可维护内容或业务记录，优先判断是否可用 DraftGo 动态 DB、已有 db_meta、custom_scripts、外部 API 或 AIHub 资产完成真实数据闭环，并考虑后续维护、迭代和稳定性。
+- **数据存储选型：业务数据优先用动态 DB 通用库。**
+- 若平台能力、权限、外部依赖或通用动态 DB 都无法支撑该功能，不要继续开发伪功能；向用户说明具体阻塞点和可选替代方案，确有复用价值时在 `.draftgo/lessons/` 记录“无法闭环原因 / 已验证限制 / 后续建议”。
+
+一句话判断：用户没有明确要假，就优先考虑真实落地闭环、高可用；做不了真实闭环，就停下来说明，不写假的。
+
+---
+
 ## 轻量任务识别与用户意图翻译
 
 不要把流程做成固定填表。开发前先用 AI 自身判断力做一次轻量识别：这次是小修、轻功能、标准功能，还是高风险系统改动。识别结果用于决定规划深度，不要求每次都输出模板。
@@ -34,15 +61,17 @@ version: 1.0.0
 3. 看使用角色：访客、普通用户、管理员、运营、审核员、客服、内部人员等决定是否需要前台 / 后台 / 权限。
 4. 看现有项目结构：已有导航、页面命名、db_meta、custom_scripts、角色体系和 Story 都是默认推断依据。
 
+进入陌生项目、资源关系不清、多页面任务或用户描述较模糊时，先运行 `draftgo map` 快速获得资源地图；目标文件明确的小修和局部改动可以跳过。`draftgo map --output json` 可用于机器读取，不替代具体文件阅读。
+
 默认策略：
 
 - 用户说“修改 / 调整 / 优化某个已存在页面” → 默认按单资源改动处理；范围清晰则小修，影响主流程则轻功能或标准功能。
-- 用户说“做 / 新建 / 增加一个页面” → 默认按**完整页面功能**处理：页面可访问、交互有效、状态完整、必要数据真实读写、入口已绑定。只有用户明确说“静态页 / 纯页面 / 视觉稿 / demo / 先做效果”时，才允许按静态页面处理。
-- 用户说“做一个功能 / 模块 / 系统能力” → 默认按功能闭环处理，不能自动降级为单个展示页。
+- 用户说“做 / 新建 / 增加一个页面” → 默认按**完整页面功能**处理：页面可访问、交互有效、状态完整、必要数据真实读写、入口已绑定，并优先考虑真实落地闭环、高可用。只有用户明确说“静态页 / 纯页面 / 静态稿 / demo / mock / 假数据 / 伪功能 / 先做效果”时，才允许按静态页面处理。
+- 用户说“做一个功能 / 模块 / 系统能力” → 默认按功能闭环处理，不能自动降级为单个展示页或前端假数据。
 - 用户说“管理 / 维护 / 发布 / 审核 / 上下架” → 默认需要后台管理能力和真实数据闭环。
 - 用户说“官网 / 官方 / 平台 / 系统” → 不要做孤立页面；至少考虑导航入口、访问路径和完整用户路径。
 
-只有当不确定点会明显改变页面数量、数据结构、后台能力、权限或风险时，才向用户确认。确认最多 1-3 个问题，并给出推荐默认值；其余细节由 AI 自主推断，并按任务等级记录到范围复述、Task 或 TDR 中。
+只有当不确定点会明显改变页面数量、数据结构、后台能力、权限或风险时，才向用户确认。确认最多 1-3 个问题，并给出推荐默认值；其余细节由 AI 自主推断，并按任务等级记录到范围复述、内部短计划或 Task 中。
 
 ### 用户路径链路（功能任务默认视角）
 
@@ -78,9 +107,9 @@ version: 1.0.0
 ```
 1. 定位：读目标 index / 文件，确认 resource id 与文件路径
 2. 改：只做最小必要改动
-3. check：运行能覆盖该改动的最小检查（lint / 语法 / 浏览器 / 回读）
-4. push：用 draftgo_push.py 推送对应资源
-5. 录：写 changelog
+3. 证据：用与改动匹配的轻量方式确认命中（文件回读 / 语法检查 / diff / 必要的本地检查）
+4. 同步：需要云端生效或用户要求时再 push
+5. 记录：影响可见功能、已 push 或有接手价值时写 changelog
 ```
 
 小修不需要 Story 门、需求门、Task 文档，也不需要并行分发。若执行中发现影响面扩大，立即升级为「轻功能」或「标准功能」。
@@ -102,7 +131,7 @@ version: 1.0.0
 1. 范围复述：一句话说明要做什么、入口在哪里、如何验证
 2. 直接做：读目标资源，按最小闭环实现
 3. 主路径验证：入口可达、核心交互有效、关键状态不空白
-4. push + changelog：推送相关资源并记录
+4. 证据闭环：按影响选择 check / push / changelog
 ```
 
 轻功能不强制创建 Task 文档，不强制 depends/resource_lock/wave，也不启用并行。若执行中发现需要多个页面协作、后台管理、复杂权限或资源冲突，升级为「标准功能」。
@@ -121,9 +150,9 @@ version: 1.0.0
 ```
 1. 若 .draftgo/story.yaml 存在，静默加载；不存在时不阻塞开发，完成后提醒补 Story
 2. 轻量确认：意图翻译 + 必要追问 + 范围复述
-3. 计划门：创建 Task 文档，写任务清单；多任务 / 多资源冲突时补充 depends/resource_lock/wave
-4. 执行门：按 TDR 循环逐任务执行
-5. 闭环门：证据 + changelog + Task 标记 + push 输出
+3. 内部短计划：列清资源、入口、数据、关键交互和证据形式；跨资源、多页面协作、并行或高风险时再创建 Task
+4. 执行门：按短计划逐项实现
+5. 闭环门：证据 + 按影响选择 changelog / check / push；有 Task 时同步标记
 ```
 
 标准功能任务最低规划要求：写清楚用户路径链路、页面入口/导航绑定、前台与后台是否需要同一份数据、哪些交互必须真实有效。不要把“页面看起来存在”当成“功能完成”。
@@ -144,7 +173,7 @@ version: 1.0.0
 1. Story 门：无 .draftgo/story.yaml 必须先构建；有则静默加载并做冲突检测
 2. 完整确认：挖透关键风险、边界和验收，复述确认后才动手
 3. 计划门：Task 文档 + 风险点 + 回滚/验证方案 + 人工确认点
-4. 执行门：TDR；涉及 roles/users/custom_scripts 等按 push skill 要求二次确认
+4. 执行门：轻量闭环执行；涉及 roles/users/custom_scripts 等按 push skill 要求二次确认
 5. 闭环门：真实验证证据 + push 输出 + 回读结果 + 影响范围说明
 ```
 
@@ -236,7 +265,7 @@ C. <更完整方案>
 ☐ 2. 不做什么（边界）
 ☐ 3. 成功长什么样（验收）
 ☐ 4. 已知约束（用户角色 / 权限 / 数据结构 / 现有页面位置）
-☐ 5. 视觉 / 体验偏好（如果涉及前端 UI）
+☐ 5. 前端 UI 需求（如果用户明确提出）
 ```
 
 **追问优先用多选题**，开放题作为兜底。
@@ -269,9 +298,9 @@ C. <更完整方案>
 
 ---
 
-## 计划门（标准功能 / 高风险，一次性产出，不打扰用户）
+## 计划门（按需 Task / 高风险，一次性产出，不打扰用户）
 
-轻量确认过了之后，AI **自主产出**设计 + 任务清单，落到 `.draftgo/Task/` 文件夹。小修和轻功能不创建 Task 文档。
+轻量确认过了之后，AI 先做**内部短计划**并直接执行；只有跨资源、多页面协作、并行开发、需要长期接手或高风险任务，才把设计 + 任务清单落到 `.draftgo/Task/` 文件夹。小修、轻功能和普通标准功能不创建 Task 文档。
 
 ### Task 文件位置
 
@@ -316,7 +345,7 @@ related_changelog: YYYY-MM-DD
 - 不做：...
 - 验收：...
 - 约束：...
-- 视觉偏好：...
+- 前端 UI 需求：...
 
 ## 设计
 
@@ -348,10 +377,10 @@ related_changelog: YYYY-MM-DD
   - 步骤：
     1. 读取当前文件，定位 X
     2. 在 Y 位置插入 Z
-    3. 浏览器打开 /admin/users 实测（验四态）
-    4. 调 push 脚本：`python {{SKILL_SCRIPTS}}/draftgo_push.py pages <page_id>`
-    5. 写更新日志
-  - 验证证据：浏览器截图说明 + push 输出 + console 无报错
+    3. 验证：文件回读 / draftgo check / 与改动匹配的轻量证据
+    4. 需要云端生效时调 push 脚本：`python {{SKILL_SCRIPTS}}/draftgo_push.py pages <page_id>`
+    5. 需要接手记录时写更新日志
+  - 验证证据：文件回读 / check / push 输出（如已推送）
 
 - [ ] T2. ... ⬜
 
@@ -413,14 +442,14 @@ related_changelog: YYYY-MM-DD
 
 ---
 
-## 门 3：执行门（DraftGo 特化的 TDR 循环）
+## 执行节奏（轻量闭环）
 
-DraftGo 主要场景是**改 HTML 页面、改导航、调 App API、写 custom_script、注册外部 API**。TDD 在这里大部分用不上，换成 **TDR 循环**：
+DraftGo 主要场景是**改 HTML 页面、改导航、调 App API、写 custom_script、注册外部 API**。执行时保持小步、可理解、有证据：
 
 ```
-Tiny     最小改动，一次只动一件事
-Demo     立即可演示（浏览器实测 / curl 验证 / 脚本执行）
-Record   迭代记录 + 任务标记 + 同步
+Small    小步实现，一次只动清楚的一件事
+Evidence 用文件回读 / check / 与改动匹配的轻量证据确认
+Record   按影响选择 changelog / Task 标记 / push
 ```
 
 ### 并行分发（Wave 模式）
@@ -428,31 +457,33 @@ Record   迭代记录 + 任务标记 + 同步
 当任务数 ≥ 3、存在多个 Wave 1 任务（`depends: []` 且 resource_lock 不冲突）、任务边界清晰，且并行收益大于协调成本时，主代理可启用并行：
 
 1. **分发**：为每个 Wave 1 任务生成子代理，携带上下文包（task 定义 + 当前文件 + 禁区摘要）
-2. **子代理执行**：每个子代理独立完成 TDR 的 Tiny + Demo，产出修改文件 + changelog 条目 + 验证报告
+2. **子代理执行**：每个子代理独立完成小步实现和证据确认，产出修改文件 + 验证报告；需要接手记录时再产出 changelog 条目
 3. **收集**：主代理收集所有子代理产出，写入文件系统
-4. **批量推送**：`python {{SKILL_SCRIPTS}}/draftgo_push.py --batch <type1> <id1>,<id2> <type2> <id3>`
+4. **批量推送**：需要云端生效时运行 `python {{SKILL_SCRIPTS}}/draftgo_push.py --batch <type1> <id1>,<id2> <type2> <id3>`
 5. **Wave 2**：依赖已完成的任务可以开始，重复上述流程
-6. **闭环**：主代理统一更新 Task 文档 + 闭环门
+6. **闭环**：主代理统一汇总证据；有 Task 文档时再更新标记
 
 **退化条件**：平台不支持子代理 / 任务数不足 / 边界不清 / 协调成本更高 / 用户明确说"串行" → 静默退化为逐任务串行。
 
 详细协议见 `{{SKILL_DIR}}/rules/parallel.md`。
 
-### 每个任务的六步执行
+### 每个任务的轻量执行
 
 ```
 1. 读 —— 读当前文件状态，理解现状（不读不改）
+        • 资源关系不清 / 陌生项目 / 多页面任务：先跑 `draftgo map`
+        • 涉及页面闭环：读取 pages/index.json、navigations/index.json 和相关 HTML
 2. 改 —— 做最小必要改动，不顺手改无关代码
-3. 演 —— 立即看效果：
-        • 页面类：在浏览器里实测路径 / 四态 / 边界场景
-        • API 类：用 App.callApi / Python urllib / push 脚本真实跑一次
+3. 证 —— 用与改动匹配的轻量证据确认：
+        • 页面类：文件回读、入口引用、状态结构、关键交互代码路径
+        • API 类：用 App.callApi / Python urllib / 管理端测试端点真实跑一次
                   （Windows 环境下 curl 对中文/特殊字符编码易出错，建议优先用 Python urllib/requests）
         • custom_script：用 POST /api/scripts/{id}/execute 跑一遍
         • db_meta / aihub / 外部 API：注册或更新后用 GET 回读字段
-4. 录 —— 写更新日志到 .draftgo/changelog.md
+4. 录 —— 影响可见功能、跨资源、已 push 或需接手时写更新日志到 .draftgo/changelog.md
         格式：- [HH:MM] [操作类型] 描述（不超过 30 字）
-5. 推 —— 按资源类型调对应 push 脚本（pages / nav / db_meta / aihub / external_apis / system_config / docs / doc_categories / custom_scripts / roles / users）
-6. 标 —— 标准功能 / 高风险任务在 Task 文档里把这个任务勾掉，记录证据摘要；小修和轻功能无需 Task 标记
+5. 推 —— 需要云端生效时按资源类型调对应 push 脚本（pages / nav / db_meta / aihub / external_apis / system_config / docs / doc_categories / custom_scripts / roles / users）
+6. 标 —— 有 Task 文档时把对应任务勾掉并记录证据摘要；没有 Task 文档则不补建
 ```
 
 ### 分段实现原则
@@ -460,7 +491,7 @@ Record   迭代记录 + 任务标记 + 同步
 复杂或高风险代码应分段实现并验证；不要一次性写入难以检查的大块代码。
 
 1. 按功能模块或逻辑段落拆分，优先保持每段可理解、可验证
-2. 大段 HTML/CSS/JS 写入后及时做语法或浏览器检查
+2. 大段 HTML/CSS/JS 写入后及时做语法、结构或静态检查
 3. 批次间保持上下文连贯（闭合标签、函数结尾等不可跨批断开）
 
 **原则**：分段是为了降低错误率，不是为了机械限制行数；清晰、完整、可验证优先。
@@ -471,10 +502,22 @@ Record   迭代记录 + 任务标记 + 同步
 
 1. **强制先读** `.draftgo/db_meta/index.json` 中对应 type 的 schema
 2. 字段名、字段类型、是否必填 **以 schema 为准**，不凭印象写
-3. 如果 `db_meta/index.json` 不存在或对应 type 缺失，先 `/draftgo pull db_meta` 刷新
+3. 要对某字段做检索/筛选（`filters`）或排序（`order_by`）前，先确认该字段在 schema 里标了 `searchable`，且操作符匹配其检索模式（`exact`→eq/in，`fuzzy`→eq/like/in，`range`→eq/gte/lte/gt/lt/in，`contains`→contains）；未标 searchable 或操作符不匹配后端返回 400
+4. 如果 `db_meta/index.json` 不存在或对应 type 缺失，先 `/draftgo pull db_meta` 刷新
 
 违反后果：字段名写错 → 数据静默丢失 → 排查成本极高。
 
+### custom_script 契约前置门（强制）
+
+当前端要对接某个 custom_script 的 route 端点（`App.callApi`、`fetch('/api/x/<slug>/...')`、DB 列表/表单页依赖某脚本的读写接口）时，**云端正在运行的脚本才是唯一契约真相，本地 `code_file` 不是**：
+
+1. **对接前强制确认"本地 = 云端"**：先 `python {{SKILL_SCRIPTS}}/draftgo_pull.py custom_scripts <id>` 拉云端运行版，或直接探测关键端点（如目标端点返回 404 即说明云端没有该 route）。两者一致才可按本地契约写前端。
+2. **本地领先时先推后接**：若本地脚本已演进但因 custom_scripts 推送的二次确认被跳过而未上云，必须先完成推送（push skill 的二次确认流程），不得对着"未上云的本地契约"写前端。
+3. **跳过推送必须留痕**：任何一次跳过 custom_scripts 推送，都要在 changelog 或 Task 里写明"本地脚本 vN 未上云"，避免后续 AI 误判已生效。
+4. **route 端点设计约束**：custom_script 的 route ctx 只有 `{body, query_params, headers, method, path, user}`，**没有 `path_params`**；基座不从 `/api/x/{slug}/{path}` 里提取 `{id}`/`{uid}` 这类路径模板。需要 id 的写操作（删除/编辑）一律走 `POST + body 带 id`，不要写 `@route("DELETE /xxx/{id}")` —— 这类 handler 取不到 path 参数，永远走异常分支，是死代码。
+
+违反后果：本地脚本 ≠ 云端运行版 → 前端对错契约 → 列表恒空 / 写读两套存储，排查极隐蔽。
+
 ### 执行禁区（继承现有规则）
 
 以下规则在根 [SKILL.md](../SKILL.md) "开发禁区"和 [frontend.md](./frontend.md) 中已有定义，执行时**全部生效**：
@@ -487,8 +530,12 @@ Record   迭代记录 + 任务标记 + 同步
 - ❌ `navigate('/login')` 退出（用 `window.location.href = '/login'`）
 - ❌ `window.alert / confirm / prompt`（用 `App.toast / confirm / showModal`）
 - ❌ 硬编码颜色（用 `var(--dg-*)` token）
+- ❌ 把 `dg-*` 当成自研 UI、daisyUI、Bootstrap、Ant Design 或 Element Plus（`dg-*` 只能表示 shadcn 的 HTML 协议形态）
+- ❌ 在数据库 HTML 页面直接写 React/TSX 版 shadcn 组件（应写对应 `dg-*` 标签，或补齐缺失映射）
 - ❌ `App.confirm` 不 `await`（详见 [debugging-syntax.md](./debugging-syntax.md) 第 3 条）
 - ❌ `await` 用在非 `async` 函数里（详见 [debugging-syntax.md](./debugging-syntax.md) 第 2 条）
+- ❌ custom_script 里写 `@route("DELETE /x/{id}")` 取 `ctx.path_params`（route ctx 无 path_params，需 id 的写操作走 POST+body）
+- ❌ 对着未上云的本地 custom_script 契约写前端（先 pull/探测确认本地=云端，见上「custom_script 契约前置门」）
 
 ### 调试方法论（升级 debugging-syntax.md 的清单为方法论）
 
@@ -498,15 +545,15 @@ Record   迭代记录 + 任务标记 + 同步
 取证 → 模式 → 假设 → 修复
 ```
 
-1. **取证**：先看浏览器 console，再看 `.draftgo/changelog.md`，再看 push 输出。**先取证再判断**，禁止靠猜。
+1. **取证**：先看文件回读、`.draftgo/changelog.md`、`draftgo check`、API 回读或 push 输出中最贴近问题的证据。**先取证再判断**，禁止靠猜。
 2. **模式**：对照 [debugging-syntax.md](./debugging-syntax.md) 10 大致命缺陷清单。九成"页面静默失效"都在里面。
 3. **假设**：一次只验证一个假设。在关键路径加 `console.log('=== A 点 ===')` 二分定位。
-4. **修复**：修根因，不修表面。改完跑一次完整 TDR 循环。
+4. **修复**：修根因，不修表面。改完用与改动匹配的轻量证据确认。
 5. **3 次修不好停手**：去 `.draftgo/lessons/` 写经验记录（基座 bug 或基座局限），与用户讨论是不是架构问题。
 
 ---
 
-## 门 4：闭环门（无证据不许说完）
+## 闭环门（无证据不许说完）
 
 ### 完成铁律
 
@@ -518,19 +565,19 @@ Record   迭代记录 + 任务标记 + 同步
 
 按任务等级选择验证强度：
 
-- 小修：验证改动点命中、无明显报错、对应资源 push 成功。
-- 轻功能：验证真实入口可达、主路径交互有效、关键状态不空白、对应资源 push 成功。
-- 标准功能：验证入口、主流程、关键四态、数据读写 / 回读、关联页面跳转和 push 输出。
+- 小修：验证改动点命中、无明显报错；需要云端生效时再确认对应资源已推送成功。
+- 轻功能：验证入口引用存在、主路径交互有效、关键状态不空白；需要时补 `draftgo check` 或 push 输出。
+- 标准功能：验证入口、主流程、关键四态、数据读写 / 回读、关联页面跳转；按影响选择 `draftgo check`、changelog 和 push 输出。
 - 高风险：在标准功能基础上增加人工确认、回读验证、影响范围说明和回滚 / 兜底方案。
 
 | 资源类型 | 完成证据 |
 |---------|---------|
-| 页面 HTML | 按等级验证：小修看改动点；轻功能看入口 + 主路径 + 关键状态；标准功能 / 高风险再完整覆盖四态、console 和 push 输出 |
-| 新增页面 / 多页面功能 | ① 页面资源创建或更新成功 ② route 与 page_id 对应 ③ 导航栏 / 首页 / 后台菜单 / 相关页面按钮至少一个入口已绑定 ④ 从入口点击到目标页可通 ⑤ 所有关联页面互相跳转可通 ⑥ push 输出 PASS |
-| 导航栏 | ① 浏览器看到新链接 ② 链接含正确 `data-page-route` ③ 点击跳转通 ④ push 输出 PASS |
-| 外部 API 注册 | ① `POST /api/external-apis/{id}/test` 返回 2xx ② push 输出 PASS ③ 页面里 `App.callApi` 能调通 |
-| custom_script | ① `POST /api/scripts/{id}/execute` 真跑一次 ② 返回值符合预期 ③ push 输出 PASS |
-| db_meta / aihub / 系统配置 | ① GET 回读字段对得上 ② push 输出 PASS |
+| 页面 HTML | 按等级验证：小修看改动点；轻功能看入口引用 + 主路径 + 关键状态；标准功能 / 高风险覆盖四态和必要的同步证据 |
+| 新增页面 / 多页面功能 | ① 页面资源创建或更新成功 ② route 与 page_id 对应 ③ 导航栏 / 首页 / 后台菜单 / 相关页面按钮至少一个入口已绑定 ④ 文件回读或 `draftgo check` 可确认入口引用 ⑤ 关联页面互跳关系清楚 ⑥ 若已推送则有 push 输出 |
+| 导航栏 | ① 文件回读确认新链接存在 ② 链接含正确 `data-page-route` ③ 若已推送则有 push 输出 |
+| 外部 API 注册 | ① `POST /api/external-apis/{id}/test` 返回 2xx ② 若已推送则有 push 输出 ③ 页面里 `App.callApi` 能调通 |
+| custom_script | ① `POST /api/scripts/{id}/execute` 真跑一次 ② 返回值符合预期 ③ 若已推送则有 push 输出 |
+| db_meta / aihub / 系统配置 | ① GET 回读字段对得上 ② 若已推送则有 push 输出 |
 | roles / users | ① 用户二次确认 ② push 输出 PASS ③ 影响范围告知用户 |
 | 文档 / 文档分类 | ① push 输出 PASS ② GET 回读字段对得上 |
 
@@ -542,21 +589,35 @@ Record   迭代记录 + 任务标记 + 同步
 入口出现 → 点击进入 → 页面加载 → 操作有效 → 反馈明确 → 数据可回读 → 后台可维护（如需要）→ 前台展示更新
 ```
 
-如果新页面只能靠手动输入 route 访问，且用户正常路径里看不到入口，视为未完成。若任务明确要求“只创建未公开页面”，必须在完成声明中说明该页面暂不绑定导航的原因。
+如果新页面没有任何导航栏、首页模块、后台菜单或相关页面按钮引用，视为未完成。若任务明确要求“只创建未公开页面”，必须在完成声明中说明该页面暂不绑定导航的原因。
+
+### CLI 闭环体检
+
+涉及页面、导航、DB、脚本或 AIHub 的任务，可按影响运行：
+
+```bash
+draftgo check
+```
+
+- 有 `错误`：与本次改动相关时先修复，不得声明完成。
+- 有 `提醒`：结合任务判断。若是未绑定入口、疑似 mock 数据、缺少真实调用，优先补齐；若是用户明确要求隐藏页 / demo，需在 changelog、Task 或完成说明中写明原因。
+- 需要把提醒也作为失败处理时运行 `draftgo check --strict`。
+
+`draftgo check` 只做本地启发式检查；结合文件回读、静态检查、API 回读和必要的 push 输出形成证据。
 
 ### 禁用措辞
 
 - "应该 / 可能 / 看起来 / 大概 / Perfect / Done / 搞定 / 好了 / OK 了"
 - 任何隐含成功但没附证据的句子
 
-### 完成声明必须附
+### 完成声明附证据
 
-- 命令 / 操作名（哪个 push / 哪个 API / 哪个浏览器路径）
+- 命令 / 操作名（哪个文件回读 / 哪个 check / 哪个 push / 哪个 API）
 - 真实输出摘要（HTTP code、关键日志行、计数）
-- 标准功能 / 高风险任务：Task 文档更新到哪些 ✅；小修和轻功能说明无需 Task
+- 有 Task 文档时说明更新到哪些 ✅；无 Task 文档时不需要补说明
 
 **示例（正确）**：
-> T2 完成。`python draftgo_push.py pages 123` 返回 `OK pages/123`，浏览器 `/admin/users` 加载正常，导出按钮点击触发下载，CSV 文件 89 行（与列表 page_size=100 + 11 条过滤匹配）。Task 文档 T2 已 ✅。
+> T2 完成。文件回读确认导出按钮绑定 `handleExport()`；`POST /api/scripts/7/execute` 返回 200，CSV 生成 89 行；已推送时 `python draftgo_push.py pages 123` 返回 `OK pages/123`。Task 文档 T2 已 ✅。
 
 **示例（错误）**：
 > 导出按钮做好了，应该没问题，push 也跑了，你试试看。
@@ -565,61 +626,27 @@ Record   迭代记录 + 任务标记 + 同步
 
 1. 把 Task 文档 frontmatter 的 `status` 改为 `done`
 2. 填写"完成回顾"段（实际改动、偏离计划处、后续 TODO）
-3. 在 changelog.md 写一条总结：`- [HH:MM] [完成] <主题>，详见 Task/<file>.md`
+3. 需要接手记录时在 changelog.md 写一条总结：`- [HH:MM] [完成] <主题>，详见 Task/<file>.md`
 4. 文件原地归档，不要移动
 
 ---
 
-## 前端审美方向（只立方向，不立细则）
-
-不强制设计 token、不强制栅格规格、不强制颜色清单。但给三个方向 + DraftGo 项目内的硬约束。
-
-### 三个方向
-
-| 方向 | 含义 | 锚点 |
-|-----|------|------|
-| **现代工艺** | 当下主流审美：克制留白、精细对齐、轻量阴影、合理动效、高质感字体与间距 | 参考 Linear / Vercel / Apple HIG / Notion；避免低质感套模板、无意义大色块和粗糙过渡 |
-| **艺术风** | 不止"能用"，要有视觉记忆点：节奏感、对比、层次、有调性的克制装饰 | 允许有调性的色彩组合、有质感的字体搭配（已有本地 Inter / Lexend / Plus Jakarta Sans / JetBrains Mono Nerd Font）、几何 / 微插画点缀；允许根据项目气质探索更鲜明的视觉语言 |
-| **用户体验** | 状态完整、操作可逆、反馈即时、信息层级清晰 | **四态必做**：空态 / 加载态 / 错误态 / 成功态。Toast 用 `App.showSuccess / Error / Warning / Info`，确认用 `App.confirm`，禁用 `window.alert` |
-
-### DraftGo 项目内的硬约束（继承 frontend.md）
-
-- 颜色：必须 `var(--dg-*)` token，禁止硬编码 hex / rgb
-- 圆角：默认 `rounded-md`（6px）；如需表达品牌感、卡片层级或营销视觉，可使用更大圆角，但需保持页面内节奏一致
-- 组件类名：`-dg` 结尾（`input-dg / btn-dg-primary / btn-dg-secondary / btn-dg-danger`）
-- 字体：用本地 `/assets/fonts/*.css`
-- 图标：用本地 `/assets/fontawesome/css/all.min.css`
-- 静态资源：禁止境外 CDN
-- 主题：必须适配 light / dark + 三套配色方案
-
-### 给 AI 的自由
-
-在"现代工艺 + 艺术风 + UX"三轴里**自由生长**。但**视觉变动必须可视化**：涉及布局 / 配色 / 风格选择时，主动产出 ASCII mockup 或 HTML 草图给用户看，而不是嘴上描述。
-
-### 唯一红线（敏感场景）
-
-登录 / 支付 / 删除确认 / 错误提示 / 权限拒绝：
-- 禁止抖机灵、禁止网络梗、禁止阴阳怪气
-- 文案保持清晰、中性、礼貌、可操作、低情绪浓度
-
----
-
 ## 与现有规则的关系
 
 | 现有规则 | 本规范如何对接 |
 |---------|---------------|
 | 根 [SKILL.md](../SKILL.md) "开发分级" | 本规范提供小修 / 轻功能 / 标准功能 / 高风险分级与执行依据 |
 | 根 [SKILL.md](../SKILL.md) "命令路由" | 增加触发：开发任务前先进本规范做任务分级 |
-| 根 [SKILL.md](../SKILL.md) "开发禁区" / "App API" / "数据库 Schema" / "API 速查" | 继续生效，执行门第 6 步验证依赖它们 |
-| [frontend.md](./frontend.md) | 继续生效，本规范的"前端审美方向"与它互补 |
+| 根 [SKILL.md](../SKILL.md) "开发禁区" / "App API" / "数据库 Schema" / "API 速查" | 继续生效，执行证据依赖它们 |
+| [frontend.md](./frontend.md) | 继续生效，提供 DraftGo 前端运行时、资源、数据、路由、入口绑定和验证方法 |
 | [debugging-syntax.md](./debugging-syntax.md) | 继续生效，本规范第 3 章"调试方法论"在其之上加方法论 |
-| 迭代记录规范（根 SKILL "迭代记录规范"段） | TDR 循环第 4 步复用 |
+| 迭代记录规范（根 SKILL "迭代记录规范"段） | 按影响选择复用 |
 | 错误日志规范（根 SKILL "错误日志规范"段） | 取证阶段复用 |
 | 经验记录规范（根 SKILL "经验记录规范（lessons）"段） | 第 3 章"3 次修不好停手"写入 `.draftgo/lessons/`，含基座 bug 与基座局限场景 |
-| 同步规范（根 SKILL "自动同步规范"段） | TDR 循环第 5 步复用 |
+| 同步规范（根 SKILL "推送规范"段） | 需要云端生效时复用 |
 
 ---
 
 ## 一句话总结
 
-> **先分级：小修直接定位改完验证推送；轻功能范围复述后直接做；标准功能轻量确认后 Task + TDR；高风险走完整 Story / 计划 / 验证 / 人工确认。审美只立方向，质量靠证据。追问必带推测意图，新增页面必须绑定真实入口。**
+> **先分级：小修直接定位改完给轻量证据；轻功能范围复述后直接做；标准功能轻量确认后用内部短计划执行；高风险走完整 Story / 计划 / 验证 / 人工确认。前端 UI 交给本地 Skills，DraftGo 质量靠真实链路和轻量证据。追问必带推测意图，新增页面必须绑定真实入口。**