recovery-testing

Recovery Testing (Chinese Version)

When to Use

You need to design test analysis or validation preparation around recovery points, recovery time, recovery steps, verification evidence, and manual takeover.
You need to deliver a reviewable initial version when materials are incomplete, and make assumptions, gaps, and human decisions explicit.
You need to distinguish static design evidence, planned validation, and execution that has already occurred.

Default output is Markdown, organized by risk, evidence, and priority.
When the user requests a table, CSV, JSON, or ticket format, retain the same finding fields and evidence status.
Before output enters an automated process, first confirm the field schema, enumeration values, and required fields.

First read prompts/recovery-testing.md, and execute according to its input audit, coverage checklist, and output order.
Extract scope, environment, version, dependencies, constraints, success criteria, and available evidence.
Establish scenarios and judgment criteria for recovery points, recovery time, recovery steps, verification evidence, and manual takeover, prioritizing high-impact or hard-to-detect items.
Separate facts, evidence-supported inferences, candidate recommendations, and Human decisions.
When information is insufficient, deliver a constrained initial version and list the minimum evidence-supplementing actions; do not write recommendations as execution results.

Each execution must read prompts/recovery-testing.md; it is the complete execution specification of this Skill.
When evaluation is needed, read evals/eval.yaml and the matching evals/cases/.
Only read references/, examples/, scripts/, or output-formats.md when the directory actually exists and the task requires it.

Separate service restart/readiness, data recovery points, and business consistency, and extract RTO/RPO definitions, failure start points, business recovery endpoints, and acceptable loss.
Deliver service/business/data recovery timelines, target calculations, and variance/compensation tables; partial recovery must not be summarized as recovery completion.
When forming domain candidates, you must read and follow prompts/recovery-testing.md for the domain operation and judgment process, retaining legitimate controls, evidence gaps, and verification actions item by item.

Only analyze recovery points, recovery time, recovery steps, verification evidence, and manual takeover; do not inject faults, do not access real dependencies, and do not call production systems.
Do not fabricate thresholds, availability, recovery time, vulnerability status, or tests that have already been executed.
When evidence is insufficient, use pending confirmation, blocked, or unassessed, and provide the verification method.
Any risk acceptance, release approval, and manual takeover must be left to Human.

The six categories of input audit have been completed and evidence timeliness has been marked.
Recovery objectives, failure modes, expected focus points, and verification methods have been covered.
Facts, inferences, recommendations, gaps, and Human decisions have been distinguished.
Static design or dry-run has not been written as real execution, passing, or release conclusions.

Treating adjacent performance, incident, or API analysis as a complete substitute for recovery testing.
Listing only steps, without writing trigger conditions, expected results, responsible roles, and closure conditions.
When information is insufficient, refuse directly, or use template assumptions to fill in the key facts.

Start with the paths most likely to cause business loss or recovery failure.
Use minimal, isolated, rollback-capable validation recommendations, and record stop conditions.
Enable another engineer to review each conclusion based on evidence and boundaries.