Vibe GuideTest the full journey personally
Acceptance means trying the agreed checks yourself and deciding whether the goal is met.
Why this milestone?
Return to the original goal and personally check whether the project solves it.
Start here3 steps · Follow in order
0103Try blank input and repeated clicksTo checkOpen this stepClose this step
01What do you need, and what should you keep?
Your working user flow and disposable test content.
Failures and untested checks are not marked passed.
Which files should AI read and save in this step?
In your tool’s project chat, ask it to open the files below. If a file is missing, follow the link back to the step that creates it.
Ask AI to read these materials first: docs/requirements.md · docs/checks.md
Ask AI to save the result to: docs/checks.md
Missing these materials? Return to the step that creates them →
02What will this step help you do?
Try invalid input, repeat clicks and service failure to check feedback and retained data.
Understand it, then judge for yourself
What does this concept mean?
Failure testing deliberately tries things going wrong to see how the project responds.
How would you decide in a different situation?
Which mistake is most likely besides normal input?
See a reference answer
Choose likely project-specific mistakes and expected handling; do not add features merely to test them.
Answer in your own words; if unsure, compare the explanation above and check it against your own project.
03What exactly should you do in this step?
OpenClose
The project with test data only
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.
Try invalid input: submit empty required fields and overly long content.OpenClose
Afterwards, you should see: The page explains the problem without saving invalid records.
Check repeated clicks and service interruption in this project’s test environment only.OpenClose
Suggested prompt:
Give step-by-step tests for repeat clicks and a stopped service, one at a time. Explain how to stop and restore only this project. Test without repairing yet.
Afterwards, you should see: You have clear testing and recovery steps.
Try saving with the service stopped, then restore it.OpenClose
Afterwards, you should see: No false success; input stays. Check the list before retrying after recovery.
Record the results.OpenClose
Suggested prompt:
Write expected/actual results and untested reasons in docs/checks.md. Keep failures open for feedback and repair.
Afterwards, you should see: Failures and untested checks are not marked passed.
Practice: personal journal (frontend + backend + database)
Use the same learning-journal project throughout this example. For your own project, compare applicable requirements without creating another project.
Try blank, spaces, oversized text and double clicking; then stop only this practice service and try saving, keeping the input.
- What should you see after this step?
- Invalid data is not stored; a stopped service cannot report success; double clicking one submission creates one record.
- What should you do first if you get stuck?
- Record visible failure even if automated checks pass; stop only this project’s process, not every Python process.
04Not sure how? Follow each action
OpenClose
Try invalid input: submit empty required fields and overly long content.
- What should you see after this action?
- The page explains the problem without saving invalid records.
- What should you do if that result is missing?
- Ask the tool to check backend rejection as well.
Check repeated clicks and service interruption in this project’s test environment only.
- What should you see after this action?
- You have clear testing and recovery steps.
- What should you do if that result is missing?
- Identify the project and port before stopping any process.
Try saving with the service stopped, then restore it.
- What should you see after this action?
- No false success; input stays. Check the list before retrying after recovery.
- What should you do if that result is missing?
- If it may already be saved, verify content/ID before submitting again.
Record the results.
- What should you see after this action?
- Failures and untested checks are not marked passed.
- What should you do if that result is missing?
- Explain inapplicability instead of adding unnecessary features.
05Words in this step
OpenClose
Regression testing ↗
Checks whether changes broke existing behavior.
After fixing one light, check the others.
Concurrency ↗
Multiple tasks progress during overlapping periods.
A chef manages several pots.
06How should you handle a problem here?
OpenClose
Blank or duplicate records appear
- Where should you look to understand the problem?
- Note the clicks and resulting record count; keep evidence.
- Follow these steps to resolve the problem
- Collect symptoms, actions, revision and exact errors; use read-only diagnosis if needed. Do not repair here. Record feedback and confirm the plan in “Plan the fix and its passing checks” first.
- Expected recovery
- Verifiable records exist; untested and failed results keep their status.
Edit the template with actual material, confirm, then copy into the current project conversation. Mark unknowns as undecided and replace examples as needed.
Confirmed · personalized content ready to copy
I am at “Try blank input and repeated clicks”. Expected: Applicable failure checks have evidence; failures and unexecuted cases retain their status.. Actual screen/error: [add here]. Inspect existing files first. Give one reversible action at a time, its location, and expected result. Do not recreate the project or delete existing work.07Material for this step (fill or copy)
OpenClose
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.
Edit the template with actual material, confirm, then copy into the current project conversation. Mark unknowns as undecided and replace examples as needed.
Confirmed · personalized content ready to copy
First check access to docs/requirements.md, docs/checks.md. If missing or inaccessible, identify the prerequisite and owner action, then stop rather than invent prior work.
Read failure cases and test criteria; check only invalid inputs and repeated actions applicable to the current features. Do not add input or storage to make a test applicable. Record actions, expected and actual results and passed/failed/not-run status in docs/checks.md. Explain unavailable conditions. Only test and record; leave repairs to the feedback and repair steps.Journal practice: fill or supplement this step
For this full-stack practice only: use this combined prompt, fill its fields and send it once instead of also sending the generic template. It does not authorize later steps.
Edit the template with actual material, confirm, then copy into the current project conversation. Mark unknowns as undecided and replace examples as needed.
Confirmed · personalized content ready to copy
First check access to docs/requirements.md, docs/checks.md. If missing or inaccessible, identify the prerequisite and owner action, then stop rather than invent prior work.
Read failure cases and test criteria; check only invalid inputs and repeated actions applicable to the current features. Do not add input or storage to make a test applicable. Record actions, expected and actual results and passed/failed/not-run status in docs/checks.md. Explain unavailable conditions. Only test and record; leave repairs to the feedback and repair steps.
I selected the full-stack journal practice.
Test only: direct backend blank/oversized requests must fail without new records; check double submit, preserved input on network failure and visible list-load errors. Retain results, do not repair here. If the response is uncertain, read the list before retrying; a network error does not prove no write occurred.08Check this before continuing
Applicable failure checks have evidence; failures and unexecuted cases retain their status.
09What should you do if the expected result is missing?
OpenClose
Ask the tool to check backend rejection as well.
Compare with an example (illustration, not your result)
Duplicate booking passed; offline failed; iPhone device untested. This is not an all-pass report.
Record this check and project version
This is self-reported, not automatic inspection. Old checks do not prove a changed version; complete or report failed and untested work.
0203Reopen it after stoppingTo checkOpen this stepClose this step
01What do you need, and what should you keep?
The startup instructions and a saved test record.
The reopened project works and retains required data.
Which files should AI read and save in this step?
In your tool’s project chat, ask it to open the files below. If a file is missing, follow the link back to the step that creates it.
Ask AI to read these materials first: README.md
Ask AI to save the result to: docs/checks.md
Missing these materials? Return to the step that creates them →
02What will this step help you do?
Check that you can close it today and reopen it from the instructions tomorrow.
Understand it, then judge for yourself
What does this concept mean?
The browser page and backend are separate; closing the browser may leave the service running.
How would you decide in a different situation?
Without this chat tomorrow, could you reopen the project using its saved instructions?
See a reference answer
README should locate the project, entry/command and expected result without chat history.
Answer in your own words; if unsure, compare the explanation above and check it against your own project.
03What exactly should you do in this step?
OpenClose
The restart instructions and original project
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.
Note one saved record and find README’s stop/start instructions.OpenClose
Afterwards, you should see: You know which record to find after reopening.
Stop and restart the project; closing the browser alone does not stop its backend.OpenClose
Suggested prompt:
Stop and restart this project using README.md, keeping its database. Give the actual URL; do not create a new project or reset data.
Afterwards, you should see: The restarted project opens.
Open the reported URL, find the record and try the main action.OpenClose
Suggested prompt:
My reopening result is: 【fill in】. Update README.md and docs/checks.md with actual instructions and results.
Afterwards, you should see: The reopened project works and retains required data.
Practice: personal journal (frontend + backend + database)
Use the same learning-journal project throughout this example. For your own project, compare applicable requirements without creating another project.
Note a record ID, stop as documented, restart from the original folder and open the URL.
- What should you see after this step?
- The same ID remains readable; restart did not create an empty database.
- What should you do first if you get stuck?
- If missing, compare absolute database paths and preserve the original file; do not reset it.
Match an error to the next action
List becomes empty after restart
- What should you check first?
- Compare database absolute paths and counts before adding more data.
- Follow these steps to resolve the problem
- If a different empty database was opened, preserve both files and correct the fixed path; inspect old records before starting.
- What should you see after the problem is resolved?
- Original IDs and content return.
Browser reports ERR_UNSAFE_PORT
- What should you check first?
- The service may be running on a browser-blocked port; this is not evidence of database damage.
- Follow these steps to resolve the problem
- Keep the error and URL. Ask the tool to choose a free browser-allowed port for this project and use the new startup URL; do not disable browser security.
- What should you see after the problem is resolved?
- The new URL opens and still uses the same database and records.
04Not sure how? Follow each action
OpenClose
Note one saved record and find README’s stop/start instructions.
- What should you see after this action?
- You know which record to find after reopening.
- What should you do if that result is missing?
- Ask for the exact directory, command and URL if missing.
Stop and restart the project; closing the browser alone does not stop its backend.
- What should you see after this action?
- The restarted project opens.
- What should you do if that result is missing?
- Identify occupied ports; use a free allowed port rather than disabling browser protection.
Open the reported URL, find the record and try the main action.
- What should you see after this action?
- The reopened project works and retains required data.
- What should you do if that result is missing?
- Check project and database paths before changing data.
05Words in this step
OpenClose
URL ↗
An address identifying a resource and access scheme.
A full address can include a building, room, and details.
Database ↗
A system for storing, retrieving, and updating data.
A ledger office supporting structured lookup.
06How should you handle a problem here?
OpenClose
The address fails the next day
- Where should you look to understand the problem?
- Has yesterday’s preview service stopped?
- Follow these steps to resolve the problem
- Open the original project and ask AI to restart it from README and report the real URL. Do not create a replacement project or change the data location.
- Expected recovery
- The original project opens and its records have been checked.
Edit the template with actual material, confirm, then copy into the current project conversation. Mark unknowns as undecided and replace examples as needed.
Confirmed · personalized content ready to copy
I am at “Reopen it after stopping”. Expected: The original project reopens as documented and the core action works; retention is checked as required.. Actual screen/error: [add here]. Inspect existing files first. Give one reversible action at a time, its location, and expected result. Do not recreate the project or delete existing work.07Material for this step (fill or copy)
OpenClose
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.
Edit the template with actual material, confirm, then copy into the current project conversation. Mark unknowns as undecided and replace examples as needed.
Confirmed · personalized content ready to copy
First check access to README.md. If missing or inaccessible, identify the prerequisite and owner action, then stop rather than invent prior work.
Write verified restart steps in README.md: which folder, where to run, exact command or file, URL, and expected result. Do not guess a port. Record a data baseline, stop and restart this project service, then compare IDs/content; without persistence check core execution only. Save actual commands, entry, revision, tool checks and pending personal retests in docs/checks.md.Journal practice: fill or supplement this step
For this full-stack practice only: use this combined prompt, fill its fields and send it once instead of also sending the generic template. It does not authorize later steps.
Edit the template with actual material, confirm, then copy into the current project conversation. Mark unknowns as undecided and replace examples as needed.
Confirmed · personalized content ready to copy
First check access to README.md. If missing or inaccessible, identify the prerequisite and owner action, then stop rather than invent prior work.
Write verified restart steps in README.md: which folder, where to run, exact command or file, URL, and expected result. Do not guess a port. Record a data baseline, stop and restart this project service, then compare IDs/content; without persistence check core execution only. Save actual commands, entry, revision, tool checks and pending personal retests in docs/checks.md.
I selected the full-stack journal practice.
Stop/restart only this service, compare the absolute database path and original record ID/count, and prove retention with a backend query. Record real commands/port; never reset the database.
Record the original ID/content, then give actual stop/start/URL actions from README. Closing the browser is not restarting the backend. Append my reported results to docs/checks.md; preserve data on failure.08Check this before continuing
The original project reopens as documented and the core action works; retention is checked as required.
09What should you do if the expected result is missing?
OpenClose
Ask for the exact directory, command and URL if missing.
Compare with an example (illustration, not your result)
A static page must reopen; a notes tool must also retain notes.
Record this check and project version
This is self-reported, not automatic inspection. Old checks do not prove a changed version; complete or report failed and untested work.
0303Check it against the original ideaTo checkOpen this stepClose this step
01What do you need, and what should you keep?
Your original requirements and actual trial results.
docs/acceptance.md contains your actual actions and conclusion.
Which files should AI read and save in this step?
In your tool’s project chat, ask it to open the files below. If a file is missing, follow the link back to the step that creates it.
Ask AI to read these materials first: Confirmed material and project location
Ask AI to save the result to: docs/acceptance.md
Missing these materials? Return to the step that creates them →
02What will this step help you do?
Return to the original goal and personally check whether the project solves it.
Understand it, then judge for yourself
What does this concept mean?
Acceptance means trying the agreed checks yourself and deciding whether the goal is met.
How would you decide in a different situation?
Are there blockers or untried core steps?
See a reference answer
Untested critical work remains untested and unacceptable issues need feedback; AI cannot supply personal acceptance.
Answer in your own words; if unsure, compare the explanation above and check it against your own project.
03What exactly should you do in this step?
OpenClose
The idea, requirements, and actual work
Reread your original description and the things the finished project should do.OpenClose
Afterwards, you should see: You have your own goals and practical tests.
Use the project as its intended user without having the tool patch data mid-flow.OpenClose
Afterwards, you should see: You know whether it solves the original problem.
Fill and confirm the trial record, then use the save-in-project section to generate and send its save instruction.OpenClose
Afterwards, you should see: docs/acceptance.md contains your actual actions and conclusion.
Practice: personal journal (frontend + backend + database)
Use the same learning-journal project throughout this example. For your own project, compare applicable requirements without creating another project.
Personally test creation, retrieval, retry and restart against original requirements before filling results.
- What should you see after this step?
- Acceptance names the current version and evidence for page, backend and database.
- What should you do first if you get stuck?
- Mark unperformed checks untested; do not copy example success as your own result.
04Not sure how? Follow each action
OpenClose
Reread your original description and the things the finished project should do.
- What should you see after this action?
- You have your own goals and practical tests.
- What should you do if that result is missing?
- Document changed goals instead of silently lowering criteria.
Use the project as its intended user without having the tool patch data mid-flow.
- What should you see after this action?
- You know whether it solves the original problem.
- What should you do if that result is missing?
- Mark untested if you cannot try it; do not copy an AI pass.
Fill and confirm the trial record, then use the save-in-project section to generate and send its save instruction.
- What should you see after this action?
- docs/acceptance.md contains your actual actions and conclusion.
- What should you do if that result is missing?
- Record issues when failing; choose delivery only after goals are met.
05Words in this step
OpenClose
Acceptance criteria ↗
Observable conditions used to accept completed work.
Instead of “fast service,” require a collection number after payment.
Dependency version ↗
An identifier for a package release.
Different releases of a part may behave differently.
06How should you handle a problem here?
OpenClose
AI says done, but I cannot use it
- Where should you look to understand the problem?
- Can the main task be completed without reading the chat?
- Follow these steps to resolve the problem
- Identify the first point needing explanation. Ask for a clearer interface or restart guide, then repeat it personally.
- Expected recovery
- The main flow works without extra explanation from its author.
Edit the template with actual material, confirm, then copy into the current project conversation. Mark unknowns as undecided and replace examples as needed.
Confirmed · personalized content ready to copy
I am at “Check it against the original idea”. Expected: Personal trial results are recorded; local use is a valid choice.. Actual screen/error: [add here]. Inspect existing files first. Give one reversible action at a time, its location, and expected result. Do not recreate the project or delete existing work.07Material for this step (fill or copy)
OpenClose
Fill your own material below, confirm it and check the result. Follow the actions above for when to give it to your tool. If reopening shows only the editor, review and confirm again to copy.
Edit the template below and confirm to prepare a copyable draft. Use it as directed by this step; sending it to AI is not required.
Confirmed · personalized content ready to copy
Version and entry: [fill in]
Which original goal are you checking in this trial: [fill in]
Where did you start, and what did you do in order: [fill in]
What should happen according to the original agreement: [fill in]
Actual result: [not an AI completion claim]
Verdict: [passed/failed/not tested]
Outstanding items: [details or none]Journal practice: fill or supplement this step
Use this as guidance for filling the template with your real information. Never copy example acceptance, costs, paths or test results.
Personal trial: version, entry, record ID, normal save, blank rejection, preserved input while stopped and restart read-back. Fill passed/failed/untested with actual observations.
08Check this before continuing
Personal trial results are recorded; local use is a valid choice.
09What should you do if the expected result is missing?
OpenClose
Document changed goals instead of silently lowering criteria.
Compare with an example (illustration, not your result)
Revision abc: booking passed, cancellation untested → not fully accepted.
Save the confirmed record in the actual project
Complete and confirm this page’s template, then use the button below. AI saves it to docs/acceptance.md; open the actual file to check it.
Record this check and project version
This is self-reported, not automatic inspection. Old checks do not prove a changed version; complete or report failed and untested work.
Not passed? Repair before continuingWhen testing or release review finds a problem, repair in three steps, then return to the milestone above.
0103Record the trial feedbackTo checkOpen this stepClose this step
01What do you need, and what should you keep?
The actions, screen or error from the failure.
Issues have IDs, reproduction steps and evidence.
Which files should AI read and save in this step?
In your tool’s project chat, ask it to open the files below. If a file is missing, follow the link back to the step that creates it.
Ask AI to read these materials first: Confirmed material and project location
Ask AI to save the result to: docs/feedback.md
Missing these materials? Return to the step that creates them →
02What will this step help you do?
Describe the failure precisely so the tool can find the same problem.
Understand it, then judge for yourself
What does this concept mean?
Feedback records actions and observations; you do not need to diagnose the code.
How would you decide in a different situation?
Which is an observation and which needs evidence: “button does nothing” or “database is broken”?
See a reference answer
An unresponsive button is an observation; a broken database is a hypothesis needing evidence.
Answer in your own words; if unsure, compare the explanation above and check it against your own project.
03What exactly should you do in this step?
OpenClose
The work, this template and project chat
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.
Choose one issue and record the entry, input, clicks and result.OpenClose
Afterwards, you should see: Someone else can follow the same steps.
Fill the template with actions/errors, confirm and send it.OpenClose
Suggested prompt:
Organize these issues in docs/feedback.md with IDs, expected and actual results: 【paste record】. Record and investigate without changing code. Do not present guesses as facts.
Afterwards, you should see: Issues have IDs, reproduction steps and evidence.
Practice: personal journal (frontend + backend + database)
Use the same learning-journal project throughout this example. For your own project, compare applicable requirements without creating another project.
Collect test input, click sequence, time, page message and error together; omit private data from screenshots.
- What should you see after this step?
- Someone can reproduce the issue, rather than merely reading “save broke”.
- What should you do first if you get stuck?
- If logs are unfamiliar, ask Codex to locate this service’s output and extract the matching error.
04Not sure how? Follow each action
OpenClose
Choose one issue and record the entry, input, clicks and result.
- What should you see after this action?
- Someone else can follow the same steps.
- What should you do if that result is missing?
- Describe the symptom, not merely “broken”; you need not know the cause.
Fill the template with actions/errors, confirm and send it.
- What should you see after this action?
- Issues have IDs, reproduction steps and evidence.
- What should you do if that result is missing?
- Hide passwords/private information in screenshots before sharing.
05Words in this step
OpenClose
06How should you handle a problem here?
OpenClose
The issue happens intermittently
- Where should you look to understand the problem?
- Record occurrence count, device, version and the latest full sequence.
- Follow these steps to resolve the problem
- Collect symptoms, actions, revision and exact errors; use read-only diagnosis if needed. Do not repair here. Record feedback and confirm the plan in “Plan the fix and its passing checks” first.
- Expected recovery
- Verifiable records exist; untested and failed results keep their status.
Edit the template with actual material, confirm, then copy into the current project conversation. Mark unknowns as undecided and replace examples as needed.
Confirmed · personalized content ready to copy
I am at “Record the trial feedback”. Expected: Feedback is reproducible and separates facts, guesses and new requests.. Actual screen/error: [add here]. Inspect existing files first. Give one reversible action at a time, its location, and expected result. Do not recreate the project or delete existing work.07Material for this step (fill or copy)
OpenClose
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.
Edit the template with actual material, confirm, then copy into the current project conversation. Mark unknowns as undecided and replace examples as needed.
Confirmed · personalized content ready to copy
First check access to the current project location. If missing or inaccessible, identify the prerequisite and owner action, then stop rather than invent prior work.
Version/date: [fill in]
Device and entry: [fill in]
Feature: [fill in]
Steps: [fill in]
Expected: [fill in]
Actual: [fill in]
Evidence: [attach or none]
Does the problem happen every time or only sometimes: [always/sometimes/once]
Which action does this problem prevent you from completing: [blocked/workaround/cosmetic]
Passed and untested: [fill in]
Save these personal observations in docs/feedback.md with issue IDs. Preserve facts and unknowns; ask for missing material. Do not fix code yet.Journal practice: fill or supplement this step
For this full-stack practice only: use this combined prompt, fill its fields and send it once instead of also sending the generic template. It does not authorize later steps.
Edit the template with actual material, confirm, then copy into the current project conversation. Mark unknowns as undecided and replace examples as needed.
Confirmed · personalized content ready to copy
First check access to the current project location. If missing or inaccessible, identify the prerequisite and owner action, then stop rather than invent prior work.
Version/date: [fill in]
Device and entry: [fill in]
Feature: [fill in]
Steps: [fill in]
Expected: [fill in]
Actual: [fill in]
Evidence: [attach or none]
Does the problem happen every time or only sometimes: [always/sometimes/once]
Which action does this problem prevent you from completing: [blocked/workaround/cosmetic]
Passed and untested: [fill in]
Save these personal observations in docs/feedback.md with issue IDs. Preserve facts and unknowns; ask for missing material. Do not fix code yet.
I selected the full-stack journal practice.
Name the failing check: table/API/connection/read/restart. Distinguish page messages from backend errors; do not paste full database contents or secrets.08Check this before continuing
Feedback is reproducible and separates facts, guesses and new requests.
09What should you do if the expected result is missing?
OpenClose
Describe the symptom, not merely “broken”; you need not know the cause.
Compare with an example (illustration, not your result)
F01 / cancel then refresh / expect one place restored / actual unchanged / revision abc / reproduced twice.
0203Plan the fix and its passing checksTo checkOpen this stepClose this step
01What do you need, and what should you keep?
The feedback record you just saved.
The fix and its test are specific.
Which files should AI read and save in this step?
In your tool’s project chat, ask it to open the files below. If a file is missing, follow the link back to the step that creates it.
Ask AI to read these materials first: docs/feedback.md · docs/requirements.md
Ask AI to save the result to: docs/repair-plan.md
Missing these materials? Return to the step that creates them →
02What will this step help you do?
Understand the proposed fix before letting the tool make it.
Understand it, then judge for yourself
What does this concept mean?
A repair plan explains changes, possible effects and retesting.
How would you decide in a different situation?
Why check history retrieval after fixing the Save button?
See a reference answer
Saving and reading may share structures/APIs; retest the fix and regress related behavior.
Answer in your own words; if unsure, compare the explanation above and check it against your own project.
03What exactly should you do in this step?
OpenClose
Project chat and docs/repair-plan.md
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.
Ask why the issue occurs before changing anything.OpenClose
Suggested prompt:
Read docs/feedback.md and the requirements. Investigate without changing code. Separate facts from hypotheses and give the next small check.
Afterwards, you should see: The explanation fits the observed issue.
Review where the fix will happen and how you will check it.OpenClose
Suggested prompt:
Save docs/repair-plan.md with changed files, affected features, original-case retest and expected results. Include backup/recovery before database changes. Wait for my approval.
Afterwards, you should see: The fix and its test are specific.
Practice: personal journal (frontend + backend + database)
Use the same learning-journal project throughout this example. For your own project, compare applicable requirements without creating another project.
Ask Codex to reproduce and identify the layer to change and the failed action to rerun.
- What should you see after this step?
- The plan protects data and retests previously working saves.
- What should you do first if you get stuck?
- Stop a suggested database deletion; request backup and a non-destructive plan or more diagnosis.
04Not sure how? Follow each action
OpenClose
Ask why the issue occurs before changing anything.
- What should you see after this action?
- The explanation fits the observed issue.
- What should you do if that result is missing?
- Investigate further rather than defaulting to reinstalling or deleting storage.
Review where the fix will happen and how you will check it.
- What should you see after this action?
- The fix and its test are specific.
- What should you do if that result is missing?
- Ask for specifics if it only says optimize.
05Words in this step
OpenClose
Root cause ↗
The underlying cause rather than a symptom.
A dark lamp may be caused by wiring.
Regression testing ↗
Checks whether changes broke existing behavior.
After fixing one light, check the others.
06How should you handle a problem here?
OpenClose
AI starts fixing without a plan
- Where should you look to understand the problem?
- Check whether changes map to feedback IDs.
- Follow these steps to resolve the problem
- Pause further changes, report and preserve work already done, then define scope and passing checks. Do not discard changes merely to return to planning.
- Expected recovery
- Repeat the original action and obtain the expected result; keep unexecuted checks marked unverified.
Edit the template with actual material, confirm, then copy into the current project conversation. Mark unknowns as undecided and replace examples as needed.
Confirmed · personalized content ready to copy
I am at “Plan the fix and its passing checks”. Expected: Every fix maps to a feedback ID and repeatable passing conditions.. Actual screen/error: [add here]. Inspect existing files first. Give one reversible action at a time, its location, and expected result. Do not recreate the project or delete existing work.07Material for this step (fill or copy)
OpenClose
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.
Edit the template with actual material, confirm, then copy into the current project conversation. Mark unknowns as undecided and replace examples as needed.
Confirmed · personalized content ready to copy
First check access to docs/feedback.md, docs/requirements.md. If missing or inaccessible, identify the prerequisite and owner action, then stop rather than invent prior work.
Read feedback, requirements, current version and checks. Reproduce issues and separate defects, new requests and missing evidence. Label uncertain causes. Write docs/repair-plan.md with issue IDs, impact, minimal scope, passing checks, regression checks and recovery. Explain scope or design changes before acting. Plan only; do not modify business code.Journal practice: fill or supplement this step
For this full-stack practice only: use this combined prompt, fill its fields and send it once instead of also sending the generic template. It does not authorize later steps.
Edit the template with actual material, confirm, then copy into the current project conversation. Mark unknowns as undecided and replace examples as needed.
Confirmed · personalized content ready to copy
First check access to docs/feedback.md, docs/requirements.md. If missing or inaccessible, identify the prerequisite and owner action, then stop rather than invent prior work.
Read feedback, requirements, current version and checks. Reproduce issues and separate defects, new requests and missing evidence. Label uncertain causes. Write docs/repair-plan.md with issue IDs, impact, minimal scope, passing checks, regression checks and recovery. Explain scope or design changes before acting. Plan only; do not modify business code.
I selected the full-stack journal practice.
Diagnose this issue read-only. From my URL, input, clicks, expected/actual results and error text, separate facts from missing evidence. Check whether the page sent a request, whether it reached the right backend, the response status/error, and the actual database path and matching record. Inspect logs you can access; for manual collection give exact entry and relevant lines, removing secrets. Do not make me guess the technical cause. Propose the smallest plan with issue ID, cause evidence, files, data impact, backup/recovery, original-case retest and working behavior to recheck. With insufficient evidence request one minimal check. Do not fix, reset or reinstall before my confirmation.08Check this before continuing
Every fix maps to a feedback ID and repeatable passing conditions.
09What should you do if the expected result is missing?
OpenClose
Investigate further rather than defaulting to reinstalling or deleting storage.
Compare with an example (illustration, not your result)
F01: restore capacity on cancellation; reproduce and retest; regress booking and repeated cancel; no styling changes.
0303Fix according to plan and hand back for retestingTo checkOpen this stepClose this step
01What do you need, and what should you keep?
Your approved repair plan and the original failing actions.
Issue status matches your result.
Which files should AI read and save in this step?
In your tool’s project chat, ask it to open the files below. If a file is missing, follow the link back to the step that creates it.
Ask AI to read these materials first: docs/repair-plan.md · docs/feedback.md
Ask AI to save the result to: docs/checks.md · docs/feedback.md
Missing these materials? Return to the step that creates them →
02What will this step help you do?
Fix the agreed issue, then repeat the original failing actions yourself.
Understand it, then judge for yourself
What does this concept mean?
Retesting checks the original issue; trying working features catches unintended damage.
How would you decide in a different situation?
If AI checks pass but the same action fails, what fact should be recorded next?
See a reference answer
Record the actual personal failure at the same revision/steps under the same issue ID.
Answer in your own words; if unsure, compare the explanation above and check it against your own project.
03What exactly should you do in this step?
OpenClose
Project chat and preview
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.
After reviewing the plan, fix one agreed issue.OpenClose
Suggested prompt:
Follow the approved docs/repair-plan.md for 【issue ID】. Preserve data, change only necessary files and report checks plus my retest steps.
Afterwards, you should see: The tool explains the change and retest.
Repeat the original failing actions, then check previously working features.OpenClose
Afterwards, you should see: The issue is fixed and normal behavior still works.
Save your personal retest results.OpenClose
Suggested prompt:
My retest result: 【fill in】. Update docs/checks.md and docs/feedback.md; close only personally verified issues and retain untested items.
Afterwards, you should see: Issue status matches your result.
Practice: personal journal (frontend + backend + database)
Use the same learning-journal project throughout this example. For your own project, compare applicable requirements without creating another project.
Apply one agreed fix, repeat the original failing action personally and check old records remain.
- What should you see after this step?
- The failure, normal create/read and existing data all pass.
- What should you do first if you get stuck?
- If everything was marked passed, restore untested statuses and separate AI checks from personal trials.
04Not sure how? Follow each action
OpenClose
After reviewing the plan, fix one agreed issue.
- What should you see after this action?
- The tool explains the change and retest.
- What should you do if that result is missing?
- Return to planning if the scope expands or a reset is proposed.
Repeat the original failing actions, then check previously working features.
- What should you see after this action?
- The issue is fixed and normal behavior still works.
- What should you do if that result is missing?
- Keep the same issue ID and add evidence if it still fails.
Save your personal retest results.
- What should you see after this action?
- Issue status matches your result.
- What should you do if that result is missing?
- Investigate any difference from the tool’s report.
05Words in this step
OpenClose
Regression testing ↗
Checks whether changes broke existing behavior.
After fixing one light, check the others.
Rollback ↗
Restores earlier software or configuration.
Restoring old equipment does not restore changed records.
06How should you handle a problem here?
OpenClose
The same action still fails after a claimed fix
- Where should you look to understand the problem?
- Verify the new version is open and retain the failed sequence.
- Follow these steps to resolve the problem
- Choose “Retest failed”, add version and actual results, and ask AI to reproduce and update the plan rather than recreate the project.
- Expected recovery
- Repeat the original action and obtain the expected result; keep unexecuted checks marked unverified.
Edit the template with actual material, confirm, then copy into the current project conversation. Mark unknowns as undecided and replace examples as needed.
Confirmed · personalized content ready to copy
I am at “Fix according to plan and hand back for retesting”. Expected: AI checks and personal retests are recorded separately; failures return to feedback.. Actual screen/error: [add here]. Inspect existing files first. Give one reversible action at a time, its location, and expected result. Do not recreate the project or delete existing work.07Material for this step (fill or copy)
OpenClose
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.
Edit the template with actual material, confirm, then copy into the current project conversation. Mark unknowns as undecided and replace examples as needed.
Confirmed · personalized content ready to copy
First check access to docs/repair-plan.md, docs/feedback.md. If missing or inaccessible, identify the prerequisite and owner action, then stop rather than invent prior work.
Read rules and docs/repair-plan.md. Fix only approved issues and preserve existing work. Rerun failures and related normal flows. Record IDs, version, expected/actual results and unexecuted checks in docs/checks.md. Provide a real preview and personal retest steps. Never mark personal tests passed on my behalf. Save a traceable version; do not publish.Journal practice: fill or supplement this step
For this full-stack practice only: use this combined prompt, fill its fields and send it once instead of also sending the generic template. It does not authorize later steps.
Edit the template with actual material, confirm, then copy into the current project conversation. Mark unknowns as undecided and replace examples as needed.
Confirmed · personalized content ready to copy
First check access to docs/repair-plan.md, docs/feedback.md. If missing or inaccessible, identify the prerequisite and owner action, then stop rather than invent prior work.
Read rules and docs/repair-plan.md. Fix only approved issues and preserve existing work. Rerun failures and related normal flows. Record IDs, version, expected/actual results and unexecuted checks in docs/checks.md. Provide a real preview and personal retest steps. Never mark personal tests passed on my behalf. Save a traceable version; do not publish.
I selected the full-stack journal practice.
Fix only agreed issues; test database changes on a copy first with recovery instructions. Record the same failing case before/after plus old-record reads, without claiming user acceptance.08Check this before continuing
AI checks and personal retests are recorded separately; failures return to feedback.
09What should you do if the expected result is missing?
OpenClose
Return to planning if the scope expands or a reset is proposed.
Compare with an example (illustration, not your result)
F01 / revision def / original case passed / booking regression passed / personally retested → close F01.
Record this check and project version
This is self-reported, not automatic inspection. Old checks do not prove a changed version; complete or report failed and untested work.
Words in this milestoneIn order of appearance; open for the full explanation
More troubleshooting references
Stuck? Start with what actually happens
2 situationsThese paths synthesize official docs and public reports, not frequency data. Check the symptom and verify the result.
Opening a page is mistaken for a passed test
Observed symptom: No submit, refresh, login, or access check has been performed.
- What should you check first?
Compare tests with requirements, not screenshots.
- Then resolve
Run the main workflow, invalid and empty input, failure recovery, and a second test account. Record expected and actual outcomes with evidence.
- Verify the result
Results distinguish passed, failed, and untested; screenshots do not replace operations.
Edit the template with actual material, confirm, then copy into the current project conversation. Mark unknowns as undecided and replace examples as needed.
Confirmed · personalized content ready to copy
I am blocked at: Opening a page is mistaken for a passed test.
Project and tool: [name, version, and project path]
Observed behavior: [steps, exact error, or screenshot; remove secrets and personal data]
Expected result: [actual goal]
First inspect: Compare tests with requirements, not screenshots.
Proposed approach: Run the main workflow, invalid and empty input, failure recovery, and a second test account. Record expected and actual outcomes with evidence.
Explain the evidence and cause before making the smallest relevant fix. Preserve existing changes and do not add features. If I must act, give one precise action at a time and its expected visible result.
Success criteria: Results distinguish passed, failed, and untested; screenshots do not replace operations.
Report actual checks, unchecked items, and the next step.ReferencesPlaywright · Testing best practices ↗
“It does not work” cannot be reproduced
Observed symptom: Repairs rely on guesses and different observed states.
- What should you check first?
Record device, URL, exact steps, actual result, and expected result.
- Then resolve
Retry from a known test state, attach error or screenshot with sensitive data removed, and report one issue with repeatability.
- Verify the result
Another person can reproduce the same behavior from the report.
Edit the template with actual material, confirm, then copy into the current project conversation. Mark unknowns as undecided and replace examples as needed.
Confirmed · personalized content ready to copy
I am blocked at: “It does not work” cannot be reproduced.
Project and tool: [name, version, and project path]
Observed behavior: [steps, exact error, or screenshot; remove secrets and personal data]
Expected result: [actual goal]
First inspect: Record device, URL, exact steps, actual result, and expected result.
Proposed approach: Retry from a known test state, attach error or screenshot with sensitive data removed, and report one issue with repeatability.
Explain the evidence and cause before making the smallest relevant fix. Preserve existing changes and do not add features. If I must act, give one precise action at a time and its expected visible result.
Success criteria: Another person can reproduce the same behavior from the report.
Report actual checks, unchecked items, and the next step.ReferencesLovable · Project chat and debugging ↗
Stuck? Start with what actually happens
2 situationsThese paths synthesize official docs and public reports, not frequency data. Check the symptom and verify the result.
AI reports completion but the owner cannot use it
Observed symptom: Checks pass while the real task remains difficult.
- What should you check first?
Choose a real task and have the owner operate without reading code.
- Then resolve
Walk from entry to result, record confusion and detours, and fix blockers before polish. Test counts do not replace acceptance.
- Verify the result
The owner completes the main task and identifies remaining requirements.
Edit the template with actual material, confirm, then copy into the current project conversation. Mark unknowns as undecided and replace examples as needed.
Confirmed · personalized content ready to copy
I am blocked at: AI reports completion but the owner cannot use it.
Project and tool: [name, version, and project path]
Observed behavior: [steps, exact error, or screenshot; remove secrets and personal data]
Expected result: [actual goal]
First inspect: Choose a real task and have the owner operate without reading code.
Proposed approach: Walk from entry to result, record confusion and detours, and fix blockers before polish. Test counts do not replace acceptance.
Explain the evidence and cause before making the smallest relevant fix. Preserve existing changes and do not add features. If I must act, give one precise action at a time and its expected visible result.
Success criteria: The owner completes the main task and identifies remaining requirements.
Report actual checks, unchecked items, and the next step.ReferencesMDN · Plan a first website ↗Playwright · Testing best practices ↗
Demo data works but real material fails
Observed symptom: Long text, real images, or larger lists break the demo.
- What should you check first?
Compare real and demo lengths, formats, volumes, and missing values.
- Then resolve
Accept using redacted real material; check long text, missing images, empty lists, and phone width.
- Verify the result
Representative material works, with remaining coverage gaps listed.
Edit the template with actual material, confirm, then copy into the current project conversation. Mark unknowns as undecided and replace examples as needed.
Confirmed · personalized content ready to copy
I am blocked at: Demo data works but real material fails.
Project and tool: [name, version, and project path]
Observed behavior: [steps, exact error, or screenshot; remove secrets and personal data]
Expected result: [actual goal]
First inspect: Compare real and demo lengths, formats, volumes, and missing values.
Proposed approach: Accept using redacted real material; check long text, missing images, empty lists, and phone width.
Explain the evidence and cause before making the smallest relevant fix. Preserve existing changes and do not add features. If I must act, give one precise action at a time and its expected visible result.
Success criteria: Representative material works, with remaining coverage gaps listed.
Report actual checks, unchecked items, and the next step.ReferencesMDN · Common web layouts ↗Playwright · Testing best practices ↗
References for this milestone
Open these when the question arises; they are not extra required actions.
- How can success or failure be verified?
When a feature can be used or a repair needs retesting.
My project material and backups
Material stays in this browser, not in project files or AI chat. Chinese and English template drafts are separate; project selection and progress are shared. Do not enter passwords or API keys here.
Includes idea, progress, template drafts, personal checks and selection conditions, but not project code. Restore creates a new draft and preserves existing projects.
Download/import unavailable? Restore backup text
Draft and progress stay in this browser.
Complete the actions in order; expand the matching checks and remedies if you get stuck.