来源：notes/documents/日历条目 target_id 过期台账.md

日历条目 target_id 过期台账：65 条被重建过的日历事件

日历条目 target_id 过期台账：65 条被重建过的日历事件

2026-09-22。这是 ticket 10 的证据表：本地台账 entity_projection_state 里有 65 条记录的 target_id（写出去时的飞书日历事件 id）已经不在日历上——记录本身都在，只是当初的事件被重建过、 id 换了。2026-09-22 决定：全修（B），已执行完——65 条全部换成现行 id，复跑 0 条待修， 对账里的 id_stale 从 65 变成 0。执行的细节与一个副作用见文末「修复执行」。

结论

• 对网页没有影响：网页要的是「这条记录在日历上」这个事实，日期、标题、正文都来自本地， target_id 只是个「已经发出去过」的标记（docs/adr/0010）。
• 只影响两处：① 对账报告里 id 级永远显示 65 条对不上；② 将来若把某条重新改成要同步、 又改了正文，事件线会拿旧 id 去 patch 一个不存在的日历事件，记一行 failed（不会重复创建）。
• 65 条都有修复依据：64 条可以用日历描述里的「同步键」链式证明（现行事件描述里的同步键 = 老账 config/feishu_calendar_sync.json 里那条记录的 key，而老账给这条记录的 event_id 正是台账里的旧 id）； 第 65 条是笔记，现行事件描述里的「笔记ID」就是本地笔记 id。
• 分布：2026-09 1 条、2026-08 1 条、2026-07 16 条、2026-06 47 条。

为什么会过期

同一份内容在日历上今天是一条新事件（描述里还留着老账那条记录的同步键），而台账记的是老事件的 id； 老 id 已经不在日历上。证据链（以 2026-06-11 22:40「数据可视化」为例）：

• 日历现在那条事件的描述末尾：同步键：719263803120097aeaafcd1d；
• 老账 config/feishu_calendar_sync.json 里这个 key 的 app_link 带着 key=fb5908e2-…；
• 台账里这条记录的 target_id 正是 fb5908e2-…_0——而日历上没有它。

逐条追「为什么被重建」没有做（台账只留旧 id，没有事件史）。能确定的是：

• 这 65 条全部来自老账还在用的时期（老账覆盖 2025-11 … 2026-08），描述里的同步键都是那种 24 位 key；
• 台账状态：64 条 synced、1 条 failed（失败的正是 2026-09 那条笔记，它在日历上另有事件）；
• 换到 SQLite 事件线之后写出去的事件，描述里的同步键是 evt_xxx（本地事件 id），台账的 target_id 与日历对得上，没有一条是过期的——所以这是个历史遗留面，不会继续扩大。

三条路

建议 B。 一次性、可复算、可回退（改的是本地台账，重跑投影即生效）， 修完 id 级重合数从 168 升到 232 左右。

附表：65 条

「依据」一列：同步键 = 现行事件描述的同步键与老账 key 链上；笔记ID = 笔记线的现行事件。

2026-09（1 条）

2026-08（1 条）

2026-07（16 条）

2026-06（47 条）

同一批对账里的其他差额（都不需要动作）

• 「只在日历」15 条：11 条白名单（6 条本地从来没有记录 + 5 条 01-23 key 与 2025-12-17 歧义）、 4 条重复（同一记录在日历上有两个事件）。
• 「只在本地」1 条：2026-06-06 19:36 文档沉淀，本地有两条、日历只有一条。
• 「时刻不一致」20 条：19 条是旧脚本对「没有时刻」的条目用 12:00 兜底而本地记 00:00， 1 条是上面那条笔记重发（09:40 → 10:00）。
• 完整机器可读版本：config/calendar_parity_report.json；生成命令 python3 scripts/calendar_parity_report.py。

修复执行（2026-09-22，选 B）

脚本：scripts/repair_stale_target_ids.py（默认 dry-run、幂等、清单落盘 config/calendar_parity_stale_repair.json）。它只写证据指向这条记录本身的行：

• sync_key（64 条）：现行事件描述里的 同步键：K，而老账里 K 这条记录的 app_link 带的 key 正是台账里的旧 id；
• note_id（1 条）：现行事件描述里的 笔记ID 就是本地笔记 id。

结果：65 条全部可修、0 条认不出、65 行写进台账；复跑一次是「过期 0 条、写 0 行」。 对账复跑：matched_by 全走台账（371 条），id_stale 0，只在日历 的构成 {whitelist: 12, duplicate: 4}，没有没解释的条目。只改了 target_id， projected_revision / status / error 原样保留。

一个副作用（要知道，但已经处理）

修完之后顺手点了那条笔记的同步（note_cli.py sync --note-id note_ffb6acf19cfe4547）， 笔记线既有的撤回分支真的执行了：这篇笔记的 registry status 是 withdrawn（当年撤下的）， 以前撤不动是因为台账停在 failed；现在 id 修对了，撤下就成功了——飞书日历上 2026-09-19 10:00 那条 [笔记] dg 板卡 X5 BPU 推理服务：飞书特供版 被删掉了。

按「已发到日历的条目一律保留」（2026-09-22 定的规则）把它重建了回去：内容一字不差 （同一标题、同一描述、同一时间），只是事件 id 变成 3fb2c4ca-9c5b-4efd-b3b6-e171fc3c8e99_0。 台账里这条笔记的 target_id 也指到了新事件，状态仍是 withdrawn。它也进了对账白名单 （config/calendar_parity_whitelist.json），标注是政策差异、不是缺记录。

顺带浮出来一个要你拍的问题：现在代码里，withdrawn 的笔记会主动从日历上撤下（delete）。 这与「已发出去的一律保留」是冲突的。两条路：

• 保留（与规则一致）：把笔记线的撤回分支从「删事件」改成「只是不再跟踪」，日历上留着；
• 照旧（与 registry 意图一致）：标记为 withdrawn 的笔记就是该从日历上消失。

现在日历是「保留」的状态（事件已经重建）。真要改代码，一句话就行。