Workflow
Drive the project from chat
The chat panel is where each meaningful iteration starts.
Keep the same thread when the project direction is still valid
Follow-up prompts preserve the current context, files, and runtime instead of fragmenting the work across fresh sessions.
Attach files when the prompt depends on concrete input
Flutty surfaces attached files directly under your prompt bubble so the run history still explains what the agent saw.
Use the composer as the next-action field
Ask for one coherent change, then verify it in `Website`, `Code`, or `Database` before stacking more requests.
Inspection
Read generation output as operations, not only prose
The most important output in chat is often structural, not just textual.
File-operation cards show what the run touched
Read them first when you want to know which files changed without opening the editor yet.
Background-command cards expose longer runtime work
These cards help you distinguish agent reasoning from shell work that is still running or has already failed.
Delegated-worker cards show side work that is still running
Expand them to inspect worker status, tail logs, or stop/kill a worker when the run exposes those controls.
File links connect chat back into `Code`
When a card references a file, Flutty can take you directly to the implementation you need to inspect.
Status lines explain whether the run is queued, thinking, streaming, complete, or canceled
This keeps progress explicit instead of leaving you to guess from silence.
Streaming
Understand how updates arrive
Chat can look like one stream, but there are two important delivery paths.
New queued runs return through project events
After a prompt is accepted, the project waits for `/api/agent-events` so the browser can receive queued run output, worker updates, preview events, and terminal state as they are persisted or fanned out.
Session resume replays directly
When a page refresh resumes an existing session, Flutty reads the saved runtime session file and replays the conversation through a direct response stream.
Use the visible state as the source of truth
`queued`, `streaming`, `complete`, `canceled`, and worker statuses describe where the run is in the current delivery path.
Windows
Work with multiple generation windows intentionally
Flutty keeps generation history as windows, not as one endless undifferentiated transcript.
- 01
Treat each prompt as a bounded work window
A window keeps the user request, attached files, generated messages, and operation history together.
- 02
Use the latest active window for the current task
This makes it easier to separate the newest run from older attempts.
- 03
Do not panic when a window is canceled or stalled
The workspace still preserves the prior windows so you can compare attempts instead of losing the trail.
- 04
Continue from the existing workspace whenever possible
New windows are for new iterations inside the same project, not for throwing context away.
Controls
Use the chat header as workspace control
The top of the chat panel contains operational shortcuts that matter during active work.
Start preview from the header when you need the runtime to wake quickly
This is the fast path back into `Website`.
Use the GitHub connector from the same header
Repository creation, refresh, conflict resolution, and remote application stay attached to the project you are already editing.
Open documentation, support, theme, and language controls from the Flutty menu
Help and workspace preferences stay close to the active generation flow instead of living in disconnected settings pages.