--- [km-pipeline] [ADD] Bug记录：merge.sh首次运行卡死30分钟 ---

[2026-04-16T03:43:07.620Z] [assistant] (session:bc20dad6)

**问题记录 #1**：11:07 那次 run.sh 的 merge 启动后至少卡了 30 分钟（11:12→11:42+）。目前 agent 在重跑中。

---

--- [km-pipeline] [ADD] Bug记录：macOS无timeout命令+agent两次失败 ---

[2026-04-16T03:46:17.445Z] [assistant] (session:d7c2d500)

Agent 没跑成功，两次都失败：

| 尝试 | 命令 | 结果 |
|------|------|------|
| 1️⃣ | `timeout 1500 bash run.sh` | **exit 127** — macOS 没有 `timeout` 命令 |
| 2️⃣ | 改用后台 PID + 5s 轮询 | **被张总拒绝**（03:43:47 UTC）|

拒绝后 agent 就停了。当前：
- 无 run.sh/merge.sh/extract.sh 进程在跑
- 之前日志看到的 `[11:42:30]` 那一轮（`75044B` 增量，`batch1/1 53830 chars`），是 agent 第二次尝试的**前置重置脚本**跑过了（它没被拒），但实际的 `bash run.sh` 被打断，所以 extract 只跑到 Stage 1 过滤就停了

换句话说：**一键全流程至今没真正实现**。agent 这次没帮上忙。

---

--- [km-pipeline] [UPDATE] 架构决策复盘：merge全量重写保留+三项已完成项确认+优先级重排 ---

[2026-04-16T03:50:01.002Z] [assistant] (session:5baa4a1e)

## 我之前说错的地方

### 错 1（最严重）：我建议把 merge.sh 改成 patch 模式

我说："merge 现在是'读全文+重写章节'，应该改成 patch + fuzzy_match，token 翻倍 / diff 噪声大"。

**实际情况**：你们团队**已经评估过这个权衡了**。压缩上下文里上一轮 Claude 明确说过：
> 增量合并 vs 全量重建质量差距分析：**增量不建关系 / 不验 schema / 无叙事连贯，全量 = 推倒重来**

而"读全文 + 重写受影响章节"被实测为 ~98% 质量、~25K tokens，是**有意识选择的方案**，不是没考虑过 patch。

我推 patch 是因为脑子里装着 Hermes 的"省 token"逻辑——但你们的定位就是**生产力 KM，质量优先 token 不计**，patch 模式的"建关系不全 / 叙事不连贯"恰恰是图谱致命伤。**这条建议作废，merge.sh 当前的全文重写策略是对的，不要动。**

### 错 2：我说 "S2 是 SOP 1 的低配山寨版，要补共享 schema"

我读 extract.sh 时看到 S2 prompt 里有 `# 知识图谱共享 Schema（v3.0）

> 17 种实体类型 + 14 种关系类型 + 类型选择决策树。供 extract / merge prompt 引用。

---

## 1. 实体类型 Detail Schema

### 1.1 原有类型（8 种）

| 实体类型 | 必需字段 | 不可省略的信息 |
|----------|---------|---------------|
| SERVICE | port, role, dependencies | 端口号、主要职责、依赖的其他服务 |
| COMPONENT | key_functions, constants, lifecycle | 函数名保留原文、常量保留具体值、流程保留步骤链 |
| API_ENDPOINT | method, path, params, returns, auth | 每个参数的名称+类型，不能只说"接受参数" |
| CONCEPT | fields, rules, constraints | 数据模型必须逐字段列出，包含校验规则 |
| ISSUE | cause, fix, affected, severity | 三要素缺一不可：现象→根因→修复方案（代码/命令级） |
| CONFIG | key, values, scope | 各环境/实例的具体值，标注生效范围 |
| FILE | path, key_contents, role | 文件路径、包含的关键模块/函数、在系统中的角色 |
| TOOL | purpose, usage | 一句话定义 + 使用方式 |

### 1.2 新增类型（9 种）

| 实体类型 | 必需字段 | 不可省略的信息 |
|----------|---------|---------------|
| WORKFLOW | steps, trigger, output, frequency | 有序步骤链（`A → B → C` 格式），不可模糊化。描述系统自动执行的流程 |
| RULE | condition, action, rationale, scope | 一条明确约束/铁律。必须包含 rationale（为什么），否则规则会被忽略 |
| METRIC | name, value, unit, context, trend | 单个量化数据点。必须附带上下文（何时测量、什么条件），孤立数字无意义 |
| CREDENTIAL | service, type, location, rotation | 凭据/密钥引用（**不存储明文**）。标注存储位置和轮换策略 |
| DEVICE | model, specs, connectivity, firmware | 物理设备。必须包含型号和连接方式 |
| TEMPLATE | language, purpose, usage_pattern, variables | 可复用的代码/配置模板。标注变量占位符和使用场景 |
| PROTOCOL | mode, trigger, steps, branching_logic, user_input, state_source | 交互式会话协议。steps 中每步标注 `[ASK]`（等用户）或 `[DO]`（自动执行）。state_source 标注持久化文件路径 |
| TRACKER | subject, current_value, unit, history, progression_rule, update_trigger | 带历史趋势的数据序列。history 保留最近 N 条。progression_rule 是升级/降级条件（如"稳定12个后升重"） |
| PROMPT_TEMPLATE | role, personality, tone, constraints, system_prompt_structure, variables | AI 角色/人设定义。constraints 列出行为禁区。variables 列出运行时可替换占位符 |

---

## 2. 关系类型（14 种）

| 关系 | 含义 | 举例 |
|------|------|------|
| FILE **exposes** API_ENDPOINT | 文件暴露接口 | routes.js exposes POST /api/login |
| COMPONENT **affects** ISSUE | 组件关联问题 | PaymentModule affects 签名验证漏洞 |
| WORKFLOW **uses** SERVICE | 流程调用服务 | 部署流程 uses PM2 |
| RULE **constrains** COMPONENT | 规则约束组件 | rsync禁止--delete constrains 部署脚本 |
| METRIC **measures** SERVICE | 指标度量服务 | 月费$220 measures TURN服务 |
| CREDENTIAL **authenticates** SERVICE | 凭据认证服务 | Bot Token authenticates Telegram |
| DEVICE **hosts** SERVICE | 设备承载服务 | Mac Mini hosts MongoDB |
| TEMPLATE **implements** COMPONENT | 模板实现组件 | ChannelPlugin模板 implements Telegram插件 |
| PROTOCOL **reads** TRACKER | 协议读取追踪数据 | 训练引导协议 reads 坐姿推举追踪 |
| PROTOCOL **writes** TRACKER | 协议写入追踪数据 | 训练完成 writes 训练日志 |
| PROTOCOL **switches_to** PROTOCOL | 协议模式切换 | 首次摸底 switches_to 每日站会 |
| PROTOCOL **uses** FILE | 协议依赖外部文件 | 训练引导 uses leg-plan.md |
| PROTOCOL **outputs** TEMPLATE | 协议生成结构化输出 | 每日站会 outputs 行动清单模板 |
| TRACKER **informs** RULE | 追踪数据触发规则 | 重量追踪 informs 渐进超负荷规则 |

---

## 3. 类型选择决策树

对每段知识，选最具体的实体类型：

| 知识描述的是... | 选择 | 易混淆项 |
|----------------|------|---------|
| "自动做什么"（无需用户介入） | WORKFLOW | -- |
| "引导用户做什么"（有问答/等待/分支） | PROTOCOL | 与 WORKFLOW 区分见下 |
| "不能做什么"（约束/铁律） | RULE | -- |
| "某一时刻的数据是多少" | METRIC | 与 TRACKER 区分见下 |
| "一段时间内数据怎么变化" | TRACKER | -- |
| "怎么连接"（软件） | API_ENDPOINT | -- |
| "怎么连接"（硬件） | DEVICE | -- |
| "可以复用的代码" | TEMPLATE | 与 PROMPT_TEMPLATE 区分见下 |
| "AI 应该扮演什么角色" | PROMPT_TEMPLATE | -- |
| "出了什么问题" | ISSUE | -- |

### 易混淆类型判定规则

**WORKFLOW vs PROTOCOL：**
- 有"询问用户""等待回答""根据回答"等表述 → PROTOCOL
- 步骤中每一步都由系统自动执行 → WORKFLOW

**METRIC vs TRACKER：**
- 只出现一次、没有历史对比 → METRIC
- 有"上次""下次建议""趋势""历史"等表述 → TRACKER

**TEMPLATE vs PROMPT_TEMPLATE：**
- 通用代码/配置模板 → TEMPLATE
- AI 角色设定/system prompt/人设定义 → PROMPT_TEMPLATE

**兜底原则：** 宁可选错类型也不要退化为纯 description。
` 占位符，但**没意识到 shared_schema.md 已经做完并注入**——这是上一轮已经完成的优化项 #1。端到端验证已经过了：
- S2 输出用了标准关系（`FILE exposes API_ENDPOINT`）
- 时间戳真实（不再是假的 `T00:00`）
- skill 名正确（`hivemux` 不是 `tmux-web-terminal`）

**这不是"待办"，是"已完成"。我没看到上下文末尾的验证结论就推荐"重做"。**

### 错 3：我对 "SOP 1/2/3/4" 的理解

我以为是 4 个独立 SOP，所以去 jsonl 里搜 SOP2/SOP3/SOP4。**实际上你们的 SOP 是一个**——`knowledge-graph-sop/SKILL.md`（826 行三合一），分 Phase 0/1/2/3/4。**你说的"SOP 1234"应该是指 SOP 的几个 Phase**，不是四个独立文档。

---

## 我说"对但被我夸大优先级"的地方

### 偏差：我把 "S2 改 tool_use 强 schema" 列为 ⭐⭐⭐⭐⭐ 

实际上当前的 **prompt 注入 shared_schema** 已经端到端工作良好（验证通过，输出格式合规）。tool_use 边际收益是"绝对不会跑偏"的硬保证，但 prompt 模式实测已经够用。这条应该降到 ⭐⭐⭐（锦上添花，不是当务之急）。

---

## 我说对的地方（不变）

1. **实体去重 / fuzzy 匹配 = 真痛点** — S2 prompt 第 5 条规则只是"建议对齐已有实体名"，没强校验。这个保留 ⭐⭐⭐⭐⭐。
2. **validate.sh 缺图谱级检查** — 现在 7 项全是文件级（章节、空章节、增量区残留），没有跨文件的"边的两端实体存在性 / 共享实体注册表与 owner skill 一致性 / 关系名白名单"。保留 ⭐⭐⭐⭐。
3. **共享实体注册表自动维护** — 27 个共享实体是 SOP 1 一次性生成，新增萃取不会自动扩充。保留 ⭐⭐⭐。

---

## 上下文末尾还揭露了一个新问题（我之前没看到）

最后一段是另一个 sub-agent 在跑 `run.sh` 全流程，**11:07 启动 merge 后卡了 30 分钟，agent 在 11:42 自己重跑了一次**。说明 **run.sh 的 "一键" 至今没真正实现**。merge.sh 还有未修复的 bug：
- INDEX 更新阶段 claude -p 会卡住（之前发生过，这次又出现）
- 没有看门狗机制（卡住的 merge 不会自动 kill 重启）
- 主进程死等子进程

**这才是当前最该修的真问题**，比"接 Hermes 的 patch / Honcho user model"重要得多。

---

## 修正后的优先级建议

| 优先级 | 该做的事 | 原因 |
|---|---|---|
| ⭐⭐⭐⭐⭐ | **修 run.sh 卡死问题**：merge 加超时 watchdog + INDEX 更新单独超时 + 子进程失败兜底 | 真"一键"，不用每次手动救 |
| ⭐⭐⭐⭐⭐ | **实体去重 / fuzzy 匹配** | 张总图谱核心痛点，目前只有 prompt 引导 |
| ⭐⭐⭐⭐ | **validate.sh 加图谱级检查** | 跨文件一致性是张总要的"准确插入验证" |
| ⭐⭐⭐ | 共享实体注册表自动维护 | 让图谱关联性能持续生长 |
| 不要做 | ~~merge 改 patch 模式~~ | 已评估过质量不行 |
| 暂缓 | S2 改 tool_use | prompt 注入 schema 实测够用 |

---

--- [km-pipeline] [UPDATE] 环境重置：日志清空+tmp清理+last_ts回拨2小时 ---

[2026-04-16T03:51:09.484Z] [assistant] (session:d7c2d500)

```bash
BASE=~/Desktop/skill-knowledge-base
# 清理状态
> "$BASE/changelog.md"
> "$BASE/scripts/extract.log"
> "$BASE/scripts/merge.log"
> "$BASE/scripts/run.log"
rm -f "$BASE/tmp/changelog_"*.txt "$BASE/tmp/newskill_"*.txt
```

```python
from datetime import datetime, timedelta, timezone
ts = datetime.now(timezone.utc) - timedelta(hours=2)
print(ts.strftime('%Y-%m-%dT%H:%M:%S.000Z'))
# 写入 last_ts.txt（让 extract.sh 能捞到最近 2 小时的 JSONL）
```

---

--- [km-pipeline] [ADD] 启动SubAgent执行全流程run.sh（第三轮） ---

[2026-04-16T03:53:57.450Z] [assistant] (session:d7c2d500)

```
[tool:Agent {
  "description": "全流程执行",
  "prompt": "任务：执行知识图谱的一键全流程脚本 `bash ~/Desktop/skill-knowledge-base/scripts/run.sh`，跑完报告结果。
  不要做任何修复或优化——只负责执行和报告。目的是暴露一键流程的真实问题交给主 agent 处理。
  执行方式：用 Bash 工具的 run_in_background: true 启动脚本..."
}]
```