修改大型平台 Monorepo，并让所有受影响的客户端保持同步

## 先读根目录规则，再读各目录自己的指令 将代码仓库根目录作为协调点，并将最近的本地指令文件作为具体任务的权威依据。先应用根目录规则，再加入每个受影响目录自行维护的规则，不要假定某个模块的约定能够支配整个变更。 对于没有本地指令文件的区域，应把最近且仍在维护的开发指南、模块`README`和持续集成工作流作为下一层事实依据。编辑跨领域变更前，应阅读所有适用的指南。 ## 编辑前先查清每部分归哪个模块负责 确定哪些模块分别拥有控制平面、运行时组件、公共规范、客户端库、部署资源、命令行界面、端到端测试、文档、示例和架构提案。 将生命周期和配置行为交给控制平面所有方，将运行时进程行为交给最近的组件指南，将公共模式变更交给规范所有方，将客户端生成工作交给库所有方，将部署行为交给其运维方或打包所有方，并将命令行为交给`CLI`所有方。 对于同时涉及契约、实现和客户端的变更，应从公共规范开始，再加载每个受影响使用方的指南。使组件`API`、测试假设和部署集成都与同一契约保持一致。 ## 确认目标，只改必要的行 说明假设，揭示歧义，并在请求存在相互冲突的解释时询问方向。实现前，将较复杂的工作转化为可观察的成功标准；需要作出决策时，应停止推进。 选择能够满足请求的最小方案。避免推测性功能、一次性抽象、不必要的可配置性、无关重构，以及删除已有工作。 只改动任务所需的文件和行，遵循本地风格；行为发生变化时，添加或更新有针对性的测试，并持续迭代，直至检查通过或明确剩余障碍。 ## 公共规范变更时，同步更新客户端和文档 将公共规范视为权威契约来源。面向用户的行为发生变化时，应使规范、实现、客户端库、文档、示例、配置、命令行为和发布产物保持同步。 部署`API`或编排器资源发生变化时，还应更新或验证生成的清单、部署包、控制器行为、服务器集成和运维文档。未经明确批准，不得让契约故意偏离实现。 在实现前或实现同时更新面向用户和面向运维人员的文档，使文档所述行为继续作为对外承诺的依据。 ## 先改源头，再重新生成生成文件 绝不能只通过编辑生成产物来完成修复。找到并修改权威模式、模板、配置或生成器输入，然后通过受支持的工作流重新生成所有受影响的客户端、清单、参考资料、示例和打包产物。 检查生成的差异中是否存在意外变更，并依据重新生成的契约验证下游使用方。将手写适配器与生成代码分开，并维持代码仓库在两者之间设定的归属边界。 如果重新生成受阻，应报告缺少的工具或环境，并让源文件和派生产物处于清楚标识的未完成状态，不得将其表述为已经同步。 ## 做破坏性的公共变更前先询问 对于公共`API`、客户端接口、配置、协议、命令行为、部署资源、注解、标签和包值，应优先采用增量式、向后兼容的变更。 在进行破坏性公共变更、引入有意的契约偏离，或在没有清晰迁移路径的情况下改变可见行为之前，应先询问。寻求批准前，应说明受影响的使用方、兼容性影响、迁移要求和发布后果。 绝不能把破坏性变更藏在生成差异中，也不能把无关的组件工作混入同一变更。应在实现、文档、测试和发行说明中明确体现已批准的兼容性决定。 ## 先在最小范围检查，再逐步扩大 在进行更广泛的验证前，先运行限定于文件或包范围的格式化程序、代码检查器、单元测试、契约检查和命令输出断言。当变更跨越相应边界时，再扩展到集成、跨语言、部署或文档构建。 将命令帮助和输出与`CLI`测试一同验证，将契约示例与模式检查一同验证，并验证所有受支持语言中的客户端行为以及受影响平台上的部署输出。行为发生变化或缺陷得到修复时，应更新有针对性的测试。 在最终交接中列出所有未运行或受阻的检查。只要某项必要检查仍在失败，或某个受影响的使用方在没有明确限制说明的情况下仍未验证，就不得声称工作已完成。 ## 每份文档只放一处，用链接代替复制 将面向用户和运维人员的详细指南保存在指定的文档树中。根目录`README`仅用于代码仓库入口；可发布软件包的`README`用于安装、快速入门和软件包入口。 已有维护中的文档页面时，应让内部组件的`README`保持精简。将可运行示例放在示例树中，将相应的说明页面放在文档树中；如果代码仓库约定如此，应将提案文档作为权威依据，而社区页面只用作索引。 通过链接引用社区政策和开发政策，不要重复其内容。优先在代码仓库文件中使用相对于版本的链接，使文档跟随当前检出的分支或标签；不得把公共网站作为版本化代码中唯一的事实来源。 ## 遵守文档站的页面规则，构建零错误 使用已配置的文档引擎和静态站点配置，不得引入未记录的构建时生成步骤。将图片放入指定的公共资源目录，并按照站点批准的路径约定进行引用。 为每个已发布页面提供所需的元数据，使用已配置的内部链接样式；链接到文档树之外时，应使用完整的源文件链接。统一应用已批准的提示块、代码组和导航约定。 不得在发布站点中包含仅供贡献者使用的指令。只有本地化政策允许时才能添加本地化副本；在认定可发布变更已经完成前，应让文档构建达到零错误。 ## 重点审查破坏性变更，并报告剩余风险 优先审查公共规范、客户端接口、配置、命令行为、部署资源和协议中的破坏性变更。指出不必要、内部不一致、使用方难以实现或缺少可信迁移路径的变更。 检查事实来源边界是否破损、分层是否遭到破坏、生成产物是否过时，以及是否存在测试缺失、未记录行为和兼容性退化。区分已确认缺陷与尚未验证的风险，并指出受影响的契约或使用方。 最后提供基于证据的报告，涵盖变更区域、已同步的使用方、已运行的检查、受阻的验证、兼容性决定和剩余风险。