v3.0.0-cofco-0916a: 本期发版包(batch1线),授权模型 f048-v4-contextual-departments
BISHENG 发布 v3.0.0-cofco-0916a 发版包（batch1 线），用于修复客户测试环境的 authorization_model_migration_required 问题。证据称客户 OpenFGA store 与数据库登记的一直是 f048-v4-contextual-departments（checksum 1898712a...），v5 从未在该环境发布，问题出在 v3.0.0-cofco-0916 镜像内带的是 v5 代码；本 tag 的模型校验和与客户 store 一致，替换后无需运行迁移或发布脚本。已在 109 上按客户环境演练：v5 镜像 migration_required=True，换回本模型 migration_required=False，前后 store 未变动。内容含 3.0.0-beta1-batch1 合并（含张国庆的知识空间子项读取优化）、知识库创建原子性、任务态新建白屏修复、工作流表单弹窗高度修复，以及中粮独有的下载按钮常显与视频全屏按钮移除。
发展脉络
- 首次出现v3.0.0-cofco-0916a: 本期发版包(batch1线),授权模型 f048-v4-contextual-departmentsBISHENG
- 行业反馈v3.0.0-cofco-0916b: 本期发版包(batch1线),授权模型 f048-v4-contextual-departmentsBISHENG
- 当前判断该案例反映企业私有化交付中授权模型（OpenFGA 类）版本与镜像打包版本容易脱钩，客户环境往往长期停留在某一模型版本。判断：在 To B 私有化场景，交付物版本可追溯性与环境一致性校验，可能比功能迭代速度更直接影响客户信任。Agent Pulse · 分析
BISHENG 发布 v3.0.0-cofco-0916a，定位为面向客户测试环境的修复版本。证据显示，客户 OpenFGA store 与数据库自始至终登记的是 f048-v4-contextual-departments（checksum 1898712a...），v5 从未在该环境发布；出现 authorization_model_migration_required 的原因是 v3.0.0-cofco-0916 镜像内打包了 v5 代码。本 tag 的模型校验和与客户 store 一致，替换镜像即可，无需运行迁移或发布脚本。发布说明还记录了在 109 上按客户环境做的演练结果：v5 镜像 migration_required=True，换回本模型 migration_required=False，前后 store 一行未动。功能内容方面包含 3.0.0-beta1-batch1 合并（含张国庆的知识空间子项读取优化）、知识库创建原子性、任务态新建白屏修复、工作流表单弹窗高度修复，以及中粮独有的下载按钮常显与视频全屏按钮移除。发布说明同时提醒不要再用分支 tag 给客户，因为分支 tag 每次推代码都会被重建。
从证据看，这是一次镜像内容与授权模型版本不一致导致的部署问题，而非数据侧迁移问题：store 与数据库登记版本未变，只有镜像内代码版本错配。可验证的下一信号是后续 release 是否改为用不可变 tag（而非会被重建的分支 tag）交付，以及是否在发布流程中加入镜像内模型 checksum 与目标 store 的自动比对。
该案例反映企业私有化交付中授权模型（OpenFGA 类）版本与镜像打包版本容易脱钩，客户环境往往长期停留在某一模型版本。判断：在 To B 私有化场景，交付物版本可追溯性与环境一致性校验，可能比功能迭代速度更直接影响客户信任。
对交付与运维团队而言，该修复避免了在客户环境执行不必要的迁移或发布脚本，降低变更风险与停机成本；同时暴露的 tag 管理问题提示需要把发布物不可变性纳入交付规范，以减少客户侧返工与支持成本。
若后续版本继续以不可变 tag 发布并附带模型 checksum 校验，此类 migration_required 误报应减少；反之，若仍使用会被重建的分支 tag，同类问题可能重复出现。可观察的下一信号是下一次客户环境发版的 tag 命名与校验说明。