agentic-flow-kit 1.8.7 → 2.1.0

package/templates/_agents/commands/build.md

@@ -1,84 +0,0 @@
----
-description: Build 阶段:起 plan + 实现代码 + 自验(确认后才动代码)
-stage: Build
-triggers:
-  - "起个 plan"
-  - "spec 没问题"
-  - "开始写吧"
-  - "动手吧"
-  - "计划可以了"
-delegation:
-  - role: implementer
-    instructions: .agents/roles/implementer.md
-    when: plan 与改动文件清单均已确认,且工作包边界满足角色契约
-    required: false
-    fallback: main
-approval_required: true
-next: .agents/commands/test.md
----
-
-> **装户边界**：本文档中 `src/`、`bin/flow-kit.mjs`、`templates/_agents/`、`modules/hosts/` 为 kit 包源仓视角引用——装户仓（无 `templates/` 包源）对应命令不适用，本仓以 `.agents/` 装副本为准。
-
-# Build · 起 plan + 写代码
-
-> AI 起草 plan,用户确认;进计划模式列改动,用户确认;最后才动代码。两道确认门。
-
-## 0. 三件套合并预览（L2/L3 起草期，2026-10-09 engine-quality-round2 C）
-
-起草 intent / spec / plan 任一件后，**在输出草稿全文前先给三件要点总览**（各一件：目标 / 关键取舍 /
-验收判据 diff，合计 ≤12 行）——用户一次看整体再逐件拍板，省三次盲确认的上下文切换。
-确认纪律不变：逐件过目全文 + 逐件 `confirm-doc` 代录（禁并录；摘要可复用——分辨力由 scope+指纹承担，2026-10-09 起）。本阶段总览侧重：plan 任务拆解与两道确认门位置。
-
-## 1. 执行
-
-### 1.1 起草 plan
-
-1. 确认同名入口文档（approved intent 或已确认的 incident）+ spec（若 L2/L3）均已确认；否则回上一阶段（fill/confirm 未过即拒）。
-2. 起草 plan:
-   - 复制 `workflow/plans/_TEMPLATE.md` → `workflow/plans/YYYY-MM-DD-<主题>.md`(与入口文档同名)
-   - L2/L3 按 4 节填写:改动方案 / 任务拆解(每个任务有判据) / 执行顺序 / 验证计划（与 fill-plan.mjs 单源一致）
-   - L1 使用 Quick-Plan 极简三节:改动方案 / 约束与风险(原 Spec 核心) / 验证计划；多文件多步骤时可补任务拆解/执行顺序
-3. 停下,输出 plan 草稿全文给用户过目,一句"可以"即确认。**逐件确认**:入口文档 / spec / plan 各自的确认点不得并作一次,plan 草稿须全文过目(不接受摘要代替)。**逐件代录**:`--delegated "<授权摘要>"` 每件单独一次——摘要为人类可读留痕,复用同句不削弱判据(分辨力由落账自动记录的改动面 `scope{files,sha256}` 与文档指纹承担,2026-10-09 起)。
-   **确认落态**：唯一入口 `node .agents/scripts/confirm-doc.mjs <path>`（draft→approved / approved→done；TTY 两形态 / 一次一份多份并录被拒 / 台账对质全口径见根 `AGENTS.md` §1.3 确认门）。
-4. 确认后 → plan 状态 draft → approved,并在 plan 内补「确认与复核」节(确认结果 + 日期)。确认环节须在文档留痕:`approved` 是确认的机器可见态,`done` 只在关单出现,禁从 `draft` 直跳 `done`;确认后立即 `docs(workflow)` 单独提交留痕(根 `AGENTS.md` 提交约定;check-loop 检查 14 口径)。
-
-### 1.2 进计划模式列改动
-
-5. **不要直接动代码**。先进「计划模式」:
-   - **先拉同模块历史坑**：按入口文档 `模块:` 跑 `node .agents/scripts/kb-search.mjs --scope workflow --module <token> "<关键词>"`——命中 incident 的根因 / 防复发条目列入改动自查
-   - 列改动文件清单(读后改 vs 新建)
-   - 列步骤(改 X 文件做 Y → 改 Z 文件做 W)
-   - **owned 文件同步**：kit.owned 列表文件（AGENTS.md / workflow 模板等）sync 不动，须列「手动同步装副本」步骤（仅包源/dogfood 双形态仓适用；纯装户仓 owned 即项目自有文件，无此步）
-   - 标注触达红线(对照根 `AGENTS.md` 红线/约束相关节（如「项目适配区」「门禁与提交」）+ 改动域目录级 `AGENTS.md`（如有）)
-6. 停下,等用户确认改动清单。
-
-### 1.3 实现
-
-7. 确认后按 plan 顺序推进;每个任务对照判据自验。若任务满足 `.agents/roles/implementer.md` 的边界,主智能体可将单个工作包连同必读材料、授权文件和验收条件委派给 `implementer`;否则由主智能体执行。
-8. 自验:按改动域跑 `项目构建命令` / `项目类型检查命令` / `项目测试命令`(对应编译 / 前端类型检查 / 自动化测试;静态门全集见 `test.md` §1);范围对账 `node .agents/scripts/check-scope.mjs workflow/plans/YYYY-MM-DD-<主题>.md`——越界件(改了未声明)即收口(回填 plan 或回滚),plan 不可读 exit 2;默认 advisory exit 0,`--strict` 供门禁化调用。
-9. **项目架构红线**:数据访问模式、公共字段写入等以根与目录级 `AGENTS.md`(如有)红线为准,不自创旁路。
-10. **L3 且含 schema 变更时**:schema 变更走项目约定的维护方式(人工 SQL / 迁移工具,以目录级 `AGENTS.md` 或 spec 约束为准),不得擅自引入项目未采用的迁移机制（仅运行时 / 管线类 L3 无此约束）。
-11. 实现中若需偏离已确认的 plan(改公共接口 / 动 plan 未列文件 / 引新依赖 / 影响任务判据)→ 停下,向用户说明原因与影响,确认后再继续。
-
-## 2. 技能辅助(可选,宿主级 skills)
-
-- plan 任务多、依赖复杂时:用 `to-tickets` 拆 tracer-bullet 任务单(每张带阻塞边);结果回填 plan「任务拆解」节,不发布外部 tracker
-- 后端逻辑改动:有测试基建的用 `tdd` 测试先行(红→绿→重构);整体实现纪律可用 `implement` 驱动
-- 遇合并冲突:用 `resolving-merge-conflicts` 按意图逐 hunk 处理
-- 技能不改变两道确认门、红线检查与委派边界
-
-## 3. 红线提示(本阶段高频踩)
-
-- 红线(架构 / 数据 / 安全等)正文与豁免见根与目录级 `AGENTS.md`(如有)——已由 pre-commit 机器门强制的部分以钩子为准，写代码前先过一遍目录级 AGENTS
-
-## 4. 子代理调用约定
-
-- plan 起草、风险判断、改动清单与两道确认门由主智能体负责;仅两道确认后范围明确的工作包可委派 `implementer`,公共接口 / Schema / 依赖 / 安全 / 权限 / 破坏性操作不得委派。
-- 多工作包并行 / 链式推进:编排机制(声明随 plan 草稿一并确认;确认后读 `.agents/workflows/` 按机制文档执行,`steps/` 为项目自定义步骤扩展点);详见 `.agents/workflows/_TEMPLATE.md`。
-- 子智能体返回后,主智能体须检查 diff 与授权文件范围、确认未覆盖既有修改并重跑相关验证;不支持子智能体时 `fallback: main`,验收标准不变。
-
-## 5. 确认后
-
-- plan 状态保持 `approved`，**不在此置 `done`**——实现完成 ≠ 关单；`done` 在 `test.md` §6 验收勾验后经 confirm-doc 置（intent / spec / 修复的同名 plan 亦在 test 一并收口；build 直跳 `done` 会绕过确认门、触发检查 15 指纹对账）
-- commit：L1+ 入口文档 / spec / plan 随代码同一提交（Conventional Commits 中文 feat/fix/refactor/perf）；docs 豁免与 bootstrap 可单独 `docs(*)`
-- 进 `next: .agents/commands/test.md`

package/templates/_agents/commands/deploy.md

@@ -1,66 +0,0 @@
----
-description: Deploy 阶段:prod 上线清单(静态门 + 配对检查 + 回归 + DB + 授权 + 24h 观察；文档关单在 test)
-stage: Deploy
-triggers:
-  - "跑下 release"
-  - "可以上了"
-  - "过一遍 release 清单"
-  - "准备上线"
-approval_required: true
-next: .agents/commands/maintain.md(仅事故时)
----
-
-# Deploy · 上线清单
-
-> 仅 prod。文档关单（验收勾验 / intent done）在 `test.md`，本阶段不重复关单。个人工作流:唯一授权人是用户本人——上线授权 = 用户一句确认 + `release/<日期>` tag 留痕,追溯靠 git,不依赖第二人审批。
-> 环境定位:dev 为开发自测;staging 即人工验证环境(不设独立发布门);prod 上线必须过本清单。
-
-## 1. 静态门(必跑,全过方可继续)
-
-同 `test.md` §1(静态门全集:`项目构建命令` / `项目测试命令` / `项目类型检查命令` 与项目自有门禁;含环境注记与 Windows 取码注记),逐条跑完再继续。
-
-## 2. 文档闭环(必查)
-
-- L2 / L3 变更:入口文档(`workflow/intents/` 或 `workflow/incidents/`) + `workflow/specs/` + `workflow/plans/` 三件同名配对齐全；intent/spec/plan 状态为 done（test 已关单）。若仍为 approved，先回 `test.md` 补关单再上
-- 若属修复:`workflow/incidents/` 同时须满足复盘三件套完整(结构性修复 / 防复发验证 / 规范条目)，状态 closed
-- 新 intent 是否已立:根因属门禁缺位 / 规范未落地 / 系统性问题时强制立(即使修复已完成)
-
-## 3. 回归清单(必过)
-
-- `workflow/regression-checklist.md` 中涉及模块的关键路径条目全过
-- 项目自动化测试用例全过(`项目测试命令`;不得跳过失败用例)
-- 历史同类 incident 的防复发验证条目(清单「防复发验证」节)逐条过
-
-## 4. 数据库(若涉及 schema 变更)
-
-- 迁移 SQL 已按项目约定的 schema 变更流程验证并留档
-- 实体映射与迁移 SQL 已人工核对一致
-- 备份点已记录 + 回滚 SQL 就绪(L3 且含 schema 变更时强制)
-
-## 5. 上线授权(用户本人最后一关)
-
-- 授权人:用户本人(个人工作流,无第二审批人);对话内一句"上"即授权
-- 授权记录:打 `release/<日期>` tag + commit SHA——tag 是「prod 跑的是哪个 commit」的追溯依据,`git log` 可查
-- 发布流水线(可选):若项目 CI/CD 配置了人工审批卡点,按提示在流水线平台自行批准;批准人仍是本人,不构成第二人评审
-- 回滚决策人:用户本人
-- 回滚预案(按 L3 类型分叉):含 schema 变更 → <备份点 + 回滚 SQL 路径>;仅运行时 / 管线(无 schema,如认证管线 / DI 注册 / 中间件) → 回退上一 `release/<日期>` tag + 配置开关回退
-- 回滚 SQL 必须在 dev 演练执行过(没跑过的回滚脚本等于没有);回退版本类预案须确认上一 tag 可复现构建
-
-## 6. 上线后观察(用户观察,Maintain 阶段接手)
-
-- 观察期:上线后 24h;由用户观察错误率 / 延迟 / 关键业务流(无监控时人工看)
-- 异常判据(观察期退出规则):项目口径填 `workflow/regression-checklist.md`——无监控时的最低判据:错误日志 / 异常告警 / 关键业务流失败**任一出现即触发 §5 回滚预案,不等 24h**;无异常满 24h 方可闭环
-- 闭环宣告:用户确认无异常后才算闭环;AI 不得自行宣告
-- 异常回落:超阈值 → 生成 `workflow/incidents/YYYY-MM-DD-<主题>.md`,进 `maintain.md`(止血方案用户拍板,见 maintain.md §0)
-- 事故响应:单用途账号 + 最小权限;不得跨智能体协作推送修复(参考 Anthropic 教训)
-
-## 7. 子代理调用约定
-
-- 上线清单、回滚方案、授权、tag 与事故决策均由主智能体处理,本阶段不委派子智能体;回滚方案(尤其含数据回滚 SQL)涉及数据安全,不得以通用实现子智能体代替主智能体判断与用户确认。
-
-## 8. 确认后
-
-- 打 `release/<日期>` tag（commit SHA 可追溯）
-- 上线 + 用户观察 24h
-- 用户确认无异常 → prod 闭环（文档 done 应已在 test 写好；若漏写在此补勾验收并置 done）
-- 异常 → 进 `next: .agents/commands/maintain.md`

package/templates/_agents/commands/design.md

@@ -1,63 +0,0 @@
----
-description: Design 阶段:起 spec(L2/L3 强制,L1 可省略)
-stage: Design
-triggers:
-  - "起个 spec"
-  - "接着起 spec"
-  - "intent 看过了"
-  - "spec 走一下"
-delegation:
-  - role: independent-reviewer
-    instructions: .agents/roles/independent-reviewer.md
-    when: L3 spec 草稿完成且用户确认前
-    required: true
-    fallback: new-session
-approval_required: true
-next: .agents/commands/build.md
----
-
-# Design · 起 spec
-
-> L2/L3 强制;L1 走快车道(直接跳 `next: build.md` 起草 Quick-Plan)。
-
-## 0. 三件套合并预览（L2/L3 起草期，2026-10-09 engine-quality-round2 C）
-
-起草 intent / spec / plan 任一件后，**在输出草稿全文前先给三件要点总览**（各一件：目标 / 关键取舍 /
-验收判据 diff，合计 ≤12 行）——用户一次看整体再逐件拍板，省三次盲确认的上下文切换。
-确认纪律不变：逐件过目全文 + 逐件 `confirm-doc` 代录（禁并录；摘要可复用——分辨力由 scope+指纹承担，2026-10-09 起）。本阶段总览侧重：spec 方案取舍与 L3 复核安排。
-
-## 1. 执行
-
-1. 确认同名入口文档已批准：新需求为 approved intent，修复为已确认的 incident 草稿；否则拒绝，分别回 `plan.md` / `maintain.md`（2026-09-30 起机器强制：fill-spec / confirm-doc 对前置未过直接拒绝 exit 2、不落盘不记账）。
-2. 级别判断(对照 AGENTS.md 第 3 条;判据单源 = `.agents/scripts/level-criteria.mjs`，**本文件只承载流程映射，不复述判据闭集**):
-   - **L1**（未命中 L2/L3）→ 快车道：省略 spec，直接跳 `next: build.md` 起草 Quick-Plan
-   - **L2**（触达面闭集见单源 `L2_SURFACES`）→ 必须有 spec
-   - **L3**（结构面闭集见单源 `L3_SURFACES`）→ 必须有 spec + **新会话独立复核**
-   - 判哪一档：逐条对照单源的 `L2_SURFACES` / `L3_SURFACES` / `L1_NEGATIVES`，不要凭记忆——判据只读单源一处
-3. 起草 spec:
-   - **填空工具先跑**：`node .agents/scripts/fill-spec.mjs --level <L1|L2|L3> --topic <主题> --output workflow/specs/<date>-<主题>.md`——输出含 frontmatter 5 字段 + 5 节正文（功能行为/数据流/系统改动/约束遵守映射/风险评估）的草稿；AI 据此填实
-   - 复制 `workflow/specs/_TEMPLATE.md` → `workflow/specs/YYYY-MM-DD-<主题>.md`(与入口文档同名)
-   - 按 5 节填写:功能行为 / 数据流 / 系统改动 / 约束遵守映射 / 风险评估
-   - 约束映射必须对照根 `AGENTS.md` 红线与「工程原则」节及约束相关节（如「项目适配区」「门禁与提交」）与改动域目录级 `AGENTS.md`（如有）逐条说明如何满足
-   - 存在多个可行方案时,在 spec 中列出各方案取舍与 AI 建议项,由用户选定后方可确认
-   - **页面/交互入口形态必须用户确认**:spec 须写明入口是「表单（字段清单）」还是「选择器/弹窗」，禁止自行推定交互形态
-4. 起草后停下,输出草稿全文给用户过目。
-5. L3 必须独立复核:宿主支持子智能体时调用 `independent-reviewer`,并要求其读取 `.agents/roles/independent-reviewer.md`;不支持时另开新会话。复核者读 spec + 根 AGENTS.md 与改动域目录级 AGENTS.md 的红线挑漏洞,结论写入 spec「确认与复核」节;复核未过不得确认。
-
-## 2. 技能辅助(可选,宿主级 skills)
-
-- 对话已充分、无需再访谈时:用 `to-spec` 直接综合成 spec 草稿;其"发布到 issue tracker"默认行为一律改为写入 `workflow/specs/` 同名文件,按 `_TEMPLATE.md` 格式
-- L2/L3 模块设计:用 `codebase-design`(深模块/接缝/接口收窄);术语混乱或需记 ADR:用 `domain-modeling`
-- 方案取舍需压力测试:用 `grilling`;技能产出不越过用户确认门,L3 独立复核流程不变
-
-## 3. 委派约定
-
-- spec 起草、方案取舍与用户确认由主智能体负责,不委派;只有 L3 确认前的独立复核委派 `independent-reviewer`(必需输入:入口文档、spec、根 `AGENTS.md` + 改动域目录级 `AGENTS.md`、固定复核目标)。
-- 宿主不支持子智能体时必须 `fallback: new-session`,不得由原主智能体自查冒充独立复核。
-
-## 4. 确认后
-
-- spec 状态 draft → approved
-- **确认落态**：唯一入口 `node .agents/scripts/confirm-doc.mjs <path>`（draft→approved / approved→done；TTY 两形态 / 逐件代录（摘要可复用——分辨力由 scope+指纹承担）/ 台账对质全口径见根 `AGENTS.md` §1.3 确认门）。
-- 立即 `docs(workflow)` 单独提交留痕(根 `AGENTS.md` 提交约定;check-loop 检查 14 口径)
-- 进 `next: .agents/commands/build.md`

package/templates/_agents/commands/gate-checklist.md

@@ -1,91 +0,0 @@
----
-description: 三处口径一致性检查（doctor §检查项 ↔ check-loop §检查项，显式配对登记表 + 断档/未登记告警）
-stage: helper（横向工具，不占 6 阶段）
-triggers:
-  - "三处口径对账"
-  - "改了 doctor 后跑这个"
-  - "改了 check-loop 后跑这个"
-  - "扫一下口径一致性"
-delegation:
-  - role: implementer
-    instructions: .agents/roles/implementer.md
-    when: 用户已确认同步范围（发现断档/未登记后修 doctor / check-loop / 登记表时）
-    required: false
-    fallback: main
-approval_required: true
-next: .agents/commands/build.md（缺点属 build 改 doctor / check-loop 未对账导致的，修复后回 build）
----
-
-> **装户边界**：本文档中 `src/`、`bin/flow-kit.mjs`、`templates/_agents/`、`modules/hosts/` 为 kit 包源仓视角引用——装户仓（无 `templates/` 包源）对应命令不适用，本仓以 `.agents/` 装副本为准。
-
-# Gate-Checklist · 三处口径一致性（显式配对登记表）
-
-> `src/doctor.mjs` § 检查项 ↔ `.agents/scripts/check-loop.sh` § 检查项，按脚本内 **PAIRS 登记表**对照。
-> 任何一处加新检查项，另一处不会自动同步——本工具报「未登记」；检查项被删/改号而登记未跟报「断档」。
-> 只报告不修复（B-b 决策）：缺点暴露给用户拍板，本工具不自动同步；exit 恒 0。
-
-## 1. 何时跑
-
-- 改 `src/doctor.mjs` 加新 § 检查项后（同时须登记 PAIRS）
-- 改 `.agents/scripts/check-loop.sh` 加新 § 检查项后（同时须登记 PAIRS）
-- 怀疑两处口径不一致时
-- 不跑：仅改既有检查项的提示文案（不动 § 项与登记表）
-
-## 2. 登记表纪律（契约）
-
-`templates/_agents/scripts/gate-checklist.mjs` 内 **PAIRS** 是配对单源，三选一登记：
-
-| 形态 | 写法 | 含义 |
-|------|------|------|
-| 直接配对 | `{ doctor: 'N', cl: 'M' }` | 同一检查两处实现 |
-| 声明独有 | `{ doctor: 'N', cl: null }` | doctor 装户体检面，无 check-loop 对应（原 intent 拍板只报告不修复） |
-| 经 §7 覆盖 | `{ doctor: '7', cl: 'M' }` | doctor §7 整体运行 check-loop，#M 自动流入 doctor |
-
-- 加新 § 检查项不登记 → 工具报「未登记」（新检查项没对账——核心信号）
-- 删/改检查项不动登记表 → 工具报「断档」
-- 关键词匹配已退役（2026-09-25 registry 重写：实测 18×14 项只匹配 2、28 条噪声缺点，真漏点不可见）
-
-## 3. 怎么跑
-
-```bash
-node .agents/scripts/gate-checklist.mjs --diff   # 人类可读（默认）
-node .agents/scripts/gate-checklist.mjs --json   # 机器可读
-```
-
-输出四段：总览计数 → 对照表（登记表展开）→ 断档（如有）→ 未登记（如有）；全绿时输出「登记完整」。
-
-### 3.1 输出示例
-
-```
-▶ flow-kit gate-checklist --diff（显式配对登记表）
-  doctor §检查项: 12  |  check-loop §检查项: 14  |  直接配对 2 + 经 §7 覆盖 12 + 声明独有 9
-  对照表（登记表展开）:
-    ✓ §5 占位符残留 ↔ #2 模板字段占位符残留(YYYY-MM-DD / <主题> 等…)（占位符残留）
-    ● §1 Node 版本（声明独有：Node 版本——装户体检独有）
-    ✓ §7 check-loop ↔ #1 入口文档/spec/plan 同名配对(…（经 §7 整体运行覆盖）
-  ✅ 登记完整（0 断档 / 0 未登记）
-```
-
-### 3.2 自验
-
-```bash
-node .agents/scripts/gate-checklist.test.mjs   # 13 场景全过
-npm test                                       # 含 gate-checklist 套件
-```
-
-## 4. 边界（不要做）
-
-- 不要把「登记完整」当作强制门 —— B-b 决策「只报告不修复」：断档/未登记暴露给 follow-up，exit 恒 0
-- 不要改 doctor / check-loop 检查项来消音 —— 登记表才是该改的地方（配对 / 独有 / 经 §7 三选一）
-- 不要扩展到看板告警 —— 看板当前无告警规则（gen-wiki-board.mjs 不做判定），扩展超出范围
-- 不要绕过登记直接改解析正则 —— 解析面只认 doctor `// N.` 节注释与 check-loop `// N.` 项注释（.mjs 头部清单，fallback 旧装户 .sh `# N.`）
-
-## 5. 不在本次同步范围
-
-- `.agents/board/` 看板告警（无告警规则）
-- `wiki/知识沉淀总览.html` 渲染（数据来源是 workflow/INDEX.md 与 wiki 目录，非本工具对照）
-- `flow-kit sync` managed 台账追踪（gate-checklist 不在 managed 范围）
-
-## 6. 相关留痕
-
-- 立法出处：2026-09-25（登记表重写 + 工具首建；父事件 = owned 漂移未对账，催生本工具）——留痕在包源仓 git 历史与 CHANGELOG，装户径不引实例路径

package/templates/_agents/commands/maintain.md

@@ -1,90 +0,0 @@
----
-description: Maintain 阶段:立 incident + 复盘三件套(修复 / 防复发 / 规范条目)
-stage: Maintain
-triggers:
-  - "立个 incident"
-  - "线上出事了"
-  - "记一笔 incident"
-  - "出事了,根因 xxx"
-delegation:
-  - role: implementer
-    instructions: .agents/roles/implementer.md
-    when: 用户已选定止血或结构性修复方案,复现路径与授权文件均明确,且任务满足角色契约
-    required: false
-    fallback: main
-approval_required: true
-next: .agents/commands/plan.md(若复盘需要新 intent)
----
-
-# Maintain · 立 incident + 复盘三件套
-
-> 修复走 incident 流程;incident 在 L1+ 即 **intent 等价物**(check-loop 已认 incident≡intent),不必另造 intent。spec/plan 与 incident 同名即闭环。
-
-> 事故回到 Plan。复盘三件套缺一不可,防复发承诺不留在文档里。
-
-## 1. 执行
-
-> **看板（可选，默认不拉起）**：需要实时看板时手动跑 node .agents/scripts/ensure-board.mjs（跨平台；幂等：探活 / 旧代码自动重启 / 全新启动才弹浏览器；端口 8933 起自动上探，链接以脚本输出为准；不开看板不影响任务流程）。
-
-### 1.1 紧急止血(仍在事故中时)
-
-1. AI 先诊断:读日志 + 代码,给出止血选项(版本回退 / 数据回滚 / 热修 / 降级 / 暂不处理)与各自影响面、耗时
-   - **版本回退**(代码 / 配置,无数据影响):回退到上一 `release/<日期>` tag——运行时 / 管线类事故(认证管线 / DI 注册 / 中间件)的首选,须确认上一 tag 可复现构建
-   - **数据回滚**(库侧):按 `deploy.md` §5 的回滚预案执行——须有备份点、回滚 SQL 已在 dev 演练过;涉及数据安全,不得委派子智能体判断
-2. 止血方案由用户拍板;AI 只执行选定方案,不自行推送修复
-3. 热修代码后仍须补跑 `test.md` 静态门;止血完成再进下面的复盘流程(时间线从本节记起)
-
-### 1.2 起草 incident
-
-1. **先检索同类 incident**：`node .agents/scripts/kb-search.mjs "<关键词>" --scope workflow --type incidents`——命中同类先读其「根因 / 复盘三件套」，本次三件套须引用其防复发条目（review.md P2 对账项）
-2. 复制 `workflow/incidents/_TEMPLATE.md` → `workflow/incidents/YYYY-MM-DD-<主题>.md`（frontmatter 填 `模块:`，词表见 `.agents/workflow-modules.txt`）
-3. 填 4 节:时间线(发现→定位→止血→恢复,带时刻) / 影响面(页面/接口/数据范围) / 根因(一句话+深层原因) / 为什么之前没拦住(门禁/测试/规范各查一遍)
-
-### 1.3 起草复盘三件套(缺一不可)
-
-> 目的:让事故真正回到 Plan,不让「防复发」承诺停留在文档里。
-
-**1. 结构性修复**
-- 修复 commit:<SHA + 改动文件清单>
-- 影响环境:dev / staging / prod(已上线模块若波及 prod,需附影响用户数 / 持续时长 / 是否回滚)
-- 是否需要新 intent(本 incident 即 intent 等价物,check-loop 已认 incident≡intent,spec/plan 与 incident 同名即闭环):
-  - 否 → 理由:<根因属实现 bug、单点修复已完成,incident 已含目标/约束,等同 intent>
-  - 是 → 根因属「门禁缺位 / 规范未落地 / 系统性问题」时强制立 `workflow/intents/YYYY-MM-DD-<主题>.md` 追踪(即使结构性修复已完成)
-
-**2. 防复发验证**(必须落到自动化用例或回归条目,禁止只写「已人工验证」)
-- 自动化用例:项目测试套件 `<文件>`(`<用例名 / 数量>`)
-- 或 verify 步骤:`.agents/commands/test.md` + <具体操作>
-- 或回归清单条目:`workflow/regression-checklist.md` 防复发验证节(追加一行)
-
-**3. 规范条目**(必须有可追溯落点)
-- 落点优先级(取最前者可行即止):`workflow/regression-checklist.md` 回归条目 / `.agents/hooks/` 或 `tests/` 断言(机器门)→ `.agents/skills/`、`.agents/notes/` → `workflow/` 文档 → `.agents/commands/`
-- **根 `AGENTS.md` 不再是落点**;**入册门槛**:已由机器门强制的内容只留一行指针,禁止在常驻面复述;**一进一出**:落点为常驻面时须在本 commit 内删除或下沉一条被取代条目
-- 常驻面体积预算由 pre-commit 硬拦(`node .agents/scripts/rule-budget.mjs --staged`,表 `.agents/rule-budgets.txt`)——超限先删再增
-- 引用:commit <SHA> / 文件:<路径>#L<行>;若无新增条目,理由:<已有条目覆盖,说明条目位置>
-
-### 1.4 起草后停下
-
-输出草稿全文给用户过目;确认后才执行三件套落地。**确认点不合并**：incident 草稿、spec、plan 各自过目确认（plan 的两道门见 `build.md`）；确认后立即留痕（spec/plan 状态 `approved` + 「确认与复核」节，incident 时间线补「用户确认」条目），`done` 只在关单出现。**L2/L3 机器前置**：起草 spec 时 fill-spec / confirm-doc 校验「时间线含『用户确认』留痕」，未过即拒（exit 2）——被拒回本流程补留痕。
-
-### 1.5 确认后落地
-
-1. **开工前先配 plan**：复制 `workflow/plans/_TEMPLATE.md` 建 incident 同名 plan（L1 极简形态填「改动面 + 验证方式」两节即可）——incident≡intent 免掉的是 intent，**plan 不可免**（pre-commit 增量配对门禁与 pre-push check-loop 均按同名硬拦）
-2. 结构性修复:L1 走 `build.md` → `test.md`;L2/L3 先走 `design.md` 再进 `build.md` → `test.md`
-3. 三件套落地:防复发验证按 §1.3②、规范条目按 §1.3③ 落点优先级逐条落
-4. 若选「需要新 intent」→ 进 `next: .agents/commands/plan.md` 立新 intent 追踪
-
-## 2. 技能辅助(可选,宿主级 skills)
-
-- 根因诊断:难复现/跨层问题用 `diagnosing-bugs` 走诊断循环(红→最小化→假设→插桩→修复→回归)
-- 事故定性/分级:参考 `triage` 技能的状态机思路;产出仍落 incident 模板,不引外部 tracker
-- 处置决策需用户离线拍板:用 `to-questionnaire` 生成问卷
-
-## 3. 子代理调用约定
-
-- 事故诊断、止血选项、根因定性、incident 与三件套起草均由主智能体负责,不委派;用户选定止血方案后,仅有明确复现路径、授权文件与验收条件的局部热修可委派 `implementer`(数据 / Schema / 权限 / 安全 / 破坏性操作不得委派)。
-- 常规结构性修复按级别回流(L1 走 `build.md`;L2/L3 走 `design.md`),不在 Maintain 绕过前置门禁;子智能体返回后由主智能体检查 diff 并补跑 `test.md`。
-
-## 4. 确认后
-
-- incident 状态 → fixed(三件套全落地)；防复发用例通过后 → closed——两跳均走确认门 `node .agents/scripts/confirm-doc.mjs <path>`（open→fixed / fixed→closed，无单跳；2026-09-28 起 check-loop 15 对账，AI 不得直改状态；口径见根 `AGENTS.md` §1.3 确认门）
-- 若需新 intent → 进 `next: .agents/commands/plan.md`

package/templates/_agents/commands/new-task.md

@@ -1,110 +0,0 @@
----
-description: AI-Native 闭环总入口:6 阶段指令索引(Plan→Design→Build→Test→Deploy→Maintain)
-stage: entry
-triggers:
-  - "开工"
-  - "发个任务"
-  - "走闭环"
-  - "从头跑"
-approval_required: true
-next: 按阶段路由
----
-
-# New Task · 闭环总入口
-
-> 6 阶段指令索引。AI 读 AGENTS.md 后按阶段路由,不并阶段、不跳阶段。
-
-## 1. 6 阶段指令索引
-
-| 阶段 | 指令 | 触发短语 | 可委派子智能体 | 确认点 |
-|------|------|---------|----------------|--------|
-| **Plan** | [.agents/commands/plan.md](.agents/commands/plan.md) | "起个 intent" / "要做个 <功能>" | 无 | intent 要点确认 |
-| **Design** | [.agents/commands/design.md](.agents/commands/design.md) | "起个 spec" / "intent 看过了" | `independent-reviewer`(L3) | spec 草稿确认(L3 加独立复核) |
-| **Build** | [.agents/commands/build.md](.agents/commands/build.md) | "起个 plan" → "动手吧" | `implementer`(确认后、范围明确时) | plan 确认 + 动手前确认 |
-| **Test** | [.agents/commands/test.md](.agents/commands/test.md) | "改完了" / "跑下 verify" | `ui-verifier`、`independent-reviewer` | 测试全过(L2/L3 独立复核)+ 关单；L1 结束 |
-| **Deploy** | [.agents/commands/deploy.md](.agents/commands/deploy.md) | "可以上了" / "过 release 清单" | 无 | 仅 prod：用户确认 + release tag |
-| **Maintain** | [.agents/commands/maintain.md](.agents/commands/maintain.md) | "线上出事了" / "记一笔 incident" | `implementer`(方案确认后) | 三件套要点确认 |
-| **Review**(横切,不占 6 阶段) | [.agents/commands/review.md](.agents/commands/review.md) | "评审一下" / "过 review 标准" | `independent-reviewer`(L2/L3 必须独立复核) | 问题定性与合入时机确认 |
-
-## 2. 风险定级(第 0 步,先定级再路由)
-
-**第 0 步先取机器面下界(必跑,不是可选提示)**:
-
-```bash
-flow-kit route --files <预计改动面…> --kind require|fix|verify|review|deploy
-```
-
-- **不给 `--files` 就拿不到路径下限**——机器面此时只能按 L1 起步并在降级栏点名,等于白跑;
-  故定级前先把**预计改动面**列出来(不必精确到最终 diff,给到目录/文件前缀即可)。
-- 跑完**再**按 §4 逐条语义判级:机器只给「就高不就低 + 路径下限」,「一处定义、多处消费」仍要你判。
-- **确实跳过**时必须写明理由(入口文档备注或当场告知用户)——判低的后果由两道门兜:
-  起草面 `check-lane-surface` 命中路径下限无合格入口即拦,提交面同门再拦一次。
-  **诚实边界**:机器**无法**发现你没跑 route——定级发生在改动面确定之前,没有可比对的记录面,
-  详见 [ARCHITECTURE §5](../ARCHITECTURE.md) 与 CHANGELOG 1.7.16 B3 条。
-
-动工前按下表定风险级 L1-L3(就高不就低;判据细则见下节「级别判断」,单源 level-criteria.mjs),级别即风险级,决定走哪条泳道——确认放事前,还是审计补事后:
-
-| 泳道 | 级别 | 确认与审计口径 |
-|------|------|---------------|
-| **协作道**(敏捷优先,审计异步补) | L1 实现级 | 一份 plan 即入口(来源 / 目标 / 红线 / 改动 / 验证 / 验收),不另立 intent。独立复核不设同步前置,check-loop 与事后 review 兜底;确认/代录可 `--batch` 批量(仅 L1) |
-| **防御道**(严谨优先,确认同步拦) | L2 规则/契约 / L3 数据与运行时结构 | 同步确认门:spec 确认通过方可起草 plan,plan 确认后方可动手;L3 加新会话独立复核,未确认不放行 |
-
-> **两问定级**（2026-10-13 L0 退役,自源仓收敛系列 1 回灌）:结构面(schema / 迁移 SQL / DI / 认证管线)→ L3;契约或共享口径 → L2;两者都没有 → L1。不要按严重程度从 L1 往上滑。
-> **落位**: L1 写在 plan frontmatter `级别`;L2/L3 写在 intent(intent 另以 `risk_level`=级别双写,`fill-intent.mjs` 自动写入,机器选道用)。
-> **判低拦截**: 入口勾触达红线 → check-loop「红线判低」hard 拦 → 升到 L2/L3 并补同名 spec。
-> **预判留痕**（§25 advisory）: 定级先做结构化预判（有结构化判定工具则对齐本仓判据，无则按两问自判），结果写进入口文档 frontmatter「预判: kind=<kind> level=<L1|L2|L3>」——与实际落位不符 check-loop 出 WARN 留账。kind 词表与对账机理见 `.agents/notes/engine-internals.md`（维护者面）。
->
-> **L2/L3 起草期合并预览**：三件套起草按 [design.md §0](design.md) 一次呈现要点总览（逐件确认代录不变）。
-
-## 3. 路由判断
-
-<!-- route-kinds: require=plan.md | fix=maintain.md | verify=test.md | review=review.md | deploy=deploy.md -->
-<!-- ↑ 本行是 kind→入口指令的**机器单源**：`flow-kit route` 读它得出「该读哪个 md」，不再在包内自带一份映射。
-     增删 kind 或改入口文件名只改这一行（判据单源 level-criteria.mjs 的纪律同源）。 -->
-
-- **自动化驱动（并列入口,可选）**:一句话全程走 [pipeline-run.md](pipeline-run.md)——状态机驱动+工单协议+原话代录,与下述手动路由二选一,同一任务不混用
-- **新需求 / 功能**:从 `plan.md` 进,立 **intent**(`workflow/intents/`)
-- **修复类任务 / 事故**:从 `maintain.md` 进,立 **incident**(`workflow/incidents/`);incident 在 L1+ 即 **intent 等价物**(check-loop 认 incident≡intent),不必另立 intent。先检索同类历史(`node .agents/scripts/kb-search.mjs "<关键词>" --scope workflow --type incidents,plans`),有同类先读其历史三件套;再按级别走:
-  - L1 → 立 incident 后进 `build.md` 起草并确认同名 Quick-Plan → `test.md`
-  - L2/L3 → 立 incident 后进 `design.md` 起草并确认同名 spec,再进 `build.md` 起草并确认同名 plan → `test.md`
-  - 仅当根因属系统性 / 门禁缺位(maintain.md 三件套「是否需要新 intent」选"是")才另立 `workflow/intents/` 同名 intent
-- **改完代码要验证**:直接进 `test.md`（验证通过即关单；L1 到此结束）
-- **合入前评审**:直接进 `review.md`(横切,P0/P1/P2 分级清单 + L2/L3 独立复核)
-- **准备上线**:直接进 `deploy.md`（仅 prod；文档应已在 test 关单）
-
-## 4. 级别判断(AGENTS.md 第 3 条)
-
-> **判据单源 = [`.agents/scripts/level-criteria.mjs`](../scripts/level-criteria.mjs)**,本节**不复述判据**。
-> 要看判据全文,或要机器可判的部分(路径下限 / 就高不就低 / 混档取高),直接:
->
-> ```bash
-> flow-kit route --files <改动文件…>      # 定级 + 下一阶段 + 该读哪个 md
-> ```
->
-> 单源导出:`LEVELS` `LEVEL_MEANING`(档位语义) / `L2_SURFACES`(四类触达面闭集) / `L3_SURFACES`(结构面) /
-> `L1_NEGATIVES`(判低红线) / `SELF_CHECK`(自查句) / `assessLevel` `hintLevelFor` `parseLevelHints` `routeAdvice`。
->
-> 路径下限清单(装户 owned,默认空):`.agents/level-hints.txt`,每行 `L2 <ERE>` / `L3 <ERE>`,登记「哪些路径一碰就至少是此档」。
-
-**本表只承载流程**(「改什么」判据以单源为准,别在本表增删判据):
-
-| 级别 | 单源语义(摘要) | 流程 |
-|------|-----------------|------|
-| L1 | 实现级改动(未命中 L2/L3) | 快车道:液态草稿(.zcode/drafts) → 实现 → 固化(`solidify-task.mjs`)——用户确认后带 `--delegated "<原话>"` 执行;无确认来源只迁移不落账;亦可一份 plan 即入口(不另立 intent) |
-| L2 | 规则 / 契约(一处改、多处依赖) | 入口文档(intent / incident) + spec + plan 三件套 |
-| L3 | 数据与运行时结构(结构面闭集见单源 `L3_SURFACES`) | 同 L2 + spec 新会话独立复核 |
-
-> 混合改动按最高档定级(就高不就低);**L1 是默认档**——判级只回答「是否命中单源 `L2_SURFACES` 或
-> `L3_SURFACES`」,负例(`L1_NEGATIVES`)命中即不得升档;自查句:`SELF_CHECK`。
-> 机器兜得住的只有「就高不就低」与路径下限;「一处定义、多处消费」是**语义**判定,由你按单源逐条判,
-> 漏判由 lane-surface 触达面门在提交面兜。先例:`workflow/specs/`、`workflow/intents/` 下同类历史(kb 检索主题词)。
-
-## 5. intent 豁免(避免小改动也走完整闭环)
-
-- **L1 新需求**:一份 plan 即入口,不另立 intent(不必 spec)
-- **docs 级改动**(AGENTS.md / workflow/ 模板 / .agents/ 脚本与 commands / yaml):豁免 intent,走 Conventional Commits 直接 commit;若同时触及代码,按代码部分级别立 intent
-- **bootstrap 类改动**(引入规则本身):豁免 intent,commit message 显式声明 `bootstrap`
-
-## 6. 闭环兜底
-
-- 门禁清单与判据以 `.githooks/` / `.agents/hooks/` / `check-loop.sh` 头部注释为准(本文件不复述、不写项数);hard-block = 配对断裂 / 回路断档 / 新建 done 未勾验。本地机器门只有本地钩子,禁 `--no-verify`(见根 `AGENTS.md`)。

package/templates/_agents/commands/pipeline-run.md

@@ -1,43 +0,0 @@
----
-description: pipeline-run 自动化驱动入口——单命令驱动六阶段闭环（工单协议+机器门+原话代录）
-stage: entry
-triggers:
-  - "pipeline-run"
-  - "跑执行器"
-  - "全自动跑"
-approval_required: true
-fallback: 主智能体亲自做 AI 槽位（工单由主智能体完成，不依赖子智能体）
-next: 按 run 停机点循环推进至 done
----
-
-# pipeline-run · 全自动闭环执行器入口
-
-> 确定性部分由 `pipeline-run.mjs` 状态机驱动（机器门序列：fill-* → confirm-doc → verify.mjs → git，退出码全记录）；
-> AI 槽位经工单协议交宿主执行；人件门到点即停、原话代录。宿主只按本协议驱动，不自行改状态。
-
-## 1. 驱动协议（宿主 AI 逐条执行）
-
-1. **启动**：`node .agents/scripts/pipeline-run.mjs start "<需求原文>"`（可预判则加 `--hint "kind=… level=… module=…"`）。
-2. **循环读停机点**：每次命令的 stdout 末行是机器标记 `PIPELINE-STOP <type> …`，按 type 分流：
-   - `work-order <runId> <工单id>`——读工单全文（目标/步骤/约束/验收），**按单干活**：
-     - triage：判级回填 `next --triage "kind=… level=… module=… topic=<英文kebab>"`（就高不就低）
-     - draft：起草指定文档；implement/fix：按授权文件实现（**偏离即停**——公共接口/计划外文件/新依赖→停机向用户上报，不自行放行）；review/closeout：按单产出并写入指定位
-     - 干完回跑 `next`（implement/fix 须 `--files "a,b"` 回填改动清单；review-only 汇报后 `--done` 收尾）
-   - `await-confirm <runId> <doc>`——**人件门**：向用户转述「要点」索确认；用户明确放行后
-     `next --delegated "<用户原话>"`（逐字原话，**永不编造、永不复用旧句**；一次一份）
-   - `gate-fail <runId> <stage>`——读 problems 原因，修复后原路重跑（不绕门、不加 `--no-verify`）
-   - `done <runId>`——向用户汇报总结（阶段条/门数/提交链），流程结束
-   - `aborted <runId>`——已显式放弃，汇报放弃态与留档位置
-3. **放弃**：用户明确不做时 `abort --run <id> --to superseded|cancelled --delegated "<原话>"`（approved 文档逐份走 confirm-doc --to）。
-4. **观测**（可选）：`status [--run <id>] [--json]` 全量事件流水；`watch` 终端轮询视图。
-
-## 2. 硬纪律（违反即协议破坏）
-
-- 状态迁移唯一入口是脚本内部的 confirm-doc 调用——宿主**永不直改** workflow 文档 frontmatter 状态。
-- `--delegated` 的原话必须是用户当次对话原话（台账 `confirmations.jsonl` 留痕可对质）。
-- 修复环超限（3 次）时停机交人工，不带病推进；verify 非绿不关单。
-- run 文件（.agents/cache/pipeline-runs/）是脚本亲写的机器事实——宿主只读不写。
-
-## 3. 与 new-task 的关系
-
-本命令是**自动化驱动的并列入口**（单命令走全程）；new-task.md 是手动阶段路由入口。同一套门禁与确认语义，二者只选其一驱动一个任务，不混用。

package/templates/_agents/commands/plan.md

@@ -1,48 +0,0 @@
----
-description: Plan 阶段:立 intent(需求来源 / 目标 / 约束 / 触达红线)
-stage: Plan
-triggers:
-  - "起个 intent"
-  - "立 intent"
-  - "新需求 <主题>"
-  - "要做个 <功能>"
-approval_required: true
-next: L1 → .agents/commands/build.md (起草 Quick-Plan) ；L2/L3 → .agents/commands/design.md
----
-
-# Plan · 立 intent
-
-> AI 起草,用户确认。确认前不进下一阶段。
-
-## 1. 执行
-
-> **看板（可选，默认不拉起）**：需要实时看板时手动跑 node .agents/scripts/ensure-board.mjs（跨平台；幂等：探活 / 旧代码自动重启 / 全新启动才弹浏览器；端口 8933 起自动上探，链接以脚本输出为准；不开看板不影响任务流程）。
-
-1. 若 `workflow/intents/` 已有目标 intent 且状态为 approved → 按级别跳 next（L1 → `build.md`，L2/L3 → `design.md`）。
-2. 否则起草新 intent:
-   - **先检索同类**：`node .agents/scripts/kb-search.mjs "<关键词>" --scope workflow --type intents,specs`——命中同类先读其结论与验收,新 intent 引用（防重复立项 / 重复踩坑）
-   - **填空工具先跑**：`node .agents/scripts/fill-intent.mjs --module <模块> --level <L1|L2|L3> --topic <主题> --output workflow/intents/<date>-<主题>.md --notes "<备注>"`——输出含 frontmatter 6 字段（含 risk_level）+ 9 节（背景与问题/历史教训防复发/目标/非目标/约束/影响面/触达红线/验收标准 8 节正文 + 确认与复核）的草稿；AI 据此填实，模板与节标题机器保证不出错
-   - 复制 `workflow/intents/_TEMPLATE.md` → `workflow/intents/YYYY-MM-DD-<主题>.md`
-   - frontmatter 填 `模块:`（词表见 `.agents/workflow-modules.txt`，新建文档必填，check-loop 会警告）
-   - 按 8 节填写:背景与问题 / 历史教训防复发 / 目标(可验证) / 非目标 / 约束 / 影响面 / 触达红线 / 验收标准（L1 微改动可省非目标/约束两节，不硬填）
-   - 红线勾选对照根 `AGENTS.md` 红线/约束相关节（如「项目适配区」「门禁与提交」）+ 改动域目录级 `AGENTS.md`（如有）;**没触及就全不勾**,不要硬填
-3. 写不出可测试判据 = 还没想清楚 → 反问澄清,不要硬填。
-4. 起草后停下,输出草稿全文给用户过目,一句"可以"即确认。
-   **确认落态**：唯一入口 `node .agents/scripts/confirm-doc.mjs <path>`（draft→approved / approved→done；TTY 两形态 / 逐件代录（摘要可复用——分辨力由 scope+指纹承担）/ 台账对质全口径见根 `AGENTS.md` §1.3 确认门）。
-
-## 2. 技能辅助(可选,宿主级 skills)
-
-- 需求模糊、判据写不出时:用 `grilling`/`grill-me` 拷问需求,答完回填 6 节
-- 需要用户离线拍板的决策:用 `to-questionnaire` 生成问卷,问题清单随 intent 草稿一并列出
-- 讨论中需同时沉淀术语表/ADR:用 `grill-with-docs`,文档落 `workflow/` 下与主题同名
-- 技能只辅助澄清,产出仍按 `_TEMPLATE.md` 落 `workflow/intents/`,确认门不变
-
-## 3. 执行主体
-
-- 需求澄清、级别判断与 intent 起草由主智能体负责,本阶段不委派子智能体。
-
-## 4. 确认后
-
-- intent 状态 draft → approved
-- 立即 `docs(workflow)` 单独提交留痕(根 `AGENTS.md` 提交约定;check-loop 检查 14 口径)——**提交最早可行点**：入口文档受 pre-commit 闭环配对（增量）门约束，同名 spec / plan 须已在工作区（先例 61ec130）
-- L1 → `.agents/commands/build.md`；L2/L3 → `.agents/commands/design.md`