Skip to content

fix(monitor): reuse explicit successor targets - #7195

Merged
loopx-agent merged 1 commit into
mainfrom
codex/monitor-successor-target-reuse-20261024
Oct 24, 2026
Merged

loopx-agent merged 1 commit into
mainfrom
codex/monitor-successor-target-reuse-20261024

Conversation

@huangruiteng

@huangruiteng huangruiteng commented Oct 24, 2026 •

Copy link
Copy Markdown
Collaborator

Goal And Delivered Outcome

  • Outcome basis / optional anchor: Reproduced control-plane defect: repeated material Monitor observations with one explicit successor target created generation-derived Todo ids instead of reusing the target's existing active work.
  • Goal/source and gap: Make an explicit Monitor successor target a stable, fail-closed identity. Compatible active work is reused; conflicting or ambiguous active work rejects the entire Monitor transaction.
  • Observable before → after, with the validation row that proves it: A second material generation previously authored another Todo for the same target. tests/control_plane_ts/todo_monitor_poll.test.ts now proves one stable Todo id across generations, aligned next_todos/successor_receipts, exact replay, and no write on conflicts or ambiguity.
  • Issue/task and intended base: Self-contained defect; base main.

Author Declaration

  • Written by: OpenAI Codex (GPT-6 model agent)

Implemented against

  • Specification and revision: No separate written specification; the reproduced defect and fail-closed behavior stated in this PR are the review basis.
  • Criteria:
Criterion (spec clause) Disposition Symbol / path Test or command
Reuse one compatible active Agent Todo for an explicit stable target implemented planCoordinationTodoCreate, planWriteback focused Monitor unit suite
Reject semantic conflicts and ambiguous target identities without partial Monitor writes implemented role_target identity focused Monitor unit suite
Preserve legacy role/text and generated-target behavior implemented planCoordinationTodoCreate, planWriteback Monitor and priority unit suites
  • Self-check before submission: Reviewed the exact three-file diff, kept target identity internal to the Monitor caller, preserved the legacy role/text path, scanned changed content for private identifiers and credentials, ran focused unit/type/semantic checks, and ran the complete control-plane suite. No UI, deployment, benchmark result, or persisted-schema change is claimed.

Scope And Continuation

  • Completed scope and remaining work: Complete within this scope. Explicit next_target_key now selects target identity only for Agent Monitor successors. Automatically derived targets, User successors, direct Todo creation, and operation-lane creation keep their prior identity behavior.
  • Slice boundary / successor: N/A; deployment/adoption remains a maintainer decision after review and merge.

Validation

  • Tested revision: 30cd7a0
  • Run state: finished
  • Input classes: synthetic
Check kind Result Public-safe evidence / limitation
unit passed Monitor transaction suite: 14/14 passed, covering compatible reuse, exact replay, semantic conflict, ambiguity, and atomic no-write behavior.
unit passed Todo priority/create compatibility suite: 7/7 passed.
static passed npm run typecheck:control-plane.
static passed Semantic vocabulary drift smoke: 1/1 passed; no new shared vocabulary finding.
static passed git diff --check and changed-file public-boundary scan passed.
integration failed npm run test:control-plane: 5,415 passed, 75 skipped, 1 failed. The sole failure is the whole-value digest owner guard against loopx/control_plane/capabilities/trajectory_input_usage.ts:24; that file and the guard are unchanged from main and the offending regex is present in base commit b8b9c1d.

See validation disclosure guidance.

Frontend / Visual Evidence

  • UI impact: none
  • Before: N/A
  • After: N/A
  • First viewport and preview: N/A
  • States and viewports shown: N/A
  • Source data: none
  • Attention review: N/A
  • Craft review: N/A

Type of Change

  • Bug fix
  • New feature
  • Breaking change
  • Refactoring (no functional changes)
  • Documentation update
  • Test update

LoopX Area

  • Control plane (goals, todos, quota, scheduler, registry, runtime)
  • Benchmark boundary (adapters, runners, verifiers, scoring, evidence)
  • Capability or extension (providers, adapters, skills)
  • Public docs or presentation surface (README, protocols, dashboard)
  • Build, packaging, installer, or CI
  • Host or runtime integration

Technical Direction

  • Direction / acceptance reference, when applicable: Core control-plane hardening.

Shared-authority RFC fixture impact

  • Production-scale fixture schema: unchanged
  • Semantic dimensions changed, or reviewed no-impact rationale: Adds an internal creation identity selector for explicit Monitor successor targets; no persisted field or public request schema changes.
  • Provider conformance arms run: File authority Monitor transaction tests.
  • Read-only legacy/file/PostgreSQL three-arm rehearsal (required for promotion, runtime-routing, or compatibility-projection changes): Not applicable; no provider routing, storage format, or compatibility projection changes.

Boundary Checklist

  • Neither the diff nor this PR body/comments/attachments disclose private state, credentials, raw traces or verifier output, internal links, or local machine paths (including .loopx/, .codex/goals/, and live ACTIVE_GOAL_STATE.md).
  • I did not duplicate maintainer-owned benchmark work unless a maintainer split out a public issue for it.
  • I kept the change scoped to the linked issue/task.
  • Existing English/Chinese RFC pairs (including ledger entries) both have a diff, and the local premerge check passes, or no paired RFC changed.
  • I completed the visual evidence section for UI changes, or marked UI impact none.
  • Every commit includes a DCO Signed-off-by trailer.

Signed-off-by: huangruiteng <huangrt01@163.com>

@loopx-agent loopx-agent left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

动机

使用 Monitor 持续观察变化、通过显式 target 标识后续工作的 CLI 调用者与既有控制面入口。

同一目标换了任务说明时,基线可能新建第二个同目标 Todo;不同目标恰好使用同一句任务说明时,基线反而以文字重复拒绝。当前提交用显式目标区分两者:兼容任务复用,冲突或多重匹配整笔拒绝,不同目标可分别继续。

真实 CLI 起步、原生写入及独立回读的 File/SQLite × legacy/native 四种组合通过:两个目标分别创建,后续兼容观察复用原 ID,回执一致,原操作重放无写入;冲突无部分状态,改回兼容意图后继续成功。

不增加执行、认领、配额或合并权限,不迁移存储,不提供新能力页面,也不以本地验证宣称安装采用或长期净收益。

改动思路

扩展既有 Todo 创建 planner 的局部身份参数,并由 Monitor 选择;共享候选归一化、语义比较和事务已足够,无需新字段、索引、全局开关或第二个写入器。

本 PR 完成显式 Agent Monitor 后继的目标身份选择与原子拒绝;既有自动目标、User 后继、直接 Todo 创建及 operation_lane 路径保持原合同。

独立核验支持这个边界,但需要校正证据解释:在本次不可变基线 e3fa61956b6e374b4475162039b7bf9f4282be01 的同输入样本里,完全兼容的同文字、同显式目标连续观察已经复用原 Todo。因此那个 happy path 本身不证明本 PR 修好了旧缺陷。真正区分 base/head 的反例是“同目标改变任务内容/优先级或存在两个活动匹配”,以及“不同显式目标使用相同文字”。前者当前会整笔拒绝,后者当前可以各自继续,价值不依赖作者的完成声明。

调用场景 基线实测 当前提交实测
同目标、兼容内容 已复用 保持复用,原回执可重放
同目标、冲突内容/优先级或多重身份 可能新增/选中已有任务 拒绝,Monitor 与 Todo 都不写
不同显式目标、相同文字 错按文字重复拒绝 创建不同后继,之后分别复用
未提供目标、User、直接创建/operation_lane 既有路径 同输入对照保持原行为

具体改动

关键代码讲解

  • planCoordinationTodoCreate(loopx/control_plane/coordination/todo_create.ts:165)复用已有候选归一化和语义比较,在局部 identity 联合类型中加入 role_target。只查同 role 的活动未完成、非 deferred 记录;零个匹配按原路径创建,一个匹配继续核对语义,多个匹配拒绝,避免任意选一个。目标身份不会覆盖既有任务内容、认领或回执。
  • planWriteback(loopx/control_plane/scheduler/monitor_batch.ts:56)只在 Agent 后继显式给出 next_target_key 时选择新模式。兼容的 no_change 仍进入 next_todos 和 successor_receipts,但不产生额外 successor upsert。未提供目标及 User 后继继续使用旧规则;这不是把所有 Todo 的身份改成 target。
  • executeCoordinationMonitorPoll(loopx/control_plane/coordination/todo_monitor_poll.ts:117,未改的调用方)先恢复原请求回执,再读取同一个已准入 authority head;planner 的冲突在 CAS 前转为 monitor_poll_rejected/no_effect。实际 File/SQLite 回读证明拒绝不推进观察、不新增业务回执;改回兼容意图后可以继续,不需要绕过 lease、配额或换写入器。

无单独书面 stable-target 规格,本评审使用已复现的上述反例和既有 Monitor 配置/观察合同、Todo 路由合同作为有界依据,不编造 RFC 验收 ID。role_target 是同部署 planner 的局部参数,不是新增持久协议、能力或权限;target_key 仍是现有显式意图,经真实 CLI 产生并独立落盘回读。

对主干的风险

我独立执行了 780 个相关 TS 测试、57 个既有 Python 真实路径测试、4 个额外真实 CLI→原生写入→回读组合,全部通过。四个额外组合覆盖 File/SQLite 与 legacy/native 记录:不同目标、兼容复用、原回执重放、冲突无部分写入,以及纠正后继续执行。相同独立入口脚本在不可变基线确实因第二个不同目标的同文案触发旧 role/text 拒绝而失败。另做了 50 行 File/SQLite 同输入对照,保留完整业务字段、诊断、观察时钟和回执;36 行完全相同,其余为上述目标/诊断差异与不能按时序逐字节比较的并发结果,没有用聚合通过数代替语义判断。

真实隔离 PostgreSQL 16.15 的完整 authority-store integration 369/369 通过,测试实例仅绑定 loopback、无主机数据挂载,结束后清理;未拿活动 Goal 做破坏性验证。typecheck:control-plane 与标准 premerge 的 4 项直接检查、17 项选中 canary/smoke 通过。没有读取、等待或轮询远端 CI,也没有本次生产安装验收。

保留红项:content_digest_single_owner.test.ts 的定向检查在 base/head 都是 16 过、1 失败,完整失败对象同为 trajectory_input_usage.ts:24 /^[a-f0-9]{64}$/;该文件与检查器在两个版本逐 blob 相同。此失败路径与三文件身份修复无因果改动,且变更不变量有独立通过证据,因此归为既有无关失败,不作为本 diff 的阻塞发现;全库仍不能称全绿,也没有通过删除断言或放宽门槛改写它。初版私有核验脚本的记录顺序和错误回读 helper 两处问题已纠正并保留失败记录,未当作产品缺陷。

我的整体评价

APPROVE,针对精确 head 30cd7a0112512bc0c4c832a3fa5637f395d58966。未发现当前差异引入的阻塞缺陷;这个局部类型分支在已有 create/transaction owner 中完成目标身份的正确区分,避免额外状态、写入器和确认流程。已有 claim/lease、原始请求身份、回执优先恢复与 provider CAS 保持其权限边界;没有用一次评审或测试数量宣布整个长期目标完成。

已检查既有 Monitor CLI、共享 Todo/事务及其展示消费者;本 diff 不改渲染页面、控件或布局,视觉验收不适用。

未跑本轮全库套件、生产安装、真实模型或自然时间长期收益实验。digest-owner 定向检查在不可变 base 与 head 同为 16/17、同一 trajectory_input_usage.ts:24 违规;文件和检查器 blob 相同,属于独立的既有失败,不能称全库全绿。未读取或等待远端 CI。

本结论是代码评审结论;另行需要的合并准备度、红项处置与合并权限仍按当前合同判定,本文不执行合并或升级。长期净成本收益和真实模型采用未验证,不能从这里推导节省比例。

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

English verdict: APPROVE at HEAD 30cd7a0112512bc0c4c832a3fa5637f395d58966. The local target-identity selector correctly distinguishes explicit Agent successors, rejects conflicting or ambiguous matches before atomic writeback, and preserves other lanes. Independent real CLI/File/SQLite counterexamples and isolated PostgreSQL integration support this bounded change. Compatible identical-target repetition already passed the inspected base; the distinguishing regressions are conflicting/ambiguous target identity and equal text across distinct targets. The unchanged digest-owner failure remains disclosed; this review grants no merge or installation authority.

@loopx-agent
loopx-agent merged commit 28f410c into main Oct 24, 2026
30 of 41 checks passed
@loopx-agent
loopx-agent deleted the codex/monitor-successor-target-reuse-20261024 branch October 24, 2026 07:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants