ProjectKuma/arise
2
0
Fork 0
Code Issues 18 Pull requests 1 Projects Releases Packages Wiki Activity

群内插句嘴+环境遥测两个新增触发入口的事务分段 #202

New issue
Open
opened 2026-08-21 06:14:47 +00:00 by KumaAgent · 0 comments
KumaAgent commented 2026-08-21 06:14:47 +00:00
Member
Copy link

Parent

#151（ADR-0013 ①层单一事务边界落地——请求级事务，issue #108 Q1）。

What to build

从「四个门控触发入口」片拆片起草时的核实过程中发现：gate_pipeline.py 模块文档字符串现状已经是
"反应式、Drive Tick、环境信号、即刻追问、群内插句嘴（issue #159）五条触发路径……按调用点数是
五处而不是四处"——比 #151 design-verify 阶段核实时（当时只有四条）多了一条。同时
environment_pipeline.py 另有 _process_ambient_telemetry_signal（issue #153，环境遥测的
tier-2-only 编排）这第六个调用点，与"环境信号"同属一条概念路径但是独立函数、独立触发。这两处是
issue #159/#153 合入之后才出现的范围增长，design-verify 阶段的原始清单不可能预见到，需要单独一张
票承接，不并入「四个门控触发入口」片以免那片继续膨胀。

两处都调用「四个门控触发入口」片会改造签名的共享函数（_evaluate_unified_gate/apply_tier1_ambient_contagion），
本票只负责这两处调用点自己怎么接线分段，不重新设计共享机制本身。

Acceptance criteria

一、群内插句嘴 _handle_group_slow_interrupt（entry_reactive.py，issue #159/ADR-0032）分段

  • pre-LLM 段：apply_tier1_ambient_contagion（tier-1，恒执行，不受 opt-in 限制）+
    compute_unlock_inputs + _evaluate_unified_gate 合并进同一段；verdict≠proceed 的早退分支
    到此为止（决策快照独立提交，见"三"节，不算这一段）
  • pre-LLM 段在 loop.run_group_slow_interrupt(chat_id, message, affective_state=boosted_state)
    调用前提交/关闭
  • post-LLM 段：record_slow_interrupt_interaction（sends 非空时触发）单独成段，
    loop.run_group_slow_interrupt() 返回后新开；决策快照走"三"节独立提交，不进这一段
  • tier-1/tier-2 两道闸（opt-in 检查 get_slow_interrupt_opt_in、能量窗口 get_slow_interrupt_window）
    都是纯读，不产生独立分段需求，随它们所在的那一段自然归属

二、环境遥测 _process_ambient_telemetry_signal（environment_pipeline.py，issue #153）分段

  • pre-LLM 段：compute_unlock_inputs +（过关系网解锁档后）get_relationship_axes（读）+
    _evaluate_unified_gate 合并进同一段；is_relationship_network_unlocked 未过时的早退不写
    决策快照    （现状如此，注释已明确"解锁档位是 tier-2 整条路径的准入硬门槛，没到档就压根没进入
    评估"，不要在分段改造时顺手补上）；verdict≠proceed 的早退分支到此为止（决策快照独立提交，
    见"三"节）
  • pre-LLM 段在 loop.run_ambient_telemetry_signal(signal) 调用前提交/关闭
  • post-LLM 段：本路径 proceed 分支在 loop.run_ambient_telemetry_signal() 之后只有决策快照
    一次写入，走"三"节独立提交，不需要额外开一个只装决策快照的段

三、决策记账类写入维持独立提交（复用「四个门控触发入口」片已确立的规则，不重新设计）

  • 两处的 _write_decision_snapshot 调用均使用地基片提供的"独立提交"能力，不接收/不使用
    当前分段的 session——与「四个门控触发入口」片"七"节的处理方式完全一致，不要为这两个新入口
    另造一套决策快照提交方式

原文（ADR-0013「更新（2026-08-18，issue #151 Design-Verify）」节，同一条规则对新增入口同样适用）：

沉默预算消费……决策快照……这几类写入在决策产生的那一刻（LLM 调用之前）独立提交，不参与①层
的请求级共享事务。

四、测试

  • 各补一条测试验证 pre-LLM 段与 post-LLM 段写入范围按上面"一""二"节划定的边界各自独立可查
    （不要求完整崩溃注入级别的覆盖，但要能看出两段写入范围确实分开）
  • 全量测试通过

Not in scope

  • _evaluate_unified_gate/apply_tier1_ambient_contagion 等共享函数的签名改造——「四个门控触发
    入口」片负责，本票只是这两个共享函数新增的第五、第六个调用点
  • runtime_loop.py::RuntimeLoop 主循环内部（run_group_slow_interrupt/run_ambient_telemetry_signal
    各自的内部写入，若与「四个门控触发入口」片"八"节覆盖的 _run_tool_loop 共用路径有差异）——
    如果实现时发现这两个 loop.run_* 变体内部还有独立于 _run_tool_loop 共用路径之外的写入，
    记录下来交「四个门控触发入口」片补充，不要在本票里顺手改 runtime_loop.py

Blocked by

  • #197（存储层分段事务基建：session 传递契约与 SAVEPOINT 修复）——需要它交付的 session/事务传递 API
  • #198（四个门控触发入口 + RuntimeLoop主循环的事务分段接线）——本票复用它已经确立的共享函数改造
    与决策记账独立提交规则，且它会先改 _evaluate_unified_gate/apply_tier1_ambient_contagion
    的签名，本票在其基础上接入
## Parent #151（ADR-0013 ①层单一事务边界落地——请求级事务，issue #108 Q1）。 ## What to build 从「四个门控触发入口」片拆片起草时的核实过程中发现：`gate_pipeline.py` 模块文档字符串现状已经是 "反应式、Drive Tick、环境信号、即刻追问、群内插句嘴（issue #159）**五**条触发路径……按调用点数是 **五**处而不是四处"——比 #151 design-verify 阶段核实时（当时只有四条）多了一条。同时 `environment_pipeline.py` 另有 `_process_ambient_telemetry_signal`（issue #153，环境遥测的 tier-2-only 编排）这第六个调用点，与"环境信号"同属一条概念路径但是独立函数、独立触发。这两处是 issue #159/#153 合入之后才出现的范围增长，design-verify 阶段的原始清单不可能预见到，需要单独一张 票承接，不并入「四个门控触发入口」片以免那片继续膨胀。 两处都调用「四个门控触发入口」片会改造签名的共享函数（`_evaluate_unified_gate`/`apply_tier1_ambient_contagion`）， 本票只负责这两处**调用点自己**怎么接线分段，不重新设计共享机制本身。 ## Acceptance criteria **一、群内插句嘴 `_handle_group_slow_interrupt`（`entry_reactive.py`，issue #159/ADR-0032）分段** - [ ] pre-LLM 段：`apply_tier1_ambient_contagion`（tier-1，恒执行，不受 opt-in 限制）+ `compute_unlock_inputs` + `_evaluate_unified_gate` 合并进同一段；verdict≠proceed 的早退分支 到此为止（决策快照独立提交，见"三"节，不算这一段） - [ ] pre-LLM 段在 `loop.run_group_slow_interrupt(chat_id, message, affective_state=boosted_state)` 调用前提交/关闭 - [ ] post-LLM 段：`record_slow_interrupt_interaction`（`sends` 非空时触发）单独成段， `loop.run_group_slow_interrupt()` 返回后新开；决策快照走"三"节独立提交，不进这一段 - [ ] tier-1/tier-2 两道闸（opt-in 检查 `get_slow_interrupt_opt_in`、能量窗口 `get_slow_interrupt_window`） 都是纯读，不产生独立分段需求，随它们所在的那一段自然归属 **二、环境遥测 `_process_ambient_telemetry_signal`（`environment_pipeline.py`，issue #153）分段** - [ ] pre-LLM 段：`compute_unlock_inputs` +（过关系网解锁档后）`get_relationship_axes`（读）+ `_evaluate_unified_gate` 合并进同一段；`is_relationship_network_unlocked` 未过时的早退**不写 决策快照**（现状如此，注释已明确"解锁档位是 tier-2 整条路径的准入硬门槛，没到档就压根没进入 评估"，不要在分段改造时顺手补上）；verdict≠proceed 的早退分支到此为止（决策快照独立提交， 见"三"节） - [ ] pre-LLM 段在 `loop.run_ambient_telemetry_signal(signal)` 调用前提交/关闭 - [ ] post-LLM 段：本路径 proceed 分支在 `loop.run_ambient_telemetry_signal()` 之后只有决策快照 一次写入，走"三"节独立提交，不需要额外开一个只装决策快照的段 **三、决策记账类写入维持独立提交（复用「四个门控触发入口」片已确立的规则，不重新设计）** - [ ] 两处的 `_write_decision_snapshot` 调用均使用地基片提供的"独立提交"能力，不接收/不使用 当前分段的 session——与「四个门控触发入口」片"七"节的处理方式完全一致，不要为这两个新入口 另造一套决策快照提交方式 原文（ADR-0013「更新（2026-08-18，issue #151 Design-Verify）」节，同一条规则对新增入口同样适用）： > 沉默预算消费……决策快照……这几类写入在决策产生的那一刻（LLM 调用之前）独立提交，不参与①层 > 的请求级共享事务。 **四、测试** - [ ] 各补一条测试验证 pre-LLM 段与 post-LLM 段写入范围按上面"一""二"节划定的边界各自独立可查 （不要求完整崩溃注入级别的覆盖，但要能看出两段写入范围确实分开） - [ ] 全量测试通过 ## Not in scope - `_evaluate_unified_gate`/`apply_tier1_ambient_contagion` 等共享函数的签名改造——「四个门控触发 入口」片负责，本票只是这两个共享函数新增的第五、第六个调用点 - `runtime_loop.py::RuntimeLoop` 主循环内部（`run_group_slow_interrupt`/`run_ambient_telemetry_signal` 各自的内部写入，若与「四个门控触发入口」片"八"节覆盖的 `_run_tool_loop` 共用路径有差异）—— 如果实现时发现这两个 `loop.run_*` 变体内部还有独立于 `_run_tool_loop` 共用路径之外的写入， 记录下来交「四个门控触发入口」片补充，不要在本票里顺手改 `runtime_loop.py` ## Blocked by - #197（存储层分段事务基建：session 传递契约与 SAVEPOINT 修复）——需要它交付的 session/事务传递 API - #198（四个门控触发入口 + RuntimeLoop主循环的事务分段接线）——本票复用它已经确立的共享函数改造 与决策记账独立提交规则，且它会先改 `_evaluate_unified_gate`/`apply_tier1_ambient_contagion` 的签名，本票在其基础上接入
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
feat/189-delegate-task-cancellation-shield
No results found.
Labels
Clear labels   
状态：人类就绪
Requires human implementation

  
状态：待拆片
Issue is too large or underspecified — needs to be broken down into smaller child tickets before work can start

  
状态：待评估
Maintainer needs to evaluate this issue

  
状态：忽视
Will not be actioned

  
状态：智能体就绪
Fully specified, ready for an AFK agent

  
状态：等待信息
Waiting on reporter for more information

No labels
状态：人类就绪
状态：待拆片
状态：待评估
状态：忽视
状态：智能体就绪
状态：等待信息
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
ProjectKuma/arise#202
No description provided.