MATEThe result you are building
Your own wording plus a one-page plan with three observable checks.
Have ready: Lesson 1 running locally. No new provider accounts.
Start from your working Lesson 1 project. Guided path: continue with follow-ups. Your-own-app path: choose another private list, such as production jobs or internal requests. Both paths use the same checks. A portal with shared customer access is a later extension, because changing labels does not create permissions.
Your route: Choose one person and one job → Write a tiny record → Describe three observable checks → Change labels before structure → Save the next-step plan
Compare the label change
Annotations: the heading is now “My business follow-ups”; the field label is “Next follow-up”; the Add task button and completion behavior remain unchanged. Change your wording while preserving those actions.
1. Choose one person and one job
Write: “When [person] needs to [job], this app lets them [action] so [visible result].” Example: “When I finish a sales call, I add a follow-up and mark it done so I know what is still open.” Keep one person using their own private records for version one.
Compare your result: You can describe the first useful action in one sentence.
If yours differs: If your sentence includes billing, a marketplace, scheduling, and a CRM, keep one action and move the others to Later.
Ask Codex:
Ask me one question at a time to turn my idea into one small private-list app. Keep team sharing, payments, and external messages out of version one.
2. Write a tiny record
In APP-SPEC.md list the information in one item. Guided path: title, due date, completion status, stable ID, and owner. Your path: rename title to the business item; keep ID and owner. An ID identifies the record even when its label changes.
Compare your result: You have a field list and know which fields are entered by a person versus supplied by the app.
If yours differs: Avoid sensitive customer records while learning. If you need shared access, write it under Later and state the permission question rather than assuming owner privacy covers it.
Ask Codex:
Update APP-SPEC.md with the fields for my private list. Separate user-entered fields from system fields. Do not change the database or application yet.
3. Describe three observable checks
Write these checks in APP-SPEC.md: add a fictional item and see it once; complete it and see its state; refresh and see the same state. For now refresh means the same browser. Add cloud persistence and two-user isolation as later checks, not results already achieved.
Compare your result: Each check says what you do and what you should see.
If yours differs: Replace “works well” with a specific button, input, and result. Avoid claiming cross-device persistence for the local demo.
Ask Codex:
Write three manual acceptance checks for the current /demo behavior. Include exact fictional input and expected results. Do not claim hosted login or cross-device storage is tested.
4. Change labels before structure
Ask Codex to rename only the heading, input label, and sample wording to your chosen use case. For the guided version use “My business follow-ups” and “Next follow-up”. Keep the same item structure. Re-run your three checks after the edit.
Compare your result: Your app uses your business wording and the original actions still work.
If yours differs: If Codex introduces new fields or services, ask it to return to the label-only scope. If you broke the baseline, use checkpoint 02 in a new folder and compare the relevant files.
Ask Codex:
Read APP-SPEC.md. Adapt only the /demo labels and fictional examples to my use case. Preserve the data shape and behavior. Show a small diff, run the build, and tell me exactly what to test.
5. Save the next-step plan
Finish APP-SPEC.md with Now, Later, and Not included sections. Save evidence in LEARNING-LOG.md. Your next lesson publishes this browser-only practice app; it does not need Supabase yet.
Compare your result: You have a narrow scope, a visible result, and a plan someone else could follow.
If yours differs: If unsure which optional app spec to choose, continue the included follow-up example. No add-on is required.
Ask Codex:
Review my APP-SPEC.md against the current app. List only mismatches and the smallest next step. Keep the first deployment browser-only.
Try it without the walkthrough
Choose a second possible business use case and explain which labels could change immediately and which feature would require a new data or permission design. Then return to the one app you chose.
Prove it worked
APP-SPEC.md names one job, a small record, three observable checks, and exclusions. Your label change passes all three checks.
- Your own wording plus a one-page plan with three observable checks.
- I repeated the lesson exercise and compared the expected result.
- I saved evidence and marked untested provider checks Pending.
- I know which complete checkpoint and recovery prompt to use.
Need a clean restart?
Use 02-make-it-yours from Restart Checkpoints. Extract it into a new folder and read CHECKPOINT.md. Keep your existing work; a source restart does not restore cloud records or account settings.
Record evidence · Choose your practice path