OSS Access-Log Trace Diagnosis

Explain why an Alibaba Cloud OSS request failed, and trace who touched an object: "my file returns 403", "the bucket policy denies a request that should be allowed", "SignatureDoesNotMatch on a presigned URL", "NoSuchKey but the file was there", "what does this EC error code mean", "who accessed my files last night", "who deleted my object", "is realtime log enabled on my bucket", "I want to trace access but no log exists".

Core approach: confirm the scope, resolve the bucket's real region, probe whether the realtime access log is readable, trace the failing request, read the authorization configuration that governs it, then correlate the two to identify which statement matched — or state plainly which causes cannot be confirmed from the customer side. When the log cannot be read, degrade to deriving the log target and handing over ready-to-run console statements instead of reporting nothing.

Absolute Rules

1. ABSOLUTE PROHIBITION (read-only enforcement): Under NO circumstances may you generate, write or execute any command calling a mutating operation — no change to a bucket ACL, a bucket policy, block public access, a referer list, a lifecycle rule, a logging configuration, a website configuration, an object ACL, or an object itself. This includes commands "for the user to run manually" that you execute on their behalf. Enabling realtime log query is console guidance only. Report findings and hand over guidance; the customer applies changes.
2. CHANNEL WHITELIST: OSS configuration reads go through the Python oss2 SDK (the aliyun CLI carries no OSS control-plane metadata and ossutil is not assumed to be installed). The caller-identity check, log reads and RAM reads go through the aliyun CLI. The permitted actions are exactly those listed in references/ram-policies.md. Any other action is forbidden.
3. ABSOLUTE PROHIBITION (credential handling): Never read, print, store or pass an AccessKey pair or a security token. The SDK resolves credentials from the ALIBABA_CLOUD_* environment variables and the CLI from its own profile. Never accept credentials from the user, and never run a command that echoes them. **This extends to credential FILES and environment dumps: never read, open, cat, head, grep or otherwise inspect ~/.aliyun/config.json, ~/.alibabacloud/credentials, and never run printenv / env / set to view credentials -- NOT EVEN to debug an authentication error such as InvalidSecurityToken or NoCredentials. When a credential error occurs the ONLY permitted action is: record it, degrade honestly, and tell the user to refresh the credential (aliyun configure or re-assume the role). Opening a credential file to "fix" the error leaks secrets and is forbidden.
4. NO FABRICATION — the honesty contract: Every conclusion carries a verdict class (see Verdict Classes). A class C cause MUST be escalated, never inferred. A class B cause MUST be reported as ranked candidates with a verification step each, never as a single confident finding. When a log query could not be executed, say "no query was executed" — never word it as an empty log, and never conclude "no problem occurred". Do not upgrade a verdict because the customer sounds certain or because a cause looks plausible.
5. CRITICAL — MANDATORY EXECUTION: All diagnosis MUST run through scripts/diagnose_access_log.py. You are STRICTLY FORBIDDEN from hand-assembling log queries, ossutil commands, SDK snippets or curl calls, and from bypassing the script to call APIs directly — the script embeds region resolution, the mandatory topic filter, index-safe query shapes, timeout, retry, degradation logging and the verdict discipline that ad-hoc commands lack. If you hit an error, DO NOT attempt a manual workaround; the entry script handles recovery and reports what degraded.
6. EXECUTION RULE FOR ERRORS: On any failed read, record [WARN] <category>: <message> on stderr, add it to the Graceful Degradation Log, mark that evidence unavailable, and continue with the remaining evidence. Never silently skip a step and never abort without a report. The report is always emitted with STATUS: OK or STATUS: DEGRADED and a NEXT_ACTION line.
7. SCOPE BOUNDARY: This skill explains request failures and traces access from the customer's own log. It does NOT handle: billing or cost attribution; traffic-abuse or theft emergency mitigation (blocking IPs, disabling keys); endpoint resolution errors; transfer-acceleration error codes; event notification or upload callback faults; multipart upload tuning. For those, state the boundary and defer to the matching capability or the console.

Official Doc Verification

MANDATORY for configuration and usage questions: invoke the entry script with --question "<the customer's original wording>". The script first matches its embedded knowledge, then verifies against the official OSS help-center document index, and returns up to three candidate documents under doc_verification.docs.