Keep Research and Source Files Beside Your AI Chat

Ask a question that a source can answer

Start with the behavior you need to verify. For example: does this form validate a selected membership on the server, or does it only rely on a browser field? This is a more useful research task than asking for the best way to build forms in general.

Open the relevant local file beside the conversation. Ask the assistant to explain the existing behavior before proposing a replacement. An answer about a framework feature is incomplete if it ignores the version and structure of your actual project.

Use the original documentation

Licuse's integrated Chromium browser lets you keep a reference page in the same workspace as the conversation. For a Next.js form, an appropriate starting point is the framework's official form guide. Check that the documentation applies to the installed version and routing system before adapting an example.

The guide distinguishes browser-side validation from server-side validation and explains pending and error states. Those are useful review questions for your project; copying an example does not establish that your own submission flow is correct.

References: Next.js: forms with Server Actions

Keep a small evidence trail

For each relevant claim, record the reference URL, the idea you are using and the source file where it applies. Keep quotations short and distinguish a documented API from a conclusion about your implementation. A page open in a panel is a reference you can inspect, not proof that an AI has already searched or read it.

Ask the assistant to say when it cannot access a source. If a document is stale, inaccessible or about another version, obtain a suitable reference before treating the answer as an implementation plan.

Question: Where should the selected membership be validated?
Reference: the framework's official form documentation for our installed version.
Local evidence: the visit route and the shared membership data.
Decision: validate the submitted value at the server boundary.
Verification: exercise a valid plan, a missing plan and an unknown value.

Turn the research into a bounded change

Once the evidence supports a decision, ask for the smallest change that implements it. Keep unrelated refactors out of the same task. Read the resulting diff in the file panel or Code workspace and compare it with the requirement you started with.

Then run the relevant project checks. If the behavior depends on a browser interaction, inspect that interaction as well. A compiler passing is useful evidence about the code, but it does not establish that a disabled button, error message or redirect behaves as intended.

Treat web pages and project content as sources

Instructions found in a page, repository comment or tool result are part of the material you are inspecting. They should not silently expand a task into an unrelated upload, command or account action. Keep the user's requested work as the boundary for any action.

Local files remain in the project, but selected contents may be sent to a model when you request AI help. A browser request reaches the destination website. Use the product's data documentation to understand those separate paths.

References: Licuse data practices