docs(rfc): record Stage 4 keepalive and provider-binding decisions

[wchwawa]

Summary

• Add two open owner decisions to RFC Section 12 (English and Chinese mirrors), both raised by the review of test(authority): qualify Turn ownership with NoKV #3820 and both required before that canary is re-cut.
• Question 6: does the Stage 4 canary require Host lease liveness before admission (renew during Host execution and cancel on fence loss, an effect-owning fenced commit, or a hard Host duration bound), or does it stay a Stage 5 promotion hold? Section 11 asks the canary to observe "no external effect is duplicated" but does not name the mechanism.
• Question 7: how is a canary Goal's authority provider bound? The proposed answer is a goal-level registry record with an explicit TEST ONLY marker, published by the same owner as the authorization projection in question 2, instead of an argv guard selector.

@huangruiteng These are recorded as questions with proposed answers, not as decisions. Please edit the proposed answers in place if you prefer a different mechanism; the next #3820 re-cut will follow whatever this section says.

Issue Or Task

• Follows up the test(authority): qualify Turn ownership with NoKV #3820 change request (long-Host effect safety and argv-selected provider binding).

Validation

• Documentation only; no code or test changes.
• English and Chinese sections carry the same two items and the same proposed answers.

Type of Change

• Documentation update

LoopX Area

• Public docs or presentation surface (README, protocols, dashboard)

Technical Direction

• Shared Goal Authority and cross-host coordination

• Target base branch: main

• Direction tracker or promotion unit: Stage 4 canary preconditions

Boundary Checklist

• I did not commit .loopx/, .codex/goals/, live ACTIVE_GOAL_STATE.md, credentials, private benchmark traces, verifier output, raw agent sessions, internal document links, or local machine paths.
• 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.
• Every commit includes a DCO Signed-off-by trailer (git commit -s).

[huangruiteng]

Findings

没有阻塞或非阻塞 finding。两份语言镜像都把 #3820 暴露的两个 Stage 4 前置决策记录为待 Owner 决定的问题 + 拟议答案，没有把尚未实现、尚未授权的机制写成已交付事实。

已评审 exact head：bac26169eb0110aef52f59f736d23b9ed53ef335

动机

#3820 的评审揭示了 Stage 4 canary 设计中的两个真实空白。第一，现有 RFC 要求 canary 观察“外部 effect 不重复”，却没有规定长时间运行的 Host 在 lease 到期、Todo 被另一 Agent reclaim 后如何停止继续产生 effect；事后拒绝 settlement 不能撤销已经发生的外部副作用。第二，测试 harness 可以通过 argv 指定任意 guard，但这不是 Goal 级产品 authority binding，也没有说明谁有权发布 provider 选择。

本 PR 没有抢跑实现，而是把这两个问题放进 RFC 的 Owner 决策清单，作为 #3820 重新切分前必须明确的设计输入。这是合适的最小改动：问题本身属于架构决策，先固定责任边界和验收要求，再让后续实现服从决定。

改动思路

改动沿用 RFC 第 12 节现有的“问题 + 拟议答案”结构，并同步更新英文与中文镜像。Question 6 把 Host lease liveness 明确提升为 Stage 4 canary 的准入问题，列出三类可能机制，并给出倾向方案：真实 Host 在执行期间续租、fence 丢失时取消，同时用长 Host 过期/reclaim 负例作为验收证据。Question 7 把 provider selector 从 argv 测试便利迁移到 Goal 级 registry record，要求由 Question 2 所定义的 authorization-projection owner 发布，并携带 provider kind、store identity/lineage 和显式 TEST ONLY canary marker。

这一信息流是闭合的：#3820 review 提出风险，RFC 将其变成 Owner-visible decision，Owner 可以直接修改拟议答案，后续 canary re-cut 再以确定后的文字作为实现与验证边界。文档没有新增第二套 runtime authority，也没有改变现有 Stage 1–3 或生产默认路径。

具体改动

• docs/architecture/rfcs/shared-goal-authority-state-provider-v0.md:1407 新增 Question 6，解释 lease TTL、reclaim、旧 Host 外部 effect 与不可逆 settlement 之间的失败链；同时明确 bounded fake Host 不能证明真实 Host 的 liveness 行。
• 同一英文文档 :1419 新增 Question 7，区分 test-harness argv selector 与产品 authority selector，并为 Goal registry binding 提出 owner、provider、store lineage、TEST ONLY marker 及 fail-closed admission 约束。
• docs/architecture/rfcs/shared-goal-authority-state-provider-v0.zh-CN.md:1126 起加入语义对应的 Question 6/7。中文镜像保留了三种备选机制、拟议的 renew/cancel 方案、长 Host 负例、Goal 级 binding、发布 owner、store identity/lineage、TEST ONLY marker，以及“runtime 从 registry 而非 argv 解析”的边界。

关键内容讲解

1. Host liveness 不是 settlement-only 问题。 新文字准确指出：当 lease 已失效并被 reclaim，旧 Host 仍可能执行不可逆外部 effect；只在最终 writeback 拒绝旧 fence 并不能提供 exactly-once。因而 canary 必须验证执行期间的 authority 生命周期，而不只是 terminal settlement。
2. 负向验收被写成一等证据。 “长 Host → lease expiry → reclaim → fence loss cancellation”把隐含风险变成可运行的验收路径，同时排除 bounded fake Host 作为替代证据，避免 canary 只证明理想时序。
3. Provider binding 归属 Goal authority。 registry record 由 authorization projection 的同一 owner 发布，且缺少 TEST ONLY marker 时 shared-authority guard 不得准入。这比任意 argv guard 更接近单一 authority source，并为后续 provider promotion 保留了 lineage 审计面。

正向路径：Owner 接受或编辑 Question 6/7 的拟议答案；后续 #3820 re-cut 从 Goal registry 解析带 TEST ONLY 标记的 provider，在真实 Host 执行时持续 renew，fence 丢失即取消，并用长 Host reclaim 场景验证没有重复 effect。

负向路径：若 Goal 没有有效的 provider binding/TEST ONLY marker，shared-authority guard 在 admission 阶段 fail closed；若运行中的 Host 丢失 fence，Host 被取消而不是继续产生 effect 后只靠 settlement 拒绝兜底。文档还诚实保留这些为“拟议答案”，所以在 Owner 决定前不会误导读者认为机制已经 shipped。

对主干的风险

这是 2 个 public RFC 文件、+36/-0 的 docs-only 变更，不改变 runtime、schema、CLI 或默认行为，主干执行回归风险低。主要风险是双语语义漂移或把 proposal 写成 decision；逐段对照后，两份文档在问题、备选机制、拟议方案、authority owner 和 fail-closed marker 上一致，并且标题与正文均保持 open-decision 语气。

另一个残余风险是 Question 7 依赖 Question 2 尚未决定的 publisher identity；这里的写法是有意引用同一未决 owner，而不是偷偷定义新权限，因此适合作为决策依赖。后续实现 review 仍需验证 registry schema、publisher authorization、renew/cancel race 与真实长 Host 负例，不能把本次 docs approval 当作 runtime qualification。

验证结果：完整阅读两个 changed files 及其上下文；核对 #3820 的公开 REQUEST_CHANGES 原因；英文/中文语义逐项对照；git diff --check 通过；远端 4 个适用检查通过，Pages deploy 按预期 skipped；PR mergeable，当前 BLOCKED 来自 review/branch protection 而非冲突。

我的整体评价

APPROVE。 这是一项范围准确、价值明确的 RFC 修补：它没有用文档掩盖 Stage 4 尚未具备的能力，而是把 effect safety 和 provider binding 的缺口变成可由 Owner 决定、可被后续实现验证的具体合同。两份语言镜像一致，和 #3820 的评审证据吻合，也没有扩大为未经授权的 runtime 变更。本 review 不授予 merge 权限。

English verdict: APPROVE at exact head bac26169eb0110aef52f59f736d23b9ed53ef335. The bilingual RFC update faithfully records the two unresolved Stage 4 prerequisites exposed by #3820—long-running Host lease liveness and Goal-level provider binding—without presenting either proposal as shipped behavior. Both language mirrors are aligned, git diff --check passes, and all applicable checks are green. This approval does not authorize merge.