Editing a pack

You can write and fix a pack's tests in the web app without leaving it. Press Edit on a pack's page, or the pencil next to a test's file. On an attempt's page, Edit this test opens the line the test broke on.

The editor works on the files in the pack's folder, the same files your own editor sees. A save writes the file, and the pack loads again right away, so the next attempt runs what you saved.

Files

The file list on the left shows the pack's folder. On a phone it opens from the panel button. Folders such as node_modules, dist and .git are left out, and only text files open (TypeScript, JavaScript, YAML, JSON, Markdown, CSS, HTML, plain text and the like, up to 1 MB). The + menu (New file) makes a YAML test, a TypeScript test or an empty file. A new test is filled with a starter test and the next free id. The ⋯ menu renames or deletes the open file, and converts a YAML test to TypeScript.

The editor can't reach a file outside the pack's folder, and it doesn't follow a link that points out of it.

With login on, viewers read the files, users change YAML tests, pack.yaml and data files, and only admins change code (.ts, .js and the like, package.json, tsconfig.json) or convert a YAML test to TypeScript, since code runs on the server. A user proposes a code change instead.

Proposing a code change

With login on, a user can still edit a code file, but instead of Save the editor offers Propose change. It sends the changed code files, with a note on what and why, to the Proposed changes page (in the menu). The files on disk stay as they are until an admin applies it.

An admin opens the change there and reads each file's diff against the version it was based on, then presses Apply (which writes the files and rebuilds the pack) or Decline, with an optional reply. When a file changed on disk since the change was proposed, the page says so, and applying writes the proposed text over the file as it is now. The person who proposed it sees what became of it on the same page, and can withdraw it while it waits. An alert rule with A code change waits for review tells admins when one comes in.

Agents do the same with the propose_change and get_proposal MCP tools.

Source

Source is a code editor with search (Ctrl+F) and save (Ctrl+S, Cmd+S on a Mac). Problems the pack has when it loads are underlined where they are and listed under the editor, and a click on one jumps to it. Problems in other files are listed too, with a link to open them.

In a YAML test file, the editor also checks the text as you type. It completes:

• step names on a new list item;
• a step's fields, and the target kinds (role, label, text, testId, …);
• the values a field allows.

Hovering a step or a field shows its description.

Steps

A YAML test can also be edited as a list of steps. Each step shows an icon, a short summary ("Fill placeholder "What needs to be done?" with "Buy milk"") and its line. Click a step to open its form:

• Change the step. Pick another kind of step from the menu. Fields the two steps share are kept.
• Edit the fields. A target gets a kind menu and its value (with the role's name and Exact for a role). Choices get a menu, yes-or-no fields a switch, and the rest a text box. An expect step picks its check first.
• Arrange the steps. Move a step up or down, duplicate it or delete it, or drag it by its grip. Add a step opens a list of every step, grouped and searchable.
• Steps inside a step. The steps of if, repeat and step show as lists of their own under the step.

The steps are written back into the file in place, so your comments, blank lines and formatting stay as they were. Fields the form can't show are left as they are, with a note to change them in Source. Source and Steps show the same file, and switching keeps your place.

Markdown preview

A Markdown file (a pack's README.md, notes) has three views above the editor: Source, Preview and Side by side, where the preview follows as you type. The preview shows headings, lists and task lists, tables, quotes, code blocks with colors and a copy button, and links. A link to another file in the pack opens it in the editor, a link to a heading scrolls to it, and a web link opens in a new tab. In Side by side, the preview follows the cursor: the part you're editing is marked and scrolled into view, and a click on the preview moves the cursor to that part of the source. Images stored in the pack (![Checkout](docs/checkout.png)) and images from the web both show; an image that can't load shows its description in a frame. HTML in the file shows as text. The editor remembers the view you picked.

Run this test

Run runs the test the cursor is in, with the parameters of the pack's last run. The menu beside it runs another test in the file. The run shows live under the editor, with pause, resume, retry, skip and stop. When it ends you see the result and the error, with Go to line for the line it broke on, and See the attempt opens the full attempt page.

Record

Record writes steps for you while you click through the site on a live view, and puts them in the file at the cursor. See Recording.

When the file changes on disk

When you save, the editor checks that the file on disk is still the one you opened. If it changed in the meantime, for example after a save in your own editor or a git pull, it doesn't overwrite it but says so. You can:

• Show the changes between the file on disk and your text;
• Use the file on disk, which drops your edits;
• Overwrite with mine, which saves your edits over it.

When another tab or an agent saves the file through Watchwright and you have no unsaved edits, the editor loads the new text by itself. Unsaved edits also survive moving to another page and back, and the browser asks before you close a tab that has some.

Agents and scripts can do the same through the files API.