Provide capability context at coordinator planning, delegation and result boundaries

[huangruiteng]

Enabling child capacity previously described launch settings without giving the coordinator lifecycle guidance. This change adds bounded capability-owned contributions at planning, delegation preparation and result reconciliation, including when the selected work contains only one Todo.

• before_plan: live decision → interaction contract → signed TurnEnvelope.
• before_delegate: admitted child operations → coordinator host request.
• after_delegate_result: receipt reconciliation → durable host-result journal → caller/replay output.
• Native child tools use the same read-only agent-context --phase interface through the LoopX project skill. No new turn, quota spend or Todo mutation occurs.

The TypeScript provider contract binds scope, phase, revision and content ID, isolates failures, and enforces 2,048-byte contribution / 3,072-byte aggregate limits. The initial provider is owned by the existing multi_subagent capability. Disabling that capability emits no context; a model preference alone does not enable it. Near the existing TurnEnvelope limit, guidance becomes a signed full-decision reference. The global envelope limit is unchanged.

User entry points: the existing Goal capability editor shows supported phases and coordinator responsibilities through shared catalog metadata, in Chinese and English. Existing configuration controls and readback remain authoritative. The packaged frontend is included. Lark has no new configuration or message action in this change.

Boundaries: delivery: projected proves generation only. This does not intercept arbitrary native tools, certify model execution/adoption, automatically launch another model turn after results, or publish runtime context. The UI shows supported phases, not per-run delivery receipts. Native CLI reads cannot invent host receipts. Owner review completed; the requested v4 compatibility correction is included for the final merge.

Validation:

• 194 focused Python tests passed across lifecycle integration, live decisions, envelope signing/compaction, turn driver/executor, catalog and model configuration. Includes actual prompt serialization, journal persistence and replay without a second host call or spend.
• 8 TypeScript provider tests passed; npm run typecheck:control-plane and focused Ruff checks passed.
• Dashboard build:chat passed. Packaged personal-workspace browser smoke passed, including the three phase descriptions, mobile overflow check and existing configuration preview/apply/readback flow; desktop/mobile screenshots inspected locally.
• git diff --check and candidate-file private path/credential/internal URL scans passed.
• Additional existing source-regex check personal-workspace-contract.test.mjs fails at line 265 (isManagerProjectionQuestion). Both that test and its asserted dashboard-page.tsx source are unchanged from the base; this is disclosed, not counted as passing. The packaged browser acceptance above passed.

Review correction: register v0/v1/v2/v3 → v4 in the existing CLI-output differential with a one-time 2,048-character/byte, 48-line, 1,664-compact-character allowance. The normal budget remains in force after migration; unknown v5, reverse migration, repeated growth and same-version signature changes still fail closed. The shared base/head runner now exercises a genuinely enabled multi_subagent fixture on both revisions, with a focused test proving it reaches the v4 producer.

Rebased validation: 85 Python tests covering differential, actual enabled CLI probe, lifecycle and envelopes; 8 TypeScript provider tests; control-plane typecheck and focused Ruff passed. The full real CLI base/head differential passed 102 rows on both revisions, with exactly one expected migration review signal. Chat was rebuilt against current main, preserving the newly fixed list markers.

Rebased packaged browser acceptance passed all criteria, including reload/reconnect, capability configuration roundtrip and visible phase guidance on desktop/mobile. Screenshots inspected.

[huangruiteng]

Request changes conclusion (author-owned PR; GitHub blocks formal self-review)

Reviewed exact head 951a27e64ca83e3cb19fdcff56f7c42745643130.

动机

这个 PR 解决的是一个真实且反复出现的协调缺口：Goal 已经声明了子代理容量和模型偏好，但 coordinator 在规划、委派前和结果回收后没有同一套 capability-owned guidance。把这些信息继续散落在静态 prompt 里，会让 Codex App、native CLI 和 turn replay 逐渐产生不同语义。PR 把范围限定为启用 multi_subagent 的 Goal，并明确 guidance_only / delivery: projected，不把“生成了上下文”夸大成“模型已采纳或执行”，这个动机和权限边界是成立的。

改动思路

整体架构方向正确：TypeScript agent_context dispatcher 负责 phase/scope/schema/budget 和 provider 隔离；现有 multi_subagent capability 提供三个阶段的 contribution；Python 只通过 effect runtime 做薄适配。before_plan 进入 quota interaction contract 和签名 TurnEnvelope，before_delegate 进入已准入的 host request，after_delegate_result 在 receipt reconciliation 后进入 durable journal/replay。native tool 复用只读 loopx agent-context --phase，没有创建第二套 quota、Todo 或 spawn authority。

我也比较了更小方案：仅补静态 prompt 或只做 before_plan 虽然代码更少，但覆盖不了 native delegation 和 replay/result reconciliation，反而会复制规则。因此当前 provider seam 与三段 lifecycle 的范围是合理的。真正需要补的不是另一套框架，而是把新增签名版本接入仓库已经存在的兼容性 owner。

具体改动

关键代码讲解

• projectAgentContext 对 enabled capability、phase、scope 和 contribution schema 做严格校验，拒绝 provider 伪造 control fields；单 contribution 2,048 bytes、聚合 3,072 bytes，provider 失败只留下脱敏 code。
• build_live_quota_should_run_decision 从 canonical orchestration 和 exact Goal/Agent/Todo scope 派生 before_plan context。关闭 capability 时不发 context；模型偏好或 observed capability 本身不会激活它。
• TurnEnvelope 在预算压力下把完整 context 压成签名 content_hash + detail_ref，并在 context 存在时把 action-signature coverage 提升到 turn_envelope_action_dimensions_v4。
• turn driver 和 subagent execution topology 分别投影 before_delegate 与 after_delegate_result；后者随 host result journal 持久化，replay 不会再次调用 host 或 spend。
• CLI、配置 catalog 和 Personal Workspace 同步暴露三个 phase 与边界说明；packaged asset 与 browser smoke 一并更新。

对主干的风险

[P1 / blocking] 新增 v4 producer，但没有更新现有 CLI-output differential consumer。 loopx/control_plane/testing/cli_output_differential.py 仍只导入并允许 v0-v3 migration；现有 test_unknown_action_signature_coverage_migration_fails_closed 甚至明确把 v4 当未知版本拒绝。普通 probe 又保持 capability default-off，因此作者新增的 lifecycle tests 全绿时，这个 feature-on 断点仍不会被看到。

我用同一份单 Todo、multi_subagent enabled 的公开 fixture，分别跑 base afff837a05694bed2f0b113ba319c6773ed486fa 和当前 head 的真实 quota should-run --turn-envelope：base 输出 coverage v0、6,877 chars / 188 lines；head 输出 v4、8,488 chars / 225 lines，并实际包含 agent_context。再交给当前 head 的 compare_cli_output_receipts，结果 ok=false：增长 1,611 chars、1,611 bytes、37 lines、1,293 compact chars，且报 action_signature semantic digest changed。这不是推测，而是现有预合并门禁的真实 fail-closed 结果。

最低修复范围：

1. 在 differential owner 中导入 v4，显式登记合法的 v0/v1/v2/v3 → v4 migration；
2. 为这次 migration 增加一次性、有上界的 growth allowance，merge 后仍回到普通预算；
3. 增加真正启用 multi_subagent 的 public TurnEnvelope probe row，断言合法 v4 只产生 review signal、不失败；
4. 保留未知 v5/future coverage 的 fail-closed mutation test。

另外，当前 exact head 仍 behind main；复审截止时 checks 已红，4 个 shard/stage job 仍在跑，后续 aggregate gate 尚未完成。workflow 未结束，GitHub 还不提供当前失败 job 的日志，所以我没有猜测归因。上一 head 的失败落在未改动路径：本地 base/head packaged browser smoke 都在同一个 “使用 Luna / max” 步骤超时，local-authority 单测则在 base/head 本地各跑一次都通过。作者需要 rebase 并恢复 required checks，但代码结论主要由上面的 v4 可复现断点决定。

我的整体评价

能力归属、typed contract、default-off、guidance-vs-obligation 和 journal replay 的设计总体靠谱；173 个相关 Python tests、8 个 TypeScript provider tests、control-plane typecheck、Ruff 与 diff check 均通过。未来向的小步判断也很清楚：继续复用现有 migration/differential owner，而不是扩展新框架。

但签名版本属于跨 producer/consumer 的公开兼容契约，不能只更新生成侧。当前 head 在真实 feature-on base/head qualification 中会被仓库自己的 fail-closed 防线拒绝，所以本轮结论是 Request Changes。补齐 migration + feature-on fixture、rebase 并恢复 required checks 后，我可以按新 exact head 复审。

English verdict: REQUEST_CHANGES at exact head 951a27e. The lifecycle design is sound, but action-signature coverage v4 is not registered or budgeted in the existing CLI-output differential, and a real enabled base/head probe fails closed; add the bounded migration and feature-on fixture, then restore required checks.

[huangruiteng]

Final review at da1f52a: no blocking findings remain. The requested v4 consumer registration, bounded one-time migration allowance and actual feature-on probe are implemented; unknown v5 and same-version semantic/growth regressions still fail closed. Independent final diff review found no additional blocker.

Product/architecture: the capability remains opt-in guidance for the coordinator at the three existing lifecycle seams. The correction reuses the established differential/migration owner, with no new state authority or widened normal budget. Existing frontend capability controls and shared phase descriptions remain the user entry point; the rebuilt bundle retains current-main formatting fixes. The future-facing pass was limited to the shared probe seam, avoiding a second migration framework.

Risk-based premerge coverage: 229 focused Python tests, 8 TypeScript provider tests, control-plane typecheck, Ruff, public-boundary/diff checks, full real base/head CLI differential (102/102 rows; one expected review signal), packaged desktop/mobile browser acceptance and the CI-equivalent instrumented development browser run all passed. The prior reload/reconnect failure did not reproduce in either current browser run; this is not claimed as proof of a permanent timing fix.

CI currently passed DCO, dependency review, macOS/Windows desktop builds, release build, both Node compatibility checks, installed-stage and Windows PowerShell. The broader checks/shards/stage jobs remain queued or running, with no current-head failure observed; full CI is not represented as green. Merge uses the owner's explicit authorization and the completed risk-based validation above. No remaining manual approval hold.

[huangruiteng]

Post-merge audit：P1 TurnEnvelope 预算回归

Reviewed exact head da1f52a813b045ae4cd8df5528021818fd0b7eb7（merge commit 32bcfa230d1ff8c4836e617b6b6e3001ba1778d4）。结论：设计方向成立、默认关闭路径保持隔离，但当前 exact head 有一个可从公开 CLI 稳定复现的 P1 enabled-path 回归，需要补修。

动机

这个 PR 要解决的问题是真实的：此前 goal_boundary.orchestration 只描述 child capacity，coordinator 在规划、实际委派、结果回收三个时点都没有 capability-owned、按生命周期阶段变化的操作上下文。仅在 skill 里追加静态提示不能绑定当前 Goal/Agent/Todo、已准入 child operation 和实际 receipt reconciliation；因此用 canonical orchestration 派生只读 context，并把它送到 before_plan、before_delegate、after_delegate_result，比 prompt-only 修补更稳妥。

非目标也表达清楚：context 是 guidance_only / projected，不授予 child 独立 authority，也不把 projection 当成 delivery、read、adoption 或 execution receipt；loopx agent-context 只读，不启动 Turn、不消费 quota。

改动思路

权威边界整体合理：TypeScript 的 projectAgentContext / subagentContextProvider 负责 phase、activation、budget、hash 和 contribution contract；Python 只在 live decision、CLI、Turn driver 的真实边界做适配。before_plan 进入签名覆盖升级到 v4 的 TurnEnvelope；before_delegate 只在 child operation 已准入时进入 host request；after_delegate_result 从规范化 receipts 与 reconciliation counts 派生并写入 host-result journal。这样没有复制 scheduler、admission 或 receipt decision authority。

我也检索了既有 generic capability hooks、interaction projection、subagent topology、TurnEnvelope 和 host-result owner。已有 hook 能覆盖部分 before-plan enrichment，但不能覆盖准入后的 delegation 与 receipt-backed result lifecycle；保留一个小的 typed provider owner 是有根据的。最小替代方案不是删掉这个边界，而是修正其 final-envelope budget compaction。

具体改动

• 新增通用 loopx_agent_context_v0 provider contract，固定三个 phase、target=coordinator、authority=guidance_only、delivery=projected，限制单 contribution 2048 bytes、总 packet 3072 bytes，并对 provider failure 做隔离和错误文本脱敏。
• 新增 multi_subagent provider：只有 mode=multi_subagent、spawn_allowed=true、max_children>0 同时成立才启用；availability、CLI 存在或 dashboard 可见都不会激活运行时 context。
• 把 before_plan 接到 live quota/interaction contract，把 before_delegate 接到 admitted host request，把 after_delegate_result 接到 receipt reconciliation/journal replay。
• 新增只读 loopx agent-context 命令、配置目录/UI、双语说明和自动加载 skill 指引；同时把 agent context 纳入 TurnEnvelope v4 action signature。
• 增加 Python/TypeScript、CLI differential 和浏览器 smoke 覆盖，并修正了早期 review 指出的 v4 producer 未进入 CLI-output differential 注册的问题。

关键代码讲解

1. loopx/control_plane/agent_context.ts:46 的 projectAgentContext 是通用 typed dispatcher。它校验 exact phase/scope，只运行已启用且注册的 in-process provider，限制贡献字段和字节数，生成 content-bound context id，并将 provider 私有异常收敛为稳定错误码。
2. loopx/control_plane/subagent_context.ts:45 的 evaluateSubagentContext 是 capability owner。它从 canonical orchestration 精确计算 activation，避免把安装、发现或 host availability 错当成启用。
3. loopx/control_plane/turn_driver/subagent_execution_topology.py:994 的 observe_subagent_host_result 在 receipt normalization/reconciliation 后才生成 after_delegate_result，所以 guidance facts 不会替代 execution receipt。
4. loopx/control_plane/quota/turn_envelope.ts:632 的 turnActionProjection 把 context 纳入 actionable projection 并尝试在高水位时压缩为 detail_ref；这里也是本次 P1 的根因位置。

对主干的风险

[P1] 应按最终序列化后的 TurnEnvelope 做 context 压缩预算

当前 turnActionProjection 在第 647 行用中间 projection的大小和固定 8192 - 1400 阈值决定是否压缩。压缩后的 reference 自身仍增加约 505 bytes，而最终 envelope 只在更晚的位置做硬预算检查；一旦仍超限，没有第二次压缩或恢复路径。

我用同一个公开 loopx --format json turn plan fixture 对 immutable base/head 做了 counterfactual。fixture 只使用 schema 合法的 16 个 write scopes、1 个 parent-approval item，以及 multi_subagent 的 4-child 配置：

• base f3237a34e699b95a2d7138420d10e61a5173e04e：exit 0，ok=true，route=replan_required，7756 bytes，within_budget=true；
• head da1f52a813b045ae4cd8df5528021818fd0b7eb7：context 已压缩成 detail_ref，但仍为 8261 bytes，exit 1，ok=false，route=contract_error，within_budget=false。

这直接违反 PR 的关键承诺：接近既有 TurnEnvelope 上限时，guidance 应退化为 signed full-decision reference，同时全局 8192-byte limit 保持不变。实际结果是一个原本合法、可执行的 Turn 因启用 capability 在 host work 之前就被拒绝。影响范围是已启用 multi_subagent 且 Goal scope/approval metadata 较大的 coordinator；默认关闭路径不受影响。

最小修复建议：

1. 基于最终 envelope的真实剩余预算决定 compaction，而不是只看 pre-envelope projection；
2. 必要时继续缩短/删除 optional reference fields，直到最终 UTF-8 payload <=8192；
3. 保留 v4 signature coverage、content hash 和 detail_ref 语义；
4. 增加一条真实公开 turn plan high-water regression，证明 baseline-within-budget 的合法输入在 context enabled/compacted 后仍可执行。现有 large-envelope test 的取点在失败区间下方，未覆盖该不变量。

验证方面：exact head 的 216 个 Python tests、8 个 TypeScript tests、TypeScript typecheck、Ruff、git diff --check、本地 browser smoke，以及 102/102 CLI differential 均通过；disabled paired path 保持 v0 parity。远端 24 项中 21 项成功，但 checks 因 instrumented Personal Workspace reload/reconnect 在 10 秒内未恢复而失败，进而使 pytest aggregate 与 merge-gate 失败；本地 rerun 通过，所以我不把它归因为本 PR，不过它仍是一次 bypass merge 后未消解的红色信号。

我的整体评价

这个能力的产品价值、typed authority placement、默认关闭隔离和三阶段 lifecycle 设计总体是成立的；+1092/-13 虽然跨 26 个文件，但约 453 行是 tests/fixtures、130 行是 generated dashboard、85 行是 docs/skill，production mechanism 与真实 caller 都存在，范围仍算 cohesive。future-facing pass 也不需要再抽象一层：最高价值的后续就是把 envelope compaction 收敛成 final-size-aware 的单一预算 owner。

但当前 merged exact head 确有可复现的 P1 observable drift，不能给出无阻塞结论。请先补上述最小修复和 public high-water regression；之后复审应继续绑定新的 exact head，并重新确认远端 required checks。

English verdict: POST_MERGE_ACTION_REQUIRED at exact head da1f52a813b045ae4cd8df5528021818fd0b7eb7. The architecture and default-off isolation are sound, but final-envelope budgeting can turn a previously valid 7756-byte public turn plan into an 8261-byte contract_error; repair final-size-aware compaction and add a public high-water regression.

[huangruiteng]

Post-merge audit：新增 P1，default-off 指令面发生泄漏

[P1] skills/loopx-project/SKILL.md:1069 的主动 delegation 建议必须由动态 capability context 门控。 该 skill 会被 loopx workflow-skills --install 始终安装；因此即使某个 Goal 没有启用 multi_subagent，宿主仍会先读到“在单个 Todo 内考虑 read-heavy delegation”的建议。原生 child tools 又处在 LoopX Turn 的 typed admission 之外，模型可能在 agent_context 为 null 之前就改变规划或启动子任务。这使“runtime default-off”没有等价为“用户可观察行为 default-off”。

最小修复：通用 skill 只负责先读取 interaction_contract.agent_context（或成功的 loopx agent-context --phase before_plan）；context 缺失/disabled 时明确保持原有单 agent 行为，不因本 capability 搜索拆分或调用 child tools；主动 delegation 策略继续由 TypeScript provider 动态提供。回归应比较真实 workflow-skills --install 的 merge-base/fixed-head 输出：disabled 输出不得含主动 delegation 指令，同时 enabled fixture 仍能从动态 packet 获得该指导。

动机

本 PR 要解决的问题真实且重要：启用 multi_subagent 后，协调器原先只有容量/启动事实，没有在 planning、delegate preparation、result reconciliation 三个生命周期边界得到 capability 自己拥有的指导。把这部分语义纳入 live decision、interaction contract、签名 TurnEnvelope 和 receipt reconciliation，可以避免各宿主各自拼 prompt，也能让指导与当前 Goal、准入事实和 child receipt 对齐。非目标也控制得清楚：context 是 guidance_only，不授予 spawn、quota、Todo settlement 或 merge 权限。

改动思路

主路径复用了现有权威边界：before_plan 从 Goal 配置和 live admission 派生 context 并进入 v4 TurnEnvelope；before_delegate 只为已准入 operation 生成 host request context；after_delegate_result 从已记录 receipt 生成 reconciliation context。TypeScript provider 是规则 owner，Python 只做薄适配，quota/turn driver 继续拥有 effect 与 retry，整体架构方向正确。正向流程在 {enabled:true}、spawn_allowed=true 且 max_children>0 时生成 bounded guidance/facts/source_refs；provider 失败会被净化并 fail closed。

问题出在另一条自动加载路径：loopx-project skill 的静态文本并不经过上述 owner。真实安装对比显示，merge-base f3237a34e699b95a2d7138420d10e61a5173e04e 的安装产物没有该主动 delegation 语句，而 exact head 新增了它。于是运行时 provider 虽然返回 null，宿主提示面已经先改变。这不是“availability”而是可影响模型决策的生产行为，必须纳入 default-off 反事实。

具体改动

projectAgentContext（loopx/control_plane/agent_context.ts:46）负责按 capability id、phase 和 scope 调度 provider，只接受 {enabled:true}，并限制单 contribution/总 packet 大小；这是正确的统一决策边界。build_live_decision 附近（loopx/control_plane/quota/live_decision.py:499）把 before_plan 投影放入 interaction contract 与签名的 TurnEnvelope v4。subagent_execution_topology.py:1000 附近把已准入 child operation 与 host receipt 交给 after_delegate_result，没有复制 settlement 权威。CLI、catalog、Dashboard 与文档则提供观察和操作说明。

关键代码讲解

• projectAgentContext：输入是当前 Goal capability 配置和阶段事实；核心 invariant 是未启用时不产出 context、阶段不匹配时不串用指导、超预算时不让 provider 扩张热路径。
• live decision / TurnEnvelope v4：新增字段进入签名覆盖，最终 head 已补上旧 v0 到 v4 的真实 CLI differential，修复了早期 review 提出的迁移证据缺口。
• result reconciliation：只围绕已准入 operation/receipt 投影 advisory context；journal、replay 和 retry 仍由 turn driver 管理。
• skills/loopx-project/SKILL.md:1069：这是当前漏洞。它的消费者是所有安装该通用 skill 的 agent，而不是仅 enabled Goal，因此扩大了声明的激活范围。

对主干的风险

我在 exact head da1f52a813b045ae4cd8df5528021818fd0b7eb7 上执行了 64 个 Python focused tests、8 个 TypeScript provider tests、control-plane typecheck、Ruff 和 diff check，均通过；真实 CLI base/head differential 为 102/102，仅出现预期的 TurnEnvelope action-dimensions v0→v4 信号。Personal Workspace 的 development 与 packaged browser smoke 在干净本地运行均通过。

关键负例是实际 workflow-skill 安装：baseline 安装产物无主动 delegation 语句，head 安装产物有；因此现有 runtime test 全绿仍无法证明 disabled prompt parity。远端 exact-head 当时另有 Personal Workspace reload/reconnect 超时，导致 checks、aggregate pytest 和 merge-gate 红；本地新跑通过，且后续 #4250 已处理 browser recovery，故不把它归为本次新增 blocker，但保留为合并时证据不完整的 residual risk。

此外，已有 post-merge audit 已报告 final-size-aware TurnEnvelope compaction 的独立 P1；这里不重复登记。

我的整体评价

运行时设计、typed authority、三阶段数据流和 v4 迁移修复总体成立，代码规模虽大但与跨生命周期能力相称；domain-neutrality 与 guidance/obligation 的协议表述也基本准确。不过 default-off 必须覆盖自动安装的 skill/prompt，而不能只证明 runtime JSON 没有 feature object。当前 head 在该维度存在可复现的行为漂移，因此结论是 POST_MERGE_ACTION_REQUIRED。修复静态 skill 门控并补真实安装产物的 disabled/enabled 配对回归后，再复审这一项即可。

English verdict: POST_MERGE_ACTION_REQUIRED at exact head da1f52a813b045ae4cd8df5528021818fd0b7eb7. Runtime context is correctly opt-in, but the always-installed loopx-project skill unconditionally tells every coordinator to consider single-Todo delegation, so native hosts can change behavior while multi_subagent is disabled. Gate that guidance on a non-null enabled context and add an installed-skill default-off regression.

[huangruiteng]

Post-merge audit：新增 P1，agent-context 未纳入 help/manpage 分类

Reviewed exact head da1f52a813b045ae4cd8df5528021818fd0b7eb7（merge commit 32bcfa230d1ff8c4836e617b6b6e3001ba1778d4）。本轮不重复登记已有的 TurnEnvelope 最终预算 P1 和 default-off 静态 skill 泄漏 P1；新增发现是一个独立、可稳定复现的 CLI 完整性回归。

动机

这个 PR 解决的问题成立：Goal 已启用 multi_subagent 时，协调器此前只有 child capacity / model preference，没有在规划、委派准备、结果回收三个时点得到 capability-owned context。仅把建议写进某个宿主 prompt 既不能绑定当前 Goal/Agent/Todo，也不能绑定已准入 child operation 和真实 receipt reconciliation。PR 因此把 context 做成 derived、bounded、guidance_only / projected 的能力贡献，并同时提供只读 loopx agent-context 给绕过 LoopX Turn 的原生宿主。

非目标也基本清楚：context 不授予 spawn、quota、Todo、evidence acceptance 或 merge 权限，不证明模型已读取/采纳，也不把 child result 当成独立事实。

改动思路

主架构复用了正确边界。TypeScript projectAgentContext 统一拥有 phase/scope/schema/budget/provider failure isolation；evaluateSubagentContext 从 canonical Goal orchestration 派生启用状态。Python 只在 live quota、Turn plan 和 host-result reconciliation 处做薄适配。before_plan 进入 interaction contract 和 v4 action signature；before_delegate 只随已准入 child operations 进入 host request；after_delegate_result 从 normalized receipts 派生并随 journal replay 返回。配置 catalog、Personal Workspace、双语文档和 native CLI 负责操作与解释，不另建状态权威。

更小的 prompt-only 或 before-plan-only 方案无法覆盖 delegation/result lifecycle，因此一个小的通用 provider seam 是合理的。需要收口的是跨公共表面的配套 owner：TurnEnvelope 最终预算、自动安装 skill 的 default-off 门控，以及本轮发现的 top-level CLI help 分类。

具体改动

• 新增 loopx_agent_context_v0：固定三个 phase、精确 coordinator scope、单 contribution 2,048 bytes / 总 packet 3,072 bytes，并限制 provider 只能返回 guidance、facts、source_refs。
• 新增内置 multi_subagent provider：只有 mode=multi_subagent、spawn_allowed=true、max_children>0 同时成立时，运行时才生成 context；provider 私有异常被收敛为稳定错误码。
• live quota、TurnEnvelope、child host request、receipt reconciliation 和 durable journal 分别接入三个阶段；v4 signature 和 base/head differential 注册了有上界的一次性迁移。
• 新增只读 loopx agent-context、Goal configuration catalog / Personal Workspace phase 说明、双语集成文档和 focused tests；packaged Chat bundle同步更新。

关键代码讲解

1. loopx/control_plane/agent_context.ts:46 的 projectAgentContext 是 typed dispatcher：按 exact phase 和 enabled:true 调度受信任 provider，绑定 content id，拒绝伪造 control fields、重复 hook 和超预算内容。
2. loopx/control_plane/subagent_context.ts:45 的 evaluateSubagentContext 是 capability owner：从 canonical orchestration 精确派生 activation，model preference 或 CLI availability 本身不会打开运行时 context。
3. loopx/control_plane/quota/live_decision.py:499 把 before_plan 附着到当前 Goal/Agent/selected Todo；selection、must_attempt 和 settlement 仍由原 owner 决定。
4. loopx/control_plane/quota/turn_envelope.ts:632 负责把 context 纳入 v4 signature，并在预算压力下改成 content-bound cold-path reference；这里仍存在前一轮已报告的 final-size P1。
5. loopx/cli.py:329 注册了新的 top-level agent-context，但同一 exact head 没有同步 loopx/help_surface.py 的 exhaustive classification。

对主干的风险

[P1] 新 top-level CLI 未进入既有 help/manpage owner，导致 required public smoke 持续失败

仓库明确要求每个 top-level parser command 必须出现在 COMMAND_GROUPS 或 MANPAGE_COMMAND_HELP_ONLY。#4244 在 loopx/cli.py:329 增加 agent-context，但 loopx/help_surface.py 两处都没有它。真实反事实结果：

• merge-base f3237a34e699b95a2d7138420d10e61a5173e04e：python examples/cli-help-manpage-smoke.py 通过；
• exact head da1f52a813b045ae4cd8df5528021818fd0b7eb7：失败，unclassified: ['agent-context']；
• current main 84334f794126735a83a6cfb77882dd58ca8066d9：同样失败，说明问题尚未进入主线修复。

这不是格式建议：它让 full-public-smoke 的 CLI surface completeness 门禁保持红色。最低修复就是复用现有 owner，把只读 lifecycle helper 加到 MANPAGE_COMMAND_HELP_ONLY；open PR #4260 已包含这一个修复，当前 head 48b029bafdad844e532d7ed33db5094e2cc260d0 mergeable，远端 25 项均成功。该 PR 合并前，main 上的回归仍然存在。

本轮 focused validation：64 个 Python tests、8 个 TypeScript provider tests、control-plane typecheck、Ruff 和 git diff --check 全部通过。exact-head 远端 24 项中 21 项成功、checks / aggregate pytest / merge-gate 失败；直接 browser failure 后来由 #4250 修复，但不能抵消上述 CLI public-smoke 回归。此前两条 exact-head P1 的 owner 文件在 current main 未变化，因此仍需分别修复，本文不重复展开。

我的整体评价

能力价值、typed authority placement、三阶段数据流、provider 隔离和 receipt/replay 边界总体合理；+1092/-13 跨 26 文件，但 tests/smokes、generated bundle 与 docs 占了大半，production mechanism 有真实 caller，整体仍算 cohesive。未来向的小步也很明确：保留一个 provider owner，不再抽象；把预算、skill activation 和 help classification 分别收回现有 owner。

不过这个 exact head 已经有两个未关闭的 P1，本轮又确认了一个直接破坏 required public smoke 的 P1，因此不能给出“无新增问题”的结论。先合入 #4260 关闭本 finding，再分别处理前两条 audit；复审应绑定修复后的新 exact heads，而不是继续在 #4244 上重复评论。

English verdict: POST_MERGE_ACTION_REQUIRED at exact head da1f52a813b045ae4cd8df5528021818fd0b7eb7. In addition to the two previously reported P1s, registering agent-context without classifying it in the existing help/manpage owner makes the merge-base pass but the exact head and current main fail with unclassified: ['agent-context']; open PR #4260 contains the minimal green repair.

[huangruiteng]

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

审阅对象：PR #4244，exact head da1f52a813b045ae4cd8df5528021818fd0b7eb7，合并提交 32bcfa230d1ff8c4836e617b6b6e3001ba1778d4（parent 3b2b79706）。本记录是该 exact head 的合并后审计，只覆盖这一 head 的完整增量（26 files, +1092/-13）。

动机

这个 PR 修的是一个"能力开了但没人告诉协调者怎么用"的缺口。此前开启子 Agent 容量（multi_subagent）只描述启动参数（max_children、model_config 等），协调者在三个关键边界上没有获得任何由能力拥有、有界且可读的生命周期指导：规划前不知道哪些读密集工作值得并行拆分、哪些核验必须留在自己手里；委派前没有"边界/模型偏好/预期证据/停止条件"的提示；回收后没有"核验来源、说明采纳、关联计划"的义务提示。结果是能力被开启后，协调者容易把研究串行化、或直接拼接子任务摘要而跳过核验与整合——成本花了，但换不到这项能力本来要买的整合纪律。

目标因此是：让"已开启的能力"在规划、委派、回收三个边界上向协调者提供有界、只读、可被原生工具读取的上下文，同时不引入新的 turn、quota 消耗或 Todo 变更，也不把"生成了指导"说成"模型已经读过或采纳"。

改动思路

改动把"通用机制"和"能力自有内容"分开，并复用既有 owner：

• 类型化契约放在控制面 TS 侧（loopx/control_plane/agent_context.ts）：阶段枚举、标识符校验、每条贡献 2,048 字节 / 聚合 3,072 字节（留 256 字节余量）预算、context_id 哈希绑定（phase+scope+contribution）、贡献字段白名单（guidance/facts/source_refs）以及失败隔离（只记录 context_provider_failed，绝不投影 provider 的私有报错文本）。provider 必须是进程内注册对象，没有脚本 DSL。
• 首个 provider 由 multi_subagent 能力自己拥有（subagent_context.ts），只负责自己的文案与 facts；启用条件是 mode == "multi_subagent" && spawn_allowed == true && max_children > 0，再叠加类型化 owner 的 config.enabled === true 检查——所以"模型偏好"本身不会开启。
• Python 侧只做传输（agent_context.py 的 project_agent_context / envelope_agent_context），不复制规则；envelope_agent_context 在信封没有 agent_context 时返回 None，因此第二、三阶段无法凭空造出上下文。
• 三个边界挂在既有真实路径上：before_plan 由 live decision 注入 interaction contract；before_delegate 在 turn plan 里生成 delegation_context 并进入 coordinator host request；after_delegate_result 在 reconciliation 之后进入 host result 与 payload 投影。
• 信封预算与既有机制复用：当投影接近 TURN_ENVELOPE_BUDGET_BYTES - 1400 时，把上下文压缩成 content_hash + 指向既有 full-decision 路由的 detail_ref，全局信封上限不变——指导不能挤掉可执行的契约。
• 原生工具路径复用同一条只读接口：loopx agent-context --goal-id --agent-id --phase，并在 LoopX project skill 中记录用法；命令声明 read_only: true 与 host_receipts_observed: false。
• 前端沿用既有能力编辑器：目录元数据新增可选 context_contribution，UI 在能力详情里展示三个阶段的中英文说明，并明确写出"这是能力范围，不能证明某次运行已读取或采纳"。

兼容性对照既有机制：turn_envelope_action_dimensions_v4 只是新增一档签名覆盖，并复用既有 CLI 输出差分机制，给"旧覆盖 → v4"一次性、有界的额度（2,048 字符/字节、48 行、1,664 compact 字符）；v4 → v4 的再次增长、语义变化、反向迁移、未知 v5 一律 fail closed。

具体改动

控制面：agent_context.ts（+113）新增阶段枚举、类型化投影与预算/隔离规则；subagent_context.ts（+60）新增 provider 与启用判定；agent_context.py（+47）新增传输与信封绑定；turn_envelope.ts（+27/-8）投影 agent_context 并在预算压力下压缩为签名引用，同时新增 v4 签名覆盖；effect_runtime_handlers.ts（+9）注册 capability_hook.agent_context.describe|project；live_decision.py（+14）注入 before_plan；driver.py（+8）在存在 child_operations 时注入 delegation_context；subagent_execution_topology.py（+16/-1）在 reconciliation 后注入结果上下文并透传到 payload 投影；cli_output_differential.py（+25）加入一次性 v4 迁移额度。

入口与界面：cli_commands/agent_context.py（+66 新增）、cli.py（+5）注册只读命令；configuration_catalog.py（+2）与 configuration_ui.py（+1/-1）把 context_contribution 纳入既有合并路径；capability-workbench.tsx（+24）渲染阶段说明，chat.ts（+6）扩展 zod schema；web/chat/assets/index-Dk5Y5CRw.js（+129）与 web/chat/index.html（+1/-1）是重新构建的打包产物。

文档与技能：docs/integrations/codex-subagent-orchestration.md（+58）说明三个边界与边界语义；skills/loopx-project/SKILL.md（+27/-1）告诉原生工具协调者在每个边界读同一条只读接口，并明确 delivery: projected 只证明生成、不证明读取/执行/采纳、原生 CLI 读取不能认证 host receipt。

测试：tests/control_plane/test_agent_context.py（+248，生命周期/信封/日志/重放）、tests/control_plane/test_cli_output_differential.py（+41/-1，参数化的有界一次性迁移与 fail-closed 分支）、tests/control_plane_ts/agent_context.test.ts（+104，隔离/预算/未知阶段与缺失 scope/回收计数过滤）、tests/capabilities/test_capability_configuration_ui.py（+5，目录元数据）、examples/personal-workspace-browser-smoke.mjs（+18，三段阶段文案与移动端溢出）、examples/control_plane/cli-output-probe-runner.py（+37，真实 enabled fixture）。

关键代码讲解

1. projectAgentContext（agent_context.ts）：唯一 owner。只有"该能力 config 显式 enabled 且 provider 声明支持该 phase"才会运行；未知 phase 或缺失 coordinator scope 在调用 provider 之前就抛错；贡献字段白名单 + guidance/source_refs 数量与长度约束 + 单条与聚合字节预算共同限界；context_id 由 phase+scope+contribution 的规范化哈希得出，因此同一签名与内容一一对应。失败被规范化为 {hook_id|invalid_hook, code: "context_provider_failed"}，provider 报错文本永不外泄。
2. subagentContextProvider / evaluateSubagentContext（subagent_context.ts）：把"能力自有内容"隔离在一个 provider 内。启用判定只看 orchestration policy（mode/spawn_allowed/max_children），不看模型偏好；回收阶段的 reconciliation counts 被过滤为 ^[a-z_]{1,40}$ 的整数字段，避免把原始子任务材料复制进上下文。
3. turnActionProjection / signatureCoverage（turn_envelope.ts）：把"指导不得挤掉契约"写成代码。字段只在存在时投影；当投影接近既有预算阈值时改投影为 content_hash + detail_ref = full_decision.interaction_contract.agent_context，并保留 authority: guidance_only、delivery: projected；签名覆盖只有在字段存在时才切到 v4。
4. project_agent_context / envelope_agent_context（agent_context.py）：Python 只做传输与绑定，envelope_agent_context 在信封缺字段时返回 None，使第二、三阶段无法为未开启的能力制造上下文；这也是默认关闭语义在 Python 侧的落点。
5. handle_agent_context（cli_commands/agent_context.py）：原生工具入口。未注册的协调者直接 ok: false 并以退出码 1 失败；成功载荷显式带 read_only: true 与 host_receipts_observed: false，markdown 渲染首行也写明"projected guidance; not delivery or adoption"。

对主干的风险

主要风险不是崩溃，而是"把指导当成保证"。逐条验证：

• 默认关闭：enabled 由 orchestration policy 与 config 双重决定；本轮真实环境运行 loopx agent-context --goal-id loopx-meta --agent-id codex-side-bypass --phase before_delegate 返回 agent_context: null 且 read_only: true，未注册 agent 直接 fail closed。模型偏好、目录元数据、CLI 存在都不会激活。
• 不泄漏：provider 异常只投影固定 code 与（合法时）hook_id，错误文本被丢弃；source_refs 与 guidance 限长限量；回收计数只保留简单整数键。
• 不挤占：信封超过阈值时改为签名引用而非丢弃或超限，全局信封上限不变；planning_horizon 的既有压缩路径保持不变。
• 不伪造：agent_context 只证明生成；CLI 明确返回 host_receipts_observed: false；文档说明原生 CLI 读取不能认证 host receipt，也不自动开启新的模型回合。
• 迁移有界：差分额度只对"旧覆盖 → v4"生效一次，绝对值上限未放宽；参数化测试证明超一字节即失败，且 v4→v4 再增长、语义变化、反向迁移、未知 v5 全部 fail closed。

前置失败与归因（如实记录）：该 head 的 hosted checks 为 22/25，失败项 checks、pytest、merge-gate；pytest/merge-gate 只是转发任务，实质失败是浏览器 smoke 的 Reload did not restore the active Goal conversation and reconnect its active Turn within 10 seconds.，与父提交上的同一 job 逐字一致（既有 fixture 缺陷，同日由 #4250/#4251 修复，最近 main 上承载 checks 的 Python Tests 已绿）。PR 正文另行披露了既有 source-regex 检查 personal-workspace-contract.test.mjs 在 isManagerProjectionQuestion 断言上失败：本轮在该合并 head 复现，同时在父提交 3b2b79706 复现，且该测试与其断言的 views/dashboard-page.tsx 都不在本 PR 改动范围内——属于既有失败，作者如实披露而未计入通过。

未验证项如实标注：模型是否真的读取/采纳这些指导不在本改动可证明范围内（PR 与 UI 文案均已声明）；本地浏览器 smoke 未复跑。

本地验证（在该合并 head 的独立 worktree 上执行）：python -m pytest -q tests/control_plane/test_agent_context.py tests/control_plane/test_cli_output_differential.py tests/capabilities/test_capability_configuration_ui.py -> 64 passed；node --test tests/control_plane_ts/agent_context.test.ts -> 8 passed；npm run build:chat 重新构建后 loopx/web/chat 无任何 diff（产物 index-Dk5Y5CRw.js、index-DYYo3B8I.css 与提交内容逐字节一致），且产物中包含新增的能力详情文案。

我的整体评价

APPROVE。这是一个边界划得很清楚的改动：通用机制（阶段、预算、哈希、隔离、启用判定）在类型化 owner 里，能力自有文案在能力自己的 provider 里，三个阶段挂在真实调用点上，原生工具通过同一条只读 CLI 读取，前端只展示支持范围并明确声明它不是运行证据。默认关闭语义在代码（policy + config 双重 gate）、测试和真实 CLI 运行中都成立；信封预算压力下用签名引用而不是挤压可执行契约，是目前最稳妥的处理方式；v4 差分额度是一次性、有界且被参数化测试钉死的兼容补偿。

无阻断发现。残余风险与最强缺失验证：delivery: projected 只能证明生成，模型是否读取/采纳无法由本改动证明（作者已声明，UI 也已声明）；原生工具路径依赖 agent 真的按 skill 去读，机制上不强制；v4 额度应在声明迁移完成后退役；该 head 的 CI 红项与 PR 自披露的 source-regex 失败均已用父提交复现证明为既有问题。合并后审计记录仅作为该 exact head 的结论，不授予任何合并、回滚或再次修改的权限。

English verdict: APPROVE - #4244 at exact head da1f52a (merged as 32bcfa2) adds bounded, capability-gated, phase-scoped coordinator context at before_plan/before_delegate/after_delegate_result through one typed TS owner plus a multi_subagent-owned provider, a Python transport, three real call sites, a read-only loopx agent-context CLI, capability-editor metadata and a one-time bounded v4 differential allowance; it starts no turn, spends no quota, mutates no Todo, keeps guidance advisory (authority: guidance_only, delivery: projected) and yields to the envelope budget via a signed content reference. Verified at the merged head: 64 focused Python tests passed, 8 TypeScript provider tests passed, a clean npm run build:chat reproduced the committed packaged assets byte-for-byte, the live CLI returned null context for a capability-off goal and failed closed for an unregistered agent, and the differential keeps failing closed on repeated growth, semantic change, reverse migration and unknown v5. Hosted checks/pytest/merge-gate failed on the pre-existing browser-smoke reload acceptance (identical on the parent commit, repaired by #4250/#4251), and the PR's disclosed personal-workspace-contract.test.mjs failure was reproduced at both head and parent and is unrelated to this delta. No blocking finding; residual risks are the unmeasured model adoption, the skill-dependent native-tool path, and the one-time v4 allowance to retire.