複数チームを支援するAgentは、複数アカウントと空間へ接続します。同名Baseや複数Spaceへの権限があると、「顧客表を更新」だけでは宛先が一意に決まりません。成功はアクセス可能な先が要求を受けた証拠にとどまります。
宛先違いでも権限エラーが出るとは限りません。host、本人、Space、Base、recordをタスクごとに固定し、別端末の活動設定に左右されないようにします。
設定の解決順を知る
優先順は個別flags、config、profile、活動中アカウントの.env、既定値です。exportされた環境値はディスク設定より優先されます。コマンドと上書きの有無を確認し、token値は出しません。
auth switchは共有の.envを書き換え、読むSkillやスクリプトも追随します。並行する二つの端末で活動状態を固定先と見なさないようにします。単発のprofile指定は共有ファイルを変えず、独立configも使えます。自動実行ではbase URLとSpace IDも明示します。
宛先を五層に分ける
CLIガイドはアカウントを認証、ワークスペースを作業空間として区別します。Cloudの一つのアカウントは複数空間に参加でき、CLIではspace、--space-id、APIではx-busabase-spaceを使います。自前サーバーは単一空間を返します。
ホスト、account/profile、Space ID、Base ID、record IDを残します。新規なら安定した業務キーを指定します。Folderの所属も確認し、名前は人の識別補助に使います。認証情報がアクセス可能なことだけでは業務対象が正しいとは決まりません。
並行タスクがそれぞれ宛先を持つ
手作業の切替は便利でも、並行実行は明示profileか独立configと固定host/Spaceを使います。一件の切替で別タスクの依存を変えないようにします。まず一件を、指定、読取照合、限定提案、正式値回読まで通せば、どこへ書いたかの根拠が残ります。
読み取りで一致を確認する
指定設定のwhoami、Folder、Baseの所属とschemaを読みます。更新ならレコードの現在内容とheadを確認します。期待値は承認済みタスクから取り、実測値と比較します。
秘密なしの一覧にホスト、別名、本人、Space、Folder/Base、レコード、変更許可項目を残します。ホスト違い、アクセス不可、所属不一致、同名の曖昧さ、意味の違うレコードなら停止します。別の同名表へ置き換えたり、成功するまで別アカウントを試したりしません。
指定profile、base URL、Space IDで本人とFolder、Base、レコードを読み、タスクIDとの一致と衝突を示してください。認証値を表示せず、共有設定切替、設定変更、変更提出は行いません。
対象を限定して変更を提案する
確認後は同じ設定を使用し、変更対象と項目を限定したChangeRequestを提出します。現在版を確認してから更新します。レコード書き込みは監査経路を残し、書き込み権限では即時マージ、別の条件では審査待ちになる場合があります。CRが返っただけで正式値の変更とはしません。
人の審査が指定されていればそれを守ります。宛先確認は本文の承認ではありません。接続テストのために無関係な正式レコードも作りません。
接続成功だけでは確認できない対象情報
whoamiで本人を確認しても、Baseとレコードの確認は残ります。期待IDをタスクに置き、実際の所属とschemaを読みます。同名の表が見つかっただけで宛先を推定しません。
並行実行はprofileか独立config、host、Spaceを引数で持たせます。共有の活動設定を変えるなら依存中の他実行を先に確認し、失敗のたびに別アカウントを試しません。
正式な結果を読み戻す
CRの状態と操作先を確認し、固定したhost、Space、Baseからcanonicalを再読します。対象項目と変更しない項目も比較します。終了コードだけでは宛先は証明できません。
タイムアウト時は元CRと正式状態を読んでから再試行を判断します。新規の安定キーと元提案を残し、結果不明のまま重複作成しません。
既存の実行Baseに、ホスト、別名、リソースID、許可項目、元head、CR ID、状態、回読根拠を保存する設計が考えられます。これは管理案であり、自動隔離ではなく、tokenを保存しません。