What we shipped.

Some apps’ signed-out page has no form until you press Sign in, and the form opens in a dialog or on another page. When a sign-in page shows no email, username or phone field, the recorder now presses a visible “Sign in” or “Log in” button or link once (never “Sign up” or a waitlist) and fills the form that opens. Its errors say whether it pressed one.

Run and Publish in the walkthrough editor used the oldest environment with a URL. They now use the project’s default environment, as the feature page already did. A cloud run against localhost, or an environment that records in your own CI, is turned down with a pointer to npx stagewright run, and the PR check shows it as neutral.

The recorder change is in the next CLI release (0.3.1), which isn’t on npm yet. Not yet re-run end to end with real credentials.

The frame around the video was a cool slate blue that matched nothing else and didn’t change in dark mode. It’s now warm charcoal, and darker in dark mode so the player sits below the page rather than blending into cards. This changes the hosted and embedded player too.

Not changed yet: the training player’s frame and the backing behind text in rendered videos.

Until now, features came only from a mapping run, and a walkthrough’s features: keys could quietly match nothing. Now you can declare them in the repo, like every other setting:

features:
  contacts: { name: Contacts, kind: area }
  import-contacts:
    name: Import contacts
    parent: contacts
    routes: [/contacts/import]
    anchors: [src/contacts/import/**]
    personas: [admin]

Each feature takes a name, description, kind, parent, routes, anchors and personas. On sync they’re written as confirmed, and mapping leaves them alone. A key that matches a feature mapping already found updates it in place. A feature you remove from the file is kept and becomes editable in the dashboard again. Declared features are read-only in the dashboard, which names the file to change.

Walkthrough keys that match no feature are called out on the Features page, in the editor and in the PR check. stagewright config check and validate read the section, and config export writes your confirmed features out. Not yet checked in a browser.

Setup moved from the side of the overview to sit under Needs attention, as cards for what’s left; finished items fold into one line. Each item can be skipped (you don’t use that kind of tool) or marked done (you handled it outside Stagewright), with Undo. Both count toward progress, and connecting the tool later overrides them.

Items name the kind of tool rather than a vendor: “your issue tracker”, “help center and support”, “your product analytics”.

Not yet: skipping from stagewright.config. The setup wizard and the Insights empty states still name vendors. Not checked in a browser.

A code editor. The walkthrough YAML tab, the sign-in routine and guidance YAML use a code editor that suggests the keys allowed where your cursor is, enum values, personas and step ids, shows a key’s description on hover, and marks schema problems on their lines as you type. Everywhere else code shows, from settings as code to the SDK snippet, it’s highlighted in light and dark.

Settings, one part at a time. Project settings (General, Connections, Recording, Voice and terminology, Video, Player and hosting) and organization settings (Members, Integrations, Branding and tone, Billing and usage) open each part as its own page instead of one long scroll. Existing links still land on the right part.

Dropdowns. Every menu in the dashboard is the same component: keyboard-friendly, searchable when it has eight or more options, and not clipped by the card it sits in.

The new settings pages and dropdowns haven’t been clicked through in the full app yet.

Failures are sorted into kinds a person can act on: you’re offline, Stagewright couldn’t be reached, the page is out of date after a release, your session ended, you don’t have access, your plan doesn’t include it, or something on our side broke. Each says so in a sentence and offers the one action that helps. Try again also runs on its own when your connection comes back.

A section that fails to load no longer takes the page with it: the editor’s panels, the player and the run page each recover on their own. When the failure is ours, the error carries a reference like E-1A2B3C4D and a Tell us about this link that opens a support chat with the details attached: the reference, the request and the page, never request bodies or tokens.

Not yet tried with the live support widget.

Runs on your own machines and pipelines use none of our compute, so they no longer have a monthly cap on any plan, Free included. They’re still counted, and staff look at unusual volumes by hand; nothing refuses a run because of it. What those runs use from us, such as narration and cloud runs, is metered as before.

After a downgrade, runs queued for runners you host stop with the reason and their PR checks say so, and a cloned voice falls back to the project’s stock voice until the plan includes custom voices again. The audit log download now fetches every page into one file.

npx stagewright@latest now installs the CLI with what was announced here over the last few days:

• stagewright prompt [name] prints a prompt for your coding agent, filled in from this project, the same text as the dashboard’s Copy prompt blocks. --copy puts it on the clipboard. Signed in, --run <id> fills in a failing run’s step, check and error.
• stagewright ci --out <dir> keeps each rendered video and its captions as files, ready to upload as a CI artifact. Without an API key, --out also turns rendering on, so a pipeline gets videos with no account.
• stagewright ci reports to GitLab, Azure DevOps and Bitbucket as well as GitHub, and ci --template prints a pipeline file for each.
• stagewright export makes a GIF, a PDF guide, a screenshots zip and quick clips from a local recording.
• Locales: i18n in stagewright.config, and stagewright run --locale de-DE to record one.
• Annotated step screenshots, issues in the config, and plan limits that name the plan you’d need.
• The MCP server’s repo tools work with no account, so the plugin’s /stagewright:init sets a repo up before anyone signs in.

The CLI sends four anonymous setup milestones, with a notice the first time. STAGEWRIGHT_TELEMETRY=0, DO_NOT_TRACK=1 or telemetry: false in the config turns them off.

@stagewright-ai/react 0.2.0: StagewrightPlayer takes an accessToken for password and members-only videos, and its control bar shows the verified stamp. @stagewright-ai/playwright 0.1.1 fails a rejected sign-in as soon as the page says so, with the page’s own words.

Every pull request to Stagewright now starts the dashboard against a seeded sample workspace and records eight walkthroughs of it: onboarding, the coverage map, drafting a walkthrough from a gap, reviewing a UI change, a failing run, settings as code, translation review and a training course. They’re declared in our own stagewright.config.yaml, and a pull request records only the walkthroughs its files can affect.

In its first three runs it caught one real regression: a plan change had locked the sample workspace out of its course page.

What isn’t done yet: the job runs without an API key, so it reports pass or fail and keeps the videos as build files, without frames, baselines or approvals. It doesn’t block merges until it has stayed green for a few weeks. The recordings of our dashboard on this site’s home page are from these walkthroughs, rendered on a local build.

stagewright 0.1.0 is published. init writes a sample walkthrough and stagewright.config.ts, doctor checks the machine, and record records and renders offline. Sign in later to report runs, compare against baselines and approve.

Each slide template now says which of its props a viewer reads, and those labels are translated with the step’s narration, glossary and kept terms. Ids, numbers, units, timing cues and a quote’s author are never translated. A translated label that no longer fits its template falls back to the source words, so every language’s slide still validates. Reviewers see and edit the labels in the translation queue, under the same approval as the rest of the translation. Slides drawn as React compositions in your repo keep their props as written.

Approving edited words in a translation now queues a new recording of that language, set up like its approved run. When none starts (a plan limit, a run already queued, or words that aren’t the current script), the reviewer is told why and it’s written to the audit log.

Removing a runner you host now also fails the runs it had already claimed (“was removed while it was recording this run”) and reports their PR checks; anything it sends afterwards is refused. A job with repo slide compositions runs alone on its runner, and compositions are capped at 200 files. The player’s language switcher keeps the page’s other settings, such as the theme.

Tested in the rebuilt runner image on our machines; no new image has been published yet.

What a plan includes is now checked in one place in the API, and a test fails when a feature is declared but never checked or a gated route loses its check. A refusal says which plan adds the feature, in the API’s problem response, the CLI, the MCP tools and one muted line in the dashboard where the control is. Background work that’s skipped for the plan (a PR check, a regression filing, a help-center sync) says so where it reports.

Kept on every plan on purpose: running walkthroughs in your own CI and reporting to GitHub, GitLab, Azure DevOps or Bitbucket from it, affected-only runs, auto-zoom, simple slides, annotated screenshots and article text, Copy prompt, the MP4 download and anonymous viewing. PR checks on our runners and embedding the player move to the first paid plan. After a downgrade nothing is deleted: private videos show “This video isn’t available” rather than going public, and custom domains stop routing until the plan allows them again.

Not verified yet: the plan features in Clerk Billing and single sign-on connections haven’t run against a live Clerk account.

Every published video now shows Recorded from build a1b2c3d · verified 3h ago, and published help-center articles carry the same stamp. Links can be public, private or behind a password, and the player can be served from a custom domain once Cloudflare has verified it.

Progress beacons count seconds watched against the approved version’s real length, so drop-off is shown by the second and lined up with the narration line on screen at the time.

A step can be a slide instead of a recording. Seven templates (concept, process, before and after, comparison, metric, step list, quote) take typed props in the walkthrough file and are checked like everything else in it. Items appear as their words are spoken (at:), and the look follows the brand kit.

Teams can also draw their own slides with a React composition in .walkthroughs/slides/. It renders in a separate process with no network and no secrets. Animated slides render locally from a checkout and in the cloud runner; the published npm CLI doesn’t render them yet.

Add i18n to stagewright.config and each walkthrough records once per locale: the browser runs in that language, the narration is translated before it records (terms in keep stay as they are), and the narrator speaks the locale’s language. Each locale is a run of its own, with its own baseline, verdict and frames.

On pull requests, the comment groups locales and adds a Localization note: strings shown in the source language and labels that no longer fit, compared with the locale’s approved recording. They never block. A person approves each locale’s translation before its video is published, unless review: false.

The player picks the language from ?lang=, then the viewer’s browser, and offers a switcher. Not yet: per-locale help-center articles, and more than the source locale from stagewright ci.

stagewright ci now reports to the code host the pipeline runs for: one sticky comment with verdicts, before and after frames, clips and preview links, plus a status a branch policy can require. GitLab (including self-managed), Azure DevOps (Services and Server) and Bitbucket Cloud. stagewright ci --template gitlab prints a pipeline file to start from.

For staging only your network reaches, run Stagewright’s recorder container yourself. It opens no ports: it asks for work over outbound HTTPS, records, uploads to signed links and reports. Point an environment at it with runner: in stagewright.config.

Not yet: Bitbucket Data Center, and GitHub Enterprise Server outside the Action.

Courses already put walkthroughs in teaching order. Now a course can also be training: a hosted course page in the project’s brand, learners signed in from your app, learning paths per role, and knowledge checks drafted from the walkthrough that a person approves before learners see them.

When an approved UI change to a lesson publishes, certificates for that course need a refresh, and learners get a short “What changed” view of just those lessons. Release training drafts “What changed in this release” from the UI changes approved between two refs. SCORM and cmi5 packages stream the current recording, so a package doesn’t go stale in the LMS.

A filed regression now carries the clip of the failing step, the frame, the failing selector, the second run’s result and a trace, and the PR’s author can be assigned. The issue says how to hand the fix to a coding agent (/stagewright:fix ENG-42). When the fix PR says Fixes ENG-42, Stagewright replays the walkthrough on it and posts proven or not proven on the PR and the issue.

In Linear, delegate an issue to Stagewright (or mention it) to reproduce a bug on video, write a walkthrough, confirm a fix or ask whether something is covered. In Jira Cloud, a label or a /stagewright comment does the same. Comments sync both ways. This has run against stubbed Linear, Jira and GitHub APIs, not live workspaces yet.

Members get every download on the walkthrough and run pages; the public player offers only what the walkthrough file lists under downloads.public. Quick clips are presets in the walkthrough file, re-rendered on every publish so links always show the current product. stagewright export makes the same files from a local recording.

The CLI also sends four anonymous milestones (init, doctor passed, first recording, first video) so we can measure time to a first video before we publish a number. It’s off in CI and turns off with DO_NOT_TRACK=1.

Stagewright reads each connected help center’s articles and support conversations, decides which feature each article explains, and checks it against the product: ▲ failing when that feature’s walkthrough fails, ◐ stale when the UI changed after the article was last edited or it names a label the screens no longer have, ● fresh when it was checked against a current walkthrough, ○ not checked when nothing covers the feature yet.

Approving a run updates the linked article, as a draft for review by default. Conversations are kept only as redacted question clusters and counts. Every request shape comes from the vendors’ docs and has run against mocks; it hasn’t run against live Intercom or Zendesk accounts yet.

Recordings note each element a step clicks, types into or highlights. The render frames it (zoom keyframes can be edited in the walkthrough), and focus marks end where the next one begins. A brand section in stagewright.config sets the logo, colors and fonts used by title, section, bullet and end cards. Logos and fonts are fetched through the same public-address guard as everything else.

Step screenshots are taken from the same run as the video, so the image and the instructions come from one recording and are checked together. Typed secrets never reach still labels or page titles.

Like a visual-testing tool’s affected-only snapshots, Stagewright reads the PR’s changed files and runs the walkthroughs whose files, paths, anchors or mapped features they touch. Shared files run everything; when it can’t tell, it runs. Skipped walkthroughs keep their approved recording as the baseline.

Each re-recorded walkthrough gets a preview video and article, linked from the comment and posted as a Stagewright Preview deployment. The GitHub Action now posts the same comment, frames and clips as the GitHub App.

Setup, empty walkthrough lists, a feature with no guide, a failing run, settings that could live in the repo, CI: each offers a Copy prompt block for Claude Code, Codex or Cursor. stagewright prompt <name> prints the same text. Every prompt ends with the same ground rules: use Stagewright’s tools, never print secrets, and stop and ask before approving, publishing or pushing.