Skip to content

backup-checkpoint-template.md

Latest commit

 

History

History
141 lines (89 loc) · 3.59 KB

backup-checkpoint-template.md

File metadata and controls

141 lines (89 loc) · 3.59 KB
Raw

Backup Checkpoint Template

Purpose

Provide a simple, repeatable way to create a recoverable checkpoint before risky work begins.

This template is for moments when the user should not have to rely on memory, trust, or luck to get back to a safe state.

Core Principle

Before meaningful risk, create a clear return point.

A checkpoint does not have to be complicated.

It only has to make recovery realistic.

When To Create A Checkpoint

Create a checkpoint before work that:

  • edits important files
  • rewrites content in bulk
  • deletes or replaces files
  • changes project structure
  • runs uncertain scripts or generated transformations
  • installs or updates dependencies with possible side effects
  • touches user-created documents or valuable outputs

If recovery would be painful, checkpoint first.

Minimum Standard

A usable checkpoint should answer:

  • what is being protected
  • where the backup or checkpoint lives
  • when it was created
  • what action it protects against
  • how to restore from it

If those answers are fuzzy, the checkpoint is not good enough.

Acceptable Checkpoint Types

The method can vary by task.

Examples:

  • duplicate the file with a clear backup name
  • copy the working folder to a temp or backup location
  • create a branch before broad project changes
  • save a snapshot of the current state before automation runs
  • export a version of the document before rewrite

The best checkpoint is the lightest one that still makes rollback realistic.

Checkpoint Template

Use a note like this before risky execution:

Checkpoint Summary

  • protected scope:
  • checkpoint type:
  • location:
  • created before:
  • restore method:
  • notes:

Filled Example

Checkpoint Summary

  • protected scope: docs/ folder and meeting summary draft
  • checkpoint type: duplicated folder copy
  • location: tmp/docs-backup-2026-03-30/
  • created before: running a script that normalizes headings across all markdown docs
  • restore method: replace edited docs/ folder with backup copy if the rewrite is wrong
  • notes: backup created because the script may touch many files at once

Naming Guidance

Use names that are easy to recognize later.

Good patterns:

  • filename.backup-YYYY-MM-DD.ext
  • project-copy-before-rewrite-YYYY-MM-DD/
  • checkpoint-before-bulk-edit-YYYY-MM-DD

Avoid vague names like:

  • temp
  • old
  • backup2

Communication Rule

Tell the user what checkpoint is being created and why.

Good pattern:

  • 🛟 This rewrite could affect many files, so I am creating a checkpoint first so we can return to the current state if the output is not acceptable.

Avoid:

  • Creating backup...

Restore Rule

Do not create a checkpoint unless the restore path is easy to explain.

If restoration would be confusing, choose a clearer checkpoint method.

The checkpoint should lower stress, not create another mystery.

Quick Heuristic

Use this rule:

  • small and easily reversible change: checkpoint may be optional
  • medium-risk change with limited scope: create a lightweight file or folder backup
  • broad or destructive change: create a stronger checkpoint before execution

Review Checklist

Before proceeding, check:

  • is the protected scope clearly named?
  • is the backup location clear?
  • is the restore method obvious?
  • does the checkpoint match the size of the risk?
  • has the user been told why this is being done?

Success Condition

This template is successful if the user feels:

  • 문제가 생겨도 돌아갈 지점이 있다
  • 백업이 형식적인 절차가 아니라 실제 복구 수단이다
  • 에이전트가 작업 전에 안전한 되돌림 지점을 만든다