Follow your Build from request to Preview

You ask Mythos to add a filter to an event listing. The useful outcome is a page where choosing a date changes the visible events, clearing the filter brings them back, and the layout still works on a phone.

The conversation explains the work along the way. Progress, screenshots and the final Preview let you inspect different parts of that result. They are most useful when you know what each one represents.

Start with a request that names the behavior you want. For the event listing, include what should happen when no event matches. That gives both the Build and your review a concrete target.

While a Build is running, its progress card shows the work in progress. When Mythos captures screenshots, they appear in a gallery you can revisit after reloading the conversation. A screenshot records what was visible at that point; you can use it to notice an incorrect heading or a cramped layout early.

The existing working Preview remains available while the next version is being prepared. This helps you compare the requested change with what you already had, instead of treating every intermediate view as the finished result.

Some work needs a decision from you. Mythos may ask a question, request a connection, or ask you to approve an external action. Read that request before continuing, particularly when the action changes information in another service.

Before delivering generated source, Mythos checks types, builds the project and attempts a browser check. The result can include details about what passed and what could not be verified. A browser check that could not run leaves a gap to inspect; it is not evidence that every interaction works.

Open the delivered result in Preview. For the event filter, choose a date with matches, try one without matches, and clear the selection. Then open an event and return to the listing. These few actions test the behavior your request actually depended on.

Use Details when you want to inspect more of the Build result. More actions on the assistant message also shows recorded credit usage and measured duration when available. A long-running operation and an expensive operation are not necessarily the same thing.

If the filter works but its selected state is hard to see, ask for that correction specifically. A focused follow-up gives you a small result to compare with the version you just reviewed.

If the Build pauses at its credit limit, review the budget card before choosing to raise the limit or stop. A saved working copy during a pause has not become a newly delivered version. The Build budget article explains that choice.

A delivered change becomes public when you update the published site. Open the public address afterward and repeat the event-filter journey there. See Building and editing for the controls, or the app testing guide for a broader review.