Help CenterUse this guide after the first build is available. Review behavior before appearance, and request one coherent change at a time.
Before you begin
Wait for the current build to finish and keep the original product brief available. Know the primary user journey and the viewport sizes you need to verify.
Steps
1. Open Preview
Choose Preview to use the generated application. Complete the main workflow as a real user would, including navigation, forms, empty states, errors, and success states.
2. Check desktop and mobile behavior
Review the longest headings, buttons, menus, forms, tables, and interactive controls at narrow and wide widths. Confirm that text does not overlap, controls remain reachable, and the main action is clear.
3. Give precise feedback
Describe the page, element, current behavior, and desired result. For example: “On the project dashboard at mobile width, place the filters above the table and keep the primary action visible without horizontal scrolling.”
Avoid requests such as “make it nicer” without naming the problem. Focused feedback produces a more reviewable change.
4. Re-test after each meaningful change
Repeat the primary workflow and check nearby states after a revision. A visual change can affect layout, navigation, forms, or responsive behavior elsewhere.
5. Inspect Code when needed
Choose Code to review the file tree, source, and terminal output. Use this view when you need to confirm what changed, investigate an error, or understand the project structure.
Do not paste secrets into source files or project messages. Use the supported connection and secret controls for private configuration.
Expected result
The main user journey works in Preview, important responsive states have been checked, and any remaining issues are specific enough to review before publishing.
Status meanings
Building means a revision is still running. Ready means the preview can be tested. An error means the build or application needs attention; read the visible message and terminal output before retrying.
Usage credit impact
Model requests and repeated revisions can use credits. Group related feedback and verify each build before requesting another broad change.
Information stored or shared
Aivah Code can store project messages, files, generated source, preview details, and terminal output. A preview may contain test data entered during review.
Limits and permanent actions
Preview behavior and available code controls can vary by project. Removing generated files or replacing broad sections of code can be difficult to reverse, so make focused changes and retain an approved version before major revisions.
Common problems and recovery
- Preview is blank or stale: wait for the build to finish, refresh the preview, and check terminal output for a visible error.
- A change fixed one screen but broke another: describe both routes and ask for the shared layout or component to be corrected.
- Mobile content overflows: identify the exact viewport and element, then request stacking, wrapping, or a responsive layout.
- The code view shows an error: capture the error text and the action that caused it before requesting a fix.