# Classic 心跳启动相位与接收余量

> 本页保留本地修复阶段记录。当前0.3.1发布候选及状态见[版本说明](release-0.3.1.zh-CN.md)；下文“尚未改manifest/公开”等仅描述当时阶段。

本地未发布修复，基于已发布0.3.0提交`93e706f696095e0d848a8d5e326f35f48bc0becb`。拟采用0.3.1补丁版本，尚未改manifest、push、建立新PR或发布；不能把本页结果归给registry0.3.0。

真实registry消费者在Mac/arm64经TLS中继连接Classic6.3.2时，100ms与1000ms配置均在主动drop之前超时。协商1000,1000的时序显示：客户端收CONNECTED及尾随LF后只发出一次心跳，约2R后关闭，中继未见后续broker心跳；20ms tick没有长停顿。

不加载MoonSTOMP超时逻辑的独立TLS观察器看到，broker首个真正空闲LF在CONNECTED后约2015ms，随后约每秒一次。固定官方归档内的字节码显示，broker写检查初始延迟为min(read,write)，若刚发送过CONNECTED则首次检查只清已发送标志，下次检查才尝试异步keepalive。因此首beat可在2R之后到达；原Client期限恰为2R，没有剩余调度余量。不同进程的时间线不逐毫秒拼接为同一次运行；这是经对照支持的互操作边界，不是registry装错版本或已经证实的操作系统缺陷。

修复把检查相位R与既有100ms调度余量相加：`tolerance=min(R+100ms,2147483647ms)`，超时仍为严格`elapsed > R+tolerance`。常见R下期限为2R+100ms；公共HeartbeatClock默认100ms和接收方向禁用行为不变。最大协商值保留既有容差上限，使用Int64计算。代价是故障检测稍晚，不保证任意调度延迟下不断线。

回归保留明确关闭断言：100/1000ms精确边界与下一毫秒、2R+15ms首beat、任意非空/部分帧重置、空chunk不延命、禁用接收、大R上限和公共Clock默认值。相同原断言路径以本地修复通过；强化夹具只在CONNECTED后至少一个周期的空闲窗口计数，继续转发全部早期EOL并单独记录总数/排除数。该窗口是保守观察约定，不是一般协议流中区分心跳与分隔LF的算法。

原registry0.3.0接强化夹具仍失败，是负控制；本地修复在100/1000ms下观察两向心跳后drop，并验证有界超时、无重连、端口和私钥清理。原失败与原发布包保持不变。完整本地验收与独立AI审查另有对应提交回执，不冒充新远端CI或人类认可。

若批准公开修复：先更新0.3.1版本与发布说明，建立新的版本PR，运行精确head常规CI及固定broker手动CI，正常合并后再核合后CI；临发布防重并使用既有官方CLI登录，发布后全新registry消费者重验本次失败路径。不得覆盖0.3.0、撤包或在修复未发布时改写其失败结论。