detail.product-detail.7084–7089 直写认领与台账补登（已闭合）

认领人：波波　日期：2026-10-14　义父裁定：2026-10-14 11:55

性质：生产库直写事件的台账补登文档（只读取证已完成，本文档不改生产任何数据）

背景：小齐《detail键谱系与41条增量对齐-2026-10-14.md》指出 6 条

detail.product-detail.7084–7089 于 10-10 / 10-12 绕过应用直写库

（updated_by 为空；应用两条写路径 user_id 均必填 int 强转，git 无痕）。

一、取证结论（journalctl + DB 只读交叉验证）

⚠️ 时区口径：DB updated_at 为 UTC，服务器日志为 CST（曾因此偏 8 小时得出错误中间结论，已纠正）。

1. 7084 / 7085（10-10 10:30–10:45 CST 写入分钟）

• 该时间窗口内 SSH 登录者仅 100.64.1.88（macbook-pro，波波本机，RSA key SHA256:4TZx0msr…）。
• ✅ 波波认领：这两条为波波操作。

2. 7086 – 7089（10-12 10:55–11:15 CST 写入分钟）

• 写入分钟内波波本机（100.64.1.88）密集登录，产品线与文案风格与波波同期提交同域；
• 义父裁定（2026-10-14 11:55）：kailash-hotspring（100.64.1.84）是义父白天干活的另一台电脑，

且写入分钟该机持续在线 ⇒ 认领归属义父侧（hotspring 机器操作），波波账上不再挂记。

• 结论闭环，无需进一步溯源。

二、流程教训（入长期记忆，已同步）

🔴 ad-hoc 库写必须：留脚本（入库 git）+ 入台账 + updated_by 必填。

直写库的代价在本事件中全部兑现：

• updated_by 为空 ⇒ 无法经审计链追溯到操作者，只能靠 SSH 日志间接取证；
• git 无痕 ⇒ 无法复现当时写入的确切内容与意图；
• 台账无记录 ⇒ 6 天后（10-10 → 10-16）即成"无主变更"，小齐被迫做只读考古。

对照正例：fix_pkg_notice_text.py（7081–7083）留了脚本 + updated_by=1，

本次谱系对齐零成本。今后任何生产库写操作一律走应用层接口或留脚本入库——

新工具 scripts/backfill_detail_verified.py 已按此纪律实现（A 端 PUT、

admin JWT、updated_by 可审计、幂等、dry-run 默认）。

三、台账补登（已闭合）

三·五、P1-11 回填执行状态（2026-10-14 义父拍板后）

• scripts/backfill_detail_verified.py --commit 已于 2026-10-14 执行：

68 条 / 164 module 全部 200 OK，回读全一致（经 A 端 PUT，updated_by 可审计）。

• 回填后 C 端行为：存量 164 个模块的 textBlock 标题旁将显示「存量·时点待核」徽章；

后续运营按 content-seed 各条 expiry_note 精确覆盖。

四、不做什么

• 不删这 6 条数据（内容本身是一日游产品配置，业务有效）；
• 不回填 updated_by（改历史审计字段比留空更糟）；
• 不动 /srv/kailash/secrets/（纪律红线：只读不写）；
• 不在本文档出现任何凭据/token。

五、决策记录（已全部闭合，2026-10-14 义父）

1. ✅ hotspring 归属：义父白天工作机 ⇒ 7086–7089 认领归义父侧；
2. ✅ P1-11 存量回填：义父拍板，当日已执行完毕（68 键/164 module，回读全一致）。