Certified Targets

Certified Targets are the narrow, stricter promise for teams that need more than generic capture support. The goal is not to say every app is certified on first contact. The goal is to make the release gate explicit and repeatable.

What certified means

A certified target passes the same end-to-end path teams are expected 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.

Target contract

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

{
  "target": {
    "key": "my-app",
    "displayName": "My App",
    "tier": "certified",
    "owner": "Acme",
    "baseUrl": "http://localhost:3000",
    "captureSafe": false,
    "supportedLocalCommand": "npm run build && npm run start",
    "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 its own contract:

{
  "name": "playground-workflow",
  "steps": [
    { "action": "goto", "url": "/playground" },
    { "action": "capture", "key": "editor-loaded" }
  ],
  "requiredRoutes": ["/playground", "/api/playground"],
  "requiredSelectors": ["[data-testid='playground-page']"],
  "expectedArtifacts": ["editor-loaded", "preview-slide1"],
  "publishPolicy": "required"
}

Readiness rules

Certified targets need app-owned readiness signals. Sleeps can exist, but they cannot be the only readiness mechanism.

At minimum, a certified scenario should have one of:

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

Commands

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

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

When to use this

Use Certified Targets when:

• the capture path is already working
• the app needs a tighter release gate
• readiness, auth, and delivery need deterministic verification

For everyone else, the normal local-first and CI flow is still the right starting point.