あなたを待っているもののための受信トレイ

14:10、あなたは Payments API でマネージド実行を開始し、自分の仕事に戻ります。14:25、エージェントはある質問で止まります。リトライは受信側からの 4xx レスポンスも対象にすべきか、それとも 5xx とタイムアウトだけか。あなたは別のタブにいます。実行にレビューのループが加わったときに書いたとおり、1 時間以内に誰も答えなかった質問については、エージェントが自分の判断で先へ進みます。1 時間以内に誰もレビューしなかった計画は、実行を失敗させます。15:25、エージェントは一人で決めます。

何も壊れてはいませんでした。実行ページにはずっと あなたの対応待ち と表示されていました。あなたが実行ページにいなかっただけです。

実行は、Archyl 全体で当たり前になってきたことの一例です。物事が人を待っています。アーキテクチャ変更リクエストは、編集権限を持つ誰かがレビューするまで開いたままです。ダイアグラムの要素に付けたコメントに返信が付いても、書いた本人は目にしません。これまで、気づく方法は 2 つでした。見に行くか、メール通知をオンにするかです。メール通知は組織全体のアーキテクチャ変更をそのまま映すので、あなたが対応すべきではないことまで大量に伝えてきます。

Archyl に 3 つ目の方法ができました。アプリのヘッダー右端、すべてのページにあるベルで、未読件数が付きます。その奥にある受信トレイに入るのは、あなたを待っているものか、あなたがしたことへの返答だけです。

パネルの見た目

ベルをクリックすると、通知 というタイトルのパネルが開きます。通知は 1 件につき 1 行です。誰が何をしたかを示す文、抜粋、プロジェクト名、どれくらい前か。ありそうな午後の様子を示します。文はアプリが実際に表示するものです。名前、プロジェクト、抜粋は例です。

通知                                                 すべて既読にする

● エージェントがあなたの回答を待っています
  Should retries also cover 4xx responses from receivers, or only
  5xx and timeouts?
  Payments API · 12 分前

● Marie Laurent さんが #14 に変更を依頼しました
  Billing shouldn't call the ledger database directly. Route it
  through the Ledger API container.
  Billing · 2 時間前

● Sam Okafor さんがディスカッションに返信しました
  That queue was replaced by the outbox table in March, the
  diagram is behind.
  Checkout · 3 時間前

  エージェントの実行が完了しました
  Document how to set up and run the service locally.
  Billing · 昨日

行をクリックすると既読になり、その通知が指すページが開きます。実行、変更リクエスト、またはディスカッションです。すべて既読にする はパネルのヘッダーにあり、未読の行にカーソルを合わせると 既読にする ボタンが現れるので、開かずに片付けたいものに使えます。何もないときは、パネルがそう伝えます。「対応待ちはありません」。

何が通知を送るのか

送信元は 3 つで、全リストはここに載せられるほど短いものです。

マネージドエージェント実行 は、実行を開始した人に通知します。

キャンセルされた実行は何も送りません。誰かが止めると決めたのであり、その本人に知らせる必要はありません。

アーキテクチャ変更リクエスト は 2 つの方向に通知します。リクエストがオープンされると、作成者を除く、プロジェクトを編集できる全員に伝わります。レビューには編集権限が必要なので、リクエストが待っているのはその人たちです。それ以降は、リクエストに起きたことが作成者に届きます。

ディスカッション は返信について通知します。返信は、ディスカッションを始めた人と、そこにすでに返信した全員に届き、その返信が抜粋になります。リンクが開くのは個別の返信ではなくディスカッションなので、スレッド全体に着地します。

3 つすべてに共通するルールが 1 つあります。自分自身の操作について通知されることはありません。同僚の変更リクエストを承認すれば、同僚には伝わります。あなたには届きません。

なぜアクティビティフィードではないのか

これを作るいちばん分かりやすい方法は、Archyl がすでに記録している変更履歴を取り出して、ベルの下に表示することです。私たちはあえてそうしませんでした。

組織の履歴の大半は、他の人の仕事が順調に進んでいるという記録です。誰かが container の名前を変え、誰かがリレーションシップを追加し、ディスカバリーが 12 個のコンポーネントを提案してチームメイトが承認した。どれも事実ですが、あなたを必要とするものはほとんどありません。それを未読件数の下に置けば、件数は何の意味も持たなくなります。私たちの多くは、ほかのツールにそういうベルを持っています。そこに載った数字を読むのは、とうの昔にやめました。

だから受信トレイには、入れるものを決める狭い基準があります。あなたが動くまで止まっているもの (エージェントの質問、計画、あなたがレビューできる変更リクエスト) か、あなたが始めたことへの返答 (あなたのリクエストへのレビュー、あなたの実行の終了、あなたのディスカッションへの返信) か。どちらの基準も満たさない変更には、行が与えられません。

広く見渡すための手段は今もあり、変わっていません。組織全体のアクティビティを見る場所は、引き続きメール通知と 履歴 ページです。受信トレイはもう半分、つまりあなた宛ての部分です。

いくつかの詳細

受信トレイは組織ごとにあります。 2 つの組織に所属している場合、ベルが数えて一覧するのは、いま開いている組織のものです。

文はあなたの言語に従い、抜粋は従いません。 アプリは 9 言語で提供されていて、各行の文はあなたのインターフェースの言語で表示されます。通知が保存するのは起きたことであって、完成した英語の文字列ではありません。そのため、フランス語で作業するレビュアーと日本語で作業する作成者は、それぞれ自分の言語で「変更を依頼しました」と読みます。抜粋は誰かの言葉なので、書かれた言語のまま残ります。

通知がコピーするものは、元と同じように保護されます。 行には、変更リクエストのタイトルやコメントの一部が繰り返されます。それらが保存時に暗号化されている場合、Archyl Cloud がそうですが、受信トレイ内のコピーも同じ方法で暗号化されます。

件数はプッシュではなくポーリングです。 未読件数は 30 秒ごとに更新され、タブに戻ったときにも更新されます。そのため、新しい通知がベルに現れるまで最大 30 秒かかることがあります。「レビュアーが変更を求めている」という通知ならそれで十分早く、開いているタブごとに長時間の接続を張らずに済みます。既読にする操作は、自分のブラウザーではすぐに件数へ反映されます。

まだできないこと

エージェントが MCP サーバー経由でオープンした変更リクエストは、レビュアーに通知しません。 アプリ内でオープンしたリクエストは通知します。エージェントが MCP 経由でオープンしたものはプロジェクトの一覧には現れますが、誰のベルも動きません。

種類ごとの設定はありません。 特定の種類の通知だけをオフにすることはできません。上のリストが、届くもののすべてです。

@メンションはありません。 コメントで誰かの名前を挙げても、その人には通知されません。現時点で返信を知らされるのは、すでにディスカッションに参加している人だけです。メンションは受信トレイのロードマップで次に予定していますが、日付は付けません。

どこにあるのか

設定することは何もありません。ベルはヘッダーの右端にあり、あなた宛てのものが届くまでは空のままです。動くところを見るいちばん早い方法は、先に計画をレビューする をオンにしたプロファイルでマネージド実行を開始し、別のページに移って、件数が付くのを待つことです。

チャットから実行を開始している場合、これはスレッドでの更新に置き換わるものではなく、並んで動きます。Slack や Teams から開始した実行は、これまでどおりスレッドに報告し、開始した人は受信トレイにも行を受け取ります。

関連記事: 実行が待つ計画と質問については作業中のエージェントをレビューするを、これらの通知がたどるレビューのワークフローについてはアーキテクチャ変更リクエストをご覧ください。