Know where your research lives before you start the task.

1. Read the workspace as a research record

The interface becomes easier to understand when every area has a job. The project is the durable boundary for the research; conversations hold individual lines of work; source files provide inputs; and artifacts such as reports, tables, figures, scripts, and logs are the outputs you need to inspect.

Begin by confirming the active project and conversation. A correct answer saved in the wrong project is still hard to find, review, and hand over later.

2. Separate project state from session permissions

Projects preserve research context over time, but not every capability should remain globally enabled. In the current release, local computing is available by default while SSH or WSL resources must be selected for the conversation that needs them.

That boundary is useful: one project may contain several conversations with different data, tools, and risk levels. Review the active conversation before granting a remote environment or starting a command-heavy workflow.

3. Verify the model connection before the real task

Check the provider, endpoint, model name, and credential location before starting a long literature or data-analysis run. A short test request can reveal an invalid model name, an unreachable endpoint, or an exhausted quota before time is spent assembling the workflow.

Model credentials belong in the application setting designed for secrets. For remote MCP OAuth connections, v0.15.0 stores access and refresh tokens in the operating-system keychain. Do not paste an API key into a prompt, project document, screenshot, or code repository.

4. Review settings according to their consequences

You do not need to configure every option on the first day. Start with the settings that change where data goes, what the Agent may execute, and how much work it may do in one turn.

• General: choose a practical Agent iteration limit; zero means unlimited in v0.15.0.
• Environment: inspect local, SSH, or WSL capabilities and select only what this conversation needs.
• Remote access: enable Feishu/Lark or WeChat only when you intend to continue the session from that service.
• MCP connections: review the destination and OAuth consent before adding an optional remote service.

5. Run a sixty-second preflight

Before a costly or sensitive task, confirm the project, conversation, model, compute environment, approval boundary, input files, and expected output. Then run the smallest request that proves the path works.

If the task will contact an external model, database, MCP server, remote machine, or messaging service, decide whether the data is appropriate to send there before the first tool call.

• Correct project and conversation selected.
• Model connection passes a small test.
• Only the required compute and remote services are enabled.
• Input paths are stable and output expectations are explicit.
• Sensitive data and credentials stay outside prompts and shared artifacts.

6. Resolve interface differences with the release note

Settings and panel positions can change as Wisp Science develops. When the screen differs from the recording, identify the installed version first, then use the matching release note and current documentation instead of guessing from an older screenshot.

This keeps the video useful as an orientation guide while the release page remains the authority for version-specific behavior.