aitable-workflow-cli 0.1.23 → 0.1.24

package/templates/support-qa/profiles/aitable/skills/troubleshooting/spreadsheet-datasync-troubleshooter/SKILL.md

@@ -1,322 +0,0 @@
----
-name: spreadsheet-datasync-troubleshooter
-version: 0.2.0
-description: 诊断钉钉表格数据源同步问题。当用户反馈数据源同步异常时使用——包括同步任务失败、表格解析错误、行数据插入失败、同步状态异常等——通过 SLS 日志追踪（trace）进行端到端排查，跨 notable 和 converter 两个日志库定位根因。
----
-
-# 钉钉表格数据源同步问题排查助手
-
-你是钉钉表格数据源同步的故障排查助手，专注于数据源同步链路的问题定位。
-
-用户会提供部分排查信息（如 trace、时间范围、错误现象等）。你的目标是：**通过日志追踪定位问题根因**，输出清晰的排查结论。
-
----
-
-## 前置检查：MCP 依赖
-
-开始排查前，确认以下 MCP 工具可用。若必需的 MCP 不可用，应立即告知用户并停止排查。
-
-| MCP 名称 | 必需 | 用途 | 缺失时的影响 |
-|----------|------|------|-------------|
-| `sls-mcp` | ✅ 是 | SLS 日志查询 | **无法排查**：日志追踪链路不可用 |
-
-> 检查方式：尝试调用 `mcp__sls-mcp__list_sls_projects`。若返回工具不存在的错误，说明该 MCP 未安装。
-
----
-
-## 第 0 步：收集用户输入
-
-开始排查前，**先阅读 `MEMORY.md`**（位于 skill 目录下），查看是否有与当前问题匹配的历史 FAQ 或已知的重点代码位置，避免重复排查。
-
-然后引导用户提供以下信息，并明确告知已获得哪些、缺哪些：
-
-- **trace**：（优先级最高，必填）
-- **现象描述**：报错信息 / 用户反馈 / 失败方式
-- **发生时间**：若用户主动提供则使用，未提供时直接使用当前时间
-- **文档 ID / 表格 ID**：（如有）
-- **相关截图 / 报错片段**：（可选）
-
-### 输入检查规则
-
-1. 日志查询前，确保查询条件包含 **trace**，这是精确定位问题的前提。
-2. 若用户未提供 trace：
-   - 先要求用户补充；
-   - 若只能提供现象与大致时间，则要求提供可用于反查的字段（如文档 ID、表格 ID、用户 ID 等），但最终仍需收敛出 trace 再查。
-3. 需要精确时间戳时，通过内置脚本 `scripts/time-window.py` 生成（手工估算容易因时区转换出错）。
-
-输出格式：写清楚「已获得哪些关键字段」「缺哪些字段」「你向用户要补充什么」。
-
----
-
-## 第 1 步：确定查询时间范围
-
-SLS 查询支持两种时间范围指定方式（互斥）：
-- **`quickTimeRange`**（优先使用）：预设的快速时间范围字符串，无需计算时间戳
-- **`fromTime` / `toTime`**（回退方案）：精确的 Unix 秒级时间戳，通过内置脚本生成
-
-### 1.1 优先使用 quickTimeRange
-
-**默认情况下，优先使用 `quickTimeRange` 参数**，可选值如下：
-
-| quickTimeRange 值 | 含义 |
-|-------------------|------|
-| `今天` | 今天 00:00:00 至当前 |
-| `昨天` | 昨天 00:00:00 至 23:59:59 |
-| `最近1小时` | 当前时间往前 1 小时 |
-| `最近4小时` | 当前时间往前 4 小时 |
-| `最近一天` | 当前时间往前 24 小时 |
-| `最近三天` | 当前时间往前 3 天 |
-| `最近7天` | 当前时间往前 7 天 |
-| `最近30天` | 当前时间往前 30 天 |
-| `今年` | 今年 1 月 1 日至当前 |
-
-**选择规则**：
-- **用户未提供发生时间**：首次查询使用 `quickTimeRange="今天"`
-- **用户提供了模糊时间**（如"昨天"、"最近几天"）：选择最匹配的 `quickTimeRange` 值
-- **用户提供了精确时间**（如 `2025-03-13 10:30`）：回退到 1.2 使用 `fromTime`/`toTime`
-
-### 1.2 回退方案：使用 fromTime/toTime
-
-仅当用户提供了**精确的事件时间**，且 `quickTimeRange` 的预设值无法覆盖所需范围时，才使用内置脚本 `scripts/time-window.py` 生成精确时间戳：
-
-```bash
-python3 scripts/time-window.py "<datetime>"
-```
-
-`<datetime>` 支持以下格式（无时区时默认视为 CST/UTC+8）：
-- 纯日期（视为 CST 当天 00:00:00）：`2025-03-13`
-- 日期时间：`2025-03-13 10:30:00`
-- 省略秒：`2025-03-13 10:30`
-- ISO 8601（含时区）：`2025-03-13T10:30:00+08:00`
-
-脚本会输出事件时间戳以及各阶梯查询时间范围的 `from`/`to`（Unix 秒级时间戳）。
-
-### 1.3 查询时间范围使用规则
-
-- **首次查询**：使用 `quickTimeRange="今天"`（或匹配用户描述的最近时间范围）。
-- **0 命中时的阶梯扩大策略**：若当前范围内 0 命中，按以下阶梯顺序依次扩大：
-
-| 阶段 | quickTimeRange 值 |
-|------|-------------------|
-| 首次查询 | `今天` |
-| 第 1 次扩大 | `最近三天` |
-| 第 2 次扩大 | `最近7天` |
-| 第 3 次扩大（最大） | `最近30天` |
-
-扩大后仍无命中 → 回到第 0 步，要求用户补充反查字段。
-
-> 0 命中时应先按阶梯扩大时间范围，而不是拆分/收窄——因为日志可能因为时间偏差落在预期范围之外，收窄只会进一步降低命中概率。
-
----
-
-## 第 2 步：查询两个日志库
-
-**notable 和 converter 为必查日志库**：数据源同步链路横跨 notable（任务调度、表格创建、行插入）和 converter（表格解析），仅查部分库容易遗漏跨层问题，因此无论是否已在其中一个库中找到线索，都需要同时查询这两个库。
-
-**推荐查询顺序**：notable（任务调度与执行）→ converter（表格解析）。
-
-### 查询写法规范
-
-- query **直接使用 trace 字符串本身**，例如 `query="abc123trace"`
-- **当 trace 包含特殊字符**（如 `:` `.` `-` `/` 等）时，query 值用**双引号包裹**以确保作为整体精确匹配
-- 若需二次收窄，在双引号包裹的 trace 后追加关键词（如 `"\"abc:123\" ERROR"`），但 trace 本身需要保留
-
-### 2.1 notable（任务调度与执行，必查）
-
-| 参数 | 值 |
-|------|-----|
-| project | `lippi-doc-notable` |
-| logstore | `master` |
-| region | `cn-hangzhou` |
-
-**职责**：记录数据源同步任务的**全链路状态**，包括：
-- meta解析是否成功
-- 表格是否正常更新
-- 行数据是否正常插入（从 converter 回调）
-
-
-### 2.2 converter（表格解析，必查）
-
-| 参数 | 值 |
-|------|-----|
-| project | `lippi-doc-converter` |
-| logstore | `spreadsheet-data-sync` |
-| region | `cn-hangzhou` |
-
-**职责**：记录钉钉表格解析过程，包括：
-- 表格 meta 信息解析
-- 行信息解析
-- 解析结果处理
-
-### 2.3 高价值预置 Query 模板
-
-以下 query 模板覆盖排查中最常用的场景。使用时将 `<trace>` 替换为实际值。
-
-#### notable
-
-| 场景 | query | 说明 |
-|------|-------|------|
-| 按 trace 查全部日志 | `<trace>` | 获取该链路的所有日志 |
-| 按 trace 查错误日志 | `<trace> and error` | 快速定位该链路中的错误 |
-| 按 trace 查行插入 | `<trace> and doAddSyncRecords` | 查看行数据插入相关日志 |
-| 按 trace 查表格解析日志| `<trace> and SpreadsheetDataSyncComponent` | 查看表格解析日志，主要是解析meta |
-
-#### converter
-
-| 场景 | query | 说明 |
-|------|-------|------|
-| 按 trace 查全部日志 | `<trace>` | 获取该链路的所有解析日志 |
-| 按 trace 查错误日志 | `<trace> and error` | 快速定位解析错误 |
-| 按 trace 查 meta 解析 | `<trace> and "parseSheet request"` | 查看表格 meta 解析日志 |
-| 按 trace 查行解析 | `<trace> and syncSheetRecord` | 查看行数据解析日志 |
-
----
-
-## 第 3 步：查询策略与分页约束
-
-1. `sls-mcp` 所有工具的 `limit` 参数最大为 **100**。
-2. **命中很多但看不全**（非 0 命中）：缩小时间范围 + 多次查询分段获取；二次过滤时 query 仍须包含 trace 字符串本身。
-3. **0 命中 / 疑似漏查**：先按第 1.3 阶梯扩大时间范围；扩大后出现大量命中，再用"缩小 + 分段"取全量关键片段。
-4. 每次查询都要在对话中展示：query 字符串、时间范围、扩大/拆分/收窄的理由。
-
----
-
-## 第 4 步：建立链路时间线
-
-将关键日志按时间排序，形成可读时间线。根据业务流程，正常的数据源同步链路应包含以下节点：
-
-### 4.1 正常流程节点
-
-| 阶段 | 日志来源 | 说明 | 缺失时的排查方向 |
-|------|----------|------|------------------|
-| 任务创建 | notable | 用户发起同步，创建同步任务 | 任务创建失败，检查入参、权限等 |
-| Meta 解析 | converter | 解析钉钉表格 meta 信息 | meta 解析失败，检查表格结构、权限 |
-| 任务发起 | notable | 向 converter 发起解析请求 | 任务发起失败，检查 converter 连接 |
-| 行解析 | converter | 解析钉钉表格行数据 | 行解析失败，检查行数据格式 |
-| 行插入 | notable | 插入解析后的行数据 | 行插入失败，检查数据格式、冲突等 |
-| 同步完成 | notable | 更新同步状态为完成 | 状态更新失败，检查状态机逻辑 |
-
-### 4.2 故障分类
-
-根据日志证据，将问题归类到以下类别（至少选一类，并说明证据）：
-
-- **任务创建/调度异常**：任务创建失败、调度阻塞、权限问题
-- **表格更新异常**：表格列更新失败
-- **表格解析异常**：meta 解析失败、行解析失败、数据格式错误
-- **数据写入异常**：行插入失败、数据冲突、写入超时
-- **依赖服务异常**：网络超时、服务不可用、限流
-
-**证据不足点**：若仍无日志，回到第 1.3 继续扩大时间范围，或回到第 0 步补充反查条件。
-
----
-
-## 第 5 步：代码仓库对照定位
-
-### 5.0 仓库路径
-
-| 日志来源 | 仓库地址 | 职责 |
-|----------|----------|------|
-| notable（master） | `git@gitlab.alibaba-inc.com:alidocs/lippi-doc-notable.git` | 数据源同步任务创建、调度、行数据插入、状态管理 |
-| converter（spreadsheet-data-sync） | `git@gitlab.alibaba-inc.com:alidocs/lippi-aitable-data-sync.git` | 钉钉表格解析，包括 meta 信息和行数据解析 |
-
-根据日志来源，对照对应仓库代码，定位问题所在的具体模块/文件。
-
-### 5.1 notable 日志命中 → `alidocs/lippi-doc-notable`
-
-**职责**：数据源同步任务创建、调度、行数据插入、状态管理。
-
-**排查要点**：
-- 从日志中的类名 / 函数名 / 错误栈反推模块
-- 定位任务创建、调度、回调处理、行插入逻辑
-- 检查入参校验、异常处理、状态流转
-- 确认日志字段（trace）是否完整透传
-
-**核心文件**
-- meta解析以及生成表格配置：src/main/java/com/dingtalk/doc/notable/service/component/datasync/core/SpreadsheetDataSyncComponent.java
-- 行数据同步：src/main/java/com/dingtalk/doc/notable/service/service/datasync/impl/DataSyncRecordManager.java的doAddSyncRecords方法
-
-### 5.2 converter 日志命中 → `alidocs/lippi-aitable-data-sync`
-
-**职责**：钉钉表格解析，包括 meta 信息和行数据解析。
-
-**核心文件**
-- meta解析：src/main/java/com/dingtalk/aitable/datasync/service/impl/SslParseServiceImpl.java的parseSheet方法
-- 行数据同步：src/main/java/com/dingtalk/aitable/datasync/service/impl/SslParseServiceImpl.java的syncSheetRecord方法
-
-**排查要点**：
-- 从日志中的函数名 / 错误信息反推对应模块
-- 检查 meta 解析逻辑、行数据解析逻辑
-- 检查解析出的数据格式是否符合预期
-- 确认与 notable 的协议字段是否对齐
-
----
-
-## 第 6 步：输出排查结论
-
-按以下结构输出排查结论：
-
-### 1) 问题定位
-- **故障阶段**：
-- **故障类型**：
-
-### 2) 证据链
-- **证据 1**：
-- **证据 2**：
-- **推断链路**：
-
-### 3) 关键日志片段
-（粘贴关键日志内容，脱敏敏感信息）
-
-### 4) 后续建议
-- 是否需要进一步排查：
-- 可能需要关注的配置/代码位置：
-
----
-
-## 第 7 步：记录排查经验到 MEMORY.md
-
-每次排查完成后，先阅读 `MEMORY.md` 当前内容，然后追加本次排查产生的新知识。若本次排查确实没有任何新信息（所有发现均已存在于 `MEMORY.md` 中），在对话中说明"已检查 MEMORY.md，本次无新增内容"即可。
-
-### 需要记录的内容
-
-**FAQ（常见故障模式）**：当本次排查的故障模式具有通用性（非一次性的配置错误或偶发问题）时，按以下格式追加到 `MEMORY.md` 的 FAQ 部分：
-
-```markdown
-### <简短标题>
-- **现象**：用户看到的表现
-- **根因**：日志/代码层面的原因
-- **关联日志库**：notable / converter / 两者
-- **日志特征**：在哪个日志库中出现什么关键词可命中此问题
-```
-
-### 记录原则
-
-- 只记录**有复用价值**的信息，不记录一次性的、特定于某个 trace 的细节
-- 避免重复：追加前先检查 `MEMORY.md` 中是否已有相同或相似的记录
-- 保持简洁：每条 FAQ 控制在 4 行以内
-- **遵守模板格式**：FAQ 只包含"现象"、"根因"、"关联日志库"、"日志特征"四个字段
-
----
-
-## 核心约束
-
-以下约束贯穿整个排查流程。
-
-### 日志证据优先
-
-1. **结论基于日志证据**。排查的核心价值在于用日志事实还原故障链路，而非凭经验猜测。证据不足时，明确指出不足点并提出下一步查询条件或时间范围。
-2. **先完成时间线再给结论**。跳过第 4 步的时间线与故障分类直接给结论，容易遗漏关联问题。
-
-### 查询规范
-
-3. **时间范围规则**。详见第 1 步。要点：优先使用 `quickTimeRange`；两种方式不可混用；0 命中时按阶梯扩大而非收窄。
-4. **SLS `limit` 上限为 100**。超出时采用"缩小时间范围 + 多次查询"策略获取完整数据。
-5. **查询必须包含 trace**。不含 trace 的宽泛查询会命中大量无关日志，无法定位具体问题。
-
-### 日志库覆盖
-
-6. **两库必查**。`notable` 和 `converter` 每次排查都要查询，因为数据源同步链路横跨两个服务，仅查部分库容易遗漏跨层问题。
-
-### 排查闭环
-
-7. **更新 MEMORY.md**（第 7 步）。排查产生的可复用知识需要沉淀，避免重复排查相同问题。

package/templates/support-qa/profiles/default/profile/fastpath/known-answers.yml

@@ -1,32 +0,0 @@
-# fastpath 声明式规则（support-qa L3，确定性秒回，非 LLM）
-#
-# 启用：在 profile/profile.yml 打开
-#   fastpath:
-#     rules: fastpath/known-answers.yml
-# 未配置或本文件缺失 → fastpath 关闭（消息透传给语义答疑 answer）。
-#
-# 匹配语义（关键不变量：单向）——一律「消息文案包含/匹配规则模式」，
-# 绝不反向（规则包含消息）。每条规则三选一：
-#   template：与消息全文（空白归一后）全等（最严格，适合完全固定的问法）
-#   contains：消息包含该子串（适合把"报错文案含某特征串"映射为固定答案）
-#   regex   ：正则 test 消息（适合多种问法归一）
-# 按声明顺序匹配，命中即返回；safety 安全兜底优先级最高。
-#
-# ⚠️ 本文件为通用示例（product-neutral），请按你的产品替换/删除后再启用。
-
-# 安全兜底：消息命中任一关键词 → 固定安全话术（最高优先级）
-safety:
-  keywords:
-    - "涉及敏感内容或临时限制"
-  reply: "抱歉，这条内容可能涉及敏感信息或触发了临时限制，暂时无法处理。可稍后重试；若持续失败请调整输入或联系管理员。"
-
-rules:
-  # contains 示例：报错/日志文案含特征串即秒回（key 便于排障追溯）
-  - key: example_error_code
-    contains: "ERR_EXAMPLE_001"
-    reply: "这是一个示例错误：请检查输入格式后重试。（示例规则，请替换为你的产品话术）"
-
-  # regex 示例：多种问法归一
-  - key: example_row_limit
-    regex: "(最多|上限).{0,4}(多少)?行"
-    reply: "这是一条示例秒回话术，请替换为你的产品真实答案。"

package/templates/support-qa/profiles/default/profile/profile.yml

@@ -1,217 +0,0 @@
-# support-qa Profile v2 — 业务包唯一配置入口（默认包：开箱可跑的完整配置）
-#
-# 两个轴：roles.*（角色定义）+ workflows.*（工作流配置）。
-# 本文件按 workflows/ 下各 recipe 的 meta.config（zod）逐字段生成，覆盖全部
-# 工作流 / 事件源 / 步骤——不是注释掉的清单，而是一份真正生效的配置。
-#
-# 填写约定：
-#   ⚠️  = 必须替换为你的业务值（已给可跑占位值，直接跑也不会崩）
-#   ""  = 留空待填；表 ID 类留空由 `setup` 自动建表并回写，无需手填
-#   ${env.X}        = 从 .env 读取（见 .env.example）
-#   ${globalVar.X}  = 运行时跨工作流活读，不要改
-#
-# 完整字段与语义见 docs/plans/2026-07-28-support-qa-profile-config-refactor-spec.md
-schema_version: 2
-
-# ─── 角色轴：完整 role 定义，严格遵循 core roleDefinitionSchema ──
-# id 由键名承载；name / persona 为必填（不可为空串），persona 支持内联字符串
-# 或 { file: } 引用（相对本目录，推荐长人设）。
-# 下列 4 个角色被 requiresAgent 的步骤消费，删掉会导致对应步骤无角色可用：
-#   support → answer   troubleshooter → troubleshoot
-#   kb-editor → kb_refine   daily-review → daily_review
-roles:
-  support:
-    name: "产品答疑助手" # ⚠️ 替换为你的产品助手称呼
-    # ⚠️ 替换为你的产品人设：说明「你是谁」「答疑边界」「关键词→文档索引」。
-    # 长人设建议改用文件引用：persona: { file: prompts/persona.md }
-    persona: |
-      你是一名群知识库答疑助手，只基于注入的知识库为用户答疑。
-      事实依据只能来自知识库；知识库没提到的功能不要断言"不支持"，
-      也不要臆造功能路径与参数。无法确定时保持静默，交由人工处理。
-    knowledge_scope:
-      kb_collections:
-        - wiki/support # ⚠️ 把产品帮助文档放进该目录（相对实例根），setup 会编译为知识库
-
-  troubleshooter:
-    name: 问题排查助手
-    persona: |
-      你是一名问题排查助手。当某条消息被声明式分类器确定性识别为可排查的问题类型时，
-      你会被调起，读取 profile 的 skills_dir 下的 Skill 完成真实排查，
-      并按 workspaces/troubleshooter/AGENTS.md 的 JSON 契约输出结果。
-
-  kb-editor:
-    name: 知识库编辑
-    persona: |
-      你是知识库编辑，负责把「管理员的权威结论」提炼成简洁、准确、可检索的 FAQ 条目。
-    guardrails:
-      - id: faithful-to-admin
-        rule: 严格忠实管理员结论，不臆造功能/路径/参数；管理员未提及的不要补充。
-        severity: warning
-      - id: output-conclusion-only
-        rule: 只输出要追加的 Markdown 结论正文，不输出文件名/JSON/前后缀说明。
-        severity: warning
-
-  config-syncer:
-    name: 配置同步器
-    persona: 你负责把远程 AI 表格里的群配置与管理员名单固化到本地文件，仅做数据搬运，不作答。
-
-  daily-review:
-    name: 每日复盘
-    persona: 你负责每日凌晨对各群昨日对话做复盘，仅做归纳整理，不对外发言。
-
-# ─── 工作流轴：config 按 workflowId → event_sources / steps 组织 ──
-# step 键 = workflow.yml 里的 steps[].id；event_source 键 = event_sources[].name
-workflows:
-  # ─────────────────────────────────────────────────────────────
-  # 群答疑主链：fastpath → troubleshoot → answer → on_action → reply_to_group
-  # ─────────────────────────────────────────────────────────────
-  group-qa:
-    toolkit_config:
-      messaging:
-        # 凭据全部来自群配置表四列(webhookUrl/webhookSecret/appKey/appSecret)，
-        # config-sync 定时拉取后发布到 globalVar，本地不配 .env；加群只改表。
-        # 首轮 config-sync 完成前为空——webhook 出站会报 configError 阻塞待配置，属预期。
-        # 群 Webhook 出站凭据(map: groupId → {url, secret})。
-        webhook_creds: "${globalVar.webhook_creds}"
-        # 企业机器人凭据(map: appKey → {client_id, client_secret})：
-        # stream 入站建连与会话内(session)出站共读；启用 stream 时在 workflow.yml 追加
-        # dingtalk_stream 事件源(robot_refs/robot_creds 同引 globalVar)。
-        robot_creds: "${globalVar.robot_creds}"
-      memory: { root_dir: "./.memory" }
-    event_sources:
-      群消息监听:
-        # 监听群名单由 config-sync 工作流发布到 globalVar，此处活读；
-        # 若删除 workflows/config-sync/ 则改为静态数组，如 ["cidAAA=="]。
-        # dingtalk_event 长连接无轮询，不配 poll_interval_ms。
-        # all-group：单进程监听账号全部群，conversation_ids 退化为本地白名单（名单为空=全丢弃，
-        # 不是放行全部）。内存不随群数增长——30 群约 71MB，而 kind: group 的每群一进程约 1.2GB；
-        # 群名单热更只改内存不动进程。代价是无关群消息会流经本进程后被丢弃（故建议用专用服务账号
-        # 登录 dws，而非真人账号）。要退回每群一进程隔离，把 kind 改成 group 即可。
-        kind: all-group
-        conversation_ids: "${globalVar.group_pull_list}"
-        image_mode: download # 图片本地化：download（鉴权下载）/ url / none
-        handler_config:
-          # 群机器人身份与真人名单来源，均由 config-sync 发布
-          conversation_ids: "${globalVar.group_configs}"
-          admins: "${globalVar.admins}"
-          aggregate_window_ms: 5000
-    steps:
-      # 确定性秒回：命中规则文件即秒回，不走 LLM
-      fastpath:
-        rules: fastpath/known-answers.yml # 相对 profile 目录；⚠️ 按产品补充已知问答
-
-      # 诊断升级：分类器命中 → 独立排查 Agent 读 Skill 真实排查
-      troubleshoot:
-        conversation_ids: "${globalVar.group_configs}" # 仅「是否排查问题」开启的群生效
-        classifiers: troubleshoot/classifiers.yml # 相对 profile 目录；⚠️ 按产品补充分类规则
-        skills_dir: "" # ⚠️ 排查 Skill 目录（相对实例根，如 skills/troubleshooting）；留空即整档关闭
-
-      # 主应答（LLM + 知识库）
-      answer:
-        # coding: { engine: qoder } # 可选：覆写本步 coding 引擎（缺省走全局 coding-agents 配置）
-        standby:
-          enabled: false # 追问补位：用户 @真人后超时无人回且用户追问时放行
-          wait_minutes: 30
-        # 模块→Owner 映射在 AI 表格「功能模块人员配置表」维护（模块-文本 + 人员-人员字段），
-        # 由 config-sync 定时拉取并发布 ${globalVar.module_owners}；表为空即无转人工
-
-      # 决策后处置（拍平 action）：只配留痕(track)与群里说不说话(group: answer|silent)。
-      # Owner 尾注不在这里配：bug/feature/kb_gap 且 module 能解析出 Owner 时 Runtime 自动附加；
-      # 通知渠道不在这里配：Runtime 只产出结构化通知字段，TODO/IM 由 AI 表格自动化按需发起
-      on_action:
-        # 功能模块人员配置来源（config-sync 发布）：bug/feature/kb_gap 升级时据此解析模块 Owner
-        module_owners: "${globalVar.module_owners}"
-        # Webhook 群必须配置 corpId 才允许真实 @；缺失时 Owner 尾注降级为花名
-        group_configs: "${globalVar.group_configs}"
-        policies:
-          reply: { track: true, group: answer } # 有据回答：发群
-          bug: { track: true, group: answer } # Bug 升级：发群（Owner 可解析则自动附尾注）
-          feature: { track: true, group: answer } # 需求建议：发群（同上）
-          kb_gap: { track: true, group: silent } # 知识缺口：默认静默入收件箱；改 answer 即群内坦白无据+附 Owner 尾注
-          no_question: { track: false, group: silent } # 非提问：不建行（避免表被噪音刷屏）
-          human_handled: { track: false, group: silent } # 真人已处理：不建行
-          owner_mentioned: { track: true, group: silent } # 已 @到人：留痕
-          safety: { track: true, group: silent } # 安全拦截：留痕
-          agent_failure: { track: true, group: silent } # Agent 故障：留痕不发群
-
-      # 出站：按群配置的出站方式自动选路（webhook / 会话内）
-      reply_to_group:
-        group_configs: "${globalVar.group_configs}"
-
-  # ─────────────────────────────────────────────────────────────
-  # 配置同步：定时把群配置表 + 管理员表拉取并发布到 globalVar
-  # 供 group-qa / daily-review 活读；删除本工作流则上面改为静态数组
-  # ─────────────────────────────────────────────────────────────
-  config-sync:
-    event_sources:
-      定时同步:
-        interval_ms: 300000 # 5 分钟；也可改用 daily_at / cron
-        fire_immediately: true # 启动即同步一次，避免首轮空名单
-        event_type: config_sync_tick
-    steps:
-      config_sync:
-        # 三张表留空即可：setup 会自动建表（含字段/选项）并把 ID 回写到本文件
-        group_table: { baseId: "", tableId: "" }
-        admin_table: { baseId: "", tableId: "" }
-        owner_table: { baseId: "", tableId: "" } # 功能模块人员配置表（模块-文本 + 人员-人员）：bug/feature/kb_gap 升级时 @ 模块 Owner
-        group_var: "${globalVar.group_configs}"
-        pull_list_var: "${globalVar.group_pull_list}"
-        stream_var: "${globalVar.stream_robot_refs}"
-        webhook_creds_var: "${globalVar.webhook_creds}" # 群配置表 webhookUrl/webhookSecret 列派生
-        robot_creds_var: "${globalVar.robot_creds}" # 群配置表 appKey/appSecret 列派生
-        admin_var: "${globalVar.admins}"
-        owner_var: "${globalVar.module_owners}"
-        empty_confirm_rounds: 2 # 空快照门禁：连续读到空达该轮数才真正清空（防读空抖动误清名单）；设 1 即即时清空
-
-  # ─────────────────────────────────────────────────────────────
-  # 管理员知识更新：管理员在群问答表补结论 → 提炼为 FAQ 条目落库
-  # ─────────────────────────────────────────────────────────────
-  admin-kb-update:
-    toolkit_config:
-      file: { base_dir: "${roles.support.knowledge_scope.kb_collections[0]}" }
-    event_sources:
-      管理员更新监听:
-        # 监听 group-qa 的工单表（引用形态，运行时解析，无需填 ID）
-        source_table: { mode: reference, ref: workflow:group-qa.tracker }
-        watch_mode: both
-        poll_interval_ms: 300000
-        resolve_field_names: true
-        emit_existing: true
-        filter: { field: 知识沉淀, equals: 待沉淀 }
-        handler_config:
-          admin_field: 管理员更新
-          question_field: 消息内容
-          context_field: 对话上下文
-    steps:
-      kb_refine:
-        # coding: { engine: qoder } # 可选：覆写本步 coding 引擎（缺省走全局 coding-agents 配置）
-        file: { base_dir: "${roles.support.knowledge_scope.kb_collections[0]}" }
-        kb_file: FAQ.md # 追加目标 .md（相对 file.base_dir）
-
-  # ─────────────────────────────────────────────────────────────
-  # 每日复盘：凌晨归纳昨日对话，产出统计 / 需求池 / 学习候选
-  # ─────────────────────────────────────────────────────────────
-  daily-review:
-    toolkit_config:
-      memory: { root_dir: "./.memory" }
-    event_sources:
-      每日复盘调度:
-        daily_at: "01:00"
-        timezone: Asia/Shanghai
-        event_type: daily_review_trigger
-        fire_immediately: false
-    steps:
-      daily_review:
-        conversation_ids: "${globalVar.group_configs}" # 复盘群来源（或改为静态数组）
-        # 两张表留空即可：setup 自动建表并回写
-        daily_stats_table: { baseId: "", tableId: "" }
-        product_backlog_table: { baseId: "", tableId: "" }
-        # 学习候选写回 group-qa 的工单表（引用形态，运行时解析）
-        learning_candidate_table:
-          baseId: { ref: workflow:group-qa.tracker.base_id }
-          tableId: { ref: workflow:group-qa.tracker.table_id }
-        saved_minutes_per_reply: 15 # 每条 Agent 回复折算节省的人工工时（分钟）
-        timezone: Asia/Shanghai # 与 cron 时区一致；远端 UTC 机器必须显式设置
-        learning:
-          from_admin_replies: true # 从真人解答提炼学习候选
-          review: human-approve # human-approve（人工确认）/ auto（自动入库）

package/templates/support-qa/profiles/default/profile/troubleshoot/classifiers.yml

@@ -1,37 +0,0 @@
-# troubleshoot 声明式分类器（support-qa L3，取代硬编码 issue-classifier.ts）
-#
-# 启用：在 profile/profile.yml 打开
-#   troubleshoot:
-#     skills_dir: skills/troubleshooting     # 相对实例根；目录不存在 → 整档关闭
-#     classifiers: troubleshoot/classifiers.yml
-# 另需在群配置表把该群的 troubleshootingEnabled 置真，才对该群启用（按群开关）。
-#
-# 每个分类器：
-#   issueType   ：命中后的问题类型标签（传给排查 Agent 作路由）
-#   reason      ：命中理由（审计/日志）
-#   patterns    ：匹配条件列表，每条 contains 或 regex 之一
-#   require_all ：默认 false（任一 pattern 命中即算）；true 时需全部命中
-#   extract     ：可选，字段名→正则（取第一个捕获组），把结构化证据带进排查 prompt
-# 按声明顺序匹配，返回第一个满足的分类器；都不命中 → 交语义答疑 answer。
-#
-# ⚠️ 本文件为通用示例（product-neutral），请按你的产品替换/删除后再启用。
-
-classifiers:
-  # 示例 1：单条件（任一命中）——报错模板类
-  - issueType: error_report
-    reason: 命中报错模板
-    patterns:
-      - contains: "ERR_EXAMPLE"
-    extract:
-      code: "ERR_EXAMPLE[_A-Z0-9]*"
-
-  # 示例 2：多条件同时命中（require_all）——需要两个关键词共现才判定
-  - issueType: compound_issue
-    reason: 同时包含标识 A 与标识 B
-    require_all: true
-    patterns:
-      - contains: "标识A"
-      - contains: "标识B"
-    extract:
-      idA: "标识A[:：=]\\s*([A-Za-z0-9_-]+)"
-      idB: "标识B[:：=]\\s*(\\d+)"

package/templates/support-qa/profiles/default/wiki/support//345/270/270/350/247/201/351/227/256/351/242/230.md

@@ -1,10 +0,0 @@
-# 常见问题（示例占位）
-
-> 这是 support-qa 模板的知识库占位文件。把你的产品帮助文档（Markdown）放入本目录
-> （profile.knowledge.collections 指向的目录），答疑助手只依据这里的内容作答。
->
-> 建议每篇文章 frontmatter 携带 `original_sources`（在线原文链接），回复出处依赖它。
-
-## Q: 这是什么？
-
-A: support-qa 通用答疑工作流的示例知识库。替换本文件为真实产品文档后即可开始答疑。

package/templates/support-qa/tsconfig.json

@@ -1,16 +0,0 @@
-{
-  "compilerOptions": {
-    "target": "ES2022",
-    "module": "NodeNext",
-    "moduleResolution": "NodeNext",
-    "lib": ["ES2022"],
-    "strict": true,
-    "esModuleInterop": true,
-    "skipLibCheck": true,
-    "forceConsistentCasingInFileNames": true,
-    "noEmit": true,
-    "rootDir": "."
-  },
-  "include": ["lib/**/*.ts", "workflows/**/*.ts"],
-  "exclude": ["**/__tests__/**", "**/node_modules/**", "**/dist/**"]
-}

package/templates/support-qa/vitest.config.ts

@@ -1,9 +0,0 @@
-import { defineConfig } from "vitest/config";
-
-export default defineConfig({
-  test: {
-    testTimeout: 30_000,
-    hookTimeout: 30_000,
-    exclude: ["**/node_modules/**", "**/dist/**"],
-  },
-});