用途：continuity-loop 定义多智能体底座的“续期契约”，涉及 NTM 窗格、MCP Agent Mail 与 renewal tick。它本身不运行智能体、不做调度，而是规定 tick 的含义、每个受监督 lane 每 tick 应做什么、如何检测停滞，以及停滞何时升级。适用于 loop 技能需要连续性步骤、需要判定某 lane 是 suspect/stalled/converged，或决定是否轻推、重启或升级时。
核心规则：tick 由宿主机计时（cron、systemd 用户计时器或人工）触发，本技能不含守护进程。唯一状态面为 .agents/continuity/state.json，原子写入（临时文件加重命名）。默认每 10 分钟一次 tick。某 lane 的 tick_seq 落后全局一为 SUSPECT，落后两个或以上为 STALLED。两 tick 规则：单 tick 不判停滞，首次无进展标 suspect，下一 tick 仍无进展才标 stalled，之后按“轻推、重启并走 recover、再停滞则升级”的顺序干预；出现任何进展证据即重置为 active。
主要能力：读取窗格活动与 Agent Mail 流量，逐 lane 判断自上次 tick 是否有进展，并续期状态条目。进展证据包括窗格输出增量、新 Agent Mail 消息或预约活动、lane 自续期、工作产物变化（提交、关闭项、新产物）。状态为 active、suspect、stalled、converged、escalated，每次状态变更必须附证据字符串。升级通过 Agent Mail 消息通知 operator/tender，绝不静默 kill。
使用方式：evolve 将其 halt/handoff 映射到 tick 契约；using-atm 的照看循环是参考 tick 执行器；recover 是重启后的再入适配器。输出为 JSON 状态文件及升级消息，tick 结束时报告各类 lane 数量。
限制：状态只写往 .agents/continuity/state.json；不得经 rpi 或 bd（均已退役）路由连续性；健康 lane 不应被干扰。其他收费、价格、平台等信息暂未提供。