测评平台（一）：资源、发布包与测评任务分层
测评后台同时承载问卷、考试、材料和报告配置。编辑页面需要频繁保存，参与者却必须在整个作答周期内读取同一份题目和评分规则。把资源、发布版本和任务放在一张表里，任何一次后台修改都可能改变进行中的结果，问题发生后也很难回答“这份报告依据了哪个版本”。
三个对象对应三种生命周期
资源是可编辑的设计对象，保存标题、FormDSL、评分配置和报告模板。资源可以有多个草稿版本，但草稿不参与正式作答。发布包是审核通过后的不可变快照，绑定一个资源版本、题目快照和报告规则。测评任务引用发布包，运行阶段再附加参与者范围与执行策略。
核心关系可以简化为：
assessment_resource(id)
assessment_form_version(resource_id, version_no, form_dsl)
assessment_release(id, resource_id, form_version_id, status, checksum)
assessment_task(id, release_id, access_mode, starts_at, ends_at)
assessment_run(id, task_id, release_id, participant_id, status)运行实例保存 release_id，不能只保存资源 ID。资源后来创建了新版本，旧运行实例仍然通过发布包得到原题目。发布包的 checksum 用来检查快照是否被意外修改，历史版本不在原记录上覆盖。
发布前校验要靠服务端
保存草稿时可以允许未完成字段，进入发布流程后执行完整 FormDSL 校验：题目标识唯一、选项引用存在、必填规则可解析、跳题条件不形成非法引用、评分维度和报告模板能够对应。前端校验提供反馈，服务端校验决定是否生成发布包。
发布动作在事务中完成：锁定目标资源版本，写入题目快照和配置快照，计算摘要，创建 AssessmentRelease，再把发布状态改为可用。任何一步失败都不应留下“已发布但快照为空”的记录。重复发布请求使用幂等键返回已有发布包。
发布包生成后不接受局部编辑。需要改一道题，复制发布内容为新草稿，修改并重新校验，再生成新的发布包。复制时保留来源发布 ID 和修改人，方便比较差异。旧任务继续引用旧包，新任务显式选择新包。
任务绑定执行策略
测评任务除了 release_id，还要绑定访问模式、时间窗、参与人范围和提交策略。运行入口读取任务快照时一次性确定版本，后续接口都从运行实例检查任务状态和发布状态。不能让客户端传入一个新的 formVersionId 覆盖任务绑定。
访问模式在服务端使用 PUBLIC、TASK_BASED、BOTH 三个枚举。公开入口只允许公开任务的启动和提交路径，任务入口必须校验任务令牌和参与人身份。前端隐藏入口不是权限边界，控制器和服务层都要做同一检查。
版本追踪要进入报告
报告记录资源 ID、发布 ID、FormDSL 版本、评分器版本和生成时间。重算时生成新结果版本，保留旧结果、输入摘要和原因，不直接覆盖历史报告。客服看到异常结果时，可以据此还原题目、评分规则和参与者提交的原始答案。
旧数据升级时要保留资源、发布包和运行实例之间的映射。破坏性 DDL 只能在在线服务、离线任务和回滚制品都停止读取旧结构后执行，主应用完成升级不足以作为删除依据。
验证场景
测试至少覆盖：草稿修改不影响已发布任务；发布包生成失败不产生可用发布记录；重复发布返回同一 ID；新任务选择新发布包；旧运行实例仍能打开；任务过期后不能提交；公开模式不暴露任务型入口。集成测试从资源编辑一路走到运行实例，不能只测三张表的增删改。
这套分层解决版本漂移和审计问题，不替平台解决题目内容质量、评分规则正确性和外部身份系统的可靠性。它要求每个执行结果都能回到一个明确的发布包。