来源：notes/documents/渠道开关实施记录：ticket_08_观测与验收对照（收官）.md

渠道开关实施记录：ticket 08 观测与验收对照（收官）

渠道开关实施记录：ticket 08 观测与验收对照（收官）

ticket 08（观测与验收对照）做完并推送：addda57。至此 .scratch/channel-switches/「用渠道开关取代 sensitivity」的 8 张 ticket 全部 resolved。报告落在仓库里：.scratch/channel-switches/report.md。

这一张不是改代码，是把「改动前后到底有没有变」钉死：五组数字、三个时点（改动前 / expand 后 / contract 后）、每一项差额的指认，以及每一格的证据来源。

一、五组数字

• contract 前后逐字节相同：/tmp/t08-post-contract.json 与 /tmp/t07-contract-after.json 是 Python 对象全等（含字段列表、每张表行数与 sha256、view_sql、integrity_check）。
• SQLite 列级对账：12 张表 + 1 个视图行数全同、共有列内容逐字节相同；唯一差异是 events / event_revisions / notes / note_revisions 与视图各少 sensitivity 一列，外加 schema_metadata 4→5。integrity_check=ok，视图 409 行。
• 日历对账：与仓库里存的改动前基线（config/calendar_parity_report.json，2026-09-22 16:33）比，两侧 unexplained 都是 0，only_calendar 16→15，总量 392→423 / 377→409（9-22 之后几天正常沉淀）。

二、差额逐条

1. +2 篇笔记 / +1 条事件：两条新笔记本身就是这轮改造的实施记录（ticket 01 重跑、ticket 03）；那条事件是 17:51 的 note sync 采集的「昨天到达重庆，今天到达库尔勒」。都在各目的地台账里有 target_id，属于当天新增内容，不是重投影漂移。
2. Neon 另 +1 篇：note_ffb6acf19cfe4547（03_dg板卡X5_BPU推理服务_飞书特供版）在 ticket 04 期间被 Base→本地反向回写从 archived 改成 active，于是满足日历视图规则、进入网页日程。这一条要你拍板，见 §四。
3. 日历改动前值只能是下界：对账报告只说明「删除不参与对账」，证明不了日历单调（投影侧确实会删 withdrawn 条目），所以只能给 ≤ 420。去掉不确定性的办法是看现在的投影结果：sync_daily_log_outputs.py --dry-run 报 to project 0 / up to date 409，两端已收敛。
4. Base 字段改名、publish_enabled 全量回填、版本号 4→5 都是计划内动作，不是漂移。

三、诚实声明（这张票最该记住的部分）

票面要求「任一不一致必须解释清楚，不许差不多」，所以把薄的地方也写明白了：

• 改动前的基线不是这张票现场存的。开工时 expand 与 contract 都已完成。#1 / #2 的改动前值是按当时数据推算，#4 是从旧代码读法推断；只有 #3（git 对象）与 #5（ticket 06 的 dump）是直采。改动前的远端 Base 快照没有留——这是整份对照里最薄的一格。报告 §一 对每一格标了来源。
• 因此清单第一项「改动前先存基线」只做到「用当时的产物与 git 对象回溯拼出 + 标注来源」。这是流程顺序造成的，不是遗漏，已作为第三条偏差记进票里待追认。
• 反向链路的证据边界：reconcile_inbound 的 5 个用例在 206 里全过，note_base_projection.py 的 8 个可回写字段在远端内容资产字段里全部存在（敏感级别 已不在）；但没重跑 ticket 04 那种真 Base 往返（要写远端），写路径的真实验证仍是 ticket 04 那次。
• 顺手发现：跑一次 render_publishable_daily_log.py（博客 payload 之下的读路径）会让 data/daily_log.sqlite3 的 sha256 变——变的是 SQLite 文件头的 change counter（打开时跑了幂等的 schema 初始化），12 张表内容逐字节不变。这也是这个文件经常在 git status 里显 modified 的原因。

四、需要你拍板 / 收尾的事

1. note_ffb6acf19cfe4547 被解锁：它 2026-09-19 被显式冻结（status=archived，正文写着「仅飞书，且已冻结不再同步」），ticket 04 的反向回写把 Base 里冻结前的旧值 active 带回本地，于是它现在出现在网页日程里。它本来就已经在博客上（2026-09-23 导入），不算新增曝光；但若恢复 archived + publish_enabled=0，--clean 导入会把这篇文章从博客撤下。两条路都动到用户可见面，本轮没有自行改。
2. 两处口径偏差待追认：ticket 02 的网页日线闸门是「删掉」而不是「换成渠道开关」；ticket 04 的「飞书文档」列只加在内容资产表，没加在日常事件V2。legacy「每日记录」表仍有「敏感级别」列（不在本轮 schema 范围）。
3. 下一件事还没 spec：用户已经定了「SQLite 不再出现在代码里、历史数据挪进归档目录（仍在个人助理仓库内）」，但 .scratch/ 里还没有这条线的 spec。

五、验收命令

• python3 -m unittest discover -s tests → 206 通过；cd web && npm test → 62 通过；npm run db:check 过。
• python3 scripts/calendar_parity_report.py --json --out /tmp/t08-parity.json → calendar_total 423 / local_total 409 / matched 408（全 ledger）/ id_stale 0 / unexplained 全 0 / ambiguous 0。
• python3 scripts/sync_daily_log_outputs.py --dry-run → local entries 409 (daily 277, note 132)、to project 0、up to date 409、Base 四表 changed=0、{succeeded: 3, failed: 0}。
• rg -n sensitivity scripts/ web/ tests/ 只剩迁移代码与其测试、历史迁移文件、supersede 叙述与一个用例名。