Configure reporting for your project#

Configure the currently supported layers directly: reporter adapter composition and session lifecycle, catalog execution settings, runtime capabilities/hooks, report aggregation/comment policy, and export review.

Compose a reporting runtime#

Run the small configuration example to inspect composition and disposal, or open a full capture/diagnostic demonstration for opt-in collection controls.

@snagbadger/configuration supplies portable composition, selection and resolution. @snagbadger/reporting/session coordinates developer-supplied harvesters and capture adapters. Initialization resolves an immutable configuration without loading adapters; selected adapters acquire resources when a session starts. Dispose the runtime when the host no longer needs it.

import { composeConfiguration } from '@snagbadger/configuration';
import { createReportingRuntime } from '@snagbadger/reporting/session';

const configuration = composeConfiguration(
  { ui: { zIndex: 20 }, adapters: {} },
  { ui: { zIndex: 40 } },
);
const runtime = createReportingRuntime(configuration);
try {
  const session = runtime.start({});
  const result = await session.finish();
  console.log(
    runtime.configuration.ui.zIndex,
    result.evidence.length,
    result.cancelled,
  );
} finally {
  await runtime.dispose();
}

This empty session prints 40 0 false: later UI settings win, and no evidence is collected without selected adapters. It does not install collectors or mount a reporting interface. Registrations combine by stable ID within a category, with the last complete registration winning. removeAdapter removes a registration; replaceAdapters replaces a category. See the implemented configuration and lifecycle contracts for settings permissions, cancellation, isolated failures and complete fixture examples. Production built-in collectors remain separate work.

Establish result policy#

For direct module consumers, defaultRunPolicy requires an explicit retry summary choice. Choose latest, any-failure, or passed-on-retry according to what reviewers should see. Comment type and importance are independent configurable scales; optional helpers do not require adopting a fixed permission mode.

The bridge's current default keeps earlier failures visible through any-failure. Describe that policy alongside run results rather than assuming a later pass erases a failure.

Bind review and hooks#

The runtime JSON identifies capability claims and an optional trusted project module. That module can export configureTesting, or hook functions and reportPolicy directly. The factory receives library review helpers so the host need not duplicate serialization/redaction. Canonical configuration examples show the real binding shape.

Review policy applies to whole narrative/source snapshots and each attachment. Secrets stay in the environment and do not belong in Markdown, runtime capability attestations or exported HTML.

Separate routing from authorization#

Catalog destination metadata selects a provider/project pair; it is not transport, authentication or permission. A provider adapter resolves privileged credentials in its execution environment and identifies the authenticated submitter in its receipt.

The accepted configuration decision permits optional shared settings, customizable profiles and host-owned access. Its initSnagBadger/profile/selector examples are illustrative; do not import those names as shipped APIs.

Prototype appearance#

The maintained reporting prototype supports experimental appearance/branding interactions. Those UI tokens and in-memory controls do not establish a production initialization or persistence contract.

Use configuration reference to locate authoritative interfaces and project status for unimplemented boundaries.