Product Journey Infrastructure for Engineering

Product Journey Infrastructure for Engineering keeps release-critical product outcomes connected to the code that implements them, the state required to reproduce them, the evidence produced by execution, the Decision that follows, and the documentation or media affected by the next change.

It does not replace unit, integration, API, or end-to-end frameworks. It gives the most important user outcomes a durable identity above those execution methods.

The engineering problem is larger than test execution

A test suite can be green while a release is still incomplete. The script may have reached its last assertion, but the wrong role received access, a confirmation was visually broken, a keyboard path became unusable, or the support procedure still shows the previous interface.

Engineering teams usually track these consequences in separate systems:

• Playwright or another framework owns executable steps;
• CI owns pass, fail, and retry state;
• visual review owns baselines;
• accessibility tooling owns mechanical findings;
• issue tracking owns approval and repair discussion;
• documentation and support own screenshots and procedures;
• product marketing recreates launch visuals and demos;
• release management compiles another checklist.

Reshot makes the Product Journey the shared identity across those records.

Start from the outcome contract

An engineering-owned Journey defines the result that must remain true, not only the browser instructions used to reach it. The contract includes actors, preconditions, branches, checkpoints, context policy, allowed side effects, dependencies, and ownership.

For example, “invite an editor” is not complete when the Send button responds. The intended recipient must receive a valid invitation for the correct workspace and role, and accepting it must create the expected membership. The Journey checkpoint expresses that consequence.

Every material edit creates an immutable Journey Version. Earlier Runs, evidence, and Decisions continue to resolve to the exact version they evaluated.

Keep native developer work portable

The developer front door supports code-defined Journeys, native Playwright discovery and import, the CLI, CI execution, APIs, webhooks, and repository writeback. Protected code constructs stay visible when the same Journey is edited through a visual surface.

The current CLI exposes a canonical workflow:

reshot journey discover .
reshot journey import <playwright-config>
reshot journey validate <journey-id>
reshot journey run <journey-id>
reshot journey review <journey-id>
reshot journey publish <journey-id>

Use reshot journey --help for exact options. The open Product Journey Contract publishes the versioned identity and definition schemas behind the round trip.

Make product state explicit

Authenticated flows depend on more than cookies. Role, permissions, plan, data, feature flags, locale, timezone, theme, viewport, clock, and side-effect policy can all change a result.

A State Capsule declares those conditions before execution. That makes state reviewable, keeps secrets separate from state policy, and lets a failed Run explain whether the product, target, environment, authentication, or seed data violated the contract.

For implementation guidance, read Stateful End-to-End Testing.

Inspect one evidence timeline

A Run executes one Journey Version under declared contexts. Its Observations keep functional, visual, accessibility, product-state, console, network, provenance, and privacy evidence attached to the same attempt.

Engineering does not have to infer the relationship among a CI failure, a screenshot diff, an accessibility finding, and a network error from separate dashboards. The evidence remains distinct but shares one Run and Journey identity.

Classify failures before retrying

Automatic retry is appropriate for a bounded infrastructure failure. It is dangerous when it converts a real product or policy failure into a later green run.

Reshot keeps failure classes explicit:

Failure class	Engineering consequence
Product	The intended outcome did not hold; fix or consciously decide the change.
State	The declared actor, data, permissions, plan, flag, or clock was not reconstructed.
Target	The automation could not reliably identify the intended product element or interface.
Infrastructure	Runner, browser, network, or provider execution failed within retry policy.
Policy	The Run or requested side effect violated an explicit boundary.
Privacy	Required evidence could not be retained or delivered under privacy policy.
Recipient	The action reached the wrong actor, workspace, role, or downstream destination.

Only the class that actually occurred should drive retry, repair, or release policy.

Turn Review into an engineering consequence

Review receives the exact selected Run, context, step, difference, and evidence. An attributable Decision records approval, rejection, repair, exception, or release consequence separately from comments and AI suggestions.

That Decision updates the owning Journey and can identify downstream material that is still current, safely refreshable, or requires editorial Review. Engineering can see the customer-facing impact of a code change before release rather than waiting for a stale help-center report.

Connect releases to outward work

Approved Observations can become documentation screenshots, step guides, support procedures, walkthroughs, in-product guidance, support clips, training, interactive demos, marketing visuals, and captioned product video.

Those Renditions preserve source lineage while allowing editorial changes. Publications retain delivery receipts and freshness. A Release Book presents changed Journeys, evidence, Decisions, accepted risks, outputs, and ownership from the same object graph.

Collaborate without making the repository the only interface

Product engineers can preserve native source and code-only constructs. QA, support, documentation, accessibility, and product marketing can work through visual surfaces over the same Journey. Unsupported edits remain locked or create explicit conflicts instead of silently rewriting developer work.

This is the engineering value of one round-trippable contract: shared product semantics without forcing every collaborator to use the same authoring tool.

When this solution fits

Product Journey Infrastructure is a strong fit when:

• the product has release-critical authenticated or stateful workflows;
• changes affect more than one team or outward artifact;
• test flakiness and state ambiguity consume engineering time;
• CI results need attributable release consequences;
• developers need code ownership without excluding non-developers;
• screenshots, guides, demos, or support procedures must remain tied to current product truth.

It is not a substitute for broad unit coverage, low-level performance profiling, exploratory research with real users, or every specialized compliance judgment.

Begin with one release-critical Journey

Choose one outcome whose failure would block or qualify a release. Define its actor, checkpoint, State Capsule, and representative contexts. Run it, inspect the evidence, and record the Decision before expanding coverage.

Explore Journeys, review Critical User Journey Testing, or measure the current gap with the Journey Coverage Calculator.

Apply Product Journey Release Verification, test across meaningful contexts, and diagnose end-to-end failures without flattening their evidence.