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. 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.