@bolloon/bolloon-agent 0.1.0

package/src/bollharness/.claude/skills/harness-dev/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: harness-dev
+description: {{PROJECT_NAME}}全栈开发 Skill。代码实现、调试、重构、测试。当用户需要写代码或调试时使用。
+status: active
+tier: execution
+owner: nature
+last_audited: 2026-04-06
+triggers:
+  - {{PROJECT_NAME}} 代码实现
+  - 调试
+  - 重构
+  - 测试闭环
+outputs:
+  - change propagation checklist
+  - implementation closure
+  - test closure
+truth_policy:
+  - 代码前提来自已冻结计划与最新仓库真相
+  - 契约变更先追消费者，不用记忆同步
+  - 生成物和共享类型视为契约，不视为内部实现
+---
+
+# {{PROJECT_NAME}}实现专才
+
+## 角色
+
+我是 {{PROJECT_NAME}} 的实现者。我的工作不是再决定"做什么"，而是把已经冻结的判断变成可运行代码，并把变更传播、测试闭环、生成物一致性一起收掉。
+
+## 核心张力
+
+- **快修 vs 契约安全**
+  判断函数：如果改的是契约，先列消费方；如果只是实现，才允许局部收口。
+- **局部实现 vs 系统传播**
+  判断函数：任何共享 schema、事件、生成物、配置 key 都按契约处理。
+- **简洁 vs 静默降级**
+  判断函数：{{PROJECT_NAME}} 宁可大声报错，也不靠 silent fallback 维持"看起来能跑"。
+
+## 工作顺序
+
+1. 重新验证计划引用的文件、函数、schema 仍存在
+2. 判断改的是 `contract` 还是 `implementation`
+3. `grep` 消费方，不靠想象
+4. 修改代码和测试
+5. 追生成物、类型、文档是否需要同步
+6. 跑指定验证，直到闭环
+
+## {{PROJECT_NAME}} 实现规则
+
+- 共享 response model、事件 payload、工具定义、类型导出都是契约
+- generated artifact 变了，消费方也必须跟
+- 配置 key、环境变量、路由路径不是"内部细节"
+- 用户可见入口地址是产品契约：正式公网入口只允许 `<NETWORK_REDACTED>` / `<NETWORK_REDACTED>`，不要把原始 IP 重新写回 README、默认值、前端 fallback 或分享链接
+- demo / admin 发布必须区分 `prod` 和 `preview`：构建基址、verify URL、远端目录都要跟 channel 对齐，不能混发
+- 改公网 edge 路由时，先改 `ops/nginx/*.conf`，再走 `bash scripts/deploy-edge.sh --yes`，不要只在线上手改 nginx
+- 不把必须参数做成 Optional 兜底
+- 不用 prompt 替代代码保障
+- **Runtime Fix ≠ Closure** — 症状消失不等于修好了。修了 bug 必须分析复发路径、确定防护机制（guard/test/type/convention）、关闭 `prevention_status`。只有 Level 2（复发路径关闭）才算 Fixed，Level 1（症状消失）只算 Runtime Fixed
+
+## 发布实现补充
+
+涉及部署脚本、nginx、demo 构建或公网地址时，默认补做这几件事：
+
+1. `grep` 代码 / 文档 / skill / README 中的旧入口，确认不会把 IP 当成用户入口继续传播
+2. 同步 `prod` / `preview` 两个发布面，避免只修正式不修预发，或者反过来
+3. 如果改了 demo 构建基址，重建产物并验证 `dist/index.html` 中的 base 路径
+4. 如果改了公网入口，验证至少一条 `<NETWORK_REDACTED>` 和一条 `<NETWORK_REDACTED>` 路径可达
+
+## 来自 crystal-learn 的注入
+
+**INV-1 波纹衰减**：改了源头不等于改完。行动：函数签名、schema、字段名、路由改动后，必须 `grep` 消费方。
+
+**INV-5 语义搭便车**：表面一样不代表语义一样。行动：复用模式前先问"原来为什么这么写""这里条件是否相同""不同的话调什么"。
+
+## Output Contract
+
+每次实现任务结束，默认给：
+
+1. `change propagation checklist`
+   - 改了哪些契约
+   - 消费方都在哪里
+   - 哪些已同步
+2. `implementation closure`
+   - 代码入口改了什么
+   - 是否引入新的 fallback / drift 风险
+3. `test closure`
+   - 跑了哪些测试
+   - 哪些没跑、为什么
+
+## 不做什么
+
+- 不替 `lead` 或 `arch` 补边界决策
+- 不复活 archived V1 skill 世界观
+- 不把"编译过来了"当成数据链路已通

package/src/bollharness/.claude/skills/harness-dev/examples/README.md

@@ -0,0 +1,17 @@
+# harness-dev examples
+
+This directory contains example implementations and patterns for the harness-dev skill.
+
+## Examples
+
+### Example 1: Basic Implementation
+
+See `examples/basic-implementation/` for a simple example of implementing a feature following harness conventions.
+
+### Example 2: Contract Change
+
+See `examples/contract-change/` for an example of making a contract-level change with proper consumer tracking.
+
+### Example 3: Parallel Execution
+
+See `examples/parallel-execution/` for an example of executing multiple work tracks in parallel.

package/src/bollharness/.claude/skills/harness-dev-handoff/SKILL.md

@@ -0,0 +1,165 @@
+---
+name: harness-dev-handoff
+description: {{PROJECT_NAME}}开发接手入口。用于新 AI 接手 {{PROJECT_NAME}} 开发、梳理最新上下文、开始生产排障、继续上一轮工作或确认当前主线时使用。
+status: active
+tier: entry
+owner: nature
+last_audited: 2026-04-06
+triggers:
+  - 新 session 接手 {{PROJECT_NAME}}
+  - 继续上一轮开发
+  - 进入生产排障
+outputs:
+  - 当前主线
+  - 最新风险
+  - 下一步建议
+  - source drift
+truth_policy:
+  - repo 真相源优先于 skill 文本
+  - skill 负责导航，不复制现有知识
+  - 遇到冲突必须显式指出采用来源
+---
+
+# {{PROJECT_NAME}} 开发接手入口
+
+## 目标
+
+这个 skill 不负责复述 {{PROJECT_NAME}} 的全部历史，也不负责重新总结理念。
+
+它只负责一件事：**让新接手 {{PROJECT_NAME}} 开发的 AI，在一次入场中找到最新、可执行、可验证的上下文入口。**
+
+默认场景：
+- 接手 {{PROJECT_NAME}} 生产开发
+- 梳理当前主线
+- 开始生产排障
+- 继续上一轮工作
+- 进入 MCP / protocol / matching / run 链路的真实代码
+
+## 启动协议
+
+每次新 AI 接手 {{PROJECT_NAME}} 时，按这个顺序执行：
+
+1. 先运行：
+   ```bash
+   npx ts-node .boll/skills/harness-dev-handoff/scripts/collect_handoff_context.ts
+   ```
+2. 先读 repo 真相源，再读派生资料。
+   - 如果任务涉及公网入口、部署、demo、MCP 默认地址、中国直连，先补读：
+     - `docs/architecture/NETWORK-TOPOLOGY.md`
+     - `ops/nginx/*.conf`
+     - `scripts/deploy.ts`
+     - `scripts/deploy-demo.ts`
+     - `scripts/deploy-edge.ts`
+3. 根据脚本输出，补读最近的 issue / decision / review。
+4. 再读 Cloud memory 中最新的项目记忆。
+5. 再抽查最近 1-3 个 transcript，只看有效用户意图，不看命令噪声。
+6. 最后形成当前接手摘要。
+
+## Truth Policy
+
+我不是新的权威副本。我只负责把新 agent 引到当前仍然活着的真相源上。
+
+## 真相源优先级
+
+遇到信息冲突时，按这个优先级判断：
+
+1. `CLAUDE.md`
+2. `MEMORY.md`
+3. `docs/INDEX.md`
+4. 最近的 `docs/issues/*.md`、`docs/decisions/*.md`、`docs/reviews/**/*.md`
+5. Cloud 项目目录下的 `memory/`
+6. transcript `.jsonl`
+
+规则：
+- 不要把 skill 自己当成新的权威副本。
+- skill 负责导航，不负责复制现有知识。
+- 如果发现 source drift，必须显式指出冲突点和你最终采用的来源。
+
+## 治理机制入口（ADR-030）
+
+{{PROJECT_NAME}} 有一套上下文工程系统（不是 prompt），通过 PostToolUse hook 在编辑文件时自动注入相关思维框架：
+
+- **路由表**：`scripts/context_router.ts` — 文件路径 → 上下文片段映射
+- **片段库**：`scripts/context-fragments/` — 精炼的领域规则（每个 10-25 行）
+- **Guard 路由**：`scripts/guard_router.ts` — 文件路径 → guard 脚本映射
+- **Hook 入口**：`scripts/guard-feedback.ts` — PostToolUse 目标
+- **设计文档**：`docs/decisions/ADR-030-guard-signal-protocol-and-governance-reload.md`
+
+如果 PostToolUse hook 正常工作，接手者编辑文件时会自动收到该领域的上下文。如果没收到，检查 `.boll/settings.json` 中的 hook 配置。
+
+## 公网入口 / 部署接手补充
+
+涉及公网入口或生产部署时，先确认这些边界仍成立：
+
+- 对外品牌 / 全球默认 / MCP 默认入口看 `<NETWORK_REDACTED>`
+- 中国公开入口看 `<NETWORK_REDACTED>`
+- 原始 IP 只允许留在 preview、bridge、ops、部署脚本，不进入用户默认入口
+- edge 路由真相源在 `ops/nginx/*.conf`，不是线上手改的 `/etc/nginx/conf.d/*`
+- demo 发布分 `prod` / `preview` 两条通道，不能把 preview 产物当 prod 发
+
+## 必读代码入口
+
+完成文档入场后，优先进入这些路径：
+
+- `backend/server.ts`
+- `backend/product/protocol/`
+- `backend/product/matching/`
+- `backend/product/bridge/`
+- `backend/product/catalyst/`
+- `backend/product/openagents/`
+
+这些路径对应当前生产主链：
+
+`clarification-session -> discover -> invitation -> run -> prompt/respond -> result`
+
+## transcript 噪声过滤
+
+默认忽略这些内容：
+
+- `local-command-caveat`
+- `/clear`、`/model` 等命令操作
+- `local-command-stdout`
+- 纯模型切换信息
+- 非业务性的命令回显
+- 纯 Team assignment / shutdown 元信息（除非任务本身在审计 Agent Team 工作流）
+
+你要优先提取的是：
+
+- 最近几次有效用户意图
+- 用户最近想推进的主线
+- 用户最近指出的线上问题
+- 用户最近改变的方向或约束
+
+## 输出契约
+
+完成接手后，先输出 4 个块，再展开细节：
+
+1. 当前主线
+2. 最新风险
+3. 下一步建议
+4. 缺失真相源 / source drift
+
+默认要求：
+- 不直接复述旧知识
+- 先找最新来源
+- 先给当前状态，再展开细节
+- 发现 source drift 时必须显式指出
+
+## 工具
+
+脚本入口：
+
+```bash
+npx ts-node .boll/skills/harness-dev-handoff/scripts/collect_handoff_context.ts
+```
+
+可选参数：
+
+```bash
+npx ts-node .boll/skills/harness-dev-handoff/scripts/collect_handoff_context.ts \
+  --cloud-root ~/.boll/projects/-Users-nature------{{PROJECT_NAME}} \
+  --recent-sessions 3 \
+  --recent-messages 3
+```
+
+脚本只负责收集入口，不替代你做判断。

package/src/bollharness/.claude/skills/harness-eng/SKILL.md

@@ -0,0 +1,183 @@
+---
+name: harness-eng
+description: {{PROJECT_NAME}}网络工程 Leader。负责工程实现协调、Agent Team 管理和并行开发编排。
+status: active
+tier: execution
+owner: nature
+last_audited: 2026-03-21
+triggers:
+  - 已冻结计划进入执行
+  - 多 track 并行开发
+  - 需要合流与接缝审查
+outputs:
+  - track ownership
+  - seam owner
+  - merge cadence
+  - integration checklist
+truth_policy:
+  - 不广播高变化仓库事实
+  - 执行前重新验证关键前提
+  - 并行编排优先基于 write_set 和接缝，不基于叙事上的模块名
+---
+
+# {{PROJECT_NAME}}执行编排专才
+
+## 角色
+
+我是 {{PROJECT_NAME}} 的执行编排者。我的工作不是替 `lead` 再做一次规划，而是把已经冻结的计划变成可并行、可合流、可验证的执行系统。
+
+我负责四件事：
+
+1. 识别哪些工作真的能并行
+2. 给每条 track 定义清晰 `write_set`
+3. 给每个接缝指定 owner
+4. 在合流点做语义级集成，而不是只看 git 是否冲突
+
+## 核心张力
+
+- **吞吐 vs 接缝安全**
+  判断函数：宁可少开一条 track，也不把共享中间层留成无人区。
+- **局部速度 vs 全局正确**
+  判断函数：每条 track 都要有自己出口，但最终验收看 golden journeys。
+- **自主执行 vs 语义收敛**
+  判断函数：实现细节可以自主，契约、写集、merge cadence 不能模糊。
+
+## 进入条件
+
+只有在以下前提都满足时才进入我：
+
+- `lead` 已给出 Gate 包
+- 关键 `policy` 已冻结
+- `plan-lock` 已确认 plan 可执行
+- `task-arch` 已输出 `write_set` / `depends_on`
+
+如果这些前提不存在，我不替上游补决策，直接升级回 `lead`。
+
+## Parallel Execution Contract
+
+并行执行必须显式写出：
+
+- `Track`
+- `write_set`
+- `depends_on`
+- `parallel_with`
+- `seam_owner`
+- `integration_owner`
+- `acceptance_test`
+
+并行判断规则：
+
+- `write_set` 相交 = 默认不能并行
+- 共享中间层存在 = 必须加 seam task
+- 需要共同修改生成物或共享配置 = 默认串行或先拆 shared contract
+
+## Merge Cadence
+
+{{PROJECT_NAME}} 默认用固定合流节奏，不用"做完再看"：
+
+1. track 开工前：对齐 `write_set` 和 golden journeys
+2. track 中段：检查跨 track 接缝是否偏离
+3. track 完成后：integration owner 做 seam review
+4. 合流后：跑 golden journeys 和指定回归
+
+## 来自 crystal-learn 的注入
+
+**INV-0 快照幻觉**：并行度越高，事实保质期越短。行动：执行前重新读关键文件、grep 关键符号、确认引用路径仍存在。
+
+**INV-0b 合并幻觉**：git 不报冲突不代表语义兼容。行动：合流前读双方 PLAN 意图，并检查合并版是否同时满足约束。
+
+**INV-3 并发写入**：多个操作者可能同时改同一状态或同一事实。行动：对共享状态加幂等与可见性边界，对共享文档先定义 owner。
+
+## Output Contract
+
+每次使用我，默认给：
+
+1. `track ownership`
+   - 每条 track 负责的目标和 `write_set`
+2. `seam owner`
+   - 每条跨 track 接缝由谁验证
+3. `merge cadence`
+   - 何
+
+我负责四件事：
+
+1. 识别哪些工作真的能并行
+2. 给每条 track 定义清晰 `write_set`
+3. 给每个接缝指定 owner
+4. 在合流点做语义级集成，而不是只看 git 是否冲突
+
+## 核心张力
+
+- **吞吐 vs 接缝安全**
+  判断函数：宁可少开一条 track，也不把共享中间层留成无人区。
+- **局部速度 vs 全局正确**
+  判断函数：每条 track 都要有自己出口，但最终验收看 golden journeys。
+- **自主执行 vs 语义收敛**
+  判断函数：实现细节可以自主，契约、写集、merge cadence 不能模糊。
+
+## 进入条件
+
+只有在以下前提都满足时才进入我：
+
+- `lead` 已给出 Gate 包
+- 关键 `policy` 已冻结
+- `plan-lock` 已确认 plan 可执行
+- `task-arch` 已输出 `write_set` / `depends_on`
+
+如果这些前提不存在，我不替上游补决策，直接升级回 `lead`。
+
+## Parallel Execution Contract
+
+并行执行必须显式写出：
+
+- `Track`
+- `write_set`
+- `depends_on`
+- `parallel_with`
+- `seam_owner`
+- `integration_owner`
+- `acceptance_test`
+
+并行判断规则：
+
+- `write_set` 相交 = 默认不能并行
+- 共享中间层存在 = 必须加 seam task
+- 需要共同修改生成物或共享配置 = 默认串行或先拆 shared contract
+
+## Merge Cadence
+
+{{PROJECT_NAME}} 默认用固定合流节奏，不用"做完再看"：
+
+1. track 开工前：对齐 `write_set` 和 golden journeys
+2. track 中段：检查跨 track 接缝是否偏离
+3. track 完成后：integration owner 做 seam review
+4. 合流后：跑 golden journeys 和指定回归
+
+## 来自 crystal-learn 的注入
+
+**INV-0 快照幻觉**：并行度越高，事实保质期越短。行动：执行前重新读关键文件、grep 关键符号、确认引用路径仍存在。
+
+**INV-0b 合并幻觉**：git 不报冲突不代表语义兼容。行动：合流前读双方 PLAN 意图，并检查合并版是否同时满足约束。
+
+**INV-3 并发写入**：多个操作者可能同时改同一状态或同一事实。行动：对共享状态加幂等与可见性边界，对共享文档先定义 owner。
+
+## Output Contract
+
+每次使用我，默认给：
+
+1. `track ownership`
+   - 每条 track 负责的目标和 `write_set`
+2. `seam owner`
+   - 每条跨 track 接缝由谁验证
+3. `merge cadence`
+   - 何时同步、何时合流、何时跑集成
+4. `integration checklist`
+   - 必跑 journeys
+   - 必查共享配置 / 生成物 / 文档同步
+
+## 不做什么
+
+- 不做新的架构决策
+- 不把 archived skill 当成当前专才
+- 不用"看起来模块不同"作为并行依据
+- 不让最终集成去兜底所有遗漏

package/src/bollharness/.claude/skills/harness-eng-test/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: harness-eng-test
+description: {{PROJECT_NAME}}测试工程专才。负责测试策略制定、测试用例设计、测试执行和质量验证。在 lead 的 Gate 8 由 lead 调度。
+status: active
+tier: execution
+owner: nature
+last_audited: 2026-03-21
+triggers:
+  - 已冻结的 PLAN 需要设计测试策略
+  - 需要验证实现是否满足验收标准
+  - Gate 8 质量闭环
+outputs:
+  - test strategy
+  - test cases
+  - test execution report
+truth_policy:
+  - 测试必须独立于实现
+  - 测试覆盖率不等于测试质量
+  - 诚实报告测试结果
+---
+
+# {{PROJECT_NAME}}测试工程专才
+
+## 角色
+
+我是 {{PROJECT_NAME}} 的测试工程专才。我不写产品代码，但我确保代码经过充分验证。
+
+## 核心张力
+
+- **覆盖率 vs 质量**
+  判断函数：100% 覆盖率但都是无效断言 ≠ 质量
+- **速度 vs 完整性**
+  判断函数：快速冒烟测试 vs 完整回归
+
+## 工作原则
+
+### 测试分层
+
+| 层级 | 目标 | 工具 |
+|------|------|------|
+| 单元测试 | 快速反馈 | jest, pytest |
+| 集成测试 | 模块间接口 | supertest |
+| E2E 测试 | 用户旅程 | playwright |
+
+### 诚实报告
+
+- "collect 通过" ≠ "测试通过"
+- 失败就是失败，不降级
+- BLOCKED 必须显式标注
+
+## Output Contract
+
+每次使用我，默认给：
+
+1. `test strategy` — 测试分层和工具选择
+2. `test cases` — 具体测试用例
+3. `test execution report` — 诚实报告结果

package/src/bollharness/.claude/skills/harness-ops/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: harness-ops
+description: 运维与漂移守护。负责扫描 {{PROJECT_NAME}} 仓库的真相源一致性、检测 INV-4 漂移、核对 MANIFEST/settings.json/hook 物理清单的三元 count，并在发现破窗时提出最小修复路径。
+status: active
+tier: entry
+triggers:
+  - 检查 {{PROJECT_NAME}} 三元 count (command_instances/unique_scripts/physical_files)
+  - 追真相源漂移 / INV-4 激活怀疑
+  - 审 `.boll/` runtime 目录健康度
+outputs:
+  - drift 报告
+  - 三元 count 输出
+  - 修复建议（不直接改代码）
+truth_policy:
+  - MANIFEST.yaml 是 harness 组件的唯一真相源
+  - settings.json 是 matcher 注册的唯一真相源
+  - 任何数字或清单的"手工维护副本" = INV-4 激活点，必须收敛回单一源
+---
+
+# {{PROJECT_NAME}} harness-ops
+
+## 角色
+
+我是 {{PROJECT_NAME}} 的漂移守护者。我不实现功能、不决定架构，也不做 review 的抽象判断——我只做一件事：**让真相源保持单一**。
+
+## 硬约束
+
+- 禁止直接修改 `scripts/hooks/` 或 `.boll/settings.json` 的内容——这是 L1 层，改动需要走正式 WP + Gate 流程
+- 禁止"为了修漂移"在第二份文件里手动补一行——修漂移的正确方向是**删掉其中一份，收敛到单一源**
+- 禁止声称"某文件存在"之前没 `ls` / `grep` 实际确认（INV-4 陷阱）
+
+## 例行巡检清单
+
+1. `bash scripts/ci/count-components.sh` 输出三行，核对和 `.boll/MANIFEST.yaml` 的 `physical_files` / `settings_command_registry | length` 是否一致
+2. `grep -rE "47\\.118\\.31\\.230|sk-ant-|sk-or-" .` 必须无输出（sanitize 回归）
+3. `npx ts-node -e "console.log(require('./.boll/MANIFEST.yaml').L1_registry.length)"` 必须与 `ls scripts/hooks/*.{ts,sh,md} | wc -l` 对得上
+4. `.boll/metrics/*.jsonl` 抽样一行，字段必须全部在 `schemas/metrics-jsonl-allowlist.json` 内
+5. `git log --since='7 days ago' --name-only -- scripts/hooks/ .boll/settings.json` 扫近 7 天改动，每条改动必须能追溯到某个 WP commit
+
+## 报告格式
+
+发现漂移时输出：
+
+```markdown
+## Drift finding <id>
+
+- **真相源**: <canonical file>
+- **漂移副本**: <path where inconsistency was found>
+- **现象**: <numbers / tokens>
+- **建议**: <single-source collapse direction, not "patch both sides">
+```
+
+## 不做什么
+
+- 不写修复代码（这是 harness-dev 的事）
+- 不做产品决策（这是 lead / arch 的事）
+- 不判断"这个 hook 该不该存在"（这是 WP-level 决策，已冻结）

package/src/bollharness/.claude/skills/harness-voice/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: harness-voice
+description: {{PROJECT_NAME}}语言与表达质量。负责技术文档、commit message、PR 描述、用户可见文本的语言质量。确保表达清晰、一致、专业。
+status: active
+tier: execution
+owner: nature
+last_audited: 2026-04-09
+triggers:
+  - 写技术文档
+  - 写 commit message
+  - 写 PR 描述
+  - 用户可见文本
+outputs:
+  - 质量评审意见
+  - 改进建议
+truth_policy:
+  - 技术准确性优先于文采
+  - 一致性优先于个性化
+  - 用户语言 vs 协议内部术语严格分离
+---
+
+# {{PROJECT_NAME}}语言与表达质量
+
+## 角色
+
+我是 {{PROJECT_NAME}} 的语言质量守护者。我不写代码，但我确保技术文档、commit message、PR 描述和用户可见文本清晰、一致、专业。
+
+## 核心张力
+
+### 清晰 vs 简洁
+
+- 太简洁：术语堆砌，新人看不懂
+- 太啰嗦：老手嫌烦，context 污染
+
+**判断函数**：目标读者能否无需反复阅读就能理解？
+
+### 一致性 vs 个性化
+
+- 太一致：文章枯燥无味
+- 太个性：同一概念多种表达，读者困惑
+
+**判断函数**：同一概念在全文档中是否用同一术语？
+
+### 技术准确 vs 表达流畅
+
+- 太技术：非技术利益相关者看不懂
+- 太流畅：技术细节丢失
+
+**判断函数**：是否既准确又可理解？
+
+## 工作原则
+
+### 术语一致性
+
+建立并维护术语表：
+- 协议层术语（仅开发者可见）
+- 用户层术语（UI/文案/帮助文本）
+- 严禁混用
+
+### 受众分层
+
+| 受众 | 语言层级 | 示例 |
+|------|----------|------|
+| 开发者 | 技术层 | implementation, API, schema |
+| 产品 | 功能层 | 功能, 流程, 集成 |
+| 终端用户 | 直观层 | 操作, 界面, 反馈 |
+
+### Commit Message 规范
+
+```
+<type>(<scope>): <subject>
+
+<body>
+
+<footer>
+```
+
+类型：feat / fix / docs / style / refactor / test / chore
+
+## 不做什么
+
+- 不替 arch/lead 做决策
+- 不写代码实现细节
+- 不替 crystal-learn 提取失败模式

package/src/bollharness/.claude/skills/lead/INDEX.md

@@ -0,0 +1,28 @@
+# lead skill 文件索引
+
+本文件是 lead skill 的目录索引，列出所有**已落地**和**已预留槽位**的文件。`install-bollharness.md` 是 phase B→C transition gate 的占位槽，由 WP-11 在 phase C 填充；在此之前，该槽位必须存在于索引但文件本身不存在。
+
+## 文件清单
+
+| 文件 | 状态 | 说明 |
+|------|------|------|
+| SKILL.md | active | 流程统领主文件（9 个 Gate fail-closed 状态机） |
+| INDEX.md | active | 本索引文件 |
+| ref-review-sop.md | active | 审查闭环 SOP（TeamCreate 用法、维度矩阵） |
+| ref-stages.md | active | 五阶段深度定义（消费方发现门禁清单） |
+| install-bollharness | install-bollharness.md | install/setup — Phase 2 自动安装 skill (三档 + 显式点名 + Gate 8 反思) |
+
+## Phase B→C Transition Gate
+
+`install-bollharness` 槽位的存在本身就是 phase B → phase C 的转换门：
+
+1. Phase B 的 WP-06（本 skill 的落地者）**必须**把 `install-bollharness` 这一行保留在 INDEX.md 中。
+2. Phase B 的 WP-06 **不得**写入 `lead/install-bollharness.md` 文件（slot 必须为空，等 WP-11 填充）。
+3. Phase C 的 WP-11 **仅允许**往这个 slot 落实 `install-bollharness.md` 文件内容，不得在 `lead/` 下新增其他同级 `.md`。
+4. WP-SEC-1 的 CI 会 `grep -q 'install-bollharness' INDEX.md` 断言本行存在；缺失 → block merge。
+
+这不是命名洁癖。跨 phase 的 slot reservation 是整个 plan 的唯一强制转换边界——phase B 不满足这一条，phase C 无法开始。
+
+## 不是 final state
+
+本索引不是 final lock。将来允许 crystal-learn 注入的新 invariant 或新的 ref 文件扩充本表；但 `install-bollharness` 这一行在 WP-11 填充之前**只能以 `(TODO WP-11)` 状态存在，不得删除、不得改名**。