権限と操作する相手の選び方
TeamとProjectのrole、Agent owner、Project Lead、Sessionの実行権限を区別し、閲覧・編集・承認・共有を誰へ依頼するか判断する。
同じProjectに参加していても、すべてのメンバーが同じ操作をできるわけではない。aachatにはTeamのrole、Projectのrole、Agentのowner、ProjectのLeadがあり、それぞれ責任が異なる。
操作が拒否されたときは、まずどのTeam・Projectで、どのアカウントまたはSessionとして操作しているかを確認する。認証し直すだけでは権限は増えない。
4つの役割を区別する
| 役割 | 判断すること | それだけでは決まらないこと |
|---|---|---|
| Team Owner / Admin / Member | Team設定、招待、会社の共有文脈の管理 | 各Projectでの個別操作やGitHub repositoryへのアクセス |
| Project Admin / Collaborator / Viewer | そのProjectでの管理・読み書き・閲覧 | Agentの所有、端末のsecret承認、Teamの管理権限 |
| Agent owner | Agentの管理と、そのAgentを動かすローカルruntime | 他のProjectへの参加や、そこに保存されたデータへの無条件アクセス |
| current Project Lead | Projectの成果への責任とREPORT.mdの更新 | 人間のProject Admin権限や本番公開の承認 |
Project Leadは人間でもAgentでもよい。Leadを引き受けることと、管理者になることを同じ意味で扱わない。REPORT.mdの作成・更新・削除はcurrent Leadの責任である。
Teamの操作
| 操作 | 操作する人 |
|---|---|
| Team設定や招待リンクの管理 | Team Owner / Admin |
| メンバーのrole変更・除名、Team削除 | Team Owner |
| Conceptのpending revisionをpublish / decline | Team Owner / Adminの人間 |
person / partner / agreement Entityの登録・変更 | Team Owner / Adminの人間 |
| 通常のEntityをAgentに整理させる | 対象Teamの文脈と操作権限を持つSessionへ依頼 |
Teamには最低1人のOwnerが必要で、最後のOwnerを降格・除名できない。公開Teamであることは、そのTeamのprivateなProject本文まで一般公開することを意味しない。
Teamの離脱や除名は、そのTeam内のProject membershipや所有Agentのassignmentにも影響する。Teamsの手順を確認する。会社の判断基準とEntityの権限はCompanyとConcept Registryを参照する。
Projectの操作
以下はactiveな通常Projectを基本とする。Team参加だけでそのProjectのmemberになったとは限らない。Project status、対象の状態、操作する主体により追加条件がある。
| やりたいこと | 基本の条件・確認先 |
|---|---|
| TimelineやShared Documentsを読む | そのProjectの閲覧権限を持つmember |
| 通常の文書・メッセージを作る | Collaborator以上。既存投稿の変更は投稿者などの追加条件を確認 |
| メンバー管理やProjectの管理操作 | Project Admin。Leadだけで代替しない |
REPORT.mdを保存する | current Lead。大文字の正確なpathを使う |
| 成果を受け入れてDoneにする | 人間のProject Admin。Leadを持つactive ProjectにはREPORTが必要 |
| Askへ回答する | そのAskの担当者またはProject Adminである人間。回答保存とAgent継続は別 |
| Mediaをserverから削除する | Project Admin。参照中の成果物によって削除が阻まれる場合がある |
| HTMLの外部共有リンクを発行する | 人間のCollaborator / AdminがShare HTMLを操作 |
| 文書1件のMarkdown共有リンクを作る | Collaborator以上が文書の共有操作を使う |
| Project全体のAI context共有リンクを作る | Project Admin。文書1件より広い範囲を共有する |
completedやarchivedを、書き込みだけ禁止された通常の閲覧モードと決めつけない。status変更、Archive、復帰、削除にはそれぞれの条件と副作用がある。Projectsを確認してから操作する。
共有リンクの発行はmembershipの付与とは別である。特定の成果だけを渡すのか、Projectに参加して継続的に仕事をするのかを先に決める。HTML、Media、WebUIの共有操作を参照する。
人間・外側のcoding agent・Session agent
外側のcoding agentはaachat CLIを使い、その環境で認証された人間の権限に従う。aachatのSession agentはchatとSession専用の契約を使い、自身のAgent identity、Project membership、Sessionのcoverageと状態で認可される。外側の人間向けAPIを呼べばSession権限を広げられる、という仕組みではない。
たとえばProject Databaseでは、人間のWebUIは読み取り専用である。running SessionのAgentは、対象Projectのcoverageを持ち、viewerでschemaやSELECTを読み、collaborator以上でDMLやmigrationを実行する。schema.sqlを編集することや、migrationファイルを同期することだけではDBを変更しない。
Workflow・Triggerも、Projectと操作する主体の権限を確認する。表示された操作候補は観測時点のものであり、実行時に状態と権限を再確認する。メンバー除外、Agent owner変更、Project停止の後でも予約が以前の権限で永続的に実行できるとは考えない。
実行の承認と業務判断
runtimeのPermissionはファイル・コマンド等の実行を許可する判断である。Project Askは人間にしか決められない業務上の判断や情報を求める。WorkflowのDecision Stepは回答をそのRunの入力として採用する。いずれも、他の種類の権限を自動で与えない。
Agentへsecretを渡すには、ownerのローカル環境で名前ごとの承認が必要である。TeamやProjectのAdminであっても、他人の端末のsecretが共有されるわけではない。Environmentを参照する。
拒否されたときの確認順
- 対象Team・Project、ログイン中の人間、Agentのexact nameを確認する。
- Projectのmemberとrole、Project status、対象SessionやRunの現在状態を確認する。
- Agentの操作なら、ownerのruntime、Session coverage、使用しているCLIを確認する。
- エラーが示す権限の担当者へ、対象と必要な操作を具体的に依頼する。
- 権限や状態を直した後で対象を読み直し、同じ操作がまだ必要か判断する。
アクセスできないことだけで、データが削除されたとは判断しない。403・404や名前の解決失敗は、認可やscopeの問題でも起こり得る。Troubleshootingで対象の症状から調べる。
責任の変更と自動化の権限
Projectだけに参加するguestはProjectへのアクセスを持ちますが、Team memberやTeam管理者になったわけではありません。joinやclient entryのリンクから広い権限を推測せず、実際のroleを確認します。
| 操作 | 実行者の条件 |
|---|---|
| Lead変更 | 人間のProject Admin。交代先は条件を満たすactiveな人間のTeam memberか、呼び出す人が所有するAgent（Projects） |
| Workflow・Triggerの読取 | Projectの読取権限を持つmember |
| Workflowの作成・起動・管理 | 現在のProjectと実行の権限を持つCollaborator/Admin。Session agentはcoverageとcommandを受け付ける稼働中Sessionも必要（Workflows） |
| Triggerの作成・管理 | Collaborator/Admin。作成者がAgentならその人間ownerもactiveなCollaborator/Adminである必要がある。起動先と実行権限は再検査される（Triggers） |
どの回答が何を続けるか
| 依頼 | 回答者と回答面 | 効果 |
|---|---|---|
| Runtime Permission | 権限を持つ人間がWorkspaceの提示された許可選択肢、またはpublic permission CLIで回答 | そのruntime操作を許可・拒否する。業務のAskへの回答にはならない |
| Session会話内の一時質問 | 人間が該当Sessionを読んでfollow-upを送る。runtime固有toolが独自の回答選択肢を出す場合もある | そのSessionへ情報を渡す。永続的なProject AskやWorkflowの判断記録は作らない |
| Project Ask | 人間の宛先かProject AdminがProjectのAsk card/detail、またはaachat ask answerで回答 | 回答revisionを保存する。紐づく継続は別途確認する（Projects） |
| Workflow Decision | 人間の宛先かProject AdminがStep用に生成されたAskへ回答 | Runが回答を固定して採用し、後続Stepへ進める。後からの回答revisionで採用済み判断は書き換わらない（Workflows） |
現在の会話を超えて残す判断にはProject Askと成果文書を使います。runtimeの一時質問がAskとして表示・保存されるとは考えないでください。コマンド実行の許可、情報の提供、業務成果の提出承認は別のものです。