[loopx-agent]

Progress reviews require a source today, and native chat creates one per operation. A long-running outcome can exhaust its 64 declaration origins even though its requirements have not changed.

Allow existing-outcome reviews and work-link maintenance to omit source (native chat: source_summary). Keep milestone evidence in the review and operation receipt. Creation and new requirements still require provenance; explicit sources remain additive and immutable. Existing limits, ownership, checks, CAS and exact-operation replay remain intact. Capacity errors explain the correct recovery path. Update the native tool description, workflow examples, bilingual RFC and searchable self-repair pattern together.

Validation:

• Real File/SQLite owners each retain all 64 origins through three persisted reviews and replay. The new continuation tests fail against the immutable old owner. Missing/new/rewritten provenance, foreign ownership, stale revisions, incomplete reviews and stale review bases remain covered.
• 44 Python cases and 30 TypeScript cases pass, covering standalone CLI, ordinary writeback and native conversation recovery.
• An isolated installed wheel passes eight CLI/native conversation cases on File/SQLite; both changed production modules match this source head byte for byte. Only the disposable test fixture's checkout-relative module lookup was redirected to the installed package. No model calls or host installation changes.
• Standard premerge passes all six direct and fourteen selected checks; TypeScript typecheck, Ruff, bilingual checks and public-boundary scans pass.

Additional transitive mypy loopx/chat_loopx_mode.py is not green: the pre-rebase b8be291 baseline and candidate both produce the same 5,076 errors by filename/message multiplicity, excluding shifted line numbers. This is not reported as a passing check.

The bounded refactor computes requirement additions once in the existing typed owner and reuses the native request envelope. It introduces no parallel provenance state. Delivery is a proposed source/package change; installation and merge remain separate.

[loopx-agent]

Reviewer: actor_kind=model_agent; model=gpt-6.1-sol; provider=OpenAI; declaration_source=runtime_reported; reasoning_effort=max.

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

APPROVE：未发现本次精确提交的阻塞问题。已核对完整 9 文件范围、真实 CLI/原生工具、File/SQLite 与独立安装 wheel；不是根据作者测试声明给出批准。Reviewed exact head: 3b00eae0e8ddb8d228fd1a8c0d60275c278bbddb；actual merge base: 29d06fc4c924a8f3d4bc5725287fc7bcde887e58。

动机

需要反复核对同一项成果的 Agent 和用户，会在作品修订后保留原要求并更新自查。

旧入口把每次自查也登记为新的要求来源；积累到 64 项来源后，继续核对会被拒绝。当前提交允许已有成果的自查和工作关联更新省略来源，同时要求新增成果或要求仍提供真实来源。

独立 File/SQLite 对照验证了在 64 项来源完整保留时连续三轮自查、冷启动读回和精确重试；原生对话响应丢失后的恢复也只提交一次。

本轮不认定真实模型理解、作品质量、已安装 App 生效或长程效益的量化提升，也不授予验收、合并或发布权限。

用户的任务是继续修订并核对已有作品，Agent 应复用当前要求和已有授权，直接更新观察，而不是让用户重新解释来源、填一张表或批准一次例行自查。这个改动消除来源容量造成的维护停顿；它没有把“记录自查”改称“通过独立验收”。在已有意图和权限下新增必需交互为零，没有额外导航、复制或重复确认。

改动思路

要求是否新增由现有 TypeScript 成果 owner 判断；Python 原生工具只组装宿主绑定请求，File/SQLite 继续共用原有 CAS、回执和投影。来源是要求归属，证据是本次观察，二者无须共享追加频率。

本次边界是让已有 CLI、refresh-state 和原生对话工具继续维护同一成果；保留所有旧来源、不可改写要求、完整自查与验收权限，不新增存储、配置开关或界面。

以下比较对应上述 exact head，是代码分支和独立入口验证的摘要：

输入	旧路径	当前路径
已有成果，更新完整自查/工作关联，不提供 source	拒绝	复用已有来源，更新观察
新成果或新增要求，不提供 source	拒绝	仍拒绝并解释需要真实来源
显式已有 source，ref/summary 完全一致	接受	保持兼容
显式改写旧 source、null 或第 65 个来源	拒绝	仍拒绝；不丢弃旧来源、不放大容量
响应丢失后重试同一 operation	复用原信封	仍复用，且先检查当前会话准入

declaresRequirements 是当前 owner 从真实旧要求 ID 与已验证 additions 推导的局部值，不是新增需要手工维护的开关。Object.hasOwn 使省略字段和显式 null 有明确区别。没有引入第二个来源日志或在 Python 重写声明决策。

具体改动

完整实际 PR 差异是 9 个文件、+196/-22：TS owner +15/-5、原生工具 +6/-4，三个测试文件 +132/-3，其余为双语 RFC 与可达工作流/修复说明。比较以实际 merge base 为准；target main 上独有的改动没有当成本 PR 的删除或回归。

评审先读取不可变接受依据 docs/architecture/rfcs/goal-outcome-refinement-v0.md @ 29d06fc4c924a8f3d4bc5725287fc7bcde887e58 及原工作流。新 RFC 不能给自己的实现背书：旧约定“所有更新都要 source”在此有意放宽为“新声明要 source”，依据是已复现的来源容量停顿，保留声明不可改写和验收权限。逐项映射如下：

原文 criterion_id	当前结果
State, reads and recovery	implemented；原要求、全部来源、CAS、原请求信封与重启重试由真实 File/SQLite 路径读回
Simplify the default path	implemented；已有 CLI、writeback 和原生对话可在不新增来源/用户往返下更新观察
Open-ended research and no premature stop	implemented；完整自查继续，但 met 仍为 unverified、independently_verified=false，配置检查与生命周期边界保留
Product journey and delivery slice	implemented；已有对话工具和实际 CLI、独立安装 wheel 可用；不声称真实模型或共享 App 已升级

关键代码讲解

1. refineGoalOutcome 先解析现存成果、原 owner/objective 和真实工作，再验证 additions 是否引入新 ID。原要求描述不能被覆盖，新声明无来源仍失败；只有既有观察/工作维护可以省略。显式来源仍校验 ref/summary，不超过 64 项，最终仍经过原 state 校验与总容量限制。
2. ChatLoopXMode 的 outcomes/refine_outcome 分支 保留严格 document 字段白名单、宿主 owner、operation/revision 与原信封。source_summary 存在才组装宿主 source，调用方不能注入 actor/source。响应丢失并重建 controller、换到稍后 turn 后，同一操作仍只重放；暂停会话连重放也拒绝。
3. projectGoalOutcomes 周围的检查与工作投影没有被放松。自查 met 只表示 Agent 观察，不能自动成为独立验收；改变工作关联会使旧 review basis 过期。当前 TS suite 对该分支、生命周期重建和配置检查有实际覆盖。

工作流明确把进展放进 review evidence/note/所属材料与操作回执，禁止丢来源、提高限额或另建成果逃容量。旧 build 兼容办法只允许为未变要求复用已检查 source 的完全相同 ref/summary，不能用来伪造新用户意图。英文/中文新增段落语义一致，committed bilingual 检查通过。

对主干的风险

最值得反证的是“省略来源”扩大成新声明、外部 owner 或自证验收的绕过入口。我用冻结后未修改的独立 probe 在不可变 base/head 执行相同实际 CLI/原生路径：File/SQLite 各在 64 次真实 canonical 来源提交后，运行七类拒绝并逐次比较完整冷读状态；包括来源超限/改写、要求改写、新成果/新要求缺来源、null 与外部 owner。拒绝均不改变 canonical 状态。随后三轮新观察成功，全部来源与两条原要求、工作关联保持不变，精确 replay 不产生新 revision。

原生 probe 在实际提交后注入一次响应丢失，再新建 controller 并换到稍后 turn 重试：head 只保留一次 review r2，来源仍一项；暂停会话返回 conversation_execution_inactive。新成果/新要求缺来源和 caller-source 注入继续拒绝。基线同一 probe 的四例都在预期省略来源/无可重放提交处失败，head 四例通过；同一 SHA 的 probe 在非 editable、独立 wheel 安装上也四例通过。只有反馈文本和响应丢失异常是合成；CLI、native handler、TypeScript owner、File/SQLite 和读回是真实代码，没有启动模型或 worker。

普通显式来源对照的完整 acceptance contract 与拒绝后完整 contract 在 base/head 相同，四类拒绝的完整 JSON 也相同。超限与两类新声明的 error_detail 有意改成可执行说明，原文差异保留，没有把诊断变化归一化掉。独立存储的 provider_revision 是不透明身份，不声称其字节相同；比较的是未删字段的完整 contract，并保留原始结果。没有用计数相等代替语义相等。

独立执行的当前检查：44 Python、30 TypeScript、改动 Python 的 Ruff、配置 mypy 17 文件、control-plane tsc 均通过；标准 premerge 为 6 direct +14 selected 全通过，无失败、skip 或 manual hold，另行 committed 双语和 diff-scoped semantic advisory 通过。advisory 只扫描支持的语法载体，空结果不证明所有语义不存在。当前 owner 的新增/保留输入已单独人工核对。

首次 wheel 构建因复用工作树旧前端包与当前 source 不一致被正确拒绝；保留这次失败记录，按标准流程重建当前 Chat bundle 后 wheel 构建、独立安装、模块字节核对和原生/CLI probe 均通过，没有修改源文件、门禁或放宽断言。作者报告的全传递 Chat mypy 大量旧诊断未在本轮重跑，不作为已独立归因或配置检查通过的替代。没有查询、轮询或等待远端 CI。

语义与范围

这是显式披露的默认输入改动，所有 Goal 的已有成果维护均可用，并无 feature-off/opt-in 承诺，因此 default_off_isolation=not_applicable。来源在新声明上的强制性、完整自查、owner、CAS/lifetime 和配置检查仍是约束；工作流建议不把它们说成可忽略的指导。错误信息保持通用成果/要求语言，无领域关键词分类。相同容器中的未来成果无来源仍拒绝，已有成果可从超限拒绝恢复到有用自查，作用域没有扩展到任意新声明。未发现具体 substring 误分类或新的通用状态词汇。

我的整体评价

要求是否新增由现有 TypeScript 成果 owner 判断；Python 原生工具只组装宿主绑定请求，File/SQLite 继续共用原有 CAS、回执和投影。来源是要求归属，证据是本次观察，二者无须共享追加频率。

本次边界是让已有 CLI、refresh-state 和原生对话工具继续维护同一成果；保留所有旧来源、不可改写要求、完整自查与验收权限，不新增存储、配置开关或界面。

该有用增量解决了本 PR 的维护停顿，problem_context=goal_achieved，repository_reuse=reused、change_proportionality=proportionate、architecture=retain、observable_semantics=intentional_change_validated、semantic_alignment=aligned。局部“requirements 只解析一次”的简化有依据；没有必要为很小的条件拆新模块或添加持久开关。现有对话与产物反馈足以承载这个动作，另建界面只会增加工作。

仓库历史经验中的“真实入口和可用结果”被用于反证 CLI/native 与独立包，而非把旧 review 当作当前授权。源码、非 editable 包可用、共享安装与真实模型采纳是不同边界；本轮只认定前两者及上述有限继续工作行为。没有作品质量、量化效率或真实模型效益的证据，不把状态保留本身宣传成效益测量。未发现需新增跟踪任务的阻塞问题；本 review 不执行 merge 或安装共享运行时，发布后仍需按原生 closeout 读回本 head。

English verdict: APPROVE. At 3b00eae0e8ddb8d228fd1a8c0d60275c278bbddb against actual merge base 29d06fc4c924a8f3d4bc5725287fc7bcde887e58, existing-outcome reviews/work links can omit source while new declarations, immutable origins/requirements, ownership, live admission, CAS/replay and independent-check authority stay enforced. Frozen actual CLI/native File/SQLite probe fails 4/4 on base and passes 4/4 on head and independently installed wheel; 64 origins survive repeated review/cold replay, including native post-commit response loss and restart. Focused 44 Python/30 TS, configured lint/type checks, rebuilt package and premerge6+14 pass. First stale-bundle setup rejection is retained and recovered by the standard rebuild. No live-model utility, shared-App installation, CI, merge or release claim.