该资料介绍了一种名为 position-based-group-sync 的同步模式，用于让共享会话中的多个客户端保持播放进度一致。其基本思路是：不等待最慢的客户端就绪，而是允许各客户端在自身准备好时开始，并通过位置修正让它们落在正确位置。
用途：在多人同步播放场景中，协调各客户端的播放头位置，避免因加载速度差异导致进度分离。
主要能力与实现要求：
- 每条命令携带位置：播放、暂停、切换条目等命令都必须携带位置，而非仅在 seek 时携带。
- 按在途时间修正：命令中的位置需根据命令在途耗时进行修正（clock.positionAt(position, running)），且仅在播放状态下推进位置；暂停状态下按在途时间修正会导致暂停会话被错误推进。
- 仅在偏差超过容差时 seek：小漂移属正常，每次 tick 都 seek 会导致持续卡顿。仅当当前位置与修正位置的差值超过 SEEK_TOLERANCE_MS 时才执行 seekTo。
- 时钟未校准时回退：首次往返完成前无偏移量，应直接使用原始位置，避免猜测偏移导致错误 seek。
- 非正位置处理：非正位置表示“从头开始”，不应进入修正流程，否则可能定位到末尾之后。
- 容差与检测阈值分离：应用容差（低于此值不 seek）与 seek 检测阈值（高于此值视为有意 seek 并发布）职责相反。若检测阈值小于等于应用容差，会导致 seek 与修正循环往复。
- 容差需实测并记录来源，不能随意推导。
- 位置需附带生效时间戳，用于在途修正；时间戳缺失时应回退到原始位置。
- 比较对象是应用时刻的本地位置，而非缓存位置。
- 位置随命令发布，而非定时广播；定时广播会增加流量且无实际收益。
- 应用路径中的 seek 需区分：修正性 seek 应受容差保护，恢复性 seek（如重建条目后恢复播放头）是无条件执行，不应受容差限制。
- 等待屏障仅用于条目中途卡顿，而非每次状态切换。
使用方式：资料提供了代码片段示例（applyTransport 函数）和验证命令。验证包括：检查容差常量是否命名而非内联（grep 命令）；审计含时钟修正的文件中的每个 seekTo 调用，确认其要么有 abs(...) > TOLERANCE 前置判断，要么是可命名的无条件恢复；行为测试包括双客户端长时间运行对比、节流一个客户端网络后释放应落在会话当前进度而非停住处、暂停一分钟后恢复两端应位置一致。
适用场景：多人同步播放/观看会话的客户端实现，尤其是 Kotlin 项目中需要协调播放头位置的场景。
限制：资料未提供具体产品平台、收费方式或完整安装步骤；代码示例为改编版本，名称已泛化，角色检查与日志已省略。