[xiaoan17]

Scope

One read-only ledger entry that answers the question the C4.3 settlement
obligation comparison left open, plus the derived RFC status index.

The comparison listed a candidate slice: vocabulary unification (small) — if
any caller adopts both paths, give guard, lifecycle_completion and
validation one typed owner instead of three names in two files. Do not unify
names that describe different obligations. It was conditional on a question
that had not been answered. This entry answers it.

Answer

They do not describe one obligation, so the candidate is withdrawn.

• validation is never executed. TurnProviderStepKind excludes it in both
  runtimes, require_turn_provider_step_kind raises validation is not a provider effect step, the reducer throws unsupported base settlement step validation if asked to run it, and the registry's own value note already
  says it is "the one step the dispatcher never executes" and "carries no
  command template".
• guard and lifecycle_completion are executed steps. The adapter decodes an
  ordered_cli_sequence of four or five steps in a fixed order and calls
  run_cli(step.args) for each, with a continue_when deciding whether the
  rest of the plan runs.
• The two value sets differ exactly where the question is asked: guard and
  lifecycle_completion occur only in A, validation only in B. The
  repository's own advisory does not list them as a merge candidate.
• lifecycle_completion has no counterpart in B.
• One shipped caller already uses both vocabularies for one admission decision:
  extensions/governed_capability_execution.py classifies the caller's
  admission snapshot with A's classify_host_guard_snapshot, then calls
  execute_turn_driver_settlement with completed_phases that already
  contain validation.

guard and validation name one obligation seen from two positions — the
producer that runs the admission and the consumer that refuses to run it.
Renaming them would hide that asymmetry and break B's "a phase is never
executed" invariant.

What it leaves open

The vocabulary that does exist has no typed owner and its literal is written
twice: an unexported STEP_KINDS in turn_driver/host_todo_completion.ts and
a private _STEP_KINDS in host_adapter_settlement.py, which validates the
TypeScript-produced plan order against the Python copy. Neither is exported,
neither is registered in loopx/semantics/vocabulary_v0.json, and the
repository's inventory sees neither carrier — the TypeScript scan matches
export const NAME = [...] as const; and the Python scan matches module-level
UPPER_NAME assignments — so the registry's drift smoke cannot cover it. A
hand-kept Python mirror of a TypeScript literal can drift, and the failure
would surface at runtime as TypeScript host provider step order mismatch.

That is a separate slice: one shared owner for the ordered host-adapter step
kinds, registered in the vocabulary registry. It must first reconcile the
in-flight settlement work (#3412, #5677, #7580, #7523).

Validation

• mkdocs build --strict for the docs site and both developer books
• RFC bilingual check passed; the English and Chinese entries change together
• examples/docs-governance-smoke.py passed
• loopx canary premerge --from-git-diff --git-diff-base origin/main green
  (17 checks, 0 failures)

No code, schema, wire, registry or default change.

Merge ordering

The derived status index counts ledger entries per RFC, so both this PR and
#7593 change the same STATUS.md line. Each branch is self-consistent on its
own, but whichever of the two lands last must regenerate the index
(python3 scripts/generate_rfc_status_index.py --write) so the entry count
matches the directory again.

Signed-off-by: xiaoan17 anbc1224@gmail.com

Rebase and re-validation (2026-10-29)

• Base: main at 9dcdc0bacd455a8cf6f6146f052ffc4df0f5d04a
• Head: 591ec63050da58c9cf4c7acf5a83e128c8fa47d1
• The change itself is unchanged; only the parent moved. The branch now carries two non-empty commits; the previous head had an empty second commit that the GitHub API push had left behind.

Merge order. This entry must land before #7645. The two entries add one ledger file each, so the derived index count moves 2 entries → 3 entries here and 3 entries → 4 entries there. The branch of #7645 is now based on this head, so merging them in this order keeps docs/architecture/rfcs/STATUS.md and its Chinese mirror accurate at every step; merging them in the other order leaves the derived index stale and scripts/generate_rfc_status_index.py --check fails.

All nine pull requests in this set were rebased onto the then-current main (this one onto 9dcdc0bacd455a8cf6f6146f052ffc4df0f5d04a) and merged together in a local worktree. The merged state passes tests/architecture/, tests/canary/, tests/test_manager_context_roundtrip.py, tests/test_lark_native_reply_context.py, tests/control_plane/test_host_adapter_settlement_step_vocabulary.py and tests/control_plane/test_host_adapter_settlement_partial_steps.py — 1805 passed, 0 failed. python scripts/generate_rfc_status_index.py --check is clean.

Merge sequence (2026-10-29)

1. docs(rfc): confirm the C4.3 settlement vocabulary question #7617 — CI is green end to end; merge it first. It must precede test(settlement): characterize the host adapter's partial-step boundary #7645.
2. test(settlement): characterize the host adapter's partial-step boundary #7645 — chained on docs(rfc): confirm the C4.3 settlement vocabulary question #7617's head; merge it after docs(rfc): confirm the C4.3 settlement vocabulary question #7617.
3. feat(control-plane): register the host-adapter settlement step vocabulary #7619 — independent of the two above.
4. test(chat): assert the preserved operator material in the native input #7632, test(semantics): derive the output-evidence guard from the registry #7640, docs(rfc): record the Codex provider-routing activation seam #7642, fix(canary): lower the stale collaboration_mcp module ceiling #7646, fix(chat): keep the provider reply projection in the composition root #7631 — the five that restore main to green. Each one fixes only its own share of the six places where main is currently red, so until all five land every one of them still shows the others' red tests in its pytest / test-shard lanes. test(semantics): point the stale turn_route fixtures at their current owners #7621 was merged the same way, with a known base-red. Merge them in any order; each merge removes one share.

[xiaoan17]

Merge ordering: regenerate the status index after #7593 lands

The derived status index counts ledger entries per RFC. This PR and #7593 each
add one entry to the same RFC ledger directory, and each branch regenerates the
index for its own tree ([1 entry] → [2 entries]). Once both are on main
the directory holds three entries, so the second PR to land must regenerate
the index (python3 scripts/generate_rfc_status_index.py --write) so the
count reads [3 entries] again. Until then examples/docs-governance-smoke.py
fails for every later change.

I will regenerate it on whichever of the two lands last.

The baseline note was also corrected: the entry now reads the facts at
652f50384 and says the settlement owners are unchanged since 544aa0fee,
which is the accurate statement — effect_program.py and effect_program.ts
did change between fb331f45 and 544aa0fee, and every claim in the entry was
re-checked at the current main.

---

Merge ordering: regenerate the status index after #7593 lands

This PR and #7593 each add one ledger entry to the same RFC and each
regenerate the derived status index for its own tree ([1 entry] →
[2 entries]). Once both are on main the directory holds three entries, so
the second PR to land must regenerate the index to [3 entries], or
examples/docs-governance-smoke.py fails for every later change. I will
regenerate it on whichever lands last.

[loopx-agent]

Reviewer: model_agent; OpenAI gpt-6.1-sol; reasoning effort max; runtime_reported.

APPROVE：词汇结论与当前调用路径一致，没有 blocking finding；保留一个已验证的 P3 中文章节跳转问题。审查完整 head 591ec63050da58c9cf4c7acf5a83e128c8fa47d1，并按实际 PR base 的 merge-base 9dcdc0bacd455a8cf6f6146f052ffc4df0f5d04a 判断全量四文件差异。

动机 / Motivation

受影响的是准备合并结算适配层的维护者：他们必须先分清 Host 入口步骤与已提交的结算阶段。

此前把三套步骤标签视为重复，可能把入口校验再执行一次，或在删除适配器时漏掉已有义务；本条目先核对调用方，撤回没有等价依据的三标签统一方案。

可验证的增量是确认同一个已交付调用方怎样使用两套不同标签，并把真正未覆盖的 Host 步骤登记问题单独留在原有后续提案。

本 PR 不删除解释器、不新增执行入口、不改持久回执、额度或默认行为，也不宣称完整 C4.3 收敛已经完成。

仍缺完整删除前提、所有失败与恢复路径的等价证据以及端到端成本比较；Host 步骤登记另由已有 #7619 提案承接。

改动思路 / Approach

这里的 settlement 是一次工作执行后的持久结算。Host adapter 解码 CLI 计划，TypeScript prepare/finalize 决定计划与停止分类；另一条 turn settlement 路径执行已存在的阶段 reducer，再读取 provider 回执。两者共享 identity，并不意味着标签可以互换。直接将三套标签统一的最强反对理由是：validation 在一条路径里已完成，在另一类列表里根本不能执行，合并名字可能改变重放义务。

本条目采用更小的已有 owner 边界：确认事实并撤回三标签统一候选，不加执行框架。实际 loopx/extensions/governed_capability_execution.py 已把 Host admission 和 execute_turn_driver_settlement 连起来；provider step validator 实际拒绝 validation，现有私有 Host step 常量又确实未被 registry inventory 收录。因而下一步 Host 步骤登记与“统一三个 label 集合”是不同问题。前者已有 #7619 提案，后者在本文撤回。这样划界可独立核查与回退，但不证明删除适配器已安全。

具体改动 / Changes

关键内容讲解

全量差异为四个文档路径 +230/-2：EN/ZH confirmation 条目与两个 RFC 索引。A 是 guard、completion、writeback、spend 等 Host 前门步骤；B 是实际执行/读回的 settlement provider phases；C 是 validation 之类已提交阶段。这是对当前职责的解释，没有新增三套 authority。逐项比对真实 owner、实际 caller、inventory 与配对中文，结论相符。

依据预变更的 docs/architecture/rfcs/ledger/controller-executor-unified-contract-v0/2026-10-27-refactor-handoff.md，spec_revision: 9dcdc0bacd455a8cf6f6146f052ffc4df0f5d04a，criterion_id: C4.3。该准则要求先比较 identity、validation、guard/vision、completion、writeback、spend、closeout 与 recovery，再考虑删除解释器，并保留原始 effect ID 与逐阶段持久读回。此处只交付有用的比较/刻画前提；完整等价、调用方采纳与成本资格仍为 deferred，不能从条目数或测试通过推导完成。

本地 PASS：docs governance、RFC index --check、以目标 main 33d9ecd9fd29bce4986da6c9e9a6b758a24f91b3 检查整个已提交 PR 的 bilingual gate，以及主站、英文书、中文书三次实际 mkdocs build --strict。文档依赖来自声明的 docs/requirements-docs.txt 隔离覆盖层。构建保留了非阻断 anchor INFO，不能把 exit 0 说成每个链接都正确。原生 change-quality 和 standard premerge 均 PASS：4 项 direct checks 与 17 项 canary/risk/public-boundary checks 通过，无 skip、timeout、tracked side effect 或人工 hold。通过验证仍不等于 merge 授权。

对主干的风险 / Risks

两个 exact head 的相关十个生产 owner 文件与不可变基线及已验证目标 main 内容一致；没有新的运行时、默认值、权限、启用开关或持久格式。检查没有发现 prose substring 分类、新状态布尔拼装或把强制义务称为建议的问题。CI 按当前策略未查询、未等待；作者关于 CI 或旧集成运行的陈述不作为本次独立证据。

P3：中文新条目第 3 行的 Parent 使用英文 fragment #c43--settlement-adapters-over-existing-primitives，实际生成的中文目标章节 ID 是 c43-adapter。点击会打开目标页但不能定位 C4.3；最小修复是换成 #c43-adapter。这是低影响导航缺陷，正文及核心结论仍可读，不作为 approval blocker。应保留实际 HTML heading/href 检查，不能仅凭 strict build 通过判断锚点有效。

我的整体评价 / Verdict

这是 justified_increment：现在有证据放弃一个错误的收敛候选，且仍把真正的后续与完整删除资格留给原有 owner。long_horizon 为 preserved，减少误导方向的设计理由成立，但实际长程效果与完整成本未测量；user_experience 为 preserved，CLI 使用方式未改，P3 导航缺陷保留。兼容评估不适用：此 PR 未更改 decoder、持久格式或升级边界。局部简化已体现在撤回候选，无需强制新增公共 helper 或发明后续任务。

本次只改 RFC ledger 正文和索引；检查的文档路径没有布局、主题或首屏交互改动。未做整页视觉检查；实际 MkDocs HTML 的锚点检查属于自动验证。完整恢复矩阵、原生 Host 采纳及持续成本收益仍为 UNVERIFIED；这些不是本 PR 声称交付的成果。结论仅适用上述完整 exact head，approval 不表示 merge 授权或完整 C4.3 完成。

English verdict: APPROVE

[loopx-agent]

[P3] 使用中文目标的实际章节锚点

实际 strict build 的中文目标章节 ID 是 c43-adapter，这里仍使用英文 fragment #c43--settlement-adapters-over-existing-primitives。页面能打开，但不会跳到对应章节。请将 fragment 改为 #c43-adapter，并核对生成 HTML 的 heading 与 href。这是非阻断导航问题。