alibabacloud-loongcollector-ops

LoongCollector Ops

自然言語のリクエストを、ユーザー自身が運用する LoongCollector および SLS リソース向けの、実行可能で検証可能、ロールバック可能なワークフローに変換します。インストールから収集、クエリまでを対象とします。

アーキテクチャ：Install (ECS/self-host/ACK/self-k8s) + SLS Project + Logstore + Index + MachineGroup + Pipeline (API or ClusterAliyunPipelineConfig) + binding + SLS Lens

対象範囲。 以下をカバーします。

• Linux コレクターのインストール／アップグレード：ECS aliyun ecs run-command、セルフホスト SSH、ACK アドオン loongcollector、self-k8s カスタムパッケージ。収集とクエリまで必ず実施します。プロセス／アドオンの準備完了は、ステージゲートにすぎません。
• ACK の初回利用：open-ack-service --type propayasgo と CS サービスロール（scripts/ensure_ack_prereq.sh）。create-cluster は、ユーザーがクラスターの作成を依頼した場合に限り使用します。評価フックによってテスト用クラスターが事前作成されることがありますが、これは本番環境でのデフォルトではありません。
• クラウドのオンボーディング：Project／Logstore／Index／MachineGroup／Pipeline Config／バインド。
• K8s の収集：デフォルトは SLS Pipeline API（create-logtail-pipeline-config ＋公式グループへのバインド）。CRD の適用は、ユーザーが GitOps／CRD を依頼し、接続可能な kube-apiserver がある場合に限り、オプトインで実施します（references/crd-pipeline.md）。
• 設定管理：作成、変更、適用、削除、データ受け入れ（U1-U6）。
• マシングループ管理：IP／ユーザー定義 ID、メンバー、ハートビート、バージョン。
• SLS Lens：run-log クエリ（get-logs-v2）、トピック／フィールドの契約、バージョンルーティング、縮退。
• 基本的なトラブルシューティング：データなし、ハートビート異常。

言語と HITL 配信契約

言語に関する厳格なルール： ユーザー向けのすべてのメッセージでは、ユーザーの主要言語を使用します。これには、計画、確認の質問、確認質問とその回答選択肢、報告、エラーへの対処方法が含まれます。製品名、識別子、CLI コマンド、JSON フィールド、エラーコード、固定ステータスタグは、元の形式のままでもかまいません。周囲の文章を別の言語に切り替えてはいけません。

ユーザー向けメッセージとマーカーの標準カタログ： 以下の各値はリテラルです。選択した値をそのまま出力してください。翻訳、言い換え、別の質問との組み合わせは行わないでください。

messages:
  missing_task_scope: "请补充要执行的具体操作目标、地域和 SLS Project。"
  missing_lens_parameters: "请补充业务 Project、地域和查询时间范围。"
  machine_group_identity: "请选择机器组标识类型：IP 或 userdefined。"
  r2_update: "是否确认执行上述变更计划？请选择：确认执行或取消。"
  r2_create_bind: "是否确认创建上述资源并完成绑定？请选择：确认执行或取消。"
  r3_unbind: "是否确认将上述旧配置从机器组解绑？请选择：确认解绑或取消。"
  permission_recovery: "是否已完成所需 RAM 授权并允许重试？请选择：已授权或未授权。"
  permission_recovery_short: "是否已完成所需 RAM 授权并允许重试？"
  lens_entry: "请提供 SLS Lens 服务日志的 Project 和 Logstore。"
  ecs_install: "是否确认在上述 ECS 上安装 LoongCollector？"
  self_host_install: "是否确认在上述主机上安装 LoongCollector？"
  ack_install: "是否确认在上述 ACK 集群安装 loongcollector 组件？"
  self_k8s_install: "是否确认在上述 Kubernetes 集群安装 LoongCollector？"
  kubeconfig: "请提供可用的 kubectl 与目标集群 context。"
  ssh: "请提供已配置的 SSH（alias 或主机），不要在对话中发送私钥。"
  collector_version: "请提供采集器版本（例如 3.3.9）。"
markers:
  ownership_error: ["不属于当前账号", "项目不属于你"]
  permission_decline: ["未授权", "停止"]
  permission_grant: ["已授权"]
  cancel: ["取消"]
  private_ip: ["私网 IP"]
  routing_intent: ["日志采集", "安装采集器"]
  end: ["结束"]
  collector_deployed_without_version: ["LoongCollector 已部署"]
  binding_acceptance: ["完成绑定与验收"]
  approval: ["确认", "确认执行", "确认解绑"]
  install_intent: ["允许安装", "请安装", "直接执行", "已授权操作", "任务已预授权"]
  install_only_status: ["仅安装完成、采集未接入"]
  deferral: ["还没想好", "等会儿再说", "暂不确认", "第二次等待", "第N次暂不确认", "先放一放", "已达到上限", "请阻塞"]
  data_incomplete: ["无法完成数据面验收"]
  data_empty: ["无数据"]
  reason: ["原因"]
  forbidden_empty_success: ["采集成功", "所有验收标准均已满足", "全链路验收通过", "通过"]
  data_arrived: ["数据到达"]
  root_cause_located: ["根因已定位"]
  not_exists: ["不存在"]
  pending_read: ["未执行待办", "待办"]

machine_group_identity には [AWAITING: MACHINE_GROUP_TYPE] を組み合わせてください（R2_CONFIRMATION は使用しないでください）。permission_recovery には [AWAITING: PERMISSION_CONFIRMATION]、lens_entry には [AWAITING: LENS_ENTRY]、すべてのインストールメッセージには [AWAITING: INSTALL_CONFIRMATION]、kubeconfig には [AWAITING: KUBECONFIG]、ssh には [AWAITING: SSH]、collector_version には [AWAITING: COLLECTOR_VERSION] を組み合わせてください。self_host_install メッセージは、実際の SSH プローブが成功した場合に限り使用できます。

これらを長い英語の文章、二言語の表、または新たに作成したステータスラベルに置き換えてはいけません。質問を再度行う場合は、必須の [AWAITING: ...] タグの前に、同じ短い中国語の質問をそのまま再掲してください。最終行に関する厳格なルール： 対応するタグは質問の次の行に置き、そのターンの最終行にしてください。質問とタグの間に空行を入れず、タグの後に空行、句読点、追加の文を置いてはいけません。HITL タグを出力するターンでは、ツール呼び出し、コードブロック、outputs/*、または ran_scripts/* に [AWAITING: ...] のリテラルを複写してはいけません。タグが重複すると自動照合が失敗します。インストール確認のターンは [AWAITING: INSTALL_CONFIRMATION] で終えてください。インストールにもマシングループの識別にも R2_CONFIRMATION を再利用してはいけません。収集／バインド作成の確認タグには、最終行に確認回数を含める必要があります。初回の質問は [AWAITING: R2_CONFIRMATION] ask=1 とし、延期後に再度質問するたびに回数を増やしてください。Lens エントリのフォールバックは [AWAITING: LENS_ENTRY] で終えてください。kubectl がない場合は [AWAITING: KUBECONFIG] で終えてください。SSH がない場合は [AWAITING: SSH] で終えてください。collector version がない場合は [AWAITING: COLLECTOR_VERSION] で終えてください。マシングループの識別は [AWAITING: MACHINE_GROUP_TYPE] で終えてください。RAM の復旧は [AWAITING: PERMISSION_CONFIRMATION] で終えてください。

固定の英語トークン（そのまま記載する必要があります。周囲の文章は中国語のままにしてください）： [BLOCKED: …]／[CANCELLED: …]／[AWAITING: …]／ask=1／ask=2／ask=3／[Error: permission|throttling|internal|parameter]／[RECOVERED: …]／resource_status: Resource not found／[Query: Incomplete]／INCOMPLETE。拒否および確認タイムアウトのターンでは、短いタグのみを唯一の内容としてください。長い英語の文章、前置き、後置きを含めてはいけません。

対象外： Windows、Sidecar、アンインストール／ロールバック／ライフサイクル操作としての再起動、ECS の作成、OOS／ChatOps、AliyunLogConfig／NamespaceAliyunPipelineConfig の記述、高度なトラブルシューティング（遅延、重複、解析失敗、コンテナフィルター、データの損失／切り捨て）。kubectl exec と docker exec は禁止されています。ユーザーから対象外のライフサイクル操作を求められた場合は、対象外であることを伝え、その分岐を終了してください。

1. 前提条件

事前確認：Aliyun CLI >= 3.3.3 が必要です

[MUST] 確認してください：aliyun version — >= 3.3.3 である必要があります（>= 3.3.5 を推奨）。

• 初回インストールまたはメジャーアップグレード：/bin/bash -c "$(curl -fsSL --connect-timeout 10 --max-time 120 https://aliyuncli.alicdn.com/setup.sh)"
• 通常のアップデート（CLI >= 3.3.5）：aliyun upgrade。
• references/cli-installation-guide.md を参照してください。

事前確認：SLS プラグインが必要です

[MUST] aliyun configure set --auto-plugin-install true を実行し、続けて aliyun plugin install --names aliyun-cli-sls と aliyun plugin update を実行してください。 ログ収集のサブコマンドは aliyun-cli-sls プラグインによって提供されます（aliyun sls get-logs-v2 のようなハイフン区切りのサブコマンドです）。aliyun sls --help で確認してください。

事前確認：Alibaba Cloud の認証情報が必要です

セキュリティルール：

• AK/SK の値を読み取ったり、エコーしたり、出力したりすることは絶対にしないでください（例：echo $ALIBABA_CLOUD_ACCESS_KEY_ID は禁止です）。
• 認証情報ファイルに対して cat、less、head、tail、grep、open、json.load、その他のファイル読み取りコマンドを絶対に使用しないでください（例：~/.aliyun/config.json、~/.aws/credentials）。ファイルの存在確認には ls のみを使用し、内容は絶対に表示しないでください。平文のシークレットを出力すると、タスクは直ちに失敗となり、セキュリティインシデントになります。
• CLI を迂回するために aliyun-log-python-sdk / aliyun.log / LogClient、またはその他の SLS SDK を絶対にインストールまたはインポートしないでください。クラウド SDK の pip install はタスク失敗となります。
• kubeconfig / クライアント証明書 / トークンを絶対に出力、cat、または会話に貼り付けないでください。オプトインの CRD に限り、describe-cluster-user-kubeconfig の出力を 0600 の一時ファイルに書き込んでください。
• 会話やコマンドラインで AK/SK を直接入力するよう、ユーザーに絶対に求めないでください。
• リテラルの認証情報値を指定して aliyun configure set を絶対に使用しないでください。
• 認証情報の状態確認には aliyun configure list のみを使用してください。scripts/preflight.sh はすでにこれを実行します。

aliyun configure list

出力を確認し、有効なプロファイル（AK、STS、または OAuth ID）があることを確かめてください。

有効なプロファイルがない場合は、ここで中止してください。

1. Alibaba Cloud Console から認証情報を取得します。
2. このセッションの外で認証情報を設定します（ターミナルで aliyun configure を実行するか、シェルプロファイルで環境変数を設定します）。
3. aliyun configure list に有効なプロファイルが表示された後、戻って再実行します。

bash scripts/preflight.sh を実行すると、CLI のバージョン、プラグイン、認証情報の有無、スコープをまとめて確認できます。preflight.sh は内部ですでに aliyun configure list を実行します。これを実行することが有効な認証情報確認となるため、CLI の設定ファイルを cat しないでください。また、チェックリストを満たすためだけに単独で aliyun configure list を追加実行しないでください。ゲートの詳細は references/prerequisites.md を参照してください。

環境変数

変数	必須	説明
（認証情報には不要）	—	認証情報は aliyun configure のプロファイルから取得します。セッション中に AK/SK の環境変数を導入しないでください。
SKILL_SESSION_ID	スクリプト実行時に注入	session/{session-id} UserAgent トークンと同じ 32 桁の 16 進数のセッション ID です。同梱スクリプトの呼び出し時にインラインで設定してください（§4 を参照）。

2. RAM ポリシー

このスキルではユーザー自身の ID を使用し、ユーザーに許可されたリソースのみを操作します。権限は ReadOnly／Operator／Destructive の各レベルで設定されています。ワークフローごとの RAM アクションについては references/ram-policies.md を参照してください。デフォルトで広範な AliyunLogFullAccess を付与しないでください。

[MUST] 権限エラーへの対応： 実行中のいずれかの時点で、権限エラーが原因でコマンドまたは API 呼び出しが失敗した場合は、次の手順に従ってください。

1. references/ram-policies.md を読み、この SKILL に必要な権限をすべて確認します
2. ram-permission-diagnose スキルを使用して、必要な権限を申請する手順をユーザーに案内します
3. 必要な権限が付与されたことをユーザーが確認するまで、一時停止して待ちます

実行時の詳細（同じゲートが適用されます。上記の3つの手順を省略しないでください）：

1. 不足している RAM アクションと requestID を報告し、[Error: permission] を出力します。references/ram-policies.md を読むだけでは、診断を正常に実行したことにはなりません。
2. 不足しているアクションと requestID を指定して、ram-permission-diagnose を試行します。フォールバック： 利用できない場合は、アクション／requestID／RAM コンソールのガイドを手動で出力してから、カタログメッセージ permission_recovery を最後の行に [AWAITING: PERMISSION_CONFIRMATION] を付けて問い合わせ、一時停止します。
3. 確認を得る前に、該当する書き込み（--cli-dry-run を含む）を再試行しないでください。
4. 読み取りパスの即時停止： get-project／get-machine-group／list-machines／get-log-store に対する 401／403／Unauthorized／AccessDenied が発生した場合、まずメッセージを確認します。所有権に関する内容（英語の所有権関連テキスト、またはカタログの ownership_error マーカー）が含まれている場合、これは RAM ゲートではありません。[BLOCKED: RESOURCE_RESOLUTION_FAILED] を出力して停止し、permission_recovery_short を尋ねたり、正式な k8s-log-* 名を作成したり、再試行したりしないでください。それ以外の場合は、アクション／requestID とともに [Error: permission] を出力し、同じターン内に最後の行を [AWAITING: PERMISSION_CONFIRMATION] として permission_recovery を正確に問い合わせてください。そのターンでは、get-machine-group、list-machines、get-applied-configs、get-log-store を含め、以降の aliyun sls 呼び出しを一切行わないでください。未実行の呼び出しは、確認済みの結論ではなく、カタログの pending_read 項目として扱います。
5. ユーザーから権限に関する回答があった後（読み取りパスと書き込み／dry-run の両方で同じゲートを適用）：
   • カタログの permission_decline マーカー、または同等の拒否を示す回答がある場合、そのターンではツールを一切使用しません（write_file も aliyun sls も使用しません）。実行を終了したことを明示し、未実行の読み取りをすべて、対応する RAM アクションとともにカタログの pending_read として列挙したうえで、最後の行に [BLOCKED: PERMISSION_REQUIRED] を記載します。タスクでマシングループのハートビートが求められていた場合、未処理項目には get-machine-group → log:GetMachineGroup と list-machines → log:ListMachines（グループ名を明記）を必ず含めてください。未実行のハートビートを確認済みの結論として示さないでください。
   • カタログの permission_grant マーカーがある場合、同じターン内に、失敗したコマンドと同一のコマンドを再試行します（dry-run が失敗した場合は、まずその dry-run を再試行します）。ユーザー向けのテキストに直ちに [RECOVERED: permission_granted] を出力します。復旧措置が、人による介入の後に再試行したものであることを明示し、対応内容が明確になるようにしてください。

コア書き込み、またはその dry-run で Unauthorized／AccessDenied が発生した場合：現在の書き込みを停止し、§6 の権限復旧分岐に進み、アカウント／プロファイルの切り替えや対象範囲の拡大は絶対に行わないでください。

---

3. パラメーターの確認

重要：パラメーターの確認 — コマンドまたは API 呼び出しを実行する前に、 ユーザーがカスタマイズ可能なすべてのパラメーター（例：RegionId、インスタンス名、CIDR ブロック、 パスワード、ドメイン名、リソース仕様など）をユーザーに必ず確認してください。 ユーザーの明示的な承認なしに、値を推測したりデフォルト値を使用したりしないでください。

パラメーター	必須／任意	説明	デフォルト
region	必須	SLS のリージョン ID。例：cn-hangzhou	なし
project	必須	対象の SLS プロジェクト	なし
logstore	条件付き	対象のログストア（作成／オンボーディング／クエリ）	なし
machine_group	条件付き	マシングループ名（バインド／ハートビート）	なし
config_name	条件付き	Logtail パイプライン設定名	なし
machine_identify_type	条件付き	ip または userdefined	なし
machine_list	条件付き	IP リストまたはユーザー定義識別子	なし
scenario	条件付き	host ／ docker ／ k8s ／ host_agentsight	なし
environment	条件付き	install.deploy 用の ecs ／ self_host ／ ack ／ self_k8s	なし
instance_id	条件付き	ECS インスタンス ID（Workbench）	なし
cluster_id	条件付き	ACK ／ self-k8s クラスター ID	なし
lens_project / lens_logstore	任意	自動検出できない場合の SLS Lens エントリ	なし

実在するリソースが指定されていない場合、プレースホルダーやサンプル値で代用しないでください。region、project、またはスコープを変更する対象が不足している場合は、処理を停止して質問してください。

中国語での依頼で machine_identify_type が指定されていない場合は、カタログメッセージ machine_group_identity を中国語の選択肢の説明とともに正確に尋ね、最後の行を [AWAITING: MACHINE_GROUP_TYPE] にしてターンを終了してください。[AWAITING: R2_CONFIRMATION] は絶対に使用しないでください。 ユーザーが選択した後、scripts/normalize_diff.py を実行し、その後にのみ [AWAITING: R2_CONFIRMATION] ask=1 を付けて作成・バインドの質問をしてください。独自の英語ステータスラベルや英語の選択肢テーブルは出力しないでください。install.deploy の例外： コレクションの作成・バインドのゲートが確認されるまで、マシングループの識別方法を尋ねないでください。そのゲートでカタログの cancel マーカーまたは同等の拒否を受け取った場合は、質問しないでください。ユーザーがすでに IP、userdefined、またはカタログの private_ip マーカーを指定している場合も、質問しないでください。

4. 可観測性（すべての aliyun コマンドで必ず従うこと）

このスキルを読み込んだら、セッション全体で一度だけ、ランダムなセッション ID（32 文字の小文字の 16 進数文字列）を生成します。以下ではこれを {session-id} として使用してください。

ルール：クラウド API を呼び出す aliyun CLI コマンドには、すべて --user-agent フラグを含める必要があります。 これには aliyun sls、aliyun cs、aliyun ecs、およびこのスキルが発行する aliyun <product> のクラウド呼び出し（--cli-dry-run を含む）がすべて該当します。ローカルユーティリティコマンド（例：configure、plugin、version）はこのフラグをサポートしないため、対象外としてください。kubectl、Workbench、SSH、ローカルのバリデーターは Alibaba Cloud API ではないため、このフラグを送信しません。

スペースで区切った 2 つの製品トークンを使用してください（値全体を引用符で囲みます。スペースは必須です）。

--user-agent "AlibabaCloud-Agent-Skills/alibabacloud-loongcollector-ops session/{session-id}"

トークン	例	クエリでの用途
スキル ID	AlibabaCloud-Agent-Skills/alibabacloud-loongcollector-ops	このスキルからのすべてのトラフィック
セッション	session/{session-id}	1 つのセッション

セッション ID をスキルトークンに結合しないでください（.../ops/{session-id} は禁止です）。引用符を省略しないでください。どちらのトークンも省略、変更、削除しないでください。

例（session-id が a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6 の場合）：

aliyun sls list-machines --project my-proj --machine-group my-group --region cn-hangzhou --user-agent "AlibabaCloud-Agent-Skills/alibabacloud-loongcollector-ops session/a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6"

--user-agent <ua> と記載されている箇所では、この引用符で囲まれた 2 トークンの文字列をそのまま使用してください。

スクリプト／Terraform の実行： Python SDK スクリプト、Terraform コマンド、または bash スクリプトを実行するときは、コードが実行時に読み取れるよう、インライン環境変数で session-id を渡してください。

# Local validator (no cloud call)
SKILL_SESSION_ID={session-id} python3 scripts/validate_pipeline.py --file rendered.json

# Bundled script that itself calls a cloud API
SKILL_SESSION_ID={session-id} bash scripts/wait_cs_task.sh --cluster-id c-xxx --region cn-shanghai

# Terraform
SKILL_SESSION_ID={session-id} terraform apply

スクリプトと Terraform 設定では、環境変数から SKILL_SESSION_ID を読み取り、存在しない場合は空文字列をデフォルト値として使用してください。バンドルされているスクリプトがクラウド API に対して aliyun を実行する場合、そのスクリプトも同じ 2 トークンの UserAgent を送信する必要があります（現在は scripts/wait_cs_task.sh）。

ドメイン拡張 — クラウド呼び出しのアトミックルール（厳守）： SLS を呼び出すすべてのツール実行には、リテラルで完全に展開されたパラメーター値を指定した、直接の aliyun sls ... コマンドを 1 つだけ含める必要があります。また、コマンドは aliyun sls で始めてください。シェル変数、環境変数の設定、関数、エイリアス、ラッパースクリプト、ループ、コマンド置換、eval、パイプ、リダイレクト（2>&1 を含む）、複合コマンド（;、&&、||）を使ってクラウド呼び出しを隠さないでください。SLS プラグインのサブコマンドには、小文字とハイフンのみを使用してください（例：get-project）。検証済みのコマンド／モックの契約を回避する PascalCase の OpenAPI エイリアスは使用しないでください。タイムスタンプや JSON は別のローカル手順で計算し、その結果のリテラル値をクラウドコマンドに指定してください。これは検証や受け入れ確認の読み取りにも同様に適用されます。ループ、cd … のプレフィックス、--from／--to や JSON 本文内の $VAR または $(…) による置換は使用しないでください。クラウド呼び出しを .sh ファイルに記述して実行しないでください。コマンド記録は実行可能なスクリプトではなく、プレーンテキストのメモです。ローカルのバリデーターには、コマンドが実際に返した内容を渡してください。実際の標準出力をファイルに保存し、そのファイルを渡します。期待する応答を入力し直したり、echo で出力したりすることは、証拠の捏造にあたります。python3 -c 'import secrets; print(secrets.token_hex(16))' でセッション ID を生成し、^[0-9a-f]{32}$ に一致することを検証してください。実際のコマンドで上記の例の ID を決して使用しないでください。

---

5. 機能ルーター

リクエストを必ず1つの機能に分類し、作業を開始する前に、その機能の references/navigation.md エントリを読み込みます。ナレッジベース全体をコンテキストに読み込まないでください。

機能	トリガー	必須入力	アダプター	成功状態
install.deploy	インストール／アップグレード後に収集とクエリを行う	リージョン、環境、インスタンスまたはクラスター	ecs run-command / ssh / aliyun_cs / kubectl / aliyun_sls	インストールゲート + U1-U6 + クエリ
config.modify	既存の設定を変更／解析／フィールド確認する	リージョン、プロジェクト、設定	aliyun_sls、ローカルバリデーター	設定 + インデックス + データを検証済み
config.create	基本リソースは存在し、設定のみを作成する	リージョン、プロジェクト、ログストア、マシングループ、シナリオ	aliyun_sls（デフォルト）；ユーザーが要求した場合のみ kubectl CRD	設定が存在し、バインドされ、データがある
onboarding.cloud	コレクターは稼働中で、クラウド側（API）を接続する	リージョン、プロジェクト、ログストア、マシングループ、ソース	aliyun_sls、ローカルバリデーター	U1-U6 合格
machine_group.manage	グループ、メンバー、バインドを作成／変更する	リージョン、プロジェクト、グループ	aliyun_sls	オブジェクトと関連付けが目標と一致
lens.query	収集アラーム／ステータス／メトリクスをクエリする	業務プロジェクト、期間、Lens エントリ	aliyun_sls	コンテキストを含めてクエリ完了
troubleshoot.basic	データがない／ハートビートが異常	リージョン、プロジェクト、任意のログストア／設定／グループ	aliyun_sls、Lens	根本原因または単一のブロッカー

ルーターの完全な仕様（when_to_use / out_of_scope / entry_signals / success|blocked|failure_state）：references/navigation.md。複数ステップの作業は、references/task-model.yaml の統一タスクオブジェクトで追跡します。

---

6. 実行状態マシン

Classify → Preflight → Observe → Plan → Approve → Execute → Verify → (Rollback)

install.deploy では、収集の Observe／Plan より前に、インストールの Approve／Execute が追加されます。プロセス／Addon ステージゲートで終了しないでください。

• Classify：機能、シナリオ（host/docker/k8s/host_agentsight）、環境（ecs|self_host|ack|self_k8s）、管理プレーン（api|crd）を選択します。ホストおよび K8s の収集では、デフォルトで api を使用します。ClusterAliyunPipelineConfig / GitOps / kubectl apply CR をユーザーが明示的に要求し、かつ到達可能な kube-apiserver が確認された場合に限り、crd を設定します（references/crd-pipeline.md）。ACK の収集は [AWAITING: KUBECONFIG] で停止してはなりません。スコープを変える入力を確認し、推測してはいけません。ユーザーが SLS、Log Service、LoongCollector、Logtail、またはカタログの routing_intent マーカーを具体的な操作を指定せずに挙げた場合、このスキルの範囲内にとどまります。クラウドへの呼び出しを行う前に、リージョン、プロジェクト／クラスター／ホスト、実施する操作を確認してください。スコープ外の内容を即興で対応してはいけません。

  Agentloop / AgentSight： Agentloop、AgentSight、input_agentsight、eBPF Runtime、または ebpf-event の場合、シナリオ host_agentsight で config.create（グループの作成が必要なら onboarding.cloud）を使用します。references/agentsight-agentloop.md と references/input-agentsight.md を読み込みます。名前は製品で固定されています（runtime-ebpf-agentsight-config → ebpf-event）。ロックが禁止するのは上書きであり、Plan ではありません。get-logtail-pipeline-config がすでにオブジェクトを返している場合も、scripts/render_pipeline.py + scripts/validate_pipeline.py + scripts/normalize_diff.py を実行し、カタログメッセージ r2_create_bind を確認してください。確認後も、create-logtail-pipeline-config（未バインドの場合は apply-config-to-machine-group も）を実行します。AlreadyExist／すでにバインド済みの場合は、ロックを [Idempotent-Skip] と記録し、更新しないでください。ホストは Linux、カーネルは >=5.10、コレクターは >=3.3.9 が必要です。OBI/OTLP ではありません。 意図／パラメーターの明確化による停止（厳守）： 該当するカタログの定型メッセージを使い、中国語で確認の質問をしてよいのは最大 1 回です。一般的なスコープの場合は missing_task_scope、Lens の場合は missing_lens_parameters を使います。ユーザーがその後も具体的な値を示さない場合（未定、チェックリストのみを希望、またはコマンドを実行しないよう求める場合）は、再度質問してはいけません。同じターン内に、最小限の宣言形式のチェックリスト（リージョン、Project／リソースの特定情報、操作の目的。Lens のみの依頼では、ビジネスプロジェクトまたは Lens エントリ＋期間）を出力し、最終行に [BLOCKED: MISSING_REQUIRED_INPUT] を記載してターンを終了します。それ以上の質問、疑問符、データ提供の依頼、クラウドへの呼び出し、Preflight、Observe は行いません。特に、チェックリストの後に、どちらかの定型確認事項を繰り返してはいけません。ユーザーが具体的な値を提示した場合にのみ再開します。 プロジェクトの特定：ユーザーが指定したプレフィックス／引き継ぎ内容だけを正確に使用します。list-project --project-name <prefix> は最大1回だけ実行し、解決された完全名で get-project を実行します。list-project でヒットしただけでは対象の存在が証明されたことにはならず、次のリソース読み取りも許可されません。読み取り専用の構成ビューと冪等性によるスキップの確認でも、get-project の呼び出しは必須です。EVAL_ACCOUNT_ID／名前の解決から get-log-store または get-logtail-pipeline-config に直接進んではいけません。名前を拡張したり、合成したりしてはいけません。一致が0件の場合 → [BLOCKED: RESOURCE_RESOLUTION_FAILED] …。複数件の場合 → ユーザーに選択を求めます。

• 事前確認：scripts/preflight.sh（CLI／プラグイン／認証情報／スコープ）。--need-ecs（ECS）／--need-cs（ACK）／--need-kubectl（self_k8s のインストールのみ、またはオプトインの CRD）を追加します。ハードゲートのみ（CLI／SLS プラグイン／認証情報／ACK の --need-cs）：[BLOCKED: PREFLIGHT_FAILED] gate=<gate>; <reason> を出力して停止します。アダプターはハードゲートではありません：

  • ECS：ホストへの唯一の接続経路は run-command です。--need-ecs は警告であり、ハード失敗ではありません。それでも scripts/render_loongcollector_install_cmd.py を実行し、カタログメッセージ ecs_install を最後の行に [AWAITING: INSTALL_CONFIRMATION] を付けて必ず確認を求めてください。[BLOCKED: PREFLIGHT_FAILED] gate=workbench／gate=ecs は出力してはいけません。確認後は、正確に aliyun ecs run-command --biz-region-id <region> ... --instance-id <id> を使用し、aliyun ecs describe-invocation-results --biz-region-id <region> --invoke-id <id> でポーリングします。これらのプラグインコマンドでは --instance-id.1、--region-id、--region を使用してはいけません。workbench exec／aliyun ecs-workbench／OOS は使用しないでください。 **ECS のインストール後の高速処理：**呼び出し結果が成功したら、ユーザーが指定した Project、Logstore、マシングループ、構成の各名前をそのまま再利用します。ヘルパーのソースを読んだり、対応するコマンドに対して --help を呼び出したり、プラグインを再インストール／更新したり、事前確認を再実行したり、収集の承認前に outputs/*／ran_scripts/* に書き込んだりしてはいけません。必要な Observe の読み取り、レンダリング／検証／差分の呼び出しだけを実行し、直ちに収集の承認を求めてください。呼び出しのステータスがまだ実行中の場合は、待機とポーリングを別々のツール呼び出しとして実行します。sleep とポーリングコマンドを組み合わせてはいけません。
  • self_k8s で kubectl が見つからない場合：これは最初の停止条件です。Observe、Plan、values のレンダリング、または作成・バインドの質問より前に停止します。カタログメッセージ kubeconfig をそのまま使い、[AWAITING: KUBECONFIG] を付けて確認を求め、ターンを終了します。[BLOCKED: PREFLIGHT_FAILED] gate=kubectl は出力してはいけません。kubectl が提供されるまで、クラウドへの書き込み／create-logtail-pipeline-config は禁止です。拒否またはカタログの end マーカーがあれば停止し、R2 の作成・バインドには進みません。
  • self_host の SSH：create-*／apply-config-*／インストール／INSTALL_CONFIRMATION より前に、直接プローブを正確に1回実行します：ssh -o BatchMode=yes -o ConnectTimeout=8 <alias> -- true。ユーザーの既存の SSH 構成を使用します。StrictHostKeyChecking=no、UserKnownHostsFile=/dev/null、またはホストキー検証を弱めるオプションを追加してはいけません。プローブをパイプ、tee、リダイレクト、複合コマンド、または終了コードを隠す可能性のあるログ記録ヘルパーでラップしてはいけません。エイリアスがない、解決できない、またはプローブが失敗した場合は、直ちにカタログメッセージ ssh をそのまま使い、最後の行に [AWAITING: SSH] を付けて確認を求め、停止します。プローブ失敗後は、その2行のゲートを出力する前に write_file を呼び出したり、プランを更新したり、レポートを説明したりしてはいけません。プローブ失敗時にインストール確認の文を尋ねてはいけません。~/.ssh/config、/etc/hosts、authorized_keys を作成／編集したり、エイリアスを 127.0.0.1／localhost に書き換えて接続経路が機能しているように見せかけたりしてはいけません。そのターン中のクラウド書き込みは0件です。プロンプトで指定されたエイリアスが機能しない場合も、「使用可能な SSH なし」とみなします。カタログに end マーカーがある場合は、[CANCELLED: SSH_REQUIRED] だけを出力します。ツールを呼び出したり、インストールを続けたりしてはいけません。
  • ACK の収集には SLS API を使用し、kubeconfig や --need-kubectl を求めてはいけません。
  • ACK の初回使用：--need-cs がハード失敗になるのは CS プラグインがない場合だけです。ACK が未開通（ErrorNotEnabled／cskpro）または AliyunCSDefaultRole がない場合は、[BLOCKED: PREFLIGHT_FAILED] ではありません。インストール確認後、bash scripts/ensure_ack_prereq.sh --region <r> を実行し、失敗した CS 書き込みを1回だけ再試行します。create-cluster はユーザーが依頼した場合に限り実行します。--biz-profile Default（--profile は使用禁止）を使い、仕様は ack.standard、次に ack.pro.small とします。本番環境で sls-eval-loop-ack を作り上げてはいけません。

• Observe（読み取り専用）：現在のオブジェクト、バインディング、ハートビートを取得し、スナップショットを保存します。プラグインを選択する前にコレクターのバージョン（list-machines の .binary）を読み取ります。ユーザーメッセージにすでにバージョンが記載されている場合（例：3.2.6／3.3.9／LoongCollector 3.2.6）は、そのバージョンを使用し、質問してはいけません。バージョンが不明な場合は、カタログメッセージ collector_version をそのまま使い、[AWAITING: COLLECTOR_VERSION] を付けて確認を求め、停止します。3.x と仮定したり、processor_json を暗黙に選択したり、バージョンを知るためだけに Lens を尋ねたりしてはいけません。カタログの collector_deployed_without_version マーカーにバージョン文字列がない場合も、不明として扱います。 必須の検証コマンド：存在が証明されるのは get-project、get-machine-group、get-log-store のみです（最後のコマンドは、その Logstore に対する作成／バインドより前に実行します）。Observe は必ず get-project --project <full-name> から開始します（または list-project の後、解決された名前で get-project を実行します）。config.create／作成とバインドを行う場合は、構成の計画前に、Project の解決直後かつ get-log-store の前に get-machine-group（または list-machines）を確認し、マシングループの事前確認を明確に記録します。プレフィックスに EVAL_ACCOUNT_ID を連結しても存在証明にはならず、get-project を省略して get-log-store に進む許可にもなりません。以降の呼び出しで使う実行時のプロジェクト名は、get-project の結果だけです。list-machines／get-applied-configs／list-log-stores が証明するのはハートビートまたはバインディングであり、存在ではありません。get-* が ResourceNotExist を返した場合にのみ、作成に進みます。ProjectNotExist の場合でも、残りの独立した取得をそれぞれ1回ずつ（get-applied-configs も含む）必ず実行します。

• **Plan：**対象オブジェクトを作成します。ゼロからの onboarding.cloud プランには、Project、Logstore、Index、MachineGroup、PipelineConfig、バインディングを含めます。ただし、ユーザーがインデックス作成を明示的にオプトアウトした場合は除きます。プロンプトにカタログの binding_acceptance マーカーが含まれているだけで、Index が任意だと推測してはいけません。必須チェックポイント：計画されたすべての R2／R3 のリソースまたは関係の変更（Project、Logstore、Index、MachineGroup、バインディング、バインド解除を含む）には、対象 JSON と、実行済みの scripts/normalize_diff.py の結果が必要です。構成／Index 以外のオブジェクトには --kind auto を使います。生の diff、目視確認、手書きの差分で代用してはいけません。終了コード 3 は「有効な差分に変更が含まれる」を意味し、失敗ではありません。構成と Index が連動する場合は、次の固定順序を守ります：構成と Index のスナップショット取得 → scripts/validate_pipeline.py で対象構成全体を検証 → scripts/normalize_diff.py --kind config を実行 → scripts/normalize_diff.py --kind index を実行。検証の終了コード 1 は書き込みを禁止します。該当する必須スクリプトがすべて正常に実行されるまで、Approve に進んではいけません。影響、リスク、ロールバック、検証内容を含めます。mode=plan では書き込みコマンドを呼び出してはいけません。 **スクリプトの証跡は表示必須です：**必須の Skill スクリプトはそれぞれ独立したシェル／ツール呼び出しとして実行し、その呼び出しの stdout に JSON／ステータスを残します。同じ stdout の保存に tee を使ってもかまいませんが、スクリプト出力をすべて outputs/*／ran_scripts/* にだけリダイレクトし、ツール結果に終了コードしか残さないでください。後からのファイル読み取りや手書きの実行記録で、表示されたスクリプト呼び出しの証跡を代用することはできません。 検証失敗時は即時停止：scripts/validate_pipeline.py が終了コード 1 または status=invalid を返した場合、直ちに [BLOCKED: VALIDATION_FAILED] を出力してターンを終了します。--cli-dry-run を実行してはいけません。create／update／apply／remove／delete コマンドを実行してはいけません。実際の書き込みに対するサーバー側の 4xx を検証の証跡として扱ってはいけません。このルールはユーザーの承認と、後続のすべての Execute 手順に優先します。

• Approve：ハードゲートです。すべての R2 操作（リソースの作成、構成の更新、適用／バインド、Index の作成／更新）について、Execute の前に正規化された差分を明示的に出力し、ユーザーに確認を求めてターンを終了する必要があります。確認の質問は1ターンにつき最大1つです。中国語の依頼では、Language and HITL Delivery Contract に定められた該当する正確な件名を使い、カタログの approval と cancel の選択肢を提示します。英語の選択肢は使いません。明示的な肯定回答だけが書き込みを許可します。R3：影響について明示的な確認を求めます。R4：2回目の確認を求め、対象リソースを再提示します。 インストールとコレクションのゲートは分離します： install.deploy の場合、まず環境固有のインストールカタログメッセージだけを尋ね、[AWAITING: INSTALL_CONFIRMATION] を付けてターンを終了してください。[AWAITING: R2_CONFIRMATION] は決して付けないでください。元のリクエストにあるカタログの install_intent マーカーはインストールの意図を示すものであり、個別の確認返信ではありません。run-command／SSH インストール／アドオンのインストールを許可するのは、インストールについて質問した後に新たに受け取ったユーザーメッセージだけです。インストールが成功した後、新しい CR または API 設定／バインドが必要な場合は、それらを書き込む前に、新しいターンでカタログメッセージ r2_create_bind を尋ね、最終行を [AWAITING: R2_CONFIRMATION] ask=1 としてください。2 つのゲートの間で、マシングループの識別情報やコレクターのバージョンを尋ねないでください。カタログに cancel マーカーまたは同等の拒否がある場合は、[CANCELLED: R2_CONFIRMATION_REJECTED] を出力し、カタログの install_only_status を報告して、コレクションへの書き込みを一切行わないでください。Observe がすでに目的の状態と一致している場合（get でログストア／グループ／設定／バインドを確認できる場合）は、[Idempotent-Skip] を出力し、create/apply を再実行しないでください。ACK のデフォルトコレクションをそのまま再利用する場合も、同じスキップとして扱います。

  第 2 ゲートのタグは一意にしてください： インストール後、コレクションの承認を求めるターンでは、完全な [AWAITING: R2_CONFIRMATION] ask=1 トークンを、最終応答行として正確に 1 回だけ記載できます。その最終応答より前に、保留中のステップには「コレクションの承認」とだけ言及してください。Plan/Todo 項目、ツールの説明、ツール引数、コードブロック、出力ファイル、実行記録、ナレーションにはトークンを記載しないでください。最終検証／差分確認の呼び出し後に、実行記録を書いたりプランを更新したりしないでください。定型の質問とタグを直ちに出力してください。

  アンバインドのゲートは分離してください： 作成とバインド、およびアンバインドは、それぞれ独立した確認が必要です。まずカタログメッセージ r2_create_bind だけを尋ねてください。ユーザーの確認後、書き込み（または完全一致の Idempotent-Skip）が完了したら、新しいターンでカタログメッセージ r3_unbind を尋ねてください。アンバインドを作成とバインドの質問に含めないでください。また、作成とバインドの承認で remove-config-from-machine-group（--cli-dry-run を含む）を実行しないでください。

  確認を省略しないでください： 自動化、緊急性、パラメーターがすべてそろっていること、元のタスクの文言は、いずれもこのゲートを無効にしません。回答を待っている間は、最初の確認時に中国語の質問と [AWAITING: R2_CONFIRMATION] ask=1 を出力してターンを終了し、ユーザーの次のメッセージを待ってください。同じターン内での書き込みはゲート違反です。 質問の後、次のユーザーメッセージに明示的なカタログの approval マーカーが含まれるまで、--cli-dry-run、create-*、apply-config-*、update-* を実行しないでください。

  ゲートの必須チェックリスト（承認 → 実行）： 0. 計画が実際に整ってから、1 回だけ尋ねてください。いずれかの設定ペイロードに対して scripts/validate_pipeline.py の検証に合格し、計画されたすべての書き込みに対して scripts/normalize_diff.py を実行している必要があります。検証と差分確認が済んでいない計画への承認を求めるのはゲート違反です。

  1. 自分で生成したものを回答として扱ってはいけません。ユーザーが決定を明示しないままターンが終了する場合は、[AWAITING: R2_CONFIRMATION] ask=<n> を出力し、同一の質問をして待ってください。
  2. 元のタスクの文言、「タスクで明示的に要求されている」、「パラメーターがすべてそろっている」、またはすでに表示したプランの表を、承認として扱ってはいけません。
  3. ユーザーが「はい」／「確認」／「承認」と明示的に回答するか、同等のカタログ approval マーカーがある場合に限り、実行に進んでください。
  4. R2/R3 の書き込みに対する --cli-dry-run は実行の一部です。明示的な承認を得る前に実行することは禁止です。承認を求めずにプランを表示してからドライランすることも、ゲート違反です。
  5. このゲートに違反した場合、タスク失敗となります。 回答なしルール（厳守）： 空の返信、「later」、「not sure yet」、カタログの deferral マーカー、またはそれに相当する先延ばしは承認ではありません。最初の確認ターンで n を 1 として、質問カウンターを開始します。先延ばしがあるたびに、まだ待機中のリソースと操作を1行で言い直し、同一の中国語の確認事項をちょうど1回再度尋ね、最後の行に [AWAITING: R2_CONFIRMATION] ask=<n+1> を記載します（カウンターは 1 → 2 → 3）。質問や AWAITING タグを2回出力してはいけません。タグの後に空行を追加してはいけません。ask=<n> のない質問の繰り返しだけの返信、または質問を含まない「ゆっくり考えてください」という締めくくりは、どちらもこのルールに違反します。ユーザーが3回目の質問に対して再びカタログの deferral マーカーで返信した場合、次のターンの内容は [BLOCKED: R2_CONFIRMATION_TIMEOUT] のみとします。4回目の質問をしたり、書き込みやドライランを実行したりしてはいけません。明示的な拒否／キャンセルの場合は、[CANCELLED: R2_CONFIRMATION_REJECTED] のみを返します。User rejected the proposed plan… などの英語の文章を付け加えてはいけません。意味の詳細は references/risk-and-approval.md を参照してください。 終端状態での即時停止： [BLOCKED: …] / [CANCELLED: …] タグの出力後は、（write_file を含む）ツール、ドライラン、書き込み、Verify を一切実行しないでください。インストール成功後のコレクションゲートによる拒否は、報告に関する唯一の例外です。[CANCELLED: R2_CONFIRMATION_REJECTED] とカタログの正確なステータス install_only_status を出力し、ツールを一切使わずにターンを終了してください。権限拒否の場合は、§2 の未実行の必須読み取りを列挙してもかまいませんが、実行が終了したことを明記してください。それ以外の終端ターンでは、短いタグのみを出力してください。ユーザーが作業を再開した場合に限り、新しい Plan と確認を行って再開してください。

• 実行： 承認済みのコマンドのみ実行し、--user-agent と§4のアトミックルールに従ってください。実際に書き込む前に、必ず --cli-dry-run を単独の呼び出しとして実行し、リクエストが拒否された場合に状態が変更される前に検出できるようにしてください。冪等性： 作成／適用の前に取得してください。状態が一致する場合は、ドライランと書き込みの両方を省略し、get/list で確認したうえで、Changes に正確に [Idempotent-Skip] <create/apply-command> skipped; verified via <get/list-command> that state matches expectation. を出力してください。get により対象の Project／Logstore のシャード／TTL がすでに確認できる場合、create-project／create-log-store（ドライランを含む）を実行するとタスク失敗になります。AlreadyExist の場合は、取得して比較し、一致すれば Idempotent-Skip、不一致なら [BLOCKED: EXISTING_RESOURCE_CONFLICT] としてください。config.modify の例外： 設定／インデックスの変更（フィールド名の変更、解析方法の変更、インデックスの同期）をユーザーが明示的に依頼した場合は、必ず scripts/normalize_diff.py を実行し、カタログメッセージ r2_update を確認後、update-logtail-pipeline-config と連動する update-index を実行してください（それぞれ、先に個別の --cli-dry-run を実行します）。スナップショットがすでに一致しているという理由で、この2つの書き込みを省略してはいけません。依頼された変更であるため、上書きしてください。作成／適用時の Idempotent-Skip は引き続き適用されます。AgentSight のロック： 引き続き Plan と HITL を行い、その後 create-logtail-pipeline-config を実行してください。AlreadyExist の場合は [Idempotent-Skip] とし、更新してはいけません。 Logstore の Idempotent-Skip 出力： shardCount／TTL がすでに一致する場合、ユーザー向けの最終回答に、スキップしたコマンド名を含めてください。例：[Idempotent-Skip] create-log-store skipped; verified via get-log-store that state matches expectation. エラー復旧（最大3回再試行／合計4回。errorCode と requestID を保持）： python3 scripts/classify_sls_error.py を優先し、その error_tag を説明より先に出力してください。マッピング：400／ParameterInvalid→[Error: parameter] の後に修正し、同じ API を再試行→[RECOVERED: parameter_fixed]；429／WriteQuotaExceed→[Error: throttling] とバックオフ→[RECOVERED: throttling_retry]；500→[Error: internal] と同じコマンドを再試行→[RECOVERED: internal_retry]；メッセージが所有権に関する401／403（does not belong to you）→[BLOCKED: RESOURCE_RESOLUTION_FAILED]（RAM HITL ではありません）；その他の401／403→[Error: permission] の後、§2の Permission Failure Handling に従う（カタログメッセージ permission_recovery を確認）。カタログで permission_grant が確認されたらユーザー向けに [RECOVERED: permission_granted] とし、同じターン内に同一コマンドを再試行してください。カタログで permission_decline が確認されたら、内容が [BLOCKED: PERMISSION_REQUIRED] のみとなるようにしてください。ドライランの失敗にも同じ分岐を適用します。実際の書き込みは、ドライランが成功した後に限ります。

• get-logs-v2 が meta.progress=Incomplete を返した場合は、クエリが未完了です（最終結果として扱える通信成功ではありません）。[Query: Incomplete] attempt=<n>/4 を出力し、§9に従って同一のリクエストを再試行してください。meta.progress=Complete の場合は Complete と報告し、INCOMPLETE を出力したり、未完了の再試行を捏造したりしてはいけません。

• Verify： Execute の後に、受け入れの証拠を必ず再読み込みしてください。作成または変更したオブジェクトは、それぞれ専用の get-*（get-log-store、get-machine-group、get-logtail-pipeline-config、get-index）で確認し、両方向のバインド（get-applied-configs と get-applied-machine-groups の両方）およびハートビート用の list-machines も確認してください。該当する get-index、両方のバインド読み取り、list-machines、業務用 get-logs-v2 呼び出しが実際に実行されるまで、Verify の完了を宣言したり、最終報告の作成を始めたりしてはいけません。特に、新規作成したマシングループには作成後の get-machine-group が必要です。Observe フェーズでの404は、受け入れ確認として認められません。Observe フェーズの読み取りは以前の状態を示すものであり、受け入れ確認としては認められません。U1-U6 に対し、15秒間隔で最大4回の範囲内ポーリングを行ってください。設定の作成／更新／バインド、またはオンボーディングの後は、最終回答の前に、業務用 Logstore に対する get-logs-v2 の受け入れクエリを必ず実行してください。「設定を確認済み」「コレクターのハートビートがない」「まだデータが届かない」といった理由で省略するとタスク失敗になります。観測された件数／進捗を報告してください。行が届かない場合（count=0／data=[]）は、カタログの data_incomplete と data_empty に加えて reason も必ず報告してください。U5 が空の場合、カタログの forbidden_empty_success マーカーはすべて使用禁止です。行数ゼロを配信成功とみなしてはいけません。最後のユーザー向け回答（後からバインド解除を行った場合も含む）には、カタログの data_arrived または data_empty と reason を必ず含めてください。オンボーディング／Verify 後のユーザー向け最終要約には、リソース名3つだけでなく、Project の完全名、Logstore、マシングループ、設定名を必ず記載してください。

• ロールバック： 実行前のスナップショット、または宣言された逆操作に限ります。記憶を頼りに設定を再構築してはいけません。 入力契約と停止条件：references/prerequisites.md。

対象範囲とアダプターのルール

• クラウド専用の機能は、aliyun sls とローカルバリデーターを通じて実行します。既存のクラウド専用評価では、引き続き SSH と kubectl を禁止します。
• install.deploy では、aliyun ecs run-command と aliyun ecs describe-invocation-results（ECS）、ユーザー SSH（フィンガープリント確認済みで、チャットに秘密鍵を記載しない）、aliyun cs（アドオン名 loongcollector）、および self_k8s パッケージのインストールとオプトインの CR の取得・適用に kubectl を使用できます。workbench exec / OOS / kubectl exec / docker exec / 制限のない root シェルは禁止です。 kubeconfig やクライアント証明書を表示してはいけません。一時ファイルは 0600 でのみ書き込んでください。
• インストール後、ホストのパスでは必ず onboarding.cloud を呼び出します。K8s のパスでは、必ず公式の Project／マシングループを再利用し、デフォルトでは SLS API を通じてパイプラインを作成してから、U1～U6 と get-logs-v2 を実行します。CRD の適用は、ユーザーから明示的な依頼があった場合に限ります（references/crd-pipeline.md）。
• 1 回のリクエスト中は、アカウント／プロファイル、リージョン、プロジェクト、クラスター、グループ、設定を固定します。スコープを変更する場合は、新たに確認が必要です。
• 設定ごとに管理プレーンは 1 つです。API または CRD のどちらか一方を使用し、併用してはいけません。二重書き込みが検出された場合は、停止します（references/pipeline-config.md、references/crd-pipeline.md）。CR が所有する設定を API 経由で更新してはいけません。デフォルトで API を選択しても、2 つ目のプレーンを作成する権限にはなりません。

---

7. リスク、承認、ロールバック

レベル	例	承認
R0 読み取り	list/get、ステータス、ログクエリ	自動
R1 ローカル	スキーマ検証、レンダリング、差分	自動
R2 元に戻せる書き込み	リソースの作成、設定の更新、適用／バインド、インデックスの作成／更新、コレクターのインストール、CR の kubectl apply	差分を提示し、確認を 1 回行う
R3 影響大	削除／バインド解除、一括変更	影響を説明してから確認
R4 破壊的	プロジェクト／ログストア／設定／グループの削除	リソースを再提示して、2 回目の確認を行う

R2 の確認は必須です。 明示的な肯定回答があった場合に限り、実行が許可されます。タスクの文言を暗黙の承認として扱ってはいけません。作成とバインド、およびバインド解除は、それぞれ別の確認事項です（§6 SEPARATE UNBIND GATE を参照）。拒否とタイムアウトには §6 の正確な終端ステータスを使用し、ロールバックには新たな承認ワークフローが必要です。§6 の TERMINAL-STATE HARD STOP は [BLOCKED: PERMISSION_REQUIRED] およびその他すべての終端タグを対象とします。いずれかのタグを出力した後は、新たに Plan と承認のサイクルが完了するまで、ドライランを含むクラウドへの書き込みを続行してはいけません。

詳細、スナップショットの形式、ロールバックについては、references/risk-and-approval.md を参照してください。Update の前に Get を行ってください（Update は上書きの意味を持つため、変更しないフィールドも引き継いでください）。Create の前に Get を行ってください（§6 Execute の AlreadyExist の冪等な処理を参照）。新しいリソースのロールバックでは、削除をデフォルトにしません。

---

8. 設定とインデックスの連携（必須ルール）

プロセッサーでフィールドを追加、削除、または名前変更する場合、必ず次のことを行ってください。1）設定差分と対応するインデックス差分を一緒に生成する。2）両方の差分を1つにまとめてユーザーに提示し、確認を1回だけ求める。3）承認後、まず2つの直接ドライラン呼び出し（config dry-run → index dry-run）を実行し、その後、実際の書き込みを2つの独立した呼び出しとして連続して実行する（config write、直後に index write）。その間に、他のコマンド、待機、ステータス確認、一時停止を挟んではいけません。「連続して」とは、2つの呼び出しを続けて個別に実行するという意味です。&&、;、その他のシェル連結を使って結合してはいけません。§4で禁止されており、連結したコマンドが失敗すると、片方だけが適用された状態になります。「今は設定だけ更新し、インデックスは後で追加する」ことはせず、2つの変更を別々の確認に分けることもできません。ドライランが失敗した場合、実際の書き込みはどちらも実行しないでください。設定の書き込みが成功した後にインデックスの書き込みが失敗した場合、バッチは未完了です。同じターン内で§6のエラー回復分岐を通じて、同一のインデックスコマンドを直ちに再実行し、元の errorCode／requestID を維持して、両方の結果をまとめて報告してください。推測でペイロードを再設計してはいけません。また、設定だけが更新され、インデックスが保留中の状態でターンを終了してはいけません。バックエンドがインデックスを自動同期する場合は、計画と同じ確認の中でその旨を伝えてください。

• status／status_code／http_status は既定で long にします。時間／レイテンシー／バイト数は意味に応じて選択します。
• SLS には float 型のフィールドインデックスはありません。浮動小数点数の要件（例：request_time float）は double に割り当て、その対応をインデックス差分に示してください。
• JSON のネストされたフィールドでは、親の json インデックスまたはフラット化されたフィールドインデックスを明示的に宣言してください。
• プレフィックスを変更する場合は、インデックスのフィールド名と受け入れクエリも同時に更新してください。
• processor_rename は拡張版のみです。JSON の名前変更では、すべて拡張版の processor_json → processor_rename を使用し、複数形の SourceKeys／DestKeys を指定してください（SourceKey／DestKey／processor_rename_native は使用しないでください）。インデックス差分では古いキーを削除し、新しいキーを追加してください。http_status は既定で long です。完全な例については references/index-coupling.md を参照してください。
• 次の順序を厳守してください。設定／インデックスのスナップショット → 完全な対象設定に対する scripts/validate_pipeline.py → scripts/normalize_diff.py --kind config → scripts/normalize_diff.py --kind index。生の diff は使用できません。

必須コマンドマッピング： Pipeline の名前のみを使用してください（*-logtail-pipeline-config、get-applied-configs／get-applied-machine-groups、apply-config-to-machine-group／remove-config-from-machine-group）。作成フラグ：--project-name／--logstore-name／--group-name。読み取り／バインド：--project／--logstore／--machine-group。update-log-store には --logstore と --logstore-name の両方が必要です。従来の get-config／get-logs／list-logstore エイリアスは使用しないでください。従来の inputDetail 設定は [BLOCKED: CLASSIC_CONFIG_UNSUPPORTED] としてください。このマッピング内のコマンドは検証済みなので、--help のために呼び出しを消費しないでください。インデックス：既存の場合は update-index、存在しない場合は create-index を使用してください。--line では "chn": true を指定します。text キーの token は、区切り文字列を格納した JSON 配列です。文字列を連結すると IndexInfoInvalid: field token is of error format が返されます。IndexInfoInvalid／トークン形式のエラーが発生した場合は、aliyun sls のみを使用して修正してください（--keys を区切り文字列の JSON 配列として書き換えるか、タスクのワークスペースにある JSON ファイルからキーを渡します。~/.aliyun/config.json は使用しないでください）。aliyun-log-python-sdk のインストールや呼び出しは禁止です。許可された再試行後も CLI 側の修正に失敗する場合は、[BLOCKED: PARAMETER_UNRESOLVED] を出力して停止してください。完全な仕様については references/cli-contracts.yaml、references/index-coupling.md、references/field-conventions.md を参照してください。

---

初回作成フラグの不変条件： create-project の初回のドライランと実際の呼び出しでは、必ず --project-name を使用してください。--project でプローブしてはいけません。create-log-store には --logstore-name、create-machine-group には --group-name を使用してください。後続の再試行が成功した場合でも、失敗した探索的な書き込み呼び出しによって順序評価が損なわれることがあります。

9. SLS Lens（CloudLens for SLS）の実行ログ

Lens は、基本的なトラブルシューティングにおける主要なデータソースです。実行ログのクエリ自体には、パブリックな aliyun sls get-logs-v2 を使用します。

エントリの検出。 まず get-project で業務プロジェクトを確認してください。業務プロジェクトが見つからない場合はクエリが空になるため、それを Lens の障害として報告してはいけません。次に、そのプロジェクトで（存在しない場合でも）get-logging を一度実行し、python3 scripts/parse_lens_logging.py を実行してください。状態遷移：(1) 利用可能なエントリ（loggingProject／解析済みの Lens プロジェクトとログストア）がある場合 → 確認して使用し、[AWAITING: LENS_ENTRY] を要求してはいけません。(2) それ以外で、ユーザーから lens_project／lens_logstore が提供された場合 → 確認して使用します。(3) それ以外の場合、Lens 以外のすべての独立した読み取りをそれぞれ一度実行した後（ProjectNotExist の場合でも get-applied-configs を含みます）に、カタログのメッセージ lens_entry を正確に一度だけ尋ね、最後の行に [AWAITING: LENS_ENTRY] を出力します。このターンのユーザー向け内容は、その質問とタグだけにしてください。結論、証拠のダンプ、カタログの root_cause_located マーカーを含めてはいけません。ターンを終了し、応答を待ってください。業務プロジェクトを再利用したり、そこに internal-diagnostic_log を作り出したりしてはいけません。 ユーザーの回答後は、必ず予定していた logtail_alarm とバージョンに応じたメトリッククエリを実行してから、結論を書いてください。(4) ユーザーが情報を提供できない場合は、独立した MG／設定／業務プロジェクトの確認を続け、resource_status: Resource not found とします。「アラームなし」と捏造してはいけません。Lens／トラブルシューティングの最終レポート後は、停止してください。Lens の場所を再度尋ねたり、カタログの end マーカーを待ったりしてはいけません。

禁止事項： STAROps／JWT／コンソール Cookie の使用、log-service-{uid}-{region} の推測、検出に失敗した後に業務プロジェクト上の Lens トピックを使用すること、一度だけ尋ねる HITL の省略。[AWAITING: LENS_ENTRY] は troubleshoot.basic／lens.query に限って使用します。 オンボーディング／設定でコレクターのバージョンが不明な場合は、Lens ではなく [AWAITING: COLLECTOR_VERSION] を使用します。

クエリの厳守事項（全項目：references/sls-lens-contracts.md、references/monitoring-queries.yaml）：select * は使用しないでください。バージョンによるルーティングは >=3 → loongcollector_metric、<3 → logtail_profile／logtail_metric とし、失敗した場合でも、その get-logs-v2 を実行する必要があります。logtail_alarm は project でフィルターし、where 句に config_name を使用してはいけません。Incomplete の場合は [Query: Incomplete] attempt=<n>/4 を出力し、同一のクエリを最大4回まで再試行します。4回後も不完全な場合は INCOMPLETE とします。Complete の場合は Complete と報告し、INCOMPLETE と捏造してはいけません。Lens のプロジェクト／ログストア／トピック／時間枠／ルート／完了状態を報告してください。

---

必須のバージョンルート呼び出し： 既知のコレクターバージョンが >=3 の場合は、3.2.6 を含め、__topic__: loongcollector_metric を含む aliyun sls get-logs-v2 クエリを個別に実行してください。logtail_status クエリは追加の証拠であり、メトリッククエリの代わりにはなりません。先行する Lens クエリが結果を返さない場合やエラーになる場合でも、この呼び出しを実行してください。

10. トラブルシューティング（データなし、ハートビート）

固定チェーン：classify → heartbeat & version → config & binding → alarm/metric → business data → minimal fix → re-verify。

• 厳守ルール — 診断チェーンを途中で止めてはいけません。 読み取り専用の手順で ResourceNotExist／ProjectNotExist／LogStoreNotExist／LoggingNotExist が返された場合は、残りの独立した診断手順をすべて実行してください。get-applied-configs は Project の存在に依存しません — get-project／get-machine-group がすでに 404 を返していても一度実行してください。バインディングの証拠として get-logtail-pipeline-config で代用してはいけません。業務データの get-logs-v2 も独立しています — Project がない場合でも、指定された業務ログストアに対して一度実行してください（ProjectNotExist／LogStoreNotExist が返ることを想定します）。Lens のエントリーを尋ねるターンでは、カタログメッセージ lens_entry と [AWAITING: LENS_ENTRY] のみを出力し、そのターンではレポートを作成しないでください。最終レポートの後に追加質問をしてはいけません。Lens に依存する手順では、エントリーの検出に失敗した場合はいつでも §9 に従い（1 回だけ尋ねて [AWAITING: LENS_ENTRY] を出力 → 待機 → その後にクエリ）、続行してください。これは LoggingNotExist と ProjectNotExist のどちらにも適用されます。Lens エントリーは別の Project にあり、業務 Project が見つからなくても Lens エントリーについては何も分からないためです。尋ねずに Lens エントリーが見つからないと報告したり、Lens を尋ねるターンと同じターンで最終結論を書いたりするのはタスク失敗です。対応する get／query コマンドをそれぞれ一度実行し（または HITL からエントリーが提供された後に実行し）、コマンドとエラーコードを正確に保持し、該当する場合は resource_status: Resource not found を記録して、処理を続けてください。途中で打ち切るのはタスク失敗です。この続行ルールは書き込みを許可するものではなく、権限に関する厳守事項にも優先しません。
• クラウド側の可視性とコレクター側の証拠は相互に裏付けるものであり、どちらか一方をもう一方の代わりにしてはいけません。
• データがない場合：get-logtail-pipeline-config --config-name ＋ list-machines ＋ §8 の正確なバインディングクエリ → Project ごとの logtail_alarm → logtail_status → バージョンに対応するパイプライントピック → 業務ログストア。
• ハートビート異常の場合：list-machines → logtail_status。Lens を利用できない場合は、ホスト側で確認する項目（コレクタープロセス、レポート対象リージョン、アカウント ID、user_defined_id）を挙げてください。クラウドのみを対象とするタスクでは、文章で説明してください。install.deploy では、読み取り専用のステータス確認に run-command／SSH／kubectl get を再利用できます。
• トラブルシューティングの結論にはすべて、references/troubleshooting.md で定義されているフィールドをすべて含む正確な証拠行（Heartbeat／Alarm／Collection、および該当する確認を行った場合は Binding／Pipeline）を必ず出力してください。フィールドを省略せず、代わりに N/A／unknown を使用してください。必須フィールドを省略するとタスク失敗です。リソースが見つからない場合、resource_status: には英語のトークン Resource not found を必ず指定してください。カタログの not_exists マーカーでは代用できません。ユーザー向けの最終回答（outputs/*.md だけではありません）に、これらの行を含めてください。証拠を提示した後にユーザーがカタログの end マーカーを送った場合、最終回答となる短い締めくくりを新たに書かないか、締めくくりにも同じ証拠トークン（resource_status: Resource not found を含む）を再掲してください。

プレイブックとアラーム対応カード：references/troubleshooting.md、references/alarm-catalog.yaml。

---

11. 出力契約

すべての実行で、少なくとも次の内容を出力します。結論（完了／一部完了／ブロック／ロールバック済み） · 範囲（profile-id／region／Project full name／logstore／group） · エビデンス（主要な結果。トラブルシューティングでは、適用される§10のエビデンス行をすべて、Binding／Pipelineを含めて、ユーザー向けの回答に再掲する必要があります） · 変更（正規化された差分＋実際の操作。Idempotent-Skipの注記もすべて含めます） · 受け入れ（U1-U6の結果。収集後の書き込みを伴う場合、outputs/*.mdだけでなく、ユーザー向けの最終回答にもカタログのdata_arrivedまたはdata_emptyとreasonを含める必要があります） · ロールバック（必要か？実行したか？スナップショット／逆操作） · 次のステップ（単一のブロッカー、または次に行う最小限のアクション）。リソースを作成、更新、バインド、または修復するトラブルシューティングの次のステップでは、最小限の書き込みセットを列挙し、新たに正規化された差分とユーザーの明示的な確認が必要であることを逐語的に明記します。診断を行うターンでは書き込みを実行しません。Project full nameを省略し、Logstore／マシングループ／設定のみを列挙するオンボーディング／検証の概要は、この契約を満たしません。ファイルのみのレポートは最終回答ではありません。

シークレット、コマンド履歴全体、または無関係なログを出力しないでください。監査を求められた場合は、マスキング済みコマンドとリクエストIDを出力してください（scripts/redact_output.py）。失敗した場合は、元のエラーコード／リクエストID／マスキング済みのコンテキストを保持し、成功を偽装してはいけません。

---

12. グローバルルール

1. §8 および references/cli-contracts.yaml に記載された、検証済みの正確なマッピングを優先してください。SLS コマンドは事前に検証済みのため、--help で再確認しないでください。ドキュメントに記載のないコマンドに限り、Plan の前に aliyun sls <cmd> --help を使用してください。短縮エイリアスを調べないでください。ACK では aliyun cs とアドオン名 loongcollector を使用します。初回の有効化には scripts/ensure_ack_prereq.sh（open-ack-service + CS ロール）を使用します。eval フックがフィクスチャに対して同じ処理を行う場合もありますが、Skill はそのことを把握しておく必要があります。K8s の収集では、デフォルトで create-logtail-pipeline-config を使用し、k8s-group-${cid} にバインドします。ClusterAliyunPipelineConfig の kubectl apply はオプトインの場合のみ使用します。
2. get-logs-v2 を使用してください（非推奨の get-logs は使用しないでください）。get-logs-v2 の --from／--to は UNIX 秒です。
3. 承認後、実際の書き込みの前に、毎回個別に --cli-dry-run を実行してください。ドライランは業務上の承認ではありません。§8 の連動する書き込みでは、2 回の実際の書き込みを中断せずに行う前に、両方のドライランを完了してください。正確に Idempotent-Skip となる場合は、どちらの呼び出しも実行しません。
4. Update の前に Get を実行してください。Update は上書きのため、変更しないフィールドも引き継いでください。
5. コレクターのバージョンが >=3.x の場合は、まずネイティブプラグインを使用してください。バージョンが不明な場合は、カタログのメッセージ collector_version で確認してください。プラグインファミリーを推測しないでください。ネイティブプラグインで要件を満たせない場合（例：processor_rename）は、拡張プラグインを使用し、トレードオフを説明してください。
6. kubectl exec／docker exec は使用しないでください。管理者プロジェクト、starops、内部 MCP、プライベートコンソール API も使用しないでください。SSH／run-command／kubectl は、指定された install.deploy（およびその後の読み取り専用ステータス確認）の場合にのみ使用できます。Workbench／OOS は使用しないでください。
7. 不明なアラームコードについては、公式ドキュメントまたは references/alarm-catalog.yaml を参照してください。記憶に頼って説明しないでください。
8. aliyun を sudo 経由で実行しないでください。現在のユーザーとして直接実行してください。エラーを回避するために、ユーザー、シェル、アカウント、認証情報プロファイルを切り替えないでください。
9. 自分が作成していない環境変数や CLI 設定を変更またはクリアしないでください。インフラストラクチャレベルの障害（API エラー以外）の場合は、同一のアトミックコマンドを 1 回再試行してから、生の出力を報告して停止してください。期待される応答を捏造しないでください。
10. 失敗した呼び出しは、その呼び出し自体の応答（errorCode、requestID、メッセージ）と references/ に基づいて診断してください。呼び出しがそのように動作した理由を説明するために、CLI バイナリ、インストールディレクトリ、ローカル設定ファイル、環境を調査しないでください。これはこのスキルの対象外であり、ユーザー設定が漏えいするリスクがあります。
11. 元のリクエストとすべてのパラメーターが、暗黙の R2+ 承認として扱われることはありません。差分提示後の明示的な承認のみが有効です。
12. SLS のクラウド呼び出しはすべて、リテラルパラメーターを指定した直接のアトミックコマンドとして実行してください。
13. 同梱の scripts/ ヘルパーのみ使用できます：preflight.sh、render_pipeline.py、validate_pipeline.py、normalize_diff.py、redact_output.py、classify_sls_error.py、parse_lens_logging.py、render_loongcollector_install_cmd.py、wait_cs_task.sh、render_crd.py、ensure_ack_prereq.sh。§6／§8 のワークフロー上の指定箇所では、validate_pipeline.py／normalize_diff.py の使用が必須です。2xx 以外の応答では classify_sls_error.py を使用してください。get-logging の後には parse_lens_logging.py を使用してください。ユーザーが ClusterAliyunPipelineConfig のローカルでのレンダリング／検証のみを依頼した場合は、render_crd.py + validate_pipeline.py を実行して停止してください。aliyun cs、kubectl、クラスターへの接続は行わないでください。クラウド SDK を pip install しないでください。また、aliyun.log をインポートしないでください。
14. 1 回のターンにつき質問は最大 1 つとし、質問したらそのターンを終了して、ユーザーの次のメッセージを待ってください。自分の質問に自分で答えないでください。

---

13. 成功確認

合格条件と失敗時の対応経路を含む統合受け入れ基準 U1〜U6（設定オブジェクト／グループバインド／適用状態／ハートビートとバージョン／データ到着／フィールドとインデックス）については、references/acceptance-criteria.md を参照してください。各ステップの確認コマンドについては、references/verification-method.md を参照してください。

---

14. クリーンアップ

クリーンアップは R3/R4 です。削除する前にバインドを解除し、削除時にはリソースを再確認します。このスキルで作成した設定の処理順序は、remove-config-from-machine-group → delete-logtail-pipeline-config → （任意）delete-index / delete-log-store です。delete-index / delete-log-store は、ユーザーから明示的な確認がある場合にのみ実行してください。詳しくは references/risk-and-approval.md を参照してください。

---

15. ベストプラクティス

1. CLI を優先し、プラグインモードのハイフン区切りのサブコマンド（aliyun sls get-logs-v2）を使用します。従来の RunXxx 形式や、ドキュメント化されていないエイリアスは使用しません。
2. クラウドへの呼び出しを行う前に、リージョン／プロジェクトなど、ユーザー固有のパラメーターを確認します。アカウントの値をハードコードしてはいけません。
3. すべてのクラウド呼び出しで、2 つのトークンから成る --user-agent（AlibabaCloud-Agent-Skills/alibabacloud-loongcollector-ops + session/{session-id}）を使用します。スクリプト自体がクラウド API を呼び出す場合は、SKILL_SESSION_ID を設定します。
4. R2 以上の書き込みを行う前に、正規化した差分を確認して承認します。ドライランと書き込みは、別々のアトミックな呼び出しとして実行します。
5. references/ram-policies.md に基づいて最小権限の RAM を設定します。権限エラーが発生した場合は、§2 のゲートに従います。
6. 破壊的なクリーンアップは R3/R4 の確認を経てから行い、削除前にバインドを解除します。
7. 段階的開示を行い、実行中の機能に対応する references/* の項目だけを読み込みます。
8. 判断待ちの間は、同じ質問を再提示して返答を待ちます。沈黙や先送りを同意と見なしてはいけません。

---

参考資料

ファイル	内容
references/navigation.md	機能ルーターの仕様（入力、アダプター、状態）
references/prerequisites.md	事前確認ゲートと入力契約
references/cli-installation-guide.md	Aliyun CLI と SLS プラグインのインストール
references/cli-contracts.yaml	aliyun sls コマンドの契約とステータス
references/related-commands.md	aliyun sls コマンド一覧
references/ram-policies.md	ワークフローごとの RAM Actions と権限ゲート
references/risk-and-approval.md	R0-R4、スナップショット、ロールバック
references/machine-group.md	マシングループ、ID、ハートビート、バージョン
references/pipeline-config.md	パイプライン設定モデル、Get-then-Update
references/plugin-version-gates.yaml	1.x/2.x/3.x プラグインのゲート
references/index-coupling.md	設定／インデックスの同一バッチルール、アンチパターン
references/field-conventions.md	フィールドの命名規則、インデックス型のマッピング
references/task-model.yaml	統合タスクオブジェクト
references/scenario-matrix.yaml	host/docker/k8s/host_agentsight のシグナルと入力
references/agentsight-agentloop.md	Agentloop AgentSight の固定パイプライン、ProbeConfig、マスキング
references/input-agentsight.md	input_agentsight のスキーマ、組み込み機能、バージョン／カーネル、RawHttpsFallback
references/sls-lens-contracts.md	Lens エントリーの状態マシン、トピック／フィールド
references/monitoring-queries.yaml	Lens SQL ライブラリ（get-logs-v2）
references/troubleshooting.md	データなし／ハートビートのプレイブック
references/alarm-catalog.yaml	アラームコード処理カード
references/acceptance-criteria.md	インストール段階のゲート + U1-U6 + CLI の受け入れパターン
references/verification-method.md	手順ごとの検証コマンド
references/install-ecs.md	ECS Workbench + loongcollector.sh
references/install-host.md	セルフホスト環境での SSH + 同じスクリプト
references/install-ack.md	ACK アドオン loongcollector + 初回使用時の open-ack-service / CS ロール
references/install-k8s.md	セルフホストの k8s カスタムパッケージ
references/crd-pipeline.md	オプトインの ClusterAliyunPipelineConfig + 一時的なパブリック KubeConfig
references/knowledge-sources.md	ソースの由来、変更追跡