adopt-better-result

采用 better-result

先收集证据，再按用户指定的范围开展工作。

选择分支

• 审计分支： 用户要求进行仓库范围的审计或提案，或未指定实现范围时使用。更改生产代码前，先完成审计分支。
• 指定范围分支： 用户明确要求实现某个函数、模块、边界或先前提议的范围时使用。将证据收集限制在该范围及其传播路径内。

审计分支中获批的范围，接下来通过指定范围分支实施。

审计分支：仓库范围提案

1. 确认仓库和 API 事实

阅读仓库说明、包清单、源代码布局、测试命令和架构文档。确认是否已安装 better-result，以及可用的版本/API。优先参考已安装的类型和源码，而不是依赖记忆中的 API。

在研究个别故障前，先梳理所有生产代码区域。审计时排除生成代码和供应商代码；检查测试以了解预期行为。

完成条件： 已列出所有生产代码区域，已知验证命令，并已核实可用的 better-result API。

2. 审计所有生产代码区域

遵循 references/repository-audit.md。追踪搜索证据，梳理端到端故障路径；对分组站点记录数量，并将无法确认的路径标记为未知。

将审计写入仓库既有的文档或规划位置；如果没有合适位置，则写入 docs/better-result-adoption.md。

完成条件： 报告满足 repository-audit.md 中的覆盖和完成要求。

3. 设计目标模型

应用 references/tagged-errors.md 中的故障分类法，并使用 references/result-boundaries.md 制定每项边界决策。将拟议的处置方式、面向用户的映射、边界决策和按优先级排序的纵向迁移范围添加到报告中。

推荐最佳的首个范围，并解释它为何边界明确且有价值。

完成条件： 所有已编目的故障均有处置方式，所有边界均记录了编解码器决策，并推荐了一个首个范围。

4. 设置审批关卡

提交报告和建议。审计分支唯一允许的仓库更改是该报告。

完成条件： 已提交报告。明确批准一个指定的纵向范围后，开始实施分支；否则，本次运行到此结束。

指定范围分支：实施

1. 确认范围和 API 事实

阅读仓库说明、验证命令、已安装的 better-result API、相关生产代码和测试。从指定故障源开始，追踪其经过直接调用方到处理边界或传输边界的路径。如果已有采用报告，则复用；否则，保留证据以供实施总结使用。

完成条件： 已梳理清楚范围边界、当前行为、故障变体、调用方、副作用和传输边界，并已核实可用的 API。

2. 实施一个纵向范围

遵循 references/vertical-slice-migration.md，使用 references/tagged-errors.md 确定故障处置方式，并使用 references/result-boundaries.md 定义边界契约。实施范围不得超出指定传播路径。

完成条件： 从故障源到所选处理边界的路径始终基于 Result，每种错误变体都已处理，所有控制流衔接点都已考虑在内。

3. 验证并报告

运行仓库适用的格式检查、lint、类型检查和相关测试命令。更新现有的采用报告，记录已完成的工作、偏差、发现和验证证据；否则，将这些内容写入面向用户的摘要。最后以推荐下一步工作内容结束。

完成标准： 所有适用检查均通过，或报告每项失败及其证据；报告或摘要准确描述仓库的当前状态。