Overview
Map the Generate surface
`Generate` is easiest to understand when you treat it as one working surface with two sides.
Chat side
Ask for the next change, attach files, review agent output, inspect file-operation cards, and keep the same project thread alive.
Workspace side
Verify the current state through preview, `Code`, `Database`, `Terminal`, and `Analytics` without leaving the project. Website projects use the browser preview; mobile app projects use a device preview surface.
Shared project context
The prompt, current files, preview URL, connector state, publish state, and workspace status all belong to the same project session.
Compact layout on smaller screens
Flutty switches between `Chat` and `Workspace` instead of showing both at once, but the project context stays the same.
Controls
Use the header controls intentionally
The top of `Generate` is more than navigation. It contains the operational controls that change project state.
Start preview
Wake or refresh the runtime when the next question is about real behavior in `Website`.
GitHub connector
Create, link, sync, pull, push, or resolve remote conflicts from the same project header instead of switching into a separate setup flow.
Download
Export the current project snapshot when you need a local copy outside the live workspace.
Publish or Go Live
Move website projects from a known-good preview into publish. For Flutter mobile app projects, use the mobile Go Live path for store setup and release runs.
Workspace status badge
Read the current runtime state before assuming preview, files, or terminal access are immediately available.
Decision guide
Choose the right surface for the next question
- 01
Use `Chat` when the next step is a product or implementation request
This is where new work starts.
- 02
Use preview when the question is behavioral
Browser layout and routes belong in `Website`; touch behavior and phone layout belong in the mobile device preview.
- 03
Use `Code` when the question is implementation detail
Open files only after chat or preview narrowed the investigation surface.
- 04
Use `Database` when the project needs backend data or auth inspection
This tab is connector-driven and can still be useful even when the runtime is not the main issue.
- 05
Use `Terminal` when you need runtime-level evidence
Commands, directories, and lower-level recovery belong here.
- 06
Use `Analytics` only after publish
This tab answers live-site questions, not preview questions.
Release
Follow the normal release loop
The most reliable projects follow the same sequence instead of mixing release and iteration randomly.
- 01
Prompt in `Chat`
Ask for one coherent change.
- 02
Check the result in `Website`
Validate the route that matters now.
- 03
Open `Code` only if behavior and implementation need confirmation
Use file-operation cards and file links to open the exact file.
- 04
Use `Database` or `Terminal` only when the project needs deeper validation
Keep those checks scoped to the current blocker.
- 05
Release from a stable preview
Use `Publish` for websites and mobile Go Live for Flutter mobile app projects. Do not treat release as the first real test.
- 06
Return to `Analytics` after a website is live
That is where traffic and request limits become meaningful.
Responsive behavior
Work cleanly in compact mode
`Chat` and `Workspace` become separate top-level surfaces on smaller screens.
Inside `Code`, compact mode splits `Files` and `Editor` so each stays readable.
File links from chat can take compact users directly into the editor when inspection is the next logical step.
The tabs keep the same responsibilities on small and large screens; only the layout changes.