Vibe GuideWhen a project stores or reads data, clarify its location and access rules here, then ask AI to implement them and verify the result.
Does this method fit your project, and how can you check?
- When would you use this method?
- When storage, shared data or an external service is needed.
- How should you choose for your situation?
- Display-only work may need no storage; personal local data can use local storage; shared data needs synchronization, identity and server-side access rules.
- What is easy to misunderstand?
- Local persistence is not backup or sync. Check external API allowance, costs and failures; keep secret credentials out of public pages and unrelated services.
- How can you check that this works for your project?
- Reopen after saving; test authorized devices/identities if shared; restore an exported copy. Also test external-service timeouts, quota exhaustion and invalid responses.
BACKEND
Backend: storage and access
The backend stores data, identifies people, and enforces access behind the interface. Content-only projects may not need one; shared reservations, cross-device access, and private data require explicit rules.
Connecting AI, payments or another API? Start here
First confirm the service is needed, then check official capability, account conditions, allowance and costs. Use a test environment and test data; confirm real payments or outbound messages separately.
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
Required capability: [fill in]
Service and official docs: [fill in]
Data to send: [fill in; no secrets]
Expected response: [fill in]
Budget and usage: [fill in or undecided]
Only assess inputs/outputs, credential placement, sandbox, timeout/failure/quota handling and duplicate requests. Propose a minimal test and passing criteria; ask about unknowns. Do not implement, pay, transact or send outward messages.Check same-browser storage first
- Write and save a sample record.
- Refresh, close, then reopen at the same address.
- Pass only if the record remains. A different browser or address is not a sync test.
Clearing browser data removes records. Ask AI for export and test recovery.
Saving failed or records disappeared →Storage and permission checks do not apply. Check displayed content, then return to the original step.
Data permissions and access rules: who can read, edit, or delete records.
Move forward using observed results
1. List what must persist
Ask AI to derive required fields from the actual flow, explaining purpose, requirement, and retention. For example, reservations may need an ID, date, and status; other projects need their own fields.
How can you tell this item is complete?Remove fields without a purpose. Keep sensitive data out of public pages and logs.
2. Define who can do what
Define what each actual role can read, create, update, and delete. Ask AI for an access matrix. For example, customers see their own reservations while an owner processes all reservations.
How can you tell this item is complete?Test two ordinary identities and an admin separately; hidden buttons are not an access check.
3. Connect saving and reading
Submit a test record, note its ID, reload or reopen, and retrieve it from another device with authorized access. Ask AI for actual write and read results.
How can you tell this item is complete?Success corresponds to a real record. Preserve input on failure and allow retry; repeated clicks should not accidentally duplicate records.
4. Prepare export and recovery
Have AI document storage location, export, deletion impact, and recovery. Restore a record using isolated test data.
How can you tell this item is complete?The export is readable and restored content and access rules are correct. Mark untested recovery as unverified.
Checks are personal marks on this page, not automatic tests or saved records. Reloading clears them.
Write check results
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: [fill in actual record or unverified]
Identity: [fill in actual record or unverified]
Test record ID: [fill in actual record or unverified]
Storage location: [fill in actual record or unverified]
Result after reload: [fill in actual record or unverified]
Access results by identity: [fill in actual record or unverified]
Export and recovery result: [fill in actual record or unverified]
Unverified items: [fill in actual record or unverified]Confirm and copy into project notes; the draft is stored in this browser. Mark unrun checks unverified, not passed.
Open troubleshooting
Choose the next step from the result
Data disappears after refresh
Can another device read it? Yes → inspect retrieval, identity, or cache on this device. No → inspect write success and storage location. Preserve test IDs and errors before concluding the database lost data.
A customer sees another person’s data
Stop exposing the affected feature and preserve evidence without sensitive content. Ask AI to inspect server access rules and retest with two identities; hiding a page does not replace server rejection.
Fill in the current situation to prepare a prompt for AI
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
What data should be stored or displayed: [fill in]
Who may create, view, edit or delete the data: [fill in]
Multi-device or shared use: [fill in]
What data must not be lost, and how far back must you be able to recover: [fill in]
Existing project and storage: [fill in or none]
Choose no persistence, local storage or a shared service only; do not create a database. Explain where access is enforced and how local persistence, sync and backup differ.
Explain your conclusions using these points: Storage/access table, required accounts/services, cost unknowns and applicable reopen/identity/restore tests; explain inapplicable tests.