制造维护最容易被简化成“设备坏了就建一条报修”。但企业版 mrp_maintenance 在 workcenter 场景下关心的远不止停机本身，它会同步改动工位、技师归属、维护团队和活动提醒内容。
一旦维护请求的 maintenance_for 指向工作中心，_compute_workcenter_id() 会把对象落到具体工位；接着 _compute_maintenance_team_id()、_compute_user_id() 会根据工位、设备和维护团队关系决定应该由谁接手。也就是说，维护请求不是孤立 ticket，而是会自动落到制造资源结构里。
_need_new_activity() 与 _get_activity_note() 进一步把这条链从对象层推到协作层。系统不只是分配负责人，还会生成与当前工位/维护对象相匹配的活动说明，让后续处理者收到的不是一句空洞的“有个维修单”，而是带制造上下文的任务。
这条链的重要性在于：维护一旦进入工作中心层，它就已经开始影响制造执行资源。维护团队拿到的任务、技师看到的备注、工位的后续调度判断，其实属于同一条资源协同链。
所以这里的跨模块接力是维护请求提供事件，制造资源模型提供工位和负责人映射，活动系统负责把这段映射变成可执行任务。没有这段协同，维护单只会停留在“有人报修了”的消息层。
如果现场说“明明切到工位维护了，结果负责人和活动说明都不对”，优先检查 maintenance_for、工作中心与维护团队的绑定关系，以及 _get_activity_note() 是否被二开改写。错误往往不是单据本身，而是协作链断了。
DISCUSSION
评论区