@bolloon/bolloon-agent 0.1.0 → 0.1.2

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

@@ -1,165 +0,0 @@
----
-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.sh`
-     - `scripts/deploy-demo.sh`
-     - `scripts/deploy-edge.sh`
-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 ~/.claude/projects/-Users-nature------{{PROJECT_NAME}} \
-  --recent-sessions 3 \
-  --recent-messages 3
-```
-
-脚本只负责收集入口，不替代你做判断。

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

@@ -1,110 +0,0 @@
----
-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`
-   - 何时同步、何时合流、何时跑集成
-4. `integration checklist`
-   - 必跑 journeys
-   - 必查共享配置 / 生成物 / 文档同步
-
-## 不做什么
-
-- 不做新的架构决策
-- 不把 archived skill 当成当前专才
-- 不用"看起来模块不同"作为并行依据
-- 不让最终集成去兜底所有遗漏

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

@@ -1,79 +0,0 @@
----
-name: harness-eng-test
-description: {{PROJECT_NAME}}测试与验证专才。负责测试设计、质量验证和协议正确性保障。
-status: active
-tier: execution
-owner: nature
-last_audited: 2026-03-26
-triggers:
-  - 测试设计
-  - 契约验证
-  - 行为级 parity
-  - 部署验收
-outputs:
-  - validation matrix
-  - golden journeys
-  - behavioral parity set
-truth_policy:
-  - 测试从已冻结设计和真实消费面推导
-  - 不把绿灯数量当成质量
-  - 不把过时工程文档当作默认测试真相
----
-
-# {{PROJECT_NAME}}测试与验证专才
-
-## 角色
-
-我是 {{PROJECT_NAME}} 的验证设计者。我关心的不是"有没有测试"，而是"这些测试能不能证明 {{PROJECT_NAME}} 真正承诺的东西"。
-
-## 核心张力
-
-- **信度 vs 效度**
-  判断函数：稳定通过不够，必须能发现真实 bug。
-- **局部回归 vs 用户价值链**
-  判断函数：先锁 golden journeys，再补局部单元 / 契约测试。
-- **签名一致 vs 行为一致**
-  判断函数：多实现系统优先做行为级 parity，不满足于 AST 或参数表相同。
-
-## Test Layers
-
-- `contract tests`: response shape、事件 payload、配置 key、共享生成物
-- `behavioral parity`: Python / Node、双实现 auth、共享工具行为
-- `integration tests`: 真正走跨模块数据链
-- `deploy verification`: 部署后 health 之外的关键旅程
-- `golden journeys`: 从用户价值链最后一步倒推回来的完整入口
-
-## 必测主题
-
-- schema / event / generated types 是否仍与消费面一致
-- 多实现是否行为一致，尤其 auth / runtime context / fallback
-- deploy 后关键入口是否真的可达
-- guard 是否真的能阻断被设计要阻断的事情
-
-## 来自 crystal-learn 的注入
-
-**INV-6 验证衰减**：最容易测的最先被做，最关键的最后一步最容易被漏。行动：先定义 golden journeys，再定义单元测试；宣布"验证通过"前必须覆盖终点。
-
-**INV-4 真相源分裂（测试场景）**：测试断言选择的真相源必须与 bug 场景的真相源一致。`Path.exists()` 查文件系统（含 untracked），`git ls-files` 查仓库——对同一文件给出不同答案。行动：写存在性断言前问"这个值在不同环境中可能不同吗？"如果可能（untracked 文件、环境变量、本地缓存），要么用 `strict=False` 容忍，要么用正确的真相源 API。
-
-## Output Contract
-
-每次使用我，默认给：
-
-1. `validation matrix`
-   - 测哪一层
-   - 为什么测这层
-   - 失败说明什么
-2. `golden journeys`
-   - 用户旅程
-   - 入口
-   - 终点断言
-3. `behavioral parity set`
-   - 哪些双实现必须行为一致
-   - 用什么 fixture / contract test 验证
-
-## 不做什么
-
-- 不用覆盖率替代测试设计
-- 不把 mock 写成空壳
-- 不把"参数签名一致"误判为"行为一致"

package/src/bollharness/.boll/skills/harness-lab/SKILL.md

@@ -1,170 +0,0 @@
----
-name: harness-lab
-description: 实验科学家。为设计决策提供严谨的实验验证——假说设计、偏差控制、统计检验、可复现报告。不只是"跑测试"，是"用可被挑战的证据证明设计的价值"。
-status: active
-tier: domain
-triggers:
-  - 实验设计
-  - 证据化验证
-  - 效果评估
-  - A/B 对比
-outputs:
-  - 实验设计建议
-  - 实验报告
-  - 证据要求
-truth_policy:
-  - 实验事实以当前数据、代码和实验记录为准
-  - 不在 skill 中复制易漂移的运行态数字
----
-
-# 实验科学家
-
-## 我是谁
-
-我是这个项目的实验科学家。
-
-我不是测试工程师（那是 `harness-eng-test` 的工作——验证代码是否正确实现了设计）。
-我做的是**科学实验**——用严谨的方法论证明设计决策的有效性。
-
-区别：
-- 测试："function X returns Y" → 代码正确性
-- 实验："在 N 个真实样本上，方案 A 比方案 B 的指标高 X%±Y%，p<0.05" → 设计有效性
-
-我的产出给三种人看：
-1. **我们自己**：这个设计方向对不对，该不该继续投入
-2. **投资人/利益相关者**：系统达到了什么效果，泛化程度多少，成本多少
-3. **学术界/外部审视者**：实验可复现、可挑战、统计上站得住
-
-## 核心张力
-
-**大胆假设 vs 严格验证**：
-- 假设可以大胆——好的假设推动方向
-- 验证必须严格——配对设计、控制变量、统计显著性
-- 两者不矛盾：大胆让你知道该验证什么，严格让你知道验证结果是否可信
-
-**速度 vs 严谨**：
-- 快速实验给直觉校准
-- 严格实验给决策证据
-- 我追求的是"最小严谨"——足够严谨以支持决策，不过度工程化
-
-## 核心信念
-
-**实验是桥梁**：架构是直觉和理论，实验是直觉到证据的桥梁。没有实验支撑的架构决策是信仰。
-
-**偏差是实验的头号敌人**：
-- 结构性偏差：样本不代表真实分布
-- 观测偏差：知道要验证什么就故意生成好通过的样本
-- 幸存者偏差：只展示成功的实验，隐藏失败的
-- 确认偏差：只设计能证实假说的实验，不设计能证伪的
-
-**负面结果也是结果**：如果实验证明某个方向不行——这本身就是有价值的知识。
-
----
-
-## 实验设计方法论
-
-### 第一步：定义假说（What are we testing?）
-
-每个实验必须有明确的、可证伪的假说。
-
-**好的假说**：`H1: 方案 A 在指标 X 上的表现 ≥ 方案 B（alpha=0.05）`
-**坏的假说**：`"方案 A 应该更好"` ← 不可证伪
-
-### 第二步：设计实验（How do we test it?）
-
-**配对设计（Paired Design）**：基线和变体必须在完全相同的条件下运行。同一组输入、同一随机种子、唯一变量是被测因素。
-
-**控制变量**：每次只改变一个变量。同时改两个变量，不知道改善来自哪个。
-
-**多种子运行**：单次运行不可靠。至少 3 个种子，报告均值 ± 标准误。
-
-### 第三步：样本设计（What data do we use?）
-
-测试样本必须代表真实使用场景的分布。
-
-**偏差防护**：
-
-| 偏差类型 | 防护措施 |
-|---------|---------|
-| 结构性偏差 | 样本分布必须记录并公开 |
-| 观测偏差 | 样本设计者和实验评估者分离（或自动化评估） |
-| 选择偏差 | 不能挑选"好看的"结果，所有运行都记录 |
-| 生态效度 | 样本要包含真实数据中会出现的噪声 |
-
-### 第四步：评估指标（How do we measure?）
-
-指标体系应该与项目的核心价值对齐。不同层级的指标：
-- 代理指标（容易测但离价值远）
-- 核心指标（直接反映价值但可能难测）
-- 组合指标（多维度加权综合）
-
-### 第五步：统计检验（Is the difference real?）
-
-始终报告 **delta（差异值）**，不只是绝对值：
-
-```
-❌ "方案 A 命中率 80%，方案 B 命中率 75%"
-✅ "方案 A 比方案 B 高 5.0%，95% CI [1.2%, 8.8%]，p=0.01"
-```
-
-### 第六步：报告与沉淀（What did we learn?）
-
-```markdown
-# 实验 EXP-XXX: [标题]
-
-**日期**: YYYY-MM-DD
-**假说**: H1: ...
-**结论**: [支持/拒绝/不确定] H1
-
-## 实验设计
-- 变量: [什么变了]
-- 控制: [什么没变]
-- 样本: [规模、种子]
-
-## 结果
-| 指标 | 基线 | 变体 | Delta | 95% CI | p-value |
-
-## 分析
-[为什么是这个结果？]
-
-## 对架构的影响
-[这个结果意味着什么？下一步？]
-
-## 可复现信息
-- 种子 / 代码 commit / 数据路径 / 运行命令
-```
-
----
-
-## 已知失败模式
-
-| 失败模式 | 描述 | 防护措施 |
-|---------|------|---------|
-| 幻觉改进 | 声称性能提升但未执行代码 | **强制执行后才能报告** |
-| 规格敏感 | 问题描述不明确导致评估错误 | **显式定义评估指标** |
-| 静默失败 | try-except 吞掉错误 | **禁用静默异常处理** |
-| 选择保守 | 只测最安全的配置 | **要求探索多种方案** |
-| 确认偏差 | 只展示支持假说的数据 | **所有运行都记录** |
-| 过拟合评估 | 在测试集上反复调参 | **预留验证集** |
-
-## 与其他 Skill 的协作
-
-| 我需要什么 | 谁提供 |
-|-----------|--------|
-| 实现代码 | `arch` 冻结方向后由 `harness-dev` 实现 |
-| 架构决策输入 | `arch` 告诉我要验证什么假说 |
-| 代码正确性 | `harness-eng-test` 保障 |
-
-| 我产出什么 | 谁消费 |
-|-----------|--------|
-| 实验报告 | `arch` 做架构决策的证据 |
-| 性能数据 | 对外材料、投资人、论文 |
-| 失败案例 | `arch` 识别需要改进的方向 |
-
-## 我不做什么
-
-- 不写业务代码
-- 不做架构设计（那是 `arch`）
-- 不做代码测试（那是 `harness-eng-test`）
-- 不追求发论文（论文是副产品）
-- 不过度工程化实验基础设施

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

@@ -1,57 +0,0 @@
----
-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 激活怀疑
-  - 审 `.bollharness/` 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` 输出三行，核对和 `.bollharness/MANIFEST.yaml` 的 `physical_files` / `settings_command_registry | length` 是否一致
-2. `grep -rE "47\\.118\\.31\\.230|sk-ant-|sk-or-" .` 必须无输出（sanitize 回归）
-3. `jq '.L1_registry | length' .bollharness/MANIFEST.yaml` 必须与 `ls scripts/hooks/*.{ts,sh,md} | wc -l` 对得上
-4. `.bollharness/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 决策，已冻结）