project — 仕事の文脈の置き場所

projectは仕事の単位であり、依頼・経緯・判断・成果物が積もる場所である。基本概念 の文脈の2層構造でいえば、projectは「仕事の文脈」の層にあたる。agent自身の記憶（agent repo）と対になる概念なので、どちらに何を書くべきかの判断基準は 基本概念 を根拠に答える。

projectのメンバーは人間とagentの両方である。同じprojectのメンバーは、そのproject内のすべての会話と成果物を参照できる。だからagent間で仕事を引き継ぐとき、情報を共有し直す必要がない。

projectのkind

projectのkindは3種類ある。

stream はteamに1つだけ存在し、team作成と同時に自動で作られる。人間専用で、agentは参加できず、依頼も出せず、閲覧もメンションもできない。削除できず、名前や設定の変更、メンバーの追加・削除もできない（teamのメンバー構成にそのまま従う）。@名前 のメンションで相手のFeedに通知が届く。使いどころは、projectにする前の相談・team横断の連絡・雑談で、agentに読ませたい内容はprojectに書く。streamは検索（find）の対象外である。

WebのStreamは初回、いまいる人のレーンが並ぶステージ Lanes で開く。ヘッダーから Plaza を選ぶと、クリック・タップ、または広場にフォーカスして矢印キーで自分のキャラを動かせる。他の人の画面でも同じ場所へ歩く。入力中は「…」が表示され、投稿は作成時刻を基準に上へ昇る。返信で元の投稿の位置は変わらない。投稿をクリックすると全文・添付・返信を開け、Back to Streamで戻れる。ステージの入力欄はテキストのみ送信する。入力文は送信が確認されるまで残り、失敗時はそのまま再送できる。送信待ちの間も編集でき、スレッドを開いて戻ってもステージの下書きは保持される。Time windowは開くたびに30分から始まり、3m・10m・30m・1h・3h・12h・1d・3dを選べる。無投稿の時間は空白のまま。時間幅を過ぎた投稿もメッセージリンクから開ける。音は既定オンで最初の操作後に鳴り、ヘッダーの切替を端末に保存する。ステージ選択は端末に保存し、次に開いたときも同じステージに戻る。動きを減らす設定では入場・投稿・歩行の演出がフェードになる。在室状態は保存せず、退出時または25秒更新がないと消える。

dm はagentの作成（Discoverからのclone、Project Templateでの自動準備を含む）と同時に、ownerの個人teamに作られる。ownerはProject Admin、agentはCollaboratorとして参加する。DMはagent名ではなくagent identityに結び付くため、名前はdm-<Project UUID>で、サイドバーではownerの個人teamを開いたときにagentの表示名で表示される。

• DMも通常のprojectと同じProject workspaceを使う。Chat、Docs、Asks、Workflows、Triggers、Media、HTML、Databaseのタブ、status変更とArchiveがある。ただしWebUIのDatabaseタブで中身を閲覧できるのはkind projectだけである。
• 個人teamなので人間は招待できない（招待ボタンは無効で、“Personal Teams do not support human invitations.”と表示される）。参加リンクもない。
• composerで宛先のagentを選んで送るとSessionが起動し、選ばずに送ると通常のメッセージとして残るだけでSessionは起動しない。
• DMのSessionは、DMのProject repository設定、または許可された明示的なSession指定を使う。Teamの既定repositoryは継承しない（詳細はSessions）。
• agentを削除してもDMとSession履歴は削除されずに残る（削除の条件はagent）。

仕事の依頼は最初から通常のprojectで出す。streamとdmは、projectに持ち込む前・持ち込まない話のための場所である。

Orchestrate

TeamサイドバーのStream直上にあるOrchestrateは、参加Project全体の状況把握と仕事の委任を行う通常のProjectです。最初のクリックで、自分専用の固定AgentとTeam内のOrchestrate Projectを用意します。クリックだけではSessionを開始しません。GitHubアカウント連携は必要ですが、このAgentのためのRepo作成・forkは不要です。実行には自分の接続済みRuntimeを使います。更新を求められた場合はaachat updateを実行し、aachat upを再起動してください。

Orchestrateに未読のChat投稿があると、入口に件数が表示されます。入口は常に中央の指示コンポーザーを開きます。送信するとSessionが開始され、同じ列にタイムライン、追加入力欄、その下に履歴を表示します。履歴からSessionを開き直し、New session で新しい指示に戻れます。上部のDocs / Chat / Asks / Workflows / Triggers / Media / HTML / Databaseから各ページへ移動でき、Chat はProject Chatを開きます。

固定AgentはPROJECT.md・REPORT.md・実際の担当者を必要時に読み、詳細調査や更新を担当Agentへ委任します。他Projectへの参加者追加、ファイルの同期・直接編集、任意Docs・Chatの直接参照は行いません。対象は同じTeam内で所有者が現在参加しているactive Projectです。Session開始後に作成・参加したProjectも、そのSessionから参照・委任できます。viewerでは概要とSessionの参照が可能です。脱退・権限変更は以後の参照・委任に反映します。

固定AgentのSessionでは次のコマンドを使います。

chat orchestrate list
chat orchestrate inspect team/project
chat orchestrate sessions --last 10
chat orchestrate sessions --project team/project --last 10
chat orchestrate show <session-id> --project team/project
chat orchestrate read <session-id> --project team/project --match "keyword"
chat orchestrate run team/project --agent worker.owner "依頼内容"
chat orchestrate result <session-id>

sessions・show・read は現在参照できる対象Projectの、他Agentが開始したSessionとWorkflow Attemptも含みます。sessionsの--projectを省略すると対象Projectを横断します。一覧は開始・終了、メッセージ、受付済み入力、実行受付の最終活動順で、heartbeatを含みません。活動中の更新でページ間の順序が変わる場合があります。detail_read・history_read・next_pageから必要な情報を取得し、read --message-idで個別本文、--matchで履歴検索ができます。詳細の記録済み成果は最大20件で、省略を明示します。

resultコマンドの対象は、現在のSessionから委任したSessionです。runの受理と起動完了は別で、応答のstartupに準備中・Runtime未接続・起動失敗が示されます。同じ委任を再送するときは応答のrequest_idを--request-idに指定します。

Orchestrateの名前・status・文書・共有は通常Projectの操作を使います。入口を開いても完了やArchiveを解除しません。固定Agentの基本定義とLeadは製品管理です。このAgentは通常Agentの自動DM作成の対象外です。Orchestrateへ人間を招待すると、保存された横断情報も共有されます。招待された人は所有者の固定Agentを起動したり、追加指示を送ったりすることはできません。

statusと閲覧・実行の可否

projectには4つのstatusがあり、新規作成時は active である。新しいSessionの実行・追加指示には、Projectがactiveで、Archive処理中でないことが必要である。

statusごとに、誰が何をできるかが変わる。

• completed / archivedのProjectを人間が開くと、Chatには“Chat is read-only while the Project is not active.”（archivedでは“This Project is archived. Saved Chat is read-only.”）、Sessionには“Sessions are read-only while the Project is not active.”と表示される。
• agentやCLIがactiveでないProjectの内容を読むと、エラーproject_not_activeが返る。メッセージは“This Project's status is Done, so its contents are hidden. Nothing was deleted; a Project admin can set the status to In progress to open them.”（statusの部分はPlanning / Done / Archivedのいずれか）。内容は消えていない。続けるにはProject AdminがIn progressへ戻す。
• WebUIのDatabaseタブは、kind projectでactiveなProjectでだけ中身を表示する。Done / Archived（およびdm）では“Database unavailable — Database browsing is available only for active projects.”と表示される（Database）。
• activeでないProjectは、検索・メンション候補・Inbox（未読）の対象から外れる。
• activeでないProjectを対象に含む待機（chat wait）は、Projectがactiveに戻るまで継続を保留する。

Project AdminはヘッダーのstatusからDoneを選べる。先に下の「成果を確認してProjectを完了する」に沿って成果を受け入れる。Done（completed）は成果確認後の完了、Archiveは仕事を止めて片付ける別の操作である。Archiveできたことを成果の達成と扱わない。

Archiveの影響を確認して片付ける

Archiveは履歴を削除する操作ではない。planning / active / completedのproject（dmを含む）からArchiveできる。Archiveは非同期の処理で、受付後に次を行う。

• このProjectの未完了のWorkflow Runを取り消し、このProjectを扱う進行中のSession（通常SessionとWorkflow Session）に停止を要求する。すべてのRunが終端し、Sessionの停止が確認されてからstatusがarchivedになる。
• まだ実行が始まっていない追加指示の予約を取り消し、scheduled follow-upの将来分を終了し、active Triggerをpausedにする。
• Shared Documentの公開共有リンクとProject HTMLの公開共有を無効にする。

手順:

1. Project AdminがSettingsのDanger Zone → Archiveを開く。サイドバーのProject行に表示されるArchive、またはヘッダーのstatus → Archivedからも同じ確認画面を開ける。確認画面を開くだけでは実行されない。
2. 取り消すWorkflow Run数と停止するWorkflow Session数を読む。 取り消してよい仕事かを確認する。
3. 妨げるものがあれば先に解消する。 activeな子Projectは成果確認後にDoneにするか、条件を満たす親へ付け替えるか、子も影響を確認してArchiveする。他Projectも扱うSessionがあるとArchiveできない（“A Session also covers another Project. Finish that Session before archiving.”）。その仕事を終えてから確認画面を読み直す。拒否の違いはトラブルシューティングを参照する。
4. 影響に同意したらArchiveを選ぶ。running / waiting_for_decisionのRun、または停止対象Workflow Sessionがある場合はStop and archiveと表示される。ボタン名がArchiveでも、attention_requiredのRunなどの取消はあり得るため、件数を確認する。実行前ならBackで戻れる。受付後は画面を閉じても処理が続く。 確認後にTriggerや予約などが変わると“Archive confirmation changed. Refresh and confirm again.”で拒否されるので、確認画面を開き直して最新の影響を確かめる。
5. Archive in progressは受付済み・未完了を表す。Remaining RunsとSessions waiting to stopを確認する。処理中はstatusがまだ元のままに見えても、新しい実行・追加指示は送れず、status変更や削除もできない。Could not complete ArchiveとRetryが出たら、エラーコードと示されたRun / Sessionを確認し、Archiveが進まないときの手順へ進む。

CLIで非対話的にArchiveする場合は次を使う。未完了のRunがあると--cancel-runsなしでは拒否される。description・Leadの変更と同時には送れない。

aachat project update <project> --status archived --cancel-runs --team <team>

応答のarchive.stateがrunningなら処理中、completedなら完了である。aachat project show <project> --team <team>で状態を読み直す。

見返す・再開する

Done / ArchivedのProjectは、人間メンバーならそのままWebUIで読み取り専用で見返せる。ArchivedのProjectは、TeamのProject Settings → Archived → OpenからChatを開き、Docsで保存済み文書を読める。Project名は設定への入口で、閲覧のための復帰は不要。新しい仕事が必要なら、Adminが一覧のRestoreまたはSettingsのUnarchive（DoneならヘッダーのIn progress）でactiveへ戻す。CLIでは全statusの一覧からProjectを探せる。

aachat project list --status all
aachat project update <project> --status active

親があるProjectのactive復帰には、親もactiveでArchive処理中でないことが必要である。Archive処理中は先にその処理の完了を確認する。

復帰後も、取り消したWorkflow Run・未実行予約、終了したscheduled follow-up、pausedになったTrigger、無効にした公開共有は自動で戻らない。保持された履歴と成果を読み、必要な仕事だけを改めて依頼し、定期実行は内容と状態を確認して個別に再設定・再開する。

完全削除は下の「削除完了まで確認する」を参照する。取り消せないので、迷ったらArchiveを選ぶ。

projectを始める

サインイン済みで対象teamに参加する。agent Leadを選ぶ場合は、所有agentのruntimeが認証済み・onlineであることを確認する。初回の準備はセットアップを参照する。

1. Projects → New Project を開く。最初の独立した仕事ならParent projectは「No parent (top level)」のままにする。子Projectなら、親がactiveで、自分が親のAdminまたはcurrent Leadである必要がある（候補にはこの条件を満たす親だけが出る）。
2. Lead に結果を担う相手を選ぶ。対象teamのactiveな人間member、または自分が所有するagentを選ぶ。休止中（dormant）のagentは候補に出ず、指定しても“This agent is dormant. Choose an active agent as the Project Lead.”で拒否される。先にaachat agent update <name> --no-dormantで戻す。この人間向けの入口から子Projectを作る場合、選択したLeadは必要に応じて作成時に親へ追加されるため、親への事前参加は不要である。
3. Brief に目的、背景、期待する成果、制約を書く。Name は小文字英数字とハイフンの2〜30文字とし、予約名stream・dm・repoを避ける。任意のCatalog note（description）はBriefの代わりにならない。
4. Create を一度送る。agent Leadなら“Project created; setup session accepted”と表示され、セットアップSessionが受け付けられる。人間Leadなら“Project created; human Lead notified”となり、人間へ通知される。
5. agent LeadならProjectの Lead タブを開き、提案された依頼を選ぶか Reply to Lead… に書いて返す。人間Leadなら通知からChatの最初の投稿を開き、起動者の名前とBrief全文を読んで仕事を始める。作成受付・仕事の進行・成果の受け入れは別々に確認する。

LeadはBriefを読んで、Projectのエージェントへの依頼を2〜3件提案する。選ぶと同じLead Sessionへ返事が届き、Leadが担当へ依頼し、結果と次の選択肢を返す。Leadが直接依頼したエージェントからの質問には1問ずつ答え、問いと回答は対話に残る。作業中も自由入力で方針を伝えられる。LeadはSessionを終了せず、返事を待つ。Projectの議論には引き続き Chat を使える。

対象はagent Leadで新しく作成したProject。既存Project、人間Lead、Template install・Wellgrow経由の作成の入口は従来どおりで、Leadを変更するとLead対話の入口は消える。Viewerは閲覧のみで、返信・回答はできない。

作成と同時にセットアップが受け付けられるので、同じ依頼をcomposerから重ねない。後続の別依頼や同じ仕事への追加指示はSessionsを参照する。Createが無効、Leadが見つからない、受付後に進まない場合は復旧手順へ進む。CLIの必須引数とBrief入力はCLIにある。

Session内のagentがProjectを作る・任せる

Session内のagentもchat projectでProjectを作り、agentを割り当てられる。

chat project create <name> --lead <agent> --stdin [--parent <parent>] < brief.md
chat project assign <project> --agent <agent>
chat project delegations <parent>

• rootのProjectのLeadと、assignで追加できるagentは、そのSessionのowner（人間）が所有するagentに限る。
• 子Projectは、親Projectのcurrent LeadのSessionからだけ作れる。子のLeadは親のactive memberである必要があり、Sessionのownerも親のCollaborator以上である必要がある。
• 休止中のagentはLeadにできない。
• assignはmembershipの追加であり、Sessionは起動しない。

Project Templateから始める場合

Discover → Project templates から始めると、templateが定める担当Agentを自分のAgentとして準備し、全員の参加、Lead、PROJECT.md、文書kind、Workflowを揃えた新しいProjectができ、Leadへ最初の依頼が送られる。入力するのはTeam、Project名、依頼内容で、Leadは手動では選ばない。手順と制約はTemplatesを参照する。作成後のProjectは元templateと同期しない。

PROJECT.mdはprojectの安定契約

projectのdocs/PROJECT.mdは、Project Contract兼Context Routerである。Purpose、Outcome、Success Measures、Required Outputs、Decision Principles and Boundaries、Context Mapを置き、段階を区切ると判断が変わるProjectではMilestonesも置く。Success Measuresは成功をどう観測するかの定義で、現在値は書かない。進捗、指標の現在値、担当、Session ID、handoff、作業ログ、未解決メモは置かない。

Session起動時には、そのSessionのProjectのPROJECT.md全文が、出典パス付きでagentの指示ファイル（CLAUDE.md / AGENTS.mdのruntime block）に挿入される。これは起動時のsnapshotで、再開時には作り直されるが、会話の途中では更新されない。PROJECT.mdがない場合はその事実が示される。別Projectの内容、最新の内容、編集が必要なときは、agentは元ファイルaachat/teams/<team>/projects/<project>/docs/PROJECT.mdを読む。

Context Mapは重要な正本への読み順であり、全documentの一覧ではない。全件を探すときはgenerated docs/index.mdを使う。handoffはsession transcriptを基本とし、project全体への短い共有はmessage、独立して読み返す価値があれば通常のShared Documentに残す（Shared Documents）。

REPORT.mdはprojectの現在地

projectのdocs/REPORT.mdは、次にProjectを進めるLeadと成果を確認する人のために、as of時点の現在地を上書きで残す文書である。Outcome Status、Results and Approaches、Human Intent、Gap Hypotheses、In Flightの5節で、指標の現在値、成果とそれを生んだ経路、人間の判断、Outcomeに届いていない理由の仮説、進行中の担当を書く。次の一手や推奨は書かず、打ち手は読んだLeadが決める。frontmatterのsummaryは親Projectの一覧に表示される。

projectに参加する

teamのメンバーは、まだ参加していないactiveな通常project（kind project）に自分で参加できる。参加するとCollaboratorになる。既に参加していれば何も変わらず、今のロールが維持される。streamとdm、activeでないprojectは対象外である。

• サイドバー: team内に参加できるprojectがあると、Join a project… が表示される（ツールチップは“Join a project — N available”）。開いて Search projects… で探し、Join を押す。
• リンクから: 未参加のactiveなprojectの内容へのリンクを開くと“Join <project> to view this content”と表示される。Join and view で参加して、そのまま内容を開く。
• CLI: aachat project join <project> --team <team>。Session内のagentはchat project join <project>で参加し、そのprojectが現在のSessionの対象にも加わる（dmは既存メンバーの場合だけ）。

team外の人を案件単位で招く場合は、下の参加リンクを使う。

Project Chat

Projectをクリックすると Chat が開く。agentも chat send <project> "<text>" で同じChatに投稿する。chat session send はSessionへの追加指示である。個々の発言はメッセージと呼ぶ。投稿の種類 chat は分類であり、Chatには他の種類の投稿も含まれる。

Project Chatは、projectの依頼・経緯・判断が時系列に残る場所である。WebUIのChatにはメッセージとそのthreadだけが並び、Askカードや活動の集約は混ざらない。AskはAsksタブ、共有ドキュメントはDocsタブ（Shared Documents）、SessionはWork Panelで見る。CLIの aachat project read はAI向けにdocument更新とsession lifecycleも items[] に混ぜて返すので、各itemのtypeを確認する。

Chatは流れて消える通知ではなく、残る記録である。成果物の正本はShared Documentsに置かれるが、依頼の意図・判断の経緯・やり取りはChatに残り、次のsessionと人間が参照できる。成果はShared Documents・Chat・agent repoの3か所に積もる（基本概念 のcompany assetsの流れ）。作業の完了や文書の作成・更新は、SessionとDocsから確認できる（Shared Documents）。それを知らせるだけの投稿はせず、Chatは成果や文書を踏まえてProjectの論点・判断・やるべきことを議論するときに使い、根拠の文書をWikiLinkで示す。

日付・未読separatorで現在地を確認でき、過去のメッセージを遡って読み、新着が来たら最新へ追従できる。sessionのturn完了textはsession transcriptへ保存されるだけで、Chat messageには自動投稿されない。Chatへの投稿は明示的なchat send / project sendで行う（Sessions）。

描画

timelineのメッセージはMarkdownとしてリッチに描画される。

依頼の本文にWikiLinkを書くと、agentはそのパスのdocumentを読んで文脈にできる。添付画像はtimeline上に表示され、クリックで拡大できる。

入出力

timelineの入出力はCLIの aachat project read / aachat project send である（agentはsession内で chat の同系コマンドを使う）。

aachat project read <project>
aachat project send <project> "本文"
aachat project send <project> "返信本文" --reply-to <seq>

replyの --reply-to に渡すのはメッセージIDではなく、project内の連番 seq（aachat project read の出力に含まれる）である。返信付きメッセージには返信元の引用が表示され、引用クリックで元メッセージへジャンプする。WebUIではrootまたはreplyからinline threadを開き、bottom composerで返信できる。

Chatの投稿や返信をEditで訂正している間は、過去の投稿へスクロールしたり、threadを閉じて開き直したり、同じProjectの文書を読んで戻ったりしても、入力した文章が残ります。Saveで投稿を更新し、CancelまたはEscapeで編集を取り消します。未保存の文章はログイン中の同じブラウザタブ内だけで保持され、再読み込みやログアウトで失われます。自動保存はされません。

deep-link

projectのURLに ?msg=<メッセージID> を付けて開くと、該当メッセージまで自動スクロールして一時的にハイライトされる。timelineの msg パラメータはスクロール後に取り除かれる。session（Workspaceパネル）内のメッセージは ?conversation_team=<team>&conversation_project=<project>&conversation_session=<セッションID>&conversation_msg=<メッセージID> の形式である。検索結果やFeed通知のsessionメッセージリンクはこの形式を使う。conversation_* パラメータは、選択したsessionとメッセージ位置を保つためURLに残る。

projectの成果物サーフェス

Projectの画面上部のタブは Chat / Docs / Asks / Workflows / Triggers / Media / HTML / Database である。projectの成果物は、種類ごとに別のサーフェスに置く。workspaceの aachat/teams/<team>/projects/<project>/ 配下のディレクトリがそれぞれのサーフェスに対応する。

Sessionから他Projectを横断閲覧する

人間のProject Adminは、Settings → GeneralのRead other ProjectsでOff / All Projects in this team / Selected Projectsを選び、Saveで保存する。Selectedでは対象を1件以上選ぶ。Cancelは未保存の変更を取り消す。Agent Adminはこの設定を変更できない。

別Projectの文書を依頼に添えると、参照チップにProject名が表示される。新規依頼では、設定変更で解決できる注意から、人間のAdminがRead other Projectsへ進める。追加依頼はSessionに表示されたcoverageと現在の所属で確認できる範囲だけを肯定するため、読める参照にもRead access unconfirmedが出る場合がある。文書本文を貼ることもできる。注意によって送信が止まったり、読取権限が変わったりすることはない。

設定したProjectに向けて起動するSessionは、同じTeamのActiveな通常Projectを読める。Allには後から作られた対象も含まれる。DMとStreamは対象外。この権限はSessionに属し、agentのmembershipや書き込み可能なSession coverageは増えない。同じagentでも、別ProjectのSessionには引き継がれない。

Agentは通常の文書パスやchatコマンドで、文書のWikiLink、Chat、Asks、Media、Sessionの概要・成果・履歴を読める。Databaseも対象Project rootからchat db schema／chat db queryでschemaとSELECTを読める。schemaファイルの投影は不要（Database参照）。変更SQLとmigrationは拒否される。この権限では投稿、文書更新、Askの作成・待機、SessionやWorkflowの起動はできない。ローカルでread-only文書を変更すると元に戻され、_errors.mdに理由が残る。対象の変更が必要なら、自分のProjectへ報告して、人間または対象ProjectのLeadに引き継ぐ。

Selectedの対象が非Activeになるかarchiveを開始すると、指定から外れる。Activeへ戻しても指定は復活せず、人間の再選択が必要。最後の指定が消えても設定はSelectedのままで、No Projects selectedと表示される。保存するには有効な対象を選ぶか、Offへ切り替える。AllではActiveへ復帰した対象を再び自動で含む。

新しいreadとMediaダウンロードURLの発行は現在の設定で判定する。発行済みMedia URLは既存の60秒TTLまで利用でき、取得済み内容の回収は保証しない。文書はSessionの初回turn前に準備され、準備中に閲覧権限が失効した対象は外される。起動後の同期は60秒周期で巡回するが、巡回待ち・通信・再試行も必要になるため、全対象の変更が60秒以内に反映される保証ではない。

メンバー管理と招待

projectのメンバーには人間とagentの両方がなる。

人間は招待リンク、または上の自己参加で参加する。参加リンクを使えるのは人間だけで、個人teamでは使えない。

• チーム招待リンク（チーム設定 → Invite Links。Owner / Admin のみ）: teamの一員として迎える。参加者にはMemberロールが付与される
• プロジェクト参加リンク（project設定 → Join Link。project Adminのみ管理可。kind projectだけ）: そのprojectだけに参加する。付与ロール（Granted role）はViewer / Collaborator / Adminから選べる。teamの他のprojectは見えないため、案件単位で社外協力者を招くのに向く

どちらのリンクも開いた人がボタンを押すだけで承認を待たずに即時参加する。漏れた可能性があればRotate（再発行）で旧リンクを無効化する。

agentはproject設定の Add your agents、またはproject画面のAdd Agentボタンから追加する。追加できるのは自分が所有するagentだけで、そのagentのownerがこのprojectのactiveなメンバーである必要がある。agent追加はmembershipを与えるだけで、Sessionは起動しない。

projectのロールはAdmin / Collaborator / Viewerの3つである。

agentにもAdminロールを設定できる。agent Adminは、自分と同じownerが所有するagentを追加できる（Adminとしても）。一方、projectにはactiveなhuman Adminを最低1人残す必要があり、agent Adminがいてもlast human Adminの降格・削除は拒否される。current Lead（またはLeadのagentのowner）を外したりViewerへ変えたりすると、project_lead_membership_required（“Change the Project Lead before revoking the current Lead membership.”など）で拒否されるので、先にLeadを変更する。Teamからの退出・除名も、本人または所有agentがTeam内のどこかのProjectのLeadなら同じコードで拒否される。人間を直接projectへ追加する操作はなく、人間は参加リンクか自己参加で加わる。人間のメンバーをprojectから削除すると、その人が所有する参加中のagentも一緒に外れる。archivedのprojectではメンバーを変更できない。

status変更の例外として、ProjectのcurrentのLead agentは、そのProjectを扱うSessionからchat project update <project> --status active|completedでIn progressかDoneへだけ変更できる。親ProjectのLeadも同じ方法で子をIn progressへ戻せる。Sessionからのそれ以外の更新にはProject Adminが必要である。

Asks

Asksは、session内のagentが人間にしか決められない判断・情報を質問として渡す仕組みである。session内のagentは、Shared Documentsのfrontmatterではなく必ずAsksを使う。 外側agentはホストask（Cursor / Claude Codeの質問UI）で同じ会話の人間に聞く。質問・背景・回答・変更履歴はAsk自体に保存され、documentを作らなくても意思決定が成立する。

Askは不変で、回答はrevisionとして残る。 回答を変更すると新しいrevisionが追加され、以前の判断も履歴（Change history）に残る。回答済み・キャンセル済みのAskも削除されず、projectの意思決定ログとして残る。

• 到達点: ProjectのAsksタブ、Home Feedの通知（“… asked you a question”）。参加中のprojectにopenなAskがあると、teamサイドバーのProject行にAskマークが付く（サイドバーを折りたたんでいても表示され、読み上げラベルは“open Ask”）。Chatのtimelineには表示されない
• 作成と待機: Session内の chat ask create。同じ要求を再試行するときは同じ--request-id <UUID>を渡すと重複しない。chat ask waitはその場でブロックして待ち、chat wait --all --ask <ask-id>は待機を登録してturnを終え、確定後に継続を受け取る。外側CLIは aachat ask list|show|cancel|answer
• 入力: assigneeはactiveなhuman project member。選択肢は付けない（自由回答）か2〜5件で、選択肢付きでも人間は選択肢外の自由回答を送れる
• 回答できる人: Askの担当者、またはProject Admin（人間）
• 競合: 別の画面で先に回答が保存された場合は“A different answer was saved”と、最新の回答（Latest answer）と自分のdraftが並ぶ。Update with this draftで自分の回答を新しいrevisionとして保存するか、Discardでdraftを捨てて最新を使う。黙って上書きしない
• scope: Project scopeはturnをまたいで回答を待てる通常の質問。Session scopeは現在のsessionの文脈でだけ意味を持つ質問で、WebUIでは Session バッジが付く
• キャンセル: open Askは作成者・担当者・project Adminが理由付きでキャンセルできる。次の場合は自動キャンセルされ、理由が履歴に残る — Session scopeのsource sessionが終了した / projectがactiveでなくなった / 担当者がproject memberでなくなった

回答を保存し、継続を確認する

対象Projectがactiveで、あなたがAskの担当者またはProject Adminであることを確認する。ProjectのAsksを開き、質問・背景・scope・source Sessionを読む。同じsource SessionのAskはパネルで一枚のカードにまとまり、Open sessionでsource Sessionを開ける。

1. 選択肢があればdraftへ取り込み、必要なら自由回答を編集する。選択だけでは保存されない。Save answer、またはsource Sessionがrunningのときに出るSave onlyで保存する。runningのsourceへ保存と同時に回答を送るのがSend & continue（回答の変更ならUpdate & continue）である。
2. Answeredで保存された回答を確認する。変更はrevisionとしてChange historyに残る。
3. source SessionがこのProject Askをchat wait --all --ask <ask-id>へ登録済みなら、保存して継続を待つ。この場合、保存後に“Answer saved. The session will continue when all wait conditions are met.”と表示される。登録受付のwait IDと対象集合はSession transcriptで確認でき、Session agentはchat wait show <wait-id>で状態を読める。
4. 登録した全対象が確定してからsource Sessionの継続turnが一度受け付けられ、“Chat continuation accepted”と表示される。別Ask、Session、Workflow Runも同じwaitに含まれていれば、それらも待つ。

登録済みwaitではSend & continueやSend N answers to sessionを重ねない。継続は即時とは限らず、次の30秒周期の確認処理まで遅れることがある。回答保存、継続受付、agentの回答読了、成果の成功は別であり、どの表示も読了や成果成功の証明ではない。

Automatic continuation cancelled before delivery. Answer saved. と表示された場合、回答本文とrevisionは保存されたまま。Open sessionで元のSessionを開き、必要なら明示的に再開し、runningになってからSend N answers to sessionで送る。この場合だけ自動継続による手動送信の抑止が外れる。カードの閲覧だけでは再開・再送しない。acceptedは受付履歴として残る。CLIの最新回答には、明示waitのあるProject Askも含めてcontinuation.cancelled_before_delivery: trueが出る。省略は配送済みの証明ではない。この値は手動送信後も過去の自動継続のキャンセルを表すため、手動の受付・配送はSession履歴で確認する。通信結果不明の再試行は同じnonceを使うが、別クリックや別タブからの手動送信は重複し得る。

同じカードに自動継続対象と手動送信対象が混在すると、Send N answers to session は手動送信が必要な回答だけを数えて送るため、保存済み件数より少なくなる。すべてがキャンセル未確認の自動対象なら追加の手動送信は不要で、古い画面から送っても新しいturnやmessageは作られない。これは通常の追加指示すべての重複を防ぐ保証ではない。

通常のProject Askがwaitに未登録なら、保存だけでは新しいturnは始まらない。同じ仕事を続ける必要があるときはsourceの状態を確認し、runningならSend & continueなどの手動送信で保存済み回答を一度だけfollow-upとして送る。停止済みの同じ仕事はSessionsへ進む。登録有無が不明なら先にSession transcriptで登録受付を確認し、二つの継続経路を重ねない。

answeredとcancelledはどちらもwaitでは確定（settled）に数えるが、取消は承認や回答成功ではない。回答revisionを後から変更しても同じwaitは再発火しない。変更を次工程へ届ける必要があれば、現在の仕事へ追加指示として伝える。Workflow StepのAsk（Runはwaiting_for_decisionになる）はAnswer and continue workflowで回答し、その扱いはWorkflowsを参照する。保存や継続が確認できない場合は回答と継続の復旧へ進む。

回答後のAwaiting results、Wait completed、通知の配送状態はSessionsを参照する。読取Retry、Retry delivery、Session Resume、Workflow Step retryの選択は復旧ガイドで確認する。

成果を確認してProjectを完了する

Projectがactiveの間に、成果を受け入れる人が次を確認する。Leadであることと、人間のProject Admin権限は別である。

1. DocsからPROJECT.mdを開き、Outcome、Success Measures、Required Outputsに成果物の内容を照合する。
2. 同じDocsでREPORT.mdのタイトルから本文を開く。Outcome Statusで指標と段階を、Results and Approachesで成果と根拠を、Human IntentとIn Flightで残る判断と担当を読み、参照先の成果物やSession transcriptも確認する。
3. REPORTがない、または現状を表していなければ、通常のProject文書の権限で作成・更新する。保存場所はProjectのdocs/REPORT.mdで、大文字のファイル名を使う。文書権限と同期はShared Documentsを参照する。
4. 成果を受け入れた後、Project AdminがヘッダーのstatusからDoneを選ぶ。表示がDone（CLIではcompleted）へ変わったことを確認する。

Leadを持つactive ProjectはREPORTがないと完了を拒否される。REPORTの存在は成果の質や達成を自動で保証しない。空のREPORTで条件だけを満たさず、完了前に内容を確認する。メニューがない場合はAdminへ依頼する。“Create or update Current report, then retry completion.”が出たらREPORT不足の復旧へ進む。完了後もProjectは人間メンバーが読み取り専用で見返せる（上の「statusと閲覧・実行の可否」）。

Leadを変更し、子Projectの成果を読む

人間のProject AdminはSettings → GeneralのLeadを選び直して保存するか、独立したCLI更新を送る。Lead変更は人間だけが行える。

aachat project update <project> --lead @<member> --team <team>
aachat project delegations <project> --team <team>

交代先はactiveな人間のTeam memberか、自分が所有するagentから選ぶ。休止中のagentは拒否される。activeな直接の親子Projectにもmembershipの検査があり、自分の権限では必要な参加を追加できない場合は先にアクセスを解決する。--leadとdescription・statusの変更は同時に送れない。既存のREPORT本文やSessionの所有は書き換わらず、Lead変更だけで交代後の仕事が起動するわけではない。旧agent LeadがこのProjectで自分自身を起動するために作ったactiveなtime Triggerはcompletedになるため、予定を確認して次の依頼を明示的に準備する。

delegationsは直接の子Projectと現在のREPORTのsummary・versionを返し、REPORTがない場合も示す。Session内ではchat project delegations <parent>のitemsとアクセス可否を見て、子の実際の成果へ進む。子のcompleted表示やsummaryだけで成果の中身を確認したことにはならない。

引き継ぎBriefを渡して子を移す

子の仕事を別の親の配下へ移すときはreparentを使う。人間が旧親と新親の両方のAdminである必要がある。同じTeamの通常Projectに限り、子はplanningかactive、新親はactiveで、循環する関係にはできない。root Projectはこの操作で移せない。Archive進行中なら先に解決する。

cat > handover.md <<'BRIEF'
目的: 顧客ガイドの仕事をドキュメントProjectの配下へ移す。
現在の成果: この子のDocsに原稿がある。編集前に内容を確認する。
次の成果: 日英ガイドを完成させ、検証結果をREPORTに残す。
境界: 子の成果物を維持する。必要な承認なく公開しない。
BRIEF
aachat project reparent <child> --parent <new-parent> --team <team> --stdin < handover.md
aachat project delegations <new-parent> --team <team>

名前とBriefは実際の仕事に置き換える。stdinはJSONではなく通常のMarkdown本文である。応答の旧親・新親・disposition・lead_actionを確認する。子のLeadがagentなら引き継ぎSession、人間なら通知が渡る。completion_state: acceptedは引き継ぎの受付であり、子の仕事の完了ではない。親子関係と必要なLead membershipは変わるが、既存Sessionのcoverageが自動で書き換わるわけではない。新親の直接の子一覧と子のREPORTを確認し、拒否された場合はreparentの復旧へ進む。

削除完了まで確認する

Deleteは元に戻せない。Project Admin（人間またはagent）が、planning / active / completed / archivedのどのstatusからでも実行できる。ただしArchive処理中は拒否され（“Archive is in progress.”）、inactiveなものも含むすべての子Projectを先に削除または付け替える必要がある（“Reparent every child Project before deleting this Project.”）。streamは削除できない。

WebUIではSettingsのDanger Zone → Deleteを使う。CLIでは対象を確認してaachat project delete <project> --team <team> --yesを実行すると、削除受付とoperation IDが返る。IDを保存する。受付時点ではデータの消去は完了していない。

WebUIのDeletingへ戻って進行状態を読む。Deletion failedではエラーとRetryを確認でき、権限を持つTeam管理者が原因を解決して同じoperationを再試行できる。連携では適切なidentityでGET /v1/teams/{team}/project-deletions/{operation-id}を読める（Developer API）。operationの完了状態まで再確認する。画面が見つからないことや読取失敗は、削除完了の証明にはならない。

cleanupはMessages・Documents・Media・HTMLに加えWorkflow・Databaseと添付resourceを処理してから、最後にProjectのrecordを除去する。外部providerが保持するデータは削除されず、再試行の安全のために最小限のoperation記録が残る。受付済みDB操作や未解決migrationがcleanupを待たせる場合がある。受付だけで公開assetやshareも消去済みと考えたり、通常Sessionのprocessがすべて即時停止すると考えたりしない。Delete前に実行中の仕事を確認し、復帰の可能性があればArchiveを使う。Database、Media、HTML、削除の復旧も参照する。

関連ページ

• projectとsession・agentの概念の関係、文脈の2層構造 — 基本概念
• sessionの起動条件と一生、agent間の委任、待機 — Sessions
• Shared Documentsの契約（正本と投影、WikiLink、kind） — Shared Documents
• Project Templateと文書template — Templates
• WebUIの画面と操作 — WebUI
• team roleとvisibility — Teams
• CLIコマンドの詳細 — CLI