Reshot

Verified developer integration

Playwright Integration for Product Journeys

Register, execute, hash, review, and bind repository-owned Playwright source to a canonical Product Journey without rewriting native tests.

The Playwright Integration for Product Journeys preserves a working repository-owned Playwright path as native execution while binding its verified source contract to a canonical Reshot Journey. Reshot does not translate a test file into trusted product truth merely because an importer can parse it.

Reachable integration path

The current Journey activation workbench supports a repository/CI path. A user registers the repository, branch, test root, Playwright configuration, CI provider, test files, config files, fixtures, storage-state references, authentication setup, locators, assertions, traces, and visual checks needed to describe native execution.

The server runs the native Playwright workflow. Source bytes and storage-state contents are not persisted as public content. The resulting source contract records exact identity and a content hash.

Only native-run-passed source can proceed to reviewed canonical binding. Unsupported constructs remain protected source or a review candidate.

What Reshot preserves

The importer contract retains:

  • repository and project identity;
  • test, config, and fixture files;
  • native command and project name;
  • authentication setup and storage-state references;
  • locators and assertions;
  • trace references;
  • screenshot/visual-check references;
  • protected hooks or advanced code that cannot be safely rewritten;
  • source provenance and semantic hash.

The native execution command remains authoritative. Reshot does not silently replace it with generated steps.

Trust states

A discovered source begins as a candidate. It becomes native-run-failed when the repository workflow fails, unsupported when required semantics cannot be preserved, or native-run-passed when exact native execution succeeds.

Even a native pass is not a release Decision. The source must be bound to a Journey Version, declared state, context matrix, Observations, and Review.

State and secrets

Playwright storage state can contain cookies and credentials capable of impersonating an account. Keep it out of source control and public artifacts. Reshot records references and policy without publishing reusable contents.

Declare the broader State Capsule: actor, role, account scope, plan, data, flags, locale, theme, viewport, clock, dependencies, network policy, side effects, and cleanup. Browser isolation does not establish server-side state.

Execution and evidence

The Journey Run binds the source contract, immutable Journey Version, State Capsule, selected context cells, runner identity, attempts, timelines, and evidence. Functional, source-visual, automated/manual accessibility, state, target, privacy, policy, console, and network evidence remain distinct.

Infrastructure failure can retry under policy while preserving attempt history. Product, state, target, privacy, and policy failures are not retried into silence.

Review and release consequences

Reviewers decide exact subjects such as functional failure, visual change, accessibility barrier, state repair, target repair, accepted risk, privacy violation, downstream Publication impact, and release readiness.

Approved evidence can produce documentation, support, training, demo, and launch Renditions. Publications retain receipts. The Release Book can include the exact Run and Decisions.

Relationship to Playwright features

Playwright remains responsible for browser automation, projects, locators, assertions, isolation, reporters, traces, screenshot comparisons, and runner tooling. Reshot provides durable product-outcome identity and cross-functional lineage around supported execution.

Read the dated Reshot vs Playwright comparison for the division of responsibility.

Unsupported boundaries

Do not assume every custom fixture, global hook, third-party service, mobile/native workflow, browser extension, or proprietary reporter becomes editable Journey data. Unsupported source stays protected and visible. A real adapter must preserve semantics or fail closed.

Playwright execution support does not imply that every environment is safe for destructive or externally visible side effects. Use explicit authorization and cleanup.

Integration procedure

  1. connect the repository through the supported GitHub path;
  2. declare branch, test root, config, and native command;
  3. supply source references without exposing secret state;
  4. run native Playwright server-side;
  5. inspect unsupported constructs and source hash;
  6. bind the passed contract to a Journey draft;
  7. declare the State Capsule and representative contexts;
  8. run and inspect peer evidence;
  9. record Review Decisions;
  10. connect approved outward consequences.

Validation

The repository’s permanent tests verify that Playwright execution remains native and unrewritten, source files and contract evidence are preserved, imports remain unverified before binding, semantic round trips are stable, and insufficient source fails closed.

Those tests are implementation evidence. Completion still requires the real customer/developer path to create and persist the source contract and Journey binding.

First proof

Use one existing Playwright test for a release-critical outcome. Register and execute it without changing the native command. Confirm the source hash, bind the Journey, run two contexts, record a Decision, and update one dependent Publication. If any consequence exists only in a fixture, do not claim integration completion.

Continue with the GitHub integration, Stateful End-to-End Testing, and Product Journey Import, Export, and Portability.

Evaluate internal ownership and long-term operating cost in Playwright and Internal Systems vs Reshot.

Start with one release-critical Journey.

Define the outcome, declare its state, run it, inspect the evidence, and record the Decision before expanding coverage.