触发时机是否等待回程结束属于实现决定，不可从动作定义推断
别名: 轻扫提交点 · fire on peak · wait for return · 触发时机
概念解释
往返轻扫作为动作包含甩出和返回，但系统事件在哪一帧提交并不是动作定义能推出来的。可以在甩出速度峰值处就翻页，也可以等手回到休息位再翻。前者快，返回段仍可能被当成第二次命令；后者稳，人会觉得“扫完了怎么还不翻”。两种都合法，必须写成实现选择并告诉用户，不能从“这是往返手势”直接读出提交点。
机制
提交点决定延迟和双触发风险如何分配。峰值提交把延迟压到弹道的前半，翻页发生时手还在空中；返回段若未被明确吞掉，镜像速度会再交一次。回程结束提交把整枚令牌闭包后再出事件，双触发下降，但反馈晚于人的主观“已经扫完”——主观结束往往在甩出减速处，不在手落回腰侧时。识别器内部还有第三种：方向一稳定就提交，连峰值都不等，更快也更容易被路过的半扫打中。动作定义只约束“什么运动算一枚轻扫”，不约束“哪一时刻对世界产生副作用”。副作用若不可撤销，提交点应偏晚；可撤销的浏览，提交点可以偏早。
怎么研究
同一套动作录像，用三种提交策略回放：峰值、方向稳定、回程结束。测事件延迟（相对用户按键报告的“我扫完了”）、双触发率、以及主观“是不是扫了才动”。自变量包括词表是否含镜像对、反馈是否在提交瞬间给出。Wizard-of-Oz 里让人先选自己喜欢的提交点，再换成算法，能把偏好和算法能力分开。不要从动作定义的文字里“推导”该用哪一种，那是把规范问题假装成语义问题。
边界
连续速率控制（手往右就一直快进）没有单次提交点，不适用这套选择。捏合拖动的副作用在维持期间连续发生，也不是一次提交。若返回被教学省略，回程结束提交会永远等不到，系统像死了；这时峰值提交反而更诚实。网络延迟会把任何提交点再往后推一截，主观差异被放大。高后果命令（关机、支付）不应采用峰值提交，即使动作定义仍是往返轻扫。
怎么落地
- 在规格里写死提交点：峰值、方向稳定或回程结束，并写明另一段运动如何被吞掉。
- 把提交点反映在反馈上：早提交就在甩出时给脉冲，晚提交就在手回休息位时给脉冲，避免人在空档里补做。
- 镜像词表默认不要用峰值提交，除非返回段被明确屏蔽；验收用完整往返和不返回两种操作核对事件次数。