OSS Cross-Region Replication Config Check

Check Alibaba Cloud OSS cross-region replication (CRR) configuration and explain why data is or is not being replicated: "I set up cross-region replication but no files appear in the target bucket", "replication shows only a rule ID and never starts", "does my replication rule sync deletes", "which authorization role does replication need".

Core approach: verify the caller identity, fetch the bucket's storage class and region with the read-only GetBucketInfo control-plane query, then read the bucket's replication rule with the read-only GetBucketReplication query. When no rule exists, report the legitimate "replication not configured" finding; when a rule exists, inspect its authorization role, prefix scope, delete-sync switch, historical-data switch, and transfer-acceleration dependency, and attribute "replication not starting" to a concrete configuration cause. Conclude with evidence-based findings and manual guidance only; this skill never creates, modifies, or deletes any replication rule.

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. PutBucketReplication, DeleteBucketReplication, PutBucket*, DeleteBucket*, PutObject*, or any replication-rule / ACL / policy change. This includes commands "for the user to run on your behalf". If the user asks to create or change a replication rule, only output manual guidance and declare this skill is read-only. Empty / not-found is a valid result — never react to it with a write. When GetBucketReplication returns no rule, the bucket is not found, target_verification.verdict is target_unreachable, or every query returns empty, that is already a complete conclusion: relay it and STOP. Never issue a create / re-create / verify / test / validate / repair call to "confirm" an empty result, and never fall back to hand-written ossutil, SDK, or aliyun commands for the same purpose.
2. MANDATORY entry-point enforcement: All CRR checks MUST be performed by running the scripts under scripts/ (crr_config_check.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. This mandate is UNCONDITIONAL: it also covers a request that names no bucket, no region, or only a consultation question (e.g. online migration vs cross-region replication selection). You MUST still run crr_config_check.py — with no --bucket it exits STATUS: FAIL whose NEXT_ACTION names the missing input and whose buckets_in_account lists up to 30 buckets visible to the current credential, and that output is exactly what to put back to the customer. NEVER answer a replication question from memory alone and NEVER guess a bucket name. A missing-input STATUS: FAIL is NOT a terminal conclusion: relay it and ask the customer for the missing input exactly as NEXT_ACTION directs, then re-run the script with the answer — Rule 1's "relay it and STOP" applies only to a result obtained for a bucket the customer actually named.
3. ABSOLUTE PROHIBITION (consultation questions): Even when the user asks a consultation question — e.g. "online migration vs cross-region replication", "does ACL affect replication", "which data volume needs which approach" — without naming a specific bucket, you MUST still run scripts/crr_config_check.py (without --bucket it exits STATUS: FAIL whose NEXT_ACTION names the missing input and whose buckets_in_account lists visible buckets). NEVER answer a replication or migration question from memory alone. The script output is the only sanctioned evidence base.
4. 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.
5. NO FABRICATION: Every conclusion must be grounded in data actually returned by GetBucketReplication / GetBucketInfo / ListBuckets / GetCallerIdentity. If a query fails or returns empty, record it and state the limitation — never invent replication rules, statuses, or role names.
6. 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.
7. SCOPE BOUNDARY: This skill only answers replication configuration correctness and "why is replication not running" attribution questions. It does NOT handle billing disputes (defer to the billing skill), deleted-object recovery (defer to the deletion-recovery skill), endpoint / internal-network access errors (defer to the endpoint skill), or generic cross-account RAM authorization design (defer to the cross-account-auth skill) — for such requests, state the boundary and give manual guidance only.

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)." ABSOLUTE PROHIBITION — NO URL FABRICATION: Every official URL in the final answer must be copied verbatim from a source this skill itself produces or documents — doc_verification.docs, the links inside region_migration_guidance (emitted when the verdict is no_replication_configured), or the official URLs already listed in this skill's references/ modules. When the customer's question is not covered by any of those, say that it is unverified. When doc_verification.note starts with DEGRADED, you MUST state "Unable to verify against online official docs (offline)" and MUST NOT supply any URL from memory — this is a hard prohibition, not a suggestion.