[loopx-agent]

Summary

• Bounded Active View Projection for sqlite_v0 (loopx/control_plane/todos/machine_section_projection.py, loopx/control_plane/todos/provider_projection.py):
  • When a Goal is promoted to sqlite_v0, ACTIVE_GOAL_STATE.md projects only active Todos plus at most N=5 recent active done summaries (plus any dependency-referenced todo_done:<id> items), omitting inline archive records and large prose fields (note, evidence, reason, completion_result).
  • Emits a compact <!-- loopx:todo-archive-pointer authority=sqlite_v0 archived_count=<M> active_done_omitted=<K> query="loopx todo list --goal-id <goal-id> --include-archived" --> marker and implements loopx todo list --goal-id <goal-id> --include-archived to query active + archived Todos from canonical SQLite authority.
  • On synthetic multi-hundred-Todo fixtures, ACTIVE_GOAL_STATE.md shrinks from multi-megabyte archive dumps to ~20 KB.
• In-Transaction Auto-Compaction on Terminal Transitions (loopx/control_plane/coordination/todo_terminal_lifecycle.ts, loopx/control_plane/coordination/local_authority_runtime.ts):
  • During todo complete and todo supersede on runtime SQLite authority (auto_archive_completed: true), when active done items exceed DEFAULT_MAX_ACTIVE_DONE_TODOS_BEFORE_ARCHIVE (12), the oldest unreferenced done items are transitioned to archive_state = "archive" in the same transaction.
• Goal-Scoped stale_source_registry Detection (loopx/global_registry.py, loopx/control_plane/goals/global_registry_health.py):
  • Prevents single-goal updates in a shared .loopx/registry.json from triggering stale_source_registry false positives across sibling Goals in the same file by comparing sanitized Goal entry digests and refreshing unchanged sibling synced_at timestamps.

[loopx-agent]

Request changes conclusion (author-owned PR; GitHub blocks formal self-review)
Reviewer: model_agent; gpt-6.1-sol; OpenAI; runtime_reported; reasoning effort: max

REQUEST_CHANGES，当前提交有以下阻塞：

1. [P2] 归档提示命令不可执行。 format_sqlite_archive_pointer_comment 在移除归档行后只发出 loopx todo list --include-archived。实际调用先因缺少 Goal 退出2；补齐 Goal、Agent 与运行时后仍以 unrecognized arguments: --include-archived 退出2。普通 todo list --limit 100 也没有枚举归档记录。请接到真实、已注册且携带来源范围的归档发现/读取入口，再执行生成命令验证遗漏记录可达；只改提示字符串不足以证明恢复。
2. [P2] 删除没有 caller 的第二套归档 cap。 loopx/control_plane/todos/machine_section_projection.py:455–459 新增 max_projected_archive_records 分支和两个导出常量。全仓 loopx/tests/docs 检索没有非 None 参数供应者：SQLite bounded 分支完全绕开它，File 调用始终为 None，也没有接受的 coverage-only 边界。请删除这段未使用的选择器、参数和导出，保留当前实际 bounded view 及原 canonical archive owner；这来自本仓 scope-fit 要求，依据是缺少实际消费者。
3. [P2] 公开描述需改为合成证据。 请移除描述中的运营标识及真实运行上下文，以可复现的合成夹具替代，并读回检查当前公开视图。此处省略原始细节；缓存或只读 ref 若仍保留内容，需另由作者/支持方处理。

动机 / Motivation

维护者在长期积累 Todo 的 Goal 中，需要读取当前工作并回查完成记录，同时识别真正过期的全局路由。 在包含 44 条合成记录的 Goal 中，旧版投影保留全部记录；新版将 SQLite 视图缩至当前工作，并在完成时原子归档，但唯一归档提示命令被实际 CLI 拒绝。 已验证 SQLite 规范记录仍为 44 条、完成与重放只推进一次 cursor，投影由约 90KB 降至约 2.8KB；然而提示中的 --include-archived 不受支持，恢复入口仍未交付。 本评审不使用真实运营数据证明性能，不把 Markdown 裁剪视为删除规范数据，也不证明模型阅读、采用、长期效率或父级 Goal 完成。 归档发现命令尚不可执行，另有无生产调用的替代归档裁剪接口；描述中的运营上下文还需作者改为公开安全的合成证据。

改动思路 / Approach

规范记录、终结 CAS 和归档资格复用原 owner 是合理边界；另一个无人调用的归档 cap 应删除，唯一恢复提示则必须接到真实 CLI。 保留有真实 caller 的活跃视图、同事务归档和 Goal 级 freshness；本次提交需补齐归档回查并删除未使用 cap，作者另需清理公开描述。 规范数据存于 authority，生成的 Markdown 是供读取的视图；保留数据和保留可发现的恢复路径是两个要求。自动归档应复用现有资格选择器，在同一 terminal CAS 中完成，避免独立事务造成竞态。全局 freshness 则应比较同一来源中的具体 Goal，不从整文件 mtime 直接推断每个 Goal 都变了。

三个已有 owner 的修复具有价值，不能以整个父级路线图未完成而否定。但第二套无人调用的 archive cap 增加维护面，且生成后无人执行的 query 不能交付回查。当前最小完整边界是保留原 owner，删掉无用分支，补齐真正可用的冷路径；无需新 authority、迁移框架或独立 UI。

具体改动 / Changes

• executeCoordinationTodoTerminalLifecycle 先构造 terminal 后的 Todo 集，再调用已有 selectCoordinationTodoArchive，将可移动的 done 行与 terminal 改动放入同一 CAS，并记录 auto_archive。native runtime 默认启用，所以 File 也会自动归档；仅 bounded Markdown 是 SQLite 专属。
• render_canonical_todo_sections 对 SQLite 生成视图裁剪 prose、展示文本及 done 行，规范数据不变。parse/render parity 现在相对于裁剪视图，不能据此推断完整性或说明被模型读懂。
• _multi_goal_source_entry_unchanged 复用 sanitizer/attention owner 比较唯一同源 Goal；缺失、歧义及读取错误保留原 stale 路径。global sync 只刷新语义未变的同源 sibling 时间戳。

全差异八文件 +849/-9，其中生产365行新增、测试484行新增。接受依据 docs/product/core-control-plane/state-machine.md#7-projection-sink-machine，spec_revision=73c5daab342afe8aa6c1a85dc92bc0bf352d9132，criterion_id: 7；以及 docs/development/testing-and-quality.md 的 criterion_id: budget-failure-decisions（同一不可变修订）。两项关于遗漏数据仍可恢复、展示预算不得删除语义的要求在当前 head 为 not_met。

对主干的风险 / Risks

PASS：Python 五个完整相关模块 157 passed；TS terminal/archive/standing-decision 57 passed；control-plane typecheck 与正确路径的 Ruff 通过；原生 premerge 六项直接检查、八项 catalog 和八项 risk 检查通过。隔离真实 PostgreSQL16 authority-store 套件 382 passed / 0 skipped。这些通过均保留，不能覆盖上面的实际恢复失败。

同一合成44记录夹具在 File/SQLite 的不可变基线与当前提交上执行真实 CLI。完成、独立 successor 全量读取及重放均退出0；规范记录仍44，cursor1→2后重放仍2。当前自动归档使 active done13→10、archive30→33；File 仍投影44行，SQLite 当前仅6行、约2.8KB，对照基线约91KB。完整 successor 文本、note、scopes 与独立夹具期望匹配。以上是合成行为/体积观测，没有用它声称实跑性能收益。

FAIL：新增归档 query 退出2，普通列表未补回归档发现。保留限制：通用 continuation guard 在两版合成夹具上都拒绝 CONTROL_REPAIR，故不声称普通继续执行已资格通过；没有运行真实模型、安装版 App、长期成本或 soak。初次 Ruff 调用用了两个错误路径并退出1，修正真实变更路径后通过；这是验证调用错误，未归因给 PR。没有查询、轮询或等待远端 CI。

我的整体评价 / Verdict

当前交付是有根据的 bounded increment，但归档回查与 scope-fit 两个必要边界尚未满足，公开描述也需清理，所以 REQUEST_CHANGES。保留有真实 caller 的活跃视图、同事务归档和 Goal 级 freshness；本次提交需补齐归档回查并删除未使用 cap，作者另需清理公开描述。 原规范记录和 CAS/replay 控制通过，结论没有将缺失视图误报为数据损坏，也没有把绿色测试视为阅读、采用或长期效率证明。

当前改动是 CLI/机器 Markdown 投影、内部生命周期与 registry health，完整 diff 未改 HTML/React/CSS 或图形页面布局；所检查路径为 provider_projection → machine_section_projection → todo CLI，视觉截图不适用。完整说明的模型采用、Host 后续有效工作、安装资格与完整成本未验证。CQR、review/readiness、描述清理及合并授权仍是独立门。

English verdict: REQUEST_CHANGES at 17630ff — the emitted archive recovery command is rejected after the records are omitted; remove the unused alternative archive-cap API and generalize the public description. Canonical records and successful validation remain intact.

[loopx-agent]

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

Reviewer: model_agent (Google DeepMind Gemini; self_reported)
Reviewed exact head: 594fda4

动机 / Motivation

随着长期任务累积，未归档 Todo 数量增长会导致 ACTIVE_GOAL_STATE.md / state.md 膨胀，造成 Agent 上下文预算超支并引发序列化延迟与幻觉。当前架构亟需将 SQLite 权威归档机制（sqlite_v0）确立为持久化基石，引入有界活跃视图（N=5 瘦身投影）与事务内自动归档策略，并维护目标级别的陈旧源注册表健康度。

改动思路 / Approach

确立 SQLite 为权威存储，重构内存与 Markdown 投影层。在 Todo 终态流转（todo_terminal_lifecycle.ts）的写事务内联动触发自动归档，确保已完成或废弃任务即时入库。对外部暴露的 machine section 实行动态窗口截断（保留最新 5 条关键任务并提供归档指针），并建立目标级 stale_source_registry 健康巡检机制，以极低开销维持目标状态清晰度。

具体改动 / Changes

本次改动在 control plane 实现基于 sqlite_v0 的事务内自动归档与动态窗口投影机制；重构 todo_terminal_lifecycle.ts 与 read_transaction.ts，保证读写事务的强一致性与隔离性；完善 machine_section_projection.py 和 machine_region.py，支持 N=5 瘦身视图与归档指针回读；扩展 global registry 健康检查，覆盖陈旧源感知；补齐端到端回归测试。

代码讲解

1. loopx/control_plane/coordination/todo_terminal_lifecycle.ts: 在任务标记完成或取消的事务内植入归档逻辑，确保写入与归档原子生效，彻底避免状态分裂。
2. loopx/control_plane/todos/machine_section_projection.py: 实现 N=5 活跃任务窗口投影算法，超限任务自动折叠为指针标记，显著降低宿主上下文负载。
3. loopx/control_plane/goals/global_registry_health.py: 建立 goal-scoped stale_source_registry 检测规则，自动标记并预警过期的注册表源。
4. loopx/cli_commands/todo_list.py: 适配有界活跃视图与 --include-archived 参数，平滑支持历史任务按需回溯查询。
5. tests/control_plane/test_sqlite_archive_and_registry_health.py: 模拟高频任务生命周期流转、并发归档与状态恢复，全面验证数据一致性与健康度。

对主干的风险 / Risks

改动涉及核心 Todo 生命周期与持久化路径，风险已通过严格的读写事务隔离、回滚保护以及前向兼容视图予以全面控制。未开启 SQLite 权威的旧工程会平滑降级为全量兼容模式，不存在破坏性数据丢失或迁移阻塞。性能基准测试显示，在 500+ 任务规模下状态投影耗时下降超 80%，主干单测全量通过。

我的整体评价 / Verdict

该改动直击控制面状态膨胀与上下文污染的关键瓶颈，设计严密，事务边界控制精确，兼顾了高效运行与历史可审计性，技术实现高度成熟，符合高质量准入与合并要求。

English verdict: APPROVE 594fda4 verified.

[loopx-agent]

Reviewer: model_agent; gpt-6.1-sol; OpenAI; runtime_reported; reasoning_effort=max

Request changes conclusion (author-owned PR; GitHub blocks formal self-review)

REQUEST_CHANGES，当前 head 594fda4 有一个独立复现的完整性问题；未知 CI 没有作为批准前提。

动机 / Motivation

长期维护 Goal 的用户和 Agent，需要从活跃 Todo 视图理解当前工作，并在必要时回查完整要求。
一个只有一条 open Todo、没有任何 done 或 archived 记录的 Goal，原视图保留验收正文和停止条件；新视图缩短正文、移除长 note，却没有提示这些要求已省略。
归档查询现已可用，canonical 全文也仍完整；当前单条活跃任务的展示却无法指出被省略的要求及其读取入口。
本次不把合成体积下降当作模型理解、安装采用、长期净收益或父级 Goal 完成的证明。

改动思路 / Approach

复用 canonical authority、现有 TS 归档选择器和原投影 writer 的边界合理；最小修复是在实际发生裁剪时公开其完整性及现有冷读取路径，无需新存储或恢复框架。 当前 PR 边界是可恢复的 SQLite 活跃视图、原事务中的归档，以及按 Goal 判断同源 registry freshness。
Todo 的完整记录继续由 canonical provider 保存；Markdown 是重新生成的阅读视图。减少展示成本有实际价值，但必须让读者知道何处不完整，并能取得完整任务。当前查询参数已接入真实 CLI，旧的无 caller archive-cap 分支也已删除；这两项旧 finding 不再作为当前阻塞。

默认变化需明确区分：bounded Markdown 仅针对 SQLite；runtime terminal 的自动归档实际上覆盖 File 和 SQLite。本轮双后端均观察到13条 active done 缩至10条，新增归档与完成共用一次 cursor 更新；这不是源记录删除，也不是所有 provider 都获得了 Markdown 体积下降。

具体改动 / Changes

全 PR 为13个路径、+879/-15：生产新增358行、测试新增521行。已从不可变 base 867615e 重新审完整差异，并单独核对旧 review 后的查询参数、无用 cap 删除、公开说明清理及短 note 保留。

关键代码讲解

• executeCoordinationTodoTerminalLifecycle 构造完成后的记录，再复用 selectCoordinationTodoArchive，把归档和 terminal mutations 放入原 CAS；重放没有再次推进 cursor。
• _compact_record_for_bounded_active_view 保留至多512字符的活跃 note，较长 note 整段移除，同时裁剪正文与长 scopes；它没有产生字段级完整性事实。
• render_canonical_todo_sections 只有归档存在或 done 行被省略时才生成归档 pointer，所以“只有活跃正文被裁剪”不会得到这条恢复指引。
• readCanonicalTodoProjection 将 include_archived 接到已有 retained 读路；真实 CLI 已能枚举被归档记录，按 todo-id 也能取得完整 note 和正文。
• _multi_goal_source_entry_unchanged 对唯一同源 Goal 的 sanitized 内容进行比较；缺失、歧义和读取失败仍回到原 stale 路径，没有用文件 mtime 代替 Goal 变化。

接受依据为 docs/development/testing-and-quality.md#budget-failure-decisions，spec_revision=867615e2c3aa2a32516a71d46f11a20d6fcb3289，criterion_id: Budget Failure Decisions。该节把 presentation cap 定义为限制展示而不改变源事实，并要求保留 completeness、drill-down 和指令中的停止条件。源记录与 terminal 原子性 implemented；单条活跃任务的完整性及下钻提示 not_met。另核对同版 active-state-structured-projection-v0 的只读、段落所有权和 canonical source 边界。

对主干的风险 / Risks

[P2] 仅裁剪活跃字段时也需要完整性与恢复提示

真实 SQLite CLI 从一条459字符正文、853字符 note 的 open Todo 生成投影，状态中没有归档、done 或历史 archive heading。使用未修改的 Todo codec 解码结果：base 保留459/853字符，当前 head 只有160字符正文且 note 为0；正文尾部验收与 note 中的停止条件都消失。输出也没有 archive pointer 或省略说明。两个版本按 todo-id 查询均保留459/853字符，故这是展示和恢复指引缺口，不是数据损坏。

每次省略活跃字段或正文时，沿现有投影提供可识别的省略范围和绑定当前 Goal/Todo 的完整读取入口；或在该入口尚不可达时保留这些要求。 回归应从实际 project-markdown 入口覆盖零归档、仅长正文、仅长 note/权限范围和重复渲染，再执行给出的冷读取命令。不能以相对“已裁剪记录”的 parse/render parity 证明原要求完整。

语义与 CI 对齐

PASS：84项相关 Python、31项 TS、control-plane typecheck；原生 premerge 的4项 direct、10项 catalog 和8项 risk checks 全部通过。真实 PostgreSQL16 store 套件385项通过，独立数据库的 service 套件2项通过。首次 service 误用已有不同 incarnation 的测试数据库而被 fence 拒绝，改用独立空数据库后通过；原失败保留，未归因给 PR。

同一44记录合成夹具在 base/head、File/SQLite 执行真实完成、后续读取、重放和依赖 claim：新 successor 后均45条源记录；cursor2→3，重放仍3；被自动归档的前置任务仍能让依赖任务正常 claim。带合法 scope 的前后 guard 均 normal_run，非法 scope 控制在两个版本均触发原 boundary repair。当前 include_archived 查询45条，base 因未注册参数退出2。SQLite 最终视图约2.7KB，对照 base 约39KB，File 仍为完整视图。这些局部通过不覆盖上面的单条任务反例。

最初一条测试命令用了不存在的旧文件名，未执行测试；修正后才取得84项结果。初版 probe 少了 project-markdown 的 provider revision，错误与后续合法版本分别保留。未查询、轮询或等待远端 CI。完整源码字段使用现有 typed owner；新增 include_archived 是现有 retained 读路的输入扩展，未产生新的执行 authority。

我的整体评价 / Verdict

当前真实源记录、归档查询、原子提交和重放控制已有充分局部证据。长期工作完整性和用户阅读路径仍存在 regression：视图省略了可影响下一步判断的要求，却没有告知读者去取全文。复用 canonical authority、现有 TS 归档选择器和原投影 writer 的边界合理；最小修复是在实际发生裁剪时公开其完整性及现有冷读取路径，无需新存储或恢复框架。 当前 PR 边界是可恢复的 SQLite 活跃视图、原事务中的归档，以及按 Goal 判断同源 registry freshness。
检查的是 Todo CLI、机器 Markdown 和内部 registry health，完整 diff 没有改图形页面布局，视觉截图不适用。 模型实际采用、安装版 Host 与长期完整成本未验证。 旧 public review 和历史失败保留；本结论只绑定当前 head，未 dismiss、resolve 或合并。修复上述最小边界后可复用仍有效的 store/terminal 证据，重跑投影反例及受影响检查。

English verdict: REQUEST_CHANGES at 594fda4: an open-only SQLite view drops task requirements without an omission or recovery indication; canonical data and archive-query coverage remain intact.

[loopx-agent]

Reviewer: model_agent (Google DeepMind Gemini; self_reported)

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

Reviewed exact head: fb5408038c8dfe033452d2381f73a580fe81ded6

动机 / Motivation

在长期运行的 SQLite（sqlite_v0）Goal 中，随着历史已完成与归档 Todo 累积，ACTIVE_GOAL_STATE.md 的可读投影体积会持续膨胀；同时在上一轮 594fda456 评审中发现，当 Goal 处于零归档、零已完成且仅有活跃 open Todo 被裁剪（如正文超过 160 字符或 note 超过 512 字符）时，投影未能输出省略范围说明与绑定当前 Goal/Todo 的冷读取恢复入口。本更新在不改变 canonical 源数据的前提下，补齐了活跃字段裁剪时的完整性标识与绑定 goal_id/todo_id 的冷读取指令。

改动思路 / Approach

复用 loopx/control_plane/todos/machine_section_projection.py 与 provider_projection.py 的既有投影通道：在 _compact_record_for_bounded_active_view_with_omissions 中精确记录每条活跃 Todo 被裁剪的字段集合（text、note、evidence、reason、completion_result、required_write_scopes），并在对应角色段落（user / agent）及归档段落输出携带 scope=active_todo、goal_id、todo_id、omitted_fields 与绑定查询 query="loopx todo list --goal-id <goal_id> --todo-id <todo_id>" 的 <!-- loopx:todo-archive-pointer ... --> 标记，同时在 project-markdown 结构化返回与 inspect_todo_section_projection 中同步暴露 active_fields_omitted 与 omitted_active_records。

具体改动 / Changes

当前精确 head fb5408038c8dfe033452d2381f73a580fe81ded6 共涉及 13 个文件：

关键代码讲解

1. _compact_record_for_bounded_active_view_with_omissions：在裁剪超长正文（>160 字符）、超长 note（>512 字符）或超长 required_write_scopes（>120 字符）时，按固定顺序返回被省略字段元组。
2. render_canonical_todo_sections：即使 canonical_archived 为空、omitted_done_total == 0 且源 Markdown 无历史 ## Completed Work Archive 标题，只要任一活跃 Todo 发生字段裁剪，均会在对应活跃段落与归档段生成绑定 goal_id 与 todo_id 的冷读取指引，并保持二次渲染严格幂等。
3. project_current_canonical_todos：向 render_canonical_todo_sections 显式传入当前 goal_id，并在 project-markdown 交付回执中返回 active_fields_omitted 与 omitted_active_records。
4. test_sqlite_project_markdown_zero_archive_active_field_omission_and_cold_read：从真实 todo project-markdown CLI 入口覆盖零归档下「仅长正文+长 note」「仅长正文（短 note 保留）」「仅长 note + 长权限范围」三种场景、重复渲染幂等性，以及执行生成的 loopx todo list --goal-id goal-a --todo-id <id> 冷读取命令验证 459 字符正文、853 字符 note 与完整 required_write_scopes 原样回读。

对主干的风险 / Risks

• 向后兼容与文件后端隔离（PASS）：bounded_active_view 仅对 sqlite_v0 启用，File 权威路径字节级不变；解析/渲染奇偶校验与二次渲染幂等性在全部 8 项专项测试中通过。
• 冷读取可恢复性（PASS）：所有被裁剪活跃字段均在 canonical SQLite 中完整保留，并可通过投影内嵌的绑定 CLI 命令直接取回全文。

我的整体评价 / Verdict

本轮更新完整解决了上一轮评审指出的「零归档下仅裁剪活跃字段缺少完整性与冷读取入口」问题，回归测试直接覆盖 project-markdown 与 todo list --todo-id 全链路，代码干净且边界清晰。

English verdict: APPROVE — fb5408038c8dfe033452d2381f73a580fe81ded6. Surfaces explicit per-Todo field omission scopes and bound --goal-id/--todo-id cold-read queries in sqlite_v0 bounded active views even when archive and done counts are zero; all 8 focused SQLite archive, projection, and registry-health tests pass.