R2.12.2write implementation issues back to the design source设计
实现中的问题需回流修改设计源
别名: 问题回流设计源 · 设计源同步 · source-of-truth patch-back
概念解释
建造时发现的对不上、做不到、或必须改的交互，要写回设计源（正在被当作下一版起点的那份文件），而不是只改代码里的那一处。代码里的补丁让这一次能发；设计源里的同一处不改，下一次仍会从旧意图开工。
回流针对的是会改变界面意图的问题：缺的状态、改过的结构、换掉的文案、平台做不到的动作。压缩图片、懒加载这类不改界面意图的实现细节，不必进设计源。
机制
下一次改动会打开设计源，而不是先去翻上次的提交说明。两份源头并行时，设计源保持「应当如此」，代码保持「实际如此」。下一张稿从应当如此画起，实现再对一次实际如此，同一场冲突被重演。回流把建造中谈妥的结果写进源头，下一次打开的就是已经吸收过约束的版本。
只在聊天记录或工单评论里留下「我们最后改成那样了」，对设计源等于没改。新来的人、隔了几周的自己、另一个平台的实现者，都只会复制旧图。节奏上的浪费不是发现问题时多花的那次讨论，而是讨论结果没有回到源头、下一轮再付一次。
边界
一次性的、明确不会再被打开的活动页，代码里改完即可，回流的收益低。正在被整页替换、本轮结束后旧文件会归档的源，往旧文件上回流是错对象——应写进将要接替的那份。纯性能或打包选择如果不改变布局、文案、状态或操作，硬写进设计文件只会制造噪声。多份设计源并存（平台分文件、实验分文件）时，回流必须打到实际被下一次使用的那一份，打错文件等于没回流。
怎么落地
- 实现发现的界面意图变更，与代码修改放在同一张票里，关闭前必须改设计源；只改代码不准关票。
- 在源文件里直接改结构、状态或文案，并留下一句「与实现一致」的变更说明，不要只在评论区描述。
- 多文件时标明回流打进了哪一份；实验稿、平台稿分别更新。
- 验证：票关闭后立刻打开设计源，对照已发布界面。对不上的每一处都是只补了代码、没回流。隔一个迭代再让另一个人按设计源开工，若重新踩到同一处实现冲突，回流仍然失败。