Show the product beside the instruction

A real screenshot can make a guide’s instructions easier to recognize. The documentation asset contract distinguishes captured product imagery from a provisional placeholder, so an unfinished capture is not mistaken for proof of the interface.

Partially available today — the limit is described on this page.

A documentation page pairs written steps with an actual application capture; a separate outlined pending frame is visibly labelled Pending

Show the product beside the instruction

Example — Prepare a guide before its capture environment is ready

A guide reserves a labelled image position while a capture is pending. Once a configured browser capture succeeds, the resulting product image can replace the provisional asset through publication.

For engineers

The capture implementation needs application-owned bindings: base URL, semantic target path, authenticated storage state, landmark, font profile and allowed origins. These identify what it should capture and under whose session. A generic page URL alone is insufficient.

The capture seam returns bytes and a receipt without choosing a publication directory:

export interface TechnicalDocumentationCaptureExecutionResult {
  readonly receipt: TechnicalDocumentationCaptureReceiptV1;
  readonly outputBytes: Uint8Array;
}

export interface TechnicalDocumentationCaptureExecutionPort {
  execute(request: TechnicalDocumentationCaptureExecutionRequestV1): Promise<TechnicalDocumentationCaptureExecutionResult>;
}

These interfaces live on the technical-doc companion surface. TechnicalDocumentationCaptureExecutionRequestV1 and its receipt come from the specifications technical-documentation entrypoint. The Node-only Playwright implementation is deliberately separate from ordinary application runtime dependencies; application tooling binds the implementation when a suitable environment exists.

Bind semantic references to the capture environment

This illustrative wiring uses the actual constructor contract from the separate capture package. The resolver functions are application-owned and deliberately remain execution-only:

const bindings = new TechnicalDocumentationPlaywrightCaptureBindings(
  resolveApplicationBaseUrl,
  resolveTargetPath,
  resolveStorageStatePath,
  resolveLandmark,
  resolveFontProfile,
  resolveAllowedOrigins,
);

const capture = new TechnicalDocumentationPlaywrightCapture(bindings);
const { receipt, outputBytes } = await capture.execute(request);

Import the two classes from @wildo-ai/technical-documentation-capture. Supply a validated TechnicalDocumentationCaptureExecutionRequestV1: its definition names the semantic target, authentication-state reference, landmark, locale, viewport, theme, network policy and capture interactions. For example, the target resolver maps the declared target to the actual list route; the auth resolver supplies a temporary authenticated browser state; the landmark resolver supplies the test ID that must be visible before capture. Unknown references must fail resolution rather than capture a convenient default screen.

The bindings can contain secret-tainted storage paths and explicitly reject JSON serialization. The capture returns bytes in memory and a receipt; the publication transaction chooses where to write them. A declared request and a constructed adapter are not evidence that a browser captured the intended user state.

Decide whether provisional imagery may be published

A screenshot request without capture output can resolve to a recognizable placeholder. It remains a required asset with provisional status, not a successful observation. Publication can refuse provisional assets according to its acceptance options. Inspect the actual captured screen and receipt; deterministic diagrams have a separate production path and must not be described as screenshots.

Show the product beside the instruction