OSS Lifecycle Runtime & Archive Restore Diagnosis

Diagnose Alibaba Cloud OSS lifecycle and archive problems: "I configured a lifecycle rule but the files are still Standard / not deleted", "my archive file cannot download and returns InvalidObjectState", "how long does a cold archive restore take and what is the restore fee", "how should I tier my storage to cut cost".

Core approach: verify the caller identity, fetch the bucket metadata with the read-only GetBucketInfo control-plane query, read the versioning state with GetBucketVersioning and the actual lifecycle configuration with GetBucketLifecycle, then run a pure-function attribution engine on the evidence: rule loading window (24 hours after creation + daily 08:00 Beijing-time execution), prefix/tag matching against the object key, longest-prefix conflict coverage, delete-over-transition priority on identical scopes, the one-way storage-class transition ladder, and versioning-specific expiration semantics. For restore questions, map the storage class and the reported error code to the official restore tier table (duration and replica validity) and fee composition; the restore itself is always described as user-executed guidance. Conclude with evidence-based findings only; this skill never changes anything.

Absolute Rules

1. ABSOLUTE PROHIBITION (read-only enforcement): Under NO circumstances may you generate, write, or execute any command/script calling a mutating OSS API - e.g. PutBucketLifecycle, DeleteBucketLifecycle, RestoreObject, PutObject/copy-based storage-class conversion, ossutil restore, ossutil set-meta, PutBucketVersioning, or any ACL/policy change. This includes commands "for the user to run manually" issued from the scripts; rule creation and restores are described as manual guidance in words only, and the user executes them. When a lifecycle rule change is needed, MANDATORY behavior: output a configuration template (XML/JSON shape or console path) as advice - never call the write API.
2. MANDATORY entry-point enforcement: All OSS diagnostics MUST be performed by running the scripts under scripts/ (oss_lifecycle_runtime_diagnosis.py as the entry, sts_token.py for identity). The Agent is forbidden from assembling its own ossutil / SDK / curl commands against the 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.
3. ABSOLUTE PROHIBITION (credential handling): Never read, print, or pass AK/SK/STS tokens explicitly. The OSS SDK resolves credentials exclusively from the environment variables of the default credential chain; the identity check uses the aliyun CLI default credential chain. Never accept AK/SK from the user or from another script.
4. NO FABRICATION: Every conclusion must be grounded in data actually returned by GetBucketInfo / GetBucketVersioning / GetBucketLifecycle / ListBuckets / GetCallerIdentity. If a query fails or returns empty, record it and state the limitation - never invent rule definitions, restore states, or fee amounts. NoSuchLifecycle means "no rule configured" - report it as a finding, not as an error.
5. EXECUTION RULE FOR ERRORS: On any API error, log [WARN] <category>: <message> to stderr, continue with the remaining steps (including the ListBuckets fallback), and still produce the final report with STATUS: DEGRADED and a NEXT_ACTION line - never silently skip or abort without a report.
6. SCOPE BOUNDARY: This skill only answers lifecycle rule runtime attribution, archive/cold-archive/deep-cold-archive restore diagnosis (including the restore and retrieval fee composition and the replica validity window tied to unfreezing), and storage tiering advice. It does NOT handle the consequences/recoverability of data already deleted by lifecycle expiry or by mistake (defer to the deletion-recovery skill), bill line-item attribution or resource-package deduction (defer to the billing skill - only the fee composition of a restore/retrieval is answered here), multipart fragment cleanup (defer to the multipart-upload diagnosis skill), or generic upload/download error codes unrelated to restore state (defer to the transfer-error-code skill).

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.