release: prepare LoopX v1.2.0 package version - #5015
Conversation
Signed-off-by: huangruiteng <14976749+huangruiteng@users.noreply.github.com>
9e1a82f to
2e9892a
Compare
huangruiteng
left a comment
huangruiteng
left a comment
There was a problem hiding this comment.
Approval conclusion (author-owned PR; GitHub blocks formal self-approval)
Reviewed exact head: 2e9892a.
动机
用户要求先完成必要的 bug fix 再发布 LoopX 新版。当前主干的公开版本命令和包元数据仍是 1.1.0；若直接给它打 v1.2.0 标签，安装、升级和诊断都会看到互相矛盾的版本。本 PR 解决的是发布前的版本身份准备，不代表已经完成打标、产物和 PyPI 发布。
改动思路
沿用现有的两个版本入口：loopx.__version__ 供 CLI、release manifest 和 doctor 读取，pyproject.toml 的 [project].version 供 setuptools 生成包元数据。两处一起改为 1.2.0，现有 release-version-contract smoke 负责校验相等、tag 派生及升级回读。没有增设配置、状态或第三套版本来源；分支已纳入主干的 #5010 发布修复、#4991/#4992/#4995 配额修复及 #4159/#4156/#4363 工作区修复，但这份 PR 的实际差异仍只有两个版本字面量。
具体改动
loopx/__init__.py:5 把运行时版本从 1.1.0 改为 1.2.0；公开 loopx --version、package_release_metadata()、release manifest、doctor 与 update plan 读取的是这条现有路径。pyproject.toml:7 同步改变构建元数据版本，使 wheel 和 sdist 的身份与运行时一致。没有修改入口参数、包 schema、Goal authority、调度或可选能力默认值。
关键代码讲解
loopx.__version__是运行时身份源，version.py将它返回给公开 CLI，release_manifest.py从它派生v1.2.0。不匹配的安装清单仍由 doctor 标成需要修复。[project].version是 setuptools 读取的构建身份；只改运行时常量会留下包元数据 1.1.0，现有版本契约测试会拒绝这种单边修改。两处字面量并列是当前构建边界，不值得为一次发版引入新的版本注册层。
在同一解释器与同一检查脚本下，基线主干的公开 CLI 返回 loopx 1.1.0、元数据派生 v1.1.0；当前 head 分别返回 loopx 1.2.0 与 v1.2.0。两边版本契约 smoke 都通过，包括故意伪造 9.9.9 安装清单时得到 repair_recommended 的负例。
对主干的风险
最重要的风险是只修改一个版本来源，或在此后再次合入代码却沿用旧的测试结果。两处同时更新、契约 smoke 和主干/当前 head 的相同入口对照覆盖了前者；发布流程必须对最终干净提交重新做完整资格核验，不能把本 PR 的检查当成标签提交的证明。本地 Ruff、配置范围内的 mypy、差异检查，以及风险 premerge 的两项 canary 均通过；premerge 没有失败或手工 hold。发布产物 CI、真实安装和模型门禁属于后续精确提交的 release 决策，不能由版本 PR 擅自替代。若合并前包构建暴露版本不一致，应在现有版本 owner 修复并重新运行版本契约。
我的整体评价
未发现阻断问题。对长期运行而言，这两行不改变 Goal 状态或续跑规则，并让未来更新回读保有一致版本；对用户而言，新版发布后能看到真实的 1.2.0 身份，错误安装清单仍有明确修复提示。改动规模与目标相称，复用了现有版本契约，也没有新增未启用能力或更广的 authority。批准当前 head 的版本准备；是否发布 v1.2.0 仍取决于独立评审、最终提交核验和远端产物回读。
English verdict: APPROVE - exact head 2e9892a; the two existing version sources now agree on 1.2.0, baseline/head CLI and metadata checks plus local quality gates passed. Release publication remains separately gated.
1 participant
LoopX v1.2.0 — verifiable team work and recoverable local agents
At a Glance
LoopX now makes a multi-agent correction legible from the original work through objection, revision, independent acceptance and adoption. Accepted team reports can return to the source manager plan and appear in Goal Files, while Goal acceptance and the canonical state layer retain the evidence and recovery rules behind that presentation. This release covers merged work since v1.1.0; it does not include open PRs or claim that a synthetic research example proves financial research quality.
Upgrade
Existing installations should inspect the update, apply it through their current installation owner, then read back the active version. New installations use the PyPI path in Install / Update.
loopx update check loopx update plan loopx update apply loopx --version && loopx doctor --deepHighlights
goal.createworkspace gate survives refresh, selection, regenerated preview, explicit confirmation and receipt readback. (#4159, #4156, #4363)goal-acceptance inspectbefore judging completion. (#4833, #4957, #4962, #4963, #4989)Replan Fixes
Release Decision
Who should upgrade: Operators using Goal Chat, steward routing, team delegation, Goal acceptance, canonical authority, Reward Memory or Windows bundles should upgrade after the release assets pass. Users stable on v1.1.0 who do not need those changes can wait.
What this release solves: A team result can be traced back to source work and independent acceptance; stalled or ambiguous canonical operations have bounded recovery; manager and host paths return clearer evidence instead of duplicate or misleading completion.
Breaking changes: Yes. The minimum Node.js version is now 22.22.3; Node.js 24 LTS is recommended. Upgrade Node before source, CLI or SQLite-authority use. No automatic promotion to canonical coordination, external research, Reward Memory or Jev observation is introduced; existing Goal authority is not silently migrated. Optional experiments retain their own activation and rollback rules below.
How to verify: After updating,
loopx --versionmust report1.2.0;loopx doctor --deepmust report the active installation. For a Goal, inspect its canonical Todo and Goal-acceptance readbacks under its own registry and runtime.Contributors: 14 community contributors, including @Green-hats and @luw2007, shipped changes in this tag range; each contribution is linked below.
loopx --version loopx doctor --deep loopx --format json goal-acceptance inspect --goal-id "$GOAL_ID"State Kernel & Control Plane
Canonical Todo, Monitor and quota settlement now handle deferred selections, in-flight work, archived Todo closeout, current source capture and long-history transport more consistently; rejected monitor-poll reservations are released, and a deferred receipt-bound Turn keeps its own selection (#4991, #4992, #4995); recovery names the original obligation or typed refusal. Complete source-bearing operations can cross the ordinary 2 MiB RPC limit through a separate, host-local transfer capped at 16 MiB per direction, while the original typed authority and operation receipt remain in charge. (#5010) Explicit leased Agent handoff can carry current context across an atomic claim-and-lease transfer without granting the receiver a new execution lease. (#4764, #4816, #4852, #4883, #4907, #4923, #4967, #4979, #4994)
Whole-Goal coordination promotion is previewed, fenced and recoverable, with retained claims and canonical source readback. It is still an explicit administrative cutover, not a new default or a universal migration to SQLite/PostgreSQL. (#4774, #4799, #4870, #4879, #4898)
Capabilities & Workflows
Goal Chat and the manager can show team readiness, versioned correction evidence, report comparison and adoption; an accepted result also returns to its source manager plan and Goal Files. The synthetic research example is configurable, but a production financial-research outcome and a team-wide stop button remain outside this claim. (#4814, #4828, #4885, #4904, #4945, #4970, #4987, #4978)
Personal Workspace remains usable when browser storage is denied, follows the browser language on first use, and restores a gated Goal workspace choice after reload without applying before confirmation. The persisted action receipt is read back after apply. (#4159, #4156, #4363)
Optional workflows gained an auditable external-evidence lifecycle, structural and destination-recall qualification for Reward Memory, a default-off Jev progress-review sentinel, and owner-configured automation cadence floors with a Goal settings editor. Each keeps a separate activation and authority boundary below. (#4813, #4824, #4854, #4866, #4921, #4929, #4933)
Quality & Testing
The tag range adds targeted tests for non-UTF-8 hosts, retry ceilings, quota readback, SQLite capacity and Windows packaging. Four private atomic writers now guard the POSIX-only
fchmodcall on native Windows; release CI also exercises the current packaged Files empty state. PR review now requires outcome and scope evidence in the checked review body, so a locally correct change cannot pass with an empty or stale conclusion. (#4998, #5010) The release qualification result for the exact candidate commit will be stated in the publication readback; a previous PR's tests are not relabelled as release-commit evidence. (#4778, #4910, #4942, #4951, #4982, #4986, #5002)Benchmarks & Integrations
LHTB research metrics and the open Jev observer differential are presented with their source and limits. No general benchmark uplift, investment conclusion or live multi-agent outcome claim is made by this release. Managed Codex and DSH workers have stronger binding and credential handling, while an example run still requires its own model, cost and acceptance verification. (#4811, #4854, #4865, #4885, #4903)
Documentation & Compatibility
Node.js 22.22.3+ is required for the WAL-fixed embedded SQLite runtime; Python remains 3.11+. Existing persisted Goal data is not automatically moved to another authority provider. The Personal Workspace and agent guide have clearer first-use and team explanations; the maintained project code tour helps contributors locate ownership boundaries. GitHub-rendered issue, security and support routes now point at the current repository, with a guard against stale live links. (#4791, #4884, #4954, #4959, #4960, #4965)
Community Contributors
Optional Capability Activation & Use
Managed Research Team Example
Activation: From a source checkout with the documented optional providers and credentials,
prepare-chatcreates an isolated synthetic Goal without model calls;run --team-size 1 1 1launches a billable Luna/DSH/Ark team only when explicitly requested.Validation: Inspect canonical Todos and independently run
validate-reportfor the DSH-led route. The Goal Chat route returns a report to the conversation but does not itself complete the lead-report Todo.Disable / rollback: Do not re-run an interrupted directory. Pause the Chat coordinator, inspect original member operations, stop each running provider through its owning control, and remove bindings only after reconciliation. Preparation can be discarded with its disposable directory.
Authority boundary: Configuration is not login, execution or acceptance. Every member needs canonical completion and current adoption; the example grants no production research authorization or team-wide cancellation.
Docs: https://github.com/loopx-project/loopx/blob/v1.2.0/examples/managed-research-team/README.md
Goal Acceptance Contracts
Activation: Preview an owner-reviewed acceptance document against the current provider revision, then repeat with
--execute. An open Todo validator revision also needs the existing reviewed edit path.Validation: Run
goal-acceptance verifyandgoal-acceptance inspectagainst the same Goal; inspect typed failures and independent scope before calling the Goal accepted.Disable / rollback: Read the latest provider revision and explicitly run
goal-acceptance disable --execute; historical receipts remain. Revert validator changes through their revision-checked owner.Authority boundary: Acceptance does not grant claim, execution, provider promotion, publication or Goal completion. A local validator cannot silently capture independently scoped work.
Docs: https://github.com/loopx-project/loopx/blob/v1.2.0/docs/reference/goal-acceptance-observations.md
Automation Cadence Floors
Activation: In Goal settings, preview and apply an owner-scoped minimum interval, or use
automation-cadencewith the current revision and--execute. Update the existing Codex App automation separately after reading back the recommendation.Validation: Read
automation-cadenceagain and inspect the same Turn's scheduler hint and actual Codex App automation schedule.Disable / rollback: Pause the affected schedule, write zero at the scope with its latest revision and
--approve-reduction --execute, then read back inherited parent floors. Downgrade only while the schedule remains paused.Authority boundary: This enforces a recommendation floor, not a pre-model App launch hook, token budget or automatic schedule mutation. Existing automations are unchanged by the setting alone.
Docs: https://github.com/loopx-project/loopx/blob/v1.2.0/docs/operations/automation-minimum-interval.md
External Evidence Research
Activation: Use
external-evidence discoverandplanwith an explicitly ready host method or connector; the chosen provider executes under its own permissions, then the parent supplies and reviews a bounded receipt.Validation: Read the plan, source provenance and
admitdecision before downstream use. A registry row or caller-presented receipt alone does not attest provider execution.Disable / rollback: Reject the candidate or
retirethe exact admission after its referenced sources appear in downstream readback; disable the external provider at its own owner if no further calls are wanted.Authority boundary: Evidence admission does not grant source credentials, downstream writes, publication or execution authority. Raw pages and provider-private state stay outside the compact LoopX record.
Docs: https://github.com/loopx-project/loopx/blob/v1.2.0/loopx/capabilities/external_research/README.md
Reward Memory Experience Qualification
Activation: Preview an ignored, repo-relative provider configuration for one registered Goal Agent with
configure-goal --reward-memory-config --reward-memory-agent, then explicitly apply. A qualified procedural experience needs evidence, exact write readback and destination recall.Validation: Read
reward-memory experiment-statusfor the same Goal and Agent; inspect quality and destination-recall receipts instead of equating persistence with usefulness.Disable / rollback: Use
configure-goal --goal-id "$GOAL_ID" --clear-reward-memory-config --execute. Disabling stops automatic use but does not erase provider data or historical receipts.Authority boundary: This is default-off and Agent-scoped. It does not create a background learner, share a private corpus with sibling Agents, or turn remembered policy into action authority.
Docs: https://github.com/loopx-project/loopx/blob/v1.2.0/loopx/capabilities/reward_memory/README.md
Progress Review Sentinel
Activation: Install the optional Jev observer and bind a Goal basis as documented. Start in
shadow; considerassistonly after reviewing real receipts and pinning the observer contract revision.Validation:
loopx status --format jsonshowsexternal_progress_reviewand any typed autonomous-replan obligation. The committed differential can be replayed without a live provider key.Disable / rollback: Set
--progress-review-mode off --executeor clear the policy; stop the separate Jev drain process. Existing receipts remain audit history.Authority boundary: Shadow does not alter the Goal. Assist raises an existing replan obligation; it cannot pause work, grant an Agent permission or claim improved real-Goal outcomes.
Docs: https://github.com/loopx-project/loopx/blob/v1.2.0/loopx/capabilities/progress_review/README.md
loopx configure-goal --goal-id "$GOAL_ID" --progress-review-mode shadow --execute loopx --format json statusCoordination Authority Promotion
Activation: Explicitly enable the transaction-bound File shadow for one Goal, bootstrap and qualify it, then preview the reviewed
coordination-shadow promoteoperation. Apply only the exact reviewed plan on a qualified Goal.Validation: Compare
coordination-shadow inspectandqualifyreadbacks, then inspect the canonical provider and original operation receipt after cutover.Disable / rollback: Before promotion, clear the runtime shadow setting or use its revision-fenced quarantine rollback. After promotion, keep the legacy writer fenced; a downgrade requires the separately reviewed export/reconciliation path, never a blind fence removal.
Authority boundary: A shadow is not authority. This action changes Todo/lease mutation ownership only after explicit review; it does not move arbitrary Goal files or grant a provider, Agent or database new access.
Docs: https://github.com/loopx-project/loopx/blob/v1.2.0/docs/architecture/rfcs/shared-goal-authority-state-provider-v0.md
Leased Agent Continuation
Activation: On a canonical
hard_leaseGoal, the current owner explicitly runsloopx handoff preparewith its lease key/version, thentask-lease transfer --transfer-claim; the receiver uses its new proof tohandoff inspectandhandoff adopt. This does not launch a receiver session.Validation: Inspect the current Todo and lease after transfer, then run
handoff inspectwith the receiver's current key/version. Only a current proof can reportcan_adopt=true; historical adoption alone is not authority.Disable / rollback: There is no global switch. Stop before transfer to abandon an uncommitted preparation. After a committed transfer, reconcile the current claim and lease before an explicitly authorized transfer back; never retry it with a new operation identity after an ambiguous response. Repair a pending Markdown projection with the original operation or
todo project-markdown, without replaying the business mutation.Authority boundary: The workflow does not acquire or renew a lease, authenticate a host session, launch an Agent, change a fixed binding, or grant external tool authority. The canonical lease and claim remain the execution gate.
Docs: https://github.com/loopx-project/loopx/blob/v1.2.0/docs/architecture/rfcs/cross-session-memory-substrate-v0.md#leased-execution-continuation
Delegated Codex and DSH Workers
Activation: Provide a reviewed local delegation execution binding for the requester; the managed Codex route now exposes only its bound MCP tools. DSH uses machine-owned credentials unless the operator explicitly overrides them for that process.
Validation: Under the same requester identity, list routes and operations and read the member's canonical Todo and acceptance result. A configured worker is not a successful execution.
Disable / rollback: Revoke the binding and stop/reconcile any admitted worker with its own provider control. Restart the MCP server without
--execution-configto remove execution tools; clearing a Goal pointer alone does not revoke a grant.Authority boundary: Registration, model selection and MCP exposure do not bypass task scope, lease, quota, credential custody or independent acceptance. Credentials are not copied into a Goal.
Docs: https://github.com/loopx-project/loopx/blob/v1.2.0/docs/reference/local-delegation.md
Install / Update
New installations use PyPI; existing installations use their current pip, pipx or archive owner. Restart the agent host after first installing workflow skills.
中文摘要
LoopX v1.2.0 把团队的“提出异议—修订—独立验收—采用”从对话效果推进到可核查的工作链。已验收的团队报告能回到来源管家计划，并在 Goal 文件中读回；Goal 验收和 canonical 状态仍由各自的权限 owner 决定。它汇总 v1.1.0 之后已合入的工作，不包含仍开放的 PR，也不把合成投研示例当作真实投资质量证明。
升级亮点
升级决策
**谁需要升级：**使用 Goal Chat、管家路由、团队委托、Goal 验收、canonical authority、Reward Memory 或 Windows 安装包的 operator，在发布包验证通过后升级；不依赖这些变化且稳定运行 v1.1.0 的用户可暂缓。
**解决了什么：**团队结论能追到源任务及独立验收，卡住或模糊的 canonical 操作可按原 operation 恢复，管家与宿主给出更清楚的证据和失败反馈。
**是否有破坏性变更：**有。Node.js 最低版本为 22.22.3，推荐 Node.js 24 LTS；源代码、CLI 或 SQLite authority 使用前先升级 Node。不自动提升协调 authority、启用外部研究、Reward Memory 或 Jev，也不暗中迁移现有 Goal 状态。
**如何验证：**升级后
loopx --version为1.2.0，loopx doctor --deep指向当前安装；同一 registry/runtime 下读回 Goal Todo 与验收。上方英文代码块提供最小命令。**贡献者：**本次 tag 区间包含 14 位社区贡献者，包括 @Green-hats 和 @luw2007；具体贡献及 PR 见下方。
状态内核与控制面
Agent 的持续监控数量不再误计为推进任务长链：9 个推进 Todo 加 19 个 Monitor 可继续运行，15 个推进 Todo 仍触发长链义务（#5004）。
Todo、Monitor、quota 的延期选择、进行中结算、归档收口与长历史读取更一致；被拒绝的 Monitor poll 预约会释放，绑定旧回执的延期 Turn 保留自身选择（#4991、#4992、#4995）；拒绝和恢复指向原本的义务。完整源操作可通过独立的本机传输越过普通 RPC 的 2 MiB 限制，每方向最多 16 MiB；原有类型化 authority 与 operation receipt 仍负责准入和恢复（#5010）。已持有硬租约的 Agent 可显式把当前上下文随 claim 与租约原子转交，不会因此替接收者创建新执行资格（#4764、#4852、#4923、#4979、#4994）。整个 Goal 的协调 authority 晋升仍是显式操作，不是 SQLite/PostgreSQL 默认迁移（#4799、#4879）。
能力与工作流
Goal Chat、管家和团队报告将 readiness、修订、验收、采用及结果回到来源计划放在同一证据链；真实投研质量与团队统一停止仍需后续验证（#4814、#4828、#4945、#4978、#4987）。个人工作区即使浏览器存储被拒也可加载；首次语言遵循浏览器且不覆盖已有选择；已保存的 Goal 创建门槛在刷新后仍可完成选择、预览、确认和回执读回（#4159、#4156、#4363）。外部证据、Reward Memory、Jev 进度复核和自动执行间隔均保留显式配置与单独权限边界（#4813、#4824、#4854、#4933）。
质量与测试
本区间新增非 UTF-8 宿主、重试上限、SQLite 容量与 Windows 包装回归；四处私有原子写入在 Windows 不再调用 POSIX 专属的
fchmod，发布 CI 同时验证当前的 Files 空状态；PR 评审会校验结果与范围证据和最终正文，避免仅凭局部正确或过时结论放行（#4778、#4942、#4951、#4986、#5002、#4998、#5010）。正式发布核验以确切 tag 提交为准，不把单个 PR 的通过结果冒充整版通过。基准与集成
LHTB 指标和 Jev 差异实验保留来源及限制；本版本不宣称普遍 benchmark 提升、投资结论或真实多 Agent 结果（#4854、#4865、#4903）。Codex/DSH 托管 worker 的绑定和凭证使用更明确，运行示例仍需单独核对成本和验收（#4811、#4885）。
文档与兼容性
Node.js 22.22.3+ 为 SQLite WAL 修复后的最低运行时，Python 仍要求 3.11+；已有 Goal 不会自动切换 authority provider。个人工作区与贡献者指南更清楚地说明入口和模块归属；GitHub 的提问、安全报告与支持入口改为现仓库地址，并阻止新的旧链接回流（#4791、#4954、#4959、#4960、#4965）。
社区贡献者
可选能力启用与使用
Managed Research Team Example
**启用：**在源码 checkout 安装文档列出的 provider 并配置机器凭证；
prepare-chat只准备隔离 Goal，显式run --team-size 1 1 1才启动可能计费的 Luna/DSH/Ark 团队。**验证：**读回 canonical Todo；DSH lead 路线另用
validate-report独立复验。Goal Chat 的报告返回对话，不自动完成 lead-report Todo。**停用 / 回退：**中断后不要在同目录重跑；暂停协调员、核对原成员 operation，分别用原 provider 控制停止/恢复。仅准备的隔离目录可废弃。
**权限边界：**配置不等于登录、执行或验收；每名成员都需完成并被采用，示例不授予真实投研权限或统一取消能力。
**文档：**https://github.com/loopx-project/loopx/blob/v1.2.0/examples/managed-research-team/README.md
Goal Acceptance Contracts
**启用：**先以当前 provider revision 预览 owner 审阅的验收文档，再加
--execute；Todo validator 修订也走既有审阅写入入口。**验证：**对同一 Goal 执行
goal-acceptance verify和inspect，检查 typed failure 与独立范围。**停用 / 回退：**读取最新 revision，显式执行
goal-acceptance disable --execute；历史回执保留。validator 修订按自身 revision 规则撤回。**权限边界：**验收不授予 claim、执行、provider 晋升、发布或 Goal 完成权限；本地 validator 不能吞并独立验收范围。
**文档：**https://github.com/loopx-project/loopx/blob/v1.2.0/docs/reference/goal-acceptance-observations.md
Automation Cadence Floors
**启用：**Goal 设置页或
automation-cadence先预览再用当前 revision 执行；Codex App 的既有 automation 日程需单独更新并读回。**验证：**再次读取 cadence 与同一 Turn 的 scheduler hint，核对 Codex App automation 的实际日程。
**停用 / 回退：**先暂停受影响日程，用最新 revision、
--approve-reduction --execute将该范围设为零，再读回父级下限；降级时仍保持暂停。**权限边界：**这里只约束推荐间隔，不是 App 启动前钩子、token 预算或自动修改既有日程。
**文档：**https://github.com/loopx-project/loopx/blob/v1.2.0/docs/operations/automation-minimum-interval.md
External Evidence Research
**启用：**用
discover、plan选择当前 ready 的 host method 或 connector，由其自身权限边界执行后提交有界回执供父 Agent 审阅。**验证：**检查 plan、来源 provenance 与
admit决定；registry 行或调用者提供的回执不等于 provider 执行证明。**停用 / 回退：**拒绝候选证据，或下游来源读回后按完整 admission 身份
retire；不再调用时在 provider owner 侧停用。**权限边界：**采纳证据不授予来源凭证、下游写入、发布或执行权；原始网页与 provider 私有数据不进入紧凑记录。
**文档：**https://github.com/loopx-project/loopx/blob/v1.2.0/loopx/capabilities/external_research/README.md
Reward Memory Experience Qualification
**启用：**对一名已注册 Goal Agent 预览忽略提交的 repo-relative provider 配置，再显式执行；经验须有证据、精确写后读回及目标召回。
**验证：**同一 Goal/Agent 执行
reward-memory experiment-status，分别看 quality 和 destination-recall 回执，不能把存储成功当作有效记忆。**停用 / 回退：**执行
configure-goal --goal-id "$GOAL_ID" --clear-reward-memory-config --execute；停用不会删除 provider 数据或历史回执。**权限边界：**默认关闭且 Agent 范围隔离；不创建后台学习器，不向兄弟 Agent 分享私有 corpus，也不把记忆升级为行动权限。
**文档：**https://github.com/loopx-project/loopx/blob/v1.2.0/loopx/capabilities/reward_memory/README.zh-CN.md
Progress Review Sentinel
**启用：**按文档安装 Jev observer 并绑定 Goal basis，先用
shadow；只有评估真实回执并固定 observer contract revision 后才考虑assist。验证：
loopx status --format json的external_progress_review和 typed replan obligation 可读回；已提交差异实验可无密钥复现。**停用 / 回退：**设置
--progress-review-mode off --execute或清除配置，并停止独立 Jev drain；历史回执留存。**权限边界：**shadow 不改变 Goal；assist 只触发既有 replan 义务，不授予暂停或新权限，也不证明真实 Goal 结果改善。
**文档：**https://github.com/loopx-project/loopx/blob/v1.2.0/loopx/capabilities/progress_review/README.zh-CN.md
loopx configure-goal --goal-id "$GOAL_ID" --progress-review-mode shadow --execute loopx --format json statusCoordination Authority Promotion
**启用：**按 Goal 显式打开 transaction-bound File shadow，bootstrap、qualify 后预览
coordination-shadow promote；只有审阅完全相同的方案后才能应用。**验证：**对照
inspect、qualify和切换后的 canonical provider 与原 operation 回执。**停用 / 回退：**晋升前清除 shadow 设置或用其 revision-fenced quarantine rollback；晋升后保留旧写入围栏，降级需另行审阅的导出与核对，不能盲目解除围栏。
**权限边界：**shadow 不是真值；显式切换只改变 Todo/lease 写入 owner，不搬迁任意 Goal 文件，也不增加 Agent/provider/数据库权限。
**文档：**https://github.com/loopx-project/loopx/blob/v1.2.0/docs/architecture/rfcs/shared-goal-authority-state-provider-v0.zh-CN.md
Leased Agent Continuation
启用： 在 canonical
hard_leaseGoal 上，当前 owner 带自己的租约 key/version 显式执行loopx handoff prepare，再用task-lease transfer --transfer-claim原子转交；接收者凭新的执行证明handoff inspect和handoff adopt。这一步不会启动接收者会话。验证： 转交后检查当前 Todo 与租约，再以接收者当前 key/version 执行
handoff inspect；历史 adoption 回执不能代替当前执行资格。停用 / 回退： 没有全局开关。转交前可停止未提交的准备；转交提交后须先核对当前 claim 与租约，再经显式授权转交回来。不确定结果沿用原 operation 身份核对，不能换身份重试；投影待送达时重试原操作或运行
todo project-markdown，不重复业务变更。权限边界： 不获取或续租、不认证宿主会话、不启动 Agent、不改固定绑定，也不授予外部工具权限；canonical 租约与认领仍是执行门槛。
文档： https://github.com/loopx-project/loopx/blob/v1.2.0/docs/architecture/rfcs/cross-session-memory-substrate-v0.md#leased-execution-continuation
Delegated Codex and DSH Workers
**启用：**为请求者提供审阅过的本地执行 binding；托管 Codex 只暴露该 binding 的 MCP 工具，DSH 默认使用机器凭证，进程环境覆盖需显式设置。
**验证：**用同一请求者读取 route、operation、成员 canonical Todo 和验收；配置成功不等于模型执行成功。
**停用 / 回退：**撤销 binding，按原 provider 控制停止并结算已准入 worker；不带
--execution-config重启 MCP 可去掉执行工具。只清 Goal 指针不等于撤销 grant。**权限边界：**注册、选模型或 MCP 暴露不能绕过任务范围、租约、quota、凭证托管与独立验收；凭证不会复制到 Goal。
**文档：**https://github.com/loopx-project/loopx/blob/v1.2.0/docs/reference/local-delegation.md
发布验证
本页只记录 tag 范围内已合入的能力；精确 release commit 的完整 CI、发布包、PyPI、桌面签名和 stable ref 读回以发布后的验证记录为准。没有匹配基线的 benchmark 结果声明，因此不要求昂贵的对照结果活动。