核心观点 上线不是流程的终点，是流程重新证明自己的地方。报障之后先定位，再分清性质——是只换数据源的修补、是画板已有但实现断了、是画板没有的新态、还是规则的例外——然后走对应的路径。分错类的代价不同：把新态当修补会绕过画板，把修补当轮次会浪费一轮审查。
Agent X-Ray 在 2026-09-02 投产。之后两天里发生的事比投产前更能说明这套流程的价值：所有者在真实站点上发现问题，报障，实现 agent 定位，然后走流程。
报障、定位、分类，然后在路牌前选路：修补、先画、开一轮。
投产前的流程是「设计稿 → 轮次 → 发版」；投产后多了一个入口：报障。报障进来的东西性质各不相同，处理路径也不同。第 08 章讲的三条扩边界路径在这里都会用到，还多一条：小修补直接进 main。
2026-09-03，所有者在生产上报两个现象：点 Skills 卡片经常没反应，点 Notes 有时也会；某个 skill 的详情页白屏，报「Application error」。
定位。 实现 agent 量了几个数：点卡片到 URL 变化 4.0 秒，界面完全静止；那个白屏的详情页 HTML 有 1.92 MB，服务端组件载荷 1.57 MB，要 5.6 到 7.2 秒；水合时文档没到齐，前端框架报了一个错误码后整页重渲，重渲出岔就是白屏。
两个现象同一个根因：全站没有任何加载态与错误边界——软导航在服务端返回前一个像素都不动，「没反应」不是崩溃是在等；而详情页把整包 markdown 全部预渲染，页面只显示一个。
分清性质。 这一步决定了后面走哪条路。任务卡把工作拆成三块，性质各不相同：
| 块 | 内容 | 性质 | 路径 |
|---|---|---|---|
| T1 | 详情页只预渲染当前文件 | 只换渲染时机，像素不变 | 规则 7 明确允许，不碰设计稿 |
| T2 | 加载态 | 画板上没有的新视觉 | 先画画板 2i、2j，再进轮次 |
| T3 | 错误态与找不到 | 画板上没有的新视觉 | 先画画板 2k，再进轮次 |
T2、T3 不是规则 8 的例外——它们走的是正道：所有者在画布上画了三块画板，拉回 design/，画板计数从 15 到 18，然后代码才动。给画布的提示词写明了「不新造视觉语言」「动效只在现有三个里挑」「骨架必须和真实内容对得上位」；画板带来的唯一新语汇是错误态的实心主按钮，由画板明确定为出口层级。
验证。 T1 的载荷降了九成，用 281 篇全量比对证明标题锚点零漂移；T2 用两组夹具把服务端渲染拖慢到看得清骨架，逐项对照画板；T3 在本机停掉后端复现「后端不可达」时发现页面级错误边界兜不住布局自己的错误——只有跑起来才发现的缺口，补了一层。
审查。 两轮，一条 P2（隐藏 tab 的 404 页主按钮指回自身），采纳，末轮零 findings。
从报障到合并 main 是同一天。流程没有因为「这是线上问题」而被跳过，反而因为线上问题有真实数字而更容易验收。
同一天，所有者核对画板时发现另一件事：会话区里没有工具调用卡。画板 1a–1d 和 1f–1g 的会话区一直画着两张（一张读文件、一张执行命令），而线上的会话区只有文字气泡。
首版有，某一轮切数据源时断了来源，下一轮删示例数据后成了死代码。
定位靠 git 考古。 首版按画板实现过这张卡；R3 把对话区切到真实数据源时只映射了角色和内容两个字段，卡片断了来源；当时内置工具全关、没有工具可显示，没人发现；R4 删掉示例数据后，那个组件成了死代码。ROUNDS.md、任务卡、BACKLOG 里没有一条「去掉它」的裁定——属无意遗漏。
分清性质。 恢复卡片本身不是新功能，与规则 8 无关——画板上一直有。但所有者提的两个态是画板没画过的：一轮跑完后把处理过程折叠成一行；卡片箭头点开的入参与结果摘要。这两个态按正道走：先画画板 2l、2m，再进轮次。画板计数 18 到 20。
落库形态跟着裁定改。 所有者裁定要做到「重新打开会话也在同一位置」——卡片不能只是实时渲染，历史回放也要有。于是一轮仍是一条助手消息，消息的 JSON 列里加一张工具调用的偏移表。这一列从第一个迁移起就留着，所以无迁移；旧行不回填，三天保留期自然清空。
验证。 本机开发库没有配任何模型 provider，用假的上游驱动真实内核跑了五个剧本，刷新前后会话区 HTML 的哈希一致。
审查。 两轮，两条 P2：一条测试夹具漏字段导致类型错误，采纳；一条「展开体超过六行时截断提示被裁切区盖住」属画板三条裁定互斥的设计取舍，写明理由记 BACKLOG。
这个案例最值得记的是定位方式：不是猜「大概什么时候没的」，是沿 git 历史找到断在哪一个提交，再确认没有任何裁定说要去掉它。定位的结论决定了它的性质——无意遗漏，恢复不是新功能。
不是每个报障都成一轮。投产前后有一批小修补，ROUNDS.md 用一张「修补记录」表记着：
| 日期 | 问题 | 处置 |
|---|---|---|
| 09-01 | 助手回复被当纯文本渲染，markdown 糊成一段；站点没有图标 | 合入 main，所有者裁定不走审查，预发升级实测 |
| 09-01 | 导航条没有 logo；右侧轨迹面板不跟随滚动 | 合入 main，所有者裁定不走审查；面板改为「贴底才跟随」 |
| 09-02 | 正文里的数学公式原样漏出 | 渲染器接公式库，按规则挡住散文里的货币金额；本地 226 篇全量跑过 |
| 09-02 | 进行中的轨迹行没有方向感；生成期间发送按钮仍可点 | 改成从左向右的扫光；按钮转圈禁用 |
| 09-02 | 文章页阅读进度线永远停在同一位置 | 照抄了画板定格的那一帧；接真实滚动，画板加注释 |
小修补的规矩：可以直接进 main，可以由所有者裁定不走审查，但必须记——ROUNDS.md 的修补表记一笔，发版时 docs/releases.md 记一行。「不走审查」要写「所有者裁定」，与「审查通过」区分开。
修补与轮次的分界不是改动行数，是有没有新的边界、迁移或机制。接公式库是修补，恢复工具卡并加两个新态是一轮。
三个案例合起来，报障的分类判据是一张表：
| 性质 | 判据 | 路径 | 实例 |
|---|---|---|---|
| 只换数据源或渲染时机 | 像素不变，画板不动 | 规则 7 允许，可以是修补也可以并入轮次 | R-PERF T1 |
| 画板已有但实现断了 | 画板上能找到，git 历史能找到断点 | 恢复，不是新功能 | 工具调用卡 |
| 画板没有的新态 | 画板上找不到 | 先画画板，再进轮次 | 加载态、错误态、折叠态 |
| 规则的例外 | 不是产品功能，是隐私、合规或运维需要 | 写明理由与边界，形态对画板偏离最小 | 会话删除入口、tab 呈现开关 |
分错类的代价不同。把新态当修补，会绕过画板——边界从此有了一个没画过的东西，下次再有人问「这个态长什么样」，答案只在代码里。把修补当轮次，会浪费一轮审查——审查配额和等待时间都是真实成本。把例外当正道，会把「这不是产品功能」的理由丢掉——下次有人拿它当先例扩功能。
所以分类这一步要慢一点。三个案例里，实现 agent 在任务卡开头都先写了一段「本轮的性质要分清」。
线上有真实数据之后，验证动作本身要小心：
线上问题跳过流程。 「先修了再说」，画板没改、审查没做、记录没留。三天后没人知道那块是怎么来的。
分类错。 新态当修补绕过画板；修补当轮次浪费审查。
定位靠猜。 「大概是上次改渲染的时候弄坏的」——git 历史能给确切答案。
修补不记。 ROUNDS.md 修补表和发布记录都不写，「不走审查」变成默认。
在生产上做可逆性未知的验证。 关掉一个开关之前先确认能开回来。
为最近一次线上报障写一张三段记录：定位（量到了什么、断在哪）、性质（四类里的哪一类、判据是什么）、路径（走了哪条、有没有留痕）。如果当时没分类就修了，补写「如果分类，应该走哪条」。
苏公网安备32011402012723号