用途：doctor 用于在提交 PR（合并请求）之前运行格式化、检查与测试，逐步执行并修复失败，直到每一步通过。
主要能力与执行流程：对每个步骤按固定顺序处理——先宣告当前步骤，然后运行该步骤并修复失败直至通过，再简短报告本步骤所做的修改，最后进入下一步。示例宣告行为“Doctor: Step 2/3 - mix check”，示例报告行为“Step 2 report: lib/surge/foo.ex - removed unused alias; wrapped side effect in after callback.”
步骤内容：第 1 步格式化，运行 mix format；一次运行即可应用该工具能做的全部格式化，仅当首次运行失败（如语法错误）或格式化后又改动了文件时才需要第二次。第 2 步检查，运行 mix check。第 3 步编译与测试，先运行 mix compile --warnings-as-errors，可选运行 mix test <file path>。
测试范围的严格限制：资料明确规定任何情况下都绝对不允许直接运行裸的 mix test。测试范围仅限分支变更路径，来源为 git diff --name-only "$(git merge-base HEAD origin/main)"...HEAD 加 git status --short。测试运行形态只接受显式的 *_test.exs 文件参数，不接受目录参数，不做全仓库运行，也不做“额外确认”性质的运行。允许的文件仅限分支差异中的测试文件，或变更的 lib/... 模块的直接对应文件（相同路径主干），不允许相邻或邻近测试。允许列表为空时跳过该步骤。
修复范围：按测试用例而非按文件界定，只修复与分支应用代码改动直接相关的失败用例；同一文件中其他失败用例忽略并保持红色。不得越界修改：不改无关测试用例、无关测试文件，也不为无关失败修改生产代码。测试文件修改前必须通过编辑前门槛：先宣告计划进行的具体测试用例修改，并引用直接证明可以改动该用例的具体应用代码路径与分支差异片段；若无法预先引用该证据，则不得编辑。任何文件改动的最终报告必须包含每个被改测试用例的有力证据：确切的失败用例、确切变更的应用代码路径、确切的直接关系；若无法证明，则不得编辑。
限制与提醒：doctor 不是让整个仓库变绿的过程，而是编译 + 仅分支相关测试文件 + 仅修改这些文件内与分支相关的测试用例（同一文件中的其他用例可以保持红色），任何更宽的范围都属错误。若陷入循环或需要做大而高风险的改动，应停下来向用户求助。资料未提供收费、价格、平台或其他额外能力信息。