阿里云 OSS CDN 源站配置诊断

安装指南

1. ClawHub CLI 从源直接安装技能的最快方式。
   npx clawhub@latest install alibabacloud-oss-cdn-origin-config-diagnosis
2. 手动安装 将技能文件夹复制到以下位置之一
   全局模式
   ~/.openclaw/skills/
   工作区
   /skills/
   优先级：工作区 > 本地 > 内置
3. 提示词安装 将此提示词复制到 OpenClaw 即可自动安装。
   请帮我使用 Clawhub 安装 alibabacloud-oss-cdn-origin-config-diagnosis。如果尚未安装 Clawhub，请先安装（npm i -g clawhub）。
   更倾向于下载？
   获取包含原生技能文件的ZIP压缩包。
   下载技能 (.zip)

什么是

此 Openclaw Skills 诊断工具会检查阿里云 CDN 域名和 OSS 源站，以调查回源 403 错误、绕过 CDN 的流量、错误的源站主机或端口，以及已停止或未配置的域名。它使用技能脚本检查 CDN 域名配置、调用方身份和可用的 OSS 存储桶元数据，然后报告发现和建议的后续步骤。
此技能绝不会更改 CDN 或 OSS 设置，也无法确定是否已启用私有存储桶 CDN 授权。其结论仅限于诊断查询实际返回的数据；检查失败时会报告为降级，而不会据此认定配置正常。Openclaw Skills 用户可以获得结构化、可执行的诊断，同时不会泄露凭据或进行云端更改。

应用场景

当 OSS 存储桶是源站时，调查 CDN 回源 403 错误。
检查私有 OSS 存储桶是否可能需要 CDN 回源授权，同时注意此技能无法读取授权状态本身。
将用户报告的 OSS 端点与已配置的 CDN 源站进行比较，以识别绕过 CDN 的流量。
检查已配置的源站主机和端口详情，找出可能不匹配或可疑的值。
诊断离线、已停止、缺失或未配置源站的 CDN 域名。
使用可用的存储桶元数据，判定同账户或跨账户 OSS 源站发现的归属。
在部分云查询失败时生成基于证据的报告，并明确指出错误和后续操作。

工作原理

收集加速域名，以及可选的用户流量实际使用的源站主机。
运行 scripts/sts_token.py，通过阿里云 CLI 默认凭据链推导调用方 UID。UID 是用于追踪的标签，不是配置证据。
将 scripts/origin_config_diagnosis.py 作为必需的诊断入口运行。它会检查 CDN 域名状态、CNAME 和源站来源、已配置的回源 Host，以及账户域名清单。
对 OSS 格式的源站，通过 oss2 SDK 查询存储桶元数据，包括 ACL、所有者和区域。如果提供了实际源站主机，则将其与已配置的源站进行比较，以检查是否直接访问 OSS。
解读返回的发现，并查阅相应的参考模块以获取指导。不要直接调用 CDN 或 OSS API，也不要推断脚本未返回的值。
返回脚本的 STATUS 和 NEXT_ACTION，在有官方文档可用时引用经核实的文档，披露自动填充的输入，并报告查询错误或限制。任何更改都只能作为手动指导。

配置指南

将技能安装或放置在 AI 编程代理支持的技能目录中。文档示例使用 ~/.qoderwork/skills/alibabacloud-oss-cdn-origin-config-diagnosis。
确保 Python 3、阿里云 CLI 和技能的 oss2 SDK 环境均可用。CLI 必须为 3.3.3 或更新版本；如有需要请升级：
aliyun version
aliyun upgrade --yes
通过默认凭据链配置凭据。CDN 和 STS 调用使用阿里云 CLI 配置或环境；OSS 调用使用 SDK 基于环境的默认凭据链。绝不要索取或打印 AK/SK 或 STS 令牌。如果身份检查失败，请指导用户配置凭据，不要要求他们分享机密。
设置技能目录、验证身份并运行诊断。将示例域名和可选源站主机替换为用户提供的值：
SKILL_DIR=~/.qoderwork/skills/alibabacloud-oss-cdn-origin-config-diagnosis
cd "$SKILL_DIR"
python3 scripts/sts_token.py
python3 scripts/origin_config_diagnosis.py --domain cdn.example.com
若要检查用户流量是否直接访问 OSS，请提供报告中的主机：
python3 scripts/origin_config_diagnosis.py \ --domain cdn.example.com \ --user-origin-host mybucket.oss-cn-shanghai.aliyuncs.com 如有配置或用法问题，使用 --question "" 调用入口脚本。仅引用 doc_verification.docs 返回的文档 URL；如果其 note 以 DEGRADED 开头，请说明：“无法根据在线官方文档进行验证（离线）。”

数据架构

技能文件及其职责
路径 用途
scripts/origin_config_diagnosis.py CDN 域名、源站配置、OSS 归属和可选绕过检查的必需入口。
scripts/sts_token.py 检查调用方身份并推导 UID 追踪标签。
scripts/_oss_client.py 共享客户端行为，包括 User-Agent 元数据、会话关联和弹性请求处理。
scripts/_doc_lookup.py 使用 --question 路径时，根据 OSS 官方文档验证相关指导。
references/manifest.json API 调用 User-Agent 元数据中使用的技能版本的唯一来源。
references/origin-auth-playbook.md 关于私有存储桶授权及同账户或跨账户情况的指导。
references/bypass-detection.md 关于识别直接访问 OSS 流量的指导。
references/origin-config-checklist.md 关于源站主机、端口、域名状态和错误路由的指导。
references/ram-policies.md 此技能所需的最小只读 RAM 权限。
报告数据
诊断会输出结构化状态、发现、建议、后续操作指导和错误数组。错误记录包含类别、代码、消息和提示。报告还提供约定行 STATUS: OK | DEGRADED 和 NEXT_ACTION: 。降级运行仍可能产生有用的发现；必须传达已记录的错误和限制，而不能用假设取代它们。
API 调用的 User-Agent 元数据包含技能名称、从 manifest 获取的技能版本，以及每次运行一个 32 位十六进制会话 ID。该次运行中的所有调用会复用会话 ID，以支持关联。此技能不会写入或修改 CDN 或 OSS 配置。

高级特性

只读强制措施：
仅使用身份、CDN describe 和 OSS 元数据读取操作。绝不更改源站、启动或停止域名、更改存储桶策略或 ACL，也不提交刷新/预热请求。
脚本强制诊断：
要求使用提供的脚本作为入口，以保留其超时、错误降级和可观测性行为，而不是发出临时 CLI、SDK 或 curl 请求。
基于证据的归属判定：
将返回的数据映射为诸如
PRIVATE_ORIGIN_AUTH_REQUIRED
、
PRIVATE_ORIGIN_CROSS_ACCOUNT
、
DIRECT_OSS_ACCESS
、
ORIGIN_HOST_MISMATCH
、
ORIGIN_PORT_SUSPECT
、
DOMAIN_NOT_ONLINE
DOMAIN_NOT_FOUND
等发现。
如实诊断私有存储桶：
存储桶元数据可以显示 ACL 和所有者，但无法显示是否启用了 CDN 私有存储桶授权；报告会建议验证，但不会声称观察到了该设置。
降级执行和重试：
将 API 问题记录为
[WARN]
，在可能时继续执行，并生成包含
STATUS: DEGRADED
NEXT_ACTION
的报告。共享客户端会对符合条件的瞬时故障重试两次，间隔分别为一秒和三秒。
官方文档验证：
对于配置或用法问题， --question 路径会检查内嵌指导，并根据 OSS 官方文档进行验证；只能引用返回的文档 URL。
灵活的 CLI 输出：
支持必需的 --domain 以及可选的 --user-origin-host 、 --uid 、 --json --quiet 选项。UID 可自动推导，且必须披露任何自动填充的参数。
明确的范围界限：
不诊断缓存刷新/预热效果、流量异常或计费、OSS 端点选择、HTTPS 证书或 ICP 备案；应将此类请求转交相关技能或提供手动指导。

name: alibabacloud-oss-cdn-origin-config-diagnosis description: | Read-only diagnostics for CDN back-to-origin to OSS. Use when CDN
fetching from an OSS origin fails or looks wrong: back-to-origin 403
on a private bucket, traffic bypassing the CDN straight to OSS, wrong
origin host or port, or a CDN domain that is offline or never
configured. Checks configuration and attributes the cause; never
changes any CDN or OSS setting.
Triggers: "CDN back-to-origin 403", "private bucket CDN origin",
"traffic bypasses CDN", "origin host misconfigured", "CDN domain
offline", "origin port check", "OSS origin authorization".
Do NOT use for refresh/preload tasks (use
alibabacloud-cdn-refresh-preload), CDN traffic anomaly analysis (use
alibabacloud-cdn-traffic-anomaly), OSS endpoint selection or
internal-endpoint errors (use
alibabacloud-oss-endpoint-internal-diagnosis), or OSS billing (use
alibabacloud-oss-billing-diagnosis).

OSS CDN Origin Configuration Diagnosis

Diagnose Alibaba Cloud CDN back-to-origin problems where the origin is an OSS bucket: "CDN back-to-origin returns 403 on my private bucket", "my users reach the OSS bucket host directly instead of the CDN", "origin host header looks wrong", "the CDN domain is offline / not configured".

Core approach: verify the caller identity, query the CDN domain record and its back-to-origin configuration (read-only), cross-check the OSS origin bucket metadata (ACL, owner, region) through oss2, then attribute the symptom to one of the branches: private-bucket origin authorization missing, traffic bypassing the CDN, origin host/port misconfigured, or domain stopped / not configured. This skill only checks and advises; it never executes any CDN or OSS change.

Absolute Rules

ABSOLUTE PROHIBITION (read-only enforcement): Under NO circumstances may you generate, write, or execute any command/script calling a mutating CDN or OSS API — e.g. origin configuration changes, domain start/stop, PutBucketPolicy, ACL changes, or any refresh/preload submission. This includes commands "for the user to run manually". If the user asks to change the origin or enable authorization, only output manual guidance and declare this skill is read-only.
MANDATORY entry-point enforcement: All diagnostics MUST be performed by running the scripts under scripts/ (origin_config_diagnosis.py as the entry, sts_token.py for identity). The Agent is forbidden from assembling its own aliyun CLI / SDK / curl commands against the CDN or OSS control plane or bypassing the scripts — the scripts embed timeout, error degradation, and observability guarantees that ad-hoc commands lack. Read the script output, interpret it, and compose the report; do not re-implement the queries.
ABSOLUTE PROHIBITION (credential handling): Never read, print, or pass AK/SK/STS tokens explicitly. CDN/STS queries rely on the aliyun CLI default credential chain; OSS queries rely on the environment variables of the default credential chain. Never accept AK/SK from the user or from another script.
NO FABRICATION: Every conclusion must be grounded in data actually returned by the CDN domain queries and OSS GetBucketInfo. If a query fails or returns empty, record it and state the limitation — never invent origin configurations, ACL values, or authorization states. Notably, whether a private-bucket origin authorization is already enabled CANNOT be read by this skill; only advise verifying it.
EXECUTION RULE FOR ERRORS: On any API error, log [WARN] : to stderr, continue with the remaining steps, and still produce the final report with STATUS: DEGRADED and a NEXT_ACTION line — never silently skip or abort without a report. A domain that cannot be found may simply have been cleaned up; report it as the "not configured / deleted" branch, not as an internal failure.
SCOPE BOUNDARY: This skill only answers back-to-origin configuration and attribution questions. It does NOT handle CDN cache/refresh/preload effectiveness, CDN traffic anomaly billing analysis, OSS endpoint selection errors, HTTPS certificate problems, or ICP filing — for such requests, state the boundary and route to the owning skill or manual guidance.

Official Doc Verification

MANDATORY: For configuration or usage questions, the entry script MUST be invoked with --question "". The script first matches embedded knowledge, then verifies against official OSS docs (doc_verification, llms-index). The final answer MUST cite the URLs from doc_verification.docs. If doc_verification.note starts with DEGRADED, state explicitly: "Unable to verify against online official docs (offline)." Never fabricate doc URLs; only URLs returned by the script may be cited.

Trigger Conditions

Trigger this skill when the user reports any of: CDN back-to-origin 403 against an OSS origin, a private bucket used as CDN origin, traffic bypassing the CDN and hitting OSS directly, origin host misconfigured, origin port problems, or a CDN domain that is offline / stopped / not configured. Chinese equivalents (e.g. questions about back-to-origin 403, private-bucket origin authorization, traffic not going through CDN, or origin Host configuration) map to the same trigger set.

Execution Principle

All diagnostics MUST be performed by running the scripts under scripts/. Read the structured output (status / findings / recommendations / next_action), interpret it, and compose the user-facing answer; do not re-implement the queries or call CDN/OSS APIs directly.

Observability

All API calls issued by the scripts include:

User-Agent template: AlibabaCloud-Agent-Skills/{skill-name}/{session-id} skill-version/{skill-version}, where {skill-name} is alibabacloud-oss-cdn-origin-config-diagnosis
skill-version: read at runtime from references/manifest.json (version), the single place where this skill's version is declared. It is never hardcoded, guessed or reused: the entry script resolves and validates it before the first cloud call and stops with STATUS: FAIL (exit 1) when the manifest is missing or its version is invalid.
session-id: 32-character hex string (uuid.uuid4().hex) generated once per script run and attached to every aliyun CLI call (--user-agent) and every OSS SDK request (User-Agent header) of that run, so all calls of one diagnosis can be correlated.

The shared client layer (scripts/_oss_client.py) implements this automatically: the session-id is generated lazily on the first call of each run and cached for the rest of the run, and the skill-version is resolved lazily from references/manifest.json on the first User-Agent build.

Credentials

Credentials are resolved exclusively by the default credential chain:

CDN/STS queries (aliyun CLI plugin mode): the CLI default credential chain (environment or ~/.aliyun/config.json profile).
OSS origin-bucket metadata (Python oss2 SDK): the environment variables ALIBABA_CLOUD_ACCESS_KEY_ID, ALIBABA_CLOUD_ACCESS_KEY_SECRET, and optionally ALIBABA_CLOUD_SECURITY_TOKEN (STS sessions).

Do not read, print, or pass AK/SK/STS tokens explicitly. If the identity check fails, guide the user to configure the credential chain — never ask for AK/SK.

aliyun CLI version requirement

The scripts shell out to the aliyun CLI (at minimum the aliyun sts get-caller-identity identity pre-check), which MUST be version 3.3.3 or newer: older builds resolve the default credential chain differently and can drop the STS session token. Verify the installed version and upgrade it before the first run:

aliyun version # must print 3.3.3 or newer (measured with 3.4.5)
aliyun upgrade --yes # upgrade the installed CLI in place to the latest version

If the CLI is not installed at all, install the Alibaba Cloud CLI package for the host OS from the official release channel and then run aliyun configure (the profile stays in ~/.aliyun/config.json; this skill never asks for AK/SK). When the CLI is missing, too old to upgrade, or unauthenticated, the identity pre-check degrades instead of aborting: scripts/_oss_client.py logs [WARN] identity pre-check failed: ... on stderr, records the empty UID, and the diagnosis still runs to a conclusion, because the identity label is traceability only and never evidence.

SKILL_DIR=~/.qoderwork/skills/alibabacloud-oss-cdn-origin-config-diagnosis
cd $SKILL_DIR

# Verify caller identity (informational only; credentials always come from the default chain)
python3 scripts/sts_token.py

User Confirmation

Because every action of this skill is strictly read-only, no user confirmation is required before running the diagnostic scripts. Confirmation discipline applies at the scope boundary instead: any request to actually change an origin, start/stop a domain, or enable an authorization is refused as out of scope, with manual guidance only.

Input Parameters

Accelerated domain (--domain): required; the CDN-accelerated domain to diagnose.
User-reported origin host (--user-origin-host): optional; the host the user's traffic is addressed to (e.g. .oss-.aliyuncs.com). When provided, the bypass-detection branch compares it with the CDN-configured origin.
UID (--uid): can always be omitted — the caller UID is derived via aliyun sts get-caller-identity and used as a traceability label plus the same/cross-account origin attribution. Auto-fill first, ask second: never ask the user for UID when it can be derived.

Auto-fill declaration requirement: Whenever any parameter is auto-filled (UID derived, origin host inferred), the Agent MUST explicitly declare this in the response or report metadata, e.g. "UID auto-derived via sts GetCallerIdentity: 1552974654746705".

Module Index

Reference modules, strictly 1:1 with the references/ directory:

Module File Responsibility

M1: Origin authorization playbook references/origin-auth-playbook.md Private-bucket back-to-origin authorization: three methods (bucket policy, private-bucket authorization via STS, origin authentication), same-account vs cross-account
M2: Bypass detection references/bypass-detection.md Detect traffic that bypasses the CDN and reaches OSS directly
M3: Origin config checklist references/origin-config-checklist.md Origin host / port / domain-state checklist and error routing
M4: RAM policies references/ram-policies.md Minimal read-only RAM policy required by this skill

Orchestration

Run scripts/sts_token.py to verify identity and derive the UID (skip only when already verified in this session).
Run scripts/origin_config_diagnosis.py --domain [--user-origin-host ] — one entry call covers all branches (domain state, origin host/port, private-bucket attribution, bypass).
Interpret findings / recommendations; consult the matching reference module for the advice text.
Compose the final report per the Final Answer Contract below.

Execution Flow

Step 1: Confirm Identity and Collect Inputs
cd $SKILL_DIR && python3 scripts/sts_token.py

Collect the accelerated domain and, if the user has it, the origin host their traffic actually uses. UID is auto-derived; declare any auto-fill.

Step 2: Run the Origin Diagnosis
cd $SKILL_DIR && python3 scripts/origin_config_diagnosis.py
--domain [--user-origin-host ] [--uid ]

The script:

Derives the caller UID via aliyun sts get-caller-identity (degraded with [WARN] on failure).
Queries aliyun cdn describe-cdn-domain-detail --domain-name — domain state (online/offline), CNAME, origin sources. InvalidDomain.NotFound routes to the "not configured / deleted" branch.
Queries aliyun cdn describe-user-domains — account domain inventory for candidate suggestions when the domain is not found.
Queries aliyun cdn describe-cdn-domain-configs --domain-name --function-names set_req_host_header — the configured back-to-origin Host.
For each OSS-shaped origin, calls OSS GetBucketInfo through oss2 (ACL, owner, region) and attributes: private-bucket authorization required, same-account vs cross-account, region consistency, origin host/port sanity.

If --user-origin-host is given, compares it with the configured origins (bypass detection).

Emits the structured report plus the contract lines STATUS: OK | DEGRADED and NEXT_ACTION: .
Step 3: Interpret the Findings and Advise
PRIVATE_ORIGIN_AUTH_REQUIRED / PRIVATE_ORIGIN_CROSS_ACCOUNT — a 403 on back-to-origin is expected until the authorization exists; advise per references/origin-auth-playbook.md. State clearly that this skill cannot read the authorization state itself.
DIRECT_OSS_ACCESS — the reported host is an OSS endpoint, so traffic bypasses the CDN; advise per references/bypass-detection.md.
ORIGIN_HOST_MISMATCH / ORIGIN_HOST_DEFAULT / ORIGIN_PORT_SUSPECT — advise per references/origin-config-checklist.md.
ORIGIN_INTERNAL_ENDPOINT — the origin content is an OSS internal endpoint (oss--internal.aliyuncs.com), reachable only from same-region Alibaba Cloud intranet clients; public CDN nodes cannot back-to-origin through it — advise switching to the public endpoint (checklist §2).
ORIGIN_ACCELERATE_ENDPOINT — the origin uses the transfer-acceleration endpoint (oss-accelerate[-overseas].aliyuncs.com); this is the official CDN + transfer-acceleration dual-acceleration architecture, NOT a misconfiguration; the region-consistency check does not apply (checklist §2).
DOMAIN_NOT_ONLINE / DOMAIN_NOT_FOUND / NO_ORIGIN_CONFIGURED — domain-state branch; advise re-enabling or verifying the domain/account.
DEGRADED report — relay the recorded errors and the NEXT_ACTION guidance honestly; never invent configuration values.

Important Notes

Private-bucket authorization is not observable here: GetBucketInfo reveals the ACL and owner, not whether CDN private-bucket authorization is enabled. Never claim the authorization "is missing" as a fact — phrase it as "403 occurs unless the authorization is in place; verify it".
Offline domains: a stopped/offline domain produces any back-to-origin symptom; check the domain state before deeper attribution. Test assets may be cleaned up over time, so treat "not found" as a legitimate branch.
Cross-account origins: when the origin bucket belongs to another account, GetBucketInfo is denied (403) by design; degrade with [WARN] and advise the cross-account authorization path from the bucket owner side.
Read-only operations: only DescribeUserDomains / DescribeCdnDomainDetail / DescribeCdnDomainConfigs, OSS GetBucketInfo, and sts GetCallerIdentity; never modifies anything.

Examples

Example 1 — back-to-origin 403 on a private bucket origin

User: "My CDN domain test234.pier39.cn pulls from my OSS bucket and gets 403. UID 1552974654746705."

python3 scripts/origin_config_diagnosis.py --domain test234.pier39.cn

Relay the findings (origin bucket private, same account), advise verifying the private-bucket back-to-origin authorization per the playbook, and declare the auto-derived UID.

Example 2 — traffic bypasses the CDN

User: "Our images are still served from mybucket.oss-cn-shanghai.aliyuncs.com, not through the CDN."

python3 scripts/origin_config_diagnosis.py --domain cdn.example.com \

--user-origin-host mybucket.oss-cn-shanghai.aliyuncs.com

Report the DIRECT_OSS_ACCESS finding and the bypass-detection guidance (point clients at the accelerated domain, verify the CNAME record).

Example 3 — CDN domain offline or not configured

python3 scripts/origin_config_diagnosis.py --domain stopped.example.com

Report DOMAIN_NOT_ONLINE / DOMAIN_NOT_FOUND with the re-enable / verify-account guidance; on DEGRADED, relay the recorded errors honestly.

Example N — ESA or CDN fronting a private OSS bucket returns 403 on origin fetch

User: "Traffic through my acceleration domain fails to fetch from OSS; direct access to the bucket endpoint works."

python3 scripts/origin_config_diagnosis.py --domain "cdn.example.com" --json

Report whether back-to-origin Host equals the bucket's public endpoint and whether private-bucket origin auth is required, then say which single switch to fix -- do not let the customer add redundant authorization or SNI options.

Available Scripts

Script Purpose

scripts/sts_token.py Verify caller identity via aliyun sts get-caller-identity; derive the UID traceability label (--json optional)
scripts/origin_config_diagnosis.py Entry: CDN domain state + origin host/port check + private-bucket attribution + bypass detection, with degradation

CLI options for origin_config_diagnosis.py: --domain (required), --user-origin-host (optional, bypass branch), --uid (optional, informational), --json / --quiet.

Error Handling

Error Cause Resolution

No credentials found Default credential chain not configured Configure the aliyun CLI / environment credential chain; never ask the user for AK/SK
InvalidDomain.NotFound Domain not configured under this account, deleted, or wrong account Report the not-configured branch; verify spelling and the owning UID
Forbidden / RAM denial on CDN queries Caller lacks the CDN read actions Record [WARN], point to references/ram-policies.md; report STATUS: DEGRADED
OSS 403 on GetBucketInfo Origin bucket owned by another account (expected) or missing oss read permission Degrade gracefully; advise the cross-account authorization path
Network timeout Transient failure Report STATUS: DEGRADED honestly; retry later, never conclude "no problem" from a failed call
InternalError / 5xx / SlowDown Transient service-side failure or request throttling Retried automatically inside scripts/_oss_client.py (2 extra attempts, 1s then 3s, each traced as [WARN] on stderr); if the call still fails the report carries STATUS: DEGRADED. Do not re-run the script in a loop and never conclude "no problem" from a failed call

| Doc lookup module | scripts/_doc_lookup.py | Runtime official-doc verification against the OSS help center (llms-index); used by the --question path | All errors follow the structured category/code/message/hint shape recorded in the report's errors array; every degraded step logs [WARN] on stderr, and the report is always emitted with whatever data succeeded.

Exit-code contract (unified with the sibling OSS skills): exit 0 means the diagnosis produced a conclusion — both STATUS: OK and STATUS: DEGRADED exit 0 ("a conclusion was produced successfully"); exit 1 is reserved for FAIL cases where no diagnosis can run at all (invalid --domain input, aliyun CLI missing on PATH). Upstream automation MUST NOT treat a DEGRADED run as a failure via exit codes — read the STATUS: line / status field of the report instead.

Final Answer Contract

The final answer to the user MUST:

Relay the script's STATUS: (OK / DEGRADED) and NEXT_ACTION: line verbatim in meaning.
State the root cause with the actual evidence fields (domain state, origin content, origin Host, bucket ACL/owner) — no fabricated values.
Declare every auto-filled parameter (UID derivation, inferred host).
On DEGRADED, list the recorded errors and limitations explicitly instead of inventing conclusions.
Give every configuration change as manual guidance only (this skill never applies changes), and for private buckets clearly state that the authorization state itself is not readable by this skill.
When the report carries doc_verification, cite the doc titles and URLs from doc_verification.docs in the final answer; when doc_verification.note starts with DEGRADED, state explicitly: "Unable to verify against online official docs (offline)."
阿里云 OSS 直连链接诊断
Alibaba Cloud OSS Event Notification & Upload Callback Diagnosis