Certified Targets

This release introduces Certified Targets. The promise is narrow on purpose: Reshot is production-stable for a named set of target apps that satisfy a documented integration contract. We are not claiming that every arbitrary app is automatically certified on first contact.

Certified In This Release

• ClaraDB docs workflows for fixture-auth and live-auth documentation captures
• PaperJSX platform flows for public playground and authenticated dashboard captures
• Reshot reference platform flows for platform UI and hosted asset delivery verification

What “Certified” Means

A certified target passes the same pipeline we expect customers to trust:

1. Route audit
2. Readiness audit
3. Capture run
4. Publish
5. Pull or export verification
6. Hosted delivery verification
7. Live-auth smoke where required

If one of those stages fails, certification fails.

The Target Contract

Add a top-level target block to reshot.config.json:

{
  "target": {
    "key": "paperjsx-platform",
    "displayName": "PaperJSX Platform",
    "tier": "certified",
    "owner": "PaperJSX",
    "baseUrl": "http://localhost:3001",
    "captureSafe": false,
    "defaultAuthMode": "live-auth",
    "fixture": {
      "command": "node scripts/prepare-docs-fixture.mjs",
      "healthUrl": "/api/health"
    },
    "requiredEnv": ["PROJECT_ID"],
    "certificationScenarioKeys": ["playground-workflow", "dashboard-overview"]
  }
}

Each scenario can also declare a contract:

{
  "key": "playground-workflow",
  "url": "/playground",
  "captureClass": "public",
  "ready": {
    "selector": "[data-reshot-ready='playground-page-ready']",
    "expression": "window.__APP_READY === true"
  },
  "requiredRoutes": ["/playground", "/api/playground"],
  "requiredSelectors": [
    "[data-testid='playground-page']",
    "[data-testid='playground-generate-btn']"
  ],
  "needsWorkspaceInjection": false,
  "expectedArtifacts": ["editor-loaded", "preview-slide1"],
  "publishPolicy": "required"
}

Target Tiers

• certified: release-gated, deterministic, and expected to pass full end-to-end verification
• candidate: integrating toward certification; advisory diagnostics still run
• custom: supported by the generic CLI, but not part of the certified release promise

Readiness Rules

Certified targets must expose app-owned readiness. Sleeps can exist, but they cannot be the only readiness mechanism. At minimum, a certified scenario needs one of:

• ready.selector
• ready.expression
• a waitForSelector step backed by an app-owned selector

Selectors should be owned by the target app, typically through data-testid or data-reshot-* attributes.

Commands

Use the new CLI commands to validate the contract:

reshot doctor target
reshot verify publish --tag v1.0.0
reshot certify --tag v1.0.0

Reports are written to .reshot/reports/certification.json.

Candidate Onboarding

To move a target from candidate to certified, make sure it has:

• a deterministic readiness signal for every certified scenario
• a reproducible auth mode (public, fixture-auth, or live-auth)
• fixture hooks when stateful screenshots depend on seeded data
• publishable assets that resolve through the public hosted delivery contract
• no unclassified browser/runtime errors during capture

The fastest path is usually:

1. Add data-reshot-ready markers in the app.
2. Add requiredRoutes and requiredSelectors to the scenario contract.
3. Run reshot doctor target until readiness and route audits are green.
4. Run reshot verify publish until hosted delivery is green.
5. Promote the target tier from candidate to certified.