ProjectKuma/arise

Fork 0

第四批清单：31 条实现类落差 + 9 条待拍板（拆片时 AC 必须带 ADR 原文引文） #103

New issue

Closed

opened 2026-07-30 06:00:52 +00:00 by KumaAgent · 5 comments

KumaAgent commented

2026-07-30 06:00:52 +00:00

Member

这是「第四批」实现类的清单票。 标 状态：待拆片（本票归工单侧：产出物是若干 slice ticket，不是 PR）——拆片时有一条硬约束必须照做（见下），直接照着裁决理由实现会重犯已经犯过的错。

2026-08-03 更正：本票原先的 AC 要求「9 条待拍板 grill 完毕」，而正文又写着它们「不在本票范围」——自相矛盾，且会让 31 条的拆片被一轮尚未安排的 grill 挟持。已拆开：待拍板项全部移交 #108，本票只管 31 条实现类。

存在的理由：2026-07-29 全 ADR 查漏产出 77 条落差，前三批开票时把「第四批 = 剩余实现类 + 待拍板」当成兜底桶，而那个桶从来没有落成清单。结果两条高紧迫项既不在任何票里、也不在任何待办里，直到有人追问"第四批指的是哪个"才被发现（已补开 #102）。一个没有清单的兜底桶不是兜底，是漏斗。

全 77 条的完整去处（对账，合计必须等于 77）

去处	条数
#93 / #94 / #95（批次一，已合并/已关闭）	8
本票·实现类清单	31（其中 2 条高紧迫已由 #102 认领并关闭，实现后从本票划掉）
#101 留痕	28
#101 作废	1
#108 待人类拍板	9（其中「ADR-0008 注入分档」已于 08-03 单独拍板，见下）
合计	77 ✅

⚠️ 拆片时的硬约束：AC 必须逐字引用 ADR 原文

每一片的验收标准里，必须逐字引用它所实现的那条 ADR/CONTEXT.md 原文段落（注明文件 + 章节）。不是"参考了 ADR-00XX"，是把原句抄进 AC。

为什么是这条而不是"先跑一轮独立的裁决复核"：本票这 31 条的裁决层从未被复核过（查漏流水线是 扫描 → 对抗复核 → 裁决，对抗复核跑在裁决之前，只能验事实层）。事后对 15 条高风险裁决补跑的复核，8 条「作废」0 条站住。但「实现」类与「作废」类风险结构不同：作废错了是静默删除，没有下游会发现；实现错了会在写 AC 时回原文、以及两轴 review 的 Spec 轴逐条核验 AC 这两道网上暴露。所以纠错应该与产出绑在同一个动作上。

这条约束是可验证的——AC 里有没有原文引文，一眼看得出来。

它已经生效过一次：实现方回原文时抓到「画像注入无界」那条的裁决建议（加硬 top-k）正是 ADR 明文否决的方案，见下。

回原文时专查两种误读

(A) 机制归属被读错。 常见是把「注入侧/声明性/被动」读成「触发侧/决策式/主动」。抓手是原文的否定式措辞——「不驱动数值方程」「不新增出口」「不抬优先度」「零 LLM」「不新开 port」「core 不自算」「不需要新造…」——这类句子就是归属声明，也最容易被跳过。
(B) 裁决声称的前置里，有环节是原文自己已经答过的。 典型是「需要 A+B+C+D，无一存在」，而原文早已指定责任方。

两条已单独拍板的结论（直接影响拆片，按此执行）

一、ADR-0008 注入分档 → 恢复分档 + 新建 `lookup_relation` 工具

原设计是两档：显式边 + 同事件共现 → 自动注入；同群共现 → 按需。而 2026-07-13 那次更新以"修复漏实现"的名义把同群共现也做成了每轮自动（gather_implicit_relations），分档消失，作者当时很可能没意识到自己推翻了它。

被推翻的两条成本理由实测都成立：gather_implicit_relations 先对每个发言人各查一次 get_known_chat_ids（n 次 DB 往返），再两两 lookup_relationship_edge（n(n-1)/2 次），且跑在 run() 组装冻结快照的前台热路径上（红线1 要保护的地方）；同时「同群共现」是最弱的关系信号，却每轮自动占注入预算。

已拍板恢复分档。 但实测 lookup_relation 没有对应的模型工具，所以"按需"这一档目前没有机制——恢复分档必须连工具一起建。

摘掉 runtime_loop.py 两处自动调用（run() 与 _run_event_driven_turn，即 :977 与 :694）。
新建 lookup_relation 工具（仿 search_memory / search_stickers 两个既有"按需检索工具"先例）。
显式边 + 同事件共现保持自动，一行不改。
ADR-0008 追加更新节，记录 07-13 那次是无意推翻、本次恢复。

二、画像注入无界 → 按 ADR 已 ADOPTED 的方案做，不要加硬上限

裁决建议的「先加一个硬 top-k/字符预算（小，立刻止血）」是 ADR-0009 点名否决的备选方案，原文（adr/0009-memory-engineering.md）：

ADOPTED — 画像"常驻注入"边界改用自然遗忘曲线，而非硬上限：……本轮曾考虑给画像加一个类似 SullyOS "Room Plates" 的硬条目数上限，但最终采用更简洁的方案——把本 ADR 已有的"自然遗忘曲线"（recency×importance 降权……）概念扩展到画像"是否保留在常驻注入的冻结快照里"这个判断上：低 importance + 高 age 的画像条目自然跌出常驻注入范围，不需要新造一套硬上限+淘汰机制。

真实缺口是 ADOPTED 的那个机制从未实现，不是"没有上限"。

体量要如实重估：从「小」改为「中等 + schema 改动」。 实测 ProfileFact 字段只有 key / value / status / sensitive / source_ctx——没有 importance，也没有时间戳，而自然遗忘曲线的两个输入正是这两样。所以：

给画像加 importance：蹭 Delta 压缩那次 LLM 调用打标（事件记忆已有现成先例，零额外调用）。
给画像加时间戳（created_at / updated_at）。
在 render_profile_snapshot 的常驻注入判断里接上 recency × importance 降权。
不要加硬上限。 若实现期认为硬上限仍然必要，必须先在 ADR-0009 追加更新节推翻原决策，不能默不作声地做。
存量画像条目没有这两个字段，缺省行为要显式定义（别让旧条目因为 importance=None 被静默淘汰）。

顺带一条基建事实：本仓不随包分发 alembic 迁移（migrations/versions/ 只有 __init__.py，真实 schema 由 host 自己的迁移链管理），加可空列不需要在本仓补迁移文件。

拆片时的第二件事：先分组再拆

31 条里绝大多数是 紧迫=中，彼此独立性未评估、依赖关系未梳理。已知至少一处依赖：ADR-0012 的「平台撤回窗口」依赖 Sent Log 增加时间字段，两者在本清单里是分开的条目（chat_id 归属校验那半已由 #102 覆盖并关闭）。

Acceptance criteria

本票不产出代码。完成标志：

31 条按依赖关系与紧迫度分组，拆成若干可独立实现的 slice ticket；每片 AC 都带 ADR 原文引文。
上面两条已拍板结论按原样落进对应 slice。
本票关闭时，31 条每一条都能指向一个具体归宿，不允许再出现"剩余"这种没有清单的桶。

待人类拍板的那些不在本票 —— 全部移交 #108，本票不等它。

31 条实现类落差清单 → 见本票评论 1

> **这是「第四批」实现类的清单票。** 标 `状态：待拆片`（本票归**工单侧**：产出物是若干 slice ticket，不是 PR）——**拆片时有一条硬约束必须照做**（见下），直接照着裁决理由实现会重犯已经犯过的错。 > > **2026-08-03 更正**：本票原先的 AC 要求「9 条待拍板 grill 完毕」，而正文又写着它们「不在本票范围」——**自相矛盾**，且会让 31 条的拆片被一轮尚未安排的 grill 挟持。已拆开：**待拍板项全部移交 #108**，本票只管 31 条实现类。 > > 存在的理由：2026-07-29 全 ADR 查漏产出 77 条落差，前三批开票时把「第四批 = 剩余实现类 + 待拍板」当成兜底桶，而**那个桶从来没有落成清单**。结果两条高紧迫项既不在任何票里、也不在任何待办里，直到有人追问"第四批指的是哪个"才被发现（已补开 #102）。**一个没有清单的兜底桶不是兜底，是漏斗。** ## 全 77 条的完整去处（对账，合计必须等于 77） | 去处 | 条数 | |---|---| | #93 / #94 / #95（批次一，已合并/已关闭） | 8 | | **本票·实现类清单** | **31**（其中 2 条高紧迫已由 #102 认领并关闭，实现后从本票划掉） | | #101 留痕 | 28 | | #101 作废 | 1 | | **#108** 待人类拍板 | 9（其中「ADR-0008 注入分档」已于 08-03 单独拍板，见下） | | **合计** | **77** ✅ | ## ⚠️ 拆片时的硬约束：AC 必须逐字引用 ADR 原文 **每一片的验收标准里，必须逐字引用它所实现的那条 ADR/CONTEXT.md 原文段落**（注明文件 + 章节）。不是"参考了 ADR-00XX"，是把原句抄进 AC。 **为什么是这条而不是"先跑一轮独立的裁决复核"**：本票这 31 条的**裁决层从未被复核过**（查漏流水线是 `扫描 → 对抗复核 → 裁决`，对抗复核跑在裁决**之前**，只能验事实层）。事后对 15 条高风险裁决补跑的复核，8 条「作废」**0 条站住**。但「实现」类与「作废」类风险结构不同：作废错了是**静默删除**，没有下游会发现；实现错了会在**写 AC 时回原文**、以及**两轴 review 的 Spec 轴逐条核验 AC** 这两道网上暴露。所以纠错应该**与产出绑在同一个动作上**。这条约束是**可验证的**——AC 里有没有原文引文，一眼看得出来。 **它已经生效过一次**：实现方回原文时抓到「画像注入无界」那条的裁决建议（加硬 top-k）**正是 ADR 明文否决的方案**，见下。 ### 回原文时专查两种误读 - **(A) 机制归属被读错。** 常见是把「注入侧/声明性/被动」读成「触发侧/决策式/主动」。抓手是原文的**否定式措辞**——「不驱动数值方程」「不新增出口」「不抬优先度」「零 LLM」「不新开 port」「core 不自算」「**不需要新造…**」——**这类句子就是归属声明，也最容易被跳过**。 - **(B) 裁决声称的前置里，有环节是原文自己已经答过的。** 典型是「需要 A+B+C+D，无一存在」，而原文早已指定责任方。 ## 两条已单独拍板的结论（直接影响拆片，按此执行） ### 一、ADR-0008 注入分档 → **恢复分档 + 新建 `lookup_relation` 工具** 原设计是**两档**：显式边 + 同事件共现 → **自动注入**；同群共现 → **按需**。而 2026-07-13 那次更新以"修复漏实现"的名义把同群共现也做成了**每轮自动**（`gather_implicit_relations`），分档消失，作者当时很可能没意识到自己推翻了它。被推翻的两条成本理由**实测都成立**：`gather_implicit_relations` 先对每个发言人各查一次 `get_known_chat_ids`（**n 次 DB 往返**），再两两 `lookup_relationship_edge`（**n(n-1)/2 次**），且跑在 `run()` 组装冻结快照的**前台热路径**上（红线1 要保护的地方）；同时「同群共现」是最弱的关系信号，却每轮自动占注入预算。 **已拍板恢复分档。** 但实测 **`lookup_relation` 没有对应的模型工具**，所以"按需"这一档目前没有机制——恢复分档必须连工具一起建。 - [ ] 摘掉 `runtime_loop.py` 两处自动调用（`run()` 与 `_run_event_driven_turn`，即 `:977` 与 `:694`）。 - [ ] 新建 `lookup_relation` 工具（仿 `search_memory` / `search_stickers` 两个既有"按需检索工具"先例）。 - [ ] 显式边 + 同事件共现保持自动，一行不改。 - [ ] ADR-0008 追加更新节，记录 07-13 那次是无意推翻、本次恢复。 ### 二、画像注入无界 → **按 ADR 已 ADOPTED 的方案做，不要加硬上限** **裁决建议的「先加一个硬 top-k/字符预算（小，立刻止血）」是 ADR-0009 点名否决的备选方案**，原文（`adr/0009-memory-engineering.md`）： > **ADOPTED — 画像"常驻注入"边界改用自然遗忘曲线，而非硬上限**：……本轮**曾考虑**给画像加一个类似 SullyOS "Room Plates" 的**硬条目数上限**，但最终采用更简洁的方案——把本 ADR 已有的"自然遗忘曲线"（recency×importance 降权……）概念扩展到画像"是否保留在常驻注入的冻结快照里"这个判断上：低 importance + 高 age 的画像条目自然跌出常驻注入范围，**不需要新造一套硬上限+淘汰机制**。 **真实缺口是 ADOPTED 的那个机制从未实现**，不是"没有上限"。 **体量要如实重估：从「小」改为「中等 + schema 改动」。** 实测 `ProfileFact` 字段只有 `key` / `value` / `status` / `sensitive` / `source_ctx`——**没有 `importance`，也没有时间戳**，而自然遗忘曲线的两个输入正是这两样。所以： - [ ] 给画像加 `importance`：**蹭 Delta 压缩那次 LLM 调用打标**（事件记忆已有现成先例，零额外调用）。 - [ ] 给画像加时间戳（`created_at` / `updated_at`）。 - [ ] 在 `render_profile_snapshot` 的常驻注入判断里接上 recency × importance 降权。 - [ ] **不要加硬上限。** 若实现期认为硬上限仍然必要，必须先在 ADR-0009 追加更新节推翻原决策，不能默不作声地做。 - [ ] 存量画像条目没有这两个字段，缺省行为要显式定义（别让旧条目因为 `importance=None` 被静默淘汰）。 > 顺带一条基建事实：**本仓不随包分发 alembic 迁移**（`migrations/versions/` 只有 `__init__.py`，真实 schema 由 host 自己的迁移链管理），加可空列不需要在本仓补迁移文件。 ## 拆片时的第二件事：先分组再拆 31 条里绝大多数是 `紧迫=中`，彼此独立性未评估、依赖关系未梳理。**已知至少一处依赖**：ADR-0012 的「平台撤回窗口」依赖 Sent Log 增加时间字段，两者在本清单里是分开的条目（chat_id 归属校验那半已由 #102 覆盖并关闭）。 ## Acceptance criteria 本票**不产出代码**。完成标志： - [ ] 31 条按依赖关系与紧迫度分组，拆成若干可独立实现的 slice ticket；**每片 AC 都带 ADR 原文引文**。 - [ ] 上面两条已拍板结论按原样落进对应 slice。 - [ ] 本票关闭时，31 条**每一条都能指向一个具体归宿**，不允许再出现"剩余"这种没有清单的桶。 **待人类拍板的那些不在本票** —— 全部移交 **#108**，本票不等它。 --- # 31 条实现类落差清单 → 见本票评论 1

KumaAgent commented

2026-07-30 06:02:18 +00:00

Author

Member

附录：31 条实现类落差清单

这是 #103 正文引用的清单，是本票的一部分（正文有命令行长度上限，只能走评论）。

每条含原查漏给的断言与裁决理由。理由未经复核——开工前先按正文「第一件事」补一轮拿原文的裁决复核。

其中 2 条 紧迫=高 已由 #102 认领（ADR-0012 决策→2.触发/6.治理 的 chat_id 归属校验半、ADR-0024 决策节第 4 条 习得贴纸开关），实现后从本清单划掉。

1. ADR-0007 决策节（第 2 条子弹） [紧迫=中工作量=中]

断言：冷启动期门控收紧（沉默预算↓、兴趣门↑）、近乎纯反应式

裁决理由：断言仍成立且 ADR-0029 重申过（「靠连续阈值自然抑制」）。现状是方向相反：唯一接了 level 的是 apply_cold_start_floor（抬下限=放松），预算容量/回填速率/兴趣门阈值三个旋钮都是裸 config，与解锁档位无关。这不是可以留痕的事——ADR-0029 用「不再需要独立解锁标志位」换掉了阶段划分，代价就是「连续阈值必须真的连续」，现在这个代价没付，等于 ADR-0029 的核心论据被架空。改动面：让 budget_capacity/refill_rate/gate_threshold_base 吃 unlock level 做单调缩放，三个乘法项 + config 三项 + 门控测试。注意与 floor=1 不冲突（floor 管事件触发保底，缩放管整体稀疏度）。

2. ADR-0007 更新（2026-07-06 已读延迟窗+选择性回应，见 ADR-0017） [紧迫=中工作量=小]

断言：冷启动期 scope_ceiling 取更紧静态值 + 选择性回应 floor=1

裁决理由：floor=1 那半已由 apply_cold_start_floor 兑现，不算落差；真落差只有 scope_ceiling 那半，且它整体依附于「已读延迟窗根本没实现」这件事（见本表 33/57）。单独看它是三个 config 数字 + 一个 max()，改动面小到不值得单开 ticket，应并入已读延迟窗那一批一起做。不给留痕的理由：留痕会把一个「阶段位已接线、只差函数体」的东西描述成待开工项，误导下一个读者以为工作量很大。

3. ADR-0010 决策节「忘记我 / 隐私」第 1 条 [紧迫=中工作量=小]

断言：「忘记我」命令仅清短期记忆（会话上下文/checkpoint），不删长期

裁决理由：隐私类承诺不适用 YAGNI 折扣——用户不会「提需求」要一个忘记我，他们只会在没有的时候被伤害。且 CONTEXT.md/design.md/ADR 三处都把它当既成事实援引（design.md:443 甚至拿它当既定治理规则推导 Knowledge 的归属），explain.py:23 还留了前向兼容注释，是全仓被引用最多的未实现物之一。改动面小：一条命令 + drain 该 chat 的 delta buffer 与 outbox（core 里「短期记忆」就这两处），复用既有 _command_matcher。与本表 63 是同一件事，只开一个 ticket。附带建议：实现时顺手在 ADR 里澄清「不删长期」这个窄口径要如何对用户表述，否则命名会造成期待落差。

4. ADR-0007 决策节第 3 条 + 更新（2026-07-10 idea grill，见 ADR-0029） [紧迫=中工作量=小]

断言：逐步解锁：统一门控 → 三因子召回 → 关系网注入 → 自发目标

裁决理由：三因子召回这一级没有闸，实现期把它当恒解锁（progressive_unlock.py:45 的 docstring 自己写了「（已解锁）」），但没有任何 ADR/CONTEXT/design 记过这个演进。后果具体且是设计要防的那一种：档位 0 的新群第一轮就能召回其它 chat 的非敏感事件——事件池全局可见是 ADR-0009 的既定设计，正因为它全局，解锁闸才是唯一的冷启动护栏。改动面小：_full_frozen_snapshot 里 _recall_events 前加一道 level 判断 + 一个阈值常量。与 1、8 同批（都是「冷启动渐启真正生效」）。

5. ADR-0007 决策节第 1 条（后半句） [紧迫=低工作量=小]

断言：被 @ 时可做轻量自我介绍

裁决理由：根因比断言本身更值得修：is_cold_start 只流向预算下限，模型从来不知道自己处在冷启动。不只是自我介绍做不到，任何「新部署头几天该有的分寸」都没法由模型自行表达，而 ADR-0007 的整个立论是「保守渐启」。改动面很小：冻结快照/light context 里加一段声明性文本（同 ADR-0018「距上次交互/时段」的既有先例，不进任何数值方程，不违反中央调节器边界）。价值中等但成本极低，且是 1/7 同一批的自然搭车项。

6. ADR-0006「更新（2026-07-04 A1 反坍缩 grill）」节 [紧迫=中工作量=中]

断言：hit-rate 按尝试归一，双向自纠；噪声坍缩是主风险 → ceiling 承重

裁决理由：反坍缩闭环是开路的：写方（反思）只在私聊 Drive Tick 产生尝试，而那条路的级一分数恒 +inf，offset 抬到 ceiling 也拦不住任何东西。ADR 明写「ceiling 承重」，现在承重件不受力。gating.py:9 给 +inf 的理由（扫描循环已筛过冷场）本身站得住，所以修法有两个分叉：给周期触发一个真实的级一兴趣分，或把 offset 改为作用于沉默预算（ADR-0005 明确拒绝过两者合并，但「offset 调预算容量」不等于合并成单一标量，需要复核）。选哪条建议由实现 ticket 内 grill，不必上升到人类拍板。与 1 有耦合（都动级一阈值），排同一批更省。

7. ADR-0006「更新（2026-07-04 A1 反坍缩 grill）」节「双向信号」条 [紧迫=中工作量=中]

断言：反思消费正/负向弱反馈，标注 landed/fell flat/annoyed 喂 hit-rate

裁决理由：拆两半判：annoyed 分支不可达（依赖恒 0 的 valence），随第 9 条落地即自动修复，不单独计工作量；四路弱反馈（话题延续/energy 升/affinity 升/被追问）在 reflection.py 零读取点，其中 affinity 本身也恒 0（见 30），energy 只有群传染一路，即便接了也没什么可读。所以实际该做的是：随 B 批修好 annoyed，并在 ADR 追加更新节把四路弱反馈收窄为「已被 attempt_status 的时间戳判定 + valence 差值覆盖」。顺带清一处自相矛盾：proactive_attempt.py:52 说「交给反思的 LLM 分类判断」，reflection.py:8 说改成零-LLM valence 比较，同一实现里两段文档打架。

8. ADR-0005「双时间尺度」节「慢情感态 per-user」条 [紧迫=中工作量=中]

断言：per-user 慢情感态按发言人个人归属独立累积，不管群聊私聊持续更新

裁决理由：「不管群聊私聊」是明确断言，实现只有私聊 Drive Tick 这一条窄路径（入队点在 _evaluate_drive_tick_chat 内，而 _drive_tick 显式跳过群聊）——群聊里一个人说一万句也不会推动他自己的慢情感态。这条与第 9 条是同一批工作：valence/energy 的产出方一旦有了，per-user 慢层的写入点自然要从「反思结局」扩到「该用户的每次发言」。复核方对 dominance 那半的纠偏我采纳（用 Outcome 驱动 per-user dominance 正是 ADR 指定做法，别当 bug 返工）。改动面：写入点从反思扩到 runtime_loop 的发言处理路径。

9. ADR-0005「更新（2026-07-06 已读延迟窗，见 ADR-0017）」节 [紧迫=中工作量=中]

断言：energy 方程新增昼夜节律 nudge(time)，深夜额外向下

裁决理由：唯一的消费方是已读延迟窗，所以它与 33/57/42/2 是同一个 ticket 里的东西，单独作废或单独实现都不对。它的设计价值不在「深夜变慢」本身，而在守住「情感态是唯一中央调节器、gate 不单独读墙钟」这条边界——ADR-0017 专门拒绝过「深夜作为独立墙钟输入」。如果已读延迟窗实现时图省事直接读墙钟，就等于绕开这条边界开了先例。改动面中等：需要一个周期性或读时施加的时段项进 update_fast_state，而当前 update_fast_state 只有两个事件驱动调用点，没有「按时间自然演进」的驱动器，这块要新建。与 39/71 是同一件事。

10. ADR-0005「决策」节（中央调节器），同 CONTEXT.md/design.md [紧迫=中工作量=小]

断言：情感态调节打字速度、linger 概率、门控阈值、自我披露倾向、兴趣门阈值

裁决理由：五个靶子里三个已落地（打字速度/门控阈值/兴趣门），缺 linger 与自我披露。linger 归第 59 条（是产品拍板，不在这条里重复计）；自我披露那半的残留工作很小且独立：反应式全量上下文里只渲染了 relationship 快照（trust 封顶那半），三轴数值只在 drive_tick light context 里渲染——即模型在被搭话时看不到自己的 valence，「valence 倾向 + trust 封顶」两层分工只有一层在场。改动面：_full_frozen_snapshot 里加一段 render_affective_state_fact。前提是 valence 不再恒 0（第 9 条），否则渲染出来也是常数。本条不单独开 ticket，随 B 批搭车。

11. ADR-0009 —「更新（2026-07-11 第三轮）」节 ADOPTED 第 3 条 [紧迫=中工作量=中]

断言：画像常驻注入边界改用自然遗忘曲线（低 importance + 高 age 自然跌出）

裁决理由：render_profile_snapshot 是无条件全量渲染，无打分、无排序、无截断，上游 gather_profile_facts 也无上限，且 ProfileFact 连 importance 和时间戳都没有（updated_at 有列但 _to_fact 不带出来）。这是画像注入无界的主因，配上 21 的 tentative 只进不出，长跑部署下 prompt 会单调增长直到爆上下文。ADR-0015 已经明确拒绝过「触发注入不设上限」，同一条理由适用。建议按 ponytail 分两步：先加一个硬 top-k/字符预算（小，立刻止血），完整的 recency×importance 曲线作为第二步、且只在 ProfileFact 补齐 importance/age 之后做。与 21、31 合成一个 ticket。

12. ADR-0008 决策（四轴）+ 更新（2026-07-13，issue #36）权威代码落盘节 [紧迫=中工作量=中]

断言：tension（近期冲突，自然衰减防记仇）

裁决理由：apply_tension_conflict 零生产调用点，导致 tension_updated_at 恒 None，decayed_axes 每次早返回——不只是「值恒 0」，是整条「自然衰减防记仇」的兑现路径一次都走不到，而它仍被逐行渲染进关系区块（「紧张 0.00」）。更该修的是文档：ADR-0008 的 07-13 更新节宣称 issue #36「落地本 ADR 全部决策面」且「runtime_loop.run() 内 familiarity/trust/tension 驱动」，两处都不实（tension 无驱动，trust 驱动在 delta.py）。改动面中等：需要定「冲突」信号源——最省的做法是蹭 Delta 压缩那次 LLM 调用多产一个字段（同 sensitive 打标的既有形状），不新开调用。与 30、74 同批。

13. ADR-0008 决策（四轴） [紧迫=中工作量=中]

断言：affinity（≈旧 warmth，注入排序键）

裁决理由：排序键本身接上了（relationship.py:416），但 apply_affinity_delta 零生产调用点 → 全体候选 affinity 恒 0.0 → sorted 退化成插入顺序，「warmth 加权排序」在生产里不产生任何区分度。而这恰是 ADR-0008「保留 dxkuma ADR-0009 全部结构」要保住、且拒绝节明确不许回退的那条。与 29 同根同批（都缺信号源、都可以蹭 Delta 压缩产出）、同一个 ticket。留痕不够的证据就在本条：代码 docstring 老老实实写了「信号源留待后续 issue」，ADR 却宣称全部决策面已落地——留痕留在了没人读的那一侧。

14. ADR-0008 决策（保留 dxkuma ADR-0009 全部结构） [紧迫=中工作量=小]

断言：两层关系网、不上图、知情-gate、注入分档 + 独立封顶

裁决理由：复核方指出「独立封顶」有三种读法、其中两种已实现，这一点我认可；但我认为不必等作者裁定就该动手，因为客观缺陷独立成立：gather_relationship_edges 拉的是每个发言人的全部历史边、不限本批次，render_relationship_snapshot 三段全是无条件列表推导，长期群聊无界增长——这正是 ADR-0015「触发注入不设上限」被拒的同一个理由。所以补一个 arise_max_relationship_lines_per_turn 是无论那四个字原意为何都该做的事，顺手在 ADR-0008 给这个词加一句澄清即可。与 21、24 合成「注入体积治理」ticket，三处上限一次性补齐更省。

15. ADR-0017「决策 → 已读延迟窗」节 [紧迫=中工作量=小]

断言：独立新 gate；delay = clamp(f(energy), 0, scope_ceiling[scope])

裁决理由：性价比最高的一条：阶段位已接线（init.py:1324，位置也对，在 flush 之后、门控之前），read_delay.py 只是个 14 行的 return None，缺的就是函数体 + 两三个 config。ADR-0017 论证扎实且逐条拒绝了更便宜的替代（拉长 debounce、每条消息重置倒计时），ADR-0029 与 07-10 更新节两次主动确认它「不受影响、继续有效」——是被复审过两遍仍然有效的断言，不是遗留。tests/test_read_delay.py 把 no-op 固化成了断言（用例名直接叫 zero_delay_passthrough），这是留痕失效的又一例证。与 57、42、2、13/39/71 合成一个 ticket。

16. ADR-0015「更新（2026-07-10 第二轮）」节 + 决策节 [紧迫=中工作量=中]

断言：Knowledge 差异化合并，同一次 LLM 调用产出结构化融合

裁决理由：复核方跑出来的实证最有说服力：旧「豆豆是只猫，2岁，很粘人」+ 新「豆豆3岁了」→ 「…2岁，很粘人；豆豆3岁了」，过期事实与新事实并列留在同一条 canonical_meaning 里，随时间单调膨胀成自相矛盾的流水账，并且每轮触发注入都喂给模型。ADR 备注节留给实现期的是「融合 prompt 怎么写」，不是「要不要经过 LLM」。改动面中等：Delta 压缩前按 trigger_keywords 查已有条目、把它塞进同一次调用的输入、schema 加一个「合并后 canonical_meaning」出口——不新开 LLM 调用，与 ADR 原意一致。可与 29/30 的「蹭压缩调用多产字段」搭同一次 schema 改动。

17. ADR-0012「决策 → 2. 触发」节 + 「决策 → 6. 治理」节 [紧迫=高工作量=小]

断言：撤/改限当前会话 + 平台撤回窗口；硬约束只针对自己的、窗口内消息

裁决理由：chat_id 守卫那半是本批最便宜的真修复：_handle_self_recall/_handle_edit 拿到 entry 后从不比 entry.chat_id 与本轮 chat_id，复核方已实测在 gB 群用 gA 群的句柄撤回成功。虽然句柄是 uuid4 前 12 位、跨会话猜不到，但模型记错句柄归属比猜句柄现实得多，而 ADR 把它称为「结构不变量」、理由是「误撤比不撤更糟」。一行判断 + 一条测试。窗口那半依赖 37（Sent Log 无时间字段），同批做。tests/test_self_message_control.py 全部用例都在单会话内，是典型的「测试与被测守卫同构、守卫不存在也全绿」。

18. ADR-0012「决策 → 1. 两 regime」节 + 「6. 治理：默认 ON + 速率预算兜底」节 [紧迫=中工作量=小]

断言：per-chat 撤回/编辑动作速率上限，超预算返回 rate-limited

裁决理由：复核方最重要的一句要采纳：ADR-0012 取「默认 ON」的立论是「用户判硬约束 + 速率预算足够」两根并列支柱，而两根都没落地（硬约束的两个限定词见 35/37，速率预算见本条），只有「默认 ON」本身生效了。现有的两条上限是每消息结构性上限（self_recall≤1、edit≤N，防死循环），一个模型在一个群里对 100 条历史消息各撤一次，两条都不会触发——而 QQ 撤回是有风控的。所以这不是可以慢慢来的观察项，是一个已经生效的风险取舍缺了兜底。改动面小：per-chat 滑窗计数 + 一个 rate-limited 工具返回值。与 35/37/38 合成一个 ticket，连「默认 ON 是否维持」一起复核。

19. ADR-0017「决策 → 已读延迟窗」节（昼夜节律 nudge energy） [紧迫=中工作量=中]

断言：深夜经昼夜节律 nudge energy 接入，gate 不单独读墙钟

裁决理由：与 13、71 同一件事，随已读延迟窗 ticket 一起做。单独强调一点：这条的价值主要是守边界而非做功能——ADR-0017 的拒绝节专门否掉了「深夜作为独立墙钟输入」，理由是「给情感态之外开第二个调节输入源，为以后绕过情感态直接读环境信号开先例」。实现已读延迟窗时如果图省事直接读墙钟，恰好就踩这条。temporal_awareness.py:4 已经自觉地把自己（ADR-0018 声明性文本）和这条区分开了，说明边界意识在，缺的是执行。

20. ADR-0017「决策 → 已读延迟窗」节（冷启动收紧，经 ADR-0007 确认为解锁子轴） [紧迫=中工作量=小]

断言：渐进解锁未启阶段 scope_ceiling 取更紧静态值

裁决理由：与 2、33、57 是同一批里的同一件事（scope_ceiling 三档中的第三档），单独看就是一个 max()。不给留痕是因为：progressive_unlock.py:77 已经有一句前瞻 docstring 说「供已读延迟窗读取 scope_ceiling」——helper 侧的接口意图都写好了、消费方是空的，这种状态留痕只会再加一层「文档说有」。ADR-0017 备注节推迟的是三档的具体数值，不是三档的存在，不适用合法待定豁免。

21. ADR-0021 人设漂移守护「决策」节（判断方式 + 判断失败两条） [紧迫=中工作量=小]

断言：产出简短理由供 /why；判断失败 fail-closed 并记入 /why 标注

裁决理由：DriftVerdict.reason 是一个全仓零消费者的产出物，judge_failed 也无外部读点——四个调用点全部只取 status、reason 直接丢弃，而 persona_drift_guard.py:16 的模块文档把记录责任明确推给了调用方。后果是候选被静默吞掉：Delta 抽出的画像/事件/技能/贴纸候选被漂移守护否决时，运维和用户都看不到任何痕迹，而 fail-closed 意味着 LLM 一次超时就会吞掉一整批候选。/why 已落地，接一个字段进去是小改动。二选一也可以：如果决定不接，就把 reason 字段一并删掉——留一个没人读的字段是本仓已经犯过多次的模式。

22. ADR-0022 安全基线 —「更新（2026-07-08）：禁止编造未声明的核心身份事实」节 [紧迫=中工作量=小]

断言：安全基线固定文本补一条：不得编造 persona/Knowledge 之外的核心身份类事实

裁决理由：性价比极高：security.py 全文 15 行、四条 bullet，加第五条就是加一行字符串，且 SECURITY_BASELINE 已在三处注入点（反应式/drive tick/subagent）全覆盖。价值不小且不可替代——人设漂移守护只跑在记忆候选上，不看实时回复，所以「用户问你几岁 → 模型现编 18 岁 → 下轮又编 22 岁」这条最常见的人设崩塌路径当前无人拦。这是本批里唯一「几乎零成本、堵一条真实故障面」的条目，无理由不做。

23. ADR-0016（reference-resolution）「决策」节第 2 条 [紧迫=中工作量=小]

断言：Delta 压缩同一次 LLM 调用顺带产出 resolved_subject

裁决理由：整份 ADR 零实现，但改动面确实小：_EXTRACT_MEMORIES_TOOL 的 schema 加一个字段、instruction 加一句、_parse_event 多解析一路——不新开任何 LLM 调用，正是 ADR 指定的形状。价值实在：现在的替代品只是「认不出是谁就填 null」，即代词一律降级为丢信息，「他说他要去北京」这类事件会永久失去主体。这条应该和 34（Knowledge 合并）、29/30（关系轴信号源）搭同一次 Delta schema 改动一起做——四条都在同一个 tool schema 上加字段，分四次改是浪费。

24. ADR-0024（learned-stickers）「决策」节第 4 条 [紧迫=高工作量=小]

断言：默认关闭（opt-in），per-chat 开关，心智模型同 /settool

裁决理由：当前状态是整个 ADR-0024 子系统在真实部署里恒不执行：get_sticker_learning_enabled 无行时返回 False，而 set_ 在 src 零调用点、也没有对应命令——识别/去重/漂移守护/落库整条链永不触发，search_stickers 恒查空库。也就是 249 行 learned_sticker.py + 存储表 + 工具 schema + 一整套测试，产出为零。learned_sticker.py:12 把跟进挂在「ADR-0010 运营面建好后」，而运营面已在 issue #83 宣布全部落地，前置早就满足。改动面：仿 /settool 加一条命令，小。这是「小改动激活一整个已建好子系统」，排第一批。

25. ADR-0023 决策节第 1、2 条（+ ADR-0029 触发源清单「poke/reaction 命中本人」） [紧迫=中工作量=中]

断言：ConversationInput.interaction 走 reactive 主路径，不进 EnvironmentSignal

裁决理由：ingress 半边整条不存在（唯一构造入口 to_conversation_input 只在 on_message 里调，OB11 的戳一戳/表情回应是 notice，命不中），egress 半边却做全了——被戳了不知道，戳别人会。conversation.py:75 的 / 渲染代码永远不可达，测试全是手工构造的纯渲染单测。但实现时不要按 ADR-0023 的封闭形状做：ADR-0030 已把它改成开放形状 + interaction_renderers，应与已知种子（ADR-0030 整份未落地）合成一个 ticket 一次做对。这是改 ConversationInput 的破坏性变更，必须在首个 host 接入前完成。

26. ADR-0025 决策节最后一条「治理免费继承」 [紧迫=中工作量=中]

断言：追问自动继承沉默预算、反思闭环 hit-rate、渐进解锁等全部反坍缩护栏

裁决理由：三项里两项真的免费继承了（群聊追问与反应式调同一个 _evaluate_unified_gate），只有 hit-rate 落空：_run_group_followup_check 全程不调 record_proactive_attempt，所以群聊追问的结局永远不进反思闭环、永远不影响 offset。落差窄但确实，而且它与第 10 条同属「反思闭环收不到该收的样本」这个更大的问题。改动面中等而非小：消费侧 reflection.py:358 用 attempt.chat_id.removesuffix(".p") 反推 user_id，是按私聊形状写死的，群聊登记前要先处理这个口径。与 10 同批。

27. CONTEXT.md「已读延迟窗」条 + design.md 运行时 mermaid gate 节点 + 真人感层条目 [紧迫=中工作量=小]

断言：批次就绪后、组装上下文前的独立等待阶段，时长 = f(energy)，按 scope 封顶

裁决理由：与 33 同一件事，文档侧三处（含 mermaid 的 gate 节点）随实现一起兑现即可，不单独开条目。补一条判定依据供排期参考：这个仓有回填习惯（ADR-0006 为 inject_skills 写了未交付说明、ADR-0010 为 /why 写了两次），而已读延迟窗在 31 份 ADR + CONTEXT + design 里搜「未实现/未落地/阶段位」零命中——这里的沉默是真沉默，说明它不是被有意推迟的，是 Phase 4 收尾时漏掉的。

28. CONTEXT.md「忘记我（Forget-me）」条 + design.md 运营与质量条 + ADR-0010 决策节 [紧迫=中工作量=小]

断言：忘记我：用户命令，仅清短期记忆，不删长期

裁决理由：与第 6 条同一件事，只开一个 ticket。采纳复核方对 expected 的纠正：不要为它补经济 hook 前置钩子，core 无经济概念是符合设计的（ADR-0013 已把 host 侧补偿副作用判定为空集）。另注 design.md:561 的上线路线六阶段里没有它——这解释了它为什么一直没做（不属于任何已排期阶段），也说明「六阶段全部落地」不等于「design.md 承诺的东西全部落地」，这一点应写进 overall。

29. CONTEXT.md「已读延迟窗」与「快情感态」条 + design.md 真人感层「已读延迟窗 + 选择性回应」条 [紧迫=中工作量=中]

断言：energy 受资源态推送 + 群氛围传染 + 昼夜节律 nudge 影响；延迟时长 = f(energy)

裁决理由：三个成分分属三条不同判定，随各自 ticket 兑现后文档一并改：群传染已实现、昼夜节律 nudge 归 13/39（实现）、资源态推送归 16（作废）、f(energy) 归 33（实现）。这条本身不新增工作，但它是很好的验收清单——文档里一句话并列了四个输入源，实际只有一个在场，改完之后这句话应该是「二实一废一未定」的准确表述，而不是继续四个并列。

30. design.md 决策基线「低争议、直接采纳」列表 + 上线路线第 4 阶段 [紧迫=中工作量=小]

断言：智能体死循环熔断

裁决理由：真的没有：is_bot 只用于决策快照归集、贴纸学习排除、familiarity 统计排除，没有任何一处做连续计数或据此拦截；arise_max_edits_per_message 那条 ADR-0012 自己说是「接其精神」不是本机制；成本熔断是池预算不是失败/循环熔断，ADR-0011 的阈值表还把 run_limit 与「死循环熔断计数」并列成两项。虽然日常预算熔断兜住了经济损失、to_me() 也提高了触发门槛，但两个 bot 互相 @ 的场景在 QQ 群里并不罕见，后果是刷屏 + 烧完当天预算导致真人被降级。改动面很小：per-chat 连续 is_bot 消息计数，超 N 直接不进门控。第一批搭车。

31. CONTEXT.md「关系亲密度 / 关系多轴」条 + design.md 真人感层「关系多轴」条 + ADR-0008 决策节 [紧迫=中工作量=中]

断言：四轴 familiarity/trust/affinity/tension，4 轴封顶防膨胀

裁决理由：与 29+30 同一件事（affinity/tension 两轴恒中性零点），三份文档随实现一起兑现。这里补一条对实现方式的建议：两轴都缺「信号源」，而 Delta 压缩那次 LLM 调用已经在做 sensitive 打标和 importance 打分，多产两个信号（本批互动的亲和倾向 / 是否发生冲突）是同一次调用里最便宜的加法——把 29/30/34/52 四条并到一次 _EXTRACT_MEMORIES_TOOL schema 改动里做，比分四个 ticket 省得多，也避免四次改同一个 prompt 互相冲突。

# 附录：31 条实现类落差清单 > 这是 #103 正文引用的清单，是本票的一部分（正文有命令行长度上限，只能走评论）。 > > 每条含原查漏给的断言与裁决理由。**理由未经复核**——开工前先按正文「第一件事」补一轮拿原文的裁决复核。 > > 其中 2 条 `紧迫=高` 已由 #102 认领（`ADR-0012 决策→2.触发/6.治理` 的 chat_id 归属校验半、`ADR-0024 决策节第 4 条` 习得贴纸开关），实现后从本清单划掉。 ### 1. ADR-0007 决策节（第 2 条子弹） [紧迫=中工作量=中] **断言**：冷启动期门控收紧（沉默预算↓、兴趣门↑）、近乎纯反应式 **裁决理由**：断言仍成立且 ADR-0029 重申过（「靠连续阈值自然抑制」）。现状是方向相反：唯一接了 level 的是 apply_cold_start_floor（抬下限=放松），预算容量/回填速率/兴趣门阈值三个旋钮都是裸 config，与解锁档位无关。这不是可以留痕的事——ADR-0029 用「不再需要独立解锁标志位」换掉了阶段划分，代价就是「连续阈值必须真的连续」，现在这个代价没付，等于 ADR-0029 的核心论据被架空。改动面：让 budget_capacity/refill_rate/gate_threshold_base 吃 unlock level 做单调缩放，三个乘法项 + config 三项 + 门控测试。注意与 floor=1 不冲突（floor 管事件触发保底，缩放管整体稀疏度）。 ### 2. ADR-0007 更新（2026-07-06 已读延迟窗+选择性回应，见 ADR-0017） [紧迫=中工作量=小] **断言**：冷启动期 scope_ceiling 取更紧静态值 + 选择性回应 floor=1 **裁决理由**：floor=1 那半已由 apply_cold_start_floor 兑现，不算落差；真落差只有 scope_ceiling 那半，且它整体依附于「已读延迟窗根本没实现」这件事（见本表 33/57）。单独看它是三个 config 数字 + 一个 max()，改动面小到不值得单开 ticket，应并入已读延迟窗那一批一起做。不给留痕的理由：留痕会把一个「阶段位已接线、只差函数体」的东西描述成待开工项，误导下一个读者以为工作量很大。 ### 3. ADR-0010 决策节「忘记我 / 隐私」第 1 条 [紧迫=中工作量=小] **断言**：「忘记我」命令仅清短期记忆（会话上下文/checkpoint），不删长期 **裁决理由**：隐私类承诺不适用 YAGNI 折扣——用户不会「提需求」要一个忘记我，他们只会在没有的时候被伤害。且 CONTEXT.md/design.md/ADR 三处都把它当既成事实援引（design.md:443 甚至拿它当既定治理规则推导 Knowledge 的归属），explain.py:23 还留了前向兼容注释，是全仓被引用最多的未实现物之一。改动面小：一条命令 + drain 该 chat 的 delta buffer 与 outbox（core 里「短期记忆」就这两处），复用既有 _command_matcher。与本表 63 是同一件事，只开一个 ticket。附带建议：实现时顺手在 ADR 里澄清「不删长期」这个窄口径要如何对用户表述，否则命名会造成期待落差。 ### 4. ADR-0007 决策节第 3 条 + 更新（2026-07-10 idea grill，见 ADR-0029） [紧迫=中工作量=小] **断言**：逐步解锁：统一门控 → 三因子召回 → 关系网注入 → 自发目标 **裁决理由**：三因子召回这一级没有闸，实现期把它当恒解锁（progressive_unlock.py:45 的 docstring 自己写了「（已解锁）」），但没有任何 ADR/CONTEXT/design 记过这个演进。后果具体且是设计要防的那一种：档位 0 的新群第一轮就能召回其它 chat 的非敏感事件——事件池全局可见是 ADR-0009 的既定设计，正因为它全局，解锁闸才是唯一的冷启动护栏。改动面小：_full_frozen_snapshot 里 _recall_events 前加一道 level 判断 + 一个阈值常量。与 1、8 同批（都是「冷启动渐启真正生效」）。 ### 5. ADR-0007 决策节第 1 条（后半句） [紧迫=低工作量=小] **断言**：被 @ 时可做轻量自我介绍 **裁决理由**：根因比断言本身更值得修：is_cold_start 只流向预算下限，模型从来不知道自己处在冷启动。不只是自我介绍做不到，任何「新部署头几天该有的分寸」都没法由模型自行表达，而 ADR-0007 的整个立论是「保守渐启」。改动面很小：冻结快照/light context 里加一段声明性文本（同 ADR-0018「距上次交互/时段」的既有先例，不进任何数值方程，不违反中央调节器边界）。价值中等但成本极低，且是 1/7 同一批的自然搭车项。 ### 6. ADR-0006「更新（2026-07-04 A1 反坍缩 grill）」节 [紧迫=中工作量=中] **断言**：hit-rate 按尝试归一，双向自纠；噪声坍缩是主风险 → ceiling 承重 **裁决理由**：反坍缩闭环是开路的：写方（反思）只在私聊 Drive Tick 产生尝试，而那条路的级一分数恒 +inf，offset 抬到 ceiling 也拦不住任何东西。ADR 明写「ceiling 承重」，现在承重件不受力。gating.py:9 给 +inf 的理由（扫描循环已筛过冷场）本身站得住，所以修法有两个分叉：给周期触发一个真实的级一兴趣分，或把 offset 改为作用于沉默预算（ADR-0005 明确拒绝过两者合并，但「offset 调预算容量」不等于合并成单一标量，需要复核）。选哪条建议由实现 ticket 内 grill，不必上升到人类拍板。与 1 有耦合（都动级一阈值），排同一批更省。 ### 7. ADR-0006「更新（2026-07-04 A1 反坍缩 grill）」节「双向信号」条 [紧迫=中工作量=中] **断言**：反思消费正/负向弱反馈，标注 landed/fell flat/annoyed 喂 hit-rate **裁决理由**：拆两半判：annoyed 分支不可达（依赖恒 0 的 valence），随第 9 条落地即自动修复，不单独计工作量；四路弱反馈（话题延续/energy 升/affinity 升/被追问）在 reflection.py 零读取点，其中 affinity 本身也恒 0（见 30），energy 只有群传染一路，即便接了也没什么可读。所以实际该做的是：随 B 批修好 annoyed，并在 ADR 追加更新节把四路弱反馈收窄为「已被 attempt_status 的时间戳判定 + valence 差值覆盖」。顺带清一处自相矛盾：proactive_attempt.py:52 说「交给反思的 LLM 分类判断」，reflection.py:8 说改成零-LLM valence 比较，同一实现里两段文档打架。 ### 8. ADR-0005「双时间尺度」节「慢情感态 per-user」条 [紧迫=中工作量=中] **断言**：per-user 慢情感态按发言人个人归属独立累积，不管群聊私聊持续更新 **裁决理由**：「不管群聊私聊」是明确断言，实现只有私聊 Drive Tick 这一条窄路径（入队点在 _evaluate_drive_tick_chat 内，而 _drive_tick 显式跳过群聊）——群聊里一个人说一万句也不会推动他自己的慢情感态。这条与第 9 条是同一批工作：valence/energy 的产出方一旦有了，per-user 慢层的写入点自然要从「反思结局」扩到「该用户的每次发言」。复核方对 dominance 那半的纠偏我采纳（用 Outcome 驱动 per-user dominance 正是 ADR 指定做法，别当 bug 返工）。改动面：写入点从反思扩到 runtime_loop 的发言处理路径。 ### 9. ADR-0005「更新（2026-07-06 已读延迟窗，见 ADR-0017）」节 [紧迫=中工作量=中] **断言**：energy 方程新增昼夜节律 nudge(time)，深夜额外向下 **裁决理由**：唯一的消费方是已读延迟窗，所以它与 33/57/42/2 是同一个 ticket 里的东西，单独作废或单独实现都不对。它的设计价值不在「深夜变慢」本身，而在守住「情感态是唯一中央调节器、gate 不单独读墙钟」这条边界——ADR-0017 专门拒绝过「深夜作为独立墙钟输入」。如果已读延迟窗实现时图省事直接读墙钟，就等于绕开这条边界开了先例。改动面中等：需要一个周期性或读时施加的时段项进 update_fast_state，而当前 update_fast_state 只有两个事件驱动调用点，没有「按时间自然演进」的驱动器，这块要新建。与 39/71 是同一件事。 ### 10. ADR-0005「决策」节（中央调节器），同 CONTEXT.md/design.md [紧迫=中工作量=小] **断言**：情感态调节打字速度、linger 概率、门控阈值、自我披露倾向、兴趣门阈值 **裁决理由**：五个靶子里三个已落地（打字速度/门控阈值/兴趣门），缺 linger 与自我披露。linger 归第 59 条（是产品拍板，不在这条里重复计）；自我披露那半的残留工作很小且独立：反应式全量上下文里只渲染了 relationship 快照（trust 封顶那半），三轴数值只在 drive_tick light context 里渲染——即模型在被搭话时看不到自己的 valence，「valence 倾向 + trust 封顶」两层分工只有一层在场。改动面：_full_frozen_snapshot 里加一段 render_affective_state_fact。前提是 valence 不再恒 0（第 9 条），否则渲染出来也是常数。本条不单独开 ticket，随 B 批搭车。 ### 11. ADR-0009 —「更新（2026-07-11 第三轮）」节 ADOPTED 第 3 条 [紧迫=中工作量=中] **断言**：画像常驻注入边界改用自然遗忘曲线（低 importance + 高 age 自然跌出） **裁决理由**：render_profile_snapshot 是无条件全量渲染，无打分、无排序、无截断，上游 gather_profile_facts 也无上限，且 ProfileFact 连 importance 和时间戳都没有（updated_at 有列但 _to_fact 不带出来）。这是画像注入无界的主因，配上 21 的 tentative 只进不出，长跑部署下 prompt 会单调增长直到爆上下文。ADR-0015 已经明确拒绝过「触发注入不设上限」，同一条理由适用。建议按 ponytail 分两步：先加一个硬 top-k/字符预算（小，立刻止血），完整的 recency×importance 曲线作为第二步、且只在 ProfileFact 补齐 importance/age 之后做。与 21、31 合成一个 ticket。 ### 12. ADR-0008 决策（四轴）+ 更新（2026-07-13，issue #36）权威代码落盘节 [紧迫=中工作量=中] **断言**：tension（近期冲突，自然衰减防记仇） **裁决理由**：apply_tension_conflict 零生产调用点，导致 tension_updated_at 恒 None，decayed_axes 每次早返回——不只是「值恒 0」，是整条「自然衰减防记仇」的兑现路径一次都走不到，而它仍被逐行渲染进关系区块（「紧张 0.00」）。更该修的是文档：ADR-0008 的 07-13 更新节宣称 issue #36「落地本 ADR 全部决策面」且「runtime_loop.run() 内 familiarity/trust/tension 驱动」，两处都不实（tension 无驱动，trust 驱动在 delta.py）。改动面中等：需要定「冲突」信号源——最省的做法是蹭 Delta 压缩那次 LLM 调用多产一个字段（同 sensitive 打标的既有形状），不新开调用。与 30、74 同批。 ### 13. ADR-0008 决策（四轴） [紧迫=中工作量=中] **断言**：affinity（≈旧 warmth，注入排序键） **裁决理由**：排序键本身接上了（relationship.py:416），但 apply_affinity_delta 零生产调用点 → 全体候选 affinity 恒 0.0 → sorted 退化成插入顺序，「warmth 加权排序」在生产里不产生任何区分度。而这恰是 ADR-0008「保留 dxkuma ADR-0009 全部结构」要保住、且拒绝节明确不许回退的那条。与 29 同根同批（都缺信号源、都可以蹭 Delta 压缩产出）、同一个 ticket。留痕不够的证据就在本条：代码 docstring 老老实实写了「信号源留待后续 issue」，ADR 却宣称全部决策面已落地——留痕留在了没人读的那一侧。 ### 14. ADR-0008 决策（保留 dxkuma ADR-0009 全部结构） [紧迫=中工作量=小] **断言**：两层关系网、不上图、知情-gate、注入分档 + 独立封顶 **裁决理由**：复核方指出「独立封顶」有三种读法、其中两种已实现，这一点我认可；但我认为不必等作者裁定就该动手，因为客观缺陷独立成立：gather_relationship_edges 拉的是每个发言人的全部历史边、不限本批次，render_relationship_snapshot 三段全是无条件列表推导，长期群聊无界增长——这正是 ADR-0015「触发注入不设上限」被拒的同一个理由。所以补一个 arise_max_relationship_lines_per_turn 是无论那四个字原意为何都该做的事，顺手在 ADR-0008 给这个词加一句澄清即可。与 21、24 合成「注入体积治理」ticket，三处上限一次性补齐更省。 ### 15. ADR-0017「决策 → 已读延迟窗」节 [紧迫=中工作量=小] **断言**：独立新 gate；delay = clamp(f(energy), 0, scope_ceiling[scope]) **裁决理由**：性价比最高的一条：阶段位已接线（__init__.py:1324，位置也对，在 flush 之后、门控之前），read_delay.py 只是个 14 行的 return None，缺的就是函数体 + 两三个 config。ADR-0017 论证扎实且逐条拒绝了更便宜的替代（拉长 debounce、每条消息重置倒计时），ADR-0029 与 07-10 更新节两次主动确认它「不受影响、继续有效」——是被复审过两遍仍然有效的断言，不是遗留。tests/test_read_delay.py 把 no-op 固化成了断言（用例名直接叫 zero_delay_passthrough），这是留痕失效的又一例证。与 57、42、2、13/39/71 合成一个 ticket。 ### 16. ADR-0015「更新（2026-07-10 第二轮）」节 + 决策节 [紧迫=中工作量=中] **断言**：Knowledge 差异化合并，同一次 LLM 调用产出结构化融合 **裁决理由**：复核方跑出来的实证最有说服力：旧「豆豆是只猫，2岁，很粘人」+ 新「豆豆3岁了」→ 「…2岁，很粘人；豆豆3岁了」，过期事实与新事实并列留在同一条 canonical_meaning 里，随时间单调膨胀成自相矛盾的流水账，并且每轮触发注入都喂给模型。ADR 备注节留给实现期的是「融合 prompt 怎么写」，不是「要不要经过 LLM」。改动面中等：Delta 压缩前按 trigger_keywords 查已有条目、把它塞进同一次调用的输入、schema 加一个「合并后 canonical_meaning」出口——不新开 LLM 调用，与 ADR 原意一致。可与 29/30 的「蹭压缩调用多产字段」搭同一次 schema 改动。 ### 17. ADR-0012「决策 → 2. 触发」节 + 「决策 → 6. 治理」节 [紧迫=高工作量=小] **断言**：撤/改限当前会话 + 平台撤回窗口；硬约束只针对自己的、窗口内消息 **裁决理由**：chat_id 守卫那半是本批最便宜的真修复：_handle_self_recall/_handle_edit 拿到 entry 后从不比 entry.chat_id 与本轮 chat_id，复核方已实测在 gB 群用 gA 群的句柄撤回成功。虽然句柄是 uuid4 前 12 位、跨会话猜不到，但模型记错句柄归属比猜句柄现实得多，而 ADR 把它称为「结构不变量」、理由是「误撤比不撤更糟」。一行判断 + 一条测试。窗口那半依赖 37（Sent Log 无时间字段），同批做。tests/test_self_message_control.py 全部用例都在单会话内，是典型的「测试与被测守卫同构、守卫不存在也全绿」。 ### 18. ADR-0012「决策 → 1. 两 regime」节 + 「6. 治理：默认 ON + 速率预算兜底」节 [紧迫=中工作量=小] **断言**：per-chat 撤回/编辑动作速率上限，超预算返回 rate-limited **裁决理由**：复核方最重要的一句要采纳：ADR-0012 取「默认 ON」的立论是「用户判硬约束 + 速率预算足够」两根并列支柱，而两根都没落地（硬约束的两个限定词见 35/37，速率预算见本条），只有「默认 ON」本身生效了。现有的两条上限是每消息结构性上限（self_recall≤1、edit≤N，防死循环），一个模型在一个群里对 100 条历史消息各撤一次，两条都不会触发——而 QQ 撤回是有风控的。所以这不是可以慢慢来的观察项，是一个已经生效的风险取舍缺了兜底。改动面小：per-chat 滑窗计数 + 一个 rate-limited 工具返回值。与 35/37/38 合成一个 ticket，连「默认 ON 是否维持」一起复核。 ### 19. ADR-0017「决策 → 已读延迟窗」节（昼夜节律 nudge energy） [紧迫=中工作量=中] **断言**：深夜经昼夜节律 nudge energy 接入，gate 不单独读墙钟 **裁决理由**：与 13、71 同一件事，随已读延迟窗 ticket 一起做。单独强调一点：这条的价值主要是守边界而非做功能——ADR-0017 的拒绝节专门否掉了「深夜作为独立墙钟输入」，理由是「给情感态之外开第二个调节输入源，为以后绕过情感态直接读环境信号开先例」。实现已读延迟窗时如果图省事直接读墙钟，恰好就踩这条。temporal_awareness.py:4 已经自觉地把自己（ADR-0018 声明性文本）和这条区分开了，说明边界意识在，缺的是执行。 ### 20. ADR-0017「决策 → 已读延迟窗」节（冷启动收紧，经 ADR-0007 确认为解锁子轴） [紧迫=中工作量=小] **断言**：渐进解锁未启阶段 scope_ceiling 取更紧静态值 **裁决理由**：与 2、33、57 是同一批里的同一件事（scope_ceiling 三档中的第三档），单独看就是一个 max()。不给留痕是因为：progressive_unlock.py:77 已经有一句前瞻 docstring 说「供已读延迟窗读取 scope_ceiling」——helper 侧的接口意图都写好了、消费方是空的，这种状态留痕只会再加一层「文档说有」。ADR-0017 备注节推迟的是三档的具体数值，不是三档的存在，不适用合法待定豁免。 ### 21. ADR-0021 人设漂移守护「决策」节（判断方式 + 判断失败两条） [紧迫=中工作量=小] **断言**：产出简短理由供 /why；判断失败 fail-closed 并记入 /why 标注 **裁决理由**：DriftVerdict.reason 是一个全仓零消费者的产出物，judge_failed 也无外部读点——四个调用点全部只取 status、reason 直接丢弃，而 persona_drift_guard.py:16 的模块文档把记录责任明确推给了调用方。后果是候选被静默吞掉：Delta 抽出的画像/事件/技能/贴纸候选被漂移守护否决时，运维和用户都看不到任何痕迹，而 fail-closed 意味着 LLM 一次超时就会吞掉一整批候选。/why 已落地，接一个字段进去是小改动。二选一也可以：如果决定不接，就把 reason 字段一并删掉——留一个没人读的字段是本仓已经犯过多次的模式。 ### 22. ADR-0022 安全基线 —「更新（2026-07-08）：禁止编造未声明的核心身份事实」节 [紧迫=中工作量=小] **断言**：安全基线固定文本补一条：不得编造 persona/Knowledge 之外的核心身份类事实 **裁决理由**：性价比极高：security.py 全文 15 行、四条 bullet，加第五条就是加一行字符串，且 SECURITY_BASELINE 已在三处注入点（反应式/drive tick/subagent）全覆盖。价值不小且不可替代——人设漂移守护只跑在**记忆候选**上，不看实时回复，所以「用户问你几岁 → 模型现编 18 岁 → 下轮又编 22 岁」这条最常见的人设崩塌路径当前无人拦。这是本批里唯一「几乎零成本、堵一条真实故障面」的条目，无理由不做。 ### 23. ADR-0016（reference-resolution）「决策」节第 2 条 [紧迫=中工作量=小] **断言**：Delta 压缩同一次 LLM 调用顺带产出 resolved_subject **裁决理由**：整份 ADR 零实现，但改动面确实小：_EXTRACT_MEMORIES_TOOL 的 schema 加一个字段、instruction 加一句、_parse_event 多解析一路——不新开任何 LLM 调用，正是 ADR 指定的形状。价值实在：现在的替代品只是「认不出是谁就填 null」，即代词一律降级为丢信息，「他说他要去北京」这类事件会永久失去主体。这条应该和 34（Knowledge 合并）、29/30（关系轴信号源）搭同一次 Delta schema 改动一起做——四条都在同一个 tool schema 上加字段，分四次改是浪费。 ### 24. ADR-0024（learned-stickers）「决策」节第 4 条 [紧迫=高工作量=小] **断言**：默认关闭（opt-in），per-chat 开关，心智模型同 /settool **裁决理由**：当前状态是整个 ADR-0024 子系统在真实部署里恒不执行：get_sticker_learning_enabled 无行时返回 False，而 set_ 在 src 零调用点、也没有对应命令——识别/去重/漂移守护/落库整条链永不触发，search_stickers 恒查空库。也就是 249 行 learned_sticker.py + 存储表 + 工具 schema + 一整套测试，产出为零。learned_sticker.py:12 把跟进挂在「ADR-0010 运营面建好后」，而运营面已在 issue #83 宣布全部落地，前置早就满足。改动面：仿 /settool 加一条命令，小。这是「小改动激活一整个已建好子系统」，排第一批。 ### 25. ADR-0023 决策节第 1、2 条（+ ADR-0029 触发源清单「poke/reaction 命中本人」） [紧迫=中工作量=中] **断言**：ConversationInput.interaction 走 reactive 主路径，不进 EnvironmentSignal **裁决理由**：ingress 半边整条不存在（唯一构造入口 to_conversation_input 只在 on_message 里调，OB11 的戳一戳/表情回应是 notice，命不中），egress 半边却做全了——被戳了不知道，戳别人会。conversation.py:75 的 <poke>/<reaction> 渲染代码永远不可达，测试全是手工构造的纯渲染单测。但实现时不要按 ADR-0023 的封闭形状做：ADR-0030 已把它改成开放形状 + interaction_renderers，应与已知种子（ADR-0030 整份未落地）合成一个 ticket 一次做对。这是改 ConversationInput 的破坏性变更，必须在首个 host 接入前完成。 ### 26. ADR-0025 决策节最后一条「治理免费继承」 [紧迫=中工作量=中] **断言**：追问自动继承沉默预算、反思闭环 hit-rate、渐进解锁等全部反坍缩护栏 **裁决理由**：三项里两项真的免费继承了（群聊追问与反应式调同一个 _evaluate_unified_gate），只有 hit-rate 落空：_run_group_followup_check 全程不调 record_proactive_attempt，所以群聊追问的结局永远不进反思闭环、永远不影响 offset。落差窄但确实，而且它与第 10 条同属「反思闭环收不到该收的样本」这个更大的问题。改动面中等而非小：消费侧 reflection.py:358 用 attempt.chat_id.removesuffix(".p") 反推 user_id，是按私聊形状写死的，群聊登记前要先处理这个口径。与 10 同批。 ### 27. CONTEXT.md「已读延迟窗」条 + design.md 运行时 mermaid gate 节点 + 真人感层条目 [紧迫=中工作量=小] **断言**：批次就绪后、组装上下文前的独立等待阶段，时长 = f(energy)，按 scope 封顶 **裁决理由**：与 33 同一件事，文档侧三处（含 mermaid 的 gate 节点）随实现一起兑现即可，不单独开条目。补一条判定依据供排期参考：这个仓有回填习惯（ADR-0006 为 inject_skills 写了未交付说明、ADR-0010 为 /why 写了两次），而已读延迟窗在 31 份 ADR + CONTEXT + design 里搜「未实现/未落地/阶段位」零命中——这里的沉默是真沉默，说明它不是被有意推迟的，是 Phase 4 收尾时漏掉的。 ### 28. CONTEXT.md「忘记我（Forget-me）」条 + design.md 运营与质量条 + ADR-0010 决策节 [紧迫=中工作量=小] **断言**：忘记我：用户命令，仅清短期记忆，不删长期 **裁决理由**：与第 6 条同一件事，只开一个 ticket。采纳复核方对 expected 的纠正：不要为它补经济 hook 前置钩子，core 无经济概念是符合设计的（ADR-0013 已把 host 侧补偿副作用判定为空集）。另注 design.md:561 的上线路线六阶段里没有它——这解释了它为什么一直没做（不属于任何已排期阶段），也说明「六阶段全部落地」不等于「design.md 承诺的东西全部落地」，这一点应写进 overall。 ### 29. CONTEXT.md「已读延迟窗」与「快情感态」条 + design.md 真人感层「已读延迟窗 + 选择性回应」条 [紧迫=中工作量=中] **断言**：energy 受资源态推送 + 群氛围传染 + 昼夜节律 nudge 影响；延迟时长 = f(energy) **裁决理由**：三个成分分属三条不同判定，随各自 ticket 兑现后文档一并改：群传染已实现、昼夜节律 nudge 归 13/39（实现）、资源态推送归 16（作废）、f(energy) 归 33（实现）。这条本身不新增工作，但它是很好的验收清单——文档里一句话并列了四个输入源，实际只有一个在场，改完之后这句话应该是「二实一废一未定」的准确表述，而不是继续四个并列。 ### 30. design.md 决策基线「低争议、直接采纳」列表 + 上线路线第 4 阶段 [紧迫=中工作量=小] **断言**：智能体死循环熔断 **裁决理由**：真的没有：is_bot 只用于决策快照归集、贴纸学习排除、familiarity 统计排除，没有任何一处做连续计数或据此拦截；arise_max_edits_per_message 那条 ADR-0012 自己说是「接其精神」不是本机制；成本熔断是池预算不是失败/循环熔断，ADR-0011 的阈值表还把 run_limit 与「死循环熔断计数」并列成两项。虽然日常预算熔断兜住了经济损失、to_me() 也提高了触发门槛，但两个 bot 互相 @ 的场景在 QQ 群里并不罕见，后果是刷屏 + 烧完当天预算导致真人被降级。改动面很小：per-chat 连续 is_bot 消息计数，超 N 直接不进门控。第一批搭车。 ### 31. CONTEXT.md「关系亲密度 / 关系多轴」条 + design.md 真人感层「关系多轴」条 + ADR-0008 决策节 [紧迫=中工作量=中] **断言**：四轴 familiarity/trust/affinity/tension，4 轴封顶防膨胀 **裁决理由**：与 29+30 同一件事（affinity/tension 两轴恒中性零点），三份文档随实现一起兑现。这里补一条对实现方式的建议：两轴都缺「信号源」，而 Delta 压缩那次 LLM 调用已经在做 sensitive 打标和 importance 打分，多产两个信号（本批互动的亲和倾向 / 是否发生冲突）是同一次调用里最便宜的加法——把 29/30/34/52 四条并到一次 _EXTRACT_MEMORIES_TOOL schema 改动里做，比分四个 ticket 省得多，也避免四次改同一个 prompt 互相冲突。

KumaAgent added the

状态：待评估

label

2026-07-30 06:02:21 +00:00

KumaAgent commented

2026-07-30 06:19:42 +00:00

Author

Member

两处清单修订（都是同一个漏斗形状，趁早堵掉）

一、ADR-0012 那条只被 #102 部分认领，别整条划掉

清单附录里那句「其中 2 条 紧迫=高 已由 #102 认领……实现后从本清单划掉」对 ADR-0024 那条成立，对 ADR-0012「决策 → 2. 触发」+「6. 治理」那条不成立。

那条落差的断言是两半：

撤/改限当前会话 + 平台撤回窗口；硬约束只针对自己的、窗口内消息

chat_id 归属校验那半 → #102 在做（一行判断 + 跨 chat 回归测试）
平台撤回窗口那半 → 不在 #102，它依赖 Sent Log 增加时间字段（本清单里的另一条独立条目）

所以：#102 合并后，这条只划掉 chat_id 那半，条目本身留在清单里，把 claim 改成只剩「平台撤回窗口 + 窗口内硬约束」。

（这处模糊是我在 #102/#103 之间新造的——#102 的 Not-in-scope 写了"窗口半属第四批，见 #103"，而 #103 的附录又说"实现后整条划掉"，两边对不上。同一个"没有清单/边界不清就会掉东西"的机制，这次在两张票之间发生。）

二、清单新增第 32 条：`RuntimeLoop` 44 参数构造函数收成 config dataclass

来源不是 ADR 查漏，是同日 src/ 内部结构实测（AST 全量）。#97 正文里提到了它、并写明「与拆不拆类是两个问题，不在本票」——但没说在哪张票，于是它成了又一个没有归宿的条目。现在归到本清单。

事实（实测，非估计）：RuntimeLoop 有 44 个方法、44 个构造参数（全 keyword-only，构造函数本身 100 行纯搬运）。其中 29 个字段只被恰好一个方法读——例如 _typing_base_delay/_typing_per_char_delay/_typing_energy_jitter 只给 _typing_delay，_recall_half_life_seconds/_recall_weights 只给 _scored_events，_familiarity_* 三个只给 run，_delegate_max_rounds/_delegate_llm_client 只给 _run_delegated_task。

它们不是对象状态，是被提升到构造函数的 config 常量。

修法：收进一个 config dataclass。_build_runtime_loop（__init__.py，88 行）是这 44 个参数唯一的生产构造点，收拢成本低。
紧迫=低、工作量=中。不是 bug，是 refactor 味道。
明确不含「拆 RuntimeLoop 类」——那条已被三份结构方案罕见一致地否掉（5 个公开方法 / 44 个方法的深模块，16 个 handler 共享 _TurnState 的 pre-send 不变量，拆它就是把深模块换成浅模块），理由记在 #97。
它不需要过裁决复核（不是查漏产出，是直接实测事实），但仍适用本票"先 grill 再拆 PRD"那条。

对账表随之更新

去处	条数
#93 / #94 / #95 / #102（批次一）	8 + 2
本票·实现类	32（31 条查漏产出 + 1 条结构实测）
#101 留痕 / 作废	28 / 1
#104（ADR-0030 整份落地，查漏产出之外）	1
本票·待拍板（清单见 #101 附录 C + Not-in-scope）	9

查漏 77 条仍然是 8 + 31 + 28 + 1 + 9 = 77 ✅（#104 与 44 参数那条都不属于那 77 条，是另外查实的）。

## 两处清单修订（都是同一个漏斗形状，趁早堵掉） ### 一、ADR-0012 那条只被 #102 **部分**认领，别整条划掉清单附录里那句「其中 2 条 `紧迫=高` 已由 #102 认领……实现后从本清单划掉」对 **ADR-0024 那条**成立，对 **ADR-0012「决策 → 2. 触发」+「6. 治理」那条不成立**。那条落差的断言是**两半**： > 撤/改限当前会话 **+ 平台撤回窗口**；硬约束只针对**自己的、窗口内**消息 - **chat_id 归属校验**那半 → #102 在做（一行判断 + 跨 chat 回归测试） - **平台撤回窗口**那半 → **不在 #102**，它依赖 Sent Log 增加时间字段（本清单里的另一条独立条目）所以：**#102 合并后，这条只划掉 chat_id 那半，条目本身留在清单里**，把 claim 改成只剩「平台撤回窗口 + 窗口内硬约束」。（这处模糊是我在 #102/#103 之间新造的——#102 的 Not-in-scope 写了"窗口半属第四批，见 #103"，而 #103 的附录又说"实现后整条划掉"，两边对不上。同一个"没有清单/边界不清就会掉东西"的机制，这次在两张票之间发生。） ### 二、清单新增第 32 条：`RuntimeLoop` 44 参数构造函数收成 config dataclass 来源不是 ADR 查漏，是同日 `src/` 内部结构实测（AST 全量）。#97 正文里提到了它、并写明「**与拆不拆类是两个问题，不在本票**」——但**没说在哪张票**，于是它成了又一个没有归宿的条目。现在归到本清单。 **事实**（实测，非估计）：`RuntimeLoop` 有 **44 个方法、44 个构造参数**（全 keyword-only，构造函数本身 100 行纯搬运）。其中 **29 个字段只被恰好一个方法读**——例如 `_typing_base_delay`/`_typing_per_char_delay`/`_typing_energy_jitter` 只给 `_typing_delay`，`_recall_half_life_seconds`/`_recall_weights` 只给 `_scored_events`，`_familiarity_*` 三个只给 `run`，`_delegate_max_rounds`/`_delegate_llm_client` 只给 `_run_delegated_task`。 **它们不是对象状态，是被提升到构造函数的 config 常量。** - 修法：收进一个 config dataclass。`_build_runtime_loop`（`__init__.py`，88 行）是这 44 个参数**唯一的生产构造点**，收拢成本低。 - **紧迫=低、工作量=中**。不是 bug，是 refactor 味道。 - **明确不含**「拆 `RuntimeLoop` 类」——那条已被三份结构方案罕见一致地否掉（5 个公开方法 / 44 个方法的深模块，16 个 handler 共享 `_TurnState` 的 pre-send 不变量，拆它就是把深模块换成浅模块），理由记在 #97。 - 它**不需要过裁决复核**（不是查漏产出，是直接实测事实），但仍适用本票"先 grill 再拆 PRD"那条。 ### 对账表随之更新 | 去处 | 条数 | |---|---| | #93 / #94 / #95 / #102（批次一） | 8 + 2 | | **本票·实现类** | **32**（31 条查漏产出 + 1 条结构实测） | | #101 留痕 / 作废 | 28 / 1 | | #104（ADR-0030 整份落地，查漏产出之外） | 1 | | 本票·待拍板（清单见 #101 附录 C + Not-in-scope） | 9 | 查漏 77 条仍然是 8 + 31 + 28 + 1 + 9 = 77 ✅（#104 与 44 参数那条都不属于那 77 条，是另外查实的）。

Issue	内容	含条目
#112	冷启动渐进解锁三件套：gate连续缩放+三因子召回闸+冷启动自我介绍声明	1,4,5
#114	ADR-0008注入分档恢复+新建lookup_relation工具	14
#115	self_recall/edit平台撤回窗口+per-chat速率预算	17,18
#116	人设漂移守护判断留痕+安全基线补编造身份禁令	21,22
#117	智能体死循环熔断	30
#123	已读延迟窗本体+scope_ceiling三档+文档同步	15,2,20,27
#124	情感态energy昼夜节律nudge	9,19
#125	情感态收尾：慢情感态energy产出方+反应式路径自我披露倾向	8,10
#126	关系网tension/affinity双轴驱动+文档对齐	12,13,31
#127	画像常驻注入自然遗忘曲线	11
#133	反思闭环样本补全	6,26
#134	Knowledge差异化合并升级为同轮LLM融合	16
#135	忘记我命令	3,28
#136	未获回应升级：新增快情感态delta输入源（核实过程中挖出的孤儿条目，此前无票认领）	新增
#137	回指消解resolved_subject落地（仅user_id半）	23
#138	energy四输入源文档对账	29

Rows
Columns

第四批清单：31 条实现类落差 + 9 条待拍板（拆片时 AC 必须带 ADR 原文引文） #103

全 77 条的完整去处（对账，合计必须等于 77）

⚠️ 拆片时的硬约束：AC 必须逐字引用 ADR 原文

回原文时专查两种误读

两条已单独拍板的结论（直接影响拆片，按此执行）

一、ADR-0008 注入分档 → 恢复分档 + 新建 lookup_relation 工具

二、画像注入无界 → 按 ADR 已 ADOPTED 的方案做，不要加硬上限

拆片时的第二件事：先分组再拆

Acceptance criteria

31 条实现类落差清单 → 见本票评论 1

附录：31 条实现类落差清单

1. ADR-0007 决策节（第 2 条子弹） [紧迫=中 工作量=中]

2. ADR-0007 更新（2026-07-06 已读延迟窗+选择性回应，见 ADR-0017） [紧迫=中 工作量=小]

3. ADR-0010 决策节「忘记我 / 隐私」第 1 条 [紧迫=中 工作量=小]

4. ADR-0007 决策节第 3 条 + 更新（2026-07-10 idea grill，见 ADR-0029） [紧迫=中 工作量=小]

5. ADR-0007 决策节第 1 条（后半句） [紧迫=低 工作量=小]

6. ADR-0006「更新（2026-07-04 A1 反坍缩 grill）」节 [紧迫=中 工作量=中]

7. ADR-0006「更新（2026-07-04 A1 反坍缩 grill）」节「双向信号」条 [紧迫=中 工作量=中]

8. ADR-0005「双时间尺度」节「慢情感态 per-user」条 [紧迫=中 工作量=中]

9. ADR-0005「更新（2026-07-06 已读延迟窗，见 ADR-0017）」节 [紧迫=中 工作量=中]

10. ADR-0005「决策」节（中央调节器），同 CONTEXT.md/design.md [紧迫=中 工作量=小]

11. ADR-0009 —「更新（2026-07-11 第三轮）」节 ADOPTED 第 3 条 [紧迫=中 工作量=中]

12. ADR-0008 决策（四轴）+ 更新（2026-07-13，issue #36）权威代码落盘节 [紧迫=中 工作量=中]

13. ADR-0008 决策（四轴） [紧迫=中 工作量=中]

14. ADR-0008 决策（保留 dxkuma ADR-0009 全部结构） [紧迫=中 工作量=小]

15. ADR-0017「决策 → 已读延迟窗」节 [紧迫=中 工作量=小]

16. ADR-0015「更新（2026-07-10 第二轮）」节 + 决策节 [紧迫=中 工作量=中]

17. ADR-0012「决策 → 2. 触发」节 + 「决策 → 6. 治理」节 [紧迫=高 工作量=小]

18. ADR-0012「决策 → 1. 两 regime」节 + 「6. 治理：默认 ON + 速率预算兜底」节 [紧迫=中 工作量=小]

19. ADR-0017「决策 → 已读延迟窗」节（昼夜节律 nudge energy） [紧迫=中 工作量=中]

20. ADR-0017「决策 → 已读延迟窗」节（冷启动收紧，经 ADR-0007 确认为解锁子轴） [紧迫=中 工作量=小]

21. ADR-0021 人设漂移守护「决策」节（判断方式 + 判断失败两条） [紧迫=中 工作量=小]

22. ADR-0022 安全基线 —「更新（2026-07-08）：禁止编造未声明的核心身份事实」节 [紧迫=中 工作量=小]

23. ADR-0016（reference-resolution）「决策」节第 2 条 [紧迫=中 工作量=小]

24. ADR-0024（learned-stickers）「决策」节第 4 条 [紧迫=高 工作量=小]

25. ADR-0023 决策节第 1、2 条（+ ADR-0029 触发源清单「poke/reaction 命中本人」） [紧迫=中 工作量=中]

26. ADR-0025 决策节最后一条「治理免费继承」 [紧迫=中 工作量=中]

27. CONTEXT.md「已读延迟窗」条 + design.md 运行时 mermaid gate 节点 + 真人感层条目 [紧迫=中 工作量=小]

28. CONTEXT.md「忘记我（Forget-me）」条 + design.md 运营与质量条 + ADR-0010 决策节 [紧迫=中 工作量=小]

29. CONTEXT.md「已读延迟窗」与「快情感态」条 + design.md 真人感层「已读延迟窗 + 选择性回应」条 [紧迫=中 工作量=中]

30. design.md 决策基线「低争议、直接采纳」列表 + 上线路线第 4 阶段 [紧迫=中 工作量=小]

31. CONTEXT.md「关系亲密度 / 关系多轴」条 + design.md 真人感层「关系多轴」条 + ADR-0008 决策节 [紧迫=中 工作量=中]

两处清单修订（都是同一个漏斗形状，趁早堵掉）

一、ADR-0012 那条只被 #102 部分认领，别整条划掉

二、清单新增第 32 条：RuntimeLoop 44 参数构造函数收成 config dataclass

对账表随之更新

拆片完结：32/32 全部有归宿

一、ADR-0008 注入分档 → 恢复分档 + 新建 `lookup_relation` 工具

1. ADR-0007 决策节（第 2 条子弹） [紧迫=中工作量=中]

2. ADR-0007 更新（2026-07-06 已读延迟窗+选择性回应，见 ADR-0017） [紧迫=中工作量=小]

3. ADR-0010 决策节「忘记我 / 隐私」第 1 条 [紧迫=中工作量=小]

4. ADR-0007 决策节第 3 条 + 更新（2026-07-10 idea grill，见 ADR-0029） [紧迫=中工作量=小]

5. ADR-0007 决策节第 1 条（后半句） [紧迫=低工作量=小]

6. ADR-0006「更新（2026-07-04 A1 反坍缩 grill）」节 [紧迫=中工作量=中]

7. ADR-0006「更新（2026-07-04 A1 反坍缩 grill）」节「双向信号」条 [紧迫=中工作量=中]

8. ADR-0005「双时间尺度」节「慢情感态 per-user」条 [紧迫=中工作量=中]

9. ADR-0005「更新（2026-07-06 已读延迟窗，见 ADR-0017）」节 [紧迫=中工作量=中]

10. ADR-0005「决策」节（中央调节器），同 CONTEXT.md/design.md [紧迫=中工作量=小]

11. ADR-0009 —「更新（2026-07-11 第三轮）」节 ADOPTED 第 3 条 [紧迫=中工作量=中]

12. ADR-0008 决策（四轴）+ 更新（2026-07-13，issue #36）权威代码落盘节 [紧迫=中工作量=中]

13. ADR-0008 决策（四轴） [紧迫=中工作量=中]

14. ADR-0008 决策（保留 dxkuma ADR-0009 全部结构） [紧迫=中工作量=小]

15. ADR-0017「决策 → 已读延迟窗」节 [紧迫=中工作量=小]

16. ADR-0015「更新（2026-07-10 第二轮）」节 + 决策节 [紧迫=中工作量=中]

17. ADR-0012「决策 → 2. 触发」节 + 「决策 → 6. 治理」节 [紧迫=高工作量=小]

18. ADR-0012「决策 → 1. 两 regime」节 + 「6. 治理：默认 ON + 速率预算兜底」节 [紧迫=中工作量=小]

19. ADR-0017「决策 → 已读延迟窗」节（昼夜节律 nudge energy） [紧迫=中工作量=中]

20. ADR-0017「决策 → 已读延迟窗」节（冷启动收紧，经 ADR-0007 确认为解锁子轴） [紧迫=中工作量=小]

21. ADR-0021 人设漂移守护「决策」节（判断方式 + 判断失败两条） [紧迫=中工作量=小]

22. ADR-0022 安全基线 —「更新（2026-07-08）：禁止编造未声明的核心身份事实」节 [紧迫=中工作量=小]

23. ADR-0016（reference-resolution）「决策」节第 2 条 [紧迫=中工作量=小]

24. ADR-0024（learned-stickers）「决策」节第 4 条 [紧迫=高工作量=小]

25. ADR-0023 决策节第 1、2 条（+ ADR-0029 触发源清单「poke/reaction 命中本人」） [紧迫=中工作量=中]

26. ADR-0025 决策节最后一条「治理免费继承」 [紧迫=中工作量=中]

27. CONTEXT.md「已读延迟窗」条 + design.md 运行时 mermaid gate 节点 + 真人感层条目 [紧迫=中工作量=小]

28. CONTEXT.md「忘记我（Forget-me）」条 + design.md 运营与质量条 + ADR-0010 决策节 [紧迫=中工作量=小]

29. CONTEXT.md「已读延迟窗」与「快情感态」条 + design.md 真人感层「已读延迟窗 + 选择性回应」条 [紧迫=中工作量=中]

30. design.md 决策基线「低争议、直接采纳」列表 + 上线路线第 4 阶段 [紧迫=中工作量=小]

31. CONTEXT.md「关系亲密度 / 关系多轴」条 + design.md 真人感层「关系多轴」条 + ADR-0008 决策节 [紧迫=中工作量=中]

二、清单新增第 32 条：`RuntimeLoop` 44 参数构造函数收成 config dataclass