Skip to main content

Documentation Index

Fetch the complete documentation index at: https://fabricate.build/docs/llms.txt

Use this file to discover all available pages before exploring further.

Errors are a normal part of building. The good news: Fabricate can read its own errors and fix them. This page explains the Fix with Fabricate flow and catalogs the errors you’re most likely to see.

​
The Fix with Fabricate flow

When your running app hits an error in the live preview, Fabricate can read that error and resolve it.
1

An error appears in the preview

The running app throws a runtime error instead of rendering.
2

Click Fix with Fabricate

A Fix with Fabricate option appears alongside the error.
3

Fabricate reads the error

It sees the error message, stack trace, and current code — the full context needed to diagnose it.
4

The fix is applied

Fabricate generates a fix and the preview refreshes. If the first fix doesn’t fully resolve it, describe what you still see.
Fix with Fabricate handles runtime errors — errors in the app while it runs. For a result that’s wrong but not technically erroring, just describe what’s off in a follow-up message.

​
Build errors

Errors that surface while Fabricate is generating code.
Fabricate usually detects a failed step and retries or corrects it on its own. If a build ends incomplete, send a short follow-up — “the last change didn’t finish, please complete it” — so it can pick up where it left off.
Generated apps use TypeScript, so a type mismatch can occasionally appear. Fabricate sees these and typically fixes them automatically. If one lingers, point at it: “There’s a type error on the tasks page — fix it.”
The build completed, but part of your request wasn’t covered. Reply naming the gap: “The build finished, but the delete button isn’t on the task cards yet — please add it.”

​
Runtime errors

Errors that appear in the live preview while the app runs. These are what Fix with Fabricate is built for.
A blank preview usually means a JavaScript error stopped the app from rendering. Use Fix with Fabricate, or describe it: “The home page renders blank — find the error and fix it.”
The app tried to use data that wasn’t loaded yet or doesn’t exist. Fabricate fixes this by handling the loading and empty states. Use Fix with Fabricate, or say “Add proper loading and empty-state handling to the page that’s erroring.”
A page request to the backend is failing — often a route, query, or auth issue. Describe it: “The projects list shows an error instead of loading — check the API route and fix it.” Fabricate can trace the request from frontend to API to database.
A handler may be missing or wired up wrong. Be specific: “The Save button on the task form doesn’t do anything when clicked — make it save the task and close the dialog.”
Generated apps include built-in JWT authentication. If a flow misbehaves, describe the exact behavior: “After I sign up I’m not logged in automatically — fix it so signup logs the user straight in.”
If the app renders but looks plain or misaligned, a styling issue slipped in. Screenshot it from the preview and attach it — see Working with Images — then ask Fabricate to fix the affected page.

​
Getting the best fix

1

Use Fix with Fabricate for runtime errors

It’s the fastest path — Fabricate already has the error and code in context.
2

Describe behavior precisely for everything else

Say what you did, what you expected, and what happened instead.
3

Attach a screenshot when it's visual

A picture from the preview removes any guesswork.
4

Revert if a fix makes things worse

Roll back with version history and try a clearer prompt.
If the same error keeps coming back, the underlying request may be ambiguous. Switch to Discuss Mode, talk through the right approach, then build it — see Prompting Best Practices.

Troubleshooting

Solutions for non-error issues like stuck builds.

Build Mode

Understand how changes and fixes are generated.