# Configuration reference

Configuration exists at several supported boundaries. Reporter composition and initialization-time selection are implemented alongside the catalog/runtime/report contracts below.

| Boundary                 | Configures                                                                 | Authoritative contract                                                                            |
| ------------------------ | -------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- |
| Reporter adapters        | Composition, stable registration IDs, selection and immutable resolution   | [Configuration and session contracts](../../../architecture/reporting-contracts.md)               |
| Reporting plugins        | Capabilities, capture adapters, settings and repeated collection           | [Reporting plugins](../../../architecture/plugins.md)                                             |
| Test/section frontmatter | Executor, metadata, inherited instructions, evidence, destination, hooks   | [Catalog format](test-definition-format.md)                                                       |
| Runtime JSON             | Installed capability attestations and project configuration module         | [Runtime configuration](../../../integration/agent-testing.md#runtime-configuration)              |
| Trusted project module   | Function registry, hook behavior and `reportPolicy`                        | [Lifecycle hooks](../../../integration/agent-testing.md#lifecycle-hooks)                          |
| Run policy               | Retry-summary strategy, comment type/importance scales                     | [Portable result policy](../../../integration/portable-reports.md#results-comments-and-promotion) |
| Export options           | Export ID/time, attachment retrieval, named sanitization policy and limits | [Export review](../../../integration/portable-reports.md#sanitization-and-self-contained-export)  |

## Runtime declarations are attestations

Declare capabilities only after verifying the installed host tools. Fresh agents, new browser contexts, screenshots, video and diagnostics describe real operations available to the coordinator. A new page sharing storage is not an isolated context. [Runtime requirements](agent-skills-and-runtime-requirements.md) describes verification and limitations.

## Evidence requirements

Evidence settings are per executor and kind; requirements are `required`, `optional`, or `off`. Browser defaults require screenshot/video; API/CLI defaults require diagnostics. Sections/tests can override individual kinds. The maintained sample root makes video optional, while recorder cases can strengthen it.

Missing required proof produces an incomplete attempt; optional missing proof warns. Do not weaken policy after the fact to make a missing artifact appear verified.

## Host-owned security and delivery

Provider/project metadata is a destination hint. Credentials and authorization belong to the host/provider execution environment. Exported HTML must not carry privileged credentials. Review policy decides whether reviewed bytes can leave that environment.

The [accepted configuration direction](../../../architecture/configuration.md) specifies developer-composed settings, optional shared configuration, customizable profiles and host-owned identity/access. Its initializer/profile examples remain illustrative. Use the implemented `composeConfiguration`, `selectConfiguration`, `resolveConfiguration` and `createReportingRuntime` entries described in [configuration and session contracts](../../../architecture/reporting-contracts.md). Remote live configuration and storage remain deferred.

See [configure reporting](../guides/configure-reporting.md) for choosing the current boundaries and [public APIs](public-api.md) for implemented entries.

## Capture categories

Capture registrations can supply a category independently of their unique registration ID. Multiple registrations in one category are alternatives; choose one per enabled category. The first enabled registration in resolved order is the UI default. Use `captureCategories` from `@snagbadger/reporting/session` to discover them without loading adapters. Reusing the same registration ID still replaces that complete registration. Screenshot, steps and recording are separate categories; DOM replay and screen video are alternative recording methods. See the [capture experiment](../../../prototypes/capture-experiment.md) for current behavior and limitations.