refactor(cli): extract goal channel operation owner

[Duang777]

Summary

• move goal-channel prepare-operation and deliver-operation registration and dispatch into a bounded command owner
• keep activation, source-runtime routing, rendering, and exit-code ownership in goal_channel.py
• preserve preview/no-write, execute readback, executor-drift, provider-stage, and unknown-write outcome semantics
• pin both commands to the new owner in the CLI module ownership smoke
• mark GH-C06 as in review on the contributor task board

Source

Implements one cohesive GH-C06 CLI ownership slice from docs/development/contributor-tasks.md, aligned with the S5 Goal Channel boundary in the overall roadmap.

Validation

• 68 passed in tests/extensions/test_lark_goal_channel.py and tests/extensions/test_lark_goal_channel_operation.py
• 65 passed across CLI entrypoint, Goal Channel target/runtime, project lifecycle, and control-plane import-boundary tests
• Ruff format/check passed on all changed Python files
• targeted mypy passed for both command modules with dependency errors silenced
• CLI module ownership smoke passed
• CLI command module regression passed
• docs governance smoke passed
• real prepare-operation --help and deliver-operation --help entrypoints passed
• exact-head loopx canary premerge --from-git-diff passed: 14 selected checks, 0 failures; one inherited advisory remains for unrelated chat_server.py and goal_topic_connections.py module budgets
• public boundary scan passed for all six changed paths

Scope

No frontend or Lark companion change is required: public CLI arguments, packets, routing, and provider behavior are unchanged. The bounded future-facing pass stopped at the operation command owner; broader Goal Channel extraction remains outside this PR.

[Duang777]

CI baseline note: the two failing test shards are the same post-#4771 stale priority assertions that reproduce on main@2caada69d:

• test_a_lane_that_already_declares_a_priority_is_not_relabelled
• test_real_canonical_provider_preserves_complete_complex_todo_semantics

They are isolated in #4819. I will sync this branch with main after #4818 (quota module budget extraction) and #4819 land, then rerun the refactor checks on the resulting exact head.

[huangruiteng]

动机

这个 PR 解决的是 GH-C06 的一个完整、可独立回滚的维护性切片：goal_channel.py 同时承担过多命令注册和运行时分派职责，而 prepare-operation / deliver-operation 又共享同一套 proposal、provider target 与 typed failure 生命周期。把这两个命令移到同一个 bounded owner 能降低后续 Goal Channel 修改的耦合，同时不需要新增状态、CLI 或兼容层。与只搬 helper 相比，本 PR 连 parser registration 和 dispatch ownership 一起迁移，才真正移除了父模块的这组变更原因；与继续拆分其他 Goal Channel 命令相比，当前边界更小、更容易验证。

改动思路

公共入口仍是 loopx goal-channel，goal_channel.py 继续负责 extension activation、global-to-source registry/runtime 路由、最终渲染和 exit code；新模块只接收已经解析出的 source context，识别两个 exact command value，然后复用原有的 ChatActionService、deliver_goal_channel_operation_card、binding/target reader 和 operation_packet。这个分工没有创建第二套 proposal、receipt 或 provider authority。

我特别对照了抽取前后的 runtime-root 语义：prepare 原来使用 invoked runtime 的默认 target file，deliver 原来会切换到 source runtime；新 _operation_target_path 保留了这个不对称规则，而且显式 --target-path 对两条路径都继续优先。global registry 路由到 project source runtime 的现有测试也验证了 action store、runtime、binding、target path 和 Goal id。

具体改动

• 新增 goal_channel_operation.py，集中两个子命令的注册、typed request 解析、target 路由、prepare/deliver 分派和专属异常投影。
• goal_channel.py 删除内联注册与执行代码，改为传入 GoalChannelOperationContext；非 operation 命令继续由父模块原路径处理。
• 测试只调整 monkeypatch/import owner，并新增 success-only extension_activation 与失败不携带该字段的断言；ownership smoke 把两个命令固定到新模块。
• contributor board 将 GH-C06 标记为 in review；没有引入私有状态、生成物或本地路径。

关键代码讲解

1. GoalChannelOperationContext：只传递 invoked/source runtime、source registry 与 binding path，避免新模块重新解析 registry 或获得更广 authority。
2. _operation_target_path：显式编码 prepare 使用 invoked runtime、deliver 使用 source runtime 的旧语义；--target-path override 始终优先。
3. run_goal_channel_operation：未知命令返回 None 给父模块；两个已知命令保留 provider_target_missing、executor drift、typed delivery stage、unknown external-write outcome 与 invalid configuration 的原 packet 语义。
4. handle_goal_channel_command：activation/source route 仍在父模块，只有成功 packet 才附加 extension_activation，然后按 ok 返回 0/1。

对主干的风险

最强回归场景是 invoked runtime 与 source runtime 不同，抽取后误读 provider target 或 action store。该场景已由 global-registry source-runtime 用例覆盖；typed provider rejection、unknown-write（必须投影为已发生写入）、executor drift、missing target 和 invalid configuration 也走过负路径。结果如下：

• Goal Channel 两个聚焦测试文件：68 passed（3.73s）。
• CLI entrypoint、target/runtime、project lifecycle 与 import-boundary 集合：65 passed（47.63s）。
• 两个真实 --help 入口保留全部 flags；changed-module ownership assertion 通过。
• Ruff、targeted mypy 与 git diff --check 通过。

仓库完整 module-size smoke 当前仍因未改动的 quota.py 为 1114 行、超过 1000 行基线而失败；本 PR 新增的 ownership 断言与两个 changed-module budget 单独通过。远端两个 Python shard 的失败也是当前 head 继承的 priority-display 断言，修复 #4819 已在最新 main；因此它们不构成本 PR 运行时 finding，但该分支仍需由 GitHub 与最新 main 集成并重跑 merge gate。这里没有把红色检查描述成“可忽略”，只是把触发路径与本 PR 改动边界分开记录。

default-off/authority 方面没有漂移：Lark extension activation 仍在父模块、先于新 owner；CLI 可见、binding 存在或 provider ready 都不会绕过 activation。新模块不授予确认或 operation execution authority，也没有更宽泛的 actor/lifecycle 命名。typed command enum 使用 exact values，没有 substring/prose classification。

我的整体评价

我没有发现阻塞性问题。这个 exact head 复用了现有语义与 domain owners，生产边界清晰，父模块降到 740 行，新 owner 为 351 行，规模与两条共享生命周期的命令相称。正/负路径、source-runtime 路由、packet 字段和 exit semantics 均有足够证据支持行为等价；更广的 Goal Channel 拆分在这里反而会扩大风险。

批准 dd47ec9ba5e13876032f96528e7a3d4380cbdeb9。剩余风险是 branch-behind 与仓库基线红灯的集成状态，不是本 PR 的代码 finding；合并前仍应让最新 main 上的 required checks 收敛。

English verdict: APPROVE - head dd47ec9