Memory 渐进式披露重构

project-blueprint 阶段二 | 设计事实见 DESIGN.md | 待用户确认后进入实现

一、方案升级：从「一次性重构」到「体系」

✅ 用户关键要求（2026-08-07）：只重构不立规范，auto-fixer 下次写入就会退化。方案升级为三件套：

二、写入规范（②）— 进 memory 前必过判断

1. 7天后还需要吗？ 2. 已有skill覆盖吗？ 3. 是事实还是指令？ 4. 单条≤80字吗？(否则指针化) 5. 是项目状态/环境配置吗？(→refs/)

教训类→允许写MEMORY ✓ 但：每条≤80字(超出进refs/lessons.md) 同类教训7天最多2条(超出合并趋势段) 写入前调用同一套F10判断

三、每日审计（③）— 定时扫描 + 源头改正闭环

集成到 unified-daily.py 流水线第 7 步，每天扫描 MEMORY.md + USER.md：

每日扫描 → 发现疏漏 → ①修正数据(memory) ②定位源头(auto-fixer/分类器/会话习惯) → 修改源头规则 → 次日扫描确认不再产生 → 闭环完成

📊 审计结果展示在 unified-report.pages.dev 新增「Memory 治理」段：条目数/字符数/当日修正/疏漏类型分布。

四、三级分类处置（① 重构）

级别	处置	MEMORY	USER
A 每轮必需	保留精简	5条+2修正	10条
B 低频	指针+refs	6条→指针	0
C skill覆盖	删除+触发链评估	4删+2改B	0

触发链修正（2026-08-07 实证）：识图优先CC（高触发风险）→改B级指针；CC额度（中风险）→留一行指针；其余4项触发链可靠→正常删。

四、任务闭环机制（③ 延伸）— 所有任务必须有明确结果

🔴 用户关键洞察（2026-08-07）：CC 额度重置触发词 skill 不存在不是个例——病根是任务没有闭环。额度重置机制"计划了但没落地"，待办看板 9 项全部缺 result 字段，任务不了了之，靠口头触发。

规则	内容
① 明确结果定义	任何待办进入看板必须带：完成标准（验收点）或删除标准（什么算放弃）
② 状态变更记录结果	completed→附 result；cancelled→附 reason；pending>30天→标 stale 询问"继续还是关闭"
③ 禁止不了了之	只有 4 种终态：completed(有结果) / cancelled(有原因) / merged(合并到X) / stale(确认放弃)

data.json 新增: result / reason / closed_date 字段 update.py 新增: close <id> <result|reason> 命令每日审计 A7: 扫描看板标记 >30天无更新 pending 为 stale

五、验证方案（改完必须验证）

✅ 冷启动实验已实测（2026-08-07）：真实子代理「只看到指针+用户说继续车贷」→ 第1步主动 read_file → 渐进式披露机制实证可行；指针断裂时如实报告不编造。

🧠 Memory 渐进式披露重构 + 治理体系 — 设计方案 v2