@bolloon/bolloon-agent 0.1.0 → 0.1.1

package/src/bollharness/docs/decisions/ADR-041-codex-claude-code-division-of-labor.md

@@ -1,128 +0,0 @@
-# ADR-041: Codex × Claude Code 分流策略（v1.0 极简版）
-
-**状态**: accepted (v1.0 — 2026-04-07，砍掉 v0.1/v0.2/v0.3 过度工程化设计)
-**日期**: 2026-04-07
-
-## 0. 历史与重写理由
-
-v0.1 → v0.3 在 Gate 2 三轮审查中被红队推着持续加机制，从"分流偏好"膨胀成"18 个架构变更 + 10 红线 + 12 白线 + 威胁模型 + cumulative drift hook + marker chokepoint + hash 锁"。Nature 看完后判断**过度工程化**：原始诉求只是「让 Claude 自己判断啥时候用 Codex + 配几个自动化省 token」，不是建一个微型操作系统。
-
-v1.0 是干净重写。v0.1/v0.2/v0.3 全部 superseded，**不**作为参考实现。失败模式记录：审查驱动复杂度通胀——红队每轮按"最大威胁假设"提 finding，作者每轮加机制应对，三轮后 ADR 与原始诉求脱节。教训沉淀到 `feedback_review_driven_complexity_inflation.md`。
-
-## 1. 问题
-
-- Claude Code (Opus 4.6) 月度 token 消耗远超预算
-- ChatGPT Pro 的 Codex 额度富余，且 2026-03 上线 Automations（schedule + trigger）
-- `codex-dev` subagent 已存在但几乎不被调用——main agent 默认把活留给自己
-- 一些重复性任务（文档漂移、夜间测试、飞书 bug 预翻译）原本由 Claude 在 session 里跑或干脆没人跑
-
-## 2. 决策
-
-四件事，没有别的：
-
-### D1: CLAUDE.md 加「老板心态」硬规则（§零）
-
-`CLAUDE.md` 的 §一（不可妥协约束）之前插入新的 §零，约 30 行，明确：
-
-> 你是技术主管，你有 Codex 这个员工。每接到任务先问"能不能 Codex 干"。默认假设 Codex 能干。
-
-列出 5 类容易忽略分流的典型场景：
-- 批量字符串替换 / i18n 提取
-- CSS / Tailwind 类名批量调整
-- 纯技术重构（命名、dead code、补 TS 类型、性能 memo）
-- 批量补测试用例（已有框架下）
-- 文档批量更新 / shell 脚本生成
-
-这是**默认偏好**，不是硬阻塞。误判由人/Claude 在下次任务里学着调整，不靠 hook 强制。
-
-### D2: codex-dev 红线（3 条，不是 10 条）
-
-`.claude/agents/codex-dev.md` 顶部加红线段，**只列 3 条**：
-
-1. **前端 React 组件结构 / 交互逻辑 / 新页面或新 feature 的实现** — Codex 前端小错多
-2. **跨模块数据流穿透**（前端 → API → DB） — Codex 类型对齐 ≠ 数据流通的元失败模式
-3. **审美决策 / `nature-designer` 流程** — CLAUDE.md §一 1.2
-
-红线之外的任务，main agent 决定要不要分流，不强制。
-
-### D3: 5 个 ChatGPT Pro Automation（异步通道）
-
-由 Nature 在 ChatGPT Pro 端手动配置，**全部以 PR 为唯一交付形态**，不直接 commit main：
-
-| Automation | 触发 | 频率 | 产出 |
-|---|---|---|---|
-| `doc-drift-scan` | schedule | 每 2h | 检测 magic docs / `check_doc_freshness.py` 漂移，有则提 PR |
-| `magic-doc-regenerate` | schedule | 每 6h | 跑 `regenerate_magic_docs.py all`，drift 则提 PR |
-| `nightly-test-baseline` | schedule | 每日 02:00 | 跑全量 unit/integration 对比 baseline，新 failure 提 PR + 飞书通知 |
-| `daily-release-brief` | schedule | 每日 18:00 | git log + PR merged 汇总，写 `.wow-harness/codex-reports/brief-{date}.md` |
-
-GitHub main branch protection 必须开启（禁直接 push main、禁 force push）。这是 Automation 安全边界的兜底。
-
-### D4: AGENTS.md 派生 + 双配置同步
-
-Codex 不读 `CLAUDE.md`。在仓根的 `AGENTS.md` 加一段从 `CLAUDE.md` 抽取的 Codex 必知子集（路径、commit 双语、python3、浅色主题、3 条红线）。手动维护即可，不写自动同步脚本——一周复盘时顺便对一遍。
-
-## 3. 不做的事（明确砍掉）
-
-为了避免 v1.x 又被审查放大，明确**不做**：
-
-- ❌ `codex-router.py` 决策树 hook（让 Claude 判断就行）
-- ❌ PostToolUse / PreToolUse 任何 router 相关 hook
-- ❌ marker 文件 / chokepoint / hash 锁
-- ❌ Gate 审查 pre-pass（Codex 在审查中的角色是 0）
-- ❌ 威胁模型四元论证 / cumulative drift / signed bias 算法
-- ❌ `.wow-harness/router-misroutes.jsonl` / `.wow-harness/router-tobe-reviewed.jsonl` / `.wow-harness/router-health.jsonl`
-- ❌ `task_signal` 字段 / `executor` frontmatter 强制 / `task-arch` skill 改造
-- ❌ PLAN-083 / 9 WP 拆分
-
-如果未来发现"老板心态规则不够，Claude 还是不分流"，**先调规则文字，不加机制**。机制化必须先在每周复盘里证明"调规则解决不了"。
-
-## 4. 实施清单（4 个文件，不是 18 个）
-
-| # | 文件 | 改动 |
-|---|---|---|
-| C1 | `CLAUDE.md` | 在 §一 之前插入 §零「老板心态」硬段 |
-| C2 | `.claude/agents/codex-dev.md` | 顶部加 3 条红线 |
-| C3 | `AGENTS.md` | 加「Codex 必知子集」一节（红线 + commit 双语 + python3 + 浅色主题） |
-| C4 | ChatGPT Pro 控制台 | Nature 手动配置 5 个 Automation（D3 表）+ 验证 main branch protection 已开 |
-
-C1/C2/C3 由本 ADR 同 commit 一起做。C4 由 Nature 手动完成，做完在 `MEMORY.md` 记一笔。
-
-## 5. 复盘节奏
-
-**每周一次**（不是月度）。每周末 Nature 看一次：
-
-1. 这周 codex-dev 被调用了几次？（人脑估算，不需要 metrics 文件）
-2. 有没有发生"应该分流但没分流"的明显案例？
-3. 5 个 Automation 是否都在跑？产出是否被消费？
-4. 老板心态规则要不要改字？
-
-如果连续 2 周分流明显不足，再考虑加机制；不要先建机制再找用途。
-
-## 6. 验收
-
-不设可量化指标。验收靠 Nature 的主观感受：
-
-- 月度 Claude token 消耗有没有"明显感觉降低"
-- codex-dev 有没有"明显感觉被用起来"
-- 5 个 Automation 是否真的在 PR 队列里看到产出
-
-当出现"感觉跟 v1.0 之前没区别"时，回头审视：是规则文字不够强？还是 Automation 没配？不是"加机制"。
-
-## 7. 关联
-
-- ADR-038 D11 — 审查 agent 工具隔离，与本 ADR 正交（本 ADR 不动审查门，Codex 不参与审查）
-- <EXTERNAL_PIPELINE_REDACTED> — Automation 下游消费方示例（已脱敏移除）
-- `CLAUDE.md §四 4.3` — subagent 模型约束。codex-dev 是**执行类**而非判断类 subagent，不受 4.3 opus 约束（这一句加到 4.3 末尾的例外子句里，由 C1 顺手做）
-- `memory/feedback_codex_quality_issues.md` / `feedback_codex_error_patterns_crystal_learn.md` — Codex 已知失败模式，沉淀在 memory 而不是 hook
-
-## 8. 失败模式记录（v0.1 → v0.3 教训）
-
-为什么前 3 版会膨胀：
-
-1. **审查门 PEHK 规则在小决策上反向放大**：「任一 reviewer P0 → BLOCK」逼出"每轮按红队最大威胁假设加机制"的循环
-2. **没人喊停**：作者在 Gate 流程里默认遵循 reviewer，没意识到原始诉求只需要 100 行 ADR
-3. **威胁模型不显式**：v0.3 才补 §2.0 威胁模型，但已经是在过度工程之上的防御
-4. **Skill 状态机鼓励完整性**：lead skill 的 Gate 0→8 完整流程对"30 分钟级别的偏好调整"是过度的——快速通道（CLAUDE.md §零行为约束 2.2）的 5 条触发条件应该被本 ADR 命中
-
-教训沉淀到 `feedback_review_driven_complexity_inflation.md`，将来类似规模的 ADR 直接走快速通道，不开 Gate 2 三角审查。

package/src/bollharness/docs/decisions/ADR-H1-crystal-learn-revival.md

@@ -1,188 +0,0 @@
----
-adr: ADR-H1
-title: crystal-learn 学习层复活——触发节奏物理化（不加机制）
-status: Accepted
-version: 1.0
-date: 2026-04-28
-owner: nature
-window_owner: shared
-window_owner_since: 2026-04-28T18:30+08:00
-parent_plan: 39-h-h-h-h-hanis-refactored-toucan
-inherits_philosophy:
-  - ADR-041-v1.0-codex-routing  # 调字不加机制
-  - ADR-H4-prompt-governance    # H4 INV-H4-3 哲学硬继承
-related_skills:
-  - ~/.boll/skills/boll-crystal-learn/SKILL.md  # 学习层（已就位，89 行成熟契约）
-  - .boll/skills/lead/SKILL.md                   # 接收侧（line 142 已布线）
-problems_addressed:
-  - "#1 自我进化健康度停摆 11 天（最后 round verdict 2026-04-17）"
-  - "#2 crystal-learn skill 周期触发停了 4 周"
-  - "#7 crystal-learn 没退役（认知修正，问题降级）"
----
-
-# ADR-H1：crystal-learn 学习层复活——触发节奏物理化（不加机制）
-
-## §1 上下文
-
-### 1.1 stop-the-bleed 现状（来自 H 系列 plan §2.1 Phase 1 调研）
-
-- crystal-learn skill 文件 `~/.boll/skills/boll-crystal-learn/SKILL.md` **存在且成熟**（89 行；status=active；tier=meta；INV-0..INV-7 全部映射到 active target skills）
-- crystal-learn 接收侧 `.boll/skills/lead/SKILL.md` line 142 **已布线**（`## 来自 crystal-learn 的门禁` 段含 INV-4 真相源分裂 + INV-6 验证衰减 + Gate 8 PASS 宣告规则）
-- crystal-learn skill commit 历史最近一次产出 `c80f2b48`（2026-04-25 billing INV-5/6 sync）；之前 `8925d8f1`（4 skill 沉淀）→ `479a6b70`（INV-1/6 instances）→ 4-5 个月静默期
-- harness-self-symptoms.md 累计 **9 条** symptom（§4.1-§4.9），其中 §4.7/§4.8 同根复发（"起草不实证"），§4.9 是新型号（cross-plan-class race）；处置段已生成 ADR-H0 修订建议第 8/9/10 条**未消化**
-
-### 1.2 root cause（4 周停摆）
-
-不是基础设施缺失，是**触发节奏断了**。crystal-learn 现有触发依赖：
-
-- (A) Nature 主动启动（人脑提醒）
-- (B) Gate 收尾时手工触发（依赖 reviewer / coordinator 在 Gate 8 闭环时记得调用）
-
-H 系列实施 11 天累积，Nature 已超载；reviewer / coordinator 角色在 H4 之前未稳定到位。两条触发轴都失效。
-
-### 1.3 不是什么
-
-- 不是 crystal-learn skill 本身契约问题（output contract = invariant delta + target injection map 已明确）
-- 不是接收侧布线问题（lead/SKILL.md line 142 段已存在）
-- 不是缺机制（写 cron / 加 hook 是 #20 推卸 + ADR-041 v1.0 红线 + H4 INV-H4-3 反例）
-
-## §2 决策本质
-
-把"何时触发 crystal-learn"从隐式人脑依赖转为显式 prompt-level checklist，**写进 lead/SKILL.md**（CLAUDE.md 隐式默认加载，70% adherence baseline）。继承 ADR-041 v1.0 "调字不加机制" + H4 INV-H4-3 "禁 hook/metrics/review-contract"。
-
-具体：
-
-1. 触发条件 ≤5 条，全部物理化为 lead/SKILL.md 段（≤30 行，同 H4 INV-H4-1）
-2. 落地路径用现有"## 来自 crystal-learn 的门禁"段（不新建文件）
-3. 受管资产 scope 严格列出（H0.1 施工隔离）
-
-## §3 不变量（INV-H1）
-
-### INV-H1-1 触发条件 ≤5 条
-
-> Why：防 ADR-041 v0.1→v0.3 膨胀剧本重演；H4 INV-H4-1 同结构（≤10 条 / H1 更紧因为是触发表非分类清单）。
-> 验证：`awk` 计触发条件计数 ≤5。
-
-### INV-H1-2 落地路径必须落到现有接收段
-
-> Why：每新建文件 = 一个新真相源分裂点（INV-4），且违反 ADR-041 v1.0 "调字"原则。
-> 验证：`grep -n "## 来自 crystal-learn 的门禁" lead/SKILL.md` 命中 1 次；H1 注入段嵌入此段下方。
-
-### INV-H1-3 不写 cron / hook / 任何运行时机制
-
-> Why：硬继承 H4 INV-H4-3 + ADR-041 v1.0 红线；任何 cron/hook 都是把"AI 自管理"机制化的失败模式（70% prompt baseline 已够用）。
-> 验证：`grep -iE "cron|hook|schedule|metrics|setInterval|crontab" lead/SKILL.md` 在本次新增段命中 0。
-
-## §4 触发节奏（5 条物理化触发条件）
-
-按消费侧（AI 自识 → 主动调用 crystal-learn skill）：
-
-| # | 触发条件 | 触发动作 | Why |
-|---|----------|---------|-----|
-| 1 | 主仓发现新型 symptom（与 self-symptoms.md 既有 §4.x 不同根） | 立即调用 crystal-learn，输入 = 新 symptom + 历史相关 symptom | 新 symptom 是结晶学习的天然原料；不及时消化会累积变成 §4.7/§4.8 同根复发 |
-| 2 | 跨 PLAN 出现同类违规 ≥3 次（grep self-symptoms.md 同根模式数） | 调用 crystal-learn，输入 = 全部同根案例 | crystal-learn 升级规则要求 ≥2 案例；3 次触发"已是结构性偏差" |
-| 3 | reviewer 给出 P0/P1 notes 涉及"教训未学" | 调用 crystal-learn 消化，输入 = reviewer notes + 关联 ADR/PLAN | 防 H4 §过度 review 第 3 条（PASS_WITH_NOTES 含 P0 仍 BLOCK）变成"修个表面 commit 完事"，不真升级 invariant |
-| 4 | Gate 8 闭环前若 self-symptoms.md 自上次 crystal-learn 后新增 ≥3 条 | 调用 crystal-learn，输入 = 新增的 ≥3 条 | Gate 8 是天然消化 checkpoint；不能 PASS 一个 H 子计划但 symptoms 越积越多 |
-| 5 | 任何 ADR-H0 修订建议累积 ≥3 条未消化 | 调用 crystal-learn，输入 = 未消化建议清单 | 修订建议是 invariant 候选；累积不消化 = 4 周停摆症状复发 |
-
-**消费侧而非生产侧**：触发条件检查时机由"AI 自识"承担（lead/SKILL.md prompt-level 指令），不接受"等 Nature 提醒"。
-
-## §5 落地路径模板
-
-crystal-learn 输出 → 注入接收侧 SKILL.md：
-
-```
-crystal-learn output:
-  invariant_delta:
-    - confirmed: INV-X 描述（≥2 案例 + 跨场景）
-    - candidate: INV-Y 描述（仅 1 案例 + 系统性形状）
-    - new_instance: 已确认 INV 的新案例
-  target_injection_map:
-    - target: <skill 路径>
-    - directive: <≤3-5 行行动指令>
-    - rationale: <为什么放这里>
-        ↓
-注入动作:
-  1. 已确认 invariant → 加到对应 SKILL.md "## 来自 crystal-learn 的门禁" 段
-  2. 候选 invariant → 暂存 ADR-H0 修订建议表（待 ≥2 案例升级）
-  3. 新案例 → reference/invariant-instances.md（不动 active SKILL.md）
-  4. 注入后 target SKILL.md frontmatter `last_audited` 必须刷新
-```
-
-**模板硬规则**（写进 lead/SKILL.md 注入段）：
-- 不新建独立 ADR/PLAN 文件来"装" invariant（INV-4 真相源分裂红线）
-- 不在 active 执行层 SKILL.md 写完整理论（仅 ≤5 行行动指令）
-- 完整理论留 reference 文档（INV-2 格式断崖反例）
-
-## §6 受管资产 scope（H0.1 施工隔离）
-
-| # | 路径 | 改动类型 | 行数预算 |
-|---|------|---------|---------|
-| 1 | `.boll/skills/lead/SKILL.md` | 在 line 142 "## 来自 crystal-learn 的门禁" 段下方追加 "## 触发节奏（H1）" 子段 | ≤30 行 |
-| 2 | `docs/decisions/ADR-H1-crystal-learn-revival.md` | 新建本 ADR | ≤300 行 |
-| 3 | `docs/decisions/PLAN-H1-crystal-learn-revival.md` | 新建 PLAN | ≤500 行 |
-| 4 | `docs/decisions/tasks/PLAN-H1/WP-04/dogfood-output-20260428-{ts}.md` | dogfood 一次产出（§4.9 输入 → INV delta + injection map） | ≤80 行 |
-| 5 | `docs/decisions/tasks/PLAN-H1/WP-05/reviewer-verdict-20260428-{ts}.md` | reviewer 报告 | ≤200 行 |
-| 6 | `.boll/log/harness-self-symptoms.md` | append 新 §4.x 若 H1 实施期触发自指 | append-only |
-
-**scope 外严格不动**：crystal-learn skill 文件本身（89 行成熟契约）、其它 SKILL.md（dev/eng/eng-test/bridge/ops/task-arch/plan-lock 接收段）。任何这些资产的修订必须先经 crystal-learn 输出 → 进 ADR-H0 修订表 → 收尾整体 commit；H1 阶段不动。
-
-## §7 失败模式（FM）— 起草内防御
-
-### FM1：触发条件 5 条膨胀到 N 条
-
-复活成功后第一周容易膨胀（"再加一条"）。防御：INV-H1-1 硬数字 ≤5；超过必须先砍一条。
-
-### FM2：lead/SKILL.md 200 行超 truncate
-
-H4 已用掉 ~22 行段（line 158-180）；H1 再加 ≤30 行 → ~210 行风险。MEMORY.md scope policy（INV-H3-1）阈值 200。**预防措施**：H1 注入段写 ≤25 行（留 5 行 buffer）；正文最长不超过 27 行；段内全部用单行短句不用表格。
-
-### FM3：触发后未真做（"prompt 70% adherence" 上限）
-
-按 ADR-038 D11.2 schema-level vs prompt-level 数据，prompt 约束 ~70% adherence。意味着即使 lead/SKILL.md 写了触发条件，也有 30% 概率 AI 不调用 crystal-learn。**接受这个上限**（改 schema 化 = 写 hook = 违反 INV-H1-3）。**唯一升级条件**：连续 2 周观察期内有 ≥3 次触发条件命中但未调用记录在 self-symptoms.md → 升级讨论（不一定升级到 hook，可能调字辞）。
-
-## §8 与 H4 关系（边界）
-
-| 维度 | H4（已 closed）| H1（本 ADR）|
-|------|---------------|-------------|
-| 治理对象 | 行为偏好（黑话/推卸/过度 review/其它） | 元学习触发节奏 |
-| 主要资产 | lead/SKILL.md "## 行为治理（H4 三类清单）" | lead/SKILL.md "## 触发节奏（H1）" 子段 |
-| 哲学 | 调字不加机制 | 调字不加机制（同 H4） |
-| INV 数 | ≥10 条三类清单 | ≤5 条触发条件 |
-| 长度预算 | ≤30 行 | ≤25 行（FM2 buffer） |
-| 调用 crystal-learn? | 否（H4 直接物理化静态规则） | 是（H1 是 crystal-learn 的"触发协议"，本身不重写规则） |
-
-H4 是"把 6 条 memory feedback 物化"，H1 是"把元学习何时跑物化"。H4 静态、H1 元层。两者正交，互不动对方文件。
-
-## §9 不做什么
-
-- ❌ 不写 cron job 触发 crystal-learn（INV-H1-3 红线）
-- ❌ 不加 PostToolUse hook 检测"应触发"（INV-H1-3 红线）
-- ❌ 不建 dashboard 看 invariant 增长（同 ADR-041 反例 #3）
-- ❌ 不复活的"复活"是给 crystal-learn 加新功能；H1 只触发现有契约
-- ❌ 不在 crystal-learn skill 自己加治理段（学习层 ≠ 执行层；学习层只输出 invariant delta + injection map）
-- ❌ 不更新 crystal-learn target injection map 表（那是 crystal-learn 自己的工作产物，由 invariant 升级触发）
-
-## §10 H0 元规约 6+1 自检
-
-- **H0.1 施工隔离**：本 ADR scope 严格在 §6 列表内；不动 crystal-learn skill / 其它 SKILL.md 接收段 / hook / cron / metrics
-- **H0.2 节流**：本 ADR ≤300 行（验证：本文件 `wc -l`）；PLAN-H1 ≤500 行；H1 注入段 ≤25 行
-- **H0.3 执检分离**：起草人 ≠ reviewer；WP-05 spawn read-only subagent 收尾
-- **H0.4 自指禁止**：本 ADR 不写"待协调员决定 / TBD / 后续讨论"（H4 §推卸第 2 条）；不写 hook / metrics（H4 §3.6 FM2 + 本 ADR INV-H1-3）；起草前完整盘点（避 §4.7/§4.8 同根复发）
-- **H0.5 跨 H 协调**：见 PLAN-H1 §4 跨 H 登记表（H4 line 158-180 已用，H1 紧接其后；不重叠）
-- **H0.6 证据机械化**：所有 INV / DoD 给 grep / wc / awk 命令（PLAN-H1 §3 验证矩阵 + §7 verify bundle）
-- **H0.meta**：grep `\bH[2-8]\b` 仅协调登记表 + §8 H4 边界 + 自检命中（无前置依赖引用）
-
-## §11 dogfood 规划
-
-WP-04 用 self-symptoms.md §4.9（cross-plan-class race，新型号）作为首次触发输入：
-
-- 触发条件命中 = §4 表第 1 条（主仓发现新型 symptom）
-- 输入：§4.9 完整描述 + 处置段（ADR-H0 修订建议第 10 条）
-- 期望输出：
-  - `invariant_delta.candidate` = "跨 plan-class race"（仅 1 案例，候选不已确认）
-  - `target_injection_map.target` = ADR-H0 修订建议表 + lead/SKILL.md "## 来自 crystal-learn 的门禁" 段
-  - `target_injection_map.directive` = ≤5 行（"施工前 git status 核 merge state；H0.5 协调表扩展为跨 plan-class"）
-  - `target_injection_map.rationale` = 防 §4.9 同模式跨业务 PLAN 复发
-
-DoD 落地物 = WP-04 输出文档（path 在 §6 #4），证明 crystal-learn 触发协议可消费。

package/src/bollharness/docs/decisions/ADR-H2-identity-isolation.md

@@ -1,183 +0,0 @@
-# ADR-H2: harness 身份物理隔离（资产 frontmatter owner 字段）
-
-**状态**: Proposed
-**日期**: 2026-04-28
-**起草者**: Nature（AI 助手协助）
-**前置**: ADR-H0 元规约 / ADR-042 §5 ownership.yaml schema / ADR-H9 邮箱（H 系列拓扑 D 上游）
-**编号说明**: 独立 H 编号（不占主仓 ADR-XXX），H 系列 plan §3.3 表 line "ADR-042 D9 补丁" 是字面歧义——ADR-042 D9 已被"AGENTS.md 渐进加载"占用；本 ADR 实际补的是**新增 D10**，plan 字面"D9 补丁"按本 ADR 校准为"D10 新增"
-
----
-
-## 1. 决策本质
-
-**一句话**：资产侧 frontmatter `owner:` 字段是 schema-level 副真相源；与 ownership.yaml（D3 主真相源）互校，冲突时取最严；让"这个资产归谁"从资产文件本身可读，不再需要查 yaml 反推。
-
-**不变量 INV-H2-1**：任何被 multi-window 协作 owns 的资产文件（SKILL.md / agent.md / 关键 hook.ts）必须在 frontmatter 含 `window_owner: <window-id>` 字段；缺字段 = 视为 unowned shared（任何 window 不得写）。注：v1.1 修订前措辞为 `owner: <window-id>`，因与历史人名语义冲突改用 `window_owner`，详见 §3.1 修订记录。
-
-**不变量 INV-H2-2**：资产 frontmatter `window_owner` 与 ownership.yaml `windows[].owned_folders` 一致性由 lint 工具校验；不一致时取**最严**（以严限松：yaml 列了而 frontmatter 缺 → 加；frontmatter 标了而 yaml 没列 → yaml 补登记）。
-
-**不变量 INV-H2-3**：ownership.yaml 是**纯 schema 数据文件**，不混入协调员日志注释；日志走独立 append-only `docs/handoffs/ownership.changelog.md`，按 ISO8601 时间戳倒序追加。
-
----
-
-## 2. 动机（为什么 D3 yaml 单点真相源不够）
-
-### 2.1 D3 现状
-ADR-042 D3 建立"协调员唯一写入 ownership.yaml + AI 自识身份查 yaml"的模型。9 个月运行下来，三个症状反复出现（H 系列 plan §2.2 #8-10、#30-31）：
-
-1. **ownership.yaml 膨胀**：当前 979 行 = ~700 schema + ~130 协调员日志注释 + ~150 windows 实例。日志注释 prepend-style（最新在顶），导致 schema diff 噪声极大，git blame 失真。
-
-2. **资产侧零标记**：SKILL.md / hook / agent.md 文件本身不知道"我归谁"。AI 编辑 `src/scripts/hooks/inbox-write-ledger.ts` 时，必须先 `grep` ownership.yaml 反查 owner——这是**间接寻址**，compact 后 AI 失忆时容易跳过查询直接编辑（schema-level 物理隔离失效）。
-
-3. **跨 session add→commit race**：D2 commit 姿势标准化只到 commit 层，但 staged area 在 add 和 commit 之间会被并行 session reset/重 stage（feedback memory `parallel_session_git_race_post_commit_verify` 实证）。即便有 D3 yaml，资产侧无 owner 字段意味着 race 时无法在 add 时就拒绝（只能 commit 后审计 `git show --stat`）。
-
-### 2.2 schema-level 物理隔离的论据
-ADR-038 D11 + OpenDev arXiv 2603.05344：
-- prompt 约束 ~70% 遵从率
-- schema 约束 100% 遵从率（物理无法绕过）
-
-D3 yaml 是**单点 schema**——AI 必须主动查询才生效，等同于 prompt-level 约束（"你应该先查 yaml"）。资产侧 frontmatter owner 字段是**资产内嵌 schema**——AI 打开文件就看到，等同 100% 遵从（CC 读文件 = 必读 frontmatter）。
-
-INV-H2-1 把 D3 单点真相源升级为"yaml 主 + 资产副"双真相源，schema 层叠加：要绕过 INV-H2-1 必须同时改两处，hint 比改一处明显得多。
-
----
-
-## 3. 设计
-
-### 3.1 frontmatter `window_owner` 字段 schema
-
-> **字段名修订记录（v1.1, 2026-04-28）**：原草稿用 `owner` 字段名；WP-03 落地时发现 9 个候选 SKILL.md 已存 `owner: nature` 字段（人名 product owner 语义），与本 ADR 期望的 window 归属语义直接冲突。修订为 `window_owner` 避开历史字段碰撞，同时保留现有 `owner: nature` 字段不动（语义解耦：`owner` = product owner 人名 / `window_owner` = window-id schema 归属）。symptoms §4.7 + ADR-H0 修订建议 #9 已登记此 spec gap。
-
-| 字段 | 类型 | 必填 | 说明 |
-|------|------|------|------|
-| `window_owner` | string \| `shared` \| `unowned` | 是（受管资产） | window-id（如 `window-0-coordinator`）/ `shared`（多 window 共写需协调员仲裁）/ `unowned`（任何 window 不得写） |
-| `window_owner_since` | ISO8601 | 否 | 首次写入时间；用于 changelog 反查 |
-| `window_owner_adr` | string | 否 | 关联 ADR 路径；如 owner 决策有专门 ADR |
-
-**字段位置**：所有受管资产（详见 §3.2）的 frontmatter 顶层；与现有 `name` / `description` / `tools` / `owner`（如有）等同级。
-
-**与现有 `owner: nature` 字段关系**：解耦共存。`owner` 沿用既有人名语义（指 Nature 是 product owner），不动；`window_owner` 是新增字段，专管 schema-level window 归属。lint 工具（H6）按 `window_owner` 校验，不读 `owner`。
-
-**示例**：
-```yaml
----
-name: lead
-description: 流形开发流程统领
-owner: nature                                  # 既有字段，product owner = 人名（不动）
-window_owner: shared                           # H2 新增，schema-level window 归属
-window_owner_since: 2026-04-28T17:00+08:00
-window_owner_adr: docs/decisions/ADR-H2-identity-isolation.md
----
-```
-
-### 3.2 受管资产清单（H2 落地范围）
-
-INV-H2-1 不要求**所有** SKILL.md / agent.md / hook.ts 都标 owner——只要求受 multi-window 协作影响的资产。MVP 范围：
-
-| 资产类 | 路径 pattern | 受管标准 | DoD 数量 |
-|--------|-------------|----------|----------|
-| skill | `.boll/skills/*/SKILL.md` | lead skill 加载 + 跨 window 共写 | ≥ 3 |
-| hook | `src/scripts/hooks/*.ts` + `.boll/plugins/*/hooks/*.ts` | settings.json 注册 + 跨 window 触发 | ≥ 3 |
-| agent | `.boll/agents/*.md` + `.boll/plugins/*/agents/*.md` | TeamCreate 用 + multi-window spawn | 按需（H2 不强制 3 个） |
-
-后续 H 系列其他段（H4 prompt 治理、H6 状态健康度）需要时增量扩列。
-
-### 3.3 ownership.yaml 日志剥离
-
-**现状**：1-136 行 + 散落的 `# 协调员日志` 注释（共 ~130 行）混在 yaml 里。
-
-**改造**：
-- 保留 yaml 顶部 `version` / `schema` / `last_updated` / `last_updated_by_session` 5 行 frontmatter
-- 删除所有 `# YYYY-MM-DDTHH:MM 协调员` 注释段（搬到 changelog）
-- 新建 `docs/handoffs/ownership.changelog.md`（append-only，最新在顶；与 yaml 同 commit 同步）
-- yaml 顶部加一行 pointer：`# 协调员动作历史见 docs/handoffs/ownership.changelog.md`
-
-**预期效果**：yaml 行数 979 → ≤ 800（剥日志后 schema 主体保持，但去掉日志后可读性飞升；后续 windows 增长仍受 D5 限）。
-
-### 3.4 ADR-042 §3 新增 D10
-
-D10 文本（≤100 行 H0.2 budget）落 ADR-042 §3 末尾，不改 D1-D9 任一字。D10 内容：
-- 引用 INV-H2-1 / INV-H2-2 / INV-H2-3
-- 与 D3 关系（主副真相源 + 互校规则）
-- 与 D2 关系（commit 姿势 + frontmatter owner 双闸）
-- 与 D5 planning-time 隔离关系（planned_windows 也按受管资产标 owner）
-- 例外申请条款（参考 review-agent-isolation.md §"例外申请"格式）
-
-### 3.5 lint 工具（不在本 H 落地，登记 followup）
-
-INV-H2-2 一致性校验需 lint 工具（扫描资产 frontmatter `window_owner` ↔ ownership.yaml `owned_folders`）。本 H2 范围不交付 lint，登记 followup `guard-h2-lint-tooling`，由 H6（状态健康度）段处置。当前阶段一致性靠协调员手工核对 + reviewer Gate 抽样。
-
----
-
-## 4. 反对意见与取舍
-
-**反对 1**：frontmatter owner 字段会污染资产文件，影响 lead skill 加载。
-
-答：现有 SKILL.md frontmatter 已有 `name` / `description` / `tools` 等 5+ 字段，加 1 个 `owner` 字段不影响 CC 解析（CC 只识别已知字段，未知字段忽略）。lead skill 也只读 `name` / `description`，不会因 owner 字段而失效。
-
-**反对 2**：双真相源会发生 drift，单点 yaml 反而干净。
-
-答：drift 风险确实存在（INV-H2-2 互校规则就是为解决它），但单点 yaml 的"间接寻址"症状已造成实际 race（feedback memory 反复升级三次）。双真相源 + lint 是工程上权衡 drift 风险换取 schema-level 物理隔离的标准做法（参考 K8s 的 etcd ↔ object metadata 双真相源）。
-
-**反对 3**：`owner: shared` 字段语义模糊，谁仲裁？
-
-答：shared = 任何 window 写入前必须经协调员 ping 仲裁，仲裁结果落 changelog；不是"任何人随便写"。语义和 ADR-042 D8 交付形态分层一致。
-
-**反对 4**：H2 是不是又一个机制堆叠？ADR-041 v1.0 警告过。
-
-答：H2 不是行为偏好治理（那是 H4 prompt 范围）；H2 是物理隔离 schema 落地——schema-level 100% 遵从是 ADR-038 D11 已论证的硬门槛，不在 ADR-041 v1.0 警告的"机制堆叠"范畴。H 系列 plan §3.3.1 边界判定表已显式区分。
-
----
-
-## 5. 与其他 ADR / H 段的关系
-
-| 关系方 | 关系类型 | 说明 |
-|--------|----------|------|
-| ADR-042 §3 D1-D9 | 不冲突，新增 D10 | INV-H2-1/2/3 嵌入 D10；D1-D9 一字不改 |
-| ADR-042 §5 schema | 互校副真相源 | yaml `owned_folders` ↔ 资产 `window_owner` 双向校验 |
-| ADR-038 D11 | 同源精神 | schema-level >> prompt-level，H2 是 D11 在 ownership 域的具体应用 |
-| ADR-H0 元规约 | 自检 | H2 起草需走 H0.4 自指禁止 grep（已通过：本文件 grep "TBD\|后续讨论\|待协调员决定" 仅命中元层定义）+ H0.2 ≤300 行（本 ADR 目标行数）+ H0.5 跨 H 协调（已 grep gate 0 撞车） |
-| ADR-H9 inbox | 渠道复用 | H2 reviewer Gate 走 inbox 通信不靠人手 ping（H 系列 plan §3.5 总体执行守则） |
-| H4 prompt 治理 | 不重叠 | H4 治"语气/推卸"等 prompt-level 偏好；H2 治"资产归属"schema-level 物理 |
-| H6 状态健康度 | 后置依赖 | H2 落地后 H6 再做 lint 工具 + 状态文件清单（避免 lint 早出但资产无 owner 字段可校） |
-
----
-
-## 6. 实施清单（PLAN-H2 落地）
-
-详见 PLAN-H2-identity-isolation.md。骨架：
-- WP-01: owner frontmatter schema 文档定义（本 ADR §3.1 已含，PLAN 补 lint TODO）
-- WP-02: ownership.yaml 日志剥离 → ownership.changelog.md
-- WP-03: ≥3 skill + ≥3 hook 标 owner（最小集挑选标准 + 实施）
-- WP-04: ADR-042 §3 D10 补丁 ≤100 行
-- WP-05: 非起草 reviewer 复核（H0.3 执检分离）
-
----
-
-## 7. 验收（DoD）
-
-- [ ] 至少 3 个 skill frontmatter 含 `owner` 字段（H 系列 plan §3.3 H2 行硬规）
-- [ ] 至少 3 个 hook frontmatter 含 `owner` 字段（H 系列 plan §3.3 H2 行硬规）
-- [ ] ADR-042 §3 D10 补丁 ≤ 100 行（H 系列 plan §3.3 H2 行硬规）
-- [ ] ownership.yaml 主体行数比 H2 前减少（剥日志后 ≤ 800 行；当前 979）
-- [ ] ownership.changelog.md 创建并迁入历史日志（按时间戳倒序）
-- [ ] 本 ADR ≤ 300 行（H0.2 budget）
-- [ ] H0.4 自指禁止 grep：`grep -nE '(TBD|后续讨论|待协调员决定)' docs/decisions/ADR-H2-identity-isolation.md docs/decisions/PLAN-H2-identity-isolation.md` 仅元层定义命中（参 ADR-H0 §6 例 4）
-- [ ] 非起草 reviewer Gate 复核 PASS（H0.3 执检分离）
-
----
-
-## 8. 不做什么（吸收 ADR-041 v0.1→v0.3 教训 + ADR-H9 边界教训）
-
-- ❌ 不做 lint 自动校验工具（登记 followup `guard-h2-lint-tooling` → H6 段处置）
-- ❌ 不做 PreToolUse hook 拦截"无 owner frontmatter 资产被写"（hook IO 已在 H 系列 plan §3.1 H7 撤销后无新 hook 框架；强制拦截留待 H6 状态文件健康度）
-- ❌ 不做 owner 字段历史回溯（`git log --diff-filter` 重写 owner_since 不写，只对 H2 之后新加字段写 owner_since）
-- ❌ 不做"全部" SKILL.md / hook.ts 标 owner（MVP 只覆盖受 multi-window 协作影响的资产；§3.2 范围）
-- ❌ 不做 owner 字段值的 enum 约束（free-form string；INV-H2-2 互校时按 ownership.yaml 已知 window_id 反查；非已知值 reviewer Gate 时手工抓）
-
----
-
-## 9. 变更记录
-
-- 2026-04-28 初稿（Proposed）
-- 后续：实施完成后翻 Accepted（参 ADR-H9 模式：附录 A 验收记录 + 状态翻 Accepted 同 commit）

package/src/bollharness/docs/decisions/ADR-H3-memory-scope.md

@@ -1,133 +0,0 @@
-# ADR-H3: Memory Scope 分段 + 三态边界（memory / inbox / proposals）
-
-**状态**：Accepted（v1.1，reviewer PASS-WITH-NOTES 后随 v1.1 patch 转 Accepted；H 系列拓扑 D 第 4 个 ADR）
-**日期**：2026-04-28（v1.0 起草）/ 2026-04-28（v1.1 reviewer P1-1 + P2-2 修订）
-**关联**：ADR-H0 元规约 / ADR-H2 身份隔离 / ADR-H9 inbox 邮箱 / ADR-042 §3 D3/D6/D10 / ~/.boll/projects/-Users-nature------boll/memory/MEMORY.md
-**修订记录**：v1.1 把 INV-H3-2 文本由"单个 `## ` 段 ≤50 行"修订为双层限速"## 父段 ≤80 行 / ### 子段 ≤50 行"，原因见 §4 反对 4（reviewer-verdict-20260428-1741.md P1-1 / P2-2）。
-
-## 1. 决策本质
-
-把跨 session 的"信息持久化"分成 **三个明确状态**，把 MEMORY.md 主索引从"30+ 主题混编、276 行（已超 200 truncate）"重组为"按 scope 分段、≤200 行硬规、单段 ≤50 行"。
-
-> **memory** = user-level 长期 recall index（项目状态快照 + 硬性要求清单）
-> **inbox** = cross-session 短期消息（WP 完工 ping / block 升级，已由 H9 落地）
-> **proposals** = single-session self-trace（每 session 自留足迹，已存在）
-
-三者**生命周期递减**（memory > proposals > inbox）+ **信息凝固度递减**（memory > proposals > inbox）+ **协作半径递减**（memory cross-window > inbox peer-window > proposals self-window）。
-
-## 2. 不变量（INV-H3）
-
-- **INV-H3-1（主索引硬规）**：`MEMORY.md` 主索引文件总行数 **≤ 200**（CC 用户级 memory 加载的 truncate 阈值；line 200+ 物理上不被加载到 prompt context）
-- **INV-H3-2（单段双层限速，v1.1）**：`MEMORY.md` 内 **`## ` 父段总行数 ≤ 80**（含所有 `### ` 子段累计）+ **单个 `### ` 子段 ≤ 50 行**（含 metadata 与子项）。两层独立约束（父段 ≤80 与子段 ≤50 必须同时满足；不取最严，也不二选一）。超 80 父段 = 必须把整段下沉到 topic-specific .md，主索引仅留 1 行 pointer；超 50 子段 = 必须把该子段拆出去，父段保留其余子段。**v1.0 旧文本"`## ` 段 ≤50 行"是单层限速，v1.1 修订原因**：父段含多个 `### ` 子段时，单层口径会因为"按 ## 切" vs "按 ### 切"产生度量分歧（reviewer-verdict-20260428-1741.md P1-1）；现状"关键索引"段 73 行属指针索引大目录形态，硬拆反碎片化（§4 反对 4）。
-- **INV-H3-3（三态边界）**：跨 session 短期通信 **走 inbox 不走 memory**；single-session 自我足迹 **走 proposals 不走 memory**；MEMORY.md **不得新增**"待办 / ping / 进行中 WP" 语义条目（这些是 inbox/proposals 的语义）
-
-## 3. 设计
-
-### 3.1 三态边界判定表
-
-| 内容形态 | 走哪 | 生命周期 | 协作半径 |
-|---------|------|---------|---------|
-| 项目状态快照（"K3 已上线 / 计费已闭环"） | memory | 跨 session 长期，保留至项目终止/重大变更 | cross-window 共读 |
-| 硬性要求 / 教训沉淀（"不要反复确认"） | memory | 跨 session 长期，保留至 Nature 显式撤销 | cross-window 共读 |
-| 真相源 pointer（"K-Series Roadmap 在 docs/roadmaps/...") | memory | 跨 session 长期，保留至该真相源失效 | cross-window 共读 |
-| WP-N 完工 ping / block 升级 | **inbox**（走 H9） | 短期，主窗口 ack 后归档 | peer-window 单次定向 |
-| Single-session 决策足迹（"我决定用 X 方案"） | **proposals** | session 内 + 收敛期归档 | self-window 自留 |
-| "待协调员决定" / "TBD" / "下次再说" | **❌ 哪都不走** | H0.4 自指禁止 | 推卸语义直接禁 |
-
-**判定流程**：写新内容前先问"这是项目终止前都该被任何 session recall 的吗？" → Y = memory；"这是要 ping 主窗口/某个 peer 窗口的吗？" → Y = inbox；"这是我这个 session 的自我足迹吗？" → Y = proposals。
-
-### 3.2 MEMORY.md 主索引重组（≤200 行 / 单段 ≤50 行）
-
-**当前问题**：276 行（line 200+ truncate）+ "硬性要求"段 ~60 项混编 + 项目状态段长短不一。
-
-**重组规则**：
-1. **顶部固定**（≤30 行）：身份说明 + 近期重要真相源 pointer（最多 8 条，每条 1-2 行）
-2. **硬性要求**：拆分为 topic-specific .md（按主题），主索引段仅留 ≤30 行高频 highlights + 指针到完整清单 `feedback_index.md`（新增）
-3. **项目状态段**：每段 ≤30 行；超 30 行下沉到 `project_<name>_state.md`，主索引仅留 1 行 pointer + 1 行最新状态
-4. **生产环境 / Discovery / Crystallization** 等技术清单段：每段 ≤30 行，详细数据下沉
-5. **Pending Reminder**：禁止累积；每条触发条件满足后立即删除（不留尾巴）
-
-### 3.3 5 条旧 memory 迁移（最低 DoD）
-
-至少迁移 5 条：把 MEMORY.md 现有"硬性要求"段（~60 项）中最高频引用的 5 条 highlights 留主索引，其余下沉为 `feedback_index.md` 单文件目录索引（每条 1 行 pointer）。具体哪 5 条 highlight 由 PLAN-H3 §2 WP-03 起草时按"近 30 天 grep 频次"挑。
-
-### 3.4 与 ADR-H9 §6.5 的关系
-
-ADR-H9 §6.5 已签 **inbox vs proposals** 边界（peer-message vs self-trace）。本 ADR 补全 **memory vs inbox vs proposals** 三态完整图。三 ADR 关系：
-
-```
-长期 ─────────── 短期
-memory  >  proposals  >  inbox
-cross    self-session    peer-window
-window     trace          message
-recall   ← H3 INV-H3-3 →  ← ADR-H9 §6.5 →
-```
-
-### 3.5 与 ADR-042 D3/D6/D10 关系
-
-- **D3 session-owner 真相源**：本 ADR 是 D3 在 user-level memory 文件层的子约束（MEMORY.md 是 user-level；不入 ownership.yaml；本 ADR 决定其 scope 分段策略）
-- **D6 心跳契约**：H9 inbox 已物理化"心跳"（peer-window 显式消息）；本 ADR 进一步拒绝把 memory 当心跳通道用（INV-H3-3）
-- **D10 资产副真相源**：本 ADR **不**给 MEMORY.md 加 `window_owner` frontmatter——MEMORY.md 是 user-level shared resource，scope 分段在文件**内部**（按 `## ` 段），不在 frontmatter
-
-### 3.6 受管资产 scope（H0.1 施工隔离）
-
-本 ADR 施工范围严格限于：
-
-| 路径 | 动作 |
-|------|------|
-| `docs/decisions/ADR-H3-memory-scope.md` | 新增（本文件） |
-| `docs/decisions/PLAN-H3-memory-scope.md` | 新增（PLAN 起草） |
-| `~/.boll/projects/-Users-nature------boll/memory/MEMORY.md` | 重组（user-level，**不进主仓 commit**） |
-| `~/.boll/projects/-Users-nature------boll/memory/_backup/MEMORY-pre-H3-{ts}.md` | 备份（H 系列灰度 §3.3.3） |
-| `~/.boll/projects/-Users-nature------boll/memory/feedback_index.md` | 新增索引文件（user-level） |
-| `.boll/log/harness-self-symptoms.md` | append §4.x（如有） |
-| `docs/decisions/tasks/PLAN-H3/reviewer-verdict-*.md` | reviewer 落点 |
-
-**不动**：ownership.yaml / SKILL.md / hook / inbox/proposals/state schema / 任何业务代码。
-
-### 3.7 backup 与回滚
-
-按 H 系列灰度策略 §3.3.3：MEMORY.md 重组前先 `cp` 到 `_backup/MEMORY-pre-H3-{ts}.md`；7 天观察期内任何 vNext 报警可一键 `cp` 回滚。重组期间不删任何 topic-specific .md 文件（225 个 memory 文件保留），仅改 MEMORY.md 主索引指向。
-
-## 4. 反对意见与取舍
-
-**反对 1**：把"硬性要求"拆到 `feedback_index.md` = 多一跳读取；session 启动时 lazy-load 不上 = AI 漏教训。
-
-**取舍**：CC 已经物理 truncate 了 line 200+，"漏读"早已发生（仅是隐藏的）。重组后主索引留 5 条 highlights 是经验上"高频引用 = 高 ROI"；其余教训 grep 即可触发，不影响。如未来发现某条新增 highlight 必要，按 INV-H3-2 限速调换（不增长）。
-
-**反对 2**：单段 ≤50 行硬规会导致项目状态段反复挪到 .md 文件，徒增碎片。
-
-**取舍**：碎片本就是分布式信息组织的代价。MEMORY.md 是**索引**不是**正文**——索引只该列指针。当前"项目状态段"长是历史包袱，不是该有的形态。
-
-**反对 3**：H3 不给 MEMORY.md 加 `window_owner` 与 ADR-H2 D10 形成不一致。
-
-**取舍**：MEMORY.md 是 user-level shared resource，没有"哪个 window 拥有"语义；它是**所有 window 共读 + 所有 window 经协调员仲裁后写**——更接近 ADR-H2 §3.1 中 `window_owner: shared` 的语义，但因为它在 `~/.boll/projects/` 下、不在主仓，frontmatter 字段没意义（lint 工具够不到）。本 ADR 用文件**内**分段替代 frontmatter，是同一精神在不同物理介质上的投影。
-
-**反对 4（v1.1 新增）**：把 INV-H3-2 改成"## ≤80 / ### ≤50"双层限速 = 给"超长指针索引段"开后门，违背 v1.0 严格"≤50"初衷。
-
-**取舍**：v1.0 单层限速文本对"父段含多个 ### 子段"形态有度量分歧（按 ## 切 73 行违例 vs 按 ### 切 14 行合规）；reviewer-verdict-20260428-1741.md P1-1 明确指认。"关键索引"段当前 73 行是**指针索引大目录**形态（每行单 hook + topic-file 链接，无信息冗余），硬拆为 `topics_index.md` 反让用户多走一跳——违 INV-H3-1 初衷（主索引高密度 recall）。双层 ## ≤80 限速仍守住"父段不会无限膨胀"硬底（4 个 80 行段已 320 行 ≫ 200，CC truncate 自然兜底），且让"父段是指针 / 子段是教训"的现状形态合规。INV-H3-1（≤200 总行）+ INV-H3-3（三态边界）这两条**核心承诺不变**；v1.1 仅在 INV-H3-2 这一条度量口径上澄清。
-
-## 5. ADR-H0 元规约自检
-
-- **H0.1 施工隔离**：scope 列表见 §3.6（7 类路径，全在主仓内 `docs/decisions/`、`docs/decisions/tasks/`、`.boll/log/`，加上 user-level memory 重组路径）
-- **H0.2 节流限速**：本 ADR 目标 ≤ 300 行（截至本行约 ~150 行；实际终稿见末尾 wc -l）；PLAN-H3 ≤ 500 行
-- **H0.3 执检分离**：起草 = 本 session；reviewer 必为非起草 read-only subagent（PLAN-H3 WP 末位安排）
-- **H0.4 自指禁止**：H3 修"memory 噪声 / 跨 session 信息漂移"，本 ADR grep `TBD|后续讨论|待协调员决定` 仅元层定义命中（参 ADR-H0 §6 例 4）
-- **H0.5 跨子计划协调**：MEMORY.md 共改冲突已记入 H 系列 plan §3.4 冲突表；本 ADR 重组的是主索引**结构**（分段规则 + 单段限速 + 主索引 ≤200 行硬规），后续任何子计划在 H3 收口前不得对 MEMORY.md schema 结构再动手；H3 收口后的 schema 是后续子计划的工作面前提
-- **H0.6 证据机械化**：所有 INV / DoD 都给出 grep / wc / test 命令（见 PLAN-H3 §2 verify 命令段）
-- **H0.meta**：本 ADR 自身不引用 H1/H4/H5/H6/H8 未来产物（grep `\bH[14-8]\b` 仅本检查行命中）
-
-## 6. 关系
-
-- **ADR-H0 §3 元规约**：本 ADR 完全遵守 H0.1-H0.6 + H0.meta（自检见 §5）
-- **ADR-H2 §3.1 schema-level 隔离 + D10 资产副真相源**：H3 选择**不**走 frontmatter 路径，原因 §4 反对 3 已答辩
-- **ADR-H9 §6.5 inbox vs proposals 边界**：H3 §3.4 在此基础上扩展为三态完整图
-- **ADR-042 §3 D3/D6/D10**：H3 是 D3 + D6 在 user-level memory 介质上的具体化（§3.5）
-- **PLAN-H3-memory-scope.md**：本 ADR 工程实施真相源
-- **CC user-level memory 加载文档**：MEMORY.md 物理 200 行 truncate 行为（reference）
-
-## 7. 落地范围 + DoD
-
-- 详细 WP 拆解 + DoD：见 PLAN-H3 §2
-- H 系列 plan §3.3 H3 行：3 天估时；DoD 关键 = 每段 ≤50 行 + 5 条旧 memory 迁移 + 0 个"待定"
-- 末位 reviewer 签字：H0.3 执检分离强制