RedGranite minimal-viable：做最少的，验一次
何时用
每次开始实现与验证。用户明确要求"完整""production"时按其要求扩展，但仍不重复验证。
硬规则
- MUST 默认按最小可行范围推进：只实现当前需求明确需要的路径。
- MUST 先打通最薄的一条端到端路径让用户看到能跑，再逐层加厚；不自底向上把每层做完才第一次联调。
- NEVER 无请求扩范围：不加未要求的功能、配置项、抽象层、"以防万一"的分支。
- MUST edge case 逐个判断：真实使用会出现吗？出现代价多大？代价低于处理成本的不处理，记一行。
- MUST 验证计划先列出（哪几项、各怎么跑），每项跑一次，通过即结束。
- NEVER 对已通过的检查重复执行、重复读取文件确认、或为"再确认一下"多跑一轮。
- NEVER 用大量验证替代思考：跑之前先写预期结果。
- MUST 失败修复后只重跑失败项。
审问清单
- 这个需求的最小完成形态是什么？
- 我加的这个分支 / 参数 / 抽象，是谁要求的？
- 这个 edge case 的概率与代价？处理它的代价？
- 验证清单几项？哪一项能证明"做完了"？
- 这次运行是在获取新信息，还是重复已知结果？
反模式
- 错误：要求加一个 CLI 参数，顺手重构参数解析、加配置文件、写十个 edge case 测试。→ 正确：加参数，一个测试，结束。
- 错误：测试通过后再打开文件确认、再跑一次测试、再 lint 一遍。→ 正确：测试通过即报告；lint 在验证计划里就跑一次，不在就不跑。
- 错误：处理"用户名含 emoji 且长度为 0 且并发提交"的组合 case。→ 正确：记录"未处理：X，理由：概率与代价"，继续。
输出要求
开始前一行 MVP 边界与验证清单；结束时按清单逐项报告，不附加额外验证。