docs(rfc): record NoKV v0 envelope capacity and the 0.11.1 fence live qualification in the ledger

[wchwawa]

Goal And Delivered Outcome

• Goal/source and gap: The RFC's execution ledger (Appendix D, docs/architecture/rfcs/ledger/shared-goal-authority-state-provider-v0/) exists so that delivery records are files instead of an append cluster, but it holds no NoKV record. Two measurements therefore live only in PR bodies and a contributor's scratch directory: the capacity of the NoKV v0 single-envelope layout that [Design] Bounded NoKV authority layout: sealed 64-commit segments and an operation index replacing the retain-all 16 MiB envelope (owner decisions Q5/capacity vocabulary) #4727 argues from, and the live qualification of the incarnation fence that feat(coordination): fence NoKV authority publication on the workbench incarnation (NoKV 0.11.1) #4774 connected, which the approving review could not rerun for lack of a live NoKV owner. This PR adds both as non-normative ledger entries with their Chinese mirrors.
• Observable before → after, with the validation row that proves it: Before, git ls of the ledger directory shows one entry (the directory's own creation record). After, it shows three, and examples/docs-governance-smoke.py accepts the naming and the mirror pairing (static row). The fence entry cites a re-measurement made today on a stack that feat(workbench): bring up the LoopX Stage 2A stack from one command NoKV-Lab/NoKV#518 brings up from one command, on LoopX main 4bed6ed3d with a clean tree (real_backend rows below), so the record is reproducible by the maintainer rather than trusted from the author.
• Issue/task and intended base: Related to feat(coordination): fence NoKV authority publication on the workbench incarnation (NoKV 0.11.1) #4774 (merged), [Design] Bounded NoKV authority layout: sealed 64-commit segments and an operation index replacing the retain-all 16 MiB envelope (owner decisions Q5/capacity vocabulary) #4727 (design issue the capacity entry informs), Scoped review invitations and module stewardship #4069 (review scope: NoKV-plane evidence only). Base main.

Scope And Continuation

• Completed scope and remaining work: Complete within this scope: two entries (2026-09-19-nokv-v0-envelope-capacity, 2026-09-22-nokv-0-11-1-incarnation-fence-live-qualification) plus .zh-CN.md mirrors; no code, no RFC clause, no profile change. Deliberately not done here, because the ledger README makes entries records rather than reviewable evidence and the approving review on feat(coordination): fence NoKV authority publication on the workbench incarnation (NoKV 0.11.1) #4774 reserved these to the maintainer: removing the profile hold atomic_workspace_incarnation_publication_fence in authority_store.ts, and updating the RFC header baseline / §11.2 Stage 2A row / Appendix A wording from 0.11.0 to 0.11.1 (the fence entry records that inconsistency). One LoopX condition surfaced while measuring and is recorded in the fence entry: under macOS's symlinked TMPDIR every s2c2 ladder row fails with shadow_management_state_invalid because shadow_management.ts digests the runtime root with realpathSync while shadow_management.py digests os.path.abspath; a symlink-free TMPDIR passes and Linux CI is unaffected. I can open an issue with the reproduction if the maintainers want one.
• Slice boundary / successor: N/A with reason: docs-only, append-only history; reverting removes the four files and nothing else.

Validation

• Tested revision: 0eaf6576cfc437b149dae2e2bcd3c871892da2af
• Run state: finished
• Input classes: synthetic

Check kind	Result	Public-safe evidence / limitation
static	passed	python examples/docs-governance-smoke.py: ledger entry names match YYYY-MM-DD-slug, every entry has its .zh-CN.md mirror, the RFC carries Appendix D: Execution ledger. git diff --check clean.
static	passed	loopx canary premerge --from-git-diff --git-diff-base origin/main on the four changed files: gate passed, 3 direct checks, 8 catalog checks, 8 risk-profile checks, 1 boundary check, 0 failures, 0 manual holds.
real_backend	passed	The fence entry's measurement: complete 23-row authority_e2e_ladder on LoopX main 4bed6ed3d (clean tree, Node 22.22.3) against a single-node NoKV 0.11.1 owner built from 590d3a4bdc (the v0.11.1 tag) by NoKV-Lab/NoKV#518's up --build, etcd 3.7.1, digest-pinned RustFS, the released nokv==0.11.1 wheel (checksum verified): 22 pass, s2b.postgresql_conformance_live unverified (no PostgreSQL), s2c2.sustained_parity_soak pending as declared, privacy scan 0 violations; s2a.nokv_live_qualification reports 15 checks including stale_incarnation_fence_rejected and stale_incarnation_fence_left_generation_unchanged, final generation 3.
regression_parity	passed	Same stack, released nokv==0.11.0 wheel: s0 pass, s2a fails typed at helper admission (nokv_transport_protocol_failed), no publication reached the owner. A second stack on the moto fallback passes s2a with the same 15 checks.
manual	passed	Every number in the capacity entry was re-read from the original probe output files (in-memory 21,858-byte and 64 KiB profiles, live 64 KiB profile) rather than from earlier summaries; the entries contain no endpoint, credential, workbench name or local path.

• Coverage and gaps: The entries are prose; the static rows cover their format, the real-backend rows are the measurement they record. Not covered: the incarnation rotation itself (NoKV exposes no client-side retire verb; covered by NoKV's executor tests), PostgreSQL (not configured locally), the ten-day soak (declared pending).

See validation disclosure guidance.

Frontend / Visual Evidence

• UI impact: none
• Before: N/A
• After: N/A
• States and viewports shown: N/A
• Source data: none

Type of Change

• Bug fix
• New feature
• Breaking change
• Refactoring (no functional changes)
• Documentation update
• Test update

LoopX Area

• Control plane (goals, todos, quota, scheduler, registry, runtime)
• Benchmark boundary (adapters, runners, verifiers, scoring, evidence)
• Capability or extension (providers, adapters, skills)
• Public docs or presentation surface (README, protocols, dashboard)
• Build, packaging, installer, or CI
• Host or runtime integration

Technical Direction

• Direction / acceptance reference, when applicable: Shared Goal Authority and cross-host coordination; Stage 2A NoKV candidate records under the RFC's Appendix D ledger convention. No promotion, activation or normative change.

Shared-authority RFC fixture impact

• Production-scale fixture schema: unchanged.
• Semantic dimensions changed, or reviewed no-impact rationale: none; two non-normative ledger entries.
• Provider conformance arms run: not applicable to a docs change; the recorded measurement ran the NoKV live rows and the complete ladder (see Validation).
• Read-only legacy/file/PostgreSQL three-arm rehearsal (required for promotion, runtime-routing, or compatibility-projection changes): N/A, no promotion, routing or compatibility-projection change.

Boundary Checklist

• Neither the diff nor this PR body/comments/attachments disclose private state, credentials, raw traces or verifier output, internal links, or local machine paths (including .loopx/, .codex/goals/, and live ACTIVE_GOAL_STATE.md).
• I did not duplicate maintainer-owned benchmark work unless a maintainer split out a public issue for it.
• I kept the change scoped to the linked issue/task.
• I completed the visual evidence section for UI changes, or marked UI impact none.
• Every commit includes a DCO Signed-off-by trailer (git commit -s).

[wchwawa]

The macOS symlinked-TMPDIR condition recorded in the 2026-09-22 entry is now filed with a second, independent reproduction matrix as #4892 (same row fails under /tmp, /var/folders and a self-made symlink, passes under a symlink-free TMPDIR; control rows pass; Python abspath digest differs from the TypeScript realpathSync digest while Python realpath matches). The entry text is unchanged: it records the condition and points at the issue for the fix.

[huangruiteng]

1. 结论与目标对齐

我按 exact head 0eaf6576cfc437b149dae2e2bcd3c871892da2af 复核了四个双语 ledger 条目、链接的公开 issue/PR 以及 append-only 规则。把容量实测和 incarnation-fence live qualification 分成两个非规范条目是合理的；不过容量条目把原始 live run 的 NoKV 版本写错了，当前 head 不应进入 append-only ledger。

2. 证据链与条目边界

容量条目的英文第 17 行和中文第 13 行都声称 live probe 使用单节点 NoKV 0.11.1 owner。与之相反，条目自己链接的 LoopX #4727 明确记录：live rows 运行在单节点 NoKV 0.11.0 owner 上；同一 issue 还把 NoKV 0.11.1 定位为后续 publish-incarnation fence 的独立工作。

PR 描述也说容量数字是从 original probe outputs 重新核读，并未声明重新跑了一次 0.11.1 capacity probe。这个 PR 中真正针对 0.11.1 的证据属于另一个 incarnation-fence qualification 条目，不能反向改写 2026-09-19 容量测量的 provenance。

3. 验证证据

• uv run --extra test python examples/docs-governance-smoke.py：docs-governance-smoke ok。
• git diff --check origin/main...HEAD：通过。
• 公开来源交叉核验：#4727 明确写明 capacity live rows 使用 NoKV 0.11.0；NoKV #518 / LoopX #4774 支撑的是独立的 0.11.1 fence qualification。
• loopx pr-review --check-result：结果契约通过，verdict 为 REQUEST_CHANGES。
• 按 review packet 的 wait_for_ci=false，没有把 CI 状态作为本次判断依据。

Docs governance smoke 能证明结构与治理格式成立，但不会验证历史数字与 backend-version provenance 是否一致，所以它通过并不能消除该问题。

4. 阻断问题

[P1] capacity run 被归因到错误的 NoKV 版本。

请把英文和中文 capacity entry 的 0.11.1 都改回 0.11.0。如果作者确实另行完成了 0.11.1 capacity rerun，则需要给出可复核的 0.11.1 运行证据，并明确说明数字是否重测、是否变化，不能继续沿用 original-output 叙述。

这不是措辞偏好：ledger 采用 append-only 维护方式，错误版本一旦合入就需要另加 correction entry，且会让后续 bounded-layout 设计误以为容量/延迟结果已经在 fence 版本上复现。

5. 维护性与最终判定

本次 future-facing 检查认为“两条独立 ledger entry”这一拆分本身是合适的：capacity 记录 0.11.0 原始测量，fence qualification 记录 0.11.1 后续验证。只需修正双语 provenance，不需要把两条内容合并，也不建议新增锁死日期数字的 one-off smoke。

修正后请保持 EN/ZH 一致，我会基于新的 exact head 复核。

English verdict: REQUEST_CHANGES - the append-only capacity entry attributes the original NoKV 0.11.0 live measurements to 0.11.1 without citing a 0.11.1 capacity rerun.

[huangruiteng]

动机

我按 exact head 0eaf6576cfc437b149dae2e2bcd3c871892da2af 重新审阅了四个 Appendix D ledger 文件、#4727 的原始 capacity 记录以及 #4774 / NoKV #518 对应的 0.11.1 fence qualification。把 capacity 与 fence 分成两份非规范、双语、append-only entry 是一个完整且可回滚的 docs slice；问题仍是 capacity entry 的 provenance 与其权威公开来源冲突，因此当前 head 还不能作为历史记录合入。

改动思路

这组文档把两个不同时间、不同目的的测量分别落入现有 ledger：2026-09-19 entry 记录单信封容量、增长率和 O(history) 代价；2026-09-22 entry 记录 0.11.1 incarnation fence 的 live qualification、负向 0.11.0 pairing 与未覆盖边界。这个边界是对的，也没有借文档改 profile、RFC clause 或 runtime。

失败点不在结构，而在来源映射：#4727 明确写明 capacity live rows 使用的是单节点 NoKV 0.11.0 owner，并把 0.11.1 fence 定位为后续独立工作。当前 capacity entry 的 EN/ZH 却都写成 0.11.1，而 PR 正文又说数字来自 original probe outputs，没有提供新的 0.11.1 capacity rerun。

具体改动

关键内容讲解

• 2026-09-19-nokv-v0-envelope-capacity.md / .zh-CN.md：记录 16 MiB 单信封在两档 projection 下的终点、连续负载折算、live latency/traffic 与设计约束。这些数字本身与 #4727 一致，但 backend version 在英文第 17 行、中文第 13 行被写成了 0.11.1。
• 2026-09-22-nokv-0-11-1-incarnation-fence-live-qualification.md / .zh-CN.md：单独记录 0.11.1 fence、stale-incarnation 拒绝、moto pairing、macOS symlinked TMPDIR 条件以及明确的 non-goals；这部分没有发现同类 provenance 冲突。
• 四个文件合计 +196/-0，没有生产代码、schema 或 fixture 变更；uv run --extra test python examples/docs-governance-smoke.py 与 git diff --check 均通过。

对主干的风险

[P1] capacity run 被归因到错误的 NoKV 版本。 触发条件是读者把该 append-only entry 当作 capacity 证据：文档声称 0.11.1，而 #4727 的原始公开记录明确是 0.11.0。docs governance smoke 只能证明命名和双语镜像成立，不能证明历史事实，因此 green smoke 不会阻止错误 provenance 合入。

最小修复是把两份 capacity entry 的 0.11.1 改回 0.11.0 并保持 EN/ZH 一致；如果确实另做过 0.11.1 capacity rerun，则需要提供可复核的运行证据，并明确原数字是否重测、是否变化。不要把独立的 0.11.1 fence qualification 反向当成 capacity rerun。

我的整体评价

结论仍是 REQUEST_CHANGES。这不是要求扩大范围：两条 ledger entry 的拆分和整体内容结构都值得保留，只需修复双语 provenance。因为 exact head 与前次实质评审相同、blocker 尚未修复，本轮没有继承 APPROVE；我重新执行了当前 policy revision 7 的完整 docs evidence plan，结果契约也通过一致性校验。

English verdict: REQUEST_CHANGES - exact head 0eaf6576cfc437b149dae2e2bcd3c871892da2af still attributes the original NoKV 0.11.0 capacity measurements to 0.11.1; docs-governance smoke and diff check pass, but the append-only provenance must be corrected in both language mirrors.