用途：在准备新增依赖（包、库、工具）、被问“该不该用 X”或“X 与 Y 比较”、或审查 lockfile 变大的 PR 时，用于做引入前的评估判断。不适用于升级已有依赖的场景。
评估顺序有严格次序，因为最便宜的检查最有决定性：先看约束，再看能力与成本的比，最后看健康度。多数候选会在前两步就被淘汰，无需读基准或变更日志。
三步（顺序即要点）：一、原则性约束测试，先检查项目的架构不变式，一条违反即可整族排除，比先比三家库再发现都不能用便宜得多。二、每单位成本的能力，衡量它做什么与它带来的全部成本，包括传递依赖树、构建时间、升级节奏、暴露给调用方的 API 面；省五十行却加四十个包，等于没省。三、健康与契合度，scripts/dep_health.py 负责抓取证据：发布节奏、维护者数量、issue 形态、许可证；它只取证据，不做决定。
四种结论，每次评估必须恰好落在一种并全部记录：在边界后采用，用自己的接口包装，让依赖成为实现细节，可替换、可 mock、可对未来替代做一致性测试，其类型不进契约；直接不封装的使用只留给刻意选定的平台级依赖。只取思路不取依赖，库的价值常只是一个算法、公式或技巧，仅三十行即可移植（许可允许并注明出处）、测试并自持。带记录暂缓，写明“现在不用”及理由，并给出重新评估的触发条件。带理由拒绝，未记录理由的拒绝会被重新提出。结论要记录在决策日志、记忆或重大采用时的 RFC 中；每库一行结论放在约束句旁即可。第二次数同族评估应在几分钟内完成。
反模式：先逛功能对比表；为演示路径采用、未考察失败模式与并发行为；忽视传递依赖；临时直接使用导致未封装调用先蔓延；反复重审已定结论。
相关技能：reading-isnt-proof、less-code-same-behavior、rfc-writer、error-taxonomy。其他细节（如具体命令与完整步骤）资料未提供。