huawei-cloud-solution-ops

Huawei Cloud Agent Skill

Overview (Core Positioning)

• A single skill covers Huawei Cloud onboarding, usage, and management scenarios, centered by default on tenant experience and a verifiable closed loop.
• Cloud resources by default prioritize the use of hcloud: it is better suited for an Agent to do operation discovery, one-off queries/changes, dry-run, and read-back. The Agent still selects hcloud, SDK, or Terraform on its own based on task intent, runtime capabilities, and evidence quality; for detailed decisions see references/backend-selection.md。
• The SDK is a supported programmatic backend, suitable for typed requests, complex bodies, pagination/concurrency, structured exceptions, or tasks where hcloud currently does have coverage/parsing obstacles.hcloud_sdk_readonly.py 's allowlist only constrains that convenience runner; it does not restrict the Agent from writing task-specific SDK code.
• Terraform is triggered by IaC intent, used for repeatable creation, environment replication, long-term management, import, or drift; it is not an ordinary fallback after hcloud fails. Pre-discovery and post-verification prioritize hcloud, and equivalent SDK/API, data source, and business probe evidence are also allowed.
• High-frequency scripts are an optional wrapper around the above backends, not a fourth backend. When a script covers the target, prioritize reusing its version selection, parameter validation, desensitization, output convergence, and error classification; for uncovered long-tail tasks, directly use evidence-backed hcloud, official SDK, or Terraform.
• In the documentation, python3 scripts/<name>.py ... assumes the current directory is the Skill root directory. When the current directory is uncertain, use bin/hcloud-skill <name> ...; on Windows use bin/hcloud-skill.cmd <name> .... This stable entry point only locates the current Skill's bundled scripts and passes parameters through as-is; it does not choose services, operations, parameters, or invocation order for the Agent.
• For Agent-facing scripts, a successful result provides at least the boolean success; by default the final stdout is a JSON object. Large results or structured entries already selected may further provide huaweicloud_skill_public_result_v1 artifact receipts, but small planners/inspectors do not need to mechanically add --output-file. For explicit Markdown, shell-command, and item-by-item image progress modes see references/public-script-contract.md。
• hcloud being unavailable does not mean the entire Skill is unavailable; if the SDK or Terraform fits the task and runtime conditions are complete, you can continue. Regardless of which backend is used, you must not claim to have queried, modified, or completed anything without real execution and read-back evidence.
• MaaS is an API-first capability surface. Model calls use the MaaS API Key; usage statistics are governance queries, handled per local AK/SK signature planning. Do not let users paste keys in the conversation.
• The goal is not to memorize commands, but to reliably complete: identify context -> discover resources/operations -> construct safe commands -> query or change -> read-back verify -> handle errors.

When to Use

Prefer to use this skill in these scenarios:

• The user mentions Huawei Cloud,hcloud, KooCLI, CLI, command line, cloud resource query, creation, change, troubleshooting, or governance.
• The user needs to view services/operations, construct --cli-jsonInput, use --cli-query、--dryrun、--cli-waiter , and other CLI capabilities.
• The user needs troubleshooting for Huawei Cloud authentication, region/project, profile, meta cache, network, or output format.
• The user explicitly needs Terraform/IaC, MaaS large models/images/videos, or Huawei Cloud Web/OBS/CDN/ECS site asset assistance.

Do not treat this skill as general cloud knowledge Q&A for non-Huawei Cloud, a guesser of APIs without evidence, an automatic Terraform applier, or a fallback for non-Huawei model services.

The hcloud command should explicitly carry the region of the current task; the standard form is:

hcloud <Service> <Operation>/<version> --cli-region=<region> <business-parameters>

Global service confirmation may be omitted only when region is not needed; cross-region tasks must not rely on a profile's implicit default value.

Cross-service and multi-turn tasks

This skill uses a small amount of shared semantics to help different service scenarios keep goals, sources of truth, and completion criteria consistent, but it is not a task execution controller. The Agent is still responsible for understanding the on-site situation and autonomously selecting or adjusting services, tools, parameters, and operation order.

• Multi-turn, cross-service, side-effecting, asynchronous, or potentially interrupted tasks require recoverable memory. When the host already has persistent task state, prefer reusing it; when the host provides a persistent and writable workspace, you can use task.md or an equivalent file to record goals, constraints, authorization, important progress, artifacts, and next steps. When the host has no file workspace, use its available state mechanism and explain recovery limitations; do not block cloud tasks merely because of the absence of a specific task ID, file tools, or directories.
• When user requirements change, reassess complexity and update recoverable state. When a runtime task ID is visible to the Agent, reuse it as-is; when it is not visible, a stable task descriptor may be used, but it must not impersonate a platform ID. For specific suggestions, see references/task-workspace-guide.md; the template is only an optional starting point.
• When creating, deleting, replacing, or binding paid/side-effecting resources, retain logical roles, expected quantities, canonical resources, and pending operations. When a pending operation has not yet confirmed a final state or its result is unknown, first read back to converge and avoid duplicate side effects.
• Raw large outputs from cloud APIs, web pages, or tools are stored in artifacts; task state retains only trusted summaries and references. Broad goals such as enterprise websites, cross-service resource inventories, and cost governance can read as needed references/goal-capability-guide.md, the router, and the matched playbook; for state expression, see references/interaction-guidance.md. These are all optional aids and do not decide architecture, tools, parameters, or order on behalf of the Agent.

Default workflow

1. First select a candidate backend and confirm the context:
   • By default, consider hcloud first; run according to the actual backend python3 scripts/hcloud_environment_doctor.py --need <dependency> --pretty. When choosing the SDK, use --need sdk --sdk-service <SERVICE>, and when choosing Terraform, use --need terraform; when real APIs, networking, or large result files are needed, additionally add --need live、--need network、--need artifacts. For complete rules, see references/runtime-dependencies.md。
   • doctor/context can only observe the current process environment and local profile; not observing AK/SK or a MaaS API Key only indicates that the configuration status is unknown, and you must not assert that the user has not configured it. Runtimes using a credentials broker may inject credentials only in an authorized execution subprocess.
   • When project-level service project_id is needed, use python3 scripts/hcloud_project_resolve.py --region=<region> --pretty, resolving in the order of explicit value, environment variable, local profile cache, IAM KeystoneListProjects ; do not rewrite the signed request just because the IAM SDK is not installed.
   • If hcloud.found=false, do not execute the hcloud path; follow references/backend-selection.md to determine whether the SDK or Terraform can reliably complete it; otherwise provide only a draft solution and environment gaps.
2. Route broad or architecturally unclear goals as needed:
   • hcloud_scenario_router.py can help find a small number of playbooks, guides, planners, SDK and Terraform candidates; when the goal, runtime vehicle, and service are already clear, the router can be skipped.
   • For broad or architecturally unclear website deployment tasks, you can first read the router's architecture_decision and matches; it is a decision aid, not a prerequisite gate for all website tasks, and it does not preset ECS, OBS, Flexus, or specific specifications on behalf of the Agent.
   • For website deployment tasks, first read the top-level architecture_decision, then note that matches。explicit_constraints is a user constraint, not a cost-optimization hint; when the user specifies a machine, ECS, public IP, SSH, Nginx, or Docker, do not automatically change it to OBS.
   • change_execution_blocked=true , clarify the runtime carrier or dynamic capability around clarification_question as-is; before confirmation, do not generate or execute changes such as creation, purchase, upload, or public access.change_execution_blocked=false only indicates that architecture clarification is not currently needed,it does not indicate that the user has authorized execution。
   • When a website task involves resource billing, public network exposure, domain/DNS/HTTPS, or MaaS image/video calls, first provide the user with a consolidated plan and then wait for confirmation. The plan must at least explain: the recommended architecture and resources, region, network and public entry point, domain/HTTPS handling method, number and purpose of MaaS assets, ongoing costs, and main risks; for ongoing costs, prioritize citing the cost_estimatefrom the change plan; if its status=unknown, you must explain the reason and scope as-is, and must not pass off a resource list or empirical price as a real-time quote. The user's first "help me build/deploy/launch" only authorizes planning and read-only prechecks, not paid resource creation, MaaS API calls, uploads, or public network exposure; only after the user sees the plan and explicitly replies "continue with this plan" or gives equivalent confirmation may execution proceed.
   • Read only the small amount of material that matches, and do not browse the catalog, Terraform examples, or long references in full.
3. Default stabilization for query-type tasks:
   • The Agent independently decides what to query and what business parameters to pass; run this Skill's dedicated CLI directly through the current runtime's ordinary command execution tool, without relying on host-specific Function Calling names, and do not invent nonexistent platform Tools.
   • For account-level multi-service inventory, use python3 scripts/hcloud_account_inventory.py --region <region> --execute --strict --output-file <workspace-result.json>. The script resolves and reuses project_idonce per region, queries services with limited concurrency, and returns a compact summary and the location of the complete result file on stdout. When it may be interrupted by the host runtime, add --checkpoint-file <private-checkpoint.json> --time-budget <seconds>; on the next round, use the same query parameters and --resume to continue only the unfinished checks, without repeating completed services.
   • For bills, costs, or expense records, use python3 scripts/hcloud_billing_live_read.py ... --execute --confirm-live-billing-read READ_BILLING_DATA --output-file <workspace-result.json>. The script automatically paginates and merges within safe limits; the Agent does not manually maintain the next page offsetfor ordinary total-amount queries. For long pagination, you may use a separate --checkpoint-file and --time-budget; when resuming, reuse the accepted pages and continue from pagination.next_offset . The checkpoint contains unmasked intermediate execution data and may only be stored in a restricted workspace; it must not be read into the conversation or treated as a public result.
   • For ongoing-cost evidence of a single resource change, use python3 scripts/hcloud_cost_estimate.py --service <SERVICE> --region <region> --project-id <project-id> --resource-spec <sku> --quantity <count> .... By default, only generate a BSS pricing plan,cost_estimate.status=unknown and amount=null; only after an explicit --execute --confirm-live-billing-read READ_BILLING_DATA returns status=quoted may the amount be cited.scope must state the included/excluded components, billing mode, usage, or period; a quote is not a historical bill, nor does it create an order. For EIP, you must explicitly choose eip-bw、eip-flow or eip-ip, and must not mix address, bandwidth, and traffic into a single price.
   • After receiving the stdout file receipt, first read outcome_status、summary and result_file. When resource details are needed, use tools such as jq to extract the fields required for the current answer from the result file; do not read the entire large file back into the model context at once. When the command exit code is nonzero, still check the result file;partially_succeeded indicates that the successful part can be used and the failed services can be explicitly identified; it does not mean the entire query has no results.
   • For parameter errors, credential errors, timeouts, version parsing errors, or partial success, first determine the root cause based on the structured error. You can correct the same path, or switch to the SDK when hcloud genuinely has coverage/parsing obstacles and the SDK is better suited for typed or programmatic handling; when switching, retain the reason and revalidation items, and do not repeat queries or side effects that have already succeeded.
   • Positive example (Beijing 4 resource inventory): run hcloud_account_inventory.py --region cn-north-4 --execute --strict --output-file <workspace>/beijing4-inventory.json; after stdout returns a receipt, extract the resource names, IDs, statuses, and relationships from that file, and retain the list of failed services.
   • Positive example (Beijing 4 regional cost): run hcloud_billing_live_read.py --operation cost-data --region-code cn-north-4 --begin-time <start> --end-time <end> --execute --confirm-live-billing-read READ_BILLING_DATA --output-file <workspace>/beijing4-cost.json. Only when pagination.complete=true、complete_result_claim_allowed=true can verified_monetary_totals be described as the complete total.monthly-sum is a whole-account summary and cannot be directly treated as the Beijing 4 cost; this month's cumulative facts and the month-end forecast must also be explained separately.
   • Positive example (partial success): when an inventory returns partially_succeeded and execution_progress.pending_check_count>0 due to time budget, continue with the original checkpoint plus --resume ; when a service itself fails, read the complete result file, use the data from the successful services and explicitly list the failed services, and after fixing the cause you can rerun by service in a targeted manner.
   • Negative example: after a dedicated inventory script times out, continuously running IAM probes, an ad hoc Python SDK, and a batch of bare hcloud commands; or when the bill returns total_count=11、record_count=10、complete_result_claim_allowed=false , writing the 10 line items as the “complete total.” An empty summary also does not mean the cost is 0.
   • The invocation priority for the hcloud path is “matching dedicated scenario script -> hcloud_resource_discovery.py / hcloud_resource_query.py -> resolver/safe exec or direct hcloud with metadata/help evidence.” Scripts are a shortcut, not a whitelist; direct commands must still confirm the operation version, parameters, risks, output policy, and verification method.
   • For multi-version operations, first use hcloud_operation_resolver.py to select the version by parameters; for ordinary small queries, write the direct hcloud command explicitly as Operation/vN; when the large-output policy is hit, the parser switches to generating hcloud_safe_exec.py --output-mode=auto。hcloud_safe_exec.py and hcloud_resource_query.py already has the same version parsing logic built in.
   • The following operations all involve large output; when they are hit, it is forbidden to first run a bare hcloud to probe the response size; directly use hcloud_safe_exec.py --output-mode=auto：
     • Images, flavors, and resource lists:IMS:ListImages、IMS:GlanceListImages、ECS:ListFlavors、ECS:ListFlavorSellPolicies、ECS:ListServersDetails、DNS:ListRecordSets。
     • Logs, events, and metrics:LTS:ListLogs、CTS:ListTraces、CFW:ListAccessControlLogs、CFW:ListAttackLogs、CFW:ListFlowLogs、CES:BatchListMetricData、CES:BatchListSpecifiedMetricData、CES:ShowMetricData。
     • All-tenant and workload resources:RMS:ListAllResources、RMS:ListResources、COC:ListResources、CCI:listCoreV1PodForAllNamespaces、CCI:listNamespacedPods、CCI:listCoreV1NamespacedPod、CCI:listCoreV1NamespacedEvent、CCI:listMetricsV1beta1NamespacedPodMetrics、SWR:ListRepositoryTags。
     • Files and downloads:CodeArtsRepo:ShowFileContent、CodeArtsRepo:ShowFileRaw、CodeArtsRepo:ShowReadmeFile、CodeArtsRepo:DownloadArchive、CodeArtsRepo:ShowRepositoryArchive、RDS:DownloadErrorlog、RDS:DownloadSlowlog、DDS:DownloadErrorlog、DDS:DownloadSlowlog。
   • The following naming rules are likewise treated directly as large output, and running them bare first is not allowed: download/export/file content/archive/diff/build logs; logs/events/audit/alerts/history; CES/AOM metrics, time series, and sample points; all-tenant List*、Search*、Query*, aggregation, and resource history operations for BSS/RMS/COC/CONFIG/SECMASTER/HSS.
   • After the large-output policy is hit, the Agent only reads the summary, counts, field structure, a small number of samples, and the disk path; it must not output the complete list, complete file, or complete parsed_json to the conversation again.
   • OUTPUT_POLICY_REQUIRED is not a cloud API failure; follow the returned corrected_command or fill in the time/range parameters in corrected_command_template and then execute once more; do not retry as-is.
   • An empty return does not equal failure; if necessary, check the region/project, filter conditions, permissions, and status code.
4. For change-type operations, plan first, then execute:
   • First examine the current-state evidence, then generate a change plan or dry-run; for execution authorization, use the confirmation interaction available on the host, and the Skill does not assume specific platform function names.
   • For complex bodies, first look at what the resolver/change plan returns for request_contract。body_shape_confidence=top_level_only : do not guess from top-level fields .1 or nested dotted parameters; prefer to use --cli-jsonInput, and when necessary follow sdk_evidence_command to read the official SDK's limited-depth request schema.
   • After writing cli-jsonInput , before dry-run or submit, first run hcloud_request_preflight.py; the general change plan will also automatically preflight when it receives --json-input-file . Explicit JSON, positional, required-field, and type errors must be corrected;validation_status=partial indicates that local evidence is incomplete, and you should continue to supplement evidence with dry-run, operation help, or official documentation, and must not misrepresent it as a cloud API failure.
   • hcloud_safe_exec.py returned by execution_semantics describes the request result and resource status separately: for mutations, request_outcome=succeeded still requires read-back;request_outcome=outcome_unknown or retry_strategy=verify_before_retry , first query the target resource or asynchronous job, then decide whether to retry; resubmitting the same request as-is is prohibited.
   • When a batch or asynchronous operation hits operation_behavior , use the target paths, submit receipt, per-item outcomes, and resource read-back conditions in it as authoritative; you can also first run hcloud_operation_behavior.py --service <SERVICE> --operation <Operation>. When creation preconditions or deletion dependencies are involved, then read the dependency_evidencereturned by the planner, or run hcloud_dependency_evidence.py --service <SERVICE> --operation <Operation>; it only provides prerequisite resources, blockers, related resources, and read-back evidence, while the execution order is still determined by the Agent based on real-time state. The Agent can directly poll the declared query API and does not require a public polling framework; helper waiters are only a high-frequency shortcut, and job success still cannot replace per-resource final-state verification.
   • Interpret the output according to the actual result contract of the selected tool. If the execute script of this Skill returns outcome_status, use that structured field as the business result; bare hcloud, help probes, and other commands that do not declare structured results must retain stdout, stderr, and the exit code at the same time, and you must not assert that a cloud operation succeeded merely because the process exit code is 0 .
   • For cloud resource operations that may incur charges or affect online services, first form one or more candidate plans. The Agent may call existing tools, expert capabilities, or analyze on its own to formulate plans; each plan should explain the target resources, expected impact, ongoing costs (if applicable), main risks, and verification methods.
   • Only after the candidate plans are presented to the user for selection and explicit confirmation may the corresponding operation be executed; the user merely raising an initial request does not constitute execution authorization.
   • Real submit, as well as MaaS image/video generation that incurs billing or external side effects, must have explicit user confirmation made after viewing this plan; the initial task request, successful routing, successful dry-run, or change_execution_blocked=false are not execution authorization. Safety, identity, secret, and governance mutations default to hard guard.
5. P0 high-frequency service closed loop:
   • First run hcloud_closure_plan.py --tier lifecycle to generate the lifecycle plan and acceptance_evidence_plan。
   • then use hcloud_acceptance_closure.py plan/run/evaluate/chain to do evidence collection planning, supported probes, and evidence result determination.
   • When doing real account regression or service promotion, use hcloud_live_validation_plan.py to list the target inputs, read-backs, probes, and promotion gaps for ECS/VPC/EIP/OBS/ELB/RDS.
6. Completion claims must be honest:
   • job_id、accepted, cloud-side ACTIVE, Terraform plan success, MaaS task_id none of these equal business availability.
   • When protocol, health, in-instance, log, metric, or user-path evidence is needed, you must state whether it has been collected, is missing, or is blocked.

Security Boundary Summary

Detailed rules are in references/runtime-safety-boundaries.md. Read that reference before performing creation, changes, network exposure, ECS in-instance operations, COC/SSH fallback, application acceptance, or troubleshooting.

Risk Point	Default Handling
Credentials, AK/SK, API Key, private key	Do not echo or save in conversations, logs, manifests, or site code; support the same-family environment variable aliases listed in the documentation, and do not concatenate AK/SK across families. In command/API output, ***、**** or more consecutive asterisks means "the value exists but has been masked," not that it is missing.
Security group ingress	SSH 22 and development ports must not be opened to 0.0.0.0/0. After the user confirms the public website plan, the exact TCP 80/443 for direct ECS connection may use --allow-public-web planning; this parameter does not replace submit confirmation, and reusing a security group still requires reading back the rules and performing an external protocol probe.
Asynchronous cloud tasks	Follow through to the job's terminal state, then perform resource status, protocol, or business acceptance.
Terraform state	import/state/remote state are high-impact operations; explicit confirmation is required, and automatic apply/destroy is not allowed.
MaaS video and asynchronous tasks	task_id is only an acceptance credential; the terminal state must be queried.
Billing/Cost	Do not infer costs from resource inventories; billing results must be masked and distinguish fact/grain/money basis/scope.
Automatic live probe	Only execute HTTP/TCP/DNS/TLS derived from the plan; metadata/link-local targets are rejected, and intranet/localhost requires explicit confirmation.
Result narrative	Describe only commands, output, and verification that actually occurred; do not fabricate failure-recovery processes or write planned states as already executed.

Preferred Entry Points

Complete script descriptions and command templates are in references/scripts.md. Only the default entry points are kept here to avoid making the model browse long script tables at runtime.

Task	Preferred Entry Point
Environment, authentication, profile, region/project	hcloud_environment_doctor.py、hcloud_context_inspect.py、hcloud_project_resolve.py
Natural language scenario routing	hcloud_scenario_router.py
hcloud version selection, batch/asynchronous and resource dependency evidence, real queries or controlled system commands	hcloud_operation_resolver.py、hcloud_operation_behavior.py、hcloud_dependency_evidence.py、hcloud_safe_exec.py
Multi-service discovery, target queries, readiness/live validation (including CCI workload pre-checks)	hcloud_resource_discovery.py、hcloud_resource_query.py、hcloud_service_readiness.py、hcloud_live_validation_plan.py、hcloud_cci_workload_plan.py
Create/change request pre-checks, risk validation, and read-back assistance	hcloud_request_preflight.py、hcloud_change_plan.py、hcloud_service_change_plan.py、hcloud_guarded_change_flow.py
P0/P1/P2 closed-loop planning and acceptance	hcloud_closure_plan.py、hcloud_acceptance_closure.py
Inventory, idle resources, cost, governance	hcloud_account_inventory.py、hcloud_idle_audit.py、hcloud_billing_readonly.py、hcloud_billing_live_read.py、hcloud_cost_estimate.py
Terraform/IaC	hcloud_terraform_context_inspect.py、hcloud_terraform_router.py、hcloud_terraform_operations_plan.py
MaaS model invocation, images/videos, usage governance	maas_models.py、maas_chat.py、maas_image_generation.py、maas_video_generation.py、maas_usage_request_plan.py
Script boundaries, maintenance layering, complete command templates	references/scripts.md、references/script-audience-manifest.json

Documentation Entry Points

Read as needed for the task; do not load all documentation at once:

• Backend selection, runtime dependencies, basic workflows, and security:references/backend-selection.md、references/runtime-dependencies.md、references/workflow.md、references/runtime-safety-boundaries.md、references/auth-and-context.md
• Cross-service facts, recoverable state, and interaction:references/unified-principles.md、references/task-workspace-guide.md、references/goal-capability-guide.md、references/interaction-guidance.md
• Scenario routing and service documentation:references/scenario-router.json、references/guides/service-guides.md、references/playbooks/playbook-index.md
• CLI installation, authentication, and IAM permissions:references/cli-installation-guide.md、references/auth-and-context.md、references/iam-policies.md
• Command construction and error handling:references/command-construction.md、references/error-playbook.md、references/output-and-query.md、references/hcloud-output-policies.json
• Script index and public contract:references/scripts.md、references/public-script-contract.md、references/script-audience-manifest.json
• Terraform：references/terraform-workflow.md、references/terraform/terraform-assets.md、references/terraform/operations.md
• MaaS：references/maas-model-calls.md、references/playbooks/maas-api-readiness.md、references/playbooks/maas-usage-governance.md
• Validation and acceptance:references/verification-method.md、references/acceptance-criteria.md、references/live-validation-profiles.json
• Coverage and promotion:references/service-coverage.md、references/operation-behavior-profiles.json、references/resource-dependency-profiles.json、references/service-curation-profiles.json、hcloud_closure_maturity_audit.py; when maintaining issue coverage examples, read references/maintenance/question-coverage/question-coverage.md
• Cross-Agent evaluation:references/cross-agent-evaluation.md、references/cross-agent-evaluation-cases.json、hcloud_cross_agent_eval.py; supports local baseline/candidate comparison and sanitized journal summaries; results are advisory evidence only, not a platform gate
• Version and compatibility strategy:references/versioning-policy.md
• Knowledge ownership, progressive loading, and material provenance:references/source-map.md、references/materials-sources.json

The original KooCLI materials are under materials/ and serve only as a source of reference, not directly as the final instruction set. When API field semantics are involved, the official Huawei Cloud documentation and actual hcloud --dryrun/query results shall prevail.

Capability boundaries

• ECS guidance is the most complete, covering pre-creation validation, dry-run, job final state, ACTIVE read-back, SSH, and application acceptance.
• P0 high-frequency services have lifecycle planner and acceptance closure; P1/P2 are mainly governance/scenario planner and cannot be described as a complete execution loop.
• OBS, MaaS, Billing, SDK, and Terraform all have dedicated boundaries; MaaS is API-first, Terraform is triggered by IaC intent, and SDK can become the task backend during programmatic processing or when hcloud is an obstacle.
• Long-tail security, database, governance, identity, and key-type services are mostly metadata-backed evidence gaps; start with discovery, planning, and evidence gaps, and do not execute mutation by default.
• Automatic live probe only supports built-in HTTP/TCP/DNS/TLS; intranet, localhost, or .local targets must carry --allow-private-targets and come from a reviewed evidence plan; other evidence needs to be collected manually or with dedicated tools before evaluate.
• Real-account regression, Terraform state-changing import, and billing resource creation/release still require the user to provide an isolated environment, resource ID, profile/region, and explicit confirmation.