Vibe GuideReview release readiness
This checks preparation; an untried installer or site remains pending.
Why this milestone?
Before delivery, check for missing features, instructions and accounts.
Start here1 step · Follow in order
0101Assess readiness for deliveryTo checkOpen this stepClose this step
01What do you need, and what should you keep?
The chosen delivery method, trial results and instructions.
You know whether to repair or prepare delivery files next.
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/design.md · docs/checks.md · docs/acceptance.md · docs/delivery.md
Ask AI to save the result to: docs/release.md · docs/feedback.md
Missing these materials? Return to the step that creates them →
02What will this step help you do?
Before delivery, check for missing features, instructions and accounts.
Understand it, then judge for yourself
What does this concept mean?
This checks preparation; an untried installer or site remains pending.
How would you decide in a different situation?
Can an openable home page establish readiness if data disappears after signing in again?
See a reference answer
No. A working homepage proves little about required login and persistence; fix critical failures first.
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/release.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.
Check what is still missing before delivery.OpenClose
Suggested prompt:
Read requirements, docs/checks.md, docs/acceptance.md and docs/delivery.md. Check features, startup instructions, data, accounts and costs. List gaps without publishing.
Afterwards, you should see: Ready and missing items are clearly separated.
Save the checklist and repair blocking issues first.OpenClose
Suggested prompt:
Save readiness to docs/release.md and numbered issues to docs/feedback.md. Mark artifact/deployment trials pending until they actually run.
Afterwards, you should see: You know whether to repair or prepare delivery files next.
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.
Confirm save, read, failures and restart for this version; startup must not merely say open HTML.
- What should you see after this step?
- Checklist includes dependencies, startup, database location, backup and unverified items.
- What should you do first if you get stuck?
- Return to acceptance if its file is missing; do not auto-generate a pass.
04Not sure how? Follow each action
OpenClose
Check what is still missing before delivery.
- What should you see after this action?
- Ready and missing items are clearly separated.
- What should you do if that result is missing?
- Return to personal testing if its record is absent.
Save the checklist and repair blocking issues first.
- What should you see after this action?
- You know whether to repair or prepare delivery files next.
- What should you do if that result is missing?
- Do not pass checks that have not run.
05Words in this step
OpenClose
Release ↗
Packages approved changes as a distributable version.
Label a product batch with release notes.
Environment ↗
Hardware, software, configuration, and services used to run software.
The same recipe behaves differently with different equipment.
06How should you handle a problem here?
OpenClose
Readiness is claimed without evidence
- Where should you look to understand the problem?
- Look for actual checks, versions and results.
- Follow these steps to resolve the problem
- Mark unsupported items unverified. Complete checks or repairs for core flow, data and permissions instead of relabeling them passed.
- 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 “Assess readiness for delivery”. Expected: Readiness decisions distinguish verified conditions, gaps and permission to prepare delivery.. 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/design.md, docs/checks.md, docs/acceptance.md, docs/delivery.md. If missing or inaccessible, identify the prerequisite and owner action, then stop rather than invent prior work.
Read requirements, design, checks, docs/acceptance.md and docs/delivery.md and compare revisions. If personal acceptance or delivery decisions are missing, stop and point to “Test the full journey personally” and “Choose how to deliver” without inventing a pass. Assess preparation only, recording verified, unmet, inapplicable and unverified conditions with evidence in docs/release.md. Artifact trials remain pending “Prepare deployment or packaging”. Number blockers in docs/feedback.md for repair planning. Do not repair, package or release.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/design.md, docs/checks.md, docs/acceptance.md, docs/delivery.md. If missing or inaccessible, identify the prerequisite and owner action, then stop rather than invent prior work.
Read requirements, design, checks, docs/acceptance.md and docs/delivery.md and compare revisions. If personal acceptance or delivery decisions are missing, stop and point to “Test the full journey personally” and “Choose how to deliver” without inventing a pass. Assess preparation only, recording verified, unmet, inapplicable and unverified conditions with evidence in docs/release.md. Artifact trials remain pending “Prepare deployment or packaging”. Number blockers in docs/feedback.md for repair planning. Do not repair, package or release.
I selected the full-stack journal practice.
Assess local full-stack delivery: environment, pinned dependencies, non-destructive setup, fixed database path and recovery. GitHub Pages alone cannot host this backend.08Check this before continuing
Readiness decisions distinguish verified conditions, gaps and permission to prepare delivery.
09What should you do if the expected result is missing?
OpenClose
Return to personal testing if its record is absent.
Compare with an example (illustration, not your result)
Build prerequisites verified; device installation pending “Prepare deployment or packaging”; production release not executed.
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.
- How can success or failure be verified?
When a feature can be used or a repair needs retesting.
- Is delivery ready, and in what form?
After acceptance, before real users receive the project.
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.