アプリケーション CLI コマンド

静的ディレクトリをアップロードせずに決定論的アーカイブにパックします。

app pack <directory> [--output FILE]

screenrig app pack ./lobby-board --output ./lobby-board.tgz

エンベロープはsha256、compressed_bytes、expanded_bytes、file_count、エントリーリスト、SDKランタイムが注入されたかを報告します。app uploadはディレクトリ自体をパックするため、アーカイブを先に調べたい場合にこのコマンドを使用してください。ローカルで実行され、サインインは不要です。

パッケージは、最大 5000 ファイル、展開後 250 MiB、圧縮後 100 MiB、1 ファイル最大 32 MiB で、パスは最大 16 階層・255 バイトです。パッキングでは、. で始まる名前、node_modules/、bower_components/、jspm_packages/、vendor/、venv/、__pycache__/、CVS/、ソースマップ *.map、鍵と認証情報のファイル（*.pem, *.key, *.p12, *.pfx, *.crt, *.cer, id_rsa, id_dsa, id_ecdsa, id_ed25519, credentials.json, secrets.json）、エディターのスワップ・バックアップファイル、Thumbs.db、desktop.ini が除外されます。ディレクトリのルートにある .screenrigignore ファイルは gitignore 形式のパターンを 1 行に 1 つ追加しますが、組み込みの除外を取り消すことはできません。シンボリックリンク、ハードリンク、スパースファイル、デバイス、重複するパス（大文字小文字を区別せず比較）、パッキング中に変化するファイル、ルートに index.html がないディレクトリは、パスを示して拒否されます。コマンドは終了コード 2 で終了し、何も送信しません。

アプリケーションはインラインコードをブロックするコンテンツセキュリティポリシーの下で実行されます。パッキングはインラインスタイルとスクリプトブロックを、各 HTML ドキュメントの隣にある _screenrig-inline-* ファイルに移動しリンクします。onclick= や javascript: のようなインラインイベントハンドラーや URL は移動できず、パッキングは拒否しファイル名と行を示します。

window.screenrig の TypeScript 型をディレクトリに書き込みます。

app types [directory]

screenrig app types ./src

エンベロープは path、bytes、sha256、および、ファイルがすでに最新の型を含んでいた場合に false となる written を報告します。ファイルは app pack と app upload が注入するランタイムと一致するため、CLI を更新したらコマンドをもう一度実行してください。既存の screenrig.d.ts は丸ごと置き換えられ、そのパスにあるディレクトリやシンボリックリンクは拒否され、コマンドは終了コード 2 で終わります。ローカルで実行され、サインインは不要です。型が宣言する内容は TypeScript を参照してください。

アップロードする前にアプリケーションを試せるよう、ディレクトリをローカルの Player ハーネスで提供します。

app dev <directory> [--port PORT] [--open] [--no-reload] [--kv FILE | --kv-from APP_ID]

screenrig app dev ./lobby-board --open

このコマンドは http://play.screenrig.localhost:18890 でハーネスを提供し、停止するまで実行され続けます。app pack と同様にランタイムを注入し、編集するたびに、パックが拒否する内容をファイル名と行を示して報告します。ハーネスは、機能、ビューポート、スクリーンの名前、タイムゾーン、パラメーター、ページタイマー、一時停止、ディスプレイ、離脱、デバイスイベント、そしてシリアルポート、GPIO ライン、Bluetooth LE ペリフェラル、プリンターをシミュレートします。emit と log の行はターミナルに出力されます。操作部分は ローカルで開発するで説明しています。

ディレクトリをパックし、新しいアプリケーションリリースとして公開し、公開の成功を待ちます。

app upload <directory> [--name NAME] [--no-wait] [--poll-ms MS] [--timeout MS]

screenrig app upload ./lobby-board --name "Lobby board"

3つのフィールドを読み取ります：data.operation.stateはsucceeded、data.application.release_idはrel_のIDでapplicationのプリミティブピン、data.application.idはapp_のIDでkvコマンドが使用します。成功した操作はリリースが使用可能であることを意味し、リリースID単独ではありません。

すべてのapp uploadは新しいアプリケーションと最初の不変リリースを作成します。同じアプリの後続リリースを公開するにはapp updateを使います。プレイリストは編集するまで既にピン留めされたリリースを提供し続けます。

中断したストレージへの転送は、アップロード URL が有効な間、最大 4 回試行されます。それでも失敗する場合は、同じコマンドをもう一度実行して同じアップロードを再開してください。

既存アプリケーションの新リリースを公開し、ID、名前、アプリケーションK/Vを保持します。

app update <id> <directory> [--expect-rev REVISION] [--no-wait] [--poll-ms MS] [--timeout MS]

screenrig app update app_01EXAMPLEAPP00000000000 ./lobby-board

名前はそのまま残ります。変更するにはapp renameを使います。data.operation.state: "succeeded"を待ってから、playlist replace-releaseを使って正確なページ、プリミティブ、新しいリリース、および影響を受けるスクリーンを確認してください。返されたインパクトトークンと、playlist workflowで説明されているオプションのリビジョンガードを使って適用します。既存のplaylistピンは適用まで変更されません。リビジョンの競合があった場合は、再試行するかどうかを決める前にアプリを再度読み込み、競合を回避するためだけに置き換えアプリケーションを作成しないでください。

プロジェクトのアプリケーション一覧

app list

パラメーターなし。

screenrig app list

アプリケーションの表示名を変更します。

app rename <id> --name NAME [--expect-rev REVISION]

screenrig app rename app_01EXAMPLEAPP00000000000 --name "Lobby welcome"

変更されるのは表示名だけです。アプリケーション ID、リリース、キー/値データ、リリースを固定しているプレイリストはそのままで、ディレクトリのアップロードも不要です。現在の名前に変更してもリビジョンは変わりません。名前は重複できます。アプリケーションは ID で指定してください。

1件のアプリケーションを読み込みます。

app show <id>

screenrig app show app_01EXAMPLEAPP00000000000

latest_ready_release は初回公開が ready に到達するまで存在しません。公開状態はオペレーションとリリースに紐づき、アプリケーションにはありません。last_used_at は、スクリーンが初めてアプリケーションを再生するまで存在しません。

アプリケーションとそのすべてのリリースを削除します。

app delete <id> [--expect-rev REVISION]

screenrig app delete app_01EXAMPLEAPP00000000000

リリースごとの削除はありません。スクリーンがアプリケーションのリリースを表示している間、削除はapplication_in_useで応答します：先にそれらのスクリーンに別のコンテンツを与えてください。削除はリリースをピン留めして表示しないプレイリストはチェックしないため、それらのプレイリストも更新または削除してください。

アプリケーションに保存されたキー一覧

kv list --app-id ID

screenrig kv list --app-id app_01EXAMPLEAPP00000000000

1件のキーを読み込みます。

kv get --app-id ID <key>

screenrig kv get --app-id app_01EXAMPLEAPP00000000000 menu

応答には値が data.value_base64 として含まれ、JSON の値もこの形式です。デコードし、data.content_type が JSON を示す場合にのみ JSON として解析してください。kv list は値を含みません。

JSON、ファイル、またはbase64バイトから1つのキーを書く。

kv set --app-id ID <key> --json-value JSON [--expect-rev REVISION]
kv set --app-id ID <key> --file FILE [--content-type TYPE] [--expect-rev REVISION]
kv set --app-id ID <key> --value-base64 BASE64 [--content-type TYPE] [--expect-rev REVISION]

screenrig kv set --app-id app_01EXAMPLEAPP00000000000 menu --json-value '{"soup":"lentil"}'

キーを1つ削除します。

kv delete --app-id ID <key> [--expect-rev REVISION]

screenrig kv delete --app-id app_01EXAMPLEAPP00000000000 menu

アプリケーションの 1 つのキー、または --card を付けるとカードのデータドキュメントを書き込むWebhookを作成し、そのURLとシークレットを一度だけ受け取ります。

kv webhook create <key> --app-id ID [--description TEXT]
kv webhook create --card CARD_ID [--description TEXT] [--map FILE|-] [--key-template TEMPLATE] [--signing]
                  [--verify VENDOR [--verify-secret-file FILE|-] [--verify-header NAME] [--verify-encoding hex|base64]
                   [--verify-timestamp-header NAME] [--verify-tolerance SECONDS]] [--handshake VENDOR]

screenrig kv webhook create menu --app-id app_01EXAMPLEAPP00000000000 --description "Point of sale menu feed"
screenrig kv webhook create --card crd_01EXAMPLEBOARD0000000000 --map alert-map.json --description "CMS alerts"

--map、--key-template、--signing、--verify（そのオプションを含む）、--handshake は、カード Webhook にのみ適用されます。

エンベロープはWebhookで、data.id (kvw_…)、data.key（カードでは data.card_id）、data.url (https://api.screenrig.ai/api/applications/<app_id>/kv-webhooks/<id>/write、またはカードでは https://api.screenrig.ai/api/cards/<card_id>/kv-webhooks/<id>/write)、data.secret (srkw_…) を含みます。署名するカードWebhookには data.signing_secret (whsec_…) も含まれます。URL とシークレットは今すぐ送信側のシステムに設定してください。後からどのコマンドでも再表示されません。作成が中断またはあいまいになった場合は、24 時間以内に同じコマンドを再実行してください。保存済みの冪等キーが再利用され、サーバーは新たに作成せず同じWebhookと同じシークレットを返します。

アプリケーションまたはカードのWebhookを古い順に一覧表示します。

kv webhook list (--app-id ID | --card CARD_ID)

screenrig kv webhook list --app-id app_01EXAMPLEAPP00000000000
screenrig kv webhook list --card crd_01EXAMPLEBOARD0000000000

各項目には id、key、description、url、created_at があり、書き込み後は last_used_at もあります。カードWebhookの項目には key の代わりに card_id があり、さらに mapping（送信されたオブジェクトがそのままドキュメントの場合は null）、enabled、signing、設定されていれば key_template、verify、handshake があります。リストにシークレットは含まれません。

Webhookを削除します。URLは即座に無効になり、キーまたはカードのドキュメントは値を保持します。

kv webhook delete <webhook_id> (--app-id ID | --card CARD_ID)

screenrig kv webhook delete kvw_01EXAMPLEWEBHOOK00000 --app-id app_01EXAMPLEAPP00000000000
screenrig kv webhook delete kvw_01EXAMPLEWEBHOOK00000 --card crd_01EXAMPLEBOARD0000000000

Webhookのシークレットを置き換え、一度だけ新しいものを受け取ります。

kv webhook rotate-secret <webhook_id> (--app-id ID | --card CARD_ID) [--signing]

screenrig kv webhook rotate-secret kvw_01EXAMPLEWEBHOOK00000 --app-id app_01EXAMPLEAPP00000000000
screenrig kv webhook rotate-secret kvw_01EXAMPLEWEBHOOK00000 --card crd_01EXAMPLEBOARD0000000000 --signing

エンベロープには新しいシークレットが data.secret に入ります。古いシークレットは即座に使えなくなるので、新しいシークレットを送信側のシステムに設定してください。--signing を付けた場合は、エンベロープに新しい署名シークレットが data.signing_secret として入り、Webhook の srkw_ シークレットはそのままです。ローテーションが中断またはあいまいになった場合は、同じコマンドを再実行してください。保存済みの冪等キーが再利用され、サーバーは再度ローテーションせず、すでに行われたローテーションの結果を返します。