如果一个产品能生成图片、视频、音乐、语音和文本，那就必须能举报其中任何一样。不是大部分。任何一样。
按钮在某些界面上是有的。这是另一回事，而这个差别很容易被忽略：内容筛查是按每条流水线手工接上的，所以有两个工作室完全没有筛查就上线了，直到一次审计去看才发现。同样的形态会把这次修复也一口口吃掉，一次一个被遗忘的界面。
每一个界面，以及一项为此背书的检查
现在，聊天回复、图片、视频、音乐、语音、语音转文字、文字转语音、翻译、画布产物、工作流结果、助手气泡和公开分享页上都有举报入口——网页端和应用端都是。
更重要的是，每次构建都会跑一项检查。任何导入了生成接口的文件，必须渲染举报入口、委托给带有它的组件，或者持有一条读者可以核对理由的豁免。它第一次运行就报出了六处真实缺口。这项工作补上的正是那六处。
随后，负责人打开正在运行的应用，又找到五处检查看不见的地方，因为它们躺在检查从不打开的目录里。这是问题里更糟的那一半——一个从没读过某段代码却在它旁边报告「零」的守卫——也正因如此，检查现在会写明自己的扫描根目录，并在其中任何一个不再解析时失败。
一个队列，以及就在这一行上的处理
分享页上早就有举报入口，写入的却是一张没人读的表：没有消费者、没有队列条目、没有通知。那些举报现在也会开一个真正的案子，旁边冻结着审核者需要的原文。
而处理动作在另一个页面上的队列，就是会被放着不管的队列。隐藏内容或结案，现在都在这一行上完成，结果会写回去，于是没有什么需要重新争论。