OSS Accidental Deletion Recovery & Residue Diagnosis

Diagnose Alibaba Cloud OSS deletion problems: "I accidentally deleted uploads/report.pdf, how can I recover it", "deleting my bucket fails with BucketNotEmpty", "I deleted files yesterday but the storage usage and cost did not drop", "what is a delete marker and can I restore the object".

Core approach: verify the caller identity, fetch the bucket metadata with the read-only GetBucketInfo control-plane query, check the bucket versioning status with GetBucketVersioning, and run a pure-function decision tree on the result: versioning enabled means the deletion only inserted a delete marker and the historical versions are recoverable (manual restore guidance); versioning suspended means a delete without version id creates a null delete marker (historical versions remain recoverable), while a delete with an explicit version id permanently removes that version; versioning never configured means the data is not recoverable from OSS itself and expectations must be managed honestly. For residue questions, ListMultipartUploads counts leftover fragments and the versioning state explains historical-version storage. 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. DeleteObject, DeleteObjects, DeleteBucket, any version restore (ossutil revert), delete-marker removal, multipart abort (AbortMultipartUpload), PutBucketVersioning, or any ACL/policy/lifecycle change. This includes commands "for the user to run manually" issued from the scripts; recovery and cleanup are described as manual guidance in words only, and the user executes them. If the user asks to restore a version or clean fragments, only output the guidance and declare this skill is read-only. Empty / not-found is a valid result — never react to it with a write. If the bucket or object does not exist (NoSuchBucket / 404), a query returns empty, or versioning was never configured, that already is a complete conclusion: report it honestly and STOP. Never try to create / re-create / verify / test / validate / restore / repair the bucket or object, and never fall back to hand-written ossutil / SDK / curl calls — stay inside the read-only entry-script flow.
2. MANDATORY entry-point enforcement: All OSS diagnostics MUST be performed by running the scripts under scripts/ (oss_deletion_recovery_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 / ListMultipartUploads / ListBuckets / GetCallerIdentity. If a query fails or returns empty, record it and state the limitation — never invent versioning states, version ids, or residue counts. Never promise recovery without an enabled (or pre-suspension) version to restore.
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 answers deletion recoverability (including a bucket released after an overdue-payment suspension, whose data official policy declares unrecoverable — state that verdict honestly with the doc citation), deletion residue attribution (objects / multipart fragments / historical versions), and prevention advice. It does NOT pursue an out-of-band or ticket-based restoration of data official policy already made unrecoverable, does NOT attribute bill line items (defer to the billing skill), and does NOT walk the detailed multipart fragment cleanup procedure (defer to the multipart-upload diagnosis skill).

Official Doc Verification