e891100a23
把「什么状态能做什么」从持久化里拎出来单独验证。这几条规则是认证改造的地基, 改坏的后果都是线上事故,故先锁住行为再写业务: - prepareForSubmit:新提交一律待审,并清空驳回原因(否则会继承上一次的驳回文案, 出现「审核中」却带着驳回原因的自相矛盾状态); - supersedeIfPending:再次提交只作废前一条待审,已通过/已驳回/已作废都是终态不碰 ——尤其是不得改动已通过的记录,它可能正被生效快照指针指着; - isCertified:唯一判据是生效快照指针,故「曾通过即永久保持」; - isAuditable:只有待审可审,终态再审会把生效快照改坏; - statusText:四种状态各一个中文说法,与列注释、前端文案保持一致。 TransportCertRecord.REJECT_REASON_MAX_LENGTH 与 reject_reason 列宽(200)对齐。 9 个用例覆盖上述规则与边界(null、未知状态、超长原因)。 可离线执行:mvn -o test -pl blade-service/blade-transport -am