AI generates the autotests. Our specialists validate. Your releases ship with confidence.
1 AI generates the autotests2 Specialists validate every edge case3 Your releases ship with confidence
User guide
TestingForge — how to use everything
This page walks you from zero to a working API (Bricks) run and a working Browser Flow run.
Read top to bottom the first time, then use the table of contents as a cheat sheet.
What TestingForge is (in one minute)
TestingForge is a web application for API-first automated testing. You connect your AI agent via MCP (or work directly in the UI), point the product at the HTTP environments you already use (staging, QA, production-like sandboxes), and work with Bricks and Scenarios — structured steps that represent real API calls, variables, and assertions.
The product can generate and maintain suites over time, run them on demand or in CI, and surface clear run diagnostics when something fails. It covers HTTP/API brick scenarios and Browser Flows (headless Chromium walks: login, click, assert URL/text/visibility, screenshots).
Browser Flows drive a real headless Chromium session: open a URL, type, click, wait for SPA navigation,
assert URL/text/visibility, and capture screenshots. Each queued execution becomes a normal
AutomationRun — same run detail page, same CI polling, same Stripe meter as an API scenario.
Mental model: Bricks speak HTTP. Flows speak the DOM. Do not try to encode a login form as a Brick
when you need cookies, JS redirects, or “is this button visible after click”.
Browser vs Bricks
Bricks / scenarios
Browser Flows
What runs
Ordered HTTP calls
Ordered Chromium steps
Editor
/workspace/bricks
/workspace/flows
CI selector
test_scenario_id
browser_flow_code or browser_flow_id
MCP namespace
workspace_*brick*, brick_guide
workspace_*flow*, browser_flow_guide
Billing
Successful run metered
Same meter / same price
Mutually exclusive
One run is either API or browser — never both in the same start payload
First SPA checklist
Fastest path for a brand-new web app (UI or MCP — same steps):
Secrets — store at least
E2E_WEB_BASE_URL (SPA origin),
E2E_USER_EMAIL,
E2E_USER_PASSWORD (mark password as secret / encrypted).
Prefer “open first row in list” over hardcoding entity UUIDs when the app regenerates fixture data.
Scaffold or create — UI: ＋ New flow / login recipe modal.
MCP: workspace_onboard_status then workspace_scaffold_login_smoke
with base_url + credentials (creates secrets + a login smoke flow in one shot).
Dry-run — editor Dry-run or MCP workspace_dry_run_flow.
This executes the full flow in-process and does not create a billed AutomationRun.
Fix selectors until green.
Preflight — confirms Chromium runtime is reachable and every {option.*} used by the flow resolves.
Queue run — editor Queue run, Test launch with a browser flow selected,
MCP workspace_run_flow, or CI start_run with browser_flow_code.
Prefer wait_selector / wait_url after SPA navigations. Sleeping “a few seconds” is a last resort —
it flakes under load and wastes wall clock on the browser worker.
Editor, dry-run, preflight, queue
Open Browser Flows, then create or edit a flow.
Each flow has a stable code (slug used by CI), a human name / description, metadata (default timeouts, tags), and an ordered list of steps.
Save — persists metadata + full step/assert tree (replace-on-save semantics for steps).
Try selected step — runs from the start through that step only (MCP: workspace_try_flow_step). Use while tuning one selector.
Dry-run — full flow, no AutomationRun, no Stripe event.
Roles: organization owner or automated_qa for write/run. Viewers can list but not mutate.
Runtime needs a Chromium endpoint: set BROWSERLESS_WS_URL (+ optional BROWSERLESS_TOKEN)
or laptop CHROME_PATH. Local docker-compose ships a browserless service and a
worker-browser process consuming the browser queue. Without a worker, queued runs stay pending forever.
Step kinds
Every step has a kind, optional label, selector/value fields, timeout, and flags. Max steps per flow is capped by config (BROWSER_MAX_STEPS, default 100).
Kind
UI label
What it does
goto
Open a page
Navigate to a URL (supports {option.KEY}).
fill
Type into a field
Focus selector and type value (passwords via options, never hardcode).
click
Click something
Click a CSS/XPath-style selector the runner understands.
Poll until location matches expected fragment / pattern.
wait_selector
Wait for element
Wait until selector is present/visible before the next action.
sleep
Pause
Fixed delay — use sparingly.
screenshot
Take screenshot
Store a PNG artifact on the run (also auto on hard failure when enabled).
assert_group
Verify only
No navigation — only evaluate attached asserts.
Default step timeout comes from BROWSER_DEFAULT_TIMEOUT_MS (default 15000). Viewport defaults to 1280×720
(BROWSER_VIEWPORT_WIDTH / BROWSER_VIEWPORT_HEIGHT).
Asserts and soft-fail flags
Asserts hang off a step (including assert_group). Each assert has a target, an operator,
and usually an expected value / selector / attribute name.
is_optional on a step — soft warn; the run continues and the step does not fail the run by itself.
continue_on_error — hard fail is recorded, but execution keeps going (useful for “probe many tabs, report all”).
Never assert the value of a password input. Prefer URL / visibility / post-login shell landmarks.
Secrets, options, selectors
Same vault as Bricks: Secrets.
In step URLs and fill values write {option.E2E_USER_PASSWORD} — resolved at run time, never stored in the flow JSON as plaintext after you used the option syntax.
Common key
Purpose
E2E_WEB_BASE_URL
SPA origin, e.g. https://app.example.com
E2E_USER_EMAIL / E2E_USER_PASSWORD
Login for smoke / deep packs (stable user; recordings may rotate)
Selector tips: prefer data-testid / stable ARIA labels over CSS that mirrors layout.
After client-side routing, pair click with wait_url or wait_selector for the destination shell.
Runs, screenshots, artifacts
A queued browser run looks like any other AutomationRun on the run show page: status, timeline, step chips (GOTO / FILL / CLICK / WAIT / CHECK / …).
Failure screenshots are stored as browser artifacts when BROWSER_SCREENSHOT_ON_FAILURE is true (default).
Explicit screenshot steps always attach PNGs you can open from the run UI
(/runs/{uuid}/browser-artifacts/{id}).
Also launch from Run test — pick a Browser flow instead of an API scenario.
The dropdown shows the human name plus the CI code.
CI with browser_flow_code
Same TF_API_KEY as API scenarios. Start endpoint: POST /api/v1/runs
(or MCP start_run). Pass eitherbrowser_flow_code or browser_flow_id —
do not also send test_scenario_id.
Minimal shape:
organization_slug — required
browser_flow_code — stable slug from the flow editor / flows index CI snippet
label — optional pipeline label
Poll with GET /api/v1/runs/{uuid} / MCP get_run until terminal status.
Copy a ready curl from the flows index (CI snippet disclosure) or from CI & Notifications after you select a browser flow on Test launch.
MCP tools for flows
Call browser_flow_guide once in the agent session (mirrors this section for tools).
Cheap path for a new SPA:
workspace_onboard_status
workspace_scaffold_login_smoke
workspace_dry_run_flow → workspace_update_flow if selectors fail
Runtime guard (enabled by default) fails the run on CDP page errors, own-origin 5xx / failed document/XHR/fetch,
or blank shells. Tunables: BROWSER_RUNTIME_GUARD, BROWSER_GUARD_PAGE_ERROR,
BROWSER_GUARD_OWN_5XX, BROWSER_GUARD_OWN_FAILED, BROWSER_GUARD_BLANK_SHELL,
ignore lists BROWSER_GUARD_IGNORE / BROWSER_GUARD_IGNORE_FAILED_MSG
(analytics, aborted SPA navigations, etc.). Console errors are off by default (BROWSER_GUARD_CONSOLE_ERROR).
Billing (same meter as API)
Successful browser runs report the same Stripe meter event as successful API runs (test_run_completed / usage price on your plan).
There is no separate browser SKU and no platform-fee bump for enabling flows.
Failed runs, dry-runs, try-step, and preflight are not billed as successful usage.
In TestingForge, a Brick is one API call stored as a plain, editable database record — not a line buried in a generated script you cannot open. The Bricks page subtitle says it plainly: “Every API call your scenarios execute.”
If you have seen the name Librix in an older note, treat it as the same subsystem: Bricks in the UI at /workspace/bricks.
How pieces nest (read this once)
Think top → bottom, like a table of contents for your test run:
Workflow (called Scenario in the database) — e.g. “Checkout smoke”. This is what you pick on Run test and what CI passes as test_scenario_id.
Section (called Group) — e.g. CHECKOUT, CLEANUP. Sections run in order; use ⇅ Sort groups on the Bricks page to change that order.
API call (the Brick) — e.g. POST /login, GET /cart. Calls inside a section run in order; drag the ⋮⋮ handle to reorder.
Execution order: sections top → bottom, then bricks inside each section top → bottom. The flow graph (◇ Flow graph on a workflow) visualises the same order — click a node to jump into its editor.
You see one block per workflow. If you have several, use the tabs under the search box (★ marks the default workflow).
Use the search field to filter by label, URL, or HTTP method. Keyboard: press / to focus search; ⌘K opens the command palette; ? shows shortcuts (when enabled in your build).
Each row is one brick: method badge, label, URL template, optional health badge (% success on recent runs), and ✎ Edit.
Anatomy of one brick (every field, in plain language)
Click ✎ Edit on any row. The editor is split into a main form (left) and preview / Try it / revisions (right). Core fields:
Method — GET, POST, PUT, PATCH, DELETE, etc.
URL template — path such as /api/v1/orders/{orderId}. Placeholders in curly braces are filled at run time.
Host — Use run environment (default): the base URL comes from the domain you pick on Run test ({baseUrl}). Custom host: call another service — paste https://files.example.com or {option.STORAGE_HOST}; the URL template path is appended.
Kind — usually http_request. Advanced kinds include auth_login, http_poll_until (retry until a status appears), sleep, assert, file upload helpers, and org-specific hooks. Pick the kind that matches what the runner should do, not just “another GET”.
Label & description — human names for the index and for debugging failed runs.
Tags — comma-separated labels (e.g. auth, smoke) for your own organisation.
Auth profile — tells the runner which headers/tokens to attach automatically (e.g. bearer token, re-login on 401, anonymous SPA). Profiles like none mean you manage headers manually.
Body mode — none, json, form_params, multipart, or raw. The runner sets Content-Type appropriately; do not fight it with duplicate Content-Type headers unless you know why.
Body template — JSON or text with {placeholders}, e.g. {"email":"{option.E2E_USER_EMAIL}"}.
Headers — extra name/value pairs; values support {variables}. Override auth profile defaults when names collide.
Allowed / warn statuses — which HTTP status codes count as pass vs warning (comma-separated lists in the form).
Timeout (seconds) — per-call ceiling (1–3600).
Flags — active (skip when off), advanced, optional (scenario continues even if this brick fails).
Variables — how data flows between bricks
At the top of the editor, coloured chips show variables you can click to insert at the cursor:
Runtime — built-ins such as {baseUrl}, {runId} (provided by the runner for every run).
Upstream — values produced by earlier bricks in the same workflow via Extracts.
Org option — {option.KEY} from organisation settings or the Secrets vault (encrypted options). Example: {option.E2E_USER_EMAIL}.
This brick — names you define in Extracts on this brick; downstream bricks can use them after this brick runs.
Extracts (in the editor) — after the HTTP response arrives, copy a value into a variable:
variable_name — e.g. token → later bricks use {token}.
source — json_path (field in JSON body), header, status, or url_path.
expression — e.g. data.attributes.token for JSON.
required / default — fail fast if missing, or fall back to a default string.
Checks (response assertions) — evaluated after the call. If any active check fails, the brick fails:
Target — JSON path, raw body, or response header.
Operator — equals, contains, regex, not_empty, empty, etc.
Expected value — can include {variables} before comparison.
Conditions — optional gates: skip or run the brick only when a variable matches a rule (useful for branching without duplicating whole workflows).
On the Bricks index, a red ⚠ unresolved badge means a {name} is referenced but nothing upstream, no org option, and no runtime var provides it yet — fix extracts or add an org option before relying on the run.
Editor actions you should know
Save — every save creates a revision. Scroll to Revision history on the right and revert to an older revision if you break something.
Try now — fire this single brick against a chosen environment with optional variable overrides; use this before running the whole workflow.
Compare with template — if your brick was forked from a shared baseline, see the diff vs upstream and optionally sync changes.
duplicate — clone the brick inside the same section.
Request preview — right panel shows the rendered URL/body with sample variables before you hit the network.
Import — don’t type what you already have
From a workflow header on the Bricks page:
↓ Import cURL — paste a command from Chrome DevTools, Postman, or terminal (/workspace/bricks/import). You land in the editor with fields pre-filled; fix extracts and checks next.
↧ Import bulk — paste Postman Collection v2.x or OpenAPI 3.x JSON (/workspace/bricks/import/bulk). One brick per operation. Template sections are auto-forked to your org when needed.
+ Add API call inside a section — blank brick appended to that group.
Open the TestingForge homepage and look at the top-right of the navigation bar.
Click Register. If you are on a phone, open the “hamburger” menu (three horizontal lines) first — the same links are inside the mobile menu.
Fill every required field. Password managers (1Password, Bitwarden, iCloud Keychain, etc.) are encouraged — you will reuse this login often.
Submit the form. If the page shows an error in red, read it literally: duplicate email, weak password, or network issues are the usual causes.
Go to your email inbox, find the verification message, and click the link inside. Details in the next section.
Return to the site and click Log in with the same email and password.
Organization
Work in TestingForge happens inside an organization. Billing, domains, and runs belong to the org. If someone invited you, accept the invite link from the email; your user will join their organization.
Roles (who can click what)
Common roles include Owner, Automated QA, and Runner. Owners manage billing and integrations. Automated QA typically sets up environments, bricks, and MCP integration. Runner can execute tests that are already configured. If a button is disabled or missing, your role may not include that action — ask an Owner in your org.
Inviting teammates
Organization owners invite colleagues from Organization members (/organization/members). Invited people receive a link; until they accept, they do not consume a seat in your plan.
Email verification (why the app blocks you)
After you register, Laravel-style email verification protects the workspace: you can authenticate, but protected routes keep redirecting you until the verification link is clicked.
Check spam/junk if nothing arrived in two minutes.
Click the verification button or URL in the email — it must open in a normal browser session (not an embedded in-app browser that strips cookies, if you can avoid it).
Log in again if the session expired during the round trip.
You should now reach Dashboard or onboarding without “verify your email” banners.
Where things live in the app (URL map)
Replace https://testingforge.io mentally with your deployment host. Paths below are the ones Laravel registers in this repository — bookmark them once you are logged in.
Visiting a URL while logged out sends you to login first — that is normal. After authentication you land on the originally requested page when possible.
First run checklist (onboarding)
After you log in, open Onboarding if the app sends you there. The checklist is deliberate — each step unlocks the next.
Connect via MCP — Generate a TF_API_KEY from CI & Notifications and add it to your AI agent config (Cursor, Claude Desktop, or any MCP-compatible client). Full setup at /mcp.
Add domains — Under Domains, create domain groups and add the hosts you are allowed to hit (for example https://api.staging.example.com). This is how you tell TestingForge where HTTP requests may go.
Activate billing — Pick a plan on the Billing page so production runs and quotas align with your subscription. Until billing is active, runs may stay blocked even if everything else is configured.
Start testing (API) — Open Run test (/test-launch), choose environment + scenario, and launch.
Or start a Browser Flow — Store E2E_WEB_BASE_URL + login secrets, open
Browser Flows, scaffold a login smoke, dry-run, then queue.
Full walkthrough: First SPA checklist.
You can jump ahead with links in the onboarding cards, but if a step shows “Done” only after you actually completed the underlying setup, trust that signal over memory.
SCM integration (optional)
TestingForge works without any source control access — the primary integration path is MCP (see the Cursor MCP section). SCM connection is an optional enhancement that lets the platform attach per-pipeline CI snippets directly to a linked source.
When you need it
If your team's policy permits granting read-only SCM access and you want per-repository CI/CD snippets pre-populated automatically, you can link GitHub or GitLab with a personal access token (PAT). Always use the minimum scopes suggested on the page — read metadata only; never grant write access.
CI snippets without SCM
You do not need SCM access to run CI. Go to CI & Notifications, copy the API key and the ready-to-paste GitHub Actions / GitLab CI YAML snippet from there. More detail in the CI/CD section below.
Domains and environments
A domain entry is a concrete base URL plus metadata (such as which environment name it represents). When you launch a run, you pick one of these domains so bricks hit the right cluster.
Create a domain group if you separate “Customer API” vs “Internal API”, etc.
Add a host URL. Include the scheme (https://). “Scheme” means the part before :// — without https:// the browser cannot speak TLS to your API.
Double-check trailing slashes only if your API is sensitive to them — some gateways treat /v1/users and /v1/users/ differently.
Return to Run test and confirm the host appears in the environment dropdown.
Only test systems you are authorized to stress. Pointing at production without approval is a policy and safety issue, not just a configuration detail.
Secrets and org options
Sensitive values (passwords, API keys, client secrets) belong in Secrets (/secrets). They are stored encrypted; the UI never shows the plain text again — only masked previews.
In Bricks and Browser Flows, reference them as org options: {option.YOUR_KEY}
(brick URL/headers/body, or flow goto/fill values). The same keys can be set in non-secret organisation settings when the value is not sensitive.
Open Secrets and create a key, e.g. E2E_USER_PASSWORD.
In a brick body, write {"password":"{option.E2E_USER_PASSWORD}"} (or use the variable chip picker in the editor).
In a Browser Flow fill step, set the value to {option.E2E_USER_PASSWORD} the same way — never paste the raw password into the step JSON.
Use Rotate when the credential changes; update any external systems that still hold the old value.
Environment-specific overrides use a prefix: {option.stage.E2E_IDM_BASE_URL} resolves the stage.E2E_IDM_BASE_URL option when the selected domain’s environment is stage.
Browser-oriented keys: see Browser Secrets.
Workflows (scenarios) — quick reference
A workflow is the full story your run executes. Everything about individual API calls lives in the Bricks guide above; this section is only workflow-level actions.
Create or change workflows
＋ New workflow on the Bricks page — pick a source workflow, tick the API calls you want, name the copy. Originals stay untouched.
＋ Add section on a workflow header — creates an empty group (then use + Add API call inside it).
★ Set as default — pre-selects this workflow on Run test and is the usual CI target.
⇅ Sort groups — reorder sections; bricks inside each section keep their own order.
◇ Flow graph — visual map of the workflow; click a brick node to open its editor. Use Run workflow (dry-run) on the graph page to validate without a full billed run.
CI references a workflow by numeric id: test_scenario_id. Copy the exact value from CI & Notifications — do not guess from the UI label alone.
If Run test shows no scenarios, your org may not have a provisioned driver yet, or workflows were removed. Finish onboarding (SCM + domains + billing) or create a workflow via import / ＋ New workflow.
Launching a test from the workspace
The Run test page (sometimes labeled Test launch) is the manual trigger panel for both API scenarios and Browser Flows.
API scenario
Choose the environment (domain) you configured.
Choose the test scenario / workflow from the dropdown. Each option maps to a concrete test_scenario_id used by CI as well.
Confirm driver settings if the page shows them.
Click Run (or the primary action button). If the button stays disabled, read the inline message: usually a missing environment, scenario, or subscription state.
Browser Flow
Switch the launcher to a Browser flow (or open the flow editor and use Queue run).
Pick the flow — the list shows the human name, short description, and CI code.
Run. Prefer dry-run from the editor first if you just changed selectors.
After you start a run, TestingForge records a run record: status, counters, timeline, and diagnostics.
API runs expose per-request traces; browser runs expose step chips plus screenshot artifacts.
Open Dashboard for a high-level snapshot.
Use Logs or run history pages (exact labels depend on your build) to find a failed run.
Open the report / run detail: for API — which brick failed and the HTTP exchange; for browser — which step/assert failed and attached PNGs.
When a run fails, fix either the system under test (real bug) or the expectations
(brick checks / flow asserts / selectors). If the platform proposes self-healing updates for API bricks, review the diff before accepting.
Browser selector drift is usually fixed in the flow editor (or via MCP workspace_update_flow) after a dry-run.
Continuous integration should call TestingForge the same way a human would from Run test, but non-interactively.
One key starts either an API scenario or a Browser Flow.
Open CI & Notifications.
Create your personal CI API key (each editor has their own). In pipelines, store it as a secret named TF_API_KEY — the YAML snippets assume exactly that name.
Copy the ready-to-paste workflow snippet.
API runs use test_scenario_id; browser runs use browser_flow_code (or browser_flow_id) — never both in one payload.
Commit the workflow file, push, and watch the pipeline start a run. Poll until the run completes and surface the report URL in your own logs if desired.
CI keys are personal within a workspace (not shared across members). Delete a leaked key and create a new one — other members' keys stay valid.
Browser-specific payload: CI with browser_flow_code.
Cursor MCP (IDE integration)
Your personal CI API key (TF_API_KEY) powers CI, the Machine API, and hosted MCP for Cursor. Creating a new key does not revoke other members' keys.
Endpoint: https://testingforge.io/mcp/server — no Node, no ZIP.
Setup: /mcp or CI & Notifications in the app.
Generate or copy tf_… in CI & Notifications.
export TF_API_KEY='tf_…' in terminal; launch Cursor from that terminal (or add to ~/.zshrc).
Use app/.cursor/mcp.json in the repo, or copy JSON from /mcp into ~/.cursor/mcp.json.
Enable testingforge under MCP settings; quit and reopen Cursor.
In Agent: mcp_guide, then either brick_guide / workspace_list_bricks (API) or browser_flow_guide / workspace_onboard_status (SPA), plus workspace_start_run / machine_api_routes.
MCP for AI: in Cursor, mcp_guide / brick_guide describe every brick field; use workspace_patch_brick, curl/Postman import, and workspace_try_brick without cloning the app repo.
For SPA UI, call browser_flow_guide and follow MCP tools for flows — never use brick tools to fake a browser login.
Local sandbox:make mcp-sandbox prints a test tf_api_key; MCP still uses https://testingforge.io/mcp/server.
MCP troubleshooting
401 — missing/wrong TF_API_KEY in Cursor’s environment.
No tools — restart Cursor; enable testingforge in MCP settings.
404 — use prod URL https://testingforge.io/mcp/server, not localhost.
Prefer create_ci_api_key for a new personal key. Use delete_ci_api_key when rotating; owners can list and revoke any workspace key.
Pulse (load-style checks)
Pulse is a separate marketing and product surface for hammering a single endpoint many times with a simple wizard — useful for quick “is this route stable under burst?” intuition without standing up k6 or JMeter locally.
Read the dedicated page for behavior and limits: Pulse.
Live demo workspace
The Live demo route hosts a public, reset-on-a-schedule workspace with a sandbox API and credentials printed on the page. Use it when you want to click through bricks and runs without creating an account first.
Billing and quotas
Plans and entitlements live under Billing. If runs refuse to start, verify:
Subscription status is active (payment method valid, no expired trial).
Monthly run quota is not exhausted.
Your user still belongs to the intended organization (check org switcher if present).
What counts as billable usage
Successful AutomationRuns — API scenarios and Browser Flows share one Stripe meter (test_run_completed). Same per-run price on your plan.
Not billed as successful usage: failed runs, dry-runs, try-step, preflight, cancelled runs.
No browser add-on: enabling Chromium flows does not change the platform fee. Details: Browser billing and pricing.
Troubleshooting
OAuth or token errors
Confirm callback URLs in your Git provider match the values configured for this deployment (services.php / environment on the server). Regenerate the PAT if scopes were too narrow.
SCM: empty repository list
Re-save the token and verify the PAT owner has access to the org/repos you expect. SCM connection is optional — you can use CI & Notifications snippets directly without it.
Run stuck or immediately failed
Check worker and application logs (operators: see project README for docker compose logs). Common causes: wrong domain URL, SSL interception, auth secret missing, or scenario referencing deleted bricks.
For browser: confirm worker-browser / queue:work --queue=browser is running and BROWSERLESS_WS_URL (or CHROME_PATH) is set.
Browser Flow issues
Selector / wait flakes — dry-run after each edit; add wait_selector / wait_url after SPA navigations; prefer data-testid.
Unresolved {option.*} — Preflight lists missing keys; create them under Secrets.
Runtime guard failure — page error, own-origin 5xx, or blank shell. Fix the app or tune BROWSER_GUARD_* / ignore lists if the noise is third-party.
CI rejects payload — do not send test_scenario_id together with browser_flow_code.
Brick / variable issues
Open the brick editor and check the right panel for ⚠ Unresolved variables. Add an Extract on an earlier brick, set an org option / secret, or supply a Try now override while debugging.
If import into a template section fails with “fork it first”, use bulk import (auto-forks) or edit a brick in that section once — customizing creates your org’s copy automatically.
CI cannot start runs
Ensure TF_API_KEY is present in the CI secret store for that pipeline, not only on your laptop. Re-copy the snippet after changing the default scenario id.
Cursor MCP
See MCP troubleshooting in the MCP section, or the copy-paste blocks on
/mcp and CI & Notifications.
Glossary
Brick — One API call record: method, URL, headers, body, extracts, checks, auth profile.
Librix — Informal name for the Bricks subsystem; in the product UI always use Bricks.
Browser Flow — Ordered Chromium steps (goto/fill/click/wait/assert/screenshot); CI key is browser_flow_code.
Dry-run (browser) — Full flow execution without creating a billed AutomationRun.
Preflight — Check that Chromium runtime and {option.*} keys are ready before queueing.
Runtime guard — Fails browser runs on page errors / own-origin 5xx / blank shells during the session.
Workflow / Scenario — Top-level API test story; picked on Run test; CI uses test_scenario_id.
Section / Group — Named block inside a workflow (e.g. CHECKOUT); runs before later sections.
Extract — Rule that copies a response value into a variable for downstream bricks.
Check — Assertion on response JSON, body, or headers; failure fails the brick.
Assert (browser) — Assertion on URL, title, text, visibility, value, count, or attribute for a flow step.
Org option — Key/value on the organisation, referenced as {option.KEY} in templates; secrets use the same syntax but are encrypted.
Fork / customized — Your org’s editable copy of a shared template section (amber badge in the UI).
Domain — Allowed base URL (environment target) for API runs; becomes {baseUrl}.
Workspace — Authenticated app where you manage bricks, flows, runs, and integrations.
TF_API_KEY — Personal CI API key for pipelines and MCP (one per member; owners can revoke any).
Self-healing — Proposed updates to bricks when APIs drift; human review before merge.
Questions not covered here: Contact the team or your internal TestingForge admin.
