Can You Return Exactly to the State Before Something Broke?

Here, “before it broke” means T0: a recovery point recorded and verified in advance. It does not include everything done right up to the failure. “Exactly” means that the specified code and settings files match byte for byte, and that the database schema, complete contents, and designated behavior match the reference.

In one bounded experiment, a small task list with invented data received one deliberately specified defect; each of two recovery methods was tried twice. This was neither a real user incident nor a reproduction of an accidentally AI-generated app defect. Restoring code alone left incorrect data; restoring code, data, and settings together matched T0 but removed two later legitimate changes. These observations establish no success rate or general rule.

What the official documentation says about restoring code and data

Git restore restores selected files from a specified source. Some projects do track database files in Git, and ignore rules do not apply to files already tracked.

SQLite’s backup interface creates a database copy. integrity_check checks structural integrity and some constraints; foreign-key checking is separate. An ok result means only that this check found no problems. That it does not guarantee a match with earlier values is an inference from the check’s scope. These manuals were checked on October 5, 2026.

This experiment’s design

In this experiment, data and settings were excluded from Git history from the outset, and writes controlled by the script were stopped to record the components together. SQLite journal mode was delete; writes by arbitrary external processes were not independently ruled out. Simply copying a live database file during a transaction can produce an inconsistent copy. This experiment used SQLite’s backup interface; pausing writes was its coordination constraint, not a universal requirement of that interface.

Recorded observations: a stopped first attempt and a separate rerun

The experiment ran on September 27, 2026, Korea Standard Time (UTC+09:00), using macOS 27.0 arm64, Git 2.54.0, Python 3.9.6, and SQLite 3.54.0. Astra (Codex) wrote and ran the experiment script. It used local invented data and a fixed script, with no model inference during measurement. Method A restores code only; B restores code, data, and settings.

The first attempt stopped before installing the defect because the code copy had inherited read-only permissions. This was a preparation defect in the experiment script, not a failed app recovery. Of the two planned trials for each method, A and B each completed 0/2. The healthy-state check and restoration rehearsal each passed 11/11 checks, but neither was a recovery from a fault. The faulty state, recovery time, and loss were unmeasured. Before the procedure was frozen, the editing tool blocked one attempt to create files outside its allowed folder; no files were written by that attempt. A different creation method was then used.

The first attempt ended under a no-retry instruction. The user subsequently authorized one separate second attempt. Before that execution, the copy’s write-permission correction and fresh workspace were documented. App code, expected values, and check rules stayed unchanged, and the first attempt’s evidence was preserved. The second attempt’s healthy-state check and restoration rehearsal again each passed 11/11 checks.

Recorded observations: state changes in attempt 2

The comparison covered app.py and .gitignore, the schema and all ID-ordered rows of tasks(id,title,done), and the list-title and show-completed settings in settings.json. Below, 0 means incomplete and 1 means complete.

Adding task 4 and changing the title were legitimate work. The restriction that made “complete task 2” affect only that task was deliberately removed. Running the action once set all four completion flags to 1: task 2 was the requested target, task 3 was already complete, and tasks 1 and 4 changed unintentionally. The faulty-control record shows 4/11 checks passing: schema, integrity, current-list output, and current-settings output. Integrity still returned ok. Task names and the setting for showing completed tasks were unchanged.

Recorded observations: what each method restored

The procedures deliberately restored different components. These runs checked whether that expected contrast occurred in this implementation; they did not establish which method is superior. Each trial used a fresh copy of the same faulty state, in order A1/B1/B2/A2. Each method completed its planned 2/2 trials.

The 11 checks cover code, settings, data, and behavior; their pass count is not a recovery percentage. Even a legitimate title edit counts as a mismatch with T0. A passed code, schema, integrity, current-list/settings output, and behavior checks; it failed the historical-row and T0 settings/list comparisons.

Both A trials repaired only the code, leaving the incorrect completion values in place. The A restoration deleted nothing further. Task 4 remained incorrectly marked complete by the fault, so it was not “preserved intact.” The title edit survived.

Both B trials matched T0’s specified code and settings bytes, database schema, and complete ID-ordered records. At the same time, two pieces of legitimate work disappeared: task 4 and the title edit. Matching the recovery point and preserving later work were different outcomes. Neither method recovered the last legitimate pre-fault state: four tasks with flags 0,0,1,0 and the title Demo v2.

Behavior was tested on a separate copy seeded with the predetermined values (0,0,1)—tasks 1 and 2 incomplete, task 3 complete: after completing task 2, the values had to be (0,1,1) and remain so after reopening. A and B each passed this check in 2/2 trials; the unrepaired faulty copy used for comparison failed. This probe did not test the restored four rows or task 4, and did not modify the restored data being compared. Passing a behavior check is different from restoring historical data. In attempt 1, the backup’s database file hash (a content fingerprint) differed despite matching logical contents. Neither database file-byte identity nor all future behavior is claimed. Expected values were fixed separately from app output, but the same script restored and verified the fixtures. There was no independently implemented verifier, and the complete original trial copies were not archived.

These timings record an automated procedure, not a speed comparison. Values are rounded to six decimal places. Total time runs from the start of restoration to the end of verification and was measured separately, so rounded parts may differ from the total in the last digit. Preparing the separate trial copies took 0.007964, 0.007863, 0.009005, and 0.009480 seconds in order A1/B1/B2/A2. Automated preparation, recovery point capture, and control checks took 0.314130 seconds. This was an automated experiment in which even the interval from T0 to the fault was only 0.077574 seconds.

For the first attempt, the recorded timestamps show 0.214146 seconds from execution start to the failure; aggregate preparation time was unmeasured. These figures do not represent human working time or establish a speed advantage. The preparation figures come from the timing record; full details are in the experiment record.

My assessment and an untested recovery-point card

My assessment is that it matters to record what was compared and what remained, changed, or disappeared together. Whether the template below improves recovery or reduces losses has not been tested.

Recovery-point card
Recorded time and time zone: ___ / Scope of paused writes: ___
Code version and location: ___ / Settings copy and location: ___
Data copy, location, and backup method appropriate to this database: ___
What to compare against (saved in advance, separately from app output): file inventory and contents, table structure and complete values, specified behavior ___
Result of restoring into a rehearsal copy: ___
Legitimate work since the recovery point and acceptable losses: ___
Post-restoration comparison: code ___ / complete data ___ / settings ___ / behavior on a separate copy ___
Work remaining, altered, or missing: ___ / What could not be verified: ___

For example, B’s entry would be “matches T0’s three tasks and Demo / later task 4 and title edit lost.” “Unknown” is an acceptable entry. Without evidence of the later work’s values, this comparison cannot establish the loss. A record that a task existed can still miss an altered value. Pause and investigate if comparisons, control checks, or the declared scope disagree. This card does not replace a safe backup procedure for a database an app is writing to, or a service-specific recovery procedure.

One computer, one defect, and two trials per method cannot establish reliability, an optimal backup interval, product or model superiority, or productivity. Novice completion time and usability, actual cost, remaining subscription capacity, the authoring model’s backend, and CLI version remain unverified. Production, hosted, concurrent-write, and distributed environments; database schema changes; undoing actions already sent to outside services; losing a backup with the same failed disk; and selectively re-applying legitimate later work were not tested. Nor was a legitimate edit to an existing completion flag followed by a conflicting faulty overwrite. The operating system, file permissions, file timestamps, and future behavior were outside the comparison. Review provenance and its limitations are in the editorial conference record.

AI assisted with research and drafting. The author reviewed the final manuscript and directed the revisions.