Move from a website complaint to a reviewed file change.
Bring the actual selected source into the conversation, inspect a complete proposed replacement, then build and preview the change you chose to apply.
Internal workflow illustration · Not publicly available or an end-to-end qualification.
The starting point
A founder wants a small product page to explain its offer more clearly. They have a saved page file and a specific change in mind. They need a result they can inspect, not code that was written without seeing the file it must replace.
Asking an assistant to improve a website can produce generic advice or a fragment that does not fit the current source. Even plausible code leaves separate questions: was this the right file, was it actually applied, and did the rendered result improve?
What you bring
- One explicitly selected, saved HTML, CSS, JavaScript or MJS file from a Web Studio project.
- A specific request and the current complete file, within the supported 6 KB limit.
- The selected local or cloud processing route, with separate consent for cloud sharing.
What EVO needs to understand
EVO works with the selected file rather than assuming it has inspected the whole repository. It can prepare a complete replacement for review. Checking that candidate, applying it and testing the rendered page are separate steps with different evidence.
Working through it
Put the real source in context
Choose the project and saved file, then prepare the conversation without losing an existing draft. The assistant receives that selected source for this request. Other project files are not silently included as full content.
Examine the proposed replacement
Review a saved answer containing a complete proposed file and run the supported candidate checks. A changed source or a different selection makes an old review unsuitable for the new situation. These are file checks, not a claim that the UI has been visually tested.
Apply, build and inspect
Explicitly apply the reviewed change, then build a saved snapshot and open the local preview. Check the page at relevant sizes and interactions. Saving a file is not publication, and a successful build is not proof that the page now communicates the right message.
What you receive
- A complete proposed file attached to the original request.
- A review of the candidate and a recorded apply result when approved.
- A local build and preview for checking the resulting page.
When you come back
Return to the current project and select the next file or revision deliberately. The selected-file conversation does not automatically carry the whole repository, old screenshots or unrelated materials into subsequent requests.
Your information and choices
- Choose the exact source file and whether its content may use cloud processing.
- Inspect the candidate before applying it; leave the current source unchanged by declining.
- Keep file application, preview and any future publication separate.
Current scope
Implemented foundation
- The selected-file, candidate review, explicit apply and local preview workflow is implemented. A controlled demonstration reached real desktop and mobile browser previews using a scripted model reply.
Next milestones
- Real-model coding quality and autonomous multi-file development are not established by that demonstration.
- The selected-file path does not combine all specialist, document and tool workflows in one run. Public hosting and installers remain closed.
These are development capabilities, not a public release. See platform availability before requesting a trial.
Platforms and availabilityBring a task you want to move forward.
Explore the Mac release, or tell us which workflow you would like to evaluate. An application does not guarantee an invitation.