Skip to content

docs(rfc): record the shipped managed selection surfaces and promotion gates - #4400

Merged
huangruiteng merged 1 commit into
mainfrom
codex/managed-host-selection-20260915
Sep 15, 2026
Merged

huangruiteng merged 1 commit into
mainfrom
codex/managed-host-selection-20260915

Conversation

@huangruiteng

@huangruiteng huangruiteng commented Sep 14, 2026 •

Copy link
Copy Markdown
Collaborator

Summary

A docs-only refresh of the managed-runtime selection RFC so it records the rule the repository selects, not the one it used to infer. This replaces the earlier revision of this PR, which recorded the credential-resolved host rule.

  • The Turn host is selected, never inferred: shipped default dsh, LOOPX_TURN_HOST re-points it, an explicit --host wins over both. A configured DEEPSEEK_API_KEY only authenticates the host that was already selected (PR feat(turn): select the managed Turn host explicitly #4443).
  • The steward channel is a different surface with its own default: codex, because that is the only transport that can hold an interactive steward session today. LOOPX_MANAGER_ENDPOINT re-points it, and its model follows the executor it selected, so a configured credential can no longer swap the model while the endpoint stays on the CLI (PR feat(chat): select the steward channel executor explicitly #4446).
  • The role table gains a steward channel executor row, and the codex-cli row now states that it is the individual executor kind billed to one person's CLI login rather than a managed lane.
  • The steward-channel section records the real promotion gate for the managed host: an interactive Chat transport, not a credential appearing. Selecting the managed host today reports available: false / managed_host_chat_transport_unsupported and fails a session request as the same typed host-tool gate.
  • The milestone table records the steward channel's M1 contract as selected -- endpoint, model, source, and executor kind -- and keeps the session-identity gap explicit: a channel answer still cannot prove which session served it.
  • Evidence and pin rows are re-pointed at the replacement PRs (feat(turn): select the managed Turn host explicitly #4443, feat(chat): select the steward channel executor explicitly #4446) and the dsh pin PR chore(dsh): pin the managed dsh host to the latest released SDK #4420. The branch is rebased onto current main.

What this is not

No runtime is promoted, no scoring or performance number is added, and no default behavior changes here. Session ownership (managed_runtime vs attached_host) and the M1-M4 integration milestones stay owned by the agent session execution modes RFC.

Validation

  • examples/docs-governance-smoke.py -> ok
  • git diff --check -> clean
  • English and Chinese mirrors updated together and diffed against each other for the changed rows.

…n gates

The RFC still described the managed host as resolved from the operator
credential. It now records what the repository ships and what the managed
stack will ship: the Turn host is selected, never inferred (shipped default
`dsh`, `LOOPX_TURN_HOST` re-points it, an explicit `--host` wins), the steward
channel selects its own executor (shipped default `codex`, because it is the
only interactive Chat transport today), and a configured credential only
authenticates the selection instead of changing it.

- The role table gains the steward channel executor row and states each
  selection source, including the `individual` versus `managed` executor kind.
- The steward-channel section replaces the credential-resolved binding rule and
  records the promotion gate for the managed host (an interactive Chat
  transport), so the credential is explicitly not the promotion signal.
- The milestone table records the steward channel's M1 contract as selected --
  endpoint, model, source and executor kind -- and states the session-identity
  gap that still blocks a channel answer from proving which session served it.
- Evidence and dsh-pin rows are re-pointed at the replacement PRs (#4443,
  #4446) and the dsh pin PR #4420.

Docs only: no runtime is promoted, no default behavior changes here, and the
English and Chinese mirrors are updated together.

Signed-off-by: huangruiteng <14976749+huangruiteng@users.noreply.github.com>
@huangruiteng
huangruiteng force-pushed the codex/managed-host-selection-20260915 branch from 4ec08de to fc278ef Compare September 15, 2026 10:23
@huangruiteng huangruiteng changed the title docs(rfc): record shipped managed execution surface and promotion gates docs(rfc): record the shipped managed selection surfaces and promotion gates Sep 15, 2026

@huangruiteng huangruiteng left a comment

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

详细中文评审

审查对象:fc278efac7fa9125dff783359f4ec3d351e27396(docs(rfc): record the shipped managed selection surfaces and promotion gates,base main,2 文件 +361/-0,纯文档)。执行契约 policy_revision=3;结果 JSON 已通过 pr-review --check-result(approval_consistent: true)。

动机

托管选择面(默认宿主由显式选择决定、凭据只认证)已经实现,管家通道的传输决策也已经做出,但 RFC 里没有记录,读者只能从 PR 列表反推。这份文档补的正是最容易误读的那一层:把「2026-09-15 已在 main」「将随本文档落地(#4443/#4446/#4420)」「本地实测、非仓库门禁」三类证据状态分开写,并把推广门禁与开放缺口一次讲清。

改动思路

在既有 harness-selection-dsh-pi-v0.md 中新增三节:Managed Execution Surface(角色与门禁表,含 dsh/codex/Pi/L1 四类角色的「今天的选择」与「推广门禁」)、Managed host binding and live qualification(binding 的四个要素与逐条证据来源)、Steward Channel Chat Transport(管家通道为何与 Turn 面默认不同、三种 transport 选项与选择规则)。中文镜像同步。里程碑归属明确留给 agent-session-execution-modes-v0.md,避免两份文档争夺同一权威。

具体改动

  • 角色/门禁表:把「默认托管执行宿主」「管家通道执行器」「可选 Turn 宿主 codex-cli」「L1 事件源候选 DSH」「可选可见宿主 Pi」分开列,并写明「发现凭据不是推广信号」「managed lane 不得静默依赖个人 CLI 订阅」。
  • 证据分源:仓库覆盖(无 provider 调用)、本地 live qualification(真实 SDK/runtime,含 validated_progress 与 fail-closed 两条)、以及 CI 不断言的本地行。
  • 开放缺口:headless profile 缺 @deepseek-ai/dsh-session-title-llm 的上游问题、托管 Turn 需要显式工具行、host_mode_planner 仍输出 --host generic-cli 且未标注为回滚路径。
  • dsh pin 两阶段:main 的 0.1.2a3 与栈内的 0.1.5rc1,并说明为何不采用 next/alpha 渠道。
  • 边界声明:容器/凭据留在 owner-local,不做 live model 执行或保留期删除授权。

对主干的风险

纯文档,无运行时影响。唯一实际风险是文本新鲜度:文中以具体 PR 号作为交付载体,若 #4443/#4446/#4420 的最终形态改变,读者会读到过期状态,而 docs-governance-smoke 只校验格式与治理要求,不校验内容是否仍然成立。文中已给出双向读法(合并后按 shipped 读,否则按 stack-only 读),把误读风险压低但未消除。

已扫描公共/私有边界:无本地绝对路径、无内部链接、无凭据或私有运营上下文。

我的整体评价

APPROVE。这是当前 RFC 最缺的一类信息:让「已交付」「栈内」「本地实测」不再互相冒充,也让推广门禁从「有凭据就上」变成「先有可承载会话的 transport」。文档把失败与缺口写得比成绩更显眼,这一点在托管默认值这种计费边界上尤其重要。

非阻塞建议一条(P2):合并 #4443/#4446/#4420 时同步更新本文档相应行,或把「本节状态随 PR 列表变化」写成醒目的阅读约定。

验证:head fc278efac 独立 worktree 内 examples/docs-governance-smoke.py → ok;examples/docs-asset-integrity-smoke.py → ok(6 assets verified);中英两文件的 ## 一级节数一致(10 / 10);远端文档路径过滤下无 failure。


English verdict: APPROVE at fc278efac7fa9125dff783359f4ec3d351e27396. Docs-only (+361 across the English RFC and its zh-CN mirror) and it records exactly what was missing: the managed selection surfaces separated into shipped-on-main, landing-with-this-document (#4443/#4446/#4420) and local-qualification-only evidence, plus the promotion gate that says a discovered credential is never the promotion signal and a managed lane must not silently depend on an individual's CLI subscription. It also names the open gaps honestly (the headless profile import gap, the required dsh tool rows, and host_mode_planner still emitting generic-cli without labelling it the rollback path) and leaves milestone ownership to agent-session-execution-modes-v0.md. Validated at this head: docs-governance smoke ok, docs-asset-integrity smoke ok, EN/ZH section parity 10/10, no failing remote checks. Only non-blocking note (P2): the PR numbers are the delivery vehicle, so update these rows when those slices land — the docs gate checks form, not content freshness.

@huangruiteng
huangruiteng merged commit 2f84af9 into main Sep 15, 2026
18 checks passed
@huangruiteng
huangruiteng deleted the codex/managed-host-selection-20260915 branch September 15, 2026 10:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant