Plan maintenance and the next change

The original project and task notes

Send one action at a time: select and copy its prompt (⌘C on Mac, Ctrl+C on Windows), switch to your tool’s project chat, paste it, replace bracketed fields and send. Wait for the reply and check the stated result before continuing.

1. Distinguish code, application data and learning drafts. Follow the database backup and restoration actions only when your project uses a database. Otherwise back up its actual files, then continue to the final handoff action.OpenClose

   Suggested prompt:

   List code and actual data locations and how/where each is backed up. A commit does not replace a database backup.

   Afterwards, you should see: Each backup source and destination is clear.

2. Create a new dated backup without overwriting older files.OpenClose

   Suggested prompt:

   Use the database’s supported consistent-backup method. Report source, destination and current record count, then output size. Preserve original data.

   Afterwards, you should see: A nonempty backup exists at the reported location.

3. Restore into a separate test location and actually read the records.OpenClose

   Suggested prompt:

   Restore to a separate test destination. Show source and target paths first. Start only a test service connected to the copy and give its URL. Never overwrite the source.

   Afterwards, you should see: The restored copy opens with records from the backup.

4. Open the restored copy’s URL and save “restore test 001”. Give its ID to the tool and check that it is absent from the original database. If saving fails, report the error instead of claiming success.OpenClose

   Suggested prompt:

   I added “restore test 001” only to the restored copy, with ID [fill in]. Check the copy’s old and new records, and read-only verify that the original does not contain this addition. Record backup location, restoration method and actual results in docs/handoff.md, then stop the test service. Do not modify the original database.

   Afterwards, you should see: The copy saves new records, the original is unchanged, and restoration instructions are saved.

5. Record where to resume next time.OpenClose

   Suggested prompt:

   Update docs/handoff.md with location, revision, startup, open issues and next task. A new chat should read it rather than recreate the project.

   Afterwards, you should see: The next session can find the project and next task.

1. Distinguish code, application data and learning drafts. Follow the database backup and restoration actions only when your project uses a database. Otherwise back up its actual files, then continue to the final handoff action.

   What should you see after this action?

   Each backup source and destination is clear.

   What should you do if that result is missing?

   Ask for data storage if only a repository is listed.

2. Create a new dated backup without overwriting older files.

   What should you see after this action?

   A nonempty backup exists at the reported location.

   What should you do if that result is missing?

   Check space, path and permissions on failure.

3. Restore into a separate test location and actually read the records.

   What should you see after this action?

   The restored copy opens with records from the backup.

   What should you do if that result is missing?

   Stop if the paths match or are uncertain.

4. Open the restored copy’s URL and save “restore test 001”. Give its ID to the tool and check that it is absent from the original database. If saving fails, report the error instead of claiming success.

   What should you see after this action?

   The copy saves new records, the original is unchanged, and restoration instructions are saved.

   What should you do if that result is missing?

   Preserve mismatches and inspect backup time/paths.

5. Record where to resume next time.

   What should you see after this action?

   The next session can find the project and next task.

   What should you do if that result is missing?

   Describe new scope and update requirements/plans first.

If you completed the individual prompts above, do not resend this full template. Use it to organize this step’s material when needed; replace bracketed fields, confirm and copy into the project chat.

First check access to docs/release.md. If missing or inaccessible, identify the prerequisite and owner action, then stop rather than invent prior work.
Read the project, README, task list and release record. Prepare the maintenance handoff and verify backup/restore in the authorized test environment without recreating the project. Save docs/handoff.md with actual location, revision, entry, verified/unverified status and next task. Add applicable maintenance rows: owner, frequency, console/file entry, action, normal result and failure response for backup/test restore, billing, logs, updates and expiry. Sync README and task status. Restore only in an authorized test environment; mark unavailable trials unverified. For new scope, propose affected documents/tests and wait for confirmation before development.

First check access to docs/release.md. If missing or inaccessible, identify the prerequisite and owner action, then stop rather than invent prior work.
Read the project, README, task list and release record. Prepare the maintenance handoff and verify backup/restore in the authorized test environment without recreating the project. Save docs/handoff.md with actual location, revision, entry, verified/unverified status and next task. Add applicable maintenance rows: owner, frequency, console/file entry, action, normal result and failure response for backup/test restore, billing, logs, updates and expiry. Sync README and task status. Restore only in an authorized test environment; mark unavailable trials unverified. For new scope, propose affected documents/tests and wait for confirmation before development.

I selected the full-stack journal practice.
Use SQLite backup/restore in an authorized isolated test directory, verify IDs/counts and never overwrite the original. Handoff records commands, absolute database path, dependencies and next task; unperformed restore remains unverified.
Report separate full paths for source, dated backup and restored copy, with baseline count and sample IDs. Create a consistent backup and run the restored copy with JOURNAL_DB on a free port. Check old records, insert a restore-only item and verify the source has no new item. Stop the test service; record actual commands, paths, baseline, results, untested items and next task in docs/handoff.md. Guide backups and commits do not replace database backups.

Ask for data storage if only a repository is listed.

Backup example: weekly, owner, service backup entry, restore in test and compare records; preserve the source on failure. Adjust frequency to acceptable loss.