@zeyue0329/xiaoma-cli 1.12.0 → 1.13.0

package/.playwright-cli/console-2026-05-13T06-36-26-793Z.log

@@ -0,0 +1,2 @@
+[    1116ms] [LOG] %c %s color: yellow; background-color: black; [instance: default] appid: 20006317, userInfo:{"user_unique_id":"7639261564058707976","web_id":"7639261564058707976"} @ https://lf3-data.volccdn.com/obj/data-static/log-sdk/collect/5.0/collect-rangers-v5.2.11.js:0
+[    1116ms] [LOG] %c %s color: yellow; background-color: black; [instance: default] appid: 20006317, sdk is ready, version is 5.2.11_tob, you can report now !!! @ https://lf3-data.volccdn.com/obj/data-static/log-sdk/collect/5.0/collect-rangers-v5.2.11.js:0

package/.playwright-cli/page-2026-05-13T06-36-27-725Z.yml

@@ -0,0 +1 @@
+- img [ref=e7] [cursor=pointer]

package/CLAUDE.md

@@ -51,6 +51,7 @@ node test/test-installation-components.js
 Modules are defined by `module.yaml` files with configuration variables, prompts, and directory declarations. Variables use `{variable_name}` interpolation syntax and can reference each other (e.g., `{output_folder}` in path defaults). Core module variables (`user_name`, `communication_language`, etc.) are inherited by other modules:
 - **`src/core/`** — Shared skills and tasks (module code: `core`)
 - **`src/xmc/`** — XiaoMa Method module, the primary agile framework (module code: `xmc`)
+- **`src/utility/`** — Shared agent-components imported by other modules
 
 ### Agent System (`src/xmc/agents/`)
 

package/demo/xiaoma-bug-circle-resolve/SKILL.md

@@ -3,4 +3,4 @@ name: xiaoma-bug-circle-resolve
 description: '循环处理所有AI测试平台推送的新增状态Bug，每次处理前清空上下文避免噪声干扰，逐个调用xiaoma-bug-resolve技能修复，直到所有新增Bug处理完毕。Use when the user says "循环处理bug", "批量修复bug", "resolve all bugs", or "circle resolve bugs".'
 ---
 
-Follow the instructions in [workflow.md](workflow.md).
+Follow the instructions in [workflow.md](workflow.md).

package/demo/xiaoma-bug-circle-resolve/workflow.md

@@ -1,13 +1,43 @@
 # Bug Circle Resolve Workflow
 
-**Goal:** 全自动循环处理所有AI测试平台推送的新增状态(defect_status=0)Bug，无需任何人工介入，直到队列清空。
+**Goal:** 全自动循环处理**指定项目**下所有AI测试平台推送的新增状态(defect_status=0)Bug，无需任何人工介入，直到队列清空。
 
-**Your Role:** 你是Bug处理调度器。你的职责是：查询Bug队列 → 为每个Bug启动独立Agent子进程处理 → 确认处理结果 → 继续下一个 → 输出最终报告。全程无需用户参与。
+**Your Role:** 你是Bug处理调度器。你的职责是：校验 jiraId 参数 → 查询当前项目的 Bug 队列 → 为每个Bug启动独立Agent子进程处理 → 确认处理结果 → 继续下一个 → 输出最终报告。全程无需用户参与。
 
 **所有输出使用简体中文。**
 
 ---
 
+## 参数说明
+
+本 skill 支持以下参数：
+
+| 参数 | 是否必填 | 传参形式 | 说明 | 示例 |
+|------|---------|---------|------|------|
+| `jiraId` | **必填** | **位置参数（唯一 token）** | JIRA 项目 ID，多项目共库场景下的硬隔离边界。**所有 `t_defect_info` 的 SELECT/UPDATE/COUNT 都必须带 `AND jira_id = '{{jiraId}}'`**，子 Agent 也必须继承此参数。 | `GYLPJ-1153` |
+
+### args 解析规则（Claude 必须严格遵守）
+
+把 skill 传入的 `args` 按空格切分成 token 列表后：
+1. 取**第一个 token**：
+   - 若**不含 `=`**，视为 `jiraId` 的值（位置参数语法，**推荐形式**）。
+   - 若形如 `jiraId=xxx`，解析为 `jiraId`（兼容旧语法）。
+   - 若形如 `otherKey=xxx`（任何其它键值对），说明位置参数缺失，视为**未提供 jiraId**。
+2. 本 skill 只接受 `jiraId` 一个参数。若 args 中出现任何第二个 token（无论形式），视为非法输入，立刻中断并提示用户只需传一个 jiraId。
+3. 若最终 `jiraId` 仍为空或空字符串，**立刻拒绝执行**，禁止开始循环（否则会把其他项目的 Bug 一并拉下来误改代码、误改状态）。
+
+### 调用示例
+
+```
+# 推荐：位置参数（最简洁）
+/xiaoma-bug-circle-resolve GYLPJ-1153
+
+# 兼容旧语法（仍可用）
+/xiaoma-bug-circle-resolve jiraId=GYLPJ-1153
+```
+
+---
+
 ## 核心架构：Agent 隔离处理
 
 **为什么不需要 `/clear`：** 每个Bug的分析和修复都委托给**独立的 Agent 子进程**。Agent 天然拥有隔离的上下文空间，处理完即释放，不会污染主对话。主对话只负责轻量的调度循环。
@@ -36,8 +66,9 @@
 - **MySQL缺陷库**: `mcp__xiaoma-dev-mysql__mysql_query` — 查询/更新Bug状态
 - **Oracle业务库**: `mcp__oracle_zqyl_pj_incentive_test4__execute_query` — 验证业务数据
 - **缺陷表**: `t_defect_info`
-- **待处理条件**: `defect_status = 0 AND is_del = 0`
+- **待处理条件**: `defect_status = 0 AND is_del = 0 AND jira_id = '{{jiraId}}'`（**jira_id 强制过滤**）
 - **状态枚举**: 0=新增, 1=已验证, 2=已修复, 3=非缺陷(测试误报)
+- **项目隔离字段**: `jira_id`（varchar(64)，JIRA 项目 ID），多项目共库时用于区分
 
 ---
 
@@ -45,34 +76,39 @@
 
 <workflow>
 
-<step n="1" goal="检查待处理Bug队列并展示概况">
+<step n="1" goal="校验 jiraId 并检查当前项目下待处理Bug队列">
 
-  <action>查询缺陷统计：
+  <action>**前置校验**：按本文件顶部的「args 解析规则」从 args 中解析出 `jiraId`。若未解析到（args 为空），立刻中断并输出：
+  `批量循环处理必须将 jiraId 作为第一个参数传入，例如：/xiaoma-bug-circle-resolve GYLPJ-1153`
+  禁止在没有 jiraId 的情况下继续执行任何 t_defect_info 查询或循环。
+  </action>
+
+  <action>查询当前项目（jiraId={{jiraId}}）缺陷统计：
   ```sql
   SELECT
     SUM(CASE WHEN defect_status = 0 THEN 1 ELSE 0 END) as pending,
     SUM(CASE WHEN defect_status = 2 THEN 1 ELSE 0 END) as fixed,
     SUM(CASE WHEN defect_status = 3 THEN 1 ELSE 0 END) as false_positive,
     COUNT(*) as total
-  FROM t_defect_info WHERE is_del = 0;
+  FROM t_defect_info WHERE is_del = 0 AND jira_id = '{{jiraId}}';
   ```
   </action>
 
   <check if="pending == 0">
-    <action>无待处理缺陷，直接进入 Step 3 输出最终报告</action>
+    <action>当前项目无待处理缺陷，直接进入 Step 3 输出最终报告</action>
   </check>
 
   <check if="pending > 0">
-    <action>查询待处理缺陷列表：
+    <action>查询当前项目下待处理缺陷列表：
     ```sql
     SELECT defect_id, title, severity, module_path
     FROM t_defect_info
-    WHERE is_del = 0 AND defect_status = 0
+    WHERE is_del = 0 AND defect_status = 0 AND jira_id = '{{jiraId}}'
     ORDER BY create_time ASC;
     ```
     </action>
 
-    <action>向用户展示概况并告知即将开始全自动处理</action>
+    <action>向用户展示概况（必须包含"当前项目 jiraId：{{jiraId}}"一行）并告知即将开始全自动处理</action>
     <action>进入 Step 2 开始循环</action>
   </check>
 
@@ -80,11 +116,11 @@
 
 <step n="2" goal="循环处理每个Bug（全自动）">
 
-  <!-- 循环开始：查询当前最早的待处理Bug完整信息 -->
-  <action>查询当前最早的一条待处理Bug的完整详情：
+  <!-- 循环开始：查询当前项目下最早的待处理Bug完整信息 -->
+  <action>查询当前项目（jiraId={{jiraId}}）下最早的一条待处理Bug的完整详情：
   ```sql
   SELECT * FROM t_defect_info
-  WHERE is_del = 0 AND defect_status = 0
+  WHERE is_del = 0 AND defect_status = 0 AND jira_id = '{{jiraId}}'
   ORDER BY create_time ASC LIMIT 1;
   ```
   </action>
@@ -101,7 +137,7 @@
   使用 Agent 工具启动一个 general-purpose 子进程来处理这个Bug。
   Agent 的 prompt 必须包含以下完整信息，使其能独立工作：
 
-  1. **Bug完整信息**：将查询到的 defect_id, title, steps, module_path, url, error_front, error_apis, defect_type, severity 全部传给Agent
+  1. **Bug完整信息 + 项目上下文**：将查询到的 defect_id, title, steps, module_path, url, error_front, error_apis, defect_type, severity **以及当前处理的 jiraId={{jiraId}}** 全部传给Agent。Agent 必须把 jiraId 视为硬约束，所有 SQL 都要带 `AND jira_id = '{{jiraId}}'`。
   2. **处理指令**：按以下步骤执行——
      a. 根据 module_path 和 url 定位代码（前端在 zqyl-manager/src/main/views/pjs/incentive/，后端在 zqyl-pj-incentive/src/main/）
      b. 使用 Explore Agent 探索相关前端页面组件、后端Controller/Service/Mapper代码
@@ -109,10 +145,12 @@
      d. 分析根因，判定：真实缺陷 or 测试误报
      e. 如为真实缺陷：使用 Edit 工具修复代码，修复范围限定在缺陷涉及的代码
      f. 验证修复逻辑正确性
-     g. 使用 MySQL MCP Server (mcp__xiaoma-dev-mysql__mysql_query) 更新Bug状态：
-        - 真实缺陷已修复：UPDATE t_defect_info SET defect_status = 2 WHERE defect_id = '{{defect_id}}' AND is_del = 0;
-        - 测试误报：UPDATE t_defect_info SET defect_status = 3 WHERE defect_id = '{{defect_id}}' AND is_del = 0;
-     h. 返回处理结果摘要：defect_id、判定结果、修改的文件列表、验证结果
+     g. 使用 MySQL MCP Server (mcp__xiaoma-dev-mysql__mysql_query) 更新Bug状态（**UPDATE 必须带 jira_id 过滤**）：
+        - 真实缺陷已修复：
+          `UPDATE t_defect_info SET defect_status = 2 WHERE defect_id = '{{defect_id}}' AND jira_id = '{{jiraId}}' AND is_del = 0;`
+        - 测试误报：
+          `UPDATE t_defect_info SET defect_status = 3 WHERE defect_id = '{{defect_id}}' AND jira_id = '{{jiraId}}' AND is_del = 0;`
+     h. 返回处理结果摘要：defect_id、jiraId、判定结果、修改的文件列表、验证结果
   3. **项目规范**：遵循 CLAUDE.md 编码规范，禁止Lombok、禁止MyBatis-Plus、返回ResultData等
   4. **常见缺陷模式参考**：
      - 模糊查询不符合预期 → SQL用 = 而非 LIKE，改为 LIKE '%' || #{param} || '%'
@@ -132,9 +170,10 @@
   <action>输出该Bug的处理结果（简要一行）</action>
 
   <!-- 检查是否还有剩余 -->
-  <action>查询剩余待处理数量：
+  <action>查询当前项目下剩余待处理数量：
   ```sql
-  SELECT COUNT(*) as remaining FROM t_defect_info WHERE is_del = 0 AND defect_status = 0;
+  SELECT COUNT(*) as remaining FROM t_defect_info
+  WHERE is_del = 0 AND defect_status = 0 AND jira_id = '{{jiraId}}';
   ```
   </action>
 
@@ -150,7 +189,7 @@
 
 <step n="3" goal="输出最终处理报告">
 
-  <action>查询所有缺陷的最终状态：
+  <action>查询当前项目（jiraId={{jiraId}}）下所有缺陷的最终状态：
   ```sql
   SELECT defect_id, title,
     CASE defect_status
@@ -161,18 +200,18 @@
     END as status_text,
     update_time
   FROM t_defect_info
-  WHERE is_del = 0
+  WHERE is_del = 0 AND jira_id = '{{jiraId}}'
   ORDER BY defect_status ASC, update_time DESC;
   ```
   </action>
 
-  <action>查询统计汇总：
+  <action>查询当前项目统计汇总：
   ```sql
   SELECT
     SUM(CASE WHEN defect_status = 0 THEN 1 ELSE 0 END) as pending,
     SUM(CASE WHEN defect_status = 2 THEN 1 ELSE 0 END) as fixed,
     SUM(CASE WHEN defect_status = 3 THEN 1 ELSE 0 END) as false_positive
-  FROM t_defect_info WHERE is_del = 0;
+  FROM t_defect_info WHERE is_del = 0 AND jira_id = '{{jiraId}}';
   ```
   </action>
 
@@ -183,6 +222,8 @@
   全部Bug处理完毕
   ========================================
 
+  项目ID（jiraId）：{{jiraId}}
+
   已修复: {{fixed}} 条
   测试误报: {{false_positive}} 条
   剩余待处理: {{pending}} 条
@@ -192,7 +233,7 @@
   |--------|------|---------|---------|
   | ...    | ...  | ...     | ...     |
 
-  所有新增状态的测试Bug已处理完毕，全程无需人工介入。
+  当前项目（{{jiraId}}）下新增状态的测试Bug已处理完毕，全程无需人工介入。
   ```
 
   </action>
@@ -205,8 +246,9 @@
 
 ## 注意事项
 
-1. **Agent 隔离是关键** — 每个Bug在独立Agent子进程中处理，自带隔离上下文，无需 `/clear`，不会相互干扰
-2. **全自动** — 用户只需调用一次 `/xiaoma-bug-circle-resolve`，之后全程自动直到队列清空
-3. **串行安全** — 一次只处理一个Bug，避免并发修改同一文件产生冲突
-4. **容错** — Agent处理失败时Bug状态仍为0，下次循环自动重试
-5. **Agent prompt 质量** — 传给Agent的prompt必须包含Bug完整信息 + 项目上下文 + 处理指令，使其能完全独立工作
+1. **jiraId 是硬隔离边界** — 批量循环处理必须指定 jiraId，**所有 `t_defect_info` 的 SELECT/UPDATE/COUNT 都必须带 `AND jira_id = '{{jiraId}}'`**，子 Agent 的 prompt 和 UPDATE 语句也必须继承该值，否则会跨项目误改代码和状态
+2. **Agent 隔离是关键** — 每个Bug在独立Agent子进程中处理，自带隔离上下文，无需 `/clear`，不会相互干扰
+3. **全自动** — 用户只需调用一次 `/xiaoma-bug-circle-resolve GYLPJ-1153`（首个位置参数即 jiraId），之后全程自动直到当前项目队列清空
+4. **串行安全** — 一次只处理一个Bug，避免并发修改同一文件产生冲突
+5. **容错** — Agent处理失败时Bug状态仍为0，下次循环自动重试
+6. **Agent prompt 质量** — 传给Agent的prompt必须包含Bug完整信息 + jiraId + 项目上下文 + 处理指令，使其能完全独立工作

package/demo/xiaoma-prd-saas-zh/README.md

@@ -0,0 +1,57 @@
+# 中文 SaaS B2B PRD 样例 — 灵协 Linkly
+
+本目录是一份完整的 XiaoMa-CLI PRD 标准化样例集，对应 `project-types.csv` 中的 `saas_b2b` 类型。它演示从产品简报 → 研究 → PRD → Epics → 验证报告的端到端工件链，作为 AI 生成 PRD 时的对照基准与人类作者的参考样板。
+
+## 虚构场景
+
+**灵协 Linkly** — 面向中型企业（年营收 5 亿-50 亿）客户成功（Customer Success）团队的 AI 客户旅程协作平台。核心能力：跨系统聚合的客户旅程画布、LLM 驱动的高风险对话摘要、可解释的客户健康度评分与触达建议。
+
+| 维度       | 取值                                           |
+| ---------- | ---------------------------------------------- |
+| 产品类型   | saas_b2b                                       |
+| 目标领域   | general（含轻度 fintech/healthcare 客户合规）  |
+| 复杂度     | medium                                         |
+| 项目阶段   | greenfield · MVP 计划 2026 H2                  |
+| 预期规模   | 单租户 ≤ 200 人 · 总租户 100-500 · 单租户 1k 并发 |
+
+## 目录文件
+
+| 文件                                    | 类型           | 作用                                         |
+| --------------------------------------- | -------------- | -------------------------------------------- |
+| [README.md](./README.md)                | 元说明         | 本文件                                       |
+| [product-brief.md](./product-brief.md)  | 上游产物（CB） | Analyst `*product-brief` 的产出样例          |
+| [market-research-2026-q1.md](./market-research-2026-q1.md) | 上游产物（MR） | 市场研究节选 |
+| [domain-research.md](./domain-research.md) | 上游产物（DR） | 领域研究（含合规要点）                       |
+| [prd.md](./prd.md)                      | **主样例**     | 9 章节 + 24 FR + 10 NFR + Traceability Matrix |
+| [prd-bad-examples.md](./prd-bad-examples.md) | 反模式集    | 对应 AP-01..AP-05 的坏例 + 修复对照          |
+| [epics.md](./epics.md)                  | 下游样例       | FR→Epic→Story 拆分演示                       |
+| [validation-report.md](./validation-report.md) | 校验报告 | `xiaoma-validate-prd` 13 维得分卡示例        |
+
+## 阅读建议
+
+- **第一次读 PRD 标准化方案：** 直接看 [prd.md](./prd.md)，对照 `prd-purpose.md` 与 `prd-skeleton-reference.md` 体感 9 章节结构。
+- **想理解 AI 化的对照基准：** [prd.md](./prd.md) ↔ [prd-bad-examples.md](./prd-bad-examples.md) 同节对比，每个反模式都标注了 AP 编号。
+- **想验证 rubric 设计：** 看 [validation-report.md](./validation-report.md)，13 维得分卡基于 `prd-quality-rubric.csv` 计算。
+- **想看上下游衔接：** 从 [product-brief.md](./product-brief.md) 出发，对照 [prd.md](./prd.md) 的 §1-§3 字段映射，再看 [epics.md](./epics.md) 中的 FR→Epic 拆分。
+
+## 与工作流的关系
+
+本目录文件**不被任何工作流自动加载**——它们是参考样例，不是模板或配置。开发者可以：
+
+1. 复制 [product-brief.md](./product-brief.md) 到 `{planning_artifacts}/`，跑 `pm *create-prd`，diff 输出与 [prd.md](./prd.md) 对比结构一致性。
+2. 复制 [prd-bad-examples.md](./prd-bad-examples.md) 中片段拼成的"坏 PRD"，跑 `pm *validate-prd`，验证 rubric 是否命中预期 blockers。
+3. 把 [prd.md](./prd.md) 作为新项目的起点，按团队实际场景增删字段。
+
+## 注意事项
+
+- 所有数字（baseline、target、SLA 等）均为**虚构示例**，不代表真实产品承诺。
+- "灵协 Linkly" 与文中所有公司名、客户名、案例均为示例。
+- 文件中的术语（CSM、健康度、触达等）遵循国内 SaaS 行业常见命名，但具体定义见 [prd.md §5.2](./prd.md)。
+
+## 维护
+
+样例与 `prd-purpose.md` / `prd-quality-rubric.csv` 同期演进：
+
+- prd-purpose.md 增新反模式 → prd-bad-examples.md 增对应坏例
+- prd-quality-rubric.csv 调整权重/阈值 → validation-report.md 重算得分卡
+- project-types.csv saas_b2b 行变更 → prd.md §7 同步

package/demo/xiaoma-prd-saas-zh/domain-research.md

@@ -0,0 +1,128 @@
+---
+workflowType: 'research'
+research_type: 'domain'
+research_topic: 'SaaS B2B · 客户成功与多租户 SaaS 合规'
+research_goals: '识别强制合规要求 · 行业术语 · 集成依赖'
+date: '2026-04-18'
+author: 林晓彤
+web_research_enabled: true
+source_verification: true
+---
+
+# Research Report: Domain
+
+**Date:** 2026-04-18
+**Author:** 林晓彤
+**Research Type:** Domain (SaaS B2B · 客户成功)
+
+---
+
+## Domain Analysis
+
+### 行业边界
+
+灵协 Linkly 所处领域：
+
+- **主：** SaaS B2B · 客户成功（Customer Success）工具
+- **次：** 跨边界场景 — 客服整合、CRM 数据消费、IM 集成
+- **不属于：** 自营 CRM · 自营客服坐席 · 销售自动化（SFA）
+
+### 核心术语
+
+| 术语                            | 英文                       | 定义                                                                 |
+| ------------------------------- | -------------------------- | -------------------------------------------------------------------- |
+| 客户成功（CS）                  | Customer Success           | 帮助客户从产品中获得预期价值，降低流失率提升续费                     |
+| 客户成功经理（CSM）             | Customer Success Manager   | 直接对客户健康度负责的角色，1:N 服务客户                             |
+| 客户健康度                      | Customer Health Score      | 综合多维信号给客户打的健康评分（0-100），表达流失风险                |
+| 流失预警                        | Churn Risk Alert           | 系统识别到客户流失风险时触发的通知                                   |
+| 触达                            | Outreach                   | 主动联系客户的动作（电话、邮件、IM 等）                              |
+| 客户旅程                        | Customer Journey           | 客户从认识、采购、使用、续费的全过程                                 |
+| 旅程画布                        | Journey Canvas             | 把客户旅程可视化呈现的视图                                           |
+| 净推荐值                        | NPS                        | -100~100，客户推荐意愿评分                                           |
+| 年度合同金额                    | ACV (Annual Contract Value) | 单客户年度合同金额                                                  |
+| 续费率                          | Renewal Rate               | 到期客户实际续费比例                                                 |
+| 净留存率                        | NRR (Net Revenue Retention) | 含扩展和流失的净收入留存率                                          |
+
+### 客户旅程阶段（行业通用模型）
+
+1. **入职（Onboarding）：** 客户签约后的 30-90 天，建立初次价值认知
+2. **采纳（Adoption）：** 持续使用产品，建立日常工作流
+3. **扩展（Expansion）：** 客户增加用户数 / 升级版本 / 购买附加模块
+4. **续费（Renewal）：** 合同到期前的评估与决策
+5. **倡导（Advocacy）：** 成为产品的推荐者，参与案例 / 介绍其他客户
+6. **流失风险 / 流失（At Risk / Churned）：** 客户出现退订意向或已退订
+
+CSM 工作重心通常在阶段 2-4，灵协 Linkly 的核心能力（流失预警 + 触达建议）覆盖阶段 2-6。
+
+## Regulatory Focus
+
+### 强制合规（中国大陆）
+
+#### 数据安全与隐私
+
+- **个人信息保护法（个保法）：** 2021 年 11 月施行，要求处理个人信息须取得授权、最小化原则、数据本地化（涉及关键信息基础设施的）
+- **网络安全法 + 等保 2.0：** SaaS 服务面向企业客户，建议达到等保二级；如客户为央企 / 政府 / 金融，需等保三级
+- **数据安全法：** 数据分类分级（重要数据 / 一般数据），跨境传输需评估
+
+#### 行业相关合规（取决于客户行业）
+
+- 客户为金融机构：JR/T 0071-2020 金融行业网络安全等级保护实施指引、银保监 SaaS 服务规范
+- 客户为医疗机构：HIPAA-like 国内对应（卫健委信息安全等级保护要求）
+- 客户为政企客户：SaaS 服务厂商需在政府云平台备案（如阿里政务云）
+
+### 灵协 Linkly 合规策略
+
+| 合规项                | 优先级 | MVP 是否覆盖 | 说明                                              |
+| --------------------- | ------ | ------------ | ------------------------------------------------- |
+| 等保二级              | 必须   | 是           | MVP 上线前完成测评                                |
+| 个保法授权链          | 必须   | 是           | 客户对话内容仅在租户内可见，跨租户隔离强制启用    |
+| 数据本地化（中国大陆）| 必须   | 是           | 仅使用中国大陆 IDC                                |
+| 审计日志              | 必须   | 是           | 所有客户数据访问行为记录，保留 ≥ 180 天           |
+| 等保三级              | 推荐   | 否           | 留待 Growth 阶段（Q1 2027）                       |
+| ISO 27001             | 推荐   | 否           | 留待 GA 上线后启动                                |
+
+### 合规对 PRD 的硬约束
+
+写入 PRD §5 Domain Requirements 的具体条款：
+
+- 5.1.1 客户对话原文不出租户边界（跨租户隔离）
+- 5.1.2 LLM API 调用不存储客户原始对话（仅缓存摘要）
+- 5.1.3 审计日志覆盖：登录、查询、导出、配置变更、API 调用，保留 180 天
+- 5.1.4 数据备份：日全量 + 小时增量，保留 30 天
+- 5.1.5 数据导出：客户可申请租户数据完整导出（30 天内交付）
+- 5.1.6 数据删除：客户解约后 90 天内完成数据删除（合规链记录）
+
+## Competitive Landscape
+
+（详细竞品分析见 [market-research-2026-q1.md §3](./market-research-2026-q1.md)。本节聚焦领域视角的差异化点。）
+
+国内 CS SaaS 行业整体处于早期，头部产品（聚客云、客成 Pro）在能力广度上仍有空白。灵协 Linkly 选择"画布 + AI + 评分"三位一体组合是领域内首例。
+
+## Technical Trends
+
+### 关键技术成熟度（2025-2026）
+
+| 技术领域           | 成熟度 | 影响                                            |
+| ------------------ | ------ | ----------------------------------------------- |
+| 国产 LLM API       | 商用化 | 摘要 / 风险解释 / 触达建议生成可商用            |
+| 多租户架构         | 成熟   | 行级隔离 + 租户级配置已成标准做法               |
+| 实时数据同步（CDC）| 成熟   | 与上游系统的数据同步可达分钟级                  |
+| 客户健康度模型     | 上升   | 从纯规则向"规则 + ML"混合演进                   |
+| 实时推荐引擎       | 成熟   | 触达建议生成可基于 ES + 向量检索                |
+| Webhook 集成生态   | 成熟   | 钉钉 / 飞书 / 主流 CRM 均提供完善 webhook 接口  |
+
+### 可借鉴的架构模式
+
+- **多租户：** Schema-per-tenant（强隔离） vs 行级隔离（成本优 - 推荐 MVP）
+- **LLM 接入：** Adapter 模式抽象多厂商（通义 / 文心 / 智谱 / OpenAI 兼容层）
+- **风险评分：** 规则引擎 + 特征仓库 + 离线模型，每日批量评分
+
+## Conclusion
+
+灵协 Linkly 在领域合规与技术成熟度上具备 MVP 可落地条件：
+
+- **合规：** 等保二级 + 数据本地化的硬约束清晰，工程量在可控范围
+- **技术：** LLM API、多租户、CDC 集成均已商用成熟
+- **竞争：** 国内 CS SaaS 头部产品仍有能力组合空白，差异化窗口期 12-18 个月
+
+PRD §5 Domain Requirements 应至少包含本研究所列的 6 条强制合规条款（5.1.1-5.1.6）。