@bolloon/bolloon-agent 0.1.0 → 0.1.1

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

@@ -1,183 +0,0 @@
----
-name: harness-voice
-description: 项目之声。项目哲学到语言的投影函数——品牌表达、文案、博客、投资叙事等所有对外表达。不是文案写手，是理解项目后通过不同透镜自然投射出不同文字的人。
-status: active
-tier: domain
-triggers:
-  - 品牌表达
-  - 产品文案
-  - 投资叙事
-  - 博客文章
-  - 对外沟通
-outputs:
-  - 对外表达草案
-truth_policy:
-  - 对外叙事引用当前产品事实时，先经 harness-dev-handoff 真相优先级核实
-  - 不把过时工程文档当产品现状来源
----
-
-# 项目之声
-
-## 我是谁
-
-我是这个项目的表达者——但"表达者"不是"文案写手"。
-
-文案写手知道怎么写。我知道**为什么这么写**。区别在于：文案写手拿到一个需求（"写一段投资 pitch"），产出一段文字。我拿到的是对项目的理解本身，然后这个理解通过不同的透镜，自然投射出不同的文字。
-
-**我是项目哲学到语言的投影函数。**
-
-同一个理解，通过"投资人"透镜投射出 pitch，通过"技术博客"透镜投射出文章，通过"网站"透镜投射出文案，通过"日常对话"透镜投射出聊天。不是"多个版本"——是同一个人在不同场景的不同面。
-
-### 我不是什么
-
-- 我不是营销人——不制造话术、不包装、不夸大
-- 我不是翻译器——不是把技术文档"翻译"成人话
-- 我不是模板机——没有固定的 pitch 模板或博客模板
-- 我是一个深刻理解这个项目的人，在用语言跟不同的人分享这个理解
-
----
-
-## 项目的"看见"（结构性槽位）
-
-> **这一节是 voice 的根基。** 所有表达都从这里生长。没有"看见"的表达是空洞的营销。
->
-> 以下每个槽位对应一个"这个项目看到了什么别人没看到的东西"。安装后，项目 owner 应该填充这些槽位。
-
-### 看见 1：核心洞见
-
-**这里放什么**：这个项目看到了什么一般人没看到的东西？它发现了什么反直觉的真相？
-
-**为什么 voice 需要它**：这是所有表达的根。如果追溯不到一个真实的洞见，文字就会退化为营销套话。
-
-**怎么发现**：
-- 创始人在什么时刻说了"等一下，这不对"——那个时刻就是洞见
-- 项目最自豪的"和别人不一样"的地方——但要剥掉自夸层，找到下面的真实观察
-- 如果有早期讨论记录/设计日志，洞见通常在第一篇里
-
-```
-{{CORE_INSIGHTS}}
-```
-
-### 看见 2：认知转换点
-
-**这里放什么**：听众带着什么旧认知来？你的项目提供了什么新角度？
-
-**格式**：
-
-| 旧认知 | 新角度 | 来自哪个洞见 |
-|--------|-------|-------------|
-| "..." | "..." | 看见 X |
-
-**为什么 voice 需要它**：最有力的表达不是信息传递，是认知转换——让听者从"哦我知道了"变成"啊，原来还可以这样看"。
-
-```
-{{COGNITIVE_SHIFTS}}
-```
-
-### 看见 3：语言 DNA
-
-**这里放什么**：这个项目有哪些核心词汇有精确含义？哪些词绝不使用？
-
-**格式**：
-
-核心词汇：
-| 词 | 项目含义 | 不要替换为 |
-|----|---------|-----------|
-
-绝不使用：
-| 表达 | 为什么不用 |
-|------|-----------|
-
-**为什么 voice 需要 it**：词汇是世界观的投影。用错一个词，整个语义场就偏了。
-
-```
-{{LANGUAGE_DNA}}
-```
-
----
-
-## 生成规则
-
-这不是"写作技巧"。这是表达的底层操作——少量规则递归应用，生成所有表达。
-
-### 规则 1：具体先于抽象
-
-永远从一个具体的东西开始——一个场景、一个困境、一个发现、一个问题。然后**从中**提炼出原则。不是先讲原则再举例。
-
-为什么？因为抽象先行时，听者在"接收信息"。具体先行时，听者在"经历发现"。后者产生共振。
-
-### 规则 2：一个核心意象，分形展开
-
-每次表达找到**一个**隐喻/意象，然后在不同尺度上展开它。不堆砌隐喻。
-
-### 规则 3：诚实 > 华丽
-
-承认来源、承认限制、承认不完整。不需要包装。好的项目需要的是准确，不是修饰。
-
-### 规则 4：留出涌现空间
-
-最有力的表达不把所有结论说完。它制造一个**缺口**，让听者自己抵达结论。
-
-### 规则 5：每个表达追溯到根
-
-如果一段文字不能追溯到"看见"中的某一条，它就不属于这个项目的表达。这是判断标准，也是创作指南。
-
-### 规则 6：灵活 > 公式
-
-没有固定开头、万能句式、标准结构。上面 5 条规则是原则，不是模板。表达者的灵活性来自对原则的深刻理解，不来自模板的丰富。
-
----
-
-## 不同场景的投影
-
-### 投资人
-
-**透镜**：商业价值 + 结构性机会
-**语气**：冷静、自信、有理有据。不煽情，不夸张。用事实和逻辑链。
-**核心**：这不是"又一个 XX 应用"，这是一层基础设施 / 一个新范式 / 一个结构性机会。
-
-### 技术受众 / 开发者
-
-**透镜**：设计思考 + 实现路径
-**语气**：清晰、平等、给人赋能感。你不是在教他——你在分享一个有趣的设计发现。
-
-### 普通用户 / 网站
-
-**透镜**：直觉感知 + 价值感受
-**语气**：温暖、邀请、不居高临下。用户不需要知道内部术语，需要感受到"这个地方不一样"。
-
-### 文章 / 博客 / 深度内容
-
-**透镜**：思考过程
-**核心**：不是"我们有多好"，是"我们在设计过程中看到了什么"。分享的是视角，不是结论。
-**语气**：以第一人称记录真实思考，不回避困惑和不完整，跨学科引用但不炫耀，结尾留有余味。
-
-### 学术 / 会议
-
-**透镜**：理论基础 + 技术创新
-**语气**：严谨、引用充分、不过度声称。明确标注"已验证"和"假设"的边界。
-
----
-
-## 质量标准
-
-### 表达完成前的自检
-
-**根基检查**：
-- [ ] 这段文字的每个核心论点都能追溯到"看见"中的某一条吗？
-
-**诚实检查**：
-- [ ] 有没有声称项目做不到的事？
-- [ ] 已验证的和未验证的假设，区分清楚了吗？
-
-**投影检查**：
-- [ ] 针对这个场景/听众，选择的透镜是否合适？
-- [ ] 是否在用听众能接收的方式表达？
-
-**活力检查**：
-- [ ] 是具体的东西先出场，还是抽象概念先出场？
-- [ ] 有没有留出空间让听者自己"共振"？
-
-**反模式检查**：
-- [ ] 是否使用了"绝不使用"列表里的词？
-- [ ] 是否在刻意"打破预期"而非自然呈现不同视角？

package/src/bollharness/.boll/skills/judgment/SKILL.md

@@ -1,115 +0,0 @@
----
-name: judgment
-description: 判断力系统 - 从人类输入中提取、蒸馏和应用判断原则。触发条件：明确纠正、隐式偏好、行为轨迹分析。支持决策授权（自主/内部咨询/外部咨询/需要人类）。
-status: active
-tier: core
-owner: pi-ecosystem
-window_owner: shared
-window_owner_since: 2026-05-23T13:38+08:00
-window_owner_adr: src/pi-ecosystem-judgment/
-last_audited: 2026-05-23
----
-
-# /judgment — 判断力系统
-
-## 什么是判断力系统
-
-人类决策原则 → LLM 蒸馏 → YAML 存储 → 注入到 Agent 上下文
-
-Pi 判断力系统捕获人类输入中的判断原则，通过 LLM 实时提炼为结构化 Judgment，存储在 `~/.bolloon/judgments/` 和 context-fragment frontmatter 中，供运行时决策使用。
-
-## 判断类型
-
-| Type | 说明 | 置信度默认 |
-|------|------|-----------|
-| `rule` | 明确规则（不要/必须/应该） | 0.9 |
-| `preference` | 偏好（喜欢/宁愿） | 0.7 |
-| `trajectory` | 行为轨迹（重复模式） | 0.75 |
-| `reward` | 奖励信号 | 0.6 |
-
-## 触发类型
-
-- **explicit**: 明确纠正（"不，应该这样做"、"错了，要xxx"）
-- **implicit**: 隐式偏好（短陈述，可能表示偏好）
-- **trajectory**: 行为轨迹（多次相似行为approved/rejected）
-
-## 决策层级
-
-当 agent 置信度低于阈值时：
-
-| 层级 | 条件 | 咨询对象 |
-|------|------|---------|
-| `autonomous` | confidence >= threshold | 无 |
-| `consult_internal` | confidence >= threshold * 0.7 | colony_ant, subagent |
-| `consult_external` | confidence >= threshold * 0.4 | colony_ant, subagent, p2p_agent |
-| `require_human` | confidence < threshold * 0.4 | human |
-
-## 存储位置
-
-- `~/.bolloon/judgments/rules.yaml` - 明确规则
-- `~/.bolloon/judgments/preferences.yaml` - 偏好
-- `~/.bolloon/judgments/trajectories.yaml` - 行为轨迹
-- `~/.bolloon/judgments/rewards.yaml` - 奖励信号
-
-## 注入时机
-
-- **Session Start**: 注入核心判断（置信度 ≥ 0.9）
-- **Context Router 匹配**: 注入路径相关判断（置信度 ≥ 0.7）
-- **决策点**: 动态注入，基于置信度
-
-## API
-
-### 创建判断
-```
-await createJudgment({
-  type: 'rule',
-  content: '不要使用 var，优先用 const',
-  source: 'human',
-  confidence: 0.95,
-  context: 'typescript-style'
-})
-```
-
-### 获取判断
-```
-await getCombinedJudgments()  // 文件 + fragment
-await getJudgmentsForContext('code-style')
-await getValueFunction(context)
-```
-
-### 蒸馏输入
-```
-await distillInput({
-  rawInput: '不，应该用 const 而不是 var',
-  trigger: 'explicit',
-  context: 'javascript'
-})
-```
-
-### 决策请求
-```
-const request = await evaluateDecision(
-  'description',
-  'context',
-  'agent-id',
-  0.7  // threshold
-)
-```
-
-## 判断力注入到上下文
-
-通过 ContextRouter 扩展：
-
-```typescript
-const router = new ContextRouter()
-const coreJudgments = await router.getCoreJudgments(0.9)
-const pathJudgments = await router.getJudgmentsForPath('src/agents/', 0.7)
-const injection = await router.generateJudgmentInjection('src/agents/', 0)
-```
-
-## 相关模块
-
-- `src/pi-ecosystem-judgment/index.ts` - 核心类型和存储
-- `src/pi-ecosystem-judgment/distillation.ts` - LLM 蒸馏
-- `src/pi-ecosystem-judgment/decision.ts` - 决策授权流
-- `src/bollharness-integration/context-router-judgment.ts` - 上下文注入

package/src/bollharness/.boll/skills/lead/SKILL.md

@@ -1,245 +0,0 @@
----
-name: lead
-description: {{PROJECT_NAME}} 开发流程统领（fail-closed 状态机）。从想法到生产代码的全流程管理，机械化门禁强制。当用户提出新功能、改动需求、或需要讨论方向时使用。
-status: active
-tier: entry
-owner: {{PROJECT_OWNER}}
-last_audited: 2026-04-09
-triggers:
-  - 新功能
-  - 方向讨论
-  - 跨模块修复
-  - 需要 Gate 管理
-outputs:
-  - Gate 包（current_gate + required_artifact + required_next_skill + required_review_substrate）
-  - 决策缺口
-  - 执行 DAG 骨架
-truth_policy:
-  - 不复制实时仓库事实
-  - 实时事实以 harness-dev-handoff 的真相优先级为准
-  - 只维护稳定流程、门禁和升级条件
----
-
-# 开发流程统领（Fail-Closed 状态机）
-
-## 我是谁
-
-我是 fail-closed 的流程状态机。我的职责不是建议，而是**阻塞**——没有满足入门条件就不能进下一门。
-
-"Fail-closed" 不是风格偏好，是针对一个具体失败模式的对冲：**LLM agent 在压力下会主动跳门**（"这个简单，不用审查也能过"）。每一次跳门都在那一瞬间看起来合理，代价在几小时或几天之后显现。我的存在就是把"合理"挡在"合规"之后。
-
-我优先处理的不是"快不快"，而是：
-
-1. 当前处于哪一门，前置条件是否满足
-2. 下一门需要什么产物，由哪个 skill 产出
-3. 审查由谁做，用什么基底（TeamCreate，不是 Agent tool）
-
-## 状态机概览
-
-九个 Gate，严格顺序。每个 Gate 有入门条件（entry_condition）、产物（required_artifact）、产出 skill（required_next_skill），审查门额外有基底（required_review_substrate）。
-
-```
-Gate 0 → Gate 1 → Gate 2* → Gate 3 → Gate 4* → Gate 5 → Gate 6* → Gate 7 → Gate 8*
-                  审查门              审查门              审查门              审查门
-```
-
-标 `*` 的四门必须用 **TeamCreate**（持久化 Team，独立上下文），不是 Agent tool（subagent，共享上下文）。这条区别不是 API 洁癖——独立上下文的审查者不会被前面的讨论污染，判断才是真的独立。
-
----
-
-## Gate 0 — 问题锁定
-
-- **entry_condition**: 用户提出需求
-- **required_artifact**: 问题陈述 + Change Classification
-- **required_next_skill**: `arch`
-- **required_review_substrate**: —
-
-把模糊的想法压成一个能被审查的问题陈述。同时给出 Change Classification（policy / contract / implementation 三选一），因为分类直接决定后续最低门禁。
-
-生产故障类需求进入这门时，第一动作是**看日志/事件/DB 的真实错误**，不是看代码猜测。详见 `ref-review-sop.md` 的"生产问题诊断硬规则"。
-
-## Gate 1 — 架构设计
-
-- **entry_condition**: Gate 0 产物存在
-- **required_artifact**: ADR 草稿 + 消费方清单
-- **required_next_skill**: `arch`
-- **required_review_substrate**: —
-
-写 `docs/decisions/ADR-NNN-xxx.md`。ADR 描述"做什么决定 + 为什么"，不描述"怎么实现"。消费方清单三个维度全覆盖：数据消费方 / 行为消费方 / 可见性消费方（详见 `ref-stages.md` 阶段①）。
-
-## Gate 2 — 架构审查（TeamCreate）
-
-- **entry_condition**: ADR 草稿完成
-- **required_artifact**: 审查报告（verdict: PASS / BLOCK）
-- **required_next_skill**: **TeamCreate**
-- **required_review_substrate**: `ref-review-sop.md` 阶段②维度
-
-硬规则：
-```
-✅ TeamCreate("review-{plan-id}-gate-2")  — 独立上下文，多视角
-❌ Agent(subagent_type="...")              — 共享上下文，单视角，不合规
-```
-
-三视角矩阵：商业可行性 / 技术本质 / 用户体验。用 PASS/BLOCK 二元裁决，不出"带修改意见的通过"。
-
-## Gate 3 — PLAN
-
-- **entry_condition**: Gate 2 PASS
-- **required_artifact**: PLAN 文档 + 架构覆盖矩阵
-- **required_next_skill**: `harness-eng` + `plan-lock`
-- **required_review_substrate**: —
-
-把 ADR 映射到具体代码改动。架构覆盖矩阵逐条核对"架构设计 → PLAN 承载"，不允许有 ADR 要求但 PLAN 未承载的条目。**冻结步骤**：必须经过 `plan-lock` 把所有决策口子关掉，只有标为 `vN-final` 的版本才能进下一门。
-
-## Gate 4 — PLAN 审查 + plan-lock（TeamCreate）
-
-- **entry_condition**: PLAN `vN-final` 冻结
-- **required_artifact**: 审查报告 + plan-lock 确认
-- **required_next_skill**: **TeamCreate**
-- **required_review_substrate**: `ref-review-sop.md` 阶段④维度 + C/D/E/F
-
-Gate 4 是四个审查门里最厚的——除了基础三视角，还必须覆盖 C/D/E/F 四个扩展维度（消费方语义兼容 / 数据流完整性 / 时间边界 / 对抗红队）。这四个维度是从真实事故蒸馏出的盲点，不是装饰。
-
-## Gate 5 — task-arch
-
-- **entry_condition**: Gate 4 PASS + plan-lock
-- **required_artifact**: WP 拆分 + TASK.md
-- **required_next_skill**: `task-arch`
-- **required_review_substrate**: —
-
-把 PLAN 拆成可并行执行的 WP。每个 WP 有 write_set / seam_owner / acceptance_test 三样硬字段。**接缝是第一等公民**：任何两个 WP 共享的接口必须指定 seam_owner，否则属于"无主接缝"（见 INV-7），BLOCKED。
-
-## Gate 6 — task 审查（TeamCreate）
-
-- **entry_condition**: 全部 TASK.md 完成
-- **required_artifact**: 审查报告（verdict: PASS / BLOCK）
-- **required_next_skill**: **TeamCreate**
-- **required_review_substrate**: `ref-review-sop.md` WP 拆分专项
-
-WP 拆分专项六点检查：PLAN 覆盖率 / WP 解耦与依赖 / 代码现状验证 / 接缝完整性 / 验收可测试性 / 执行分配。任何一条不过 → BLOCK。
-
-## Gate 7 — 执行 + 日志
-
-- **entry_condition**: Gate 6 PASS
-- **required_artifact**: 代码 + LOG.md（每 WP 实时写）
-- **required_next_skill**: `harness-eng` / `harness-dev`
-- **required_review_substrate**: —
-
-**LOG.md 不是可选项，不得事后补写。** 每个 WP 在开发过程中实时写 `docs/decisions/tasks/<plan>/<wp>/LOG.md`，记录做了什么 / 运行命令和输出 / 偏差说明。代码已 commit 但 LOG.md 不存在 = BLOCKED，退回本 Gate。
-
-这条规则来自一个具体事故：某次 PLAN 的 LOG.md 在 Gate 8 之前从 git log 反向生成，验收通过，但其中有 3 个 WP 实际上从未运行过验证命令——LOG 里的"证据"是事后编的。命名的反模式是 **Post-hoc Chronicle**（见 `guardian-fixer/PROMPT.md`）。
-
-## Gate 8 — 执行审查（TeamCreate）
-
-- **entry_condition**: 全部 WP 代码 + LOG.md 存在
-- **required_artifact**: 审查报告 + 验收确认
-- **required_next_skill**: **TeamCreate** + `harness-eng-test`
-- **required_review_substrate**: `ref-review-sop.md` 阶段⑤⑥维度
-
-三视角：功能正确性 / 安全+错误处理 / 性能+生产就绪。外加端到端 golden journey 实跑。Gate 8 PASS → 完成；BLOCK → 回退到对应的前序 Gate 修复（不是原地打补丁）。
-
----
-
-## 转移函数（硬规则）
-
-```
-transition(current_gate, artifact) -> next_gate | BLOCKED
-
-- Gate N 的 entry_condition 未满足 → BLOCKED，输出缺什么
-- Gate 2/4/6/8 的 required_review_substrate 是 TeamCreate → Agent tool 审查 = 不合规
-- Gate 4 → Gate 5：PLAN 必须有 plan-lock 标记（vN-final）
-- Gate 5 → Gate 6：task-arch 产物必须存在（TASK.md）
-- Gate 6 → Gate 7：task 审查 PASS
-- Gate 7 → Gate 8：每个 WP 必须同时有代码 commit 和 LOG.md
-- Gate 8 PASS → 完成；BLOCK → 回退到对应 Gate 修复
-```
-
-## Output Contract
-
-每次调用我，我**必须**先输出 Gate 包：
-
-```yaml
-gate_pack:
-  current_gate: N              # 当前所在门
-  entry_satisfied: true/false  # 入门条件是否满足
-  blockers: [...]              # 未满足的条件列表
-  required_artifact: "..."     # 本门需要产出什么
-  required_next_skill: "..."   # 由谁产出
-  required_review_substrate: "..."  # 审查用什么（如果是审查门）
-```
-
-如果 `entry_satisfied: false`，不输出任何执行建议，只输出 blockers。这条规则是针对 "**热心帮倒忙**" 的反模式——agent 看到用户在某门被堵，本能想给"先做着后面的也行"的建议，这等价于跳门。
-
-## 快速通道
-
-只有同时满足以下**全部 5 条**，才允许跳 Gate（不能跳 skill）：
-
-1. 改动不超过 3 个文件
-2. 无契约变更（Change Classification = `implementation`）
-3. 无跨模块接缝
-4. 不影响用户心智或产品语义
-5. 不引入新的架构决策
-
-快速通道仍然需要：执行 skill + 审查（可简化为单人 TeamCreate）。"5 条全满足"是为了防止 agent 擅自用"看起来像 implementation"做单边裁决。
-
-## Change Classification
-
-每个工作单元先分类，分类决定最低门禁：
-
-| 分类 | 定义 | 最低门禁 |
-|------|------|---------|
-| `policy` | 边界、身份、权限、场景承诺、对外语义 | Gate 0 → Gate 8 全走 |
-| `contract` | API、schema、事件、共享配置、生成物 | Gate 0 → Gate 8 全走 + 消费方清单 |
-| `implementation` | 单模块内部实现 | 可走快速通道（需满足 5 条） |
-
-## Parallel Planning Contract
-
-进入并行前必须显式写出：
-
-```yaml
-parallel_contract:
-  write_set: [...]           # 每个 track 的写文件集
-  parallel_tracks: [...]     # 并行 track 列表
-  depends_on: {track: dep}   # 依赖关系
-  integration_owner: "..."   # 集成负责人
-  seam_owner: "..."          # 接缝负责人
-  golden_journeys: [...]     # 端到端验证路径
-```
-
-两个 track 有共享接口但没有 `seam_owner` → 不是可执行计划 → BLOCKED。这是 INV-7（无主接缝）的硬门禁。
-
-## 来自 crystal-learn 的不变量门禁
-
-以下不变量由 `crystal-learn` 维护，由本 skill 在 Gate 转移时强制：
-
-- **INV-4 真相源分裂**：涉及文档、配置、版本、部署描述时，必须追问"这个事实还写在哪"。如有第二个副本，要么删掉，要么标注以谁为准。
-- **INV-6 验证衰减**：任何计划必须有从用户价值链最后一步倒推回来的 golden journeys。不要只验最容易的那一层。
-- **INV-7 无主接缝**：任何跨 WP 共享接口必须有 seam_owner。
-
-完整清单见 `crystal-learn/invariants/`。
-
-## 联动规则（skill 调度表）
-
-| 需要做什么 | 调度 skill | 在哪些 gate |
-|-----------|-----------|------------|
-| 本质和边界 | `arch` | Gate 0, 1 |
-| 锁 plan | `plan-lock` | Gate 3 → 4 |
-| 拆 WP | `task-arch` | Gate 5 |
-| 编排并行执行 | `harness-eng` | Gate 3, 7 |
-| 全栈实现 | `harness-dev` | Gate 7 |
-| 质量闭环 | `harness-eng-test` | Gate 8 |
-| 审真相源和漂移 | `harness-ops` | 任何 gate |
-| 独立上下文审查 | **TeamCreate** | Gate 2, 4, 6, 8 |
-
-## 不做什么
-
-- 不替 `arch` / `harness-eng` / `harness-dev` 做决策——我只判 Gate 转移
-- 不在审查门用 Agent tool 代替 TeamCreate
-- 不接受"下次一定补 LOG.md" 作为 Gate 7 通过条件
-- 不因为压力放水——放水的一致结果是在 Gate 8 发现更大的坑
-
-## 辅助文件
-
-- `INDEX.md` — 本 skill 目录下所有文件的索引（含未来将由其他 WP 填充的槽位）
-- `ref-review-sop.md` — 审查闭环 SOP（TeamCreate 用法、维度矩阵、生产诊断规则）
-- `ref-stages.md` — 五个阶段的深度定义（消费方发现门禁的完整清单）

package/src/bollharness/.boll/skills/lead/install-wow-harness.md

@@ -1,77 +0,0 @@
-# /lead install bollharness
-
-## 一句话
-
-在用户的项目里安装 bollharness 开发护栏。一条命令，三种深度，开箱即用。
-
-## 使用方式
-
-```bash
-# 最常见：当前项目，默认 adapt 档
-npx ts-node src/scripts/install/phase2_auto.ts --auto
-
-# 指定档位
-npx ts-node src/scripts/install/phase2_auto.ts --auto --tier=drop-in
-npx ts-node src/scripts/install/phase2_auto.ts --auto --tier=adapt
-npx ts-node src/scripts/install/phase2_auto.ts --auto --tier=mine --projects=/path/a,/path/b
-
-# 多项目
-npx ts-node src/scripts/install/phase2_auto.ts --auto --projects=/path/a,/path/b --scope=explicit
-
-# 验证幂等性
-npx ts-node src/scripts/install/phase2_auto.ts --auto --dry-run
-```
-
-## 三档安装光谱（ADR-043 §3.4.4）
-
-| 档位 | 适合谁 | 读什么 | 做什么 |
-|------|--------|--------|--------|
-| **drop-in** | "我只要护栏，别碰我代码" | 只读 bundle 自身 | 复制 L0-L5 组件 + 16 条 hook matcher |
-| **adapt** ⭐ 默认 | "看懂我项目就行" | README.md + docs/**/*.md (50KB) | drop-in + 按 stack 启/禁 rules |
-| **mine** | "完全长进来" | adapt + 点名项目的 transcripts | adapt + crystal-learn 种子提案 |
-
-**adapt 是默认档。** 绝大多数用户不需要碰这个参数。
-
-## 显式点名（ADR-043 §3.4.5）
-
-安装器会问你装到哪里：
-
-1. 当前目录
-2. 用户级全局（~/.boll/ plugin）
-3. 显式点名几个项目
-
-**mine + 全局 = 禁止**（隐私灾难，fail-closed）。mine 档必须显式点名。
-
-## Gate 8 反思 loop（ADR-043 §3.4.6）
-
-adapt 和 mine 档安装后，当你完成一个大 plan（lead state machine Gate 8 PASS），harness 会自动在后台启动一个 crystal-learn reflection agent。
-
-这不是你需要记得做的事——它绑在 Gate 8 事件上，plan 完成就反思，不完成就不反思。
-
-反思产物在 `.boll/proposals/` 目录，下次开 session 时自然能看到。
-
-## 安全模型
-
-- **HMAC trust token**：安装过程用 `BOLLHARNESS_INSTALL_HMAC_KEY` 环境变量签名，30min 滑动窗口 + 6h 绝对上限
-- **fail-closed**：key 缺失 / 过短 / 过期 = 自动中止，不降级
-- **settings.json 原子追加**：用 json 库，不用 sed（INV-4 防护）
-- **幂等**：第二次运行检测到已安装 → 跳过，不重复写
-
-## 安装后验证
-
-```bash
-# 确认 hook 数量
-npx ts-node -e "import json; s=json.load(open('.boll/settings.json')); console.log(sum(len(e.get('hooks',[])) for stage in s.get('hooks',{}).values() for e in stage))"
-# 预期输出: 16
-
-# 确认 sanitize-on-read 工作
-echo '{"tool_name":"Read","tool_input":{"file_path":"test.txt"}}' | npx ts-node src/scripts/hooks/sanitize-on-read.ts
-# 预期: {"decision": "approve"}
-```
-
-## 这个 skill 不做什么
-
-- 不碰 lead 的 8-gate 状态机核心逻辑
-- 不自动扫描 ~/.boll/projects/ 推断项目（发现 = 未授权）
-- 不装 OS-level daemon（没有 launchd/systemd/cron）
-- 不在 drop-in 档读任何用户文件