[cocolord]

Resolving a capability editor queried the Codex profile and steward option owners for every request. An unavailable unrelated provider could therefore block metadata for another editor, including a disabled periodic-report subscription.

Query the existing profile owner only for codex_chat, and the existing steward vocabulary helper only for codex_chat or steward_executor. Complete baseline/candidate comparisons cover selected metadata, scopes, options, helper order/errors, configuration precedence/provenance and detached outputs. This four-file proposal builds on the merged permission-first PR wait hook in #8821; the paired RFC retains both checkpoints and qualifies their current composition.

Validation on 7a340f2b42cf1e3c0e1d8fe46c3ac9556dcf3103, based on main@fef679d1819231fdd15be9bfd7d9858f691758bc:

• Focused editor suite: 55 passed; selected consumer suites: 66 passed. Fresh subprocess counterexamples and selected-owner positive/negative checks cover unavailable providers, nullable options and helper ordering.
• Source compatibility against the current base: 46 complete editor outputs and 105 resolution outputs equal; 44 detached-output cases and five legacy nonstring characterization cases equal. The public input contract remains str.
• Separately built, installed loopx-core wheels from this author tree and its conflict-free merge with current C1 #8266 head 1a3740cf9e6ebad337f17967452693a9050edc81: each 22 full metadata outputs equal, one fresh process exercises 20 unselected IDs (18 registered plus unknown/empty), and 3 File/SQLite execution, replay and readback checks pass. Each arm preserves all 31 Core subprocess commands and complete outputs, including the two expected CLI rejection results. Both environments contain only the noneditable Core distribution. All 1,902 / 1,903 product files match committed composition sources, preparation staging, wheel, RECORD and installed namespace. This C1 composition includes current main, Defer PR wait provider loading until permission is checked #8821 and this editor change.
• Independent installed-Core PR wait observation checks: File/SQLite both pass on each composition (four cases), retaining the original permission checks, provider merge event and canonical Todo readback. Test tooling stays outside the product namespace.
• Standard final-head premerge: 11 selected checks, zero failures; whitespace, semantic-vocabulary checks, changed-file public-boundary checks and staged/final-head bilingual RFC gates pass.

The Core execution fixture uses synthetic generic-cli work and explicitly stops its runtime during cleanup. This evidence qualifies selected-editor metadata loading; full Settings journeys, actual-model adoption, total cost, natural process drain, full C1 acceptance, full D2/D5, R1/M3 and default cutover remain unqualified. Formal exact-head review and merge readiness remain pending.

[mergify]

This pull request has merge conflicts with main and cannot be merged
until they are resolved. Please rebase or merge the base branch, @cocolord.

Choose the remote for the base repository, not an out-of-date fork.
For a fork clone, first inspect git remote -v; upstream must point
to https://github.com/loopx-project/loopx.git. If it is absent, add it
with git remote add upstream https://github.com/loopx-project/loopx.git.
Then run:

git fetch upstream
git rebase upstream/main
# Resolve each conflict, git add the resolved files, then git rebase --continue.
git push --force-with-lease origin HEAD

For a same-repository clone whose origin points to
https://github.com/loopx-project/loopx.git, use origin instead of
upstream for fetch/rebase. If you prefer merging the base, use
git merge <base-remote>/main and push normally.

Keep the DCO Signed-off-by trailer on every commit when you rebase.
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[cocolord]

Reviewer: model_agent; GPT-6; OpenAI; self_reported

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

评审目标为 #8822 的 7a340f2b42cf1e3c0e1d8fe46c3ac9556dcf3103，基线为 fef679d1819231fdd15be9bfd7d9858f691758bc。完整 exact-head 评审结论为 APPROVE；GitHub 对 author-owned PR 使用 COMMENTED 记录该结论。

动机 / Motivation

受影响的是读取 capability 配置的用户，以及为后续受控工作解析配置的 Agent。用户只是检查尚未启用的定期报告配置，却可能先遇到无关的 Codex 配置发现或 steward provider 缺失；这会让一个本来不需要这些执行器的只读操作失败，并迫使用户修复无关的环境。这里的 editor 指供设置界面和配置查询共用的字段描述，不是执行能力本身。

具体场景是解析 periodic_report 的未启用订阅：原路径为构造全部 editor definitions 先查询 steward options 和 Codex profiles；新路径仍返回同一报告 editor 和有效配置，但只在请求 codex_chat 或 steward_executor 时查询它们各自需要的选项。已验证的可观察改进是，无关 provider 不可用时，报告及其他未选中 provider 的 metadata 读取仍能完成，用户不用为这次操作配置无关执行器。

这次交付边界是现有 metadata owner 内的 demand loading 修复。它保留所选 editor 的字段、说明、scopes、nullable/options、错误传播和配置优先级；不缩减已安装能力、不启用能力、不替用户执行报告。完整 Settings 旅程、真实模型和上下文采用、完整成本、完整 D2/D5、R1/M3、完整 C1 及默认切换仍未资格化。这个剩余缺口由原有发行和产品验收边界承接，不能用本次只读修复关闭父目标。

改动思路 / Approach

最有力的反对理由是：一个很小的 import 条件可能让 provider 缺失看起来像“没有选项”，掩盖所选能力真实不可用，或者在构造 catalog 时丢失既有字段。若只是吞掉 ImportError、返回空的所选字段，或另建一份 provider vocabulary，局部测试可能通过，用户后续提交配置却会失败。应直接复用现有 owner，并把条件放在产生无关依赖的调用之前。

两个请求 id 条件复用原 options/profile owner，保留所选失败和完整配置投影；不新增状态、cache、注册表或第二个决策 owner，机制成本与已证明的依赖缺陷相称。

本 PR 交付现有 metadata 加载修复、所选完整契约对照和新 installed Core 组合回归；完整 Settings、模型/context、成本、D2/D5、R1/M3、完整 C1 与默认切换继续由原验收边界承接。

当前实现采用这一较小边界：保留 definitions 和返回结构，只约束两个 options 查询。steward endpoint 和 reasoning effort 仍由原 namespace owner 提供；Codex profile 仍由原 native profile owner 发现。没有新增 cache、注册表、状态格式、CLI 或第二个配置决策 owner。所选 provider 的失败继续向调用方传播，未选中的 provider 不应参与当前 metadata 读取。这一机制属于现有配置投影中的本地加载条件，执行和持久化仍由原 owner 负责；默认安装、activation 和任务 authority 不由它决定。

请求	基线调用	候选调用及结果
periodic_report、其他无关 editor、unknown/empty	先查 steward 与 Codex options，再取所选定义；无关 provider 可能阻断读取	跳过两类无关查询，仍取原定义或原只读 fallback
steward_executor	steward endpoints → efforts → Codex profiles	endpoints → efforts；保留原 steward 选项与所选错误
codex_chat	endpoints → efforts → profiles	保留同一顺序、原 profile owner、nullable 选项与所选错误

这张表来自 7a340f2b42cf1e3c0e1d8fe46c3ac9556dcf3103 的源码分支，仅解释行为，不替代执行证据。原 owner 足以解决已证明的依赖边界问题；无需把 20 个 definitions 改成新 builder 系统，也无需借此迁移稳定 Python provider。

具体改动 / Changes

完整 fef679… → 7a340… diff 为四个文件、175 additions / 3 deletions：生产文件 10 additions / 3 deletions；测试新增 121 行；英文 RFC 新增 24 行、中文新增 20 行。生产改动集中在现有 options 查询，没有移动模块或增添共享 vocabulary。

关键代码讲解

1. capability_configuration_editor 接收 capability id 与 Explore profiles。第 86–94 行仅在 id 为 codex_chat 或 steward_executor 时求 steward options，仅在 codex_chat 时 import/call codex_profile_options。后面的全部 definitions、字段说明和 flags 仍建立，最终仍深拷贝所选 fields 并复制 scopes；unknown/empty 保留完整只读对象。resolver 和 machine/Goal catalog 都调用这个公共入口，因此条件必须在这里生效，不能只保护一个 UI 页面。
2. _steward_executor_editor_options 仍调用 namespace 的 steward_executor_endpoints 和 steward_reasoning_efforts，返回排序后的 endpoints 和原 effort 顺序。B 调整它的调用时机，未复制 closed set，也未 catch 它的异常。所选调用顺序是 Codex 的 endpoints → efforts → profiles，以及 steward 的 endpoints → efforts。
3. resolve_capability_configuration 未改：先规范化 id，再通过 editor 检查 supported scopes，并深拷贝输入。优先级仍是完整的 Goal override > machine default > capability default > not configured，Goal override 不逐字段合并。返回 source、presence、inherited 与 effective revision 仍由同一 resolution identity 导出。这解释了为什么 demand loading 修复也必须保护 nullable、scope 拒绝顺序和 detached output，而不能只断言某个字段出现。

现有 companion consumers 已定位：machine 和 Goal configuration catalog、配置 inspection，以及 Dashboard 的 capabilityConfigurationEditorSchema、machine/Goal settings 和 capability workbench。它们继续读取同一 editor schema；本次没有布局或交互控件 diff。源码与 API consumer 测试可保护这个契约，尚不能证明整页设置旅程。

正向路径是未启用报告的 resolver → shared editor → 原报告 fields/scopes → 原 atomic precedence → effective configuration。新 installed Core 反例在不可用 provider finder 下走真实 resolve_active_goal_periodic_report_subscription，未启用报告返回 None。反向路径是明确请求 Codex/steward 且所选 provider 无法 import：原 ImportError 必须传播；没有降级为可编辑空选项，也没有未经控制的执行 fallback。unknown editor 与 empty editor 保留只读诊断；empty resolver 仍抛 capability_id is required。supported scopes 不允许的值和非对象输入仍由原 resolver 拒绝。

不可变规范与当前验收边界

spec_ref 为 monorepo-distribution-split-v0.md，spec_revision 为 fef679d1819231fdd15be9bfd7d9858f691758bc。下表依据改动前的规范；HEAD 新增的双语 checkpoint 是待评审的交付说明，不能成为认证自身实现的规范。

原 criterion_id	与本次边界的关系
I1	单仓四路径 proposal；当前 packet 和标准 premerge 可支持本 PR 的交付组织，CI 状态另列。
I2	kernel truth owner 和 transaction 不变；这里只减少 metadata 对无关 provider 的依赖，未新增 truth 实现。
I3	无 public import move、shim 或 deprecation 变更；迁移兼容性不在本次范围。
I4	覆盖未选中 provider 的 metadata 退化边界；不证明所有缺失 optional distributions 的完整 off-state。
I5	Node 安装和 effectful missing-Node 诊断未改变，也未完成整条资格化。
I6	editor schema、scopes、字段/说明、public/private 规则和 licences 保留；新双语 checkpoint 明确范围。
I7	覆盖本 editor 的未选中 provider 不加载与所选错误传播；不扩展为全宿主 startup、timer/network/instruction 隔离证明。
I8	此 diff 未修改 context delivery 或 replay contract；完整连续性保持未验证。
I9	新 Main A+B 和实际 merged-C1 来源、wheel/RECORD、运行范围及旧证据范围均明确；不从文件数或测试数推导成果/性能收益。
V1	覆盖本次 metadata demand loading，含一 fresh process 的未选中 provider 反例；完整 import/help/listing/unknown/selected-route tracing 仍是更大的验收边界。
V2	editor/resolution 完整对照及 File/SQLite provider replay 提供局部语义证据；不完成 requirements/stale claims/stop/budget/settlement 全 corpus。
V3	editor schema、完整诊断和现有调用方契约有对照；不完成全部 supported CLI 与 missing-provider/Node corpus。
V4	disposable Core execution/replay/readback 可作为局部支撑；完整 managed task、注入中断、restart、结果和 recovery cost 未验证。
V5	没有 model/context、compaction 或 lost-ACK 资格化；继续保留缺口。
V10	未运行 repeated paired cold/warm 计时或完整成本；20 IDs 的加载反例不能被当成性能样本。
R1	source/installed Core 子集证据没有关闭“一 real managed Turn、restart、result readback”的整体组合验收。
M3	本地 clean Core wheels 不等于 split-package pre-release 发布，也不等于完整 R1/R2 cold-install journeys；里程碑继续未完成。

语义与验证对齐

现存 source evidence 记录 55 个 focused tests、66 个 periodic-report/steward/API consumers 通过。Root 的当前基线独立 replay 记录 46 个完整 editor output、105 个 resolution output 和 46 个深拷贝反例通过；两个 raw output 文件 SHA256 同为 73dacd3683362a3917d47b2060e0630192d0e8e9f84854f6fb36bdb8ae45a4eb。它比较完整对象、nullable/default、错误类型/全文与 scope 拒绝，并在返回树每层加入修改来检查下一次结果和 caller profiles 未污染；不只比较 fields 中的一个 key。author 自己的 detached corpus 为 44 加五个 legacy 非字符串观察，不能与 Root 的 46 合并计数；公共 input contract 仍是 str。

新 Core 两 arm 是 Main A+B 的 7a340f2b42cf1e3c0e1d8fe46c3ac9556dcf3103，以及它与当前 C1 1a3740cf9e6ebad337f17967452693a9050edc81 的真实合并 18a8ea11bf74dade8cc813314e9d6dfb1351f065（tree 7ba18db2c17b16830f2e7287710499a3a137ac6d）。后者不是 editor overlay。两者都携带已合入 A 的 hook bytes。wheel 构建发生在只差后续 RFC evidence 文本的 provisional commits，final source→stage→wheel→RECORD hash/size→install 映射把全部 1,902 / 1,903 product files 绑定到最终树；原 Core fixture bytes 也保持一致。这是明确的 bytes transfer 边界，不能声称 wheel 在 final commit 上重建。

新 Core arm	完整 metadata 与 provenance	执行、回放及读取证据
Main A+B	22 完整输出与 BASE 相等；editor SHA 5e72e31d…；wheel 77b2e93c… / RECORD e317142b…	原 correctness 3 passed / 29 deselected；31 完整 CLI records，其中两个 rc2 是预期负例；独立 File 与 SQLite retention 各一例
Actual merged C1	22 完整输出与 BASE 相等；相同 editor；wheel 3f77cdb0… / RECORD 7f49ec0f…	原 correctness 3 passed / 29 deselected；31 完整 CLI records，同样两个预期 rc2；独立 File 与 SQLite retention 各一例

每 arm 的 unselected counterexample 是一个 fresh process 遍历 20 IDs：18 registered 非 Codex/steward IDs，加 unknown/empty。它不是 20 个 cold processes。另有真实隔离 profile owner 的正反例和所选 normalization 校验。四个独立 provider replay 保留原 retention assertions、完整 CLI/hook/events/fixture 与 serving-runtime origin，并正常关闭 private runtime；其中 claimant metadata 保持，不代表独立执行 lease/admission 已资格化。运行 provider replay 所需 pytest 工具单独置于测试命名空间，没有重建或写入两套 Core 环境。

新 author v2 seal 记录 52 stable artifacts。首版新 seal 对自己的 stdout 文件在填充前取 hash，已作为失败保留；v2 排除 execution-time stdout 文件并回读稳定材料。原旧 seal 和其 C1-only editor-overlay 证据也保留。旧 04eabc… / BASE 2b156… 证据不携带当前 A，因此不用于认证这次新 composition。历史基线的 unselected-import 失败提供缺陷敏感性，但仍保留其旧 revision；Root 已核对当前 immutable BASE 仍具有相同的无条件 options 查询，并独立验证当前完整输出与 fresh source/Core 反例；旧失败不被改写为当前版本执行。

Root 和 author 的 standard premerge 均记录 6 direct / 11 selected checks、zero failures。Root receipt 的 CQQ policy 为 disabled，表示这项机制不执行，不能写成“qualification passed”。premerge 同时扫描一个未提交 uv.lock，这是更宽的工作树验证范围；实际 PR 仍只有上述四个 committed paths。当前 exact-head 远端读取有 69 个 raw check rows：28 success、12 failure、14 cancelled、8 skipped、6 pending、1 in-progress；raw rows 可能含被替代的 context，不能据此宣称 normalized CI 全绿。OPEN/nonDraft、head/base 不变、BLOCKED / MERGEABLE。失败因果仍为 unresolved diagnostic；所改 invariant 的独立必要验证已通过，merge-readiness 仍须在合入前单独即时读取，不能用 APPROVE 自动放行。

对主干的风险 / Risks

最强回归场景是条件过窄或 exception 被隐藏：selected Codex/steward editor 返回失去原 options 的表单，让用户保存错误配置；另一风险是只验证单 editor 而 catalog 仍先访问其他 providers。本 diff 用明确 id 分支及原 helper/owner 避免复制规则，selected failure subprocess、真实 profile owner、调用顺序测试、完整 schema/resolution 对照和 Core caller 反例针对前者。catalog 的既有 selected capability 项目仍会合法触达其 owner；本 PR 没有许诺整份所有能力 catalog 在每个 selected provider 缺失时都成功。

第二类风险是把 output parity 误写成 authority、性能或产品旅程完成。当前 provider 四例证明的是具体 installed compositions 的 File/SQLite observation、facts 和 Todo 读取；generic CLI execution/replay 由另行的每 arm 三项 Core correctness 支撑。四个 provider 例无 quota-spend 或 Todo-complete，不能认证独立 execution lease/admission；fixtures 明确停止 runtime，不能证明自然 descendant drain。Root 已独立核对 author 52 stable artifacts 和 provider 1,944 artifacts 的完整 hash，并结合原始执行、source/RECORD 与 fixture/runtime 来源验证；hash 本身不认证业务成果或模型采用。rollback 是 revert B 的 options 查询条件；它会恢复无关 provider 依赖，因此只能作为定位和回退，不能被描述为更好的 off-state。

原 owner 的 selected ImportError 和 resolver 的 ValueError/TypeError 仍是 actionable 的失败边界。B 不更改任何 actor 生命周期、claim/lease、quota、scheduler、persisted state、prompt 或 instruction。provider discovery 不是 activation，也没有授予消息、配置写入、模型执行或 merge authority。需要的修复若只是本地 contract 缺陷，应留在该 owner；完整 Settings、完整成本和 R1/M3 等 gap 应按原验收程序继续，不能添加一个批准流程来替代缺失证据。

Root 对完整 exact-head、immutable frame、current source/seals 和必要 invariant 的实质评审未发现 blocking production finding。这个结论来自真实调用与正反例，而非空 findings 数组、哈希或测试数。远端红/等待 CI 的因果未验证与 merge gate 继续分别保留。

我的整体评价 / Verdict

结论为 APPROVE。用户和 Agent 不再因未选中执行 provider 而丢失本次 metadata，所选 metadata 的完整契约继续由原 owner 提供。原字段、说明、nullable/options、scopes、配置优先级、完整错误及 detached output 已作当前 BASE/head 对照；fresh unavailable-provider 反例和真正 A+B/current-C1 installed Core 证据覆盖暖路径对照可能遗漏的加载缺陷。

两个请求 id 条件复用原 options/profile owner，保留所选失败和完整配置投影；不新增状态、cache、注册表或第二个决策 owner，机制成本与已证明的依赖缺陷相称。

本 PR 交付现有 metadata 加载修复、所选完整契约对照和新 installed Core 组合回归；完整 Settings、模型/context、成本、D2/D5、R1/M3、完整 C1 与默认切换继续由原验收边界承接。

long-horizon 判断为 preserved：现有配置/source/错误与受控 caller 的契约保留，没有新增 continuation authority；持续任务成果与完整成本未测量。user experience 的 improved 仅指已验证的无关 provider 缺失读取路径，完整 Settings 或真实模型采用仍未认证。

本次只改变 editor/resolver 的 provider 查询条件，完整 schema 对照及现有 Dashboard 调用方保持一致，没有渲染布局或交互控件变更，因此此 diff 无需新增页面视觉资格化。

完整 Settings 页面、长且重复的混合状态内容与交互恢复仍未验证；本次源码和 API 对照不认证这些页面验收。

七项 required validation 为 PASS；CI 因果和 broader parent acceptance 为 UNVERIFIED diagnostic。Goal 的 CQQ 为 disabled，没有伪造通过 receipt。原 revision6 十项与最终完整回归仍未完成，不能依据此 PR 合入或局部测试宣布父目标完成。合入另需 unchanged head、双语检查、无 unresolved finding/thread、即时 readiness 和既有 maintainer 授权；若仅有 CI/GitHub policy hold，已授权的 bypass 也不能替代上述必要验证。

English verdict: APPROVE. Reviewed head 7a340f2b42cf1e3c0e1d8fe46c3ac9556dcf3103 confines option discovery to the requested editor, reuses the existing providers, and preserves complete selected editor/resolution and failure contracts. Current source negatives, full BASE/head comparisons and genuine A+B/current-C1 installed-Core readbacks support this bounded repair. No blocking production finding remains. Diagnostic CI causes and broader Settings/model/context/cost/R1/M3/original-ten-item acceptance remain unverified; merge readiness and maintainer authority are separate gates.