fix(reward-memory): reconcile live configuration and guide requalification

[huangruiteng]

Changing a private Reward Memory configuration invalidates its enablement receipt, but the settings catalog could still show cached verification and the recall CLI called the failure disabled. Operators and agents received no actionable recovery plan.

This change keeps the drift guard, makes the catalog reuse runtime admission validation, and separates desired automation/historical verification from effective availability. Stale or unverified bindings expose a shared configure-goal preview/apply/verify plan that retains the existing configuration pointer and complete Agent allowlist. Each command template requires an explicit invocation-registry binding, so copying it cannot silently fall back to the default registry. Applying still performs provider write/exact-readback qualification and registry synchronization; it does not automatically trust a changed configuration.

User entry points: CLI recall, quota/managed-Turn projection, status/Markdown, and the existing frontend capability configuration summary share these results. The existing editor already supports preview/reapply with the retained pointer and Agent list. No new frontend controls or bundle changes are needed: the existing summary renders the updated current projection. Lark continues to consume shared status; no new chat state owner is introduced.

Validation:

• 89 focused tests passed across Reward Memory, turn recall, outcome lifecycle, capability configuration UI contract and chat configuration API.
• Ruff and git diff --check passed.
• Negative cases cover drift, unverified/disabled bindings, missing configuration, and mismatched Goal/Agent/provider/isolation receipts. Reading recovery guidance performs no provider writes or registry mutation.
• Separately qualified local recovery through the existing owner, followed by one reviewed experience write, exact readback and an independent business recall. Private configuration, memories and receipts are excluded from this PR.
• No browser visual acceptance was run for the unchanged frontend renderer; no claim of improved decision quality is made from successful storage alone.

中文：私有配置变化后旧启用回执失效，但设置页仍可能误报已验证，召回 CLI 又将故障统一标为 disabled。本修改保留漂移保护，设置页复用运行时准入校验，区分期望配置、历史回执与当前可用性；失配时提供沿用原指针及完整 Agent 名单的共享 owner 恢复计划。CLI、managed Turn、状态与现有设置页共用投影，不引入新配置权威。89 项测试通过；本机已完成现有 owner 恢复、真实经验写入、精确读回和独立业务召回，私有材料不进入仓库。代码提交审阅，尚未宣称已部署。

[huangruiteng]

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

审阅 exact head：606105d0174c10ba378faaaf9af3ea2bde4089fd

动机

这个 PR 修复的是一个容易误导操作者的状态分裂：私有 Reward Memory config 一旦被编辑，runtime admission 已会因 digest/receipt 不匹配而拒绝使用；但 settings catalog 仍可能把历史 receipt 显示成“已验证”，显式 recall 又把所有 unavailable 情况统一叫作 disabled。结果是运行时在正确 fail-closed，操作面却看不出 drift 的真实原因和安全恢复方式。

我重点验证了两个反例：缓存 receipt 是否还能让 automatic recall/ingest 看起来有效；repair command 是否可能漏掉 invoked registry、泄漏私有 pointer，或在只读查看时产生 provider/registry effect。两者在当前 head 都被正确封住。

改动思路

resolve_goal_reward_memory_experiment 是共享的只读 admission owner：catalog 不再复制一套简化 receipt 规则，而是复用与 runtime 相同的 config digest、Goal/Agent、provider、isolation、writability 和 exact-readback 校验。投影明确分开 desired/historical 与 effective/current：配置意图可以继续显示，但 drift/unverified 时 effective availability 和 effective automation 必须为 false。

恢复不新增 authority。_enablement_repair 只生成 configure-goal 的 preview/apply/verify 模板，保留完整 Agent allowlist，且每条命令都把 --registry <invoked-registry> 放在 command 前并声明 required binding。真正的 provider canary write、exact readback 与 registry synchronization 仍只在既有 configure-goal --execute owner 中发生。

具体改动

• experiment resolver 增加 already-loaded Goal 入口，使 runtime 与 catalog 共用完整 admission 规则；stale/unverified 返回 typed reason 与 public-safe repair plan。
• repair payload 明确 commands_are_templates=true、automatic_apply=false，不包含 registry 实际路径、config pointer、provider URI 或 credential；disabled 状态不返回 repair。
• reward_memory_goal_policy_summary 增加 binding_status、effective_available、desired_automation 与历史/有效 verified Agent 的区分。只有当前至少一个 Agent 真正 available 时 effective automatic flags 才能为 true。
• agent-turn-recall 保留真实 unavailable status/reason；quota boundary、status projection 与 Markdown 传递同一 repair plan。现有 configuration catalog/frontend summary 消费新增 current fields，不引入新的 editor 或配置权威。
• exact head 上运行了 89 项相关测试（experiment、turn recall、outcome lifecycle、capability UI、chat configuration），全部通过；Ruff、git diff --check 与当前 origin/main merge-tree 通过。测试覆盖逐项篡改 Goal、Agent、provider、isolation、digest、receipt，以及 missing/disabled config 和 explicit registry template parsing。

对主干的风险

我没有发现 blocking finding。default-off 边界仍成立：未同时满足 enabled + experimental + exact Agent 时不会触碰 provider；explicit disabled 不提供 repair；只读取 catalog/status/repair 不会写 registry、花 quota 或产生 external effect。配置存在、历史 receipt 存在或 repair template 可见都不等于 capability 已启用。

剩余风险主要是我没有在本地对真实外部 OpenViking 服务重新做一次 qualification；独立证据覆盖了生产 CLI、真实本地文件 binding、test provider、exact readback contract 与 no-effect branches。该分支同样处于 BEHIND；虽然与当前 main（包括较新的 Reward Memory 改动）merge-tree 无冲突，批准不替代更新基线后的 exact-head readiness。

我的整体评价

这不是单纯换文案，而是把“期望配置 / 历史证明 / 当前可用性”重新对齐到一个 admission owner，并把恢复留在原有配置 owner。新增字段都是 derived projection，没有第二份可编辑状态，也没有让 guidance 冒充授权。代码量与故障成本匹配；未来向前看的最佳简化——移除 catalog 的缓存 receipt 真值——已经在本 PR 内完成，不需要再建新的 provider 或 recovery framework。

结论：对 exact head 606105d0174c10ba378faaaf9af3ea2bde4089fd 无阻塞问题，批准；合并前仍需更新 head 并重新走 readiness。

English verdict: APPROVE - The exact head makes live config and receipt admission authoritative across recall, catalog, and status while keeping recovery template-only and explicitly registry-bound; focused negative evidence passed, with live external-provider qualification and post-rebase readiness left as residual risks.

[huangruiteng]

已将分支同步到当前 origin/main，exact head 更新为 97ff03aa3183f1737255e4ef0c09d72b081de1cf。相关 Reward Memory 改动与主干最近合入的 application/recall receipt 改动无冲突。

本地重新验证：

• 目标验证集：89 passed
• 改动 Python 文件 Ruff：通过
• git diff --check origin/main...HEAD：通过
• 出站提交 author/committer：均为已验证 GitHub noreply 身份

PR 保持未合并，等待 exact-head review 与 CI。