Jinba Trailのすべてのオートメーション、APIキー、スケジュールは組織に属します。メンバーページ（/org/members）には、組織に誰が所属していて、何ができるかが表示されます。

​
階層ではなく2つのロール

Jinba Trailのロールは正確に2つだけです。第3の階層やカスタム権限セットはありません。

オーナー

フルコントロール: メンバーができるすべてのことに加えて、以下のすべての組織管理操作を実行できます。

メンバー

組織への読み取りアクセス: オートメーション、Run、自分のダッシュボード表示を確認できます。組織自体は管理できません。

​
オーナー限定の操作

次の変更操作はサーバー側で requireRole(wrapper, "owner") によってガードされています。メンバーがこれらのルートを直接呼び出すと、単にボタンが非表示になるだけではなく、403 forbidden が返されます。
  • APIキーの発行と失効
  • オートメーションの公開（レビュー済みの手順をライブエンドポイントにコンパイル）
  • スケジュールの変更（オートメーションのcronトリガーを作成、更新、削除）
  • メンバーシップの変更: 別のメンバーの追加、削除、ロール変更
  • オーサリングの変更: Build Studioでオートメーションを作成または編集
  • オートメーションのMCP公開状態の切り替え
  • 監査ログの表示
メンバーにもダッシュボードへの読み取りアクセスはあります。オートメーション、Docsページ、実行履歴を確認できます。ガードされるのは、組織の設定や公開済みエンドポイントを変更するものです。
ダッシュボードもこの挙動に合わせています。メンバーページでメンバーが見る各操作は、クリックして失敗するコントロールではなく、ツールチップ “この操作を実行できるのは組織オーナーのみです。” とともに無効化されています。これはUI上の配慮にすぎません。実際のゲートはサーバー側のロールチェックなので、メンバーがAPIを直接呼び出して回避することはできません。

​
メンバーを追加する

オーナーは、メンバーページまたは POST /api/members から、メールアドレスでチームメイトを追加します。 
{ "email": "teammate@example.com", "role": "member" }
招待を承認するフローはありません。メンバーの追加は即時です。（org, user）のメンバーシップエッジが同期的に作成され、そのメールアドレスに対応するアカウントがまだ存在しない場合は自動的にプロビジョニングされます。追加された人が承認すべき保留中のものはありません。オーナーがフォームを送信した時点でアクセスできます。
すでにメンバーである人を再度追加すると、409 already_member が返されます。

​
最後のオーナーを守るガード

組織には常に少なくとも1人のオーナーが必要です。そのオーナーが組織に残っている唯一のオーナーである場合、オーナーをメンバーに降格する操作とオーナーを削除する操作はどちらも 409 last_owner で拒否されます。
  • PATCH /api/members/:userId（ロール変更）: 対象がオーナーで、新しいロールが owner ではなく、現在の組織にオーナーが正確に1人しかいない場合は拒否されます。
  • DELETE /api/members/:userId（削除）: 同じ条件で拒否されます。
ダッシュボードでは、最後のオーナーに対するロールセレクターと削除ボタンが事前に無効化されます（ツールチップは “組織には少なくとも1人のオーナーが必要です。”）。そのため実際にガードに当たる前に確認できますが、UIの表示にかかわらず、この不変条件はサーバー側で強制されます。
メンバーはいつでも削除でき、ロールも自由に変更できます。最後のオーナーを守るガードがブロックするのは、残っている唯一のオーナーに対する操作だけです。

​
監査される内容

すべてのメンバーシップ変更は、監査ログ（表示できるのはオーナーのみ）にエントリを書き込みます。member.added、member.role_changed、member.removed のそれぞれに、操作を行ったセッションと影響を受けたユーザーが記録されます。

​
次のステップ

PlaygroundとAPIキー

オートメーションの呼び出しに使うキーを発行または失効できるのは、オーナーだけです。

Build Studio

オートメーションの記録、レビュー、公開はオーナー限定です。