用途
melech-roi 用来回答一个核心问题：一项变更的复杂度和影响范围（blast radius），是否真的配得上它带来的收益。它用一个日常比喻说明立场——水龙头在滴水：方案 A 为了止住这一处滴水而重排整栋房子的管道；方案 B 只更换那个水龙头里的垫圈。两者都能止漏，但只有一种会让未来每一位水管工为了修别的水龙头，都得先弄懂整栋房子的新管道布局。melech-roi 的存在，就是要在“已经存在的代码”或“尚未编码的想法”上，识别出伪装成局部修复的大范围改动。它评估眼前的方案，不设计替代方案。
主要能力
它从两个维度进行判断：
- 收益（Benefit）：滴水有多真实、多大——严重程度、影响范围（多少用户/路径）、发生频率、修复的持久性、战略价值。
- 负担（Burden）：这次改动动了多少“房子”——触及的共享边界、新增的持久化状态或生命周期、回归风险、未来维护者必须学习的新概念、可逆性。
在此基础上给出：
- 裁决（Verdict）：负担是否与收益相称，还是为了一处滴水而重排整栋房子。
- 收据（Receipt）：方案在哪里赚到了 ROI、在哪里损失了 ROI——问题影响范围对比方案影响范围、获得的价值、被收取的成本，以及最大的一笔成本。
使用方式
它可以指向三类来源：
- 一个已有的 PR（diff + 描述 + 讨论）；
- 一个本地 diff（已暂存/未暂存，分支对比基线）；
- 一个仍只在对话中讨论的想法或方向——此时还没有 diff，因此应把置信度标为较低，并把假设明确标注为假设。
来源从上下文中解析，只有在确实含糊时才询问。
工作流程：
- 命名滴水：用一句话说明实际追求的收益。如果收益本身不清楚或未经证实，标低置信度并指出缺失的证据，不要悄悄编造收益。
- 追踪被触及的表面：对代码而言是共享模块、持久化状态、公共契约、新依赖、调用点、概念；对想法而言是它一旦建成需要触及什么。
- 用同一单位比较影响范围：把“谁经历问题”与“谁必须承担方案”并列展示——路径、调用方、用户、任务、记录或其他有依据的单位。用“未知”而不是虚假的精确。
- 逐项列出收据：列出获得的具体价值和被收取的永久成本，并把成本严重程度标为 LOW、MEDIUM 或 HIGH。
- 找出最大的一笔成本：指出单一最明显的不成比例来源，或解释为什么广泛的影响范围是合理的。
- 给当前方案评级：分数衡量的是相称性，而不是开发者离某个想象中的完美实现有多近。
- 只对已有候选排名：如果 PR 或讨论中已经包含多个具体方案，就评估并排名这些方案；绝不为了凑排名而发明替代方案。
- 渲染收据：使用视觉契约，并参照 references/output-examples.md 中的示例。
输出形态
默认输出是一份逐项收据，包含：方案名称；ROI 评分与字母等级；仅当已有两个或更多方案时才给出排名；用可比单位展示的问题影响范围条与方案影响范围条；获得的价值；被收取的成本及其严重程度；最大的一笔成本；以及一句关于当前方案的裁决。收据只做诊断，不做处方——不添加替代设计、改进计划或“应该这样做”的部分。
等级含义保持一致：
- A（85–100）：负担明显与收益相称。
- B（70–84）：值得做，但成本真实且有边界。
- C（55–69）：可行，但存在明显的影响范围或复杂度错配。
- D（40–54）：负担超过已证明的收益。
- F（0–39）：严重不成比例，或基本缺乏支撑。
只在接近等级边界时使用 + 或 −。开发者不需要达到 100 分；等级回答的是这个方案是否相称，逐项成本解释了原因。渲染结果前应先阅读 references/output-examples.md，其中包含不成比例、合理、运营成本高、已排名和低置信度等示例。
适用场景
适合在评审已有 PR、本地 diff，或评估一个尚未编码的方向时使用，用来判断改动是否“过度设计”或是否确实需要触及共享边界。它也可以作为链条中的一环：melech-distill-need 在收益本身存疑时先确认滴水是否真实；melech-roi 诊断错配；melech-8020 在诊断出错配后设计更省成本的形态；melech-tidy 在 melech-roi 评级后执行自适应 diff 缩减。典型链条为 melech-distill-need → melech-roi → melech-8020 / melech-tidy。
限制
melech-roi 只评估眼前的方案，不设计替代方案，也不提出改进计划。它只对已经存在的候选方案排名，不会发明替代方案来凑排名。对于尚未编码的想法，置信度较低，且应把假设标注为假设。它不负责确认收益是否真实（那是 melech-distill-need 的职责），也不负责执行改动（那是 melech-tidy 的职责）。关于收费、价格、平台支持等信息，资料中暂未提供。