Consoleとは

Console は loopkeep の Web コントロールプレーンです。アカウント、ペアリング済みの デバイス、そして外部のイベントで自分のマシンの workflow をトリガーする GitHub・Slack 接続を管理します。ここは意図的に、あなたの作業が行く場所ではありません — Console が 知ることをできるだけ少なくするように、アーキテクチャが作られています。

イベントがマシンに届く仕組み

GitHub / Slack / 自分の webhook ──▶ gateway ──verify → match──▶ your daemon ──▶ run

あなたの daemon は Console への外向き WebSocket 接続を 1 本だけ保ちます — マシンに 受信ポートはありません。イベントが届くと、gateway は署名を検証し、daemon が アップロードしたトリガーの宣言と突き合わせ、一致したものを、その きっかけになった本文(コメント、メッセージ、issue のタイトル)と一緒に配送します。

ペアリングでは一覧・操作用の workflow カタログと、イベント配送用の routing 宣言を別々に 同期します。リモート監督が有効なときは、daemon が active run の最新スナップショットを 別にアップロードします。そこに含まれるのは状態と起点を示す locator だけで、workflow 本文、 プロンプト、イベント本文、transcript は含まれません。

この本文は運ぶだけで、保管しません。保持するのは配送に必要な間だけ(store-and-forward なので、マシンが眠っている間に届いたイベントは再接続時に届きます)。出す先はあなた自身の アカウントのデバイスだけで、ルーティングと配送以外には使いません。64 KB を超える本文は 切り詰め、そのことを印として付けます。

決して越えないもの: リポジトリとそのソース、.env と secret、policy ファイル、 プロンプト、run の transcript。サインインしてもこれらはアップロードされません。 コネクタの認証情報は、設定した GitHub・Slack 機能だけに使い、コードを読むためには使いません。 Slack の bot token は名簿とチャンネルの可視性・参加状況の確認、要求した thread 文脈、reply・post・通知の 送信に使い、受信イベントの真正性は別の signing secret で確認します。

daemon は gateway が一致させたものをそのまま起動し、イベントを照合し直しません。肝心の 監督はローカルのままです。run が提案する操作は、何がその run を起こしたかに関わらず、 あなたの policy と floor で評価されます。

オフラインから戻ったとき

デバイスがオフラインの間、gateway は一致したものを預かります(最大 1000 件・最大 24 時間)。再接続するとその全部が届くので、停止が長かったときは一度に大量になります。

loopkeep はそれを 100 本の run にはしません。再接続したら 5 秒かけて届いた分を集め、 10 件未満ならそのまま走らせます(本来その時刻に走っていたものなので)。10 件以上なら どれも走らせず、いったん保存して、workflow ごとに 1 枚のカードを受信箱に出します。 カードには件数といちばん古いものの経過時間が書かれ、答えは 3 つです。

• Run all — 1 件につき 1 本、古い順に走らせます。
• Run latest only — いちばん新しい 1 件で run を 1 本だけ走らせます。全件はその エージェントに渡るので、隠れるものはありません。
• Deny — 何も走らせずに捨てます。

考えている間に失われるものはありません。溜まった分は「配り終えた」を gateway に伝える 前にディスクへ書くので、daemon を再起動しても残り、カードも一緒に戻ります。 launch: confirm の workflow も二度は聞きません — カードへの回答がその確認を兼ねます。

デバイス

lk login またはデスクトップアプリの ログインしてご利用中のデバイスをペアリング で行います (Console とペアリングする を参照)。各デバイスは専用のトークンと 署名鍵を持ち、Console の デバイス に一覧され、個別に無効化できます — 紛失・盗難 したノートPCの復旧経路です。

権利があり、リモートの automation 制御 capability を通知するデバイスでは、自動化を停止 が lk pause --all と同じ永続的な全体トリガーゲートを設定します。 すべての workspace でこれから始まるトリガー起動を止めますが、手動 run とすでに進行中の run は続きます。再開は lk resume --all またはデスクトップ/TUI の設定からローカルでのみ 行います。

デバイスがオフライン、またはオンライン状態が不明でも 自動化を停止 は操作できます。ただし、あとで 配送されるコマンドにはなりません。要求を配送できなかった場合は Console がその結果を表示し、 デバイスがゲートを受理しない限りローカルの automation は動き続けます。制御要求は送信前に安全側で 拒否します。gateway からオンライン状態を取得できなかった場合は HTTP 503 (presence_unavailable)、取得に成功して対象デバイスがオンラインでない場合は HTTP 409 (device_offline) を返します。

自動化を停止 が受理されると、Console はリモートアクセスを切る別の次の手順として 無効化 を 勧めます。2 つは 1 トランザクションではありません。無効化するとリモート機能を切り、そのデバイスが アップロードした run スナップショット、workflow カタログ、トリガーの routing 宣言を削除します。 デバイス上のローカルデータと automation は残ります。要求が拒否・期限切れ・未確認になった場合は、 再試行の前にデバイスを確認してください。

Active run

Console の 実行 ページには、リモート監督が有効なペアリング済みデバイスの非終端 run だけが表示されます。これは各デバイスの最新の全置換スナップショットで、クラウド上の run 履歴ではありません。アップロードするスナップショットは workspace ID と表示名を持ち、各 run の payload には workflow、run ID、状態、監督フラグ、開始時刻と、GitHub の repository・issue 番号や Slack の channel・timestamp といった起点 locator が入ります。タイトル、本文、author、session、 worktree、engine 設定、プロンプト、transcript は除外されます。daemon が remote_supervision_enabled: false を認識している間は、スナップショットを組み立てず、送信待ちの スナップショットも破棄します。ただし entitlement の変更が届く前のリクエストや、すでに送信中の リクエスト body がネットワークを通ることまでは防げないため、常に 0 byte という保証ではありません。

表が表示する列は、アップロードした全フィールドではありません。見えるのは 状態、run、 workflow、デバイス、起点、監督 で、開始時刻は行の並べ替えだけに使います。 デバイス、workspace、状態で絞り込めます。

空の領域は 4 つを区別します: active run がない、プランにリモート監督が含まれない、オンラインの デバイスが run 状態を報告しておらず更新が必要、または active run はあるが現在のフィルタには 一致しない、です。オフラインで過去のスナップショットもないデバイスは古いと断定できないため、 active run なしの表示になります。

オンラインで capability のあるデバイス上の、終了可能な attended run では、終了 がそのデバイスに既存のローカル終了操作を適用するよう依頼します。Abort、rollback、 terminal session の kill はせずに監督を外します。すでに出力のある run は completed に、 出力のない run は interrupted になって再開できます。結果を確認できなければ、再試行の前に デバイスを確認してください。

GitHub

Console の 接続 ページから、loopkeep の GitHub App を自分のアカウントか 組織にインストールします。するとリポジトリのイベント(issue、コメント、pull request、 レビュー、push、CI)が daemon に届きます。

インストールを承認すると、同時にあなたの GitHub login が紐付きます。App を入れた アカウントではなく、承認した本人の login です。これが mentions: me のようなトリガーで me が解決される先で、接続ページには Linked as @you と表示されます。もう一度接続すると 上書きされます。紐付いていない間、me は全員に一致するのではなく何にも一致しません。

workflow はリポジトリに暗黙で bind します。origin リモートがあるリポジトリを指す workspace は、設定なしでそのリポジトリのイベントを受け取ります。複数のリポジトリを 購読するには、明示的に名前を指定します:

on:
  github:
    issues: {}
    repos: ["org/other-repo"]

接続ページの 接続解除 は loopkeep 側の接続を解除し、イベントが daemon に届か なくなります。GitHub App 自体のアンインストールは GitHub の設定から行います。

Slack

Console の Add to Slack で Slack workspace を接続します — 共有アプリが 1 つ、 作ったり貼ったりするトークンはありません。すると workflow はメンション・DM・キーワード・ リアクションでトリガーできます(トリガー 参照)。

identity は workspace ごとです。その workspace を承認した Slack ユーザーが、そこから来る イベントの me になります。認識されたい workspace ごとに接続してください。

接続ページの 接続解除 は保存したトークンを失効させ、接続を解除します。

リモートイベントが届かなかった理由

接続 ページには、その日の gateway 配送停止カウンターが理由別に表示されます: 宣言や filter に一致しない、resource にアクセスできない・検証できない、quota・rate limit、 offline queue の結果などの routing 判断です。日は UTC の 0 時に切り替わります。これは イベントごとの log や過去の audit 記録ではなく集計診断で、1 つの受信イベントが複数の デバイスや workspace の判断に数えられることもあります。gateway に到達できなければ値は 0 ではなく不明です。lk trigger explain はローカル宣言を説明し、この配送カウンターを 参照するよう案内します。

webhook

コネクタの無いもの — CI ジョブ、自宅のサーバー、POST できるサービス — には専用の URL を 発行します:

lk hooks add deploy-done

URL は 1 度だけ表示され、それを知っていること自体が資格情報のすべてです。持っている人は 誰でもあなたの workflow を起こせます。ほかの secret と同じ場所に保管し、漏れたら lk hooks rotate <name> で作り直してください。名前は変わらないので、宣言している workflow は 書き換え不要です。lk hooks は持っている名前を一覧し、lk hooks rm <name> は以後の POST を 拒否します。宣言の書き方は トリガー にあります。

Console から run を開始する

manual トリガーを宣言した workflow は、Console の ワークフロー ページに workspace と デバイスごとに並びます。実行 を押すと、Console はそのデバイスに開始を依頼します。 workflow も worktree も、それが読むものもすべてそのマシンに残り、動くのは依頼だけです。

依頼できるのはオンラインのデバイスだけで、同じ workflow が複数のデバイスにあるときは どれで動かすかを選びます。依頼は 1 回だけ有効な起動権で、2 分で期限切れになります。 デバイスが受け取らなかった依頼が、あとから突然 run になることはありません。

これは有料プランの機能です。Free プランでも workflow の一覧は出ますが、実行ボタンは 出ません。

権利のあるアカウントでは、同じページでデバイスごとに workflow の自動トリガーを有効・無効に できます。手動 run とすでに進行中の run は影響を受けません。切り替えはデバイスが既知の disabled 状態と remote_workflow_control capability を報告したときだけ表示され、古い デバイスでは read-only のまま更新案内が出ます。この互換状態には現在のオンライン状態が必要です。 オフラインのデバイスには読み取り専用チップも更新案内も出ません。

プランと上限

接続 1 件は、GitHub installation 1 つまたは Slack workspace 1 つです。どちらも同じ上限を 共有します。

wake signal はイベント単位ではなく配送単位で数えます。1 つのイベントが 2 台のデバイスの workflow に当たれば 2 消費します。その日の枠を使い切ると、以後の signal はその日(UTC)の 間は捨てられます。何件届かなかったかは Console の概要に出ます。ローカルのトリガー (cron・file-watch・git・手動)は影響を受けず、枠も消費しません。Console から自分で開始する run も枠を消費しない ため、枠を使い切った日でも手動での実行は止まりません。

保証すること

• コードはマシンに残る。 リポジトリ・ファイル・.env・secret・プロンプト・run の transcript が アップロードされることはありません。越えるのは、購読したイベントがマシンへ向かう分と、 上で説明した最小限の workflow カタログ・routing 宣言・active run metadata です。
• 購読していないものは配送されない。 照合は配送の前に行われ、誰のトリガーにも当たら なかったイベントは捨てられます。
• ランタイムは決してゲートされない。 サインアウト中、オフライン、Console が落ちて いても — ローカルのトリガー、run、受信箱、デスクトップアプリはいつまでも動き続けます。 Console の 自動化を停止 はこれからの自動起動だけに効く、永続的でローカルから解除できる狭い ゲートであり、process や runtime の kill switch ではありません。
• 無効化は本物。 無効化されたデバイスは Console に接続できず、コネクタの認証情報も 取得できません。それだけでローカル automation が止まることはありません。