Build and test incrementally

The preview URL or HTML file AI provides

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.

1. Have the tool do the next unfinished task only.OpenClose

   Suggested prompt:

   Read tasks/todo.md and identify the next task whose prerequisites are ready. Explain and complete only that task. Preserve other files and report how to open and test it.

   Afterwards, you should see: You receive a change summary and working entry.

2. Open the project and try this feature yourself.OpenClose

   Afterwards, you should see: The result matches the task or you can name the difference.

3. Report what happened before continuing.OpenClose

   Suggested prompt:

   My actions and results: 【fill in】. Update tasks/todo.md and docs/checks.md; complete only checked tasks. Save the confirmed changes as a local revision without pushing.

   Afterwards, you should see: Task status reflects actual progress.

1. Have the tool do the next unfinished task only.

   What should you see after this action?

   You receive a change summary and working entry.

   What should you do if that result is missing?

   If unrelated work was added, review it and return to the agreed task.

2. Open the project and try this feature yourself.

   What should you see after this action?

   The result matches the task or you can name the difference.

   What should you do if that result is missing?

   Report the URL and error if it will not open; keep unavailable tests pending.

3. Report what happened before continuing.

   What should you see after this action?

   Task status reflects actual progress.

   What should you do if that result is missing?

   Record failures and follow the feedback/repair steps.

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.

First check access to docs/requirements.md, docs/stories.md, docs/design.md, tasks/todo.md, README.md. If missing or inaccessible, identify the prerequisite and owner action, then stop rather than invent prior work.
Read project rules, requirements, design and tasks/todo.md. Reuse the verified runtime and implement only the first unfinished development task. Ask if unclear or too broad to check here. Execute that task’s checks, give the real preview entry and instructions, and update its status. Do not reinitialize, execute later tasks or publish. Record requirement/task IDs, actual checks and untested work in docs/checks.md. Mark awaiting personal review first; mark passed only after the user reports success, then save only this task’s local revision and safe recovery instructions while preserving unrelated work.

First check access to docs/requirements.md, docs/stories.md, docs/design.md, tasks/todo.md, README.md. If missing or inaccessible, identify the prerequisite and owner action, then stop rather than invent prior work.
Read project rules, requirements, design and tasks/todo.md. Reuse the verified runtime and implement only the first unfinished development task. Ask if unclear or too broad to check here. Execute that task’s checks, give the real preview entry and instructions, and update its status. Do not reinitialize, execute later tasks or publish. Record requirement/task IDs, actual checks and untested work in docs/checks.md. Mark awaiting personal review first; mark passed only after the user reports success, then save only this task’s local revision and safe recovery instructions while preserving unrelated work.

I selected the full-stack journal practice.
Implement only the planned page task, make disconnected saving clearly unavailable and avoid localStorage or fake success. Return the real HTTP entry; leave backend tasks to save.

If unrelated work was added, review it and return to the agreed task.

T01 entry checked; T02 booking pending; T03 cancel pending → full acceptance is not yet possible.

The preview and project conversation

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.

1. Open your project and locate one confusing place, such as an unlabeled field or overlapping button.OpenClose

   Afterwards, you should see: You can name the page and location to change.

2. Tell the tool the problem and desired result.OpenClose

   Suggested prompt:

   Change only 【page/location】. It currently looks like 【actual】; I need 【specific result】. Preserve other pages/features and give me the review URL.

   Afterwards, you should see: The updated page opens.

3. Try the feature again and narrow the window to check text, fields and buttons.OpenClose

   Afterwards, you should see: The page is usable and the original feature still works.

1. Open your project and locate one confusing place, such as an unlabeled field or overlapping button.

   What should you see after this action?

   You can name the page and location to change.

   What should you do if that result is missing?

   Fix a specific usability problem rather than requesting a complete redesign.

2. Tell the tool the problem and desired result.

   What should you see after this action?

   The updated page opens.

   What should you do if that result is missing?

   Describe the remaining difference and keep the fix focused.

3. Try the feature again and narrow the window to check text, fields and buttons.

   What should you see after this action?

   The page is usable and the original feature still works.

   What should you do if that result is missing?

   Record any overlap or failed click and request a focused repair.

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.

First check access to docs/design.md, tasks/todo.md. If missing or inaccessible, identify the prerequisite and owner action, then stop rather than invent prior work.
Page and location: [fill in]
What happens here now, and what does not meet your needs: [fill in]
Desired change: [concrete result]
Change only this interface location, following the agreed design and preserving unrelated features and data logic. Provide a preview and check both the requested result and affected existing actions. Report actual results.

First check access to docs/design.md, tasks/todo.md. If missing or inaccessible, identify the prerequisite and owner action, then stop rather than invent prior work.
Page and location: [fill in]
What happens here now, and what does not meet your needs: [fill in]
Desired change: [concrete result]
Change only this interface location, following the agreed design and preserving unrelated features and data logic. Provide a preview and check both the requested result and affected existing actions. Report actual results.

I selected the full-stack journal practice.
Check or adjust labels, layout and status messages only, preserving fields and API agreement; do not claim working persistence before connection.

Fix a specific usability problem rather than requesting a complete redesign.

Location: event booking button. Prevent repeat submission while loading; explain errors and allow retry; show the real result.

The project field, Save button, and history

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.

1. Prepare real storage. A database keeps records after the page closes. If no storage is needed, skip this step. For browser-only storage, follow that design without adding a backend or database. Database actions apply only when the design requires one.OpenClose

   Suggested prompt:

   Read the requirements and inspect storage. If a database is needed, inspect existing content, create only missing tables and report its location and record fields. Do not erase data.

   Afterwards, you should see: You know where records live and what they contain.

2. If your design uses a backend: Make the backend save and read records. It is the program processing page requests.OpenClose

   Suggested prompt:

   Implement or inspect save-one and read-list endpoints. Test a record, report its ID and verify the matching database record. Reject blank input.

   Afterwards, you should see: A valid record has a matching database ID; blank input is not inserted.

3. If your design uses a backend: Connect the page’s Save button to the checked backend.OpenClose

   Suggested prompt:

   Connect Save to the checked backend. Prevent repeat pending clicks, keep input on failure and show success only after saving. Give me the test URL.

   Afterwards, you should see: One save produces a record you can find in the list.

4. Save a recognizable test entry such as “save test 001”, refresh and reopen the page to find it. Use another browser only if the design calls for shared backend data; check browser-only data in the original browser.OpenClose

   Afterwards, you should see: The entry remains in the storage location promised by the design, with its original content.

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.

Follow section 03 above: prepare storage, check the backend, connect the page, then reopen and read the record. Review each result before sending the next task to your chosen tool.

What should you see after this step?

Saving “Practice A” produces a real record ID readable from a second browser on the same service.

What should you do first if you get stuck?

A new row on screen is insufficient; verify the same ID in the actual SQLite file without clearing/recreating it.

Match an error to the next action

Save returns 404 or HTML

What should you check first?

Check whether /api/entries reaches the running Flask service.

Follow these steps to resolve the problem

Give Codex the actual URL, request path and service log to compare routes; this example serves page and API together.

What should you see after the problem is resolved?

GET returns a list; a valid POST returns a record ID.

CORS / cross-origin error

What should you check first?

Check whether the page came from file:// or another port.

Follow these steps to resolve the problem

Use the Flask HTTP URL and relative /api/entries. Do not disable browser security; separate-service projects need approved origins in their design.

What should you see after the problem is resolved?

The same-service request is no longer blocked.

no such table: entries

What should you check first?

An existing database file may lack its table; check its full path first.

Follow these steps to resolve the problem

Run the agreed non-destructive setup on the correct file; do not delete the database or copy table-dropping examples.

What should you see after the problem is resolved?

entries exists and old data is retained.

database is locked

What should you check first?

Check for another test service, editor or unfinished write holding the file.

Follow these steps to resolve the problem

Stop only a confirmed practice owner and inspect transaction/connection cleanup; do not delete lock files or the database.

What should you see after the problem is resolved?

Writing recovers while old records remain readable.

Success appears, but refresh loses the record

What should you check first?

Record a unique title, URL and ID; check whether only the page or browser cache was updated.

Follow these steps to resolve the problem

Read-only compare save response, database record and list response to locate the loss. Show success only after real backend persistence.

What should you see after the problem is resolved?

Database, read endpoint and refreshed page show the same test record.

The URL refuses the connection

What should you check first?

Compare the URL with this project’s startup output and check that the service is running. A port is the service number after the colon.

Follow these steps to resolve the problem

Give the URL and recent startup error to the tool. Start this project as documented; for an occupied port identify its owner, choose a free port and update the URL rather than stopping unknown processes.

What should you see after the problem is resolved?

The service remains running and its actual URL opens the page; then check saving.

Save reports failure, but the record exists

What should you check first?

The server may have saved before the response was lost; search the unique title in the list and database.

Follow these steps to resolve the problem

Do not submit again yet. Give the existing ID and error to the tool; inspect response handling and repeat-submission protection. Compare IDs and content rather than deleting matching titles.

What should you see after the problem is resolved?

The submission outcome is established, feedback is accurate and old records remain.

1. Table: report full database path, entries and fields; startup must preserve records.
2. API: GET reads, POST submits. Test saving and its returned ID, then rejection of spaces-only input.
3. Connect: Save sends to /api/entries on the same service. Show success only after persistence; retain input on failure.
4. Read back: open the running URL in another browser and find the same ID. Codex checks the database read-only; you need not learn SQL first.

Flask installation · SQLite integration

1. Prepare real storage. A database keeps records after the page closes. If no storage is needed, skip this step. For browser-only storage, follow that design without adding a backend or database. Database actions apply only when the design requires one.

   What should you see after this action?

   You know where records live and what they contain.

   What should you do if that result is missing?

   Ask for the actual location/table if the response only says done.

2. If your design uses a backend: Make the backend save and read records. It is the program processing page requests.

   What should you see after this action?

   A valid record has a matching database ID; blank input is not inserted.

   What should you do if that result is missing?

   Keep the error and check whether the request reached the backend.

3. If your design uses a backend: Connect the page’s Save button to the checked backend.

   What should you see after this action?

   One save produces a record you can find in the list.

   What should you do if that result is missing?

   Match its ID to the database rather than trusting an extra on-screen row.

4. Save a recognizable test entry such as “save test 001”, refresh and reopen the page to find it. Use another browser only if the design calls for shared backend data; check browser-only data in the original browser.

   What should you see after this action?

   The entry remains in the storage location promised by the design, with its original content.

   What should you do if that result is missing?

   Check URL, account and storage location without deleting data.

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.

First check access to docs/requirements.md, docs/design.md, tasks/todo.md. If missing or inaccessible, identify the prerequisite and owner action, then stop rather than invent prior work.
Read requirements and design to confirm whether persistent storage is required. If not, mark this step not applicable and stop without adding it. Otherwise implement only agreed saving and reading, using required inputs and access rules. Do not add history, login or cloud services without a requirement. Use disposable test data to check saving, reopening and applicable failures. Report actual and unverified results.

First check access to docs/requirements.md, docs/design.md, tasks/todo.md. If missing or inaccessible, identify the prerequisite and owner action, then stop rather than invent prior work.
Read requirements and design to confirm whether persistent storage is required. If not, mark this step not applicable and stop without adding it. Otherwise implement only agreed saving and reading, using required inputs and access rules. Do not add history, login or cloud services without a requirement. Use disposable test data to check saving, reopening and applicable failures. Report actual and unverified results.

I selected the full-stack journal practice.
This is the personal local learning journal example. Inspect existing files and preserve finished work. Explain where the page, backend and database are. Perform only one item at a time, report evidence and wait for my review:
1. Database: use SQLite; resolve instance/journal.sqlite to a stable full path independent of startup directory. Inspect existing records and explain backup. Prepare entries non-destructively with id, title, body and created_at.
2. Backend: GET /api/entries reads the list; POST saves a record. Validate trimmed content and agreed length limits on the backend, use parameterized SQL and return success only after commit. Report a unique test item’s response and ID, then read the matching database record. Blank requests must not insert.
3. Page: use relative /api/entries on the same service, check HTTP status, prevent pending repeat clicks and retain input with an explanation on failure. Give exact startup, URL, input and click instructions, not only code.
4. Read back: guide me through a second browser on the same URL, then restart only this project service and check old records. Record actual and untested results without claiming my acceptance.
For uncertain outcomes, query before retrying to avoid duplicates. Do not delete storage, drop tables, disable browser security or add unrequested login features.

Ask for the actual location/table if the response only says done.

Two users claim the last place: exactly one succeeds; repeats do not reserve additional places.

The actual 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.

1. Ask for a checklist from opening the project to finishing a task.OpenClose

   Suggested prompt:

   Read requirements and tasks/todo.md. Write one ordinary-user journey, one action at a time, with inputs, clicks and expected results. Mark unfinished prerequisites.

   Afterwards, you should see: You have a usable checklist.

2. Open the project and follow each action, recording what you actually see.OpenClose

   Afterwards, you should see: You finish the flow or can identify the exact stopping point.

3. Save your record and cover the remaining required journeys.OpenClose

   Suggested prompt:

   Save my test record to docs/checks.md: 【actions, expected, actual】. Separate passed, failed and untested checks; do not invent passes.

   Afterwards, you should see: Every required journey has an honest 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.

Enter “Practice B”, save once, inspect status/list, then refresh and read the same ID in another browser.

What should you see after this step?

Page, API and database agree on ID and content.

What should you do first if you get stuck?

Record the failing layer: button, request, write or read. Send it to feedback without changing code during testing.

1. Ask for a checklist from opening the project to finishing a task.

   What should you see after this action?

   You have a usable checklist.

   What should you do if that result is missing?

   Prepare any missing account or page before continuing.

2. Open the project and follow each action, recording what you actually see.

   What should you see after this action?

   You finish the flow or can identify the exact stopping point.

   What should you do if that result is missing?

   Stop on failure and keep input, URL and error.

3. Save your record and cover the remaining required journeys.

   What should you see after this action?

   Every required journey has an honest result.

   What should you do if that result is missing?

   Report failures and repeat the same journey after repair.

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.

First check access to docs/requirements.md, tasks/todo.md. If missing or inaccessible, identify the prerequisite and owner action, then stop rather than invent prior work.
Read one confirmed core flow in docs/requirements.md and execute its entry, actions and results in order. Record expected and actual results, evidence and passed/failed/not-run status in docs/checks.md. Explain inaccessible actions and how the user can perform them. Only check the flow; do not change code or add features. Before testing, list applicable test accounts/disposable data and setup entries; start with one flow, then cover other required flows.

First check access to docs/requirements.md, tasks/todo.md. If missing or inaccessible, identify the prerequisite and owner action, then stop rather than invent prior work.
Read one confirmed core flow in docs/requirements.md and execute its entry, actions and results in order. Record expected and actual results, evidence and passed/failed/not-run status in docs/checks.md. Explain inaccessible actions and how the user can perform them. Only check the flow; do not change code or add features. Before testing, list applicable test accounts/disposable data and setup entries; start with one flow, then cover other required flows.

I selected the full-stack journal practice.
Verify one unique record through page→POST→database→GET→page. Record its ID and actual evidence for each layer; mark unobservable layers unverified.
Read requirements/tasks and confirm each layer is ready. Give the ordinary-user entry, unique input and stepwise expectations. Record my results in docs/checks.md only after I report them. Start with one route, then cover all required flows; send failures to feedback/planning without changes here.

Prepare any missing account or page before continuing.

R01 / revision abc / test name / expect confirmation and one fewer place / actual matches / evidence path / passed.