ae-things

Workspace Things

ae-cli things を使用して、明示的に指定された現在の TE スペース内の Things を管理します。まず CLI リファレンス をお読みください。ID を推測したり、別のスペースを自動的に選択したりしないでください。返信とユーザー向けの Thing コンテンツにはユーザーの言語を使用し、コマンド、フラグ、フィールド識別子は変更しないでください。

Things を作成するタイミング

Thing を作成するかどうかを積極的に判断してください。「Thing を作成して」などの明示的な依頼を待たないでください。 個人用スペースと共有スペースのどちらにも、同じルールを適用します。

次のいずれかの兆候があれば、事前に確認せず Thing を直接作成してください。

• 「A に X の調査を、B に Y の調査を依頼する」のように、誰が何をするかが示されている。
• 「最終提案を作成する」「この頻度で進める」「作業をスケジュールする」など、成果物と実行の意図が結び付いている。
• 会話に、取り組み、ToDo、次のステップ、マイルストーン、段階的な計画が含まれている。
• ユーザーが合意済みの決定を再確認し、実行を示唆している。

次の場合は Thing を作成しないでください。

• 情報を求める質問、概念の説明、または気軽な会話。
• 選択肢を比較している段階である、議論が仮定上のものである、またはユーザーが決定をまだ行わないよう明示している。
• 重複チェックで同等の Thing が見つかった場合は、重複を作成するのではなく、その Thing を伝える。
• ユーザーが Thing を作成しないよう指示している。

判断に迷う場合は、提案する Thing（タイトル、担当者、説明の概要）を返信に記載し、一度だけ確認を求めてください。割り当てを単にリストに整形するだけでは、十分な対応ではありません。

作成手順

1. 明示的な AgentSpace がバインドされていることを確認します。バインドされていない場合は、Thing を作成しないでください。
2. members を使用して、会話中に挙がった名前をメンバー ID に対応付けます。一意に一致する場合は --assignee-id として指定します。一致がない、または複数一致する場合は担当者を省略します（サーバーが現在のユーザーを既定値として設定します）。解決していない担当者については返信で伝えてください。
3. list --query または options --query で重複をチェックします。
4. Thing ごとに create を実行します。ユーザーの言葉を繰り返すのではなく、成果物を名前にし、目標と受け入れ基準を説明に記載して、べき等な再試行のために --command-id を含めてください。
5. 必要に応じて、conversation bind で主要な Thing をバインドするか、link-conversation で通常の参照を追加します。
6. 作成した Thing の番号、タイトル、担当者を報告し、確認待ちの割り当ても含めてください。

粒度： 独自の担当者を持つ、個別に成果を出せる単位ごとに Thing を 1 つ作成します。Things にサブ Thing やグループはありません。階層を作らないでください。たとえば、「A、B、C がそれぞれ 1 つの領域を調査し、その後、結果をまとめて最終提案を作成する」は、1 つでも文ごとに 1 つでもなく、4 つの Thing に対応します。

認可の境界

新しい Thing の作成と、作成直後の Thing への最初のエントリーの追加は、自律的に行ってください。

ユーザーが進行または完了を許可した Things については、関連する進捗を直接自動的に追記または更新し、この作業に関わる成果物ファイルを自動的に添付してください。以下の説明に従って、公開と読み戻しを完了します。このルールは個人用スペースと共有スペースの両方に適用されます。公開には引き続き --confirm-share が必要です。Thing の作業を遂行する許可には、その成果物ファイルを Thing のスペースと共有する許可も含まれます。

既存の Things に対するその他の変更、担当者の再割り当て、アーカイブまたは復元、バインド解除、完全削除には、引き続き明示的な許可が必要です。過去にバインドされていたことだけでは、許可されたことにはなりません。メッセージの自動送信やスケジュールされたタスクの作成は行わないでください。

成果物の添付ワークフロー

進捗を追記または更新する際は、この作業で実際に納品した各ファイルを確認してください。

1. asset available を使用してスペース内のファイルを調べ、すべてのページを確認します。登録済みファイルは assetId で、未登録ファイルは返された相対パスでリンクします。
2. スペースにまだない新しいファイルには asset publish を使用します。この実行で生成された未登録の出力には --conversation-id --run-id --source-path を、既存の成果物には --artifact-id / --file-token を使用します。ファイルごとに別の commandId を指定し、再試行時も同じ値を再利用します。
3. linked:false は、ファイルは公開されたもののリンクされていないことを意味します。返された assetId を使って asset link を実行し、再コピーせずにリンクを完了します。この作業の成果物ファイルのみを公開し、一時ファイルや会話ディレクトリ全体は公開しないでください。
4. asset list --id で読み戻し、すべての添付ファイルが存在し、availability=available であることを確認してから、進捗エントリーを読み戻します。両方の確認に成功した場合に限り、"progress and attachments updated" と報告します。失敗した場合は、公開済みファイル、リンク済みファイル、復旧待ちの作業を区別して報告します。

添付ファイルには、これらのファイルリンク API を使用してください。ローカルパスへのテキストリンクは添付ファイルの代わりにはならず、ファイルをコピーしただけでは納品は完了しません。すべてのパラメーターについては CLI リファレンスを参照してください。

現在の会話バインディングと実行スナップショット

この実行のために固定されたバインディング宣言を使用して、デフォルトの Thing を特定します。その Thing を実行、確認、要約、または更新する前に、宣言の readCommand を使用して実行スナップショットを読み取ります。通常のチャットでは、この読み取りは必要ありません。実行中にバインドの切り替えや解除を行うと、会話との関連付けは即時に変更されますが、待機、再開、再試行を含む現在の実行では、元のスナップショットが維持されます。実行開始時に Thing がなかった場合、デフォルトの Thing は引き続きありません。最新のバインディングが適用されるのは新しい Run のみです。ユーザーが別の Thing を明示的に指定した場合は、権限の範囲内でその Thing を読み取り、操作します。会話の最新の関連付けと、この実行のスナップショットを混同しないでください。

ユーザーから現在の会話を Thing にバインドするよう明示的に求められた場合は、対象を一意に特定し、conversation bind を実行してから、conversation primary で確認します。名前から Thing を一意に特定できない場合は、ユーザーに確認してください。成功した場合は、バインディングが保存され、Thing のコンテキストは次の実行から適用されることを説明します。バインド解除も読み戻して確認してください。通常の link-conversation 参照は、プライマリ Thing のバインディングの代わりにはなりません。権限を回避せず、API エラーを正確に報告してください。

context --id <thing-id> --run-id <run-id> は、実行が受け付けられた時点で取得された業務テキストとバージョンを返します。書き込みに現在の事実またはバージョンが必要な場合は、追加の手順として --run-id を付けずにライブコンテキストを明示的に読み取り、収集時点とスナップショットのバージョンを区別してください。スナップショットの読み取りに失敗した場合は、タイトルから推測したり、自動的にライブデータへ切り替えたりせず、不足している情報を明らかにしてください。実行スナップショットとライブコンテキストを参照してください。

• フィールドはタイトル、説明、タグ、ステータス、担当者、コラボレーターです。ステータスは open／paused／done です。アーカイブと復元は別の操作です。作成時は説明が必須です。作成時に担当者を省略すると、現在のユーザーがデフォルトで設定されます。明示的に null を指定すると拒否されます。
• members/options を使用して、メンバーと Thing の候補を照会します。作成、編集、コラボレーターの管理はサーバーの権限に従います。変更前に最新バージョンを読み取ります。409 が発生した場合は、バージョン番号を置き換えるだけでなく、変更内容を比較します。
• エントリでは url/note/progress を使用します。type を省略した場合、サーバーは単一の HTTP(S) URL をリンクとして、それ以外の内容をノートとして保存します。entry append --type progress で進捗を追記します。エントリは entry update と expected-updated-at を使用して編集します。タイトル、type、本文はそれぞれ個別に変更できます。--clear-title はタイトルを消去します。
• from-message を使用して会話のメッセージを Things に変換するには、検証済みの conversation-id/message-id の値と、確認済みの本文テキストを指定します。このコマンドを明示的に指定するようユーザーに求めず、上記の作成シグナルを適用します。推測した内容は、まず会話内で提案として提示します。削除済みの永続的な変更ドラフト用コマンドは使用しないでください。
• メインの Thing には conversation primary/bind/unbind、通常の参照には link-conversation、関連付けの照会には conversations を使用します。リンクしても会話のプライバシーや権限は変わりません。
• 途中成果物は進捗エントリとして記録します。引き継ぎにはノートを使用し、完了した作業、根拠、次のステップを明記します。担当者とコラボレーターが、人に関連する唯一のコラボレーション関係です。別途、担当者になる手順は不要です。
• 上記の承認境界と成果物添付のワークフローに従い、ファイルには asset available/list/link/unlink/publish を使用します。リンクを解除してもファイルは削除されません。
• 完全に削除する前に最新バージョンを読み取り、削除は取り消せないことと、残る会話／ファイルを説明します。その後、明示的な確認を得てから delete --confirm-delete --yes を使用します。実行中の実行と競合した場合は待機し、自動的に実行を終了しないでください。
• 具体的に承認された変更は、同じ許可を再度求めずに直接実行します。

ae-cli things create --agent-space-id <space-id> --title 'API acceptance' --description 'Verify permissions and data consistency' --format json
ae-cli things entry append --agent-space-id <space-id> --id <thing-id> --type progress --content 'Completed API integration checks' --format json

レビューには ae-things-review、定期的な要約には ae-things-progress を使用します。どちらも、収集済みの事実をすべて統合しつつ、未読ファイル、切り捨て、トランザクション非対応の収集に伴う制限を明示します。

リンク済みの会話を一覧表示するには things conversations を、会話を読むには things conversation get を使用します。新しい会話はワークスペースの UI から開始します。Things CLI で管理できるのは Thing のリンクとメイン Thing のバインドのみです。