[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