feat(consolidation): resolution=auto_v1（规格 C）

ARCHITECTURE.md

@@ -201,6 +201,12 @@ Scheduler 的独立单工作线程执行 Maintenance，不占学习、模型探
 
 按 DECISIONS 2026-10-10，矛盾与派生依据复核只有报告和标注路径，不写正文／相信程度，不重复 M2 扣减。`consolidation_annotations` 持久记录建议类型、来源、相关记忆／替代目标、写入时修订与报告 ID；同结论唯一键去重，管理员确认／清除是元数据。建议只进入管理详情与报告，即使已确认也不进入宿主 prepare/search；详情按当前修订与标注修订比较显示“标注后已修改”。报告明确标为模型建议并附源消息摘录。
 
+`resolution=auto_v1` 是第二种处理方式（设置项，默认仍是 `report_only_v1`，未知或旧值一律归一成 `report_only_v1`，运行快照固定）。模型只给判断和互有细节的合并草稿，分数、生命周期和标注由代码按规则写：推断档 `belief=min(belief,49)`，降一档到设计 10.1 下一档上沿，进入遗忘 `lifecycle=forgotten, retention=min(retention,F-1)`。`evidence_trace.py` 沿 `sources` 追溯原始消息（防循环，不经过失效依据），只追溯到 self_output 的依据不算独立。工作开始时人工编辑或置顶的记忆记为 `protected`，不调用模型。矛盾按规格第 4 节核对后执行 supersedes／reported_vs_self／coexist／undecided，核对失败一律 undecided；依赖按追溯到的不同原始消息计独立依据（目标记忆自己直接引用、不是 self_output 的消息也算），0 条进入遗忘并标 `insufficient_support`。每项自动处理写自己的标注（去重键含运行和工作），已清除的旧标注不会吞掉新标注。互有细节的对先由确定性检查核对草稿（双方独有片段、数字、否定、限定、主体引用、时间、实体，以及全部词项——含“已经、想、过”等功能词，去掉标点和连接词——必须正好等于双方词项的并集），失败记 `mutual_merge_rejected` 和固定原因，保持两条、不写建议；通过后存续记忆写新正文（修订号＋1，清向量），另一条按既有合并路径标记。`memory_revisions.reason` 用固定枚举（`auto_superseded`、`auto_reported_downgrade`、`auto_insufficient_support`、`auto_merge`、`auto_merge_mutual`、撤销 `auto undo`）。跨对互不连带：`blocked` 只含共用记忆的矛盾——判为 undecided 的，以及已判为矛盾、但因预算耗尽或调用失败还没处理完的对。同一运行内依赖链上较早的自动处理使祖先记忆变化时，不把下游工作判为过期，规则重新读取当前状态。
+
+auto_v1 的初判使用 `consolidation_pair_auto_v1.md`（report_only 仍用 pair_v3）。模型的 reason 只作记录：通过现有引用核对就展示，否则存档为 `archived_reason`，报告改用由已核验字段生成的确定性文本，结构结论不因 reason 失败。evidence、keep_id、old_id/new_id、依据 ID 写成文字时，只有能唯一对应材料中可见的整数 ID 才转换，绝不猜测；类型错误、缺字段、多余字段和不合法 ID 走一次机械修复，修复后重新做全部授权核对。初判为 merge 但独有片段不是正文子串时，把不合格片段和两条正文发回纠正一次，仍不合格才降级；初判为 conflict 的对不受片段检查影响，照常进入关系判定。规划时因可见范围不同而分开的相关对，与被替代记忆的跳过一样，按运行汇总记录（`skip:visibility_differs`）。
+
+撤销：`POST /admin/api/maintenance/{run}/consolidation/{work}/undo`（管理员会话和 CSRF，带 `expected_revision`）。每项自动处理在 `maintenance_items.details_json.undo` 保存逐字段的前后值，合并还保存继承的来源、标签和重定向的依赖边。撤销前逐条核对修订号和被处理字段（retention 不加修订号，按差值还原），有任何变化返回 409，不部分撤销；撤销时这次处理引起的依赖损失未扣减的取消、已扣减的按原子增量退回，正文还原后依赖边跟到新修订，不再被当作依据被更正；被并入的占位由迁移 037 的 `consolidation_undo_guard` 在同一事务内放行。`superseded_forgotten`（memory_ops）让被替代且遗忘的记忆再次确认时只追加来源、记录弃项 `superseded_no_restore`；`adjust_retention` 的恢复转换也统一拦截（宿主反馈、入口画像确认／准入、阈值调整后的衰减），保留强度照常增加但不自动恢复有效。只有管理员恢复和撤销清除标注、解除限制。上述限制只认 auto_v1 规则执行后写的标注（迁移 037 的 `consolidation_annotations.automatic=1`），report_only 的模型建议不算，旧数据默认 0；每日衰减阶段被拦截的恢复记为 skipped（`superseded`），不写变化记录。含未清除 superseded 标注且处于遗忘的记忆不进入配对（broad 合并、互有细节合并和 report_only 的合并建议都适用），规划时跳过、不调用模型，本次运行汇总记为 `skip:superseded_member`；恢复或撤销改变快照后重新进入整理。
+
 `maintenance_persona`（迁移 019）把 run_id 与 persona_attempts 原子关联。先用 persona_due 判断到期，再在同一短事务预留既有 persona 尝试及关联，复用 PersonaEngine 的带 attempt_id 执行入口，保留 only_if_due、版本 CAS、依据检查和发布策略；不另建发布路径。恢复时终态尝试只补报告，queued 尝试可继续，已 running 但未完整结束的尝试记录 interrupted，不重放生成、不发布部分结果。persona 的监管设置与发布方式沿用该模块在接受尝试时的快照。
 
 迁移 019 保留原 `consolidation_calls` 行，允许 persona 调用的 work_id 为 NULL；`maintenance_persona.attempt_id` 提供尝试关联。每个实际 HTTP 尝试在调用前独立预留一行，按步骤计入运行快照的调用上限；persona 使用独立的 `persona_max_calls`（默认 30，范围 0—1000），不占用其他步骤额度。记录用量、耗时、结束原因、推理档位，异常中断保留未知用量。persona 外层健康预检不占调用，内层 Gateway 的每次重试才占一次；生成及其修正至少须余两次，给检查留下一个名额。persona 发布仍须完整检查通过，修正／重试耗尽则留待后续整理。所有模型调用仍写原 model_calls，用于共同每日 token 限额与用途健康。

README.md

@@ -756,6 +756,23 @@ prepare 和 search 为每条最终返回的记忆追加 `subject_annotations`，
 
 依据 DECISIONS 2026-10-10，矛盾和依赖复核只生成**模型建议**及可撤销标注（争议、依据不足、被某条记忆替代），不改正文、相信程度或删除对象，不重复 M2 的保留强度扣减。材料附双方来源摘录，每条最多取最早一条与最近三条，各最多 300 token。建议只在管理员整理报告和记忆详情中显示，附来源供核对；可采纳为“已确认”或清除，重复结论不重加，之后正文修订显示“标注后已修改”。未确认和已确认的建议都不进入回复准备或查询返回。置顶及人工编辑的记忆也可收到建议。
 
+设置页“梦境整理”可选择处理方式。默认仍是“只报告”（`report_only_v1`）；选择“自主处理”（`auto_v1`）后，互有细节的合并、矛盾和依赖由模型判断、程序按规则直接处理，不等管理员采纳：
+
+- 互有细节：模型写合并正文，程序逐项核对（双方独有细节、数字、否定、限定、主体、时间、实体，正文用词必须正好是两条原文用词的并集，“已经、想、过”这类词也不能增删），不通过就保持两条并记录原因。
+- 矛盾：本人明确更正时旧记忆标“已被替代”、相信程度降到推断档并进入遗忘；本人说法与他人转述冲突时转述降一档；历史与当前并存时不动；无法判定时两条都保留并标争议。依据只有角色自己发言的按无法判定。
+- 依赖：剩余依据里追溯到的独立原始消息为 0 时进入遗忘，至少 1 条时不变；记忆自己直接引用的他人消息也算。角色自述不算依据。
+
+模型写的理由只作记录，不影响处理：理由引用不实时，报告改用程序根据已核对的字段生成的说明。人工编辑和置顶的记忆不动，不调用模型。每项自动处理在整理报告里列出结果和“撤销此次处理”，处理之后记忆又被修改时撤销返回 409，不部分撤销。被判定“已被替代”并遗忘的记忆，再次确认只记录来源；宿主反馈、入口画像和每日维护可以提高它的保留强度，但不会让它自动恢复有效。只有管理员恢复或撤销能解除。这类记忆也不参与合并或合并建议，恢复后才重新进入整理。以上限制只针对自主处理写下的“已被替代”，只报告模式的模型建议不影响恢复和合并。撤销时，这次处理引起的依赖保留强度扣减也一并取消或退回。
+
+公开集 `evals/consolidation_v2.json` 的运行和计分：
+
+```bash
+uv run python evals/consolidation_eval/run.py --method broad --resolution auto_v1 --out <仓库外目录>
+uv run python evals/consolidation_eval/auto_score.py --materials <目录>/materials --detail-judgments <第一轮> --detail-judgments <第二轮> --judge-model <判分模型> --out <报告目录>
+```
+
+`--corpus` 可换外部语料；误处理、正确处理、保护和写回损坏由代码计算，合并丢细节的判分说明见 `evals/consolidation_eval/merge_details_scoring_auto_v1.md`，不提供判分时该项为 null。
+
 persona 在记忆整理后调用既有到期判断：自上一版至少五条自我记忆新增／变化，或满七天且有变化；“待更新”的依据计入变化。只在生成候选、逐句检查和版本／依据校验全部通过后发布，变化大时默认待管理员确认，仍遵循 persona 的 `small_medium_auto / all_auto / all_manual` 设置。未到期、缺模型、用途暂停、每日 token 限额或预算不足都有报告状态，原版保持可用。目标复核随后逐目标检查内部依据的当前状态，添加／结束依据标注，保留目标正文和状态；过期沿用目标模块按截止时间的只读标识，不自动完成或放弃。
 
 入口画像、记忆（合并／矛盾／依赖）、人物摘要和 persona 分别使用自己的每轮调用上限，互不占用；HTTP 重试和 JSON 修正均逐次计入所属步骤。每日 token 限额、用途暂停和停止信号优先于各步上限。某一步耗尽额度只停止该步，后续步骤仍可运行，但仍须通过共同的停止条件。记忆任务按重要度降序、变化时间降序、ID 升序处理，未完成留到下次。persona 和人物摘要开始生成前须在自己的额度内留出生成、检查各一次；生成重试／修正仍须为检查保留一次，预算中途不足或检查失败不会发布部分候选。目标复核不调用模型，预算耗尽或模型暂停仍能执行。无 gateway 的离线调用跳过模型阶段，确定性维护和目标复核照常。中断后已完成项目不重做；已完成 persona 尝试可补回报告，不重新生成，未完成尝试标为中断后留待下一次整理。