# Provider and harvester review

Use the installed runner's public configuration/reporting contracts and inspect its available exports. Resolve the provider and harvester plan for both reporting and agentic testing.

Before proposing destination inputs, recommending collection or verifying an
approved change, follow [the provider/harvester review guide](../../../../docs/integration/onboarding-reporting-review.md).
Use `tooling/onboarding/reporting-setup.mts`: inspect the actual installed
namespace with `recommendInstalledHarvesters`, construct the per-application
request and call `inspectReportingSetup`. Present its pending/blocked requirements,
actual schemas, inputs and collection disclosures for approval. Keep deterministic
validation in this seam; preserve host adapters and application-specific options.

## Provider project

Ask for file-based output, Linear, or Jira, suggesting an existing configured choice when available. Configure the local destination or request the actual tracker/project identifiers required by the adopter's adapter. A repository remote is not evidence of a Linear or Jira project. Preserve reusable destination settings while adapting each consumer's configuration through the supported resolver.

End users connect their provider accounts in the browser. Setup configures projects and policy; it does not log in on their behalf. The current SnagBadger checkout may only supply local export and provider seams. If live adapter/account support is unavailable, show the project configuration proposal and record the integration as pending; use a real host adapter when supplied. A mocked provider is not a verified connection.

If the button and Jira/Linear are selected, ask whether reporters share devices, such as a QA team sharing phones. If they do, offer disabled, optional, or mandatory account selection with account-specific PINs. Configure this only through supported provider/host policy. Where real policy support is absent, record the selected requirement as pending; visible fixture PINs do not secure accounts. Account connection and test-application authentication are separate workflows.

## Harvesters

Show recommended built-ins preselected, with collected-data and lifecycle explanations; let the user adjust them before final approval. The maintained package currently exports createBrowserHarvester, createAppHarvester, createHttpHarvester, and createWebSocketHarvester. Inspect the installed version before claiming additional adapters. HTTP instrumentation may cover fetch without covering every networking client; application context requires a host callback. Keep the existing session-only/default-off pre-recording policy unless the user explicitly changes it.

Detected state/query/network libraries are custom-harvester candidates when no real built-in exists. Obtain specific opt-in before starting each custom integration, then show concrete file/dependency/options changes for approval. Record both consent and concrete-change approval in the request; retain declined/pending candidates. Read the library's installed API and official documentation when designing it. Use the same public compatibility/plugin boundary as supplied integrations, bounded snapshots, sanitization and cleanup.

After approval, call `verifyReportingSetup` with the current review ID and approved
disposable-host probes for each selected consumer. Observe actual collection,
bounds/sanitization, inactive behavior, cleanup and failure isolation. Keep
metadata-only HTTP/WebSocket defaults, explicit content opt-in, default-off
pre-recording and memory-only SDK/extension recording data. Report missing app
callbacks, fetch-response and existing-socket/history limitations explicitly.
For user-selected local output, validate the actual reviewed bundle with
`verifyLocalReportingExport`. Configuration validity, observed collection and
provider connection are separate results; fixture adapters leave the last one
unverified. Feed partial results into the established user-directed recovery flow.