@bolloon/bolloon-agent 0.1.35 → 0.1.37

package/src/bollharness/scripts/ci/count-components.sh

@@ -1,65 +0,0 @@
-#!/bin/bash
-# count-components.sh — WP-03 AC 1 primary judge + WP-SEC-1 meta-self-check.
-#
-# Emits three lines that WP-SEC-1 CI asserts against MANIFEST.yaml:
-#   command_instances=<N>   # count of "command": entries in .boll/settings.json
-#   unique_scripts=<N>      # deduped scripts referenced by those commands
-#   physical_files=<N>      # hook + root-script files on disk (L1 registry)
-#
-# Meta-self-check (§13.5 INV-4 activation 5):
-#   After set -e, the script verifies (a) its own file still exists, and
-#   (b) .github/workflows/ci.yml — if present — still references this script
-#   by name. If either check fails, exit 2 with the message
-#   "count-components.sh meta-self-check failed: the chokepoint itself is vapor".
-#
-# Run from repo root. Reads .boll/settings.json, scripts/hooks/, scripts/.
-
-set -e
-
-# --- meta-self-check ---------------------------------------------------------
-SELF_PATH="$(cd "$(dirname "$0")" && pwd)/$(basename "$0")"
-test -f "${SELF_PATH}" || {
-  echo "count-components.sh meta-self-check failed: the chokepoint itself is vapor" >&2
-  exit 2
-}
-
-REPO_ROOT="$(cd "$(dirname "$0")/../.." && pwd)"
-CI_WORKFLOW="${REPO_ROOT}/.github/workflows/ci.yml"
-if [ -f "${CI_WORKFLOW}" ] && ! grep -q 'count-components.sh' "${CI_WORKFLOW}"; then
-  echo "count-components.sh meta-self-check failed: the chokepoint itself is vapor" >&2
-  exit 2
-fi
-# -----------------------------------------------------------------------------
-
-cd "${REPO_ROOT}"
-
-# command_instances: every "command" key in settings.json's hooks[]
-# Count the total commands across all hook stages.
-if command -v jq >/dev/null 2>&1; then
-  CMD_INSTANCES=$(jq '[
-    .hooks.PreToolUse[]?.hooks[]?,
-    .hooks.PostToolUse[]?.hooks[]?,
-    .hooks.PreCompact[]?.hooks[]?,
-    .hooks.SessionStart[]?.hooks[]?,
-    .hooks.SessionEnd[]?.hooks[]?,
-    .hooks.Stop[]?.hooks[]?,
-    .hooks.PostToolUseFailure[]?.hooks[]?
-  ] | length' .boll/settings.json)
-else
-  # Fallback: line-grep. Less precise but works without jq.
-  CMD_INSTANCES=$(grep -c '"command":' .boll/settings.json || echo 0)
-fi
-
-# unique_scripts: distinct scripts referenced by those commands.
-# Extract the last `npx ts-node scripts/...` or `bash scripts/...` token and dedupe.
-UNIQUE_SCRIPTS=$(grep -oE '(npx ts-node|bash) scripts/[^ "]+' .boll/settings.json \
-  | awk '{print $2}' | sort -u | wc -l | tr -d ' ')
-
-# physical_files: hooks dir + 2 root scripts
-HOOKS_COUNT=$(ls scripts/hooks/*.ts scripts/hooks/*.sh scripts/hooks/*.md 2>/dev/null | wc -l | tr -d ' ')
-ROOT_COUNT=$(ls scripts/guard-feedback.ts scripts/deploy-guard.ts 2>/dev/null | wc -l | tr -d ' ')
-PHYSICAL=$((HOOKS_COUNT + ROOT_COUNT))
-
-echo "command_instances=${CMD_INSTANCES}"
-echo "unique_scripts=${UNIQUE_SCRIPTS}"
-echo "physical_files=${PHYSICAL}"

package/src/bollharness/scripts/context-fragments/artifact-linkage.md

@@ -1,14 +0,0 @@
-## 代码变更与 Artifact 关联
-
-你正在编辑决策文档。代码变更必须伴随相应的 artifact：
-
-| 变更类型 | 必须伴随的 artifact |
-|----------|---------------------|
-| 新功能 | ADR 或 PLAN 文档 |
-| Bug 修复 | Issue 文档（含根因分析） |
-| 架构变更 | ADR + 影响范围分析 |
-| 契约变更 | 消费方清单 + 迁移说明 |
-
-**行为约束**: 不得提交无 artifact 关联的重大变更。
-目标态文档不得使用"已完成"语气描述尚未实现的功能（承诺 vs 现实漂移）。
-PLAN 文档中的 WP 状态必须反映实际代码状态，不是计划状态。

package/src/bollharness/scripts/context-fragments/auth-consumers.md

@@ -1,17 +0,0 @@
-## 认证消费方与安全约定
-
-你正在编辑认证相关代码。以下是认证体系的消费方：
-
-| 消费方 | 认证方式 | 入口文件 |
-|--------|----------|----------|
-| Protocol API | session token (Bearer) | `backend/product/auth/middleware.py` |
-| MCP Server (Python) | session token | `mcp-server/boll_mcp/client.py` |
-| MCP Server (Node) | session token | `mcp-server-node/src/client.ts` |
-| SecondMe OAuth | client_id + secret | `backend/product/auth/secondme.py` |
-| Bridge API | bridge API key | `backend/product/routes/bridge.py` |
-| Admin API | admin key | `backend/product/routes/admin.py` |
-| WebSocket | ticket auth | `backend/product/ws/` |
-
-**行为约束**: 前端不得暴露任何 API Key。SecondMe OAuth 的 client_secret 不得硬编码。
-修改认证中间件时，必须确认所有消费方的认证链路不受影响。
-session token 必须有 TTL，不得发放永不过期的 token。

package/src/bollharness/scripts/context-fragments/bridge-constitution.md

@@ -1,13 +0,0 @@
-## Bridge 宪法（ADR-026）
-
-你正在编辑 Bridge 相关代码。以下 5 条规则约束所有 bridge 改动：
-
-1. **Worker 不拥有业务解释权，只上报执行事实。** 如果代码需要理解输出内容的含义，它写错了地方。
-2. **同一个语义只允许有一个定义。** 文件名模式、artifact 类型、event 含义，只能在一个地方定义。
-3. **跑通了就发结果，没跑通就报 failed。** 不做 partial_success 抢救、不生成 placeholder。
-4. **生产不能是第一个集成环境。** 本地必须能用 fake CLI + 真实 HTTP backend 跑完整链。
-5. **新增观测维度或 event 类型，只改 server，不改 worker。**
-
-三层职责：`boll-run` 定义成功产物契约 -> `worker` 执行和上报事实 -> `server` 解释事实并生成产品语义。
-
-**行为约束**: 你不得在 worker 侧添加任何需要理解业务语义的逻辑。所有解释权必须归 server。

package/src/bollharness/scripts/context-fragments/catalyst-distributed.md

@@ -1,18 +0,0 @@
-## 分布式协商约定
-
-你正在编辑 catalyst 相关代码。端侧与平台侧职责严格分离：
-
-**平台侧（cloud catalyst）**：
-- 协调协商轮次、管理 deadline、聚合响应
-- 拥有全局视角，决定何时进入下一轮或结束
-
-**端侧（bridge worker）**：
-- 执行具体的 LLM 调用、生成响应
-- 只上报执行事实，不判断协商是否成功
-
-**BYOK 模式**：用户绑定自己的 API Key（Anthropic / MiniMax / 自定义 base_url）。
-平台侧使用用户 key 调用 LLM，不存储 key 明文（仅 session 级绑定）。
-
-**行为约束**: 不得在 worker 侧添加协商策略逻辑（何时结束、何时重试）。
-catalyst coordinator 的状态机变更必须伴随测试覆盖。
-BYOK base_url 必须经过校验，不得接受任意 URL（SSRF 防护）。

package/src/bollharness/scripts/context-fragments/closure-checklist.md

@@ -1,13 +0,0 @@
-## Issue 闭环检查清单
-
-你正在编辑 issue 文档。关闭 issue 前必须逐条确认：
-
-1. **prevention_status 是否 closed？** 如果是 open，说明复发路径未关闭，不得标 Fixed
-2. **mechanism_layer 是否声明？** 必须指定防护机制：guard / test / type / convention
-3. **有无具体的防护措施描述？** 不能只写"已修复"，必须说明如何防止复发
-4. **Guard > Memory 原则**：如果防护靠"记住规则"，则 prevention 不算 closed
-
-**行为约束**: 你不得在 prevention_status 为 open 的情况下将 status 改为 fixed。
-如果根因分析表明无法机械化防护，必须显式标注 `mechanism_layer: convention` 并说明原因。
-
-检查顺序：根因 -> 复发路径 -> 防护机制 -> 标记状态。不得跳过中间步骤。

package/src/bollharness/scripts/context-fragments/contract-consumers.md

@@ -1,15 +0,0 @@
-## 契约 vs 实现 + 消费方追踪
-
-你正在编辑 API 路由代码。区分契约和实现是防止漂移的核心：
-
-**契约**（改了必须通知消费方）：
-- URL 路径、HTTP method、请求/响应 JSON schema
-- 环境变量名、配置 key
-- 事件类型枚举、artifact 类型枚举
-
-**实现**（内部可自由调整）：
-- 函数签名、内部数据结构、算法细节
-
-**行为约束**: 修改契约时，必须先列出所有消费方，逐一确认兼容性。
-消费方列表不靠记忆维护——必须 grep 代码确认谁在调用。
-新增 API 字段必须是 optional；删除字段必须走废弃流程，不得直接移除。

package/src/bollharness/scripts/context-fragments/db-shared-structures.md

@@ -1,15 +0,0 @@
-## DB 共享结构与迁移约定
-
-你正在编辑数据库相关代码。以下表被多个模块共享：
-
-| 表 | 主要写入方 | 读取消费方 |
-|----|-----------|-----------|
-| users | auth 模块 | protocol, dashboard, admin |
-| demands | formulation | matching, runs, dashboard |
-| runs | catalyst, bridge | status API, result API, admin, WS |
-| run_events | bridge, catalyst | 6 个消费方（见 run-events-consumers） |
-| agents | protocol | discovery, federation, MCP |
-
-**行为约束**: SQLAlchemy `create_all()` 不会 ALTER 已有表——新增列必须用迁移脚本。
-修改表结构时，必须检查所有读取消费方的查询是否兼容。
-不得在不同模块中对同一表定义不同的 ORM model（一个表一个 model 定义）。

package/src/bollharness/scripts/context-fragments/fixed-three-layers.md

@@ -1,19 +0,0 @@
-## Fixed 三层定义
-
-你正在编辑 issue 文档。"Fixed" 不等于"症状消失"：
-
-| 层级 | 含义 | 标准 | 标记 |
-|------|------|------|------|
-| Level 1 | 症状消失 | 生产不报错了 | Runtime Fixed |
-| Level 2 | 复发路径关闭 | 有机制防止同类问题再次发生 | **Fixed**（最低标准） |
-| Level 3 | 机制消灭 | 有 guard 自动检测 | Fixed + Guarded |
-
-issue doc YAML frontmatter 必须包含：
-```yaml
-status: fixed|open|wont_fix
-prevention_status: open|closed|not_applicable
-mechanism_layer: guard|test|type|convention
-```
-
-**行为约束**: 如果标 `status: fixed` 但 `prevention_status` 是 `open`，则不合格。必须先分析复发路径。
-Guard: `check_issue_closure.py`

package/src/bollharness/scripts/context-fragments/general-dev-principles.md

@@ -1,11 +0,0 @@
-## 通用开发原则
-
-以下原则适用于所有代码变更：
-
-1. **Guard > Memory**: 如果一件事靠"记住规则"维护，它一定会出错。能机械化检测的，必须写 guard。
-2. **一个事实一个定义**: 同一信息不得在多处重复定义。其余位置必须自动派生或引用。
-3. **验证看最后一公里**: "服务启动了"不等于"功能正常"。验证必须到达用户可观测的终点。
-4. **先分层再动手**: 区分 policy / contract / implementation 三层，搞清楚问题在哪层再修。
-
-**行为约束**: 不得引入新的重复定义。如果发现已有重复，应在本次变更中收口为单一来源。
-不得跳过测试直接部署。不得用 `--no-verify` 绕过 pre-commit hook。

package/src/bollharness/scripts/context-fragments/issue-first.md

@@ -1,8 +0,0 @@
-## Issue-First 工作流
-
-修复 Bug 或变更业务逻辑前，先确认 `docs/issues/` 或 `docs/decisions/` 中有对应文档。
-没有文档就没有复发路径分析，修了也白修。
-
-**检查清单**（一行即可）:
-- 工作区是否已有或已创建对应的 issue/decision 文档？
-- 文档中是否写了复发路径（prevention_status）？

package/src/bollharness/scripts/context-fragments/mcp-parity.md

@@ -1,16 +0,0 @@
-## MCP 双端一致性约定
-
-你正在编辑 MCP 相关代码。Python 和 Node 两端必须保持一致：
-
-- **工具数量**：两端都是 54 个 @mcp.tool() / registerTool()
-- **工具名称**：必须完全相同（boll_xxx）
-- **行为语义**：相同输入必须产生相同输出结构
-- **版本号**：pyproject.toml 和 package.json 版本必须一致
-
-对应文件映射：
-- Python: `mcp-server/boll_mcp/server.py` <-> Node: `mcp-server-node/src/index.ts`
-- Python: `mcp-server/boll_mcp/client.py` <-> Node: `mcp-server-node/src/client.ts`
-- Python: `mcp-server/boll_mcp/config.py` <-> Node: `mcp-server-node/src/config.ts`
-
-**行为约束**: 改了一端后，你必须检查另一端是否需要同步。不得单独修改一端的工具签名或行为。
-Guard: `check_mcp_parity.py`

package/src/bollharness/scripts/context-fragments/pi-agent-operations.md

@@ -1,108 +0,0 @@
----
-paths:
-  - "src/agents/**"
----
-
-# Pi Agent 操作与工具定义
-
-> 来源: pi-sdk.ts TOOL_DEFINITIONS + getDefaultResponse
-> 关联: src/agents/constraint-layer.ts（工具注册）
-
----
-
-## 核心操作
-
-| 操作 | 描述 | 方法签名 |
-|------|------|----------|
-| 读取文档 | 读取并分析文档内容，支持 .txt, .md, .pdf, .docx | `read_document(path)` |
-| 总结文档 | 总结文档内容，可选提供上下文 | `summarize_document(path, context?)` |
-| 改进文档 | 改进文档，需提供文件路径和改进要求 | `improve_document(path, requirements)` |
-| 查看节点 | 查看已连接的对等节点 | `list_peers()` |
-| 发送消息 | 向指定对等节点发送消息 | `send_message(peer_id, message)` |
-| 广播消息 | 广播消息到所有节点 | `broadcast_message(message)` |
-| 查看身份 | 查看当前智能体身份 | `get_identity()` |
-| 设置 Persona | 更新智能体 persona 信息 | `set_persona(persona_json)` |
-| 执行工作流 | 执行预定义工作流 | `run_workflow(steps)` |
-| 查看日志 | 查看最近操作日志 | `get_operation_logs()` |
-| 列出文件 | 列出目录中的文件 | `list_files(path?)` |
-| 读取目录 | 读取目录内容，返回文件列表和目录结构 | `read_directory(path?)` |
-
----
-
-## 自主循环机制
-
-智能体基于 ReAct (Reasoning + Acting) 模式工作，具备自动评估质量和错误恢复能力：
-
-### 质量评估与自动改进
-- **质量阈值**: `0.6` (6/10)
-- **最大改进次数**: `3` 次
-- 当回复或工具执行结果质量低于阈值时，自动触发改进循环
-- 改进时在 system prompt 中添加质量提示，让 LLM 重新生成更优回答
-
-### 错误处理与自动恢复
-- **连续错误上限**: `3` 次
-- 工具执行失败时增加错误计数
-- 达到连续错误上限时，添加错误上下文让 LLM 换一种方式处理
-- 工具执行异常会被捕获并记录，不中断循环
-
-### 循环继续条件
-当 LLM 返回不是 tool call 格式时，判断是否需要继续循环：
-1. 包含错误/失败信息（不存在、找不到、错误、failed 等）
-2. 回复太短（<100 字符且无换行），可能是中间回复
-3. 包含问号，可能是需要更多信息
-4. 不包含明确结论（完成、结果、答案等）
-
-满足以上任一条件且循环未达上限，则继续处理。
-
-### 重试机制
-- 工具调用失败时重试（最多 3 次）
-- 汇报发送失败时重试（最多 2 次，指数退避）
-- 失败的汇报会进入待重试队列
-
----
-
-## 示例请求格式
-
-### 文档操作
-```
-"读取 README.md"
-"总结一下 src/index.ts"
-"改进文档，按照更清晰的错误处理要求"
-```
-
-### P2P 网络操作
-```
-"查看当前连接了哪些节点"
-"向 QmABC... 发送测试消息"
-"广播消息：系统将在 10 分钟后维护"
-```
-
-### 身份与状态
-```
-"查看身份"
-"查看日志"
-```
-
----
-
-## 工具注册位置
-
-工具在 `pi-sdk.ts` 的 `PiAgent` 类构造函数中注册，映射到：
-- `src/agents/constraint-layer.ts` — ConstraintLayer 基类提供的基础能力
-- `src/network/p2p.ts` — P2P 网络模块
-- `src/documents/reader.ts` — 文档读取模块
-
----
-
-## 自然语言指令映射
-
-| 自然语言指令 | 解析关键词 | 执行方法 |
-|-------------|-----------|----------|
-| 读取 X | `读取`、`read_document`、`read` | `readDocument(path)` |
-| 总结文档 | `总结`、`summarize_document` | `summarizeDocument(path, context?)` |
-| 改进文档 | `改进`、`improve_document` | `improveDocument(request)` |
-| 查看节点 | `查看节点`、`list_peers` | `listPeers()` |
-| 发送消息 | `向 X 发送消息`、`send_message` | `sendMessage(peerId, message)` |
-| 广播消息 | `广播消息`、`broadcast_message` | `broadcast(message)` |
-| 查看身份 | `查看身份`、`get_identity` | `getIdentity()` |
-| 查看日志 | `查看日志`、`get_operation_logs` | `getOperationLogs()` |

package/src/bollharness/scripts/context-fragments/protocol-consumers.md

@@ -1,15 +0,0 @@
-## Protocol API 消费方
-
-你正在编辑 /protocol/ 相关代码。以下是 Protocol API 的消费方列表：
-
-| 消费方 | 入口 | 认证方式 |
-|--------|------|----------|
-| MCP Server (Python) | `mcp-server/boll_mcp/client.py` | session token |
-| MCP Server (Node) | `mcp-server-node/src/client.ts` | session token |
-| 前端 website | `website/` fetch 调用 | session token (cookie) |
-| Bridge Agent | `bridge_agent/` | bridge API key |
-| 外部 A2A 调用方 | federation endpoint | DID 签名 |
-
-**行为约束**: 修改任何 /protocol/ 路由的请求/响应结构时，必须检查上述所有消费方是否兼容。
-不得在不更新消费方的情况下修改返回字段名或删除字段。
-新增字段必须是 optional，避免破坏现有消费方。

package/src/bollharness/scripts/context-fragments/run-events-consumers.md

@@ -1,15 +0,0 @@
-## run_events 消费方（共享结构）
-
-你正在编辑 run_events 相关代码。此表有 6 个消费方，各自角色不同：
-
-| 消费方 | 读/写 | 用途 | 关键依赖 |
-|--------|-------|------|----------|
-| Bridge events 路由 | 写 | 接收 worker 上报的事件 | event_type 枚举 |
-| Catalyst coordinator | 写 | 记录协商轮次事件 | round_number, role |
-| Run status API | 读 | 前端展示进度 | 按 run_id 查询 + 时间排序 |
-| Run result API | 读 | 提取最终产物 | artifact 类型过滤 |
-| Admin event log | 读 | 运维审计 | 全字段 |
-| WebSocket hub | 读 | 实时推送 | 增量查询（last_id） |
-
-**行为约束**: 修改 run_events 表结构或写入逻辑时，必须逐一确认 6 个消费方不受影响。
-不得假设"只有一个地方读"。读模型截断会导致长 run 状态不正确。

package/src/bollharness/scripts/context-fragments/scene-fidelity.md

@@ -1,13 +0,0 @@
-## 场景保真度分级
-
-你正在编辑场景相关代码。每个场景有明确的保真度等级：
-
-| 等级 | 含义 | 数据来源 | 示例 |
-|------|------|----------|------|
-| **real** | 接真实 Protocol API | 生产后端 | startup-hub |
-| **demo** | 有独立后端但非协议链路 | demo 专用 API | ai-gig-market |
-| **shell** | 纯前端展示，无后端 | 静态/mock 数据 | 其他展示页 |
-
-**行为约束**: 文档和代码中声明的保真度必须与运行时实际行为一致。
-不得在文档中声称"真实协议"而代码跑 demo fallback（承诺 vs 现实漂移）。
-修改场景接入方式时，必须同步更新场景配置中的 fidelity 字段。

package/src/bollharness/scripts/context-fragments/truth-source-hierarchy.md

@@ -1,15 +0,0 @@
-## 真相源优先级
-
-你正在编辑核心文档。boll 的真相源有明确的优先级：
-
-| 优先级 | 来源 | 说明 |
-|--------|------|------|
-| 1 | 运行中的代码 | 实际行为是最终真相 |
-| 2 | 数据库 schema + 测试 | 可执行的约束 |
-| 3 | ADR / TECH / PLAN 文档 | 设计决策记录 |
-| 4 | CLAUDE.md | 开发指导（派生自上层） |
-| 5 | MEMORY.md | 会话间记忆（最易过期） |
-
-**行为约束**: 当不同层级的信息冲突时，必须以高优先级来源为准并修正低优先级来源。
-CLAUDE.md 中的信息必须可以从代码或 ADR 中验证——不得包含无法溯源的断言。
-修改真相源文件时，必须检查下游是否需要同步更新。

package/src/bollharness/scripts/context-fragments/two-language.md

@@ -1,15 +0,0 @@
-## 两套语言体系
-
-你正在编辑面向用户的代码。协议术语和用户语言必须严格分离：
-
-**协议层**（仅开发者/文档可见）：
-formulation, crystallization, catalyst, nomination, intent field, operator, resonance
-
-**用户层**（UI/文案/帮助文本）：
-需求澄清, 多方协商, 协调, 推荐, 能力匹配
-
-**行为约束**: 前端 UI、用户提示、错误消息中不得出现协议内部术语。
-用户永远不需要知道"结晶"是什么——他们只知道"多方协商"。
-比喻：酒店管家不会跟客人说"我现在执行 housekeeping protocol"。
-
-禁词（用户可见文本）: "播种意图"、"共振"、"场域"、"结晶"等诗意表达。

package/src/bollharness/scripts/context-fragments/version-sources.md

@@ -1,14 +0,0 @@
-## 版本号来源清单
-
-你正在编辑版本相关文件。一个事实只允许有一个定义：
-
-| 版本号 | 权威来源 | 必须同步的位置 |
-|--------|----------|----------------|
-| MCP Python | `mcp-server/pyproject.toml` | CLAUDE.md 引用 |
-| MCP Node | `mcp-server-node/package.json` | 必须与 Python 版本一致 |
-| 后端 API | `backend/product/protocol/service.py` | /protocol 元数据返回 |
-| 前端 | `website/package.json` | 部署产物 BUILD_ID |
-
-**行为约束**: 修改任何版本号时，必须同步所有关联位置。
-Python MCP 和 Node MCP 版本号必须完全一致，不得出现 0.x.y vs 0.x.z 的漂移。
-"一个事实一个定义"——如果两个地方都写死版本号，其中一个必须是自动派生的。

package/src/bollharness/scripts/hooks/find-project-root.sh

@@ -1,47 +0,0 @@
-#!/bin/bash
-# Walks up from $PWD to find the bollharness-installed project root.
-#
-# Anchor priority:
-#   1. .bollharness/MANIFEST.yaml  (primary — declared by installer)
-#   2. CLAUDE.md                   (fallback — older projects or pre-install)
-#
-# Why not scripts/guard-feedback.ts like the old boll-specific script?
-# Because that created a circular dependency: guard-feedback.ts was both
-# the anchor AND the target invoked by the hook. Projects that don't ship
-# guard-feedback.ts (because they disabled it via issue-adapter.yaml) would
-# fail to locate their own root. The MANIFEST anchor is independent of any
-# specific hook installation.
-#
-# Prints absolute project root to stdout. Exits 1 if not found.
-set -e
-d="${PWD}"
-while [ "$d" != "/" ] && [ -n "$d" ]; do
-  if [ -f "$d/.bollharness/MANIFEST.yaml" ]; then
-    echo "$d"
-    exit 0
-  fi
-  d="$(dirname "$d")"
-done
-
-# Fallback 1: walk up again looking for CLAUDE.md alone
-d="${PWD}"
-while [ "$d" != "/" ] && [ -n "$d" ]; do
-  if [ -f "$d/CLAUDE.md" ]; then
-    echo "$d"
-    exit 0
-  fi
-  d="$(dirname "$d")"
-done
-
-# Fallback 2: CLAUDE_PROJECT_DIR env var set by Claude Code
-if [ -n "${CLAUDE_PROJECT_DIR:-}" ]; then
-  if [ -f "${CLAUDE_PROJECT_DIR}/.bollharness/MANIFEST.yaml" ] || [ -f "${CLAUDE_PROJECT_DIR}/CLAUDE.md" ]; then
-    echo "${CLAUDE_PROJECT_DIR}"
-    exit 0
-  fi
-fi
-
-# Fail-closed: no hardcoded machine-specific path. If you reach here the
-# project is either not yet installed or CLAUDE_PROJECT_DIR is unset —
-# both cases should surface as an error to the hook caller.
-exit 1

package/src/bollharness/scripts/hooks/inbox-poll.sh

@@ -1,78 +0,0 @@
-#!/bin/bash
-# H9 inbox poll：状态检查 + 下次 wake 间隔推荐（PLAN-H9 §4.5 WP-05）。
-#
-# Spec letter 工程修订（disclosure）：
-#   PLAN-H9 §4.5 原文写"shell 脚本 ... 内部调用 ScheduleWakeup MCP"。落地阶段
-#   发现 ScheduleWakeup 是 CC agent loop 内部 tool API，shell 进程没有合法 RPC
-#   入口直接调用——必须由 CC agent（主窗口）调用。本脚本因此切分为：
-#     [shell 层] inbox-poll.sh = 状态检查 + 推荐间隔 → stdout 状态
-#     [agent 层] 主 agent 读 stdout 后自行决定下一次 ScheduleWakeup 时机
-#   切分边界已在 PLAN-H9 §4.5 + §11 letter 对齐时点明，记入 ADR-H9 修订建议。
-#
-# 输出：纯 KV 文本（不是 hook IO JSON），主 agent 解读后调度。
-#   unread_count=<int>
-#   p0_exists=<true|false>
-#   oldest_unread_age_seconds=<int|0>
-#   recommended_wake_seconds=<int>
-#
-# Hook IO 红线：本文件**不是** CC hook（不在 .boll/settings.json 注册），
-# 是主 agent 用 Bash tool 主动调用的检查脚本。无 print(json.dumps) / echo
-# permissionDecision / echo systemMessage 等 banned form——由 PLAN-H9 §8 显式
-# grep DoD 物理校验。
-
-set -euo pipefail
-
-# 主仓 root 检测（与 find-project-root.sh 语义对齐）
-SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
-REPO_ROOT="$(cd "${SCRIPT_DIR}/../.." && pwd)"
-INBOX_ROOT="${REPO_ROOT}/.boll/inbox"
-MAIN_UNREAD="${INBOX_ROOT}/main/unread"
-
-# 默认间隔常量（见 ADR-H9 §6.3 ScheduleWakeup 边界）
-NORMAL_WAKE_SECONDS="${INBOX_POLL_NORMAL_WAKE:-1200}"   # 20 分钟（cache 友好）
-P0_WAKE_SECONDS="${INBOX_POLL_P0_WAKE:-300}"            # 5 分钟（CC ScheduleWakeup 最短允许下限）
-
-# unread 计数
-unread_count=0
-if [ -d "${MAIN_UNREAD}" ]; then
-  unread_count="$(find "${MAIN_UNREAD}" -maxdepth 1 -type f -name '*.md' 2>/dev/null | wc -l | tr -d ' ')"
-fi
-
-# 是否存在 priority=P0 消息
-p0_exists=false
-if [ "${unread_count}" -gt 0 ]; then
-  if grep -lE '^priority:[[:space:]]*P0[[:space:]]*$' "${MAIN_UNREAD}"/*.md 2>/dev/null | head -1 | grep -q .; then
-    p0_exists=true
-  fi
-fi
-
-# 最旧 unread 的 mtime delta（秒）
-oldest_age=0
-if [ "${unread_count}" -gt 0 ]; then
-  oldest_file="$(ls -1tr "${MAIN_UNREAD}"/*.md 2>/dev/null | head -1 || true)"
-  if [ -n "${oldest_file}" ] && [ -f "${oldest_file}" ]; then
-    if stat --version >/dev/null 2>&1; then
-      # GNU stat (Linux)
-      oldest_mtime="$(stat -c %Y "${oldest_file}" 2>/dev/null || echo 0)"
-    else
-      # BSD stat (macOS)
-      oldest_mtime="$(stat -f %m "${oldest_file}" 2>/dev/null || echo 0)"
-    fi
-    now="$(date +%s)"
-    oldest_age="$((now - oldest_mtime))"
-  fi
-fi
-
-# 推荐 wake 间隔
-if [ "${p0_exists}" = "true" ]; then
-  recommended="${P0_WAKE_SECONDS}"
-else
-  recommended="${NORMAL_WAKE_SECONDS}"
-fi
-
-# 输出（KV 纯文本，主 agent 用 grep / awk 解读）
-printf 'unread_count=%s\n' "${unread_count}"
-printf 'p0_exists=%s\n' "${p0_exists}"
-printf 'oldest_unread_age_seconds=%s\n' "${oldest_age}"
-printf 'recommended_wake_seconds=%s\n' "${recommended}"
-printf 'note=ScheduleWakeup MCP must be invoked by main agent (shell cannot reach CC internal tool API)\n'

package/src/bollharness/scripts/hooks/precompact.sh

@@ -1,56 +0,0 @@
-#!/bin/bash
-# PreCompact hook: 注入必须在 context compaction 中保留的关键信息
-# [来源: ADR-038 D2.3 + D9 (v4 Objective Recitation), CC PreCompact hook — exit 0 追加为 compact 指令]
-
-# 读取当前活跃的 PLAN/TASK/Issue 状态
-REPO_ROOT="$(git rev-parse --show-toplevel 2>/dev/null || pwd)"
-
-cat <<'PRESERVE'
-## 必须保留的关键信息
-
-### 当前工作上下文
-- 保留当前正在进行的 PLAN/TASK/Issue 的完整状态和进度
-- 保留 Sprint Contract（如果有）的全部验收标准
-- 保留当前 WP 的 scope 和验收条件
-
-### 不可降级规则 (ADR-030 核心)
-- Guard > Memory: 能机械化检测的必须写 guard
-- 一个事实一个定义: 同一信息不得在多处重复定义
-- 验证看最后一公里: 验证必须到达用户可观测的终点
-
-### 行为约束
-- 所有 commit message 必须中英双语
-- 所有 subagent 必须使用 claude-opus-4-6
-- 不得跳过 Gate 2/4/6/8 审查
-- Issue 先于代码: 改代码前必须先创建 issue 文档
-PRESERVE
-
-# ── v4 D9: Objective Recitation ──
-# [来源: Manus/IMPACT — recite objectives at end of context after ~50 tool calls]
-# [来源: Cursor — 丢失 reasoning traces 导致 30% 性能下降]
-# 在 compact 后的新上下文末尾追加原始目标，防止注意力漂移。
-# KV cache 友好——只追加到末尾，不重排前文。
-PROGRESS_FILE="$REPO_ROOT/.boll/progress/current.json"
-if [ -f "$PROGRESS_FILE" ]; then
-    echo ""
-    echo "## Objective Recitation (v4 D9)"
-    echo ""
-    echo "**原始目标**（不可漂移，由 D8 Initializer Agent 写入后 read-only）："
-    npx ts-node -e "
-import * as fs from 'fs';
-const data = JSON.parse(fs.readFileSync(process.env.PROGRESS_FILE!, 'utf-8'));
-console.log('  ' + (data.objective || '<未设置>'));
-console.log();
-const pending = (data.features || []).filter((f: { status: string }) => f.status !== 'passing');
-if (pending.length) {
-    console.log('**未完成 features**：');
-    pending.forEach((f: { status: string; id: string; subject: string }) => {
-        console.log('  - [' + f.status + '] ' + f.id + ': ' + f.subject);
-    });
-} else {
-    console.log('**所有 features 已 passing**，可以进入 Stop 流程。');
-}
-" 2>&1
-fi
-
-exit 0