feat(orc): centralize host-aware routing

skills/orc/README.md

@@ -1,7 +1,7 @@
 # orc
 
-ORC 是显式调用的工程编排入口：把开发、版本发布、DEB 和 Docker 任务拆成阶段，
-交给对应 Skill，并为每个执行 Agent 选择 `low`、`mid` 或 `high` 档位。
+ORC 是显式调用的薄路由器：只把开发、版本发布、DEB 和 Docker 意图映射成阶段，
+按静态配置选择 `low`、`mid` 或 `high` worker，再交给对应 Skill。
 
 ## 什么时候使用
 
@@ -16,13 +16,14 @@ ORC 是显式调用的工程编排入口：把开发、版本发布、DEB 和 Do
 - Orca 正在运行并启用了 orchestration。
 - 安装本次需要的 `$ack`、`$manage-release`、`$deb-publisher` 或
   `$publish-docker-image`。
-- 运行 `$orc 初始化` 生成 `docs/orc/config.yaml`，确认三档对应的精确模型。
-- `/usr/bin/python3`；ORC v1 配置必须保持为内置模板使用的 JSON-compatible YAML。
+- ORC 直接使用 skill 内共享的 `config.yaml`，不需要在每个项目初始化配置。修改这份
+  配置会影响所有项目；旧的项目级 `docs/orc/config.yaml` 不再参与解析。
+- `/usr/bin/python3`；ORC v2 配置必须保持为 JSON-compatible YAML。
   resolver 以 `-I -S` 隔离模式运行，不加载项目模块、用户 site-packages 或第三方解析器。
-- ORC v1 worker 使用 `workspace-write` sandbox，以便发送 Orca lifecycle 消息；
+- ORC v2 worker 使用 `workspace-write` sandbox，以便发送 Orca lifecycle 消息；
   只读任务会在阶段 prompt 中禁止文件修改。
 
-## Agent 档位
+## Worker 档位
 
 | 档位 | 典型任务 |
 |------|----------|
@@ -31,27 +32,34 @@ ORC 是显式调用的工程编排入口：把开发、版本发布、DEB 和 Do
 | `high` | 需求理解、跨系统改动、异常恢复和高风险裁决 |
 
 档位不是权限。三个档位仍受各自 profile 和下游 Skill 的授权边界约束。
-当前 ORC v1 的结构化启动适配器支持 Codex worker；其它 Agent CLI 需要独立适配器，
-不会通过自由命令接入。
+这些档位只选择下游 worker，不会切换当前 ORC Coordinator 已经使用的模型。
+结构化启动适配器支持 Codex 与 Cursor worker，并固定跟随当前宿主：从 Codex 调用就使用
+Codex，从 Cursor 调用就使用 Cursor。共享配置为两个 CLI 分别维护三档模型，不设置跨宿主
+默认值。
 
 ## 使用示例
 
 ```text
 $orc high 修复登录问题，验证通过后发布新版本。
 $orc code=high release=mid docker=low，完成修复、发版并推送镜像。
+$orc low，检查并准备下一个版本，不执行远端写操作。
 $orc mid 继续上次中断的 v1.4.0 发布流程。
 ```
 
-阶段级档位优先于全局档位。用户显式指定后，ORC 不会静默改档；能力不足时会暂停并
-请求确认。
+阶段级档位优先于全局档位；未指定时只读取 `stageDefaults` / `defaultLevel`。ORC 不根据
+任务复杂度动态升降档；worker 报告能力不足时，ORC 只转发请求。
 
 ## Agent 会做什么
 
-1. 识别开发、源码发布、DEB 与 Docker 阶段及其依赖。
-2. 解析每个阶段的 Agent profile，把配置快照、可信 Codex executable 和真实 Git
+1. 识别开发、源码发布、DEB 与 Docker 意图，并按固定表建立阶段依赖。
+2. 从当前 Agent 的系统身份锁定宿主 CLI，再解析每个阶段的 profile，把共享配置快照、
+   可信 Agent CLI executable 和真实 Git
    worktree 绑定成 launch fingerprint，并展示计划和外部写入边界。
-3. 通过 Orca 分发给对应 Skill，监督完成消息、异常和决策门。
-4. 汇总每个阶段的实际状态、证据和安全恢复入口。
+3. 通过 Orca 分发给对应 Skill，转发完成消息、异常和决策门。
+4. 按下游 Skill 声明的证据字段汇总状态和恢复入口，不重新做领域判断。
+
+ORC 不分析实现、不建议版本、不评估发布风险、不选择合并或构建方案；这些工作全部属于
+下游 Skill。
 
 ## 如何判断完成