docs(rfcs): record what the decision log can verify, not a status frozen at authoring

[songoow]

What was wrong

All ten dated rows in Appendix B of the semantic-vocabulary-convergence RFC carried an authorization status from the moment the row was written, while all ten changes were already on main. Eight said PR review pending. Two said kernel-maintainer approval required, not yet given — and one of those, the F1/F2 domain binding, has an explicit approving review from @huangruiteng on #4631.

A reader of main would therefore conclude the current goal_boundary migration budget of 16 is unauthorized. It is not.

The actual defect is the column, not the ten rows

Nothing updated the status at merge. Correcting ten rows without changing that only resets a clock that drifts again, so Appendix B now states what the column records and when it is updated:

1. The column records acts verifiable from the repository — the merge commit, and the approving review where one exists — not a status at authoring time.
2. A row is updated in the PR that lands the change, in the same diff.
3. A merge and an approving review are different acts and are named differently.

Why #4651's two rows do not say "approved"

It was merged by the maintainer in 02cc53bd5 while a CHANGES_REQUESTED review still stood, and no approving review exists. Whether a maintainer merge satisfies Section 5 for a budget raise is the maintainer's call; the row records the act and says so, rather than resolving it here.

This table has now been wrong in both directions. An earlier revision of one of these rows asserted an approval that did not exist, sourced from an instruction given outside the repository; review caught it and it was withdrawn. Leaving not yet given standing after the change landed is that same failure mirrored — both mislead a reader who cannot see what was said elsewhere, and both come from the column describing a conversation instead of the tree.

What each row now records

Row	Now records
Q9 on-demand inventory	#4494, merge 75fcd5556
B2 re-export hop	#4573, merge 6979d528b, approved
B3 repair · B3 budget	#4651, merge 02cc53bd5 — merge on record, no approving review
B1 rename invariance	#4614, merge 0a4917956, approved
B2 call-result binding	#4682, merge 14a766e50, approved
B5 consumer report	#4663, merge 736299027, approved
B0 stage separation	#4661, merge 2303ff033, approved
F1/F2 domain binding	#4631, merge 440b002fb, approved
cross_runtime values	#4662, merge 11b857dec, approved

Limit, stated rather than left implied

This is a prose contract with no check behind it. Verifying "no row claims pending while its PR is merged" needs GitHub state, which the smoke deliberately cannot reach, and adding a scanner for it would extend the apparatus #4447 has just scoped down. What is checked: the bilingual mirrors and the dated row sequence — both carry 10 rows with an identical date sequence.

Verification

• docs-governance-smoke ok
• semantic-vocabulary-drift-smoke ok (every ratchet unchanged; this PR moves no budget)
• tests/architecture/ 619 passed
• loopx canary premerge --from-git-diff — 0 failures, re-run after merging origin/main
• Merged origin/main (6 commits, none touching the RFC) before pushing

Refs #4447

🤖 Generated with Claude Code

[huangruiteng]

审阅对象：PR #4704，exact head 6e3252b9b5bad79c0ef79fde004a060ecce317d3（作者 songoow），base main，本次审阅该 exact head 的完整增量（2 files, +51/-20，纯文档）。

动机

这份 RFC 的附录 B 是一张决策日志，"Owner / approval"（负责角色 / 批准）一列原先记录的是撰写时刻的状态。结果是十行里有八行写着"PR review pending"、两行写着"kernel-maintainer approval required, not yet given"，而对应的改动其实早已在 main 上；读到 main 的人会以为当前的 goal_boundary 迁移预算上调尚未获批，而承载它的 #4651 已经合并。真正的缺陷不是那十行写错了，而是没有任何东西在合并时更新这一列——只改这十行等于把一只会再次漂移的钟重新对了一遍。

因此本次交付的不是"把状态改成正确值"，而是把这一列的含义改成可从仓库本身核实的行为：合并提交，以及（存在时）那条批准评审；并要求"谁让改动落地，谁在同一个 diff 里更新对应行"、"合并与批准评审是两种行为、分别命名"。这是一个完整、可独立审阅的切片：它同时修正了当前十行，并写明了未来的更新规则与其边界。

改动思路

没有任何机制改动，只动两份镜像文档的附录 B：

• 在表格前新增一段说明，声明该列记录"仓库可核实的行为"，并给出两条规则（同 diff 内更新；合并与批准分别命名），同时明确这条规则本身没有检查在背后兜底——验证"已合并的行不再声称待批"需要 GitHub 状态，而 smoke 刻意不触网，因此不为其新增扫描器，以免反过来扩张这个 tracker 刚刚收窄的装置。
• 十行逐行改写：给出落地的 PR 号与 merge 提交；仅在该 PR 确有批准评审时写"approved by @huangruiteng"。
• 对 #4651 这一行不做"已批准"的结论，而是如实记录：它在 02cc53bd5 被维护者合并，当时一条 CHANGES_REQUESTED 评审仍然成立、且不存在批准评审；维护者合并是否满足第 5 节对预算上调的要求，交由维护者判断。

这条"记录行为、不代替判断"的取向是本次审阅最看重的部分：整张表此前两个方向都错过——更早的一版曾凭仓库外的指示断言过一次并不存在的批准，被 review 拦下；而把"尚未给出"留在已落地的改动旁边是同一种错误的镜像。

具体改动

docs/architecture/rfcs/semantic-vocabulary-convergence-v0.md（+28/-10，英文镜像）与 docs/architecture/rfcs/semantic-vocabulary-convergence-v0.zh-CN.md（+23/-10，中文镜像）。两份镜像的改动同构：一段说明加十行改写。

关键内容讲解

• 该列的语义重定义：新说明把"授权"从对话状态改为仓库事实——merge 提交，以及存在时的那条批准评审。这使读者不需要仓库外的上下文就能判断一行是否成立，正是此前两次出错的共同根因（该列描述的是"对话"而不是"树"）。
• 十行的事实改写：逐一给出落地 PR 与 merge 提交。本次审阅独立核实了全部九个具名 merge 提交与七条"approved by @huangruiteng"断言：#4494 75fcd5556、#4573 6979d528b、#4651 02cc53bd5、#4614 0a4917956、#4682 14a766e50、#4663 736299027、#4661 2303ff033、#4631 440b002fb、#4662 11b857dec，全部与 GitHub API 返回的 merge_commit_sha 精确一致，且每条"已批准"断言都对应一条真实的 APPROVED 评审。
• #4651 那一行的显式保留：该行不写"approved"，而是写明"在案的是合并、不是批准评审"，并把第 5 节的判断留给维护者。这点对上了事实：#4651 有五条 CHANGES_REQUESTED、零条批准、于 2026-09-18 合并。这正是本次改动最有价值的一处——它记录行为而不替读者下结论。

对主干的风险

纯文档改动，无运行时、schema、CLI 或调度影响；回滚即回退两个文件。本轮在 exact head 上独立复现了 PR 声称的全部验证：docs-governance-smoke ok；semantic-vocabulary-drift-smoke ok；tests/architecture 619 passed；loopx canary premerge --from-git-diff 0 failures / gate passed；托管检查 5 success、13 skipped（文档路径过滤）、0 failures。两份镜像各 10 行、日期序列完全一致，且不再残留任何"PR review pending / not yet given"。

需要如实记下的边界：新规则是散文约定，没有检查在背后，作者已在正文明确写出这一点，因此未来仍可能有人写了待批状态就直接合并。本审阅的做法是不接受"结构化 smoke 通过"作为该列事实正确的证据：正因为 smoke 只能校验行数、日期序列与镜像同步，才逐条对照 GitHub API 重验了九个 merge 提交与七条批准。另：本 head 落后 main 三个提交，但这三个提交没有改动该 RFC，另无其它开启中的 PR 触碰该文件，故可干净应用。中文镜像在表格前比英文镜像多一个空行，渲染结果相同，属排版小瑕疵，不影响合入。

我的整体评价

结论是 APPROVE。这是我在本仓库见过的较高质量的一类文档修复：它没有停在"把十行改对"，而是修掉了会让同一错误复现的规则本身，并对修不掉的部分（需要 GitHub 状态的检查）明确写出边界而不是假装已覆盖。表中最容易被写成政治判断的那一处——维护者合并是否构成第 5 节批准——被如实降级为"记录行为、交由维护者判断"，这与仓库"证据优先、不代替判断"的取向一致。所有具名事实均经独立核实，仓库自带验证层与 premerge canary 在 exact head 全部通过；除一条排版小瑕疵外没有阻塞项。审批不代表合并授权；合并仍走 loopx-pr-merge，并且需要在该 head 未变的前提下重新执行。

English verdict: APPROVE - #4704 at exact head 6e3252b is a docs-only correction of Appendix B in both RFC mirrors that redefines the "Owner / approval" column to record acts verifiable from the repository (the merge commit, and the approving review where one exists), updates all ten dated rows accordingly, and states the update rule together with the honest limit that no check enforces it. I independently reproduced every claimed validation at the head (docs-governance-smoke ok, semantic-vocabulary-drift-smoke ok, tests/architecture 619 passed, loopx canary premerge --from-git-diff 0 failures, hosted checks 5 success / 13 skipped / 0 failures) and, because the structural smokes cannot validate the column, re-verified all nine named merge SHAs and seven "approved by @huangruiteng" claims against the GitHub API - every one matches exactly, and #4651's row correctly records a merge over a standing CHANGES_REQUESTED review with no approval rather than asserting authorization. Both mirrors carry 10 rows with an identical date sequence and no remaining pending-status text. No blocking finding; residual risk is the disclosed prose-only contract, plus a cosmetic extra blank line in the zh-CN mirror. Approval here is not merge authority.