@bolloon/bolloon-agent 0.1.0

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

@@ -0,0 +1,183 @@
+---
+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

@@ -0,0 +1,115 @@
+---
+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

@@ -0,0 +1,245 @@
+---
+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

@@ -0,0 +1,77 @@
+# /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 档读任何用户文件