诊断不是附属品，而是生成器契约的一部分

很多生成器在非法输入上选择“什么都不做”。从实现角度看这很省事，但从使用角度看，它几乎等于没有契约。

当前项目明确把几类约束定义成诊断：

• TSG001 目标类型必须是 partial
• TSG002 包含类型必须是 partial
• TSG003 目标类型不能已经声明无参 ToString
• TSG004 目标类型不能是 static

为什么要把这些做成显式诊断

因为生成器不是私有脚本，而是会被别人引用的编译期组件。调用方最需要的不是“猜测为什么没生成”，而是尽快收到清晰错误。

显式诊断有三个直接好处：

• 失败原因离代码更近
• 回归时更容易写测试
• 行为边界会稳定下来

契约思维比“尽量兼容”更重要

生成器不是越宽松越好。对于明显不满足前提的输入，越早拒绝，系统越稳定。

一旦你把契约写成诊断，后续扩展功能时就会自然地问自己：这个新规则是语义能力，还是新的契约边界？这个问题会让整个实现更清楚。