[xuruijohn]

Summary

• add a LoopX-native, task-bound local synthetic overlay with ZERO product write authority
• bind issuance and validation to the Goal registry Git repository while supporting legitimate linked worktrees
• bind the exact candidate worktree, HEAD, tree, digest-protected Compose project, and cleanup readback
• fail closed for unrelated repositories, receipt tampering, provider unavailability, and cleanup mismatch or residue

Validation

• focused local synthetic overlay tests: 21 passed
• related capability tests: 14 passed
• CLI tests: 17 passed
• Ruff: passed
• Ruff format check: passed
• mypy: 15 source files passed
• loopx check: errors 0, warnings 0
• premerge canary from Git diff: 17 selected, 0 failures, 0 manual holds
• independent read-only semantic review: PASS, 0 findings

No checks were skipped. The current main advancement is limited to disjoint install and release documentation paths; Git merge-tree reports no conflict. The PR changes only the eight local-synthetic overlay capability, CLI, documentation, catalog, and test paths.

Scope

No Legacy Dispatcher changes, real-resource access, product repository mutation, iPad execution, or capability expansion beyond local_container and synthetic_database. The future-facing scope pass found the repository identity and Compose token helpers cohesive; no broader refactor is needed.

[xuruijohn]

@huangruiteng Normal merge is currently blocked on the required non-author review. This PR is exact reviewed HEAD c714bb7; its diff is limited to the eight local-synthetic overlay paths, and the validation evidence is in the PR body. Please review when available; no admin bypass will be used.

[huangruiteng]

Findings

P1 — “system-managed receipt” 可以被调用方自行伪造，当前 digest 不构成 authority provenance

位置：loopx/capabilities/local_synthetic_overlay/core.py:578-582

触发条件是调用方能够写 configured runtime root——这正是本地 agent/CLI 通常所在的同一用户权限边界。validate_local_synthetic_overlay_receipt 只读取 JSON，然后比较一个由 receipt 自身计算出的普通 SHA-256；这个值既没有密钥，也没有不可伪造的 LoopX lifecycle receipt/authority event。调用方可以完全跳过 issue 和 provider doctor，自行写入 schema、未来 expiry、issued_by=loopx-native-local-synthetic-overlay、system_managed=true 以及对应 checksum，随后得到 valid=true。

这会把“字段和值相互一致”误报成“LoopX 已签发 authority”。我用真实 public API 构造了一个从未经过 issuance/doctor 的记录，validator 接受并返回 valid。最小修复应先明确 threat boundary：如果它真是 authority receipt，issuance/provenance 必须由调用方不能自行制造的既有 LoopX authority/lifecycle owner 持有，并在验证时核对该 authoritative event/receipt；如果本地同用户写权限本来就是完全受信任边界，则这个对象只能命名为 advisory snapshot/integrity checksum，不能作为 governed action 的授权证据。请增加“self-authored store record 必须拒绝”的回归测试。

P1 — Goal/Todo 绑定只证明“找得到”，没有证明任务可执行或拥有这组 capability

位置：loopx/capabilities/local_synthetic_overlay/core.py:311-335

_active_goal_todo 没有检查 registry Goal 的 lifecycle status，也没有检查 Todo role、runnable task class、claimed_by/agent identity、task lease、owner gate 或 required_capabilities。它甚至明确接受 status=blocked。issue_local_synthetic_overlay_receipt 随后丢弃返回的 Todo metadata，只保留 goal repository。结果是：已结束 Goal 中一个 blocked、只声明 filesystem_read 的无关 Todo，也能被包装成同时具有 local_container 与 synthetic_database 的 task-bound overlay。

这不是“capability escalation 被 hard-coded tuple 阻止”：问题是这对 capability 从未由该 Todo/actor 获准。最小修复是复用现有 Todo/capability/agent-scope/lease authority，而不是只做字符串绑定：要求 live Goal、可执行 agent Todo、当前 actor/claim 或有效 lease，以及 Todo 明确声明/绑定的 exact capability set；blocked/user/terminal/other-agent task 必须 fail closed。请覆盖 inactive Goal、blocked Todo、缺少 capability、claim mismatch 和 stale lease 的负例。

P1 — “exact candidate” 未绑定会实际影响 validation 的输入，也没有 active governed-action consumer

位置：loopx/capabilities/local_synthetic_overlay/core.py:288-300、loopx/capabilities/local_synthetic_overlay/README.md:63-70

_candidate_snapshot 用 git status --untracked-files=no，因此只验证 HEAD/tree 与 tracked modifications。一个会改变容器/测试行为的 untracked compose.yaml、Python hook、seed/config 或 mounted input 可以存在，validator 仍报告相同 exact candidate 为 valid；receipt 也没有绑定 validation command、Compose definition、seed/data digest 或 mount/network envelope。我的负例在 worktree 中加入 untracked compose.yaml 后仍得到 valid=true。

同时，全仓搜索只找到 CLI 注册/handler，没有任何真正执行 governed action 的生产 consumer。README 的“Before every governed action, call validate”目前只是调用方约定，不是 machine-enforced obligation；cleanup-check 也只读取 caller-supplied Compose project label。以当前 1,072 行 production mechanism 来看，这是一套可自签、未被 executor 消费、且不能证明实际执行输入的 receipt framework，change_proportionality 与 scope_fit 尚未成立。

最小修复是先交付一个真实、受控的 consumer：在执行边界强制验证 receipt，并从 tree-only materialization 或显式 digest 列表绑定 Compose file、命令、seed、mount/network inputs；或者将本 PR 收窄为 doctor/read-only advisory contract，删除 authority/overlay 完成声明，把真实执行与 authority 绑定留到有 call site 的阶段。请增加 untracked/ignored execution input 与“consumer 未验证不得执行”的负例。

P1 — 新 builtin catalog row 破坏现有 capability registry contract

位置：loopx/capabilities/catalog.py:58

新增 LOCAL_SYNTHETIC_OVERLAY_CATALOG_ENTRY 后，没有同步 repository 的 builtin-id 顺序/组合契约。运行相关 capability suite 得到 24 passed / 2 failed：test_builtin_catalog_preserves_order_and_marks_provider 与 test_declared_manifest_composes_public_capability_without_claiming_readiness 都因为多出的 local-synthetic-overlay 失败。PR 自带 21 个 focused tests 没覆盖这个共享 catalog 回归，远端目前也只有 Sonar check。

最小修复是更新 canonical builtin expectation，并把这组 shared catalog tests 纳入提交前/CI validation；修复后应在 exact head 上同时跑 focused overlay、capability documentation/registry contract 和 CLI regression tests。

评审 exact head：c714bb740fbe309f6cc85d89fe98db7e189ad172。

动机

这个 PR 想解决一个真实边界：某个 LoopX task 需要本机 disposable container 与 synthetic database 来验证精确 candidate，但不应因此获得任何 product repository write、真实客户/儿童/音频数据、真实 provider 或 production authority。此前没有一个内建的 LoopX-native 命令把 provider readiness、Goal/Todo、Git candidate、TTL 和 cleanup readback 组合成公开合同；作者希望避免复用 legacy Dispatcher 的 grant/queue/lease schema，并提供独立的 doctor、issue、validate 与 cleanup-check 路径。

目标方向合理：把“本机运行条件存在”与“产品写权限存在”分开，且默认 preview、显式 --execute、digest-pinned image、短 TTL 和 cleanup readback 都是有价值的限制。但 nearest smaller fix 不能只是新增一份自描述 JSON：如果它被称作 authority path，必须由现有 authority owner 强制签发和消费；如果只需要 readiness/advisory evidence，则可以用更小的 doctor + typed snapshot 完成。

改动思路

入口在 root CLI：register_local_synthetic_overlay_commands 注册四个子命令，handler 将 global registry/runtime-root 与 caller-supplied Goal、Todo、repo/head/tree、capability pair、image 和 Compose project 交给 core。doctor_local_synthetic_providers 只执行 Docker version/image inspect，不 pull、不创建资源；issue_local_synthetic_overlay_receipt 校验 restrictive envelope、Git common-dir/head/tree、Todo 状态和 doctor 结果，然后把 receipt 写入 LoopX runtime root；validate_local_synthetic_overlay_receipt 重新读取 record、digest、live state/Git/expiry/bindings；verify_compose_cleanup 通过 Compose project label 枚举 container/volume/network residue。

正向路径是：operator 对本地 digest-pinned database image 运行 doctor；在 provider ready 且 candidate tracked-clean 时显式 issue --execute；后续 caller 用相同参数 validate，最后运行 cleanup 并用 cleanup-check 观察没有 task-labelled residue。这个路径在 focused tests 中成立。

负向路径则暴露 authority ownership 缺口：调用方不运行 doctor/issue，而是直接在 receipt store 写入自造 JSON + 自算 checksum；所指 Goal 已结束，Todo 为 blocked 且未声明 container/database capability，worktree 还含 untracked Compose 输入。当前 validator 仍按顺序通过 digest、Todo lookup、HEAD/tree、expiry 和 caller-supplied expected values，最终返回 valid=true。因此失败/重试 owner 实际仍是 caller，而不是 LoopX authority boundary。

具体改动

本 PR 共 8 files、+1658/-0：production +1072，docs +73，tests +513。production 中 core.py（723 行）持有 provider doctor、Git/Goal/Todo binding、receipt persistence/validation 与 cleanup readback；cli.py（229 行）定义参数和 dispatch；catalog_entry.py、__init__.py、root loopx/cli.py 与 catalog 注册公开能力。README 描述 closed envelope 和 operator flow，单一 513 行测试文件覆盖 21 个 focused cases。

关键代码讲解

1. doctor_local_synthetic_providers：以 digest-pinned image 为输入，先检查 Docker daemon，再做 local image inspect；输出 typed provider states、network_pull_attempted=false、resource_created=false 和 evidence digest。它的 read-only/no-pull 边界清晰，是当前最可独立保留的部分。
2. _candidate_snapshot：用 Git common directory 支持合法 linked worktree，并比对 exact HEAD/tree；关键分支只拒绝 tracked dirty state，显式忽略 untracked inputs，因此不能支持“实际 validation environment 与 commit tree 完全一致”的更强结论。
3. _active_goal_todo：通过 registry 解析 state file，再找 Todo block；目前把 open 和 blocked 都当可签发状态，而且不消费 Goal status、Todo role/task class/claim/required capabilities，这正是 authority escalation 的入口。
4. issue_local_synthetic_overlay_receipt / validate_local_synthetic_overlay_receipt：issue 构造随机 receipt id、plain digest 并原子写 JSON；validate 重新计算同一 digest并对 caller-supplied bindings做 equality check。这个机制适合 accidental corruption detection，但不能证明 issued_by/system_managed provenance。
5. verify_compose_cleanup：对 receipt-bound project name 读取三类 Docker labels 并统计 residue，失败与 unavailable daemon 会 fail closed；不过它既不拥有 cleanup effect，也不证明这个 project 在 issuance 前为空或确属本 task。

对主干的风险

默认路径隔离方面，现有命令不会主动创建资源：新 action 只能由显式 local-synthetic-overlay 子命令触发，issue 默认 preview，真正 receipt 写入需要 --execute；105 个 CLI entrypoint/argument diagnostics 通过，说明其他 CLI 路径没有观察到回归。公共 catalog 会默认多出一项，这是有意的可见行为变化，并已在 README/catalog 中披露。domain language 基本中性，restricted boolean/constant 与 exact capability tuple 也避免了字符串 substring 分类。

但 authority naming 与实际 lifecycle 不对齐：公开文档称其为 built-in authority、system-managed、task-bound、governed-action obligation，而 implementation 没有不可自签的 issuer、没有 task capability/actor/lease admission、没有执行 consumer。guidance_vs_obligation 实际是 advisory；authority_semantics 为 misleading；scope_fit 只有 CLI 与 tests，没有真实 governed consumer；对“获得安全本地 synthetic execution”这一原始问题而言，1,072 行 production framework 的收益尚未被证明，change_proportionality 为 not-yet-proven。这些都是 capability review contract 中的 blocking verdict，不能由 Sonar 绿或 focused tests 覆盖。

验证矩阵：focused overlay 21 passed；shared capability documentation/registry 24 passed / 2 failed；CLI regression 105 passed；repository-native mypy 15 source files passed；Ruff lint 通过；exact PR diff check 通过；SonarCloud 绿。exact-diff premerge 的 4 个 direct checks 与 17 个 selected checks本身全通过、public boundary clean、无 manual hold，但 strict gate 因 exact-scope change-quality receipt 缺失而先返回 non-passing；随后记录并回读的 exact-scope quality receipt仍为 fail/invalid，因为上述 blocker 与 required catalog validation failure未解决。ruff format --check 对 exact head 的 root CLI 返回 nonzero，但同一文件在 base 也同样返回 nonzero，因此这是 baseline formatting debt，不算本 PR 新回归。

我的整体评价

我认可问题方向，也认可 doctor 的无副作用检查、linked-worktree identity、short TTL、hard-coded ZERO/product restrictions 和 residue readback等局部设计；代码组织与错误返回总体清楚，复用了 registry/runtime/todo/catalog 的既有 helper。问题在于最核心的产品承诺尚未成立：它把可自造、未绑定 runnable task/actor/实际 execution inputs、且无 machine consumer 的 snapshot命名为 authority receipt，同时遗漏一个现成的 shared catalog regression。

结论为 REQUEST_CHANGES。建议先决定产品形态：要么收窄为小而诚实的 read-only doctor/advisory snapshot；要么将 issuance、Todo capability admission、actor/lease identity、exact execution-input digest 与真实 governed consumer 一起接到既有 LoopX authority boundary。完成后补齐 4 组负例和 shared catalog tests，再基于新 exact head 重跑完整评审。没有 merge。

English verdict: REQUEST_CHANGES on exact head c714bb740fbe309f6cc85d89fe98db7e189ad172. The local-only/zero-product-write goal is valuable, and 21 focused tests, 105 CLI regression tests, repository mypy, Ruff lint, Sonar, diff hygiene, and 17 selected premerge checks passed. However, the current authority receipt is caller-forgeable, Goal/Todo lookup does not prove runnable task capability or actor authority, exact-candidate validation ignores execution-affecting untracked/unbound inputs and has no governed-action consumer, and the shared capability registry suite now fails 2 tests. Narrow this to an advisory doctor/snapshot or connect issuance and consumption to the existing authoritative Todo/capability/lease boundary, bind actual execution inputs, and fix the catalog contract before re-review. No merge was performed.

[huangruiteng]

Maintainer scope proposal — a smaller first contribution

This supplements the existing review of c714bb740fbe309f6cc85d89fe98db7e189ad172; it does not replace that review or approve the current implementation.

动机

本地集成测试前确认 Docker daemon 可达、指定 digest 镜像已存在，以及测试后观察 Compose 资源残留，是值得保留的使用场景。建议把首次交付明确为“本地测试环境检查”，让 operator/agent 获得可操作的检查结果。感谢这次实现中对 no-pull、无资源创建和失败路径的关注。

改动思路

建议选择前次评审中的收窄路线，不要求本 PR 同时实现完整任务授权和执行系统。保留只读 provider inspection 与按明确 Compose selector 查询残留的能力；删除 issue/validate receipt store、TTL、Goal/Todo authority binding，以及尚未兑现的 exact-execution/zero-write enforcement 声明。检查结果只表示本次观测，不证明任务授权、数据为 synthetic、数据库可接受连接，或完整执行过程已被隔离。

具体改动

• 优先评估使用现有 extension lifecycle/doctor 和 extension-owned command。Docker-specific 实现放在可选 provider package；不要仅为安装一个 provider 新增 builtin capability。现有 benchmark container selector 可作为相关实现对照，但其运行中容器唯一绑定语义不同，不必强行共用。
• 从 core 保留可独立使用的只读检查，移除无 consumer 的 receipt framework；同步收窄 CLI、exports、README、catalog 与测试，避免只改名称却保留整套无调用方的状态机制。
• README 给出一条实际可运行的检查流程，说明每种失败的下一步，以及残留统计只覆盖指定 Docker endpoint/project label。明确检查不会 pull/run/down，也不授予执行或产品写权限。
• 验收包括 daemon/image 不可用、超时、残留存在与为空、非零退出码，以及实际命令无 pull/create/delete 的边界；在一次隔离的真实 Docker 环境验证 CLI 正负路径。保留共享 catalog/CLI 回归和风险匹配的 premerge 检查。

对主干的风险

本轮在未修改的 exact head 重跑 focused overlay 与 shared extension registry tests，结果为 39 passed / 2 failed；失败仍是 builtin catalog composition expectations。当前与 main 的合并冲突位于 loopx/capabilities/catalog.py 和 loopx/cli.py。本轮未重跑完整 canary 或真实 Docker 验证，不能据此批准合并。当前权限及 exact-candidate 问题仍以前次评审为准。

我的整体评价

建议保留这个 PR 和作者贡献，以一个完整、诚实的只读检查功能争取合并。维护者适合协助主干冲突、代码归属、共享测试和措辞收敛；作者的原始提交/署名应保留，维护者修改以独立 signed-off commits 追加，避免另开替代 PR 抹掉贡献归属。未来确有执行 consumer 时，再独立设计 execution/authority integration。本次 future-facing pass 建议删除重复 authority owner、复用现有 extension lifecycle，不引入新的执行框架。以上是建议的收敛边界，尚未修改 fork 分支或执行合并。

English verdict: Current REQUEST_CHANGES remains on c714bb740fbe309f6cc85d89fe98db7e189ad172. Recommend a smaller, useful first contribution: read-only Docker/image inspection and scoped Compose residue observation, preferably through existing optional-extension lifecycle, without a new authority receipt framework. Fresh focused/shared tests: 39 passed, 2 catalog failures. Main integration also conflicts in catalog and root CLI. Preserve contributor attribution and append maintainer fixes; validate the narrowed CLI against isolated real Docker before approval.

[huangruiteng]

REQUEST_CHANGES — 请将本 PR 收敛为可选的 Docker 测试环境只读检查工具。

评审 head：c714bb740fbe309f6cc85d89fe98db7e189ad172。

这条评审将前面的两条可能路线收敛为一条可执行的修改方案。我们认可 Docker/镜像检查和 Compose 残留观察的价值；本 PR 不需要补齐完整任务授权系统。按下面的范围修改后即可进入重新评审，最终批准仍以新 head 的实现和验证为准。

动机

首版只回答两个 operator 问题：指定 Docker 环境和镜像是否具备测试前提？指定 Compose project 当前还有多少资源？

当前阻塞在于 issue_local_synthetic_overlay_receipt / validate_local_synthetic_overlay_receipt 把本地可自写的 JSON checksum 当作 authority provenance；_active_goal_todo 未证明 task/actor 权限；_candidate_snapshot 不绑定完整执行输入，且没有 executor 强制消费凭证。这些问题应通过删除本次不需要的授权机制解决，不要求在本 PR 添加签名服务、lease 系统或测试执行器。

改动思路

本次选定 standalone optional extension 路线。

• 建议 package/provider id：loopx-docker-inspect，位置 packages/loopx-docker-inspect/，capability_id: none。名称可以微调，交付边界按这里执行。
• 使用既有 extension install/enable/disable/doctor/run 生命周期；manifest 只声明 standalone runtime，不新增 builtin capability，也不为了安装而添加 [[provides]] / [[implements]]。
• 使用 loopx extension run 作为实际用户入口。可参考 extension scaffold 和 standalone 说明，不要新增通用 extension framework 或 root CLI 分支。
• 现有 benchmark_toolkit/container_binding.py 负责“按镜像/labels 唯一定位运行容器”，与本次 readiness/residue observation 不同；可以参考参数校验与失败处理，不要求迁移或抽象它。

具体改动

1. 按文件收敛当前 diff。

当前改动	本次要求
core.py 的 doctor_local_synthetic_providers	移入 provider，保留 Docker daemon 与本地 digest-pinned image 的只读检查；名称和输出改为实际观测含义。
core.py 的 verify_compose_cleanup	移入 provider，去掉 receipt/validation 前置依赖，直接接收明确 project selector；返回三类 residue counts，不负责执行 cleanup。
core.py 的其余 receipt/Goal/Todo/Git/TTL 机制	删除 issue/validate、receipt store/digest/issuer、task capability/restriction flags，以及仅被这些路径使用的 helper/import。不要换成另一套 snapshot store。
capability cli.py、__init__.py	将必要入口/exports 移到 package；删除 issue/validate 参数和重复绑定参数。
catalog_entry.py、root catalog.py、root loopx/cli.py	移除本 PR 新增的 builtin 注册、导入、parser 和 dispatch；合并最新 main 时保留 main 现有内容，不回退整份文件。
capability README.md	替换为 package README：安装、显式运行、结果解释、停用/卸载和边界。同步 PR 标题与 body。
test_local_synthetic_overlay.py	改为检查工具的 focused tests；删除只服务已移除 receipt/authority/Git binding 的测试，不保留未交付功能的兼容 wrapper。

2. 只交付两种有明确输入的检查 operation。

• inspect：输入一个 digest-pinned image reference；观察 daemon 是否可达及该镜像是否已存在。镜像存在只能报告 image_present，不能报告“数据库已 ready”“数据是 synthetic”或“允许任务执行”。
• residue-check：输入一个合法 Compose project selector；分别查询 containers（含停止的）、volumes、networks 的 counts。只有三次查询均成功且全部为零才是 clean；只要一次查询失败/超时就是检查失败，不能拿零补齐后报告 clean。
• provider 的无参数 --doctor 只检查 provider/Docker 基础可用性；每次 operation 仍重新检查运行条件。不要把某个测试镜像写死在 manifest 的 doctor 配置里，也不要把历史 doctor 成功当作当前检查成功。
• 请求使用一个小的版本化 contract，operation 用显式枚举/分支；拒绝未知 operation、空 project 和未固定 digest 的 image。成功检查用零退出码；不可用、非法输入、残留存在和查询失败用非零退出码，并验证经过 extension run 后仍能区分这些结果。
• subprocess 使用固定 argv，无任意 command/shell 输入。检查路径不得 pull/create/run/exec/down/delete，不自动清理、不连接数据库、不读取测试数据、不写产品仓库。
• Docker 会受 context/环境变量影响：明确检查所指向的 endpoint/context 和结果范围。若文档继续承诺“仅本地”，应在发出 daemon 查询前拒绝无法确认为本机的 endpoint。不要从命令名 docker 推断目标必然是本地，也不要向输出暴露 Docker credentials。

3. 提供完整但很小的使用流程。

README 和两个 request examples 分别覆盖 inspect、residue-check。以下是修改后应能跑通的入口形状（新 package/examples 由本 PR 提供）：

python3 -m pip install packages/loopx-docker-inspect
loopx extension install \
  --manifest packages/loopx-docker-inspect/extension.toml \
  --execute --format json
loopx extension run loopx-docker-inspect \
  --input-json packages/loopx-docker-inspect/examples/inspect.json \
  --execute --format json
loopx extension run loopx-docker-inspect \
  --input-json packages/loopx-docker-inspect/examples/residue-check.json \
  --execute --format json
loopx extension disable loopx-docker-inspect --execute --format json

说明 image digest/project 如何由使用者填入；--execute 表示实际运行只读检查，不授予 container execution 权限。结果是所选 endpoint/project 在检查时的观测，不是 task ownership、全局清理完成或未来持续无残留的证明。安装 provider 是显式信任本地程序，extension lifecycle 也不是 Docker 权限沙箱。

对主干的风险

本轮已在上述未修改 head 运行 focused overlay 与 shared extension registry tests：39 passed / 2 failed，失败仍是新增 builtin 导致的 catalog expectations；与当前 main 的冲突在 root catalog 和 CLI。完整 canary 与真实 Docker 未在本轮重跑，因此这里没有新的通过结论。

修改后的验收清单：

• 只有检查功能；上述 authority/receipt/store/Goal/Todo/Git 依赖及 builtin 注册已从最终 diff 移除。不需要再补旧授权机制的防伪、lease、actor 或 exact execution-input 测试。
• focused tests 覆盖 daemon/image 不可用、timeout/nonzero、合法/非法输入、每类 residue、部分查询失败；验证只发允许的只读 argv，以及任何失败都不能形成成功结果。
• 通过 managed entrypoint 验证 schema/input/output 和失败传播；provider 未安装/禁用时不可执行，未安装该 package 的普通 CLI/catalog 不出现新 requirement 或 Docker probe。
• 运行 shared capability registry/documentation、extension runtime/scaffold、CLI entrypoint/argument diagnostics 回归。恢复默认 catalog 合同，不通过给 BUILTIN_IDS 塞入这个 optional provider 来消除断言。
• 在隔离的真实 Docker 环境运行一次 managed CLI：已存在镜像、明确不存在的镜像、带已知 project label 的一次性资源残留，以及由测试操作者清理后再检查为空。资源创建/清理属于独立 fixture setup/teardown，不属于 provider。简述环境和结果；缺少真实 Docker 时明示缺口，维护者可协助补验，不用 mock 冒充。
• 在与最新 main 集成后的最终 head 运行 lint/type checks、diff/public-boundary 检查及 loopx canary premerge --from-git-diff；记录失败/跳过。保留作者署名，后续修改使用 signed-off commits。

我的整体评价

这个收敛后的功能有独立使用价值：给 agent/operator 一个可重复、机器可读、无资源变更的检查入口。首版到这里即可，不要求顺带建设执行、权限或新通用能力。Future-facing pass 的决定是移除未被消费的 authority owner、复用现有 extension lifecycle，暂不抽公共 Docker framework。维护者可以协助冲突与共享验证；请在当前 PR 更新，保留原贡献归属。

English verdict: REQUEST_CHANGES on c714bb740fbe309f6cc85d89fe98db7e189ad172. Please take the narrow path: a standalone optional Docker inspection extension with inspect and residue-check, using existing extension lifecycle and managed invocation. Remove the receipt/authority framework and builtin registration; no new lease, signing, or executor system is required. Preserve honest endpoint-scoped observations, failure propagation, and no resource mutations. Current focused/shared validation is 39 passed / 2 catalog failures; real Docker and final integrated-head validation remain required before approval. The checklist above defines the requested re-review scope.

[now-ing]

Sampled the enforcement core and it holds together well — some notes in case they help the review queue:

• The restrictive envelope requires exact literals for scope / write scope / lifetime and hard-rejects every real-resource flag and cross-task reuse, and _capabilities rejects subsets and anything beyond the two allowed values, so there's no gradual-escalation path into the overlay.
• The receipt chain is sound: the stored record is digest-pinned, expiry is checked against a timezone-normalized now, and the expected-record comparison collects all mismatches before failing (good diagnosability) including provider_binding.revision and the digest-pinned image reference.
• Doctor's _run wrapper has both OSError and subprocess.TimeoutExpired handled at the call sites, and the digest-pinned-image regex forecloses mutable tags.

One minor observation: _required_token bounds length and rejects whitespace but accepts any other Unicode (full-width characters, control characters outside whitespace). If these tokens ever flow into compose project names or receipt ids verbatim the existing narrower regexes (_COMPOSE_PROJECT, _RECEIPT_ID) cover them, so this is only about the goal/todo/free-form labels — a character-class check there would make the boundary uniform, but nothing currently depends on it.