/**
 * `generate-sbom` capability (#606, epic #551 follow-up to #564's build
 * archive / #568's build ledger — closes the "produce" side #568 explicitly
 * deferred).
 *
 * One capability, artifact-type-keyed via the injectable `SbomGenerator`
 * (./sbom-generator.ts — mirrors ./cloud-executor.ts's `CloudExecutor`
 * pattern), so a build-producing component of *any* artifact type — image,
 * JAR, zip/Lambda package, or a bare source directory for a config-only
 * producer — generates its SBOM through the same verb. Never docker-only:
 * dispatch is on `input.artifactType`, not on which build capability
 * produced the artifact.
 *
 * Writes the result into the build-archive manifest as an `sbom`-kind entry
 * (../verbs/build-archive.ts), content-addressed and linked to its subject
 * artifact's digest via `subjectDigest` — the **universal home** for the
 * SBOM regardless of artifact type or registry availability. Registering the
 * SBOM as an OCI referrer for image artifacts at publish time is a separate,
 * later concern (the publish step/registry tooling's job, see
 * ../../lifecycle/build-ledger.ts's `ReferrerLookup` for the consume side);
 * this capability only ever writes the archive-carried copy, so it works
 * unconditionally — including the registry-less `load-image-on-host` path.
 *
 * Config-only / infra components have no built artifact and simply never
 * compose this step into their `deploy`/`build` phase — "skips cleanly" is
 * structural (no step to run), not a special case this module needs to
 * detect. Opt-out is the same: a component that wants no SBOM omits the
 * `generate-sbom` step from its composition.
 */
import type { Capability } from "../capability.js";
import { type BuildArchiveManifest } from "./build-archive.js";
import { type SbomArtifactType, type SbomDocument, type SbomFormat, type SbomGenerator } from "./sbom-generator.js";
export interface GenerateSbomInput {
    /** Which artifact type to generate an SBOM for — selects the `SbomGenerator` method dispatched to (image -> BuildKit/syft, jar -> syft/cyclonedx-maven, zip -> syft, dir -> syft/cdxgen). */
    artifactType: SbomArtifactType;
    /** Archive-relative (or local, for `dir`) path to the artifact being scanned — the archive entry's `path` for `image`/`jar`/`zip`, or a source directory for `dir`. An `archive:`-prefixed reference is accepted and stripped, matching `publish-image`'s `from` convention. */
    path: string;
    /** Digest of the artifact this SBOM describes (the `image`/`asset` archive entry's `digest`) — omitted for `dir` scans that precede any build (no artifact digest exists yet), in which case the SBOM entry's `subjectDigest` is left unset. */
    digest?: string;
    /** SBOM format to request. Defaults to `chant.config.ts`'s `sbom.format`, then `DEFAULT_SBOM_FORMAT` (SPDX) when neither this input nor project config says otherwise — see ./sbom-generator.ts. */
    format?: SbomFormat;
    /** Where the SBOM document is written inside the build archive (e.g. `"search.sbom.json"`). Defaults to `<path>.sbom.json`. */
    into?: string;
    /** Manifest to extend with this SBOM's entry, rather than starting a fresh one — the same accumulation convention `docker-build`'s `manifest` input uses (./build.ts), so a component's whole build phase (image + SBOM, or JAR + SBOM) shares one manifest. */
    manifest?: BuildArchiveManifest;
}
export interface GenerateSbomOutput {
    /** The generated SBOM document (format, media type, bytes, package count, generator) — see ./sbom-generator.ts. */
    sbom: SbomDocument;
    /** Where the SBOM was written inside the build archive. */
    archivePath: string;
    /** Content-addressed digest of the SBOM document's own bytes. */
    digest: string;
    /** The build archive's manifest, now including this SBOM's entry alongside whatever `input.manifest` already held. */
    manifest: BuildArchiveManifest;
}
/**
 * Generate an SBOM for a build-producing component's artifact (image, JAR,
 * zip, or source directory) via the artifact-type-keyed `SbomGenerator`, and
 * fold the result into the build-archive manifest as an `sbom`-kind entry
 * linked to the subject artifact's digest. Format defaults to
 * `DEFAULT_SBOM_FORMAT` (SPDX) when neither `input.format` nor the injected
 * generator overrides it — see ./sbom-generator.ts's module doc for the
 * full default-resolution story. `chant.config.ts`'s `sbom.format` (see
 * ../../config.ts's `ChantConfig.sbom` and `resolveSbomFormat`) is resolved
 * by the caller/orchestrator into `input.format` before this capability
 * runs, the same way env config is resolved before any other capability's
 * `run` (this module never imports ../../config.ts directly, matching how
 * no other verb module does either).
 *
 * No rollback: an already-generated SBOM sitting in the archive (or, later,
 * projected as a registry referrer) is immutable, content-addressed
 * evidence — nothing to compensate, the same opt-out `docker-build` and
 * `publish-image` already take for their own no-mutable-remote-state reason.
 */
export declare function createGenerateSbomCapability(generator?: SbomGenerator): Capability<GenerateSbomInput, GenerateSbomOutput>;
/** Default `generate-sbom` capability, backed by the process-wide default `SbomGenerator` — the hermetic lockfile backend (#630), so `dir`/`zip`/`jar` work with no tool installed; only `forImage` throws until `toolSbomGenerator` is injected. See ./sbom-generator.ts's `defaultSbomGenerator`. */
export declare const generateSbomCapability: Capability<GenerateSbomInput, GenerateSbomOutput>;
//# sourceMappingURL=sbom.d.ts.map