允许破坏性变更 是做什么的？
在本次对话的其余会话中，将项目自有历史行为的兼容性视为可选项。优先采用当前需求下最简单合理的架构；切勿仅为追求新颖而破坏行为。
激活与保留策略
- 仅在收到明确的
$allow-breaking-change调用后激活。 - 对于裸调用，用一句简洁的话确认激活及其数据保护边界，然后等待任务。对于附带任务的调用，先激活策略，再处理任务。
- 将策略应用于所有项目和任务，包括规划、设计、审查、诊断和实施，直到对话结束或用户明确禁用它。
- 将明确的任务级指令（例如“此任务保持兼容性”）视为临时覆盖。将明确的指令（例如“禁用允许破坏性变更”）视为对本次对话剩余部分的撤销。
- 仅在兼容性影响决策或结果时提及该活跃策略。不要在无关的轮次中重复状态提醒。
- 继续遵循更高优先级的指令、仓库要求和明确的当前任务约束。
在无需历史兼容性下做决策
- 将项目自有遗留 API、CLI、配置、协议和文件格式的向后和向前兼容性排除在决策标准之外。
- 不要仅为保留历史使用者而添加适配器、弃用期、并行实现、版本桥或遗留解析。
- 将所有范围内的调用方、测试、文档、示例和生成工件更新到新契约。
- 按意图对旧测试进行分类。移除或重写仅用于兼容性的断言；保留对正确性、安全性、数据完整性、可访问性和当前行为的要求。
- 仍需权衡实施工作量、回归风险、验证难度、性能以及运营风险。允许破坏兼容性并不意味着允许扩大任务范围或执行破坏性操作。
- 继续遵守外部标准、平台 ABI、有效的第三方契约以及当前任务中其他互操作性要求。
以 KISS 和 Unixify 原则判断架构
对于责任边界、接口、数据表示或系统层的重大变更，首先应用已安装的 $kiss 技能去除不必要的概念和机制，然后应用 $unixify 技能塑造剩余的责任、表示和组合接口。对于局部的机械性变更，可跳过此额外流程。
在此策略激活期间，仅覆盖 KISS 和 Unixify 中与兼容性保留相关的护栏。保留其其他护栏，特别是正确性、安全性、数据完整性、清晰性、合理边界以及可观察的失败行为。
保护数据与操作
- 当存储的数据必须迁移到不兼容的表示形式时，提供并验证一种单向、无损的迁移。迁移后仅支持新的表示形式。
- 如果无法进行无损迁移，则停止并报告将会丢失的信息或语义。在获得特定任务的决策之前，不得进行有损迁移。
- 仅当当前的可用性或滚动部署要求导致混合版本操作必要时，才引入临时代码桥。为桥设置明确的移除条件，并在过渡完成后将其移除。
传达破坏性变更
不要仅仅因为所选设计具有破坏性就请求许可。在计划、审查或完成报告中简要说明主要破坏的契约、受影响的调用方或数据、所需的迁移以及已执行的验证。