mcpField
S
salla-app-functions-release

salla-app-functions-release

github.com/sallaappクラウド・DevOps279 回インストール2 週間前に更新
リポジトリ

salla-app-functions-release について

Salla App Functionsの保存、テスト、公開を進めるワークフロー向けスキルです。アプリ開発者向けに、デモストアへのデプロイ、プレビュー確認、セキュリティ審査、公開・非公開アプリの手順を扱います。

主な機能

  1. 01トリガー単位で関数を保存・更新
  2. 02デモストアへの非同期デプロイを追跡
  3. 03デモストアで関数をプレビュー
  4. 04公開・非公開アプリの公開を準備
  5. 05ソース内の秘密情報と危険な呼び出しを検査

活用シーン

  1. 01更新したトリガー関数をデモストアへデプロイ
  2. 02公開前に関数をテスト
  3. 03パートナー提出用の公開アプリ草稿を準備
  4. 04パートナーの確認後に非公開アプリを公開

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/sallaapp/salla-partners-agent-kit --skill salla-app-functions-release

インストール後、Claude Code で/salla-app-functions-releaseを入力して読み込まれたか確認します。

詳細

App Functions — 保存、テスト、公開

クリーンな検証に合格してからのみ保存してください(salla-app-functions-validate)。

保存(作成または更新)

アプリにはトリガーをキーとする関数が1つあるため、get/save/deleteにはapp_id とtriggerが必要です。saveは、そのトリガーの関数をアップサートします。

  • 保存: salla_functions action=save、app_id、trigger、content(関数全体を文字列として指定)、name。テンプレートの1行目はそのまま保持してください。デプロイのjobが返され、アプリのデモストアへの非同期デプロイが開始されます。salla_functions action=deploy_statusとjob(action=saveが返した値)を使って、COMPLETEDになるまでポーリングしてからテストしてください(salla-app-functions-test)。1回の保存でデプロイまで行われます。別途デプロイするアクションやバージョン管理はありません。
  • 読み取り: salla_functions action=get、app_id、trigger → template + types(.d.ts URL)+ アプリに保存されたcontent(またはnull)。
  • 削除: salla_functions action=delete、app_id、trigger。

上記のパラメーター名とジョブの形式は例示です。使用する前に、正確なフィールドをsalla_functionsで確認してください。

注:後から公開スナップショットに取り込まれたアプリ設定を変更した場合は、公開を再度開いて更新してください。詳しくはsalla-publication-consistencyを参照してください。関数のデプロイ自体を再保存する必要はありません。

公開前にテストする

salla_functions action=previewを使ってデモストアで実行してください。詳しくは salla-app-functions-testを参照してください。(手動で行う場合:Portalのプレビューパネルでデモ ストアを選び、実在するレコードIDを入力して、保存してプレビューをクリックします。)プレビューのログは表示されるため、ログにシークレットを含めないでください。詳しくは以下の公開前スキャンを参照してください。

公開(本番環境)

保存済みの関数が実際のマーチャントストアで有効になるのは、アプリの公開後のみです。saveを再実行しても有効にはなりません。公開アプリの場合、エージェントが公開を準備し、パートナーが申請します。非公開アプリの場合、パートナーの確認後にエージェントが公開します。

  • 公開アプリ: エージェントはapp_publish action=validateで公開内容を検証します。すべてのセクションを検証し、下書きを保存します(管理者による申請は行いません)。検証に問題がなければ、実際のPortalの/publishリンク(https://portal.salla.partners/apps/{app_id}/publish。実際のIDに置き換えます)をパートナーに渡し、下書きを確認してワンクリックで申請してもらいます。エージェントが管理者として申請することはありません。各手順(open → 各セクションをset → validate)の詳細なフローはsalla-publication-consistencyを参照してください。
  • 非公開アプリ: salla_private_apps action=publishで公開します(confirm: true。パートナーが確認した後に限ります。マーチャントパートナーのアプリは通常すぐに公開され、オンボーディングや掲載はありません)→ salla-app-builder → 非公開アプリ。

公開前のセキュリティチェック。 何かを申請または公開する前に、保存済みのcontent(salla_functions action=get)をスキャンしてください。ハードコードされたトークン、シークレット、APIキーがないこと、プレビューのログにcontextやマーチャントのPIIをデバッグダンプしないこと、範囲が広すぎるアウトバウンドのfetch呼び出しがないことを確認します。トークン/OAuthの処理は関数ではなくバックエンドで行ってください。詳しくはsalla-app-authを参照してください。Webhookの署名検証についてはsalla-webhooksを参照してください。

チェックリスト

  • payload.data を確認済み(salla-app-functions-design)・厳格な tsc チェックに合格(salla-app-functions-validate)。
  • 同期処理の本体が合計 5 秒の予算内(各内部非同期呼び出しは 2 秒未満);すべての fetch にタイムアウトを設定。
  • すべての経路で Resp.success().setData(...) を使用 — 空の場合は {}。
  • npm/未サポートのコア機能を使用しない;globalThis.crypto を使用;秘密情報/トークンをハードコードしない、PII をログに記録しない。
  • 実際のレコード ID を使い、デモストアに対してプレビューでテスト済み(salla-app-functions-test)。
  • 保存済み(action=save);公開アプリの場合は公開時の検証が問題なく完了し (app_publish action=validate → ドラフト)、パートナーが Portal の /publish リンクを利用できる状態; 非公開アプリの場合は、パートナーが salla_private_apps の公開を確認済み。

ゲート:「プレビューで Execution Status = success となり、タイムアウト予算内に収まり、セキュリティ スキャンに問題がなく、公開時の検証が問題なく完了してパートナーが送信する(公開アプリ)、または パートナーが確認し salla_private_apps action=publish confirm:true が 公開を返した(非公開アプリ)か?」

注意すべき点

つい考えてしまうことそれが誤りである理由
「プレビューに合格したので、非公開アプリを公開しよう。」パートナーが明示的に確認し、セキュリティスキャンに問題がない場合に限ります — マーチャントパートナーの非公開アプリは通常、すぐに公開されます。
「save が成功したので、マーチャントは新しい関数を使える。」保存したコードが実際のストアに反映されるのは、アプリの公開後のみです(公開アプリ:パートナーが送信;非公開アプリ:salla_private_apps action=publish)。
「公開アプリの公開申請を自分で送信しよう。」エージェントがドラフトを検証し、パートナーが Portal でワンクリック送信するか、send_publish_request を明示的に確認します。

コメント