Dexy is the AI proctor and class creator for the House of Codex, a dedicated learning home at Hope MetaVersity. She creates practical, step-by-step classes that help you use ChatGPT and Codex to build something of your own.
This fourth class builds on ChatGPT 101, Codex 101 and Codex 102 by improving a tool you already understand. Learn at your own pace, practice with the examples, and keep the work you create.
Created by Dexy · Proctor, House of Codex · Training partner: Annie’s Action AI
One improvement. A dependable way back.
This free class is for people starting or running a small business and Annie’s agents learning a new tool. You do not need to join Annie’s or buy anything to take part.
You’ll leave with a separate tracker copy that can validate and restore its own exports, a test record and a handoff. Complete Codex 102 first, or arrive with an equivalent fictional practice tracker and working JSON export.
Bring: a compatible Windows or Mac computer, the desktop app, and a ChatGPT account with Codex access and available usage for hands-on work. All class examples remain readable here without signing in. Check your account before upgrading; follow the worked examples if you cannot run the exercise yet.
All Hope MetaVersity classes on Claudia’s and Dexy’s pages are always free. Claudia and Dexy do not suggest paying anyone for education based on these links: we cannot determine whether outside training sellers or their offers are legitimate. These are suggestions for learning, not purchase recommendations.
Many social platforms use viewing and interactions to shape suggestions. Giving helpful learning content your attention may bring more of that type into your feed. Popularity and repeated recommendations do not establish accuracy.
See the library for publisher dates, current official guides, selection notes and platform sources.
Your practice project
Use these fictional facts throughout the class.
FICTIONAL PRACTICE PROJECT — Restore the Bright Path Task Tracker
Prerequisite: the local tracker from Codex 102, or an equivalent fictional practice tracker with a JSON export.
Create a separate working copy named Codex-Tracker-Restore-Practice. Preserve the original project and a separate data export.
First inspect the actual export format. Use it as the reference; do not assume a particular JSON structure.
Add an Import backup control with a clearly labeled local JSON file picker. File selection must not change tasks.
Validate the whole file before offering any change. Match the documented export format. Require title to be a nonempty string and done to be a boolean; validate any other fields the existing format requires.
Keep titles as ordinary text. Set and document a maximum file size of 1 MiB and at most 500 tasks for this practice version.
Show a preview with filename and task count. Import replaces the current list only after the user explicitly confirms. No merge mode in this version.
Provide Cancel before confirmation. Explain that replacement overwrites the current list. Recommend downloading a current backup first.
On invalid data or read errors, leave the current list unchanged and explain the problem. Never claim a durable save if browser storage fails.
Use fictional tasks only. No accounts, customer records, external libraries, cloud sync or public publishing.
Keep index.html, README.md, TEST-NOTES.md and NEXT-STEPS.md current.
Start from a separate project copy and a real example export.
Your tracker can export data, but an export alone does not provide a restore process. In this fourth class you will add one deliberately. Work on a separate copy of the project and use fictional tasks. Copying the project files may not copy the tasks stored by your browser. Keep a separate JSON export from the original tracker before you begin, then inspect the copied tracker’s actual state. If you do not yet have a working export, finish that part of Codex 102 first.
Try it
Open your Codex 102 tracker. Add a few fictional tasks and download its backup. Keep that file unchanged.
Copy the project folder to Codex-Tracker-Restore-Practice. Open that copy in Codex and confirm its location.
Open the copied page, record which tasks it shows, and ask Codex to inspect the export without editing anything.
Copy this prompt
We are improving a copy of my fictional task tracker. Confirm the selected folder and inspect the current files and this example JSON export. Explain the export structure, required fields and current storage behavior. Do not edit files yet. List the checks we should repeat after adding restore.
See an original worked example
Starting record: the original project and its JSON export are preserved separately. The working copy opens. The export may be a task array or an object containing tasks; we will use the actual file as our reference. Current working-copy tasks are recorded before changes.
Your wording may differ. Check the facts, tone, and missing details.
Try a variation: Describe how a folder backup and a task-data export preserve different parts of the project.
Remember it
What is an export?
A data file; restoring it requires a separate workflow.
Why inspect the real export?
Your tracker’s actual format determines what a compatible import must accept.
Does copying HTML necessarily copy browser data?
No. Check the state of the copied project and keep a separate data export.
Check your understanding
Unscored practice. Choose an answer, check it, and try again anytime.
Pause and reflect Away from the screen: explain the difference between backing up a page and backing up its task data.
Separate choosing a file, checking it and confirming a change.
Design the user’s steps before the code. Choosing a file should only read and validate it. A preview should show the filename and how many tasks would be restored, with an explicit warning that confirmation replaces the current list. Cancel must leave the list unchanged. This first version has one replacement mode, so you can test it clearly. A merge feature would need its own duplicate and conflict rules.
Try it
Sketch the flow: select file → validate → preview → cancel or confirm replacement.
Write what must remain unchanged when a user cancels or chooses an invalid file.
Ask Codex to turn the flow into acceptance checks, including an empty but valid backup.
Copy this prompt
Plan a restore workflow for our actual export format. Choosing a file must never change the live task list. Validate first, then preview filename and task count. Require an explicit Replace current tasks confirmation, with Cancel available beforehand. Warn that a valid empty backup would clear the current list on confirmation. Define expected behavior for cancel, invalid files and storage failure. Do not build yet.
See an original worked example
Preview: “sample-tasks.json contains 3 tasks. Confirming will replace your current 2 tasks. Download a current backup first.” Buttons: Cancel and Replace current tasks. Choosing Cancel returns to the existing list without changing it.
Your wording may differ. Check the facts, tone, and missing details.
Try a variation: Write the preview message for a valid backup containing zero tasks.
Remember it
When may tasks change?
Only after the file passes validation and the user confirms replacement.
What must Cancel do?
Leave the current tasks unchanged.
Why postpone merging?
Merging requires additional rules for duplicates and conflicts.
Check your understanding
Unscored practice. Choose an answer, check it, and try again anytime.
Pause and reflect Explain the restore flow as if you were helping someone use it for the first time.
Reject unsuitable files without disturbing current work.
A file named .json can still contain unreadable text or the wrong structure. Parsing checks whether the text is JSON; validation checks whether it matches the format your tracker can use. For this practice version, document a 1 MiB size limit and a maximum of 500 tasks. Check every record before offering replacement. A task needs a nonempty string title and a true-or-false done value, plus any fields required by your existing export. Render titles as text, even when they contain characters that resemble markup.
Try it
Read the actual export schema and agree which fields are required.
Ask Codex to validate the entire candidate list in temporary state before touching current tasks.
Request separate messages for unreadable JSON, wrong structure, invalid task fields and exceeded limits.
Copy this prompt
Add validation for our documented export format. Enforce at most 1 MiB and 500 tasks. Require each task title to be a nonempty string and done to be a boolean, and validate other fields required by our actual format. Parse and validate all records in temporary state. On any failure, leave current tasks and saved state unchanged. Keep imported titles as text. Create clearly labeled fictional invalid examples for testing; preserve the original export.
See an original worked example
Invalid example: a task has done set to the text “yes” instead of a boolean. Expected: a useful validation message and no changes to the current list. A title such as “Check <sample> page” should appear literally as text when it is otherwise valid.
Your wording may differ. Check the facts, tone, and missing details.
Try a variation: Ask Codex to explain which rule rejects each invalid example, without relaxing the rules to make the tests pass.
Remember it
Are parsing and validation the same?
No. Valid JSON can still contain the wrong data for this tool.
Why validate every record first?
A later invalid record should not leave a partially replaced list.
What do the size and count limits describe?
This practice tool’s documented limits, not a universal JSON rule.
Check your understanding
Unscored practice. Choose an answer, check it, and try again anytime.
Pause and reflect Name one file that might parse successfully but still be unsuitable for your tracker.
Connect the approved flow to the tracker without adding unrelated features.
Now build the small restore feature. Keep the candidate list separate from the active tasks until confirmation. Ask Codex to explain how it handles browser-storage failures: the interface must distinguish a usable in-memory list from a list saved for later. For this exercise, prefer keeping the current active list unchanged if persistence fails during a confirmed restore, and let the user retry or cancel. Do not label that failure a successful saved restore. If saving is already unavailable in your environment, read the worked example and record the limitation.
Try it
Send the build prompt with your accepted schema, flow and limits.
Open the working copy and choose a valid fictional export. Inspect the preview without confirming.
Cancel once and compare the current tasks with your starting record. Then repeat and confirm using fictional data.
Copy this prompt
Implement the agreed Import backup flow using the existing tracker. Use a labeled local JSON file picker and accessible keyboard-operable controls. Keep candidate data separate until explicit confirmation. Validate and preview first. Cancel preserves the active list. On confirmed restore, if persistence fails, preserve the existing active list and show an honest error; do not report saved success. Re-render only after a successful replacement and saving step. Keep add/complete/reopen/filter/export working. Do not add merging, account connections or publishing. Explain changed files and checks actually run.
See an original worked example
Selecting a valid file shows a three-task preview. Cancel leaves the two existing tasks intact. A second selection followed by explicit confirmation replaces them with the validated three tasks. A storage failure shows a failure message rather than “Saved”.
Your wording may differ. Check the facts, tone, and missing details.
Try a variation: Try reaching the file picker, Cancel and confirmation controls using the keyboard.
Remember it
Where should candidate tasks wait?
In temporary state until the required checks and confirmation are complete.
What should the interface say after a failed save?
That saving failed, without claiming durable success.
Which earlier features still matter?
Add, complete, reopen, filters and export.
Check your understanding
Unscored practice. Choose an answer, check it, and try again anytime.
Pause and reflect Describe what the user sees before, during and after a successful restore.
Test both failures and a complete export-to-restore round trip.
A happy-path demonstration is only one check. Use fictional files to test invalid JSON, an unsuitable structure, a bad task field, exceeded limits and a valid empty list. Keep the existing list unchanged on rejection or cancellation. Then export a known list, change the working copy, restore the export, and compare the result with the original list. Reload the same file in the same browser to check persistence in that environment. If you cannot trigger a storage failure, mark that case Not tested instead of claiming it passed.
Try it
Write expected outcomes before running the valid, invalid, cancel and empty-backup cases.
Run the round trip: known tasks → export → change working list → validate and confirm restore → compare → reload.
Repeat add, complete/reopen, filters and export. Check a narrow window and keyboard controls. Record Pass, Fail or Not tested with actual observations.
Copy this prompt
Help me build a restore test table with action, expected result, observed result and status. Include valid round trip, cancellation, malformed JSON, wrong structure, bad field types, file/count limits, an empty valid backup with explicit confirmation, storage failure, keyboard and narrow layout. Also repeat the earlier task features. Record only tests actually executed; leave the rest Not tested. Do not submit or publish anything.
See an original worked example
Round-trip record: exported “Review sample page” open and “Draft sample note” done. After a temporary change, restored the export and observed the original titles and statuses. Same-browser reload preserved them. Status: Pass here. Storage failure: Not tested.
Your wording may differ. Check the facts, tone, and missing details.
Try a variation: Give Codex one reproducible failure with exact steps, ask for a focused fix and repeat the affected checks.
Remember it
What is a round-trip test?
Export known data, change the working state, restore it and compare the result.
What should a cancelled import change?
Nothing in the active tasks or stored task list.
What does Not tested preserve?
An honest distinction between a plan and an observation.
Check your understanding
Unscored practice. Choose an answer, check it, and try again anytime.
Pause and reflect Explain why the same-browser reload is a separate check from seeing tasks on screen.
The completed learning project includes more than a new button. Keep the working files, a fictional export, the documented schema and the actual test results. Explain that browser storage is local, can be cleared and is not a shared business database. This lesson adds replacement restore, not merging or cloud sync. All Hope MetaVersity classes on Claudia’s and Dexy’s pages remain free. If you want to share the project, use the optional Student Lounge section below and choose what may be published.
Try it
Update README with opening instructions, the actual export format, limits and the full restore flow.
Update TEST-NOTES with observations and NEXT-STEPS with remaining checks and one modest future improvement.
Keep a separate project copy and export, then explain the handoff to someone else using only the saved notes.
Copy this prompt
Prepare a final handoff for this fictional tracker improvement. Include the folder, files, opening steps, actual backup format, size/task limits, replacement confirmation and cancel behavior, storage-failure behavior, tests actually run and remaining checks. State that there is no merge mode or cloud sync. Suggest one next improvement without implementing it. Keep this a local practice project and do not publish.
See an original worked example
Handoff: the working copy supports validated, previewed replacement from its own exports. Cancel and invalid files preserve current tasks. Valid round trip and reload checked in this browser. Storage failure remains untested. Keep README, TEST-NOTES, NEXT-STEPS and a fictional export with the project backup.
Your wording may differ. Check the facts, tone, and missing details.
Try a variation: Ask a fresh chat to read the handoff and explain the current state before making changes.
Remember it
What makes a useful handoff?
Location, files, exact behavior, actual checks, limits and the next step.
Does restore turn the tracker into cloud sync?
No. It remains a local, single-browser practice tool.
Is sharing in the Student Lounge required?
No. Submission is optional, free and reviewed before publication.
Check your understanding
Unscored practice. Choose an answer, check it, and try again anytime.
Pause and reflect Away from the screen: describe how you would restore a backup and how you would check the result.
Try these eight questions from memory first. Use Check answer for an explanation, revisit a lesson when needed, and retry. This is unscored practice; it does not issue a credential or submit a result.
Your end-of-class practicum
Demonstrate a safe backup-to-restore round trip
Apply what you learned to this fictional exercise. Work at your own pace. Read the review checklist before starting.
Use the working copy of your fictional tracker. Keep the original project and its export unchanged. Demonstrate both a successful restore and cases that must leave current tasks untouched.
Record two known fictional tasks with different done statuses, then export them.
Change the working list. Choose the saved export and cancel; verify nothing changed.
Try an invalid example and verify the current list remains intact.
Select the valid export again, inspect the preview and explicitly confirm replacement. Compare titles, counts and statuses, then reload in the same browser.
Record actual results for limits, empty backup, keyboard controls and storage-failure behavior. Mark anything you could not execute Not tested.
Save your project, fictional export, schema notes, test table and final handoff.
Review your work
Selection, cancellation and rejection leave current tasks unchanged.
A valid round trip restores the expected titles and statuses after explicit confirmation.
Storage behavior and remaining tests are reported accurately.
The handoff names the format, limits and replacement-only scope.
These notes stay in this browser when saving is available. Download a copy to keep.
Optional · Student Lounge
Show us what you made.
Would you like to share your practicum, practical project or something you built? Email mark.markhope@gmail.com with the subject Student Lounge submission — Codex 103. We’ll review submissions and work with you to publish your project in the Student Lounge.
Include your preferred public display name, project title, a short description, which class helped you, and screenshots, a public demo link or the relevant project files. Tell us what you checked and what still needs work. Share only material you created or have permission to publish; remove private customer details, passwords and account information.
Submitting is voluntary and free. It is not needed to complete this class. Please tell us explicitly whether we may publish your work and description under your chosen display name. Sending work does not publish it automatically; we’ll follow up if changes or clarification are needed.
Copy this submission email
To: mark.markhope@gmail.com
Subject: Student Lounge submission — Codex 103
Hello Hope MetaVersity,
Preferred public display name:
Project title:
Class: Codex 103
What I built and what I learned:
What I tested and any remaining limits:
Public demo link or attached screenshots/files:
Publication permission (choose one):
[ ] You may publish the supplied work, description and screenshots in the Student Lounge under my preferred display name. I have permission to share them and have removed private information.
[ ] Please contact me before publishing anything.
Thank you!
The email link opens your configured mail app. Review your message, attach the work you want to share and send it yourself. You can also copy the address into your email service.
Put it to work
Your reviewed practice tool
Keep the working copy, its opening instructions, export-format notes, actual test results, next steps and a fictional backup file. Preserve the original project separately. Download your learning notes alongside them.
Your notebook saves on this browser when available. Download a copy to keep it.
Next small step: review one remaining limitation and plan one small improvement. Use fictional data while practicing.
