reduce-system-complexity

降低系统复杂度

保留行为。精简机制。

仅当已选定具体的行为路径或子系统，且预期结果是净移除机制时，才使用此技能。它负责维护守恒台账、核算完整路径上的机制、确定第一性原理下的最小方案，以及分别设置行为门槛和机制门槛。

请将其与以下内容区分开：

• improve-codebase-architecture，负责发现并排列架构投资的优先级；
• codebase-design，负责设计所选模块的职责和完整的调用方契约；
• structure-codebase，负责物理布局、包、导入、约束执行和迁移；
• refactoring，负责实施常规、有界且保留行为的清理，不声称实现完整路径上的复杂度降低；
• functional reducer 函数、Redux reducer 和状态管理方案。

在生成诊断或实现报告前，请阅读 references/ledger-template.md。在解释来源或将此改编版本与上游来源进行比较时，请阅读 references/source-notes.md。

操作约定

• 保留用户要求的范围。不要将单一路径扩大为整个代码库重写。
• 诊断为只读操作。默认只写入报告；实施工作需要明确授权。
• 遵循仓库说明、架构决策、术语表、公共契约和工作区未提交更改约束。绝不要破坏性地重置、检出或覆盖用户或团队成员的更改。
• 将实现、测试、跟踪记录、历史、事件和运维知识视为证据。不要把当前分解方式当作目标，但也不要忽视其中发现的未记录约束。
• 从夹具、跟踪记录、快照和报告中删除机密、令牌、个人数据和生产负载。
• 根据风险调整台账的规模。移除本地标记不需要分布式迁移那样繁琐的流程；但涉及数据、授权、并发、兼容性或外部副作用的变更则需要。
• 将有限的测试和观察称为保留证据，绝不要称为普遍等价性的证明。说明置信度和保真度方面的差距。
• 默认以只读方式或在一次性沙盒中执行所有提供方、集成、迁移、故障切换、回滚、发布和运维检查。未经针对该副作用的具体授权，绝不要写入外部生产系统。

工作流

1. 明确范围、模式和需保留的契约

说明：

• 选定的入口点、结果、调用方、数据、集成和运维路径；
• 诊断模式或经授权的实现模式；
• 对于此范围，“减少机制”具体指什么；
• 排除的行为和边界；
• 限制工作范围的不可逆影响或已发布契约。

在承诺保留某种行为之前，先对观察到的行为进行分类：

类别	处理方式
已记录或已接受的契约	除非用户授权改变行为，否则予以保留
被依赖的可观察行为	即使未记录，也视为对兼容性敏感
有可信证据表明是预期行为且当前受支持或可观察到	予以保留，并在需要时强化其判定依据；将愿景式意图视为行为变更，返回契约决策流程并执行 tdd
已知缺陷或存在争议的行为	提交产品／领域决策；不得悄悄保留或修复
无法触达、已过时或推测性的内部实现	只有在确认可达性并掌握消费者证据后，才考虑删除

盘点输出、影响、错误、顺序、持久化、集成、授权、安全、隐私、可靠性、资源预算、兼容性、并发、重试、迁移和恢复行为。在行为与保证台账中记录每项及其证据和缺口。

特征化测试揭示代码的实际行为；它们不能决定代码应该如何行为。诊断期间，记录缺失的判定依据，不进行编辑。如果分别获得了实现工作和测试框架工作的授权，而当前行为缺少可用的判定依据，则加载 characterisation-tests 和 finding-seams。加载 testing，用于设计行为级判定依据。记录最终的变更范围，但将自动化 mutation-testing 测试框架推迟到精简范围已基本准备好提交 PR 时再搭建。

在该阶段结束时的 PR 就绪门槛上，并非每条已证明确实不可达的路径、仅涉及配置的变更、生成边界或运维机制都适合进行变异测试。此时应根据可达性、配置、契约、集成或运维证据标记为 N/A。切勿为了满足工作流而编造结构性变异，或伪造 RED。

只要拟议变更范围可能影响的任何重要行为仍存在未解决的证据缺口，实现工作就仍属于诊断阶段。

2. 为整体机制建立基线

针对每项需保留的行为，从触发到结果及恢复路径进行追踪。使用变更后的盘点方式和计数方法，对适用的机制维度进行盘点：

• 控制 — 决策、条件、顺序、错误、重试、回退和恢复路径。圈复杂度可以作为某个局部指标，但不能用于跨系统汇总。
• 状态和时间 — 状态、转换、可变数据所有者、缓存、队列、任务、回调、锁、同步点和生命周期阶段。
• 结构 — 模块、表示形式、层、调用跳转、内部和外部依赖、循环依赖、适配器和转换。
• 可变性和运维 — 标志、模式、配置、扩展点、可部署单元、作业、迁移、监控、运行手册和故障处理。

如果测试和运维机制带来持续的所有权成本，也应将其纳入。除非生成产物的源代码、构建机制或运行时机制发生变化，否则将其排除。将不相关的维度标记为 N/A。

对于混合运行时，应在变更前后的盘点中纳入各消费者和实现之间的运行时入口及转换，而不仅仅统计入口点移除的封装层。如果该路径使用 Effect，请阅读 Effect 运行时参考。

不要将不同类型的计数合并成一个综合评分。如果调用方、运维人员、依赖项或恢复路径承接了被移除的负担，那么函数、目录或差异集变小就不代表机制减少。

3. 从约束条件推导最小方案

独立于当前形态回答：

1. 必须具备哪些结果和非功能性保证？
2. 哪些领域决策和外部约束不可省略？
3. 哪些边界是固定的？谁必须负责状态、时间、故障和恢复？
4. 从触发到可观察结果，最短的连贯路径是什么？

勾勒最小可行机制，并指出保留每个部分所依据的约束。按以下顺序寻求杠杆：

1. 删除已证明过时的路径、选项、标志、配置、回退机制和推测性机制。
2. 统一重复的策略、表示、状态和归属权。
3. 缩小决策空间和状态空间。
4. 移除直通层、转换链、时间跳转和协调工作。
5. 只有在总生命周期成本和运营成本降低时，才用成熟的基础机制替代自定义机制；对于影响重大的依赖项或工具选择，使用 evaluate-existing-solutions。

拒绝那些只重命名、拆分、包装、迁移或掩盖复杂性的提案。更深的模块可以改善调用方，同时保留或增加内部机制；这在 codebase-design 中是有效结果，但本身并不代表成功减少了复杂性。

4. 选择完整的精简方案

对候选方案进行定性排序：

1. 优先完整移除一种机制，而不是只将其部分隐藏。
2. 优先选择保留证据更有力、保真度缺口更少的方案。
3. 将影响范围更小、恢复更容易作为决胜因素。

对于选定的候选方案，记录：

• 确切要处理的机制和需要保留的行为；
• 每个适用维度的客观基线观察值和目标观察值；
• 受影响的调用方、数据、集成、运营事项和公开契约；
• 缺失的验证依据及其他证明义务；
• 发布、可观察性、兼容性、数据迁移和恢复需求；
• 旧机制完全移除后的最终状态。
• 对于包含多个切片的计划，记录计划/台账标识、最终切片，以及每个切片的类别：减少过渡或最终减少。

优先选择规模小、可逆的切片。如果无法逆转或逆转不安全，应在实施前定义设有防护措施的前向恢复路径。扩展/收缩迁移可能会临时增加桥接机制、标志、双写或兼容性垫片；为每项指定负责人、移除条件和有限期限。如果某个过渡不会引入临时桥接机制，则记录 N/A。只有在最终状态移除了被取代的机制后，才能宣称已完成精简。

诊断到此结束，并产出报告。如果需要多个交付切片，则在完整精简方案和门槛条件定义完成后使用 planning。

5. 通过 REFACTOR 路径进行精简

只有获得授权后，才能继续实施。

编辑前，先对已授权的切片进行分类：

• 精简过渡 — 一个可独立验证的程序增量，在保留既定契约的同时，可能暂时保留或增加机制。它引用计划／台账和终端切片；对于任何桥接机制，记录负责人／移除条件／生命周期上限元数据（若无则记为 N/A），并保持 mechanism gate: pending — no net-reduction claim。
• 终端精简 — 移除被取代机制和已过期桥接机制的切片。它引用程序／台账并履行先前过渡切片的义务，或者记录 N/A — authorized single terminal slice。只有两道门槛都通过后，才能声称实现了净精简。

过渡切片可以是安全、可合并的增量，而程序整体仍未完成。不要将其描述为已完成精简，也不要仅仅因为它自身的机制门槛仍待处理，就让它失去精简台账。

保持行为的精简，应从通过的行为判定依据开始，并辅以与风险相称的可达性、配置、契约、集成和运维证据。这属于 REFACTOR 路径，不应成为编造失败测试的理由，更不能用测试去断言分支、层、状态或依赖的数量。如果切片已具备提交 PR 的条件，则在适用时对累计结果进行变异测试检查。如果期望结果会改变可观察行为或修复有争议的 bug，请停止此工作流，明确预期契约，并使用 tdd 实现行为变更。

对于每个安全切片：

1. 记录切片前的状态，并运行受影响的行为、类型、构建、集成和运维检查。
2. 编辑前，识别数据库、队列、部署、消息、授权、并发及其他不可逆影响。
3. 做出最小且连贯的变更，以推进完整的精简工作。
4. 保留面向行为的测试。只有在已有等效的行为覆盖后，才可淘汰形状依赖于实现的测试；阶段结束时的变异测试或替代证据门槛会在提交 PR 前验证累计测试套件。
5. 立即运行有针对性的检查，然后运行更广泛的相关测试套件，以及无法通过 mock 确认真实性的提供方／契约检查。除非明确授权涵盖了确切的线上影响，否则提供方检查必须只读或在沙盒中运行；绝不可默认执行线上迁移、故障切换、回滚、发布或外部写入。
6. 移除已被取代的代码、依赖、标志、状态、配置、针对已弃用内部实现的测试，以及已满足移除条件的临时桥接机制。
7. 重新审查完整路径，包括调用方、运维、故障和恢复。

如果证据检查失败，或发现新的受影响行为，请停止。只恢复本切片负责的编辑和影响，不要破坏无关工作。绝不可将已修改的行为用作变更前的基线。

6. 应用分类门槛

行为门槛

• 每条受影响的账本条目都有达到所需保真度且通过验证的保留证据。
• 结果、效果、错误、顺序、边界和非功能性约束均符合约定的契约。
• 对于每项被移除的决策、状态、依赖或回退机制所隐含的边界情况，只要可达且有意义，都已进行测试；否则，应通过明确的可达性、配置、契约、集成或运维证据来佐证相关声明。
• 明确说明剩余的不确定性和未经测试的供应商行为。

机制门槛

• 在相同范围内，使用相同方法重新统计相同维度。
• 将每个新增部分映射到其替代的旧机制，或说明其服务的必要约束。
• 检查调用方、适配器、运维、部署和恢复流程，确认是否产生了外部负担。
• 确认已废弃的机制和已过期的迁移桥接机制均已移除。
• 确认生命周期所有权总量有所减少。结果净持平或仅发生转移，均不合格；仅实现过渡的结果会使此门槛保持待定，也意味着整个计划尚未完成，但不一定影响该切片是否可合并。

对于减量过渡，行为门槛和独立切片验证必须通过，同时机制门槛必须明确保持待定，且不得声称实现了净减量。对于终态减量，必须通过两个门槛后，才能声称已实现减量。

报告

使用 references/ledger-template.md 编写一份全新的 Markdown 报告。默认将报告写入操作系统临时目录下带时间戳的文件，以免诊断过程弄脏代码库。仅在用户要求或项目已确立惯例时，才使用项目中的持久路径。

对于诊断，报告建议的减量、目标差异、证据缺口、风险和下一步决策。不得声称等效或已实现减量。

对于可用于 PR 的减量过渡，首先说明保留的契约以及计划与终态切片之间的关联；展示 behavior gate: pass、独立验证结果、阶段结束时单次变更的结果或明确标注为 N/A 的替代证据、任何桥接机制的所有权／移除元数据（没有时标注 N/A），以及 mechanism gate: pending — no net-reduction claim。

对于终态减量，首先说明计划／账本链接（或 N/A — authorized single terminal slice）、保留的契约和已移除的机制；展示同类对比的前后证据，列出所有执行过的验证，确认先前的过渡义务和已过期桥接机制均已处理完毕，并披露剩余的保真度缺口或必要的复杂性。

完成检查

• 在开始此工作流之前，是否已选定具体的系统或行为路径？
• 是否区分了有文档记录的、依赖的、预期的、有争议的和过时的行为？
• 每项受影响的保证是否都有相称的保留证据，或明确列出阻塞性缺口？
• 基线是否包含调用方和运维机制，而不只是已编辑的文件？
• 最小方案是否源于实际约束，而非追求流行的形式？
• 终态是否真正移除了机制，而不是转移或隐藏了机制？
• 每项实现产物是否都归类为减量过渡或终态减量，并关联了计划与终态切片？
• 临时迁移机制是否明确归属、范围受限且已安排移除；若不存在，是否明确标注为 N/A？
• 是否分别评估了行为门槛和机制门槛？
• 过渡是否让机制门槛保持待定且不声称净减量，而只有终态减量才声称两个门槛均已通过？
• 声明是否与证据相符？

致谢

改编自 Adam Bulmer 采用 MIT 许可证的 reducer 技能。本地版本缩小并重命名了触发范围，以定性证据取代不实的精确排名，整合了相关的测试和架构技能，并增加了实施、迁移、隐私和未清理工作树方面的保护措施。有关固定来源信息和许可证条款，请参阅 references/source-notes.md 和 LICENSE。