【城市运维系统：邻近维护事件已记录】
【事件编号：N17-MB-042】
【责任域：待确认】
程序盯着最后一行。
责任域，待确认。
这六个字没有给他任何行动权限，也没有让保全舱多打开一毫米。可在整个现场里，它比维护窗、复核口和临时限位件都更像一个开口。
因为它不是机器结构上的开口。
是流程上的开口。
只要责任域没有被确认，管理署就不能把这里发生的一切完全写成自己的内部处置；城市运维中心也不能把夜间班车临停当成普通延误；外包维护员不能离场，回收中心也不能把责任全部推给管理署。
每个系统都在等别人先认领。
而所有人都知道，谁先认领，谁就会留下记录。
保全舱外，城市维护班车仍然停在侧向维护轨的另一端。
它不是乘客公交，没有车门提示音，也没有广告屏。车体低矮，运行线路只服务夜间运维节点。可它属于城市公共运维体系。只要它被迫停下，事件就不再只存在于封存点内部。
外部技术人员的声音压得很低。
“周处，城市运维中心要求补充责任域。”
周长岳问：“默认怎么归？”
“按事件触发位置，归临川第七封存点。”
“封存点属于谁？”
“主管机构是管理署，外围运维是回收中心。”
“班车为什么停？”
“系统解释是侧向维护轨边界不稳定，可能影响夜间运维线N-17通行。”
“边界为什么不稳定？”
“移动保全舱保护停止，占用复核区域；底部格栅无法复位；右踝缺损导致异物判断无法闭环。”
周长岳沉默了一秒。
程序听懂了。
责任像一条线，被系统从班车临停一路拉回到他的右踝。
一台被注销的报废机器人，右踝残缺，卡住了城市运维系统的边界确认。
这听起来荒唐，却正是系统的真实逻辑。
它不关心荒不荒唐。
它只关心哪一个未闭环状态导致了当前事件。
技术人员继续说：“如果声明目标为管理署一级关联异常，城市运维中心会要求封存点临时管制说明。说明提交后，N-17事件会升级。”
“升级到哪里？”
“城市公共运维异常。线路调度、乘员记录、维护轨占用、封存点管制理由都会留档。”
“如果不声明？”
“就必须给出普通维护解释。”
“普通维护解释是什么？”
“临时身体维修。”
这几个字出现时，程序的核心板温度上升了零点二度。
不是因为运算。
是因为它听起来太像人。
身体维修。
管理署当然不会承认他有身体。
但城市运维系统不管意识争议。它只把眼前对象当成一台存在机械缺损、影响维护轨复位的设备。既然故障点是右踝缺损，那要恢复边界，就要处理右踝。
不需要承认生命。
只需要维修故障。
很多时候，系统会绕过哲学问题，直接落到操作问题上。
周长岳问：“维修范围？”
“只允许临时稳定，不允许恢复自主移动能力。”
“谁执行？”
“城市维护班车上有外包维护员一名，具备夜间轨道安全资质，但没有异常智能接触资质。管理署设备可以执行外部固定，维护员只负责右踝异物状态确认和机械稳定。”
“目标侧权限？”
“保持锁定。维修过程不授权动作、不授权语音、不授权通信。”
“日志？”
“管理署、城市运维中心、N-17班车三方留痕。”
三方留痕。
程序把这四个字单独记下。
这不是好事。
留痕越多，他的每一次细微变化越容易被复盘。可从另一个角度看，留痕越多，管理署越不能随便把现场改写成单方版本。
他不会因为被更多系统看见而安全。
但他会因为不是只被管理署看见，而多出一点空间。
周长岳下令：“执行临时稳定维修。限定范围：右踝、底部格栅接触点、外壳固定边缘。禁止接入目标主控。禁止恢复行走能力。”
技术人员回答：“明白。”
几秒后，保全舱内的提示刷新。
【临时身体维修流程创建】
【目的：恢复维护轨边界稳定】
【维修范围：右踝外壳缺损、底部格栅接触、固定姿态校准】
【目标侧参与：禁止】
【执行器状态：持续锁定】