Early testing

Early testing is a guided evaluation of a development alpha. Arrange access with the person running the installation before following the tutorial. This page does not provision an account. If you are starting from Docker images alone, read installation and first access first.

Before you start

Ask the installation operator to provide:

• The Console URL, sign-in instructions and your permitted workspace.
• A dedicated draft and an agreed test task, separate from shared or published work.
• A connected development draft runner and the supported test input.
• A support contact and a way to identify the installed build in a bug report.

Use a desktop viewport at least 1600 pixels wide; the current Studio layouts have been reviewed at 1600x900 and 1920x1080. Resolve certificate or access problems with the operator instead of changing browser security settings.

For the first draft tutorial, the operator should prepare a disposable source with a JavaScript collect export, object input and an array output schema containing string fields id and title. Its descriptor must reference the module and schemas and use the guida.extractorResult.v1 result envelope. The tutorial code returns synthetic records without contacting a source website. Preparation is part of the supported evaluation, rather than an assumption that every workspace already contains this fixture.

Prepare the example (operator)

Before the tester begins, the operator can prepare the source through Studio:

1. Open the isolated draft. Beside Sources, choose Add source, then Write a custom source.
2. Set Source name to First draft example, Collect with to API / HTTP requests, Default URL to https://example.com/, and Target domains to example.com. This is a declared placeholder; the tutorial module makes no network request.
3. Under Source identity and files, use the identifier first-draft-example. Choose Create source and write code.
4. Replace the generated implementation with the tutorial module. Studio’s generated module is lib/first-draft-example.js; keep that filename and the collect export. The downloaded .mjs file supplies the code, not a new path.
5. In Files, replace schemas/first-draft-example-input.schema.json and schemas/first-draft-example-output.schema.json with the supplied input and output schemas and save. The input schema permits the source’s configured URL default as well as {}.
6. Keep the descriptor’s generated module/schema references and result envelope. Run the saved source once and confirm example-1 / My first draft result. Give the tester this draft and source name.

These steps follow the current Studio source-creation controls. They assume write access and the already connected runner; they do not provision either.

Agree on source access and execution

The development runner executes trusted code. Use an isolated evaluation workspace and code reviewed for the task. It is not a sandbox for arbitrary untrusted submissions. Agree on any target websites and credentials separately.

Start with editing, testing, reading results and correcting failures. Keep release preparation, publication, activation and scheduled work outside the first tutorial. Those operations need their own instructions and an agreed task.

AI setup and saved-context previews can be inspected while inference is disabled. Calling a live model requires an explicitly enabled provider and can consume tokens. The first tutorial needs no AI calls. See AI and coding assistants if you want to explore the experimental integration afterward.

Confirm the installation is usable

1. Sign in to the supplied Console URL.
2. Confirm the selected workspace matches the one assigned to you.
3. Open Workspace Studio, then the prepared draft and source implementation.
4. Open Test draft. If the runner is unavailable, ask the operator to restore it, then choose Refresh. A visible Console alone does not prove execution is connected.
5. Follow edit, test and correct a draft.

Useful feedback

Record what you tried to do, what you expected, what happened and where the instructions stopped being sufficient. Include the relevant screen label, build, time, safe error text and steps to reproduce. A confusing term or an unnecessary detour is useful feedback even when nothing crashes.

Use synthetic examples when sharing a report. Keep credentials, tokens and private source data out of screenshots and copied results. Send installation details through the support channel agreed with your operator. General feedback and guided-evaluation requests can use the public feedback channel.

If a test is interrupted

• Runner unavailable: preserve your edits, restore the connection and refresh.
• Save conflict: review the latest saved version before keeping or reconciling your changes. Do not overwrite another edit blindly.
• A long-running script: use Stop test, wait for its terminal state, then correct the code before another run.
• Reload or service restart: saved drafts remain separate from temporary test results. Save code before reload. A missing temporary result does not prove the original operation failed and is not a reason to replay an unknown mutation.