MVP 范围切割：每功能问「砍了还成立吗」
B 方向·OPC 最佳实践（执行纪律维度）。opc-90-day-launch-plan 的最大风险不是做不完而是做多——本篇是范围切割的操作纪律。
背景与问题
MVP 的「最小」怎么执行？每个功能 addition 的门槛是什么？
发现（纪律设计，综合）
- 核心问句：每个候选功能问「砍掉它，产品对目标用户还成立吗？」——成立=砍；不成立=它可能是核心，倒过来验证核心假设（经典 MVP 逻辑的机械应用）。
- 「三件套上线法」：MVP 只许三个用户可见动词（例：防诈=送る/判定/止める）——第四个动词出现即触发范围听证（本周例程的周一槽）。
- 「模块寄生」纪律：本工作区的模块类候选（熱中症/冬雪/口腔/退院/vitals——japan-heatstroke-watch-module 等）全部不进首发 MVP，按「每个版本带一个模块」节奏出货——研究早就位、实现按序释放。
- 时间盒的物理隔离：D-60 后新 idea 一律进 backlog 不进当前 sprint（opc-launch-runbook 的注意力纪律延伸）。
推测
- 范围蔓延的早期信号：①「顺手也做一下」句式的出现频率（开发日志里自查）；②每日 15 分钟看板外的时间消耗；③测试用例数超过三个动词的自然组合——三个信号任一出现=范围听证。
- 砍掉的功能不是丢失：进「版本路线图」明示（「v1.1 で〜」）——既管理用户预期又保留功能价值（japan-refund-cancellation-design 的期望管理同源）。
结论
可行动启发：
- 三动词上限 + 砍了还成立吗问句：写进 PRD 模板首行——范围决策的机械规则优先于感觉。
- 模块寄生的出货节奏：「每版本带一个模块」从终活套件扩展到全部模块候选——模块永远不阻塞主链。
- 范围听证进周一例程：第四动词出现当周必开 15 分钟听证（砍/缓/换三选一，无第四选项）。
- 被砍功能的公开路线图：v1.1/v1.2 的功能明示——诚实的路线图是信任资产（japan-trust-signals-foreign-dev）。