権限と操作する相手の選び方

同じProjectに参加していても、すべてのメンバーが同じ操作をできるわけではない。aachatにはTeamのrole、Projectのrole、Agentのowner、ProjectのLeadがあり、それぞれ責任が異なる。さらにProjectのstatusと、操作する主体が人間かAgentかによって、できることが変わる。

操作が拒否されたときは、まずどのTeam・Projectで、どのアカウントまたはSessionとして操作しているかを確認する。認証し直すだけでは権限は増えない。

4つの役割を区別する

Project Leadは人間でもAgentでもよい。Leadを引き受けることと、管理者になることを同じ意味で扱わない。

Teamの操作

Teamには最低1人のOwnerが必要で、最後のOwnerを降格・除名できない。公開Teamであることは、そのTeamのProject本文まで一般公開することを意味しない。

Teamの離脱や除名は、そのTeam内のProject membershipや所有Agentのassignmentにも影響し、本人か所有AgentがProjectのcurrent Leadなら拒否される。Teamsの手順を確認する。Teamの共有知識はTeam Wikiを参照する。

Projectの操作

以下はactiveな通常Projectを基本とする。Team参加だけでそのProjectのmemberになるわけではない。Team memberは未参加のactive ProjectへCollaboratorとして自己参加でき、Project参加linkで入った人はlinkに設定されたroleになる（Teams、Projects）。Project status、対象の状態、操作する主体により追加条件がある。

Project statusと読み書き

書き込みと、Agentによる操作はすべてactiveなProjectが必要である。人間のmemberはDoneとArchivedのProjectを読み取り専用で開ける。

内容を読めない場合はproject_not_active（statusはPlanning / Done / Archivedとして示される）が返る。WebUIではactive以外のProjectに「Chat is read-only while the Project is not active.」「Sessions are read-only while the Project is not active.」と表示される。

Done / Archivedは読み取り専用で開けるが、Sessionの実行・追加指示、メッセージ送信、メンバー変更、共有リンクの発行はできない。Archiveは既存のMarkdown共有リンクをrevokeし、HTML共有リンクを削除する。status変更、Archive、復帰、削除にはそれぞれの条件と副作用がある。Projectsを確認してから操作する。

共有リンクの発行はmembershipの付与とは別である。特定の成果だけを渡すのか、Projectに参加して継続的に仕事をするのかを先に決める。共有、HTML、Mediaを参照する。

人間・外側のcoding agent・Session agent

外側のcoding agentはaachat CLIを使い、その環境で認証された人間の権限に従う。aachatのSession agentはchatとSession専用の契約を使い、自身のAgent identity、Project membership、Sessionのcoverageと状態で認可される。外側の人間向けAPIを呼べばSession権限を広げられる、という仕組みではない。

Session内（環境変数AA_SESSION_IDがある）で人間の権限を使うaachat操作を実行すると、outside agent専用であるというエラー（invalid_argument）で拒否され、chatを使うよう案内される。対象はaachat ask answer、aachat ask cancel、aachat db、aachat trigger、aachat workflow、aachat skill feedbackである。aachat session permission、aachat session schedule、aachat session compactも同様に拒否される。Session内のaachat session listの行参照はchat session show <id> --project <team>/<project>を指し、aachat session readの--decisionなどの外部専用viewもinvalid_argumentで拒否される。返されたnext_actionsに従う。

たとえばProject Databaseでは、WebUIのDatabase画面は閲覧専用である。activeなProjectで、外側の人間はaachat db、running SessionのAgentは対象Projectのcoverageを持ってchat dbを使う。どちらもViewerでschemaやSELECTを読み、Collaborator以上でDMLやmigrationを実行する。schema.sqlを編集することや、migrationファイルを同期することだけではDBを変更しない（Database）。

Workflow・Triggerも、Projectと操作する主体の権限を確認する。表示された操作候補は観測時点のものであり、実行時に状態と権限を再確認する。メンバー除外、Agent owner変更、Project停止の後でも予約が以前の権限で永続的に実行できるとは考えない。

実行の承認と業務判断

runtimeのPermissionはファイル・コマンド等の実行を許可する判断である。Project Askは人間にしか決められない業務上の判断や情報を求める。WorkflowのDecision Stepは回答をそのRunの入力として採用する。いずれも、他の種類の権限を自動で与えない。

Agentへsecretを渡すには、ownerのローカル環境で名前ごとの承認が必要である。TeamやProjectのAdminであっても、他人の端末のsecretが共有されるわけではない。Environmentを参照する。

aachat session permission respondは、保存済み回答のreceiptを返すserverが必要である。旧serverの空の応答や配送情報だけの応答は受理しない。回答が保存されても配送を確認できない場合はwarningで示す。再回答を判断する前に、現在のPermission状態を確認する。

拒否されたときの確認順

1. 対象Team・Project、ログイン中の人間、Agentのexact nameを確認する。
2. Projectのmemberとrole、Project status、対象SessionやRunの現在状態を確認する。
3. Agentの操作なら、ownerのruntime、Session coverage、使用しているCLI（Session内はchat）を確認する。
4. エラーが示す権限の担当者へ、対象と必要な操作を具体的に依頼する。
5. 権限や状態を直した後で対象を読み直し、同じ操作がまだ必要か判断する。

アクセスできないことだけで、データが削除されたとは判断しない。403・404や名前の解決失敗は、認可、scope、Project statusの問題でも起こり得る。memberでないTeamやProjectは404として見える。Troubleshootingで対象の症状から調べる。

責任の変更と自動化の権限

Projectだけに参加するguestはProjectへのアクセスを持つが、Team memberやTeam管理者になったわけではない。joinやclient entryのリンクから広い権限を推測せず、実際のroleを確認する。

どの回答が何を続けるか

現在の会話を超えて残す判断にはProject Askと成果文書を使う。runtimeの一時質問がAskとして表示・保存されるとは考えない。コマンド実行の許可、情報の提供、業務成果の提出承認は別のものである。