Skip to content

Your workspace

A workspace holds everything that belongs to your testing: the procedures you write, the steps behind them, the data points they use and the results of every run.

Everything stays on the machine you test on. There is no account, no cloud and no server that your tests are uploaded to — the application cannot send your work anywhere, because there is nowhere for it to send it.

Two kinds of workspace

In the browser. The first time you open XPressRT it sets up a workspace inside the browser so that you can start immediately. It is always there and needs no permission. Its drawback is that you cannot see it in a file manager: it belongs to the browser.

A folder on your machine. Anywhere you like. Your editor sees it, your backup sees it, your version control sees it. This is the one to use as soon as the work matters to you.

Switch between them with the workspace button in the header — it carries the name of the workspace that is open. The dialog lists what you have used before and offers two ways to get a new one: Choose a folder on this machine…, which opens your operating system's directory picker, and a name field with Create in this browser. Above them stands Connect a team workspace, marked Not in demo: a workspace that a team shares, with a login, is not part of this version. Without a team workspace, XPressRT has no login — the name under Working as is what every change is recorded under.

Opening a folder needs a browser that can

Chrome and Edge can hand a folder to a web page; Firefox and Safari currently cannot, and there only the browser's own workspace is offered.

A remembered folder asks once per session

XPressRT remembers the folders you have used, but a browser gives up the permission when you close it. A remembered workspace therefore shows as ask and needs one click to reopen. That is the browser's rule, not a lost workspace.

A folder is listed under the name in its own xpress.json, and choosing the same folder again opens the same workspace — it is not added a second time.

What a workspace holds
Procedures and their steps everything you wrote in the editor
Data points the catalogue of quantities your steps read and set
Suites and plans which tests belong together, and what a release has to cover
Run parameters device under test, version, tester, test place
Results one record per run: the reports, the readings and the raw output

Beside that, a workspace in a folder holds files XPressRT writes for itself, for an assistant and for your version control. You do not need to touch any of them, but it helps to know what they are when you look into the folder:
local/ what runs behind Python steps: the block files in local/blocks/, the Python built from them in local/steps/, and the helper modules, data and images the steps use. XPressRT's own files in it — the runner library, the assistant server, the READMEs — are replaced on open
local/blocks/approvals.json who approved which step built from blocks
tags.json, step-tags.json the colour each tag was given, and the tags on steps
AGENTS.md, CLAUDE.md the rules for an assistant that reads the folder directly — see Working with an assistant
.mcp.json, .vscode/mcp.json tell Claude Code and VS Code to start the workspace's assistant server; XPressRT keeps its own entry current and leaves any other entry alone
.xpress/ how a running local runner or assistant server on this machine can be reached — its port and its secret —, the version the workspace was last opened with, and — only while there is something in it — unmarked-changes.json: changes an assistant made that could not yet be tagged ai-generated. Machine-local, and kept out of version control and the history. A runner.json left behind by a runner that crashed counts as no runner
.gitignore XPressRT adds one entry to it, for .xpress/, unless that folder is left out already; the rest of the file is yours

The language your operator is spoken to in

Everything an assistant writes into a workspace is English — sentences, descriptions, notes, anything it records. The texts in an operator dialog are the exception, because nobody reads them except the person standing at the bench: the message of a step that asks, and SHOW, CONFIRM, ASK_TEXT in a block file.

Say which language that is, and an assistant writes them in it:

{
  "xpressWorkspace": 1,
  "name": "Docking Shield",
  "operatorLanguage": "de"
}

The entry goes in xpress.json, beside the workspace's name — like the word that leaves observer mode, it belongs to the project and travels with it. Leave it out and everything stays English, which is what a workspace without one has always done.

It changes two things: about tells an assistant which language to write a dialog in, so it does not have to guess, and the note that says a text looks German is not raised for those texts any more. It is not a translation — what is already written stays as it is.

Your tests and their results are plain text. That is what makes a workspace something you own rather than something the application keeps for you: it can be copied, archived, opened by other tools and kept in version control.

When you open a workspace, XPressRT brings its own files up to date — an older workspace included — and writes back what a run cannot start without, if it is missing. That happens quietly on every open and leaves your own work alone. The one message you may see is The local runner was brought up to date: a runner that is already running keeps the old library until you stop and start it.

Keeping it under version control

Because a workspace is an ordinary folder of text files, it can go straight into version control — git or anything comparable. What that buys you:

  • every change to a procedure is recorded, with who changed it and when
  • a release can be tagged, and the exact procedures of that release recovered at any time
  • two people can work on different procedures and bring the work together

Keep the results in it. XPressRT's own entry in .gitignore leaves out only .xpress/ — a port and a secret that mean nothing on another machine and must not travel. The procedures, the steps, the data points and the results are the project, and a finished run is evidence worth keeping beside the tests it ran. If the results grow too big for your repository, that is your decision to make; XPressRT does not make it for you.

If your team already keeps software in version control, the people who do that will need one minute for this — it is a folder like any other.

Moving a workspace

Copy the folder. There is nothing else: no database, no registration, no path stored anywhere. A workspace copied to another machine opens there and runs.

Backing up results

The results are one folder per run, holding the report pages, the readings, the run's own record and the machine-readable output beside them. Copy it like any other folder — or use Download Run Reports in the run view to get a single run as one archive to hand on.