@chenguangyao/devflow-kit 0.1.43

package/skills/df-orchestrator/references/escalation-matrix.md

@@ -0,0 +1,191 @@
+# df-orchestrator / escalation-matrix
+
+sub-skill 报 `BLOCKED` 或 `NEEDS_INPUT` 时,orchestrator 根据本表决定:**回退到哪个 phase、是否要通知用户、重试还是终止**。
+
+---
+
+## 使用姿势
+
+每个 sub-skill 收尾都会输出 `---STATUS---` 块。orchestrator 拿到 status 后:
+
+1. `DONE` / `DONE_WITH_CONCERNS`:按 `workflow-state-machine.md` 正常推进。
+2. `NEEDS_INPUT`:把 sub-skill 附带的问题转给用户,收到答复后把 sub-skill 再次 resume。**不做 phase 转移**。
+3. `BLOCKED`:查本表,按 **blocker 类型** + **当前 phase** 决定去哪。
+
+---
+
+## Blocker 类型速查
+
+sub-skill 在 `---STATUS---` 的 `concerns` / `reason` 字段会带一个 `blockerType`,本表按它索引:
+
+| blockerType | 直译 | 常见 sub-skill |
+| --- | --- | --- |
+| `provider_unreachable` | provider 调不通(401/403/超时) | intake / vcs / ci / notify / kb |
+| `provider_missing` | 目标 provider 未配置 | 同上 |
+| `credential_expired` | 凭据过期 | 同上 |
+| `scope_ambiguous` | 需求范围不清 | requirement-analysis |
+| `design_flawed` | 设计有缺陷(review 报出来的) | code-review → tech-spec |
+| `test_fail` | 自测 / 集成 / e2e 失败 | verify |
+| `review_rounds_exceeded` | code-review 3 轮未过 | code-review |
+| `delta_conflict` | spec 合入失败 | archive |
+| `gate_violation` | 强行跳 phase / 产物缺失 | 任意 |
+| `cred_leaked` | doctor 检测到敏感信息落文本 | verify / deliver |
+| `branch_dirty` | 工作区不干净 / 有未提交改动 | apply / deliver |
+| `pr_rejected` | MR / PR 合入失败(CI 失败 / 冲突) | deliver |
+| `ci_failure` | CI / Jenkins / PR required check 失败 | ci-fix / deliver |
+| `pr_feedback_unresolved` | PR/MR reviewer comment 未解决 | ci-fix / code-review |
+| `dependency_breaking_change` | 依赖升级存在 breaking / peer / lockfile 风险 | dependency-upgrade |
+| `frontend_evidence_missing` | 前端改动缺少浏览器/截图/联调证据 | frontend-quality / verify |
+| `security_risk_unaccepted` | 安全风险未验证或未被 owner 接受 | security-hardening / verify / deliver |
+| `handoff_state_unclear` | 恢复任务时缺少可信下一步 | handoff-resume |
+
+---
+
+## 处置矩阵
+
+### provider_unreachable / credential_expired
+
+| 当前 phase | 处置 |
+| --- | --- |
+| 任意 | 1. `devflow provider rotate <provider>` 走引导 2. 成功后 sub-skill resume;失败且 provider 非关键 → 建议切换到等价 provider(如 kb.weknora → kb.local) |
+
+### provider_missing
+
+| 当前 phase | 处置 |
+| --- | --- |
+| 任意 | 先看 `~/.devflow/providers.example.json` 是否已有公共 endpoint 示例；把需要的条目复制到 `~/.devflow/providers.json` 并把个人账号/token/密码改成 `${env:VAR}`，或执行 `devflow provider add <provider>` / `devflow provider setup`。sub-skill 不 resume,直到 provider 可用 |
+
+### scope_ambiguous
+
+| 当前 phase | 处置 |
+| --- | --- |
+| requirement | 进入 Round 1 或 Round 2 追加 Q;用户回答后 sub-skill resume |
+| design / plan | 回退到 requirement,追加一轮 Q;不要在 design/plan 里猜 |
+| apply | 不合法(在 apply 阶段遇到需求模糊 = 前置没做好),强制回退到 requirement,audit 标"late-scope-clarification" |
+
+### design_flawed
+
+触发点几乎都是 code-review 的 Path B(见 `code-review/references/escalation-playbook.md`)。
+
+| 当前 phase | 处置 |
+| --- | --- |
+| review(round 2+ 仍有同一 MUST 或 `fixMode: SPEC` ≥ 1) | 回退到 `design`,`devflow tech-spec --revise --from review` 产出 design.v2;重新做 plan |
+| verify(发现非功能需求漏设计,比如没考虑性能) | 回退到 design(最小增量 revise) |
+
+### test_fail
+
+| 报告类型 | 处置 |
+| --- | --- |
+| unit fail | 回退到 apply,定位对应 task,修好重跑 `devflow test unit` |
+| integration fail | 先判是不是依赖/环境问题(走 verify skill 的 failure-triage);若是代码问题 → apply |
+| e2e / smoke fail | 同上 |
+| regression fail | 可能要回退到 design(说明改动影响到了未触及的路径) |
+
+### review_rounds_exceeded
+
+| 处置 |
+| --- |
+| 完全走 code-review skill 的 escalation-playbook:`--continue-rounds`(审计) / `--force-pass`(审计) / 回 tech-spec(推荐) 三选一,不要在 orchestrator 层偷偷 override |
+
+### delta_conflict
+
+| 处置 |
+| --- |
+| 1. 不 `--force` 2. 打开冲突的 `delta/*.md`,对齐 heading 或调整 ADDED/MODIFIED 语义 3. 冲突严重(多个 capability 相互依赖)→ 回退到 design 重新切分 delta |
+
+### gate_violation
+
+示例:用户要求 `deliver` 但 `code-review-report.md` 不存在。
+
+| 处置 |
+| --- |
+| **orchestrator 不替用户 bypass**。告诉用户缺哪个产物、怎么补。允许 `--force --reason=...` 走审计,reason 必填 |
+
+### cred_leaked
+
+| 处置 |
+| --- |
+| 1. `devflow doctor --scope cred` 输出泄漏位置 2. 让用户手工擦除或走 `devflow secrets rotate` 3. 擦除不干净 **严禁** deliver;审计 |
+
+### branch_dirty
+
+| 当前 phase | 处置 |
+| --- | --- |
+| apply | 检查是不是别的 task 未提交 → 提示 commit 或 stash |
+| deliver | deliver 要求工作区干净;提示用户 commit / stash / discard |
+
+### pr_rejected
+
+| 原因 | 处置 |
+| --- | --- |
+| CI 失败 | 回 apply 修;不要只看 CI 日志自作主张 |
+| 代码冲突 | 提示 rebase 或回退到 apply 解决冲突 |
+| Reviewer 拒绝 | 按 PR 评审意见拆到下一轮 review 或 apply |
+
+### ci_failure / pr_feedback_unresolved
+
+| 处置 |
+| --- |
+| 触发 `devflow-ci-fix`。必须先读 CI 日志 / reviewer comment,归因为 `code_error` / `env_error` / `flake` / `baseline`;代码问题回 apply,环境问题先修环境或标 blocked,baseline 需要写明不属于当前 diff 的证据。comment 按 MUST / SHOULD / NIT 分类;MUST 未解决不得 deliver |
+
+### dependency_breaking_change
+
+| 处置 |
+| --- |
+| 触发 `devflow-dependency-upgrade`。若是 major/framework/build-tool 升级,建议升级到 L3 或至少 L2;必须同步 manifest + lockfile,检查 changelog/breaking/peer dependency,并在 verify 留兼容性证据和回滚说明 |
+
+### frontend_evidence_missing
+
+| 处置 |
+| --- |
+| 触发 `devflow-frontend-quality`。补 `reports/test-report.md#joint` 或 `#e2e` 的浏览器证据;如果工具或环境不可用,在 `verify.md` 记录跳过原因、人工验证步骤和风险 owner |
+
+### security_risk_unaccepted
+
+| 处置 |
+| --- |
+| 触发 `devflow-security-hardening`。先看风险是设计问题还是实现问题:设计问题回 tech-spec,实现问题回 apply/review。无法消除的风险必须写 owner + reason + mitigation;未接受前不得 deliver |
+
+### handoff_state_unclear
+
+| 处置 |
+| --- |
+| 触发 `devflow-handoff-resume`。以 `state.json`、pending checkpoint、`reports/test-report.md`、`handoff.md` 为可信源恢复下一步。不要凭聊天摘要继续;如果多个 active change 无法判断,先让用户选 slug |
+
+---
+
+## 话术模板(告诉用户当前状况 + 下一步)
+
+orchestrator 接到 BLOCKED 后,给用户的回复应该含这 4 段:
+
+1. **当前 phase 与 blocker 类型**:"当前在 `verify`,blocker: `test_fail (integration)`"
+2. **诊断**:"`reports/test-report.md#integration` 里 TestOrderCreate 失败,原因看起来是 X"
+3. **推荐动作**:"建议回到 apply 修 T-3 再重跑 verify"(或给 2-3 个备选)
+4. **审计留档**:"本次回退会记到 `state.audit[]` 作为 late-rollback 追踪"
+
+---
+
+## 什么时候应该 "终止" 而不是"回退"
+
+极少数情况下,orchestrator 应该直接向用户说"这个任务不该继续":
+
+| 场景 | 建议 |
+| --- | --- |
+| 发现任务是冗余的(已有一个 active change 做同一件事) | 停,合并到那个 slug 去做 |
+| 发现任务违反公司合规 / 安全政策 | 停,建议走合规审批流程 |
+| 发现任务已经被别人完成 / PR 已合 | 停,直接 archive 当前 change 或 discard |
+| 发现需求本身是用户误解(没有这个需要) | 停,取消 change,记 discarded reason |
+
+终止时:
+
+```
+devflow deliver --mode=discard --reason="<详细原因>"
+```
+
+discard 不会进 archive,但会留审计,方便下次排查"是否真的不该做"。
+
+---
+
+## 本文与 SKILL.md 的关系
+
+SKILL.md 只给了 4 种 sub-skill status 的粗分类。每种 blocker 类型对应的具体处置、话术、审计要求在本文。orchestrator 遇到 BLOCKED 时,**必须**按 blockerType 回查本表,不要自主判断跳步。

package/skills/df-orchestrator/references/routing-rules.md

@@ -0,0 +1,290 @@
+# df-orchestrator / routing-rules
+
+用户第一句话的意图识别。本文是 SKILL.md "入口路由"章节的细化:每个入口类型怎么识别、边界情况怎么处理、识别失败时怎么追问。
+
+---
+
+## 识别优先级
+
+遇到一条用户输入,**按下面顺序**匹配,命中即路由,不再往下看:
+
+1. 恢复已有 change(最优先,避免用户重新 new)
+2. 明确的质量修复入口(CI / PR feedback / dependency / security / handoff)
+3. URL(Wiki / Confluence / Notion / 飞书 / 语雀 / GitLab issue page)
+4. Issue ID(JIRA / 内部追踪 ID)
+5. Incident / 告警
+6. 纯自然语言 idea(兜底)
+
+## 1. 恢复已有 change
+
+### 识别信号
+
+- 用户提到某个词或短语恰好匹配某个 `devflow/changes/<slug>/` 目录名
+- 用户说"继续 xxx"、"xxx 那个事"、"接着干 xxx"
+- 项目根存在 `devflow/changes/` 且里面有至少一个 slug
+
+### 动作
+
+```
+devflow status                          # 列出所有 active changes + 各自 phase
+```
+
+让用户选一个具体 slug,然后:
+
+```
+devflow status --slug=<slug>            # 打印 state.json 的 currentPhase / lastUpdated / gates
+```
+
+然后按 `currentPhase` 触发对应 sub-skill:
+
+| state.currentPhase | 触发 skill |
+| --- | --- |
+| `intake` / `brainstorm` | brainstorm |
+| `requirement` | requirement-analysis |
+| `design` | tech-spec(带 `test-spec` 若 `state.level ∈ {L2, L3}`) |
+| `plan` | plan |
+| `apply` | apply |
+| `review` | code-review |
+| `verify` | verify |
+| `deliver` | deliver |
+| `archive` | archive |
+
+### 边界
+
+- 用户说"继续"但没给 slug,且有多个 active change:列 slug + 简短描述,让用户选。
+- `state.json` 损坏或缺字段:跑 `devflow doctor --scope state`,按提示修复后再进入。
+- 如果用户说"接着上次继续"、"从上次做到哪继续",且上下文不完整,先触发 `devflow-handoff-resume`:读取 `state.json`、pending checkpoint、`reports/test-report.md` 和 `handoff.md`(若存在),给出下一步命令,不要重新建 change。
+
+---
+
+## 2. 明确的质量修复入口
+
+这些入口不一定要新建 change。若当前目录已有 active change,优先在当前 change 内接入专项 skill;若没有 active change,再按普通入口创建。
+
+| 用户输入 | 识别信号 | 路由 |
+| --- | --- | --- |
+| "CI 挂了"、"Jenkins 失败"、"PR check failed"、"review comment 修一下" | CI / PR / MR / Jenkins / GitHub Actions / GitLab CI / required check / reviewer comment | 触发 `devflow-ci-fix`;先读日志/评论,归因后回 apply 或 verify |
+| "升级依赖"、"修漏洞"、"更新 package-lock/go.sum/pom.xml" | package manager manifest / lockfile / CVE / Dependabot / Renovate | 触发 `devflow-dependency-upgrade`;按 patch/minor/major 判断 level 和验证 |
+| "前端页面"、"React/Vue/Next/Vite"、"样式/交互/表单/弹窗/轮询页" | UI diff、浏览器路径、前端消费者、redirect/query/returnUrl | 触发 `devflow-frontend-quality`;在 review/verify 增加浏览器证据 |
+| "安全"、"支付"、"鉴权"、"隐私"、"权限"、"回调验签"、"token/cookie/password" | 安全/合规/敏感信息/上传/OSS/SLS | 触发 `devflow-security-hardening`;必要时建议升级 L3 |
+| "继续上次"、"换个 agent 接着做"、"上下文快满" | resume / handoff / context compact / long task | 触发 `devflow-handoff-resume`;先恢复状态再决定 phase |
+
+专项 skill 只增强当前 phase,不绕过 phase gate:
+
+- CI 失败:先 `ci-fix` 归因;代码问题回 `apply`,环境问题标 `env_error`,baseline 问题写风险。
+- 依赖升级:仍要通过 `apply -> review -> verify`;不能只改 lockfile 后 deliver。
+- 前端质量:不能替代单元/集成测试,只补浏览器和 UI 证据。
+- 安全增强:如果发现设计级风险,回 `tech-spec` 而不是在 review 里硬补实现。
+- handoff:恢复出的下一步必须以 `state.json.currentPhase` 和 pending checkpoint 为准。
+
+---
+
+## 3. URL 入口
+
+### 识别信号
+
+正则:
+
+```
+/^https?:\/\/[^\s]+$/                              # 单个 URL
+/(https?:\/\/[^\s]+)/                              # 混在自然语言里的 URL
+```
+
+域名白名单(按项目 provider 配置动态加载):
+
+| 域名模式 | intake provider |
+| --- | --- |
+| `confluence.*` / `*.atlassian.net/wiki/*` | confluence |
+| `*.notion.so` / `notion.so/*` | notion |
+| `*.feishu.cn` / `*.larksuite.com` | feishu |
+| `*.yuque.com` | yuque |
+| `*.qschou.com` / 其他内部 Wiki | 内部 wiki provider(`devflow provider list intake` 查) |
+| GitLab / GitHub issue URL | 按 issue 对待(见第 3 节) |
+
+### 动作
+
+**执行 shell 命令**（不是自己抓 URL）：
+
+```bash
+devflow ingest "<url>" --follow-links --project-root=/path/to/primary,/path/to/dependency
+# 或：用户只给了多项目大目录，允许 CLI 自动推荐时
+devflow ingest "<url>" --follow-links --search-root=/path/to/multi-project-root
+# devflow 内部用已配置的 intake provider 携带认证抓取
+# → devflow/changes/<auto-slug>/refs/source.md
+# 自动生成 slug（基于 primary project git branch + 标题或 URL 末段）
+```
+
+入口处必须先确认项目再创建 change。不要先裸跑 `devflow ingest "<url>"`，再把项目选择推迟到 `requirement`；那会导致 change slug 来不及使用 primary 项目的 git branch。
+
+项目确认顺序：
+
+1. 用户已明确项目路径：直接加 `--project-root`。
+2. 用户给的是多项目根目录：加 `--search-root`，让 CLI 用拉取到的标题/正文自动评分推荐。
+3. 用户没给项目且当前目录明显包含多个服务：先问用户选 primary project，拿到答案后再执行 `devflow ingest`。
+4. 单项目仓或用户明确要求只导入材料：允许省略项目参数，必要时加 `--no-project-routing`。
+
+> ⛔ **禁止** agent 用 curl / fetch / browser 工具访问 URL，也禁止裸跑 `devflow ingest` 后再选项目。
+> 原因：内网 URL 不可达 + 缺 provider token；同时 change slug 必须在创建前拿到 primary project branch。报"需要登录"时唯一正确处理是执行带项目路由参数的 `devflow ingest`。
+
+`ingest` 成功后 state.currentPhase=`intake`，**先做 KB 轻量预检索，再触发 complexity-grading**：
+
+```bash
+# Step A：KB 轻量预检索（只看摘要，秒级完成，结果写到 refs/kb-context.md）
+devflow knowledge query "<从 source.md 提取的核心关键词>" --slug=<slug>
+# 关键词提取策略：取需求标题 + 主要功能词，3-6 个词即可
+# 例：devflow knowledge query "会员权益 升级 订单" --slug=18-健康保障会员升级
+
+# Step B：complexity-grading（可读到 refs/kb-context.md 的命中摘要辅助判级）
+```
+
+> KB 预检索的目的是给 complexity-grading 提供"历史相似功能的复杂度参考"，不是做完整需求分析。
+> 若 KB 不可用（未配置 / 网络不通），静默跳过，直接进 complexity-grading。
+
+### 边界
+
+- **多个 URL**:一个任务可能同时关联 PRD + 设计稿 + 历史 issue。`devflow ingest <url1> --follow-links` 后在 `requirement-analysis` 的 Round 1 追加 `devflow ingest <url2> --slug=<current>` 追加 refs,不要重新 new。`--follow-links` 只抓入口页一层同域/本地链接。
+- **URL 需要登录**:provider 未配好,`devflow ingest` 会提示 `401` / `403`。触发 `devflow provider rotate <intake>` 流程,完成后重试。
+- **URL 指向代码文件**:不是文档,直接 `devflow new <slug>` 走 brainstorm,把 URL 作为 "code reference" 记进 proposal.md。
+- **跨项目 URL**:URL 属于另一个项目的文档库,询问用户是否要在当前 repo 做,还是要跨仓。跨仓的开发应在目标 repo 里 `devflow init` 后再 `devflow ingest`。
+
+---
+
+## 4. Issue ID 入口
+
+### 识别信号
+
+正则 `^[A-Z]{2,10}-\d+$`(匹配 `SCRUM-15803`、`PROJ-123`、`DEVOPS-42`)。
+
+**排除**:长度 ≥ 40 且全为 hex 字符 → git SHA,不是 issue ID。
+
+### 动作
+
+```
+devflow ingest <issue-id>               # intake provider 自动选 JIRA 或内部 issue tracker
+                                   # → devflow/changes/<issue-id-slug>/refs/source.md
+```
+
+slug 生成规则:`<issue-id>-<标题前 6 词 slugified>`,例如 `SCRUM-15803-add-coupon-grant`。
+
+然后进入 `requirement-analysis`。
+
+### 边界
+
+- **Issue 链接而不是 ID**(`https://jira.corp.com/browse/SCRUM-15803`):按 URL 匹配第 2 节,provider 的 URL rewriter 会把它转回 ID 再 ingest。
+- **Issue 被关闭 / 已完成**:`devflow ingest` 仍会把内容拉下来,但 orchestrator 要在 `requirement-analysis` 开头提示"此 issue 已 Closed,请确认要继续而不是新建"。
+- **Issue 无结构化字段(裸 Markdown body)**:照常 ingest,在 `requirement-analysis` 的 Round 1 显式问"是否有验收标准 / 边界场景"。
+
+---
+
+## 5. Incident / 告警入口
+
+### 识别信号
+
+用户输入含有下面关键词之一:`告警 / alert / incident / P0 / P1 / P2 / 故障 / 线上报错`,并带有一个 ID 或 URL(指向告警平台如 Sentry / Datadog / 内部监控)。
+
+### 动作
+
+```
+devflow ingest incident:<id-or-url>     # intake provider: incident-*(Sentry / Datadog / 内部)
+                                   # → devflow/changes/<incident-slug>/refs/incident.md
+                                   # + 自动打标签 level=L1(hot-fix 默认)
+```
+
+进入 `requirement-analysis`,但用 **incident 专项模板**(包含"事故时间线 / 复现步骤 / 根因假设 / 影响面 / 是否要加监控"字段)。
+
+### 边界
+
+- **Incident 复杂度高**:根因涉及架构问题 → `requirement-analysis` 在 Round 2 提示"建议升级为 L3",要求用户确认。
+- **Hot-fix 压力大**:用户明确要 skip 流程,orchestrator 只能允许"L1 + 必须事后补 postmortem",不允许整条流程 bypass。postmortem 模板见 `archive/references/postmortem-template.md`。
+
+---
+
+## 6. 纯自然语言 idea(兜底)
+
+### 识别信号
+
+前面 4 条都没匹配,输入是中文/英文自然语言描述一个想法 / 功能 / 问题。
+
+### 动作
+
+1. 从用户输入里抽 **3-4 个关键词** 作 slug 候选,并展示给用户确认:
+
+   > "我把这个事起名 `add-coupon-batch-grant`,行不行?"
+
+2. 确认后:
+
+```
+devflow new <slug>                      # 创建 devflow/changes/<slug>/proposal.md 骨架
+                                   # state.currentPhase=brainstorm
+```
+
+3. 触发 `brainstorm` skill。
+
+### 边界
+
+- **用户同时给 URL + 自然语言描述**:URL 优先,`devflow ingest <url>` 把自然语言描述记进 `refs/user-hint.md`。
+- **用户描述模糊到无法起 slug**(如"我有个想法"):触发 brainstorm 的"拆问题"流程,不要强行生成 slug。
+- **用户描述就是抱怨**(如"这破东西又崩了"):不建 change,引导用户提供:具体症状 / 复现路径 / 错误截图 /日志,走 incident 路径。
+
+---
+
+## 7. `df` / `/df:*` 命令
+
+### 识别信号
+
+用户输入以 `df ` 或 `/df:` 开头。
+
+### 动作
+
+**本 skill 不拦截**,命令直接执行。只在下面情况介入:
+
+- 命令 exit code ≠ 0 → 读 stderr,按 `escalation-matrix.md` 诊断
+- 命令输出 `ASK`(带结构化问题给用户)→ 把问题转给用户,收到回答后继续
+- 命令输出 `BLOCKED` → 回退,不继续
+
+---
+
+## 8. 非 devflow 任务(必须识别并跳出)
+
+下面这些**不进入 devflow 流程**,按普通对话处理:
+
+| 用户意图 | 特征 | 处理 |
+| --- | --- | --- |
+| 问概念 / 问文档 | "什么是 X?" "这个库怎么用?" | 直接回答,不建 change |
+| 评估他人 PR / 他人代码 | "帮我看看这个 PR" + 贴链接 | 阅读 + 点评,不建 change;如需正式 CR → 让用户在 PR 仓里跑 `devflow review` |
+| 环境 / 工具问题 | "我的 `devflow doctor` 报错" | `devflow doctor` + 诊断,不建 change |
+| 求助于别的 skill | "帮我做 XXX 调研" | 不归 devflow 管 |
+
+**关键**:若强行把非开发任务塞进 devflow,会产生"一次性 change"污染 archive,且对用户无帮助。
+
+---
+
+## 9. 识别失败 / 歧义
+
+### 处理原则
+
+当识别不到明确入口(如用户输入 3 个 URL + 1 个 idea + 1 个 issue ID),**不要猜**,直接问:
+
+```
+检测到多种可能入口:
+  (1) PRD Wiki: <url-1>
+  (2) 设计稿:  <url-2>
+  (3) 历史 issue: <issue-id>
+  (4) 你描述的新功能
+
+请告诉我这次要做的主任务是基于哪一个?其余的可以作为补充 refs。
+```
+
+### 歧义的常见例子
+
+| 用户输入 | 歧义 | 追问 |
+| --- | --- | --- |
+| 只给一个 slug 名,没提事的内容 | 是要恢复还是要新建? | `devflow status <slug>` 检查存在性,反馈后再问 |
+| 一段长描述包含 URL + idea | URL 是参考还是主输入? | "这个 URL 是需求来源(走 ingest),还是参考资料(走 brainstorm 收)?" |
+| 复制了一段错误日志 | 是要 debug 还是要走 incident 流? | 如果有告警 ID → incident;如果是开发期报错 → 普通对话(非 devflow) |
+
+---
+
+## 9. 本文与 SKILL.md 的关系
+
+SKILL.md 只列了入口表和硬规则。细节边界、识别失败的 fallback、歧义解决套路**全在这里**。reviewer / agent 在遇到"不知道怎么路由"的具体场景时,回这里查对应节。