Internal Study: One Journey Across Three Contexts

This is an internal Reshot dogfood study of one Journey across three contexts. It is not a customer case study, production performance claim, or claim that a fixture completed a customer path. The evidence comes from an actual execution of Reshot’s verification runtime plus its current context parsing and contract tests; the study shows what the maintained contract proves today and what still requires a live production Run.

The versioned raw execution artifact records three executed context cells, two successful owner contexts, and one deliberately blocked member context with a non-retryable functional failure. The public-calibration signature is tamper-evident but deliberately not a production trust credential.

The Journey under study

The outcome is: an authorized owner invites a member and the invitation reaches the intended pending state.

The durable identity used by the runtime capstone is journey-invite-editor, with Journey Version journey-invite-editor-v5. The implementation binds evidence to the Journey Version, Run, context cell, step, and Observation rather than attaching unscoped screenshots to a test title.

The contract includes the action that sends an invitation and an observable status checkpoint. Its execution sources preserve repository-owned Playwright locators, assertions, fixtures, authentication setup, trace references, and visual checks when imported through the supported runner path.

Three declared contexts

The current product path parses role, device, theme, and locale into a machine-safe context identity while preserving the human-readable declaration. The three study contexts are representative rather than exhaustive:

Context	Actor and role	Device and viewport	Theme	Locale	Why it changes meaning
A	owner	desktop, 1440×900	light	en-US	Reference authorized path and primary review context
B	owner	mobile, 390×844	dark	fr-FR	Responsive containment, translated copy, formatting, and dark-theme visual state
C	member	desktop, 1440×900	light	en-US	Permission boundary: a member must not silently inherit owner authority

Reshot’s parseDeclaredContext contract is exercised by automated tests for owner/mobile/dark/fr-FR and for explicit defaults when dimensions are absent. The Journey runtime separately models a Context Matrix with role, plan, locale, theme, viewport, and reduced-motion dimensions.

Expected outcomes by context

Context A is expected to complete the invitation action and expose the pending invitation checkpoint. Context B expects the same business outcome while allowing presentation differences caused by locale, viewport, and theme. Context C is intentionally an authorization boundary: the product should prevent an unauthorized member from completing the owner action and the Run should classify that outcome as a product or policy result according to the declared Journey contract—not retry it as generic flakiness.

These expectations keep “different pixels” separate from “different outcome.” A translated button label or mobile layout is not automatically a failure. A member acquiring owner authority is not a harmless visual difference.

Evidence model

The runtime capstone demonstrates peer evidence categories attached to a shared timeline:

• functional evidence for the invitation checkpoint;
• source-visual evidence connected to baseline Observation and comparison context hash;
• automated accessibility evidence with rule and component ownership;
• manual accessibility evidence with protocol and evaluator;
• state evidence for a role mismatch;
• target evidence for an unresolved interaction target;
• privacy evidence for a redaction-policy failure.

The evidence objects carry Run ID, Journey Version ID, context cell ID, step ID, Observation ID, capture time, status, and source references. That structure is the key proof. A screenshot, axe result, trace, or assertion becomes useful release evidence only when its identity and context are retained.

Failure classification

The study uses classification to prevent automatic retries from hiding meaning.

Observed condition	Classification	Response
Expected invitation status is absent after the action	product failure unless state/target evidence proves otherwise	Block and inspect the checkpoint evidence
Authenticated actor does not match the State Capsule	unauthorized state mismatch	Repair identity or correct the declared context; do not retry blindly
Declared target cannot be resolved	target failure	Repair the target contract and rerun the affected cell
Screenshot differs under the same comparison-context hash	visual change requiring intent review	Compare source/baseline Observations and record a Decision
Accessible name fails automated and manual evaluation	accessibility barrier	Assign ownership, remediate or issue a scoped expiring exception
Declared private value appears in retained evidence	privacy/policy failure	Quarantine evidence and block release publication

Infrastructure failures are retryable only when the runtime identifies an infrastructure exception. Explicit state mismatches are not converted into flaky passes.

Review and Decision

Reshot’s unified Review contract creates review subjects for functional failure, visual change, accessibility barrier, target repair, state repair, intended product change, exception or accepted risk, privacy or policy violation, downstream publication impact, and release readiness.

An effective Decision identifies the actor, authority, exact Journey and version, Run, evidence references, outcome, rationale, and time. Expired exceptions reopen the affected review work. This avoids a permanent green status based on a temporary exception or an earlier Journey Version.

What this study proves

The current code and tests prove that Reshot can:

• preserve the declared role, device, theme, and locale in a context identity;
• build a deterministic context matrix from declared dimensions;
• bind evidence to Journey, version, Run, context cell, step, and Observation;
• preserve functional, visual, automated/manual accessibility, state, target, and privacy evidence as peer records;
• classify state mismatch separately from retryable infrastructure failure;
• create attributable Review Decisions over exact evidence;
• keep native Playwright source and execution semantics during supported import.

What it does not prove

This study does not claim that all three contexts were executed against the live production service during this publication. The deterministic internal executor proves the Run, evidence-timeline, context-coverage, and failure-classification contracts; it does not prove the hosted UI outcome. The checked-in tests and runtime artifacts are supporting implementation evidence, not a substitute for a customer or production Run. It also does not establish browser-market coverage, defect-detection rates, time savings, or business outcomes.

The honest next proof step is to execute these three cells through the live supported Journey path, retain the resulting Observations, complete Review, and publish a sanitized receipt. Until then, this page remains an internal implementation study with a clearly stated evidence boundary.

Use Critical User Journey Testing to design the outcome, Stateful End-to-End Testing to declare context, and the Journey Coverage Calculator to track evidence, Decision, and lineage gaps separately.