Vibe GuideDeliver and check the real entry
Check the local entry for local use or the real URL for a public site.
Why this milestone?
Try the actual user entry to check that the delivered version works.
Start here1 step · Follow in order
0101Approve delivery and verify the real entryTo checkOpen this stepClose this step
01What do you need, and what should you keep?
The prepared installer, local launch entry or real website URL.
Users can follow accurate instructions.
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/release.md · docs/delivery.md
Ask AI to save the result to: docs/release.md
Missing these materials? Return to the step that creates them →
02What will this step help you do?
Try the actual user entry to check that the delivered version works.
Understand it, then judge for yourself
What does this concept mean?
Check the local entry for local use or the real URL for a public site.
How would you decide in a different situation?
Can another device or identity finish the same task, and which limits should users know?
See a reference answer
Test promised devices, roles and channels; disclose requirements and limits without presenting untested support as verified.
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 production URL or target device
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.
Confirm the real destination. For local use check startup; for publication review account, URL, costs and impact.OpenClose
Suggested prompt:
Read docs/release.md and docs/delivery.md. List the proposed delivery actions, destination and costs; wait for my explicit confirmation.
Afterwards, you should see: You can understand and approve the action.
After approval, execute and open the intended user entry.OpenClose
Suggested prompt:
I approve these actions: 【fill in】. Execute only these and report the actual entry and revision. Mark pending reviews honestly.
Afterwards, you should see: A real entry exists or its pending review is clear.
Try the main task and reopen it, then record your result.OpenClose
Suggested prompt:
My actual use result: 【fill in】. Save it to docs/release.md and update README.md with the latest entry/instructions.
Afterwards, you should see: Users can follow accurate instructions.
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.
Open the delivered entry, create “Delivery check” and read it after restart rather than relying on a cached page.
- What should you see after this step?
- The delivered revision works with a documented database path and usage scope.
- What should you do first if you get stuck?
- Check the service if opening fails; retain pending status instead of equating prepared files with successful delivery.
04Not sure how? Follow each action
OpenClose
Confirm the real destination. For local use check startup; for publication review account, URL, costs and impact.
- What should you see after this action?
- You can understand and approve the action.
- What should you do if that result is missing?
- Clarify unknowns before approval.
After approval, execute and open the intended user entry.
- What should you see after this action?
- A real entry exists or its pending review is clear.
- What should you do if that result is missing?
- Do not invent a public URL for local use; test public access as an ordinary user.
Try the main task and reopen it, then record your result.
- What should you see after this action?
- Users can follow accurate instructions.
- What should you do if that result is missing?
- Contain failures and use the planned recovery without blindly overwriting storage.
05Words in this step
OpenClose
Deploy ↗
Places software and configuration in a target environment.
Install equipment at the operating site.
Rollback ↗
Restores earlier software or configuration.
Restoring old equipment does not restore changed records.
06How should you handle a problem here?
OpenClose
It opens locally but not for others
- Where should you look to understand the problem?
- Check for localhost, 127.0.0.1 or a private preview URL.
- Follow these steps to resolve the problem
- Read the real entry from the platform, check access and deployment state, and retest as the intended visitor. A local address is not a public release.
- 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 “Approve delivery and verify the real entry”. Expected: The actual entry works; pending or failed delivery is not reported as successful release.. 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/release.md, docs/delivery.md. If missing or inaccessible, identify the prerequisite and owner action, then stop rather than invent prior work.
Confirmed delivery target, version and allowed actions: [fill in; without authorization only review readiness]
Check docs/release.md and this authorization; perform only explicitly allowed delivery actions. Test the required core flow and applicable data/access conditions through the real entry. Record target, revision, actual results and unverified items in docs/release.md. Record failures and use only an already authorized recovery plan. Do not add features or begin a new iteration; maintenance handoff is next.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/release.md, docs/delivery.md. If missing or inaccessible, identify the prerequisite and owner action, then stop rather than invent prior work.
Confirmed delivery target, version and allowed actions: [fill in; without authorization only review readiness]
Check docs/release.md and this authorization; perform only explicitly allowed delivery actions. Test the required core flow and applicable data/access conditions through the real entry. Record target, revision, actual results and unverified items in docs/release.md. Record failures and use only an already authorized recovery plan. Do not add features or begin a new iteration; maintenance handoff is next.
I selected the full-stack journal practice.
Perform only authorized local delivery; verify requests reach its backend/database and record revision/entry/ID. Do not expose publicly without authorization.
Local delivery does not require a public URL. Save the actual entry and my results in docs/release.md. Public delivery requires account, cost, impact and explicit permission; otherwise record not published and do not invent online acceptance.08Check this before continuing
The actual entry works; pending or failed delivery is not reported as successful release.
09What should you do if the expected result is missing?
OpenClose
Clarify unknowns before approval.
Compare with an example (illustration, not your result)
Reachable URL but broken login callback: fail. Store review pending: pending. Full ordinary-user flow passes: checked.
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
References for this milestone
Open these when the question arises; they are not extra required actions.
- Is delivery ready, and in what form?
After acceptance, before real users receive the project.
- 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.