CGL SCRM / defects
缺陷台账
发现 · 修复 · 判据
这一页是「账本」
13 个已经修好的问题，6 个还等决定的。
之所以把「修过什么」也列出来，是因为这张表本身出过一次错，而且那次比问题本身更危险—— 见下。
13
已修复
且线上已生效
6
待决定
多为业务判断
8
留下的经验
都已写成自动检查
待决定的 6 件
这些不是「还没修」，而是修了会改变用户看到的东西，所以需要业务上先拍板。
| 事项 | 为什么还没动 |
|---|---|
| meeting_status 恒 0（桩列） | 源站只有是/否 ⇒ 无更细状态机。启用前必须先定「申请→状态」映射并补写入侧 |
| signup_count / checkin_count 失真为 0 | 绕过 ORM 的报名写入没有回填这两个计数列 |
| REG_CHANNEL_LABELS / ISADD_LABELS 等刻意未接线 | 接线会改变用户可见行为 = 产品决策；SUBSCRIBE_SCENE_LABELS 源站零证据 |
| 迁移把 dev 种子带进生产（28 表 / 76 行） | 已清 52 行；保留 24 行是 B 类配置（score_rule 12 被 lead_service 读，清掉 = AI 打分静默失效） |
| /api/v1/health 无鉴权却回 lead_total | 摘要写明「无需鉴权」是有意的；收窄属公开 API 契约变更 |
| data/uploads/ 孤儿在累积（dev 专属） | 闸门只守 69 张表、不守 blob 目录 ⇒ 「无残留 ✓」覆盖面比读起来窄；生产走 COS，零正确性影响 |
已修好的 13 件
| 问题 | 怎么回事 / 怎么修的 |
|---|---|
| 台账过期比缺陷本身更危险 | audit_status 早已修复、线上已生效，台账却还记着它是坏的 |
| 生产二维码是 dev 种子假码 | qr_seed_rows 归零，重新出码 |
| 线索池把 14 个下拉压成文本框 | 指纹 YN_LABELS 零引用 ⇒ 判定「这是一条没接完的线」，已接线 |
| dev_seed 捏造的 capacity 污染生产真实活动 | 🔴 「列级污染」逐行计数清理看不见 —— 只有逐列问「这列值来自种子吗」才抓得到 |
| 导出「字段→字面值」写两遍、各漏一边 | 已合成 format_export_value() 单一真源 |
| 导出 xlsx 必 500 | openpyxl 不在依赖清单 ⇒ 闸门打到路由 ≠ 测过每个分支 |
| MCP 状态码图例手打错 | 6/7 写成「有意向/已合作」⇒ 模型静默拿错数据。已改为从真源渲染 |
| QR_ACTION_* 零引用、字符串被手打 8 处 | 已接线 + 守护 |
| 测试只写不删、污染共享 dev 库 | 代价不是「脏」，是把「与记录基线对不上」这条最好的诊断信号弄哑 |
| 第三份过期生成物 docs/SERVICE_REFERENCE.md | 升级为第 9 道闸门 check_generated_docs.py |
| 一个零证据的统计口径漂到交付物里 | 把「状态分布」（快照、无递进）讲成了逐级递进的口径；已发给客户的 v1.1 PDF 里也有。修 5 处 + 3 守护 + 重生成 v1.2。⚠️ 那四个字的原词在此刻意不复述——对外文件一律不出现（有守护 test_no_zero_evidence_funnel_wording_in_outward_files 拦着，本站的产物也在它的扫描范围里） |
| 交付物在教用户用一个打不开的域名 | 手册/技能包/说明全指向未备案的默认域名 ⇒ 统一为 scrm.jxccwx.com，加 3 条守护 ⑦⑦b⑧ |
| 4 个写库脚本零库闸门 | create_account 能改管理员口令、issue_token 能签 token:admin ⇒ 判据收成一份 + 2 条守护（首跑就找出我自己漏的两个） |
那张表自己出过的错（单独讲，因为它最典型）
有一件事早就修好了、线上也已经生效，但台账里还记着它是坏的。
后果是：后来有人照着台账去查，查了半天发现代码根本没问题—— 浪费的时间还在其次，真正危险的是它让人开始不信任台账。 一份不可信的账本，比没有账本更糟。
所以现在的规矩是：修好了要立刻回写台账，台账本身就是一件要维护的东西。 「台账过期」被单独列成一类问题，跟「代码有 bug」同等对待。
后果是：后来有人照着台账去查，查了半天发现代码根本没问题—— 浪费的时间还在其次，真正危险的是它让人开始不信任台账。 一份不可信的账本，比没有账本更糟。
所以现在的规矩是：修好了要立刻回写台账，台账本身就是一件要维护的东西。 「台账过期」被单独列成一类问题，跟「代码有 bug」同等对待。
8 条经验
每一条都不是「最佳实践」这种空话，而是这套系统里真出过一次事之后留下的。 而且基本都变成了自动检查——不靠人记得，靠机器拦。
1
守「自己这一侧」不够，要守「交付物那一侧」
前八次「同一事实写两遍」的守护都在仓库内部，而这一份错的已经发出去了（手册 PDF）。
2
一条能变红的扳机 > N 条各管一段的清单
做不到「能变红」的守护，等于不存在。
3
突变没变红，先怀疑突变本身
一次 heredoc 语法错让突变根本没注入，而测试照样「1 passed」—— 标准的假绿。
4
自查用的正则也算「守卫」，它一样会覆盖面不足
本轮用粗正则找库闸门，误报了一个其实有闸门的脚本。
5
基准钉在「外部权威」上
判断「该用哪个域名」不看哪份文档看起来权威，去看系统自己
self-report 的值。6
会给未来留下漂移源的事实，最好的处置是别说
邮件里「10 页」实际一直 11 页 ⇒ 改成不写页数；而必须在多处写的事实就要立守护（「N 个工具」）。
7
「原站没有」与「我们没导」在计数上长得一模一样
都是 0。写「缺什么」之前，先回源站找那个字段。
8
不编造
原站没有的字段就不填。猜错的台账比空着的台账更坏。
三类反复出现的问题
修过的问题里，有三类是换了个地方又出现的。所以处置不是「修这一处」， 而是去找所有同类的地方。
同一个事实写了两遍
出现次数最多的一类。两份副本会各自变化，然后对不上。
处置：先合并成一份，别先争哪份对；改措辞前先找齐所有副本——包括自己写的注释和生成器的说明书。 （生成器说明书里手打的「195 条路由」就是这一类——真值是 199。 同一次现抽还查出：闸门道数「十道」实际 11 道（连闸门脚本自己打印的都是旧数）、 被审计模块「57 个」实际 68 个。三个都出在最该准的地方。）
处置：先合并成一份，别先争哪份对；改措辞前先找齐所有副本——包括自己写的注释和生成器的说明书。 （生成器说明书里手打的「195 条路由」就是这一类——真值是 199。 同一次现抽还查出：闸门道数「十道」实际 11 道（连闸门脚本自己打印的都是旧数）、 被审计模块「57 个」实际 68 个。三个都出在最该准的地方。）
本机好、线上坏
两套环境走了不同代码路径。踩过八次。
处置：动了数据、类型、时间、密钥的改动，必须单独再跑一遍真对线上的检查。
处置：动了数据、类型、时间、密钥的改动，必须单独再跑一遍真对线上的检查。
检查本身不灵
有检查写着，但其实测不到东西；或者一直是红的，久了没人看。
处置：每条检查都要先证明它「会变红」；新写的守护要先把旧问题重现一次。
处置：每条检查都要先证明它「会变红」；新写的守护要先把旧问题重现一次。
为什么这一页放在最后：
前面那些页讲的是「系统有什么」，这一页讲的是「我们在哪里栽过」。
从演示的角度，后者往往更能说明这套东西是真的在跑——
只有真用过、真出过事、真改过，才会有这样一份账本。