@intentius/chant 0.13.1 → 0.15.0

package/dist/components/verbs/build-archive.d.ts

@@ -0,0 +1,205 @@
+/**
+ * BuildArchive format — the self-contained bundle `docker-build` (and the
+ * other build-family verbs) write into (#564, epic #551 "4. Build archive +
+ * deferred publish"). See docs/components/build-archive.mdx.
+ *
+ * A build archive holds four kinds of contents, enumerated by one manifest:
+ *  - `image` — an image tarball in OCI layout (as `docker save` produces),
+ *    content-addressed by its digest.
+ *  - `template` — a synthesized deploy template (e.g. a CloudFormation
+ *    document) referenced by `cfn-deploy`'s `archive:<name>` convention
+ *    (see ../verbs/apply.ts's `CfnDeployInput.template`). Per #613, a
+ *    `template` entry is a first-class artifact with its own content
+ *    digest — peer to `image`/`asset` — so it can itself be the
+ *    `subjectDigest` a `sbom`-kind entry (specifically a config-BOM,
+ *    `bomKind: "config"`) is attached to.
+ *  - `asset` — any other published artifact (a jar, a zip) the `publish`
+ *    family's non-image backends (`publish-artifact`) promote.
+ *  - `sbom` — a Bill of Materials attached to another entry's digest (#606,
+ *    #613, epic #551 follow-up to #564/#568), written by either the
+ *    `generate-sbom` capability (./sbom.ts, a **software** BOM over an
+ *    image/jar/zip/dir) or the `extract-config-bom` capability
+ *    (./config-bom.ts, a **config-BOM** over a synthesized IaC template's
+ *    declared resources/nested stacks/external references). `bomKind`
+ *    distinguishes the two without introducing a separate entry kind — both
+ *    are content-addressed, digest-linked BOM documents, and every existing
+ *    `sbom`-kind consumer (`findSbomForSubject`, the build ledger) keeps
+ *    working unmodified for either kind. The archive is the **universal
+ *    home** for both: an image's SBOM may also be projected as an OCI
+ *    referrer at publish time (a registry-side convenience for `oras
+ *    discover`/`cosign tree`), but the archive-carried copy is what makes
+ *    non-image artifacts (a jar in S3, a zip, a template) and registry-less
+ *    deploys (`load-image-on-host`) work identically — no registry required
+ *    to read a build's BOM back.
+ *
+ * The manifest is itself content-addressed (`manifestDigest`, a stable hash
+ * over its entries) so two builds of the same inputs produce the same
+ * archive identity, and so a promoted digest can be traced back to exactly
+ * the manifest that produced it. Nothing here shells out or touches a real
+ * filesystem/docker daemon — manifest assembly is pure data, which is what
+ * lets `docker-build` (./build.ts) and `publish-image`/`load-image-on-host`
+ * (./publish.ts) build and promote an archive entirely through the injectable
+ * `CloudExecutor`, exercised in tests via `MockCloudExecutor` with no real
+ * disk/docker/AWS involved. The same is true of `generate-sbom` (./sbom.ts)
+ * and the injectable `SbomGenerator` (./sbom-generator.ts).
+ *
+ * Per #614, every `image`/`template`/`asset` entry also carries an honest,
+ * per-artifact `reproducibility` record and an optional `provenance`
+ * source->output link (see ./reproducibility.ts) — never a single blanket
+ * flag hoisted to the component, since a component that builds more than one
+ * artifact type (an image plus a synthesized template, say) has a different
+ * true answer for each.
+ */
+import type { ArtifactReproducibility, ProvenanceLink } from "./reproducibility.js";
+export type BuildArchiveEntryKind = "image" | "template" | "asset" | "sbom";
+/** One content-addressed item inside a build archive. */
+export interface BuildArchiveEntry {
+    /** What this entry is — an OCI-layout image tarball, a synthesized template, a non-image asset (jar/zip), or an SBOM. */
+    kind: BuildArchiveEntryKind;
+    /** Path of this entry inside the archive (what `cfn-deploy`'s `archive:<path>` and `publish-image`/`publish-artifact`'s `from` reference). */
+    path: string;
+    /** Content-addressed digest of this entry's bytes (`sha256:...`). Identity for promote-by-digest. */
+    digest: string;
+    /** Declared media type, mirroring the OCI conventions the epic references (`oras discover`/`cosign tree` attach to the same digest). Defaults are assigned per `kind` by `addArchiveEntry` when omitted. For a `kind: "sbom"` entry this is the SBOM's own media type (`application/spdx+json` or `application/vnd.cyclonedx+json`) — never hardcoded, always read from the `SbomDocument` that produced the entry (./sbom-generator.ts). */
+    mediaType?: string;
+    /**
+     * For a `kind: "sbom"` entry only: the digest of the artifact this SBOM
+     * describes (an `image`/`asset` entry's `digest` elsewhere in the same
+     * manifest) — the OCI "referrer subject" relationship, recorded uniformly
+     * here regardless of whether the backend that produced it was a BuildKit
+     * attestation or a `syft` scan (#606: "the backend owns HOW it attaches
+     * ... the archive manifest records it uniformly"). Absent for non-SBOM
+     * entries.
+     */
+    subjectDigest?: string;
+    /** For a `kind: "sbom"` entry only: number of packages/components the SBOM enumerates, when known — surfaced by `chant components status` without parsing the SBOM bytes. */
+    packageCount?: number;
+    /** For a `kind: "sbom"` entry only: which tool produced it (e.g. "syft", "buildkit") — surfaced alongside format/package count so status reports SBOM *source*. */
+    generator?: string;
+    /**
+     * For a `kind: "sbom"` entry only: whether this is a **software** BOM
+     * (over an image/jar/zip/dir's declared dependencies, ./sbom.ts) or a
+     * **config-BOM** (over a synthesized IaC template's declared resources +
+     * nested stacks + external references, ./config-bom.ts) (#613). Defaults
+     * to `"software"` when omitted, so every pre-#613 `sbom` entry (and every
+     * caller that never set this field) is unambiguously the software kind —
+     * this default must never change without a manifest version bump.
+     */
+    bomKind?: "software" | "config";
+    /**
+     * For an `image`/`template`/`asset` entry: the honest, per-artifact
+     * reproducibility basis (#614, see ./reproducibility.ts). Assigned a
+     * kind-appropriate default by `addArchiveEntry` when omitted — see
+     * `defaultReproducibility` — so every entry that can meaningfully carry a
+     * reproducibility claim gets one without every call site having to compute
+     * it. Absent for `sbom` entries, which describe another artifact rather
+     * than being one themselves.
+     */
+    reproducibility?: ArtifactReproducibility;
+    /**
+     * For an `image`/`template`/`asset` entry: the source ref/commit that
+     * produced this artifact's digest (#614). Optional — a caller that hasn't
+     * threaded through a source ref (e.g. a test fixture, or a build run
+     * outside a git checkout) simply omits it rather than fabricating one.
+     */
+    provenance?: ProvenanceLink;
+}
+/** The manifest of contents for one build archive — the "self-contained format" #564 asks for. */
+export interface BuildArchiveManifest {
+    /** Manifest schema version, so a future incompatible shape can be detected before being misread. */
+    version: 1;
+    /** Component this archive was built for. */
+    component: string;
+    /** ISO-8601 timestamp this manifest was assembled. */
+    createdAt: string;
+    /** Every image/template/asset this archive carries. */
+    contents: BuildArchiveEntry[];
+    /**
+     * Content-addressed digest of this manifest's own entries (`sha256:...`),
+     * stable across rebuilds of byte-identical inputs and independent of
+     * `createdAt` — so identical inputs produce the same archive identity even
+     * when built at different times, and a changed digest here always means
+     * changed contents, not merely a re-run.
+     */
+    manifestDigest: string;
+}
+/**
+ * Deterministic content digest over arbitrary string content. Same shape as
+ * the FNV-ish fake digest `MockCloudExecutor` uses, so tests can assert on it
+ * without a real `sha256` implementation. Exported so callers that need to
+ * digest content that never goes through the `CloudExecutor` (e.g. a
+ * synthesized template's serialized bytes, see ./build.ts's
+ * `addArchiveTemplate`) share this one algorithm rather than each defining
+ * their own. Production `image`/`asset` entries instead carry the real
+ * digest their producing capability already computed (e.g. `docker-build`'s
+ * `executor.docker.build` digest).
+ */
+export declare function contentDigest(input: string): string;
+/** Compute the aggregate `manifestDigest` over a set of entries — sorted by path so entry order never changes the digest, only content does. */
+export declare function computeManifestDigest(contents: BuildArchiveEntry[]): string;
+/** Start a new, empty manifest for `component`. Entries are added with `addArchiveEntry`. */
+export declare function createBuildArchiveManifest(component: string, opts?: {
+    now?: () => Date;
+}): BuildArchiveManifest;
+/**
+ * Add (or replace, by `path`) one entry and return a new manifest with
+ * `manifestDigest` recomputed. Pure/immutable so callers (and tests) can hold
+ * onto a manifest snapshot before/after a step without aliasing surprises.
+ *
+ * Assigns a kind-appropriate default `reproducibility` (#614,
+ * `defaultReproducibility`) when the caller omits one — `template` entries
+ * default to `deterministic-synthesis`, `image`/`asset` entries default to
+ * `best-effort`, and `sbom` entries get none. An explicit `entry.reproducibility`
+ * (e.g. a future reproducible-build-attested image) always wins over the
+ * default. `reproducibility`/`provenance` are never part of
+ * `computeManifestDigest`'s input — they describe the artifact, they are not
+ * content the artifact's identity depends on, so recording/correcting them
+ * later never perturbs `manifestDigest`.
+ */
+export declare function addArchiveEntry(manifest: BuildArchiveManifest, entry: BuildArchiveEntry): BuildArchiveManifest;
+/** Look up one entry by archive-relative path (the same path form `cfn-deploy`'s `archive:<path>` and `publish-image`'s `from` use). */
+export declare function findArchiveEntry(manifest: BuildArchiveManifest, path: string): BuildArchiveEntry | undefined;
+/**
+ * Strip the `archive:` prefix chant's step wiring uses
+ * (e.g. `cfn-deploy`'s `template: "archive:search.template.json"`) down to
+ * the manifest-relative path. Returns the input unchanged when it carries no
+ * such prefix (a plain filesystem path outside the archive).
+ */
+export declare function archiveRelativePath(ref: string): string;
+/** All `image`-kind entries in a manifest — what a publish backend has to choose from when `from` is ambiguous/omitted. */
+export declare function imageEntries(manifest: BuildArchiveManifest): BuildArchiveEntry[];
+/** All `sbom`-kind entries in a manifest, regardless of which artifact they describe (#606). */
+export declare function sbomEntries(manifest: BuildArchiveManifest): BuildArchiveEntry[];
+/**
+ * Find the archive-carried SBOM entry attached to a given artifact digest
+ * (an `image`/`asset` entry's `digest` elsewhere in the same manifest). This
+ * is the archive-native lookup ../../lifecycle/build-ledger.ts's
+ * `buildLedgerEntries` uses to surface "SBOM by digest" without any registry
+ * or `oras`/network access — the archive is the universal home for the SBOM
+ * regardless of artifact type (#606).
+ */
+export declare function findSbomForSubject(manifest: BuildArchiveManifest, subjectDigest: string): BuildArchiveEntry | undefined;
+/**
+ * Find the archive-carried **config-BOM** entry (`bomKind: "config"`)
+ * attached to a given template digest — the config-BOM analogue of
+ * `findSbomForSubject` (#613). A `template` entry's digest is computed the
+ * same way an `image`/`asset` entry's is (`contentDigest` over its bytes,
+ * see `addArchiveTemplate` in ./build.ts), so config-only/infra components
+ * with no software artifact still resolve a BOM by digest through the same
+ * lookup shape as every other artifact kind.
+ */
+export declare function findConfigBomForSubject(manifest: BuildArchiveManifest, subjectDigest: string): BuildArchiveEntry | undefined;
+/** All `template`-kind entries in a manifest — every synthesized IaC document the archive carries, each a first-class artifact with its own content digest (#613). */
+export declare function templateEntries(manifest: BuildArchiveManifest): BuildArchiveEntry[];
+/** All `asset`-kind entries in a manifest (non-image published artifacts — a jar, a zip). */
+export declare function assetEntries(manifest: BuildArchiveManifest): BuildArchiveEntry[];
+/**
+ * Every artifact entry in a manifest — `image`, `template`, and `asset`
+ * kinds, excluding `sbom` entries (which describe an artifact rather than
+ * being one) — the set #614's per-artifact reproducibility surface iterates
+ * over. Order is manifest insertion order; callers that need a stable order
+ * for display/JSON output sort by `path` themselves (mirroring
+ * `computeManifestDigest`'s own path-sort convention).
+ */
+export declare function artifactEntries(manifest: BuildArchiveManifest): BuildArchiveEntry[];
+//# sourceMappingURL=build-archive.d.ts.map

package/dist/components/verbs/build-archive.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"build-archive.d.ts","sourceRoot":"","sources":["../../../src/components/verbs/build-archive.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAmDG;AAIH,OAAO,KAAK,EAAE,uBAAuB,EAAE,cAAc,EAAE,MAAM,mBAAmB,CAAC;AAGjF,MAAM,MAAM,qBAAqB,GAAG,OAAO,GAAG,UAAU,GAAG,OAAO,GAAG,MAAM,CAAC;AAE5E,yDAAyD;AACzD,MAAM,WAAW,iBAAiB;IAChC,yHAAyH;IACzH,IAAI,EAAE,qBAAqB,CAAC;IAC5B,8IAA8I;IAC9I,IAAI,EAAE,MAAM,CAAC;IACb,qGAAqG;IACrG,MAAM,EAAE,MAAM,CAAC;IACf,6aAA6a;IAC7a,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB;;;;;;;;OAQG;IACH,aAAa,CAAC,EAAE,MAAM,CAAC;IACvB,6KAA6K;IAC7K,YAAY,CAAC,EAAE,MAAM,CAAC;IACtB,mKAAmK;IACnK,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB;;;;;;;;OAQG;IACH,OAAO,CAAC,EAAE,UAAU,GAAG,QAAQ,CAAC;IAChC;;;;;;;;OAQG;IACH,eAAe,CAAC,EAAE,uBAAuB,CAAC;IAC1C;;;;;OAKG;IACH,UAAU,CAAC,EAAE,cAAc,CAAC;CAC7B;AAED,kGAAkG;AAClG,MAAM,WAAW,oBAAoB;IACnC,oGAAoG;IACpG,OAAO,EAAE,CAAC,CAAC;IACX,4CAA4C;IAC5C,SAAS,EAAE,MAAM,CAAC;IAClB,sDAAsD;IACtD,SAAS,EAAE,MAAM,CAAC;IAClB,uDAAuD;IACvD,QAAQ,EAAE,iBAAiB,EAAE,CAAC;IAC9B;;;;;;OAMG;IACH,cAAc,EAAE,MAAM,CAAC;CACxB;AAiBD;;;;;;;;;;GAUG;AACH,wBAAgB,aAAa,CAAC,KAAK,EAAE,MAAM,GAAG,MAAM,CAOnD;AAED,gJAAgJ;AAChJ,wBAAgB,qBAAqB,CAAC,QAAQ,EAAE,iBAAiB,EAAE,GAAG,MAAM,CAI3E;AAED,6FAA6F;AAC7F,wBAAgB,0BAA0B,CAAC,SAAS,EAAE,MAAM,EAAE,IAAI,CAAC,EAAE;IAAE,GAAG,CAAC,EAAE,MAAM,IAAI,CAAA;CAAE,GAAG,oBAAoB,CAG/G;AAED;;;;;;;;;;;;;;GAcG;AACH,wBAAgB,eAAe,CAC7B,QAAQ,EAAE,oBAAoB,EAC9B,KAAK,EAAE,iBAAiB,GACvB,oBAAoB,CAatB;AAED,wIAAwI;AACxI,wBAAgB,gBAAgB,CAC9B,QAAQ,EAAE,oBAAoB,EAC9B,IAAI,EAAE,MAAM,GACX,iBAAiB,GAAG,SAAS,CAE/B;AAED;;;;;GAKG;AACH,wBAAgB,mBAAmB,CAAC,GAAG,EAAE,MAAM,GAAG,MAAM,CAEvD;AAED,2HAA2H;AAC3H,wBAAgB,YAAY,CAAC,QAAQ,EAAE,oBAAoB,GAAG,iBAAiB,EAAE,CAEhF;AAED,gGAAgG;AAChG,wBAAgB,WAAW,CAAC,QAAQ,EAAE,oBAAoB,GAAG,iBAAiB,EAAE,CAE/E;AAED;;;;;;;GAOG;AACH,wBAAgB,kBAAkB,CAChC,QAAQ,EAAE,oBAAoB,EAC9B,aAAa,EAAE,MAAM,GACpB,iBAAiB,GAAG,SAAS,CAE/B;AAED;;;;;;;;GAQG;AACH,wBAAgB,uBAAuB,CACrC,QAAQ,EAAE,oBAAoB,EAC9B,aAAa,EAAE,MAAM,GACpB,iBAAiB,GAAG,SAAS,CAI/B;AAED,sKAAsK;AACtK,wBAAgB,eAAe,CAAC,QAAQ,EAAE,oBAAoB,GAAG,iBAAiB,EAAE,CAEnF;AAED,6FAA6F;AAC7F,wBAAgB,YAAY,CAAC,QAAQ,EAAE,oBAAoB,GAAG,iBAAiB,EAAE,CAEhF;AAED;;;;;;;GAOG;AACH,wBAAgB,eAAe,CAAC,QAAQ,EAAE,oBAAoB,GAAG,iBAAiB,EAAE,CAEnF"}

package/dist/components/verbs/build.d.ts

@@ -0,0 +1,150 @@
+/**
+ * build family — source -> BuildArchive, keyed by artifact type.
+ * Fully cloud-agnostic (see docs/components/cloud-boundary). `docker-build` is
+ * a real implementation (#557, epic #551) built over the injectable
+ * `CloudExecutor` (./cloud-executor.ts) so tests never shell out to a real
+ * `docker` daemon. `zip-package` (via `zip`) and `jvm-build` (via `mvn`/the
+ * gradle wrapper) are real, run through the injectable `ProcessRunner`.
+ *
+ * `docker-build` also assembles the component's `BuildArchiveManifest`
+ * (#564, epic #551 "4. Build archive + deferred publish" — see
+ * ./build-archive.ts): every build appends an `image`-kind entry recording
+ * the archive path and digest it just produced, so the archive is
+ * self-describing (content-addressed, with a manifest of contents) rather
+ * than a bare tarball. `addArchiveTemplate` lets a caller fold synthesized
+ * deploy templates (e.g. CloudFormation JSON, already written into the
+ * archive by chant's existing synthesis step) into the same manifest, so one
+ * document enumerates every content kind the archive holds.
+ *
+ * Per #614, both entry points accept an optional `sourceRef` (a git sha, or
+ * `"<sha>:<path>"` for a monorepo subpath) that becomes the entry's
+ * `provenance` link. `image`/`template` entries otherwise default to their
+ * kind-appropriate `reproducibility` basis via `addArchiveEntry` — see
+ * ./reproducibility.ts.
+ */
+import type { Capability } from "../capability.js";
+import { type CloudExecutor } from "./cloud-executor.js";
+import { type ProcessRunner } from "./process-runner.js";
+import { type BuildArchiveManifest } from "./build-archive.js";
+export interface DockerBuildInput {
+    /** Build context directory. */
+    context: string;
+    /** Path to the Dockerfile, relative to `context`. Default: "Dockerfile". */
+    dockerfile?: string;
+    /** Build args passed to `docker build --build-arg`. */
+    buildArgs?: Record<string, string>;
+    /** Target stage for a multi-stage build. */
+    target?: string;
+    /** Where the produced image tarball is written inside the build archive. */
+    into: string;
+    /**
+     * Manifest to extend with this build's `image` entry, rather than starting
+     * a fresh one. Pass the manifest returned by a prior build/template step in
+     * the same archive (e.g. via `@Build.manifest` wiring) to accumulate one
+     * manifest across a component's whole build phase. Omit to start a new
+     * single-entry manifest for this build alone.
+     */
+    manifest?: BuildArchiveManifest;
+    /** Source ref/commit this build was run against (#614) — recorded as the entry's `provenance.sourceRef`. Omit when unknown (e.g. a build run outside a git checkout); no `provenance` is recorded in that case. */
+    sourceRef?: string;
+}
+export interface DockerBuildOutput {
+    /** Path of the produced image tarball (OCI layout) inside the build archive. */
+    archivePath: string;
+    /** Content-addressed digest of the built image (`sha256:...`). */
+    digest: string;
+    /** The build archive's manifest, now including this image's entry — content-addressed via `manifest.manifestDigest`. */
+    manifest: BuildArchiveManifest;
+}
+/**
+ * Build a container image from a Dockerfile into the build archive: `docker
+ * build`, tagged with a build-local reference derived from `into`, then
+ * `docker save`d to the archive path (OCI layout, per `docker save`'s output
+ * format). Records the produced tarball as an `image` entry in the archive's
+ * manifest (extending `input.manifest` when the caller threads one through,
+ * so a component with more than one image build accumulates a single
+ * manifest for the whole archive). No rollback — a local build produces no
+ * remote/mutable state to compensate; the archive path is simply not consumed
+ * further if a later step fails.
+ */
+export declare function createDockerBuildCapability(executor?: CloudExecutor): Capability<DockerBuildInput, DockerBuildOutput>;
+/** Default `docker-build` capability, backed by the real `CloudExecutor`. */
+export declare const dockerBuildCapability: Capability<DockerBuildInput, DockerBuildOutput>;
+export interface AddArchiveTemplateInput {
+    /** Where the synthesized template is written inside the build archive (e.g. `"search.template.json"`). */
+    path: string;
+    /** Serialized template content — its digest is computed from these exact bytes, so an unrelated re-synthesis with identical content keeps the same manifest digest. */
+    content: string;
+    /** Manifest to extend. Omit to start a new manifest holding just this template. */
+    manifest?: BuildArchiveManifest;
+    /** Source ref/commit this template was synthesized from (#614) — recorded as the entry's `provenance.sourceRef`. Omit when unknown; no `provenance` is recorded in that case. */
+    sourceRef?: string;
+}
+export interface AddArchiveTemplateOutput {
+    /** Content-addressed digest computed over `content`. */
+    digest: string;
+    /** The build archive's manifest, now including this template's entry. */
+    manifest: BuildArchiveManifest;
+}
+/**
+ * Fold one synthesized deploy template (e.g. the CloudFormation JSON chant's
+ * existing synthesis already produces) into a build archive's manifest as a
+ * `template`-kind entry, alongside the image(s) `docker-build` recorded. Not
+ * a registered capability — template synthesis is chant's existing `build`
+ * pipeline (see ../../build.ts), not a new deploy-time verb — so this is a
+ * plain function a build orchestration step calls directly to keep one
+ * manifest across every content kind the archive holds (image + templates).
+ * Exported alongside the build-family capabilities since it is the other
+ * half of "what goes in the manifest" `docker-build` documents above.
+ */
+export declare function addArchiveTemplate(input: AddArchiveTemplateInput): AddArchiveTemplateOutput;
+export interface ZipPackageInput {
+    /** Directory (or file list) to package. */
+    source: string;
+    /** Glob patterns to exclude from the archive. */
+    exclude?: string[];
+    /** Where the produced zip is written inside the build archive. */
+    into: string;
+}
+export interface ZipPackageOutput {
+    /** Path of the produced zip inside the build archive. */
+    archivePath: string;
+    /** Content hash of the zip (for promote-by-digest style referencing). */
+    digest: string;
+}
+/**
+ * Package a directory into a zip artifact (e.g. a Lambda deployment package)
+ * inside the build archive, via the `zip` CLI through the injectable
+ * `ProcessRunner`. Removes any prior `into` first so the archive is rebuilt from
+ * scratch (not appended to), then returns its content digest for
+ * promote-by-digest referencing.
+ */
+export declare function createZipPackageCapability(processRunner?: ProcessRunner): Capability<ZipPackageInput, ZipPackageOutput>;
+/** Default `zip-package` capability, backed by the real process runner. */
+export declare const zipPackageCapability: Capability<ZipPackageInput, ZipPackageOutput>;
+export interface JvmBuildInput {
+    /** Build tool driving the compile/package step. */
+    tool: "maven" | "gradle";
+    /** Project directory containing the build file. */
+    path: string;
+    /** Build tool goals/tasks to run. Default: tool-appropriate package goal. */
+    goals?: string[];
+    /** Where the produced jar is written inside the build archive. */
+    into: string;
+}
+export interface JvmBuildOutput {
+    /** Path of the produced jar inside the build archive. */
+    archivePath: string;
+    /** Content hash of the jar. */
+    digest: string;
+}
+/**
+ * Compile and package a JVM project (Maven or Gradle) into a jar in the build
+ * archive, via the build tool through the injectable `ProcessRunner`. Runs the
+ * package goal, copies the produced jar (skipping `-sources`/`-javadoc`
+ * classifiers) to `into`, and returns its content digest.
+ */
+export declare function createJvmBuildCapability(processRunner?: ProcessRunner): Capability<JvmBuildInput, JvmBuildOutput>;
+/** Default `jvm-build` capability, backed by the real process runner. */
+export declare const jvmBuildCapability: Capability<JvmBuildInput, JvmBuildOutput>;
+//# sourceMappingURL=build.d.ts.map

package/dist/components/verbs/build.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"build.d.ts","sourceRoot":"","sources":["../../../src/components/verbs/build.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AAEH,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,eAAe,CAAC;AAGhD,OAAO,EAAwB,KAAK,aAAa,EAAE,MAAM,kBAAkB,CAAC;AAC5E,OAAO,EAA2B,KAAK,aAAa,EAAE,MAAM,kBAAkB,CAAC;AAC/E,OAAO,EAIL,KAAK,oBAAoB,EAC1B,MAAM,iBAAiB,CAAC;AAKzB,MAAM,WAAW,gBAAgB;IAC/B,+BAA+B;IAC/B,OAAO,EAAE,MAAM,CAAC;IAChB,4EAA4E;IAC5E,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,uDAAuD;IACvD,SAAS,CAAC,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC;IACnC,4CAA4C;IAC5C,MAAM,CAAC,EAAE,MAAM,CAAC;IAChB,4EAA4E;IAC5E,IAAI,EAAE,MAAM,CAAC;IACb;;;;;;OAMG;IACH,QAAQ,CAAC,EAAE,oBAAoB,CAAC;IAChC,mNAAmN;IACnN,SAAS,CAAC,EAAE,MAAM,CAAC;CACpB;AAED,MAAM,WAAW,iBAAiB;IAChC,gFAAgF;IAChF,WAAW,EAAE,MAAM,CAAC;IACpB,kEAAkE;IAClE,MAAM,EAAE,MAAM,CAAC;IACf,wHAAwH;IACxH,QAAQ,EAAE,oBAAoB,CAAC;CAChC;AAED;;;;;;;;;;GAUG;AACH,wBAAgB,2BAA2B,CACzC,QAAQ,GAAE,aAAsC,GAC/C,UAAU,CAAC,gBAAgB,EAAE,iBAAiB,CAAC,CA0BjD;AAED,6EAA6E;AAC7E,eAAO,MAAM,qBAAqB,EAAE,UAAU,CAAC,gBAAgB,EAAE,iBAAiB,CAAiC,CAAC;AAIpH,MAAM,WAAW,uBAAuB;IACtC,0GAA0G;IAC1G,IAAI,EAAE,MAAM,CAAC;IACb,uKAAuK;IACvK,OAAO,EAAE,MAAM,CAAC;IAChB,mFAAmF;IACnF,QAAQ,CAAC,EAAE,oBAAoB,CAAC;IAChC,iLAAiL;IACjL,SAAS,CAAC,EAAE,MAAM,CAAC;CACpB;AAED,MAAM,WAAW,wBAAwB;IACvC,wDAAwD;IACxD,MAAM,EAAE,MAAM,CAAC;IACf,yEAAyE;IACzE,QAAQ,EAAE,oBAAoB,CAAC;CAChC;AAED;;;;;;;;;;GAUG;AACH,wBAAgB,kBAAkB,CAAC,KAAK,EAAE,uBAAuB,GAAG,wBAAwB,CAa3F;AAID,MAAM,WAAW,eAAe;IAC9B,2CAA2C;IAC3C,MAAM,EAAE,MAAM,CAAC;IACf,iDAAiD;IACjD,OAAO,CAAC,EAAE,MAAM,EAAE,CAAC;IACnB,kEAAkE;IAClE,IAAI,EAAE,MAAM,CAAC;CACd;AAED,MAAM,WAAW,gBAAgB;IAC/B,yDAAyD;IACzD,WAAW,EAAE,MAAM,CAAC;IACpB,yEAAyE;IACzE,MAAM,EAAE,MAAM,CAAC;CAChB;AAED;;;;;;GAMG;AACH,wBAAgB,0BAA0B,CAAC,aAAa,GAAE,aAAsC,GAAG,UAAU,CAAC,eAAe,EAAE,gBAAgB,CAAC,CAW/I;AAED,2EAA2E;AAC3E,eAAO,MAAM,oBAAoB,EAAE,UAAU,CAAC,eAAe,EAAE,gBAAgB,CAAgC,CAAC;AAIhH,MAAM,WAAW,aAAa;IAC5B,mDAAmD;IACnD,IAAI,EAAE,OAAO,GAAG,QAAQ,CAAC;IACzB,mDAAmD;IACnD,IAAI,EAAE,MAAM,CAAC;IACb,6EAA6E;IAC7E,KAAK,CAAC,EAAE,MAAM,EAAE,CAAC;IACjB,kEAAkE;IAClE,IAAI,EAAE,MAAM,CAAC;CACd;AAED,MAAM,WAAW,cAAc;IAC7B,yDAAyD;IACzD,WAAW,EAAE,MAAM,CAAC;IACpB,+BAA+B;IAC/B,MAAM,EAAE,MAAM,CAAC;CAChB;AAED;;;;;GAKG;AACH,wBAAgB,wBAAwB,CAAC,aAAa,GAAE,aAAsC,GAAG,UAAU,CAAC,aAAa,EAAE,cAAc,CAAC,CAmBzI;AAED,yEAAyE;AACzE,eAAO,MAAM,kBAAkB,EAAE,UAAU,CAAC,aAAa,EAAE,cAAc,CAA8B,CAAC"}

package/dist/components/verbs/cloud-executor.d.ts

@@ -0,0 +1,88 @@
+/**
+ * Injectable cloud I/O boundary for the *agnostic* capability implementations
+ * that remain in core: the `docker` build/push client and the Neo4j bolt-port
+ * probe. Every capability here that talks to a real tool goes through a
+ * `CloudExecutor` instead of shelling out directly, so production code gets a
+ * real, `child_process`/`net`-backed executor and tests get a
+ * `MockCloudExecutor` (./__tests__/mock-cloud-executor.ts) that records calls
+ * and returns canned results — no live docker, ever, in a test run.
+ *
+ * The AWS-specific clients (CloudFormation, ECS, Lambda, EMR, CodeDeploy, SSM
+ * host, S3, CloudFront, snapshot, ECR) used to live here too. They now live in
+ * the aws lexicon (`@intentius/chant-lexicon-aws/components`), contributed
+ * through the capability-plugin seam — see docs/components/cloud-boundary. The
+ * `docker` client stays in core because it is genuinely cloud-agnostic and
+ * shared: `docker-build` (agnostic) uses it here, and the aws lexicon's
+ * `publish-image` reuses the exported `realDocker` rather than duplicating it.
+ */
+import { exec } from "node:child_process";
+export declare const execFileAsync: typeof exec.__promisify__;
+export interface DockerBuildArgs {
+    context: string;
+    dockerfile?: string;
+    buildArgs?: Record<string, string>;
+    target?: string;
+    /** Tag applied to the built image so it can be referenced by name (e.g. saved to a tarball). */
+    tag: string;
+}
+export interface DockerSaveArgs {
+    /** Image reference to save (tag or digest). */
+    image: string;
+    /** Destination tarball path. */
+    outFile: string;
+}
+export interface DockerLoadArgs {
+    /** Tarball path to load. */
+    inFile: string;
+}
+export interface DockerTagArgs {
+    source: string;
+    target: string;
+}
+export interface DockerPushArgs {
+    /** Fully qualified image reference to push (registry/repo:tag). */
+    image: string;
+}
+export interface DockerClient {
+    /** Build an image from a Dockerfile; returns the built image's content digest. */
+    build(args: DockerBuildArgs): Promise<{
+        digest: string;
+    }>;
+    /** Save an image to an OCI/tarball archive on disk. */
+    save(args: DockerSaveArgs): Promise<void>;
+    /** Load an image tarball into the local docker store; returns the loaded image's digest. */
+    load(args: DockerLoadArgs): Promise<{
+        digest: string;
+    }>;
+    /** Tag a local image with an additional reference (e.g. before push). */
+    tag(args: DockerTagArgs): Promise<void>;
+    /** Push a tagged image to its registry; returns the pushed image's registry digest. */
+    push(args: DockerPushArgs): Promise<{
+        digest: string;
+    }>;
+    /** Inspect a remote image's manifest digest without pulling it (used to verify a promoted tag). */
+    remoteDigest(image: string): Promise<string>;
+}
+export interface Neo4jProbeArgs {
+    /** Cluster identifier — a comma-separated list of `host:port` bolt endpoints. */
+    cluster: string;
+}
+export interface Neo4jClusterClient {
+    /** Probe every member's bolt port; returns how many are reachable/healthy. */
+    probe(args: Neo4jProbeArgs): Promise<{
+        healthyCount: number;
+        total: number;
+    }>;
+}
+export interface CloudExecutor {
+    docker: DockerClient;
+    neo4j: Neo4jClusterClient;
+}
+export declare const realDocker: DockerClient;
+/** Build a `CloudExecutor` that shells out to the real `docker` CLI and probes real bolt ports. Never used in tests. */
+export declare function realCloudExecutor(): CloudExecutor;
+/** The default `CloudExecutor` each capability factory falls back to when none is supplied. */
+export declare function defaultCloudExecutor(): CloudExecutor;
+/** Sleep for `ms`. Shared by every polling capability (`wait-*`) between attempts. */
+export declare function sleep(ms: number): Promise<void>;
+//# sourceMappingURL=cloud-executor.d.ts.map

package/dist/components/verbs/cloud-executor.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"cloud-executor.d.ts","sourceRoot":"","sources":["../../../src/components/verbs/cloud-executor.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;GAgBG;AAEH,OAAO,EAAE,IAAI,EAAE,MAAM,oBAAoB,CAAC;AAI1C,eAAO,MAAM,aAAa,2BAAkB,CAAC;AAI7C,MAAM,WAAW,eAAe;IAC9B,OAAO,EAAE,MAAM,CAAC;IAChB,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,SAAS,CAAC,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC;IACnC,MAAM,CAAC,EAAE,MAAM,CAAC;IAChB,gGAAgG;IAChG,GAAG,EAAE,MAAM,CAAC;CACb;AAED,MAAM,WAAW,cAAc;IAC7B,+CAA+C;IAC/C,KAAK,EAAE,MAAM,CAAC;IACd,gCAAgC;IAChC,OAAO,EAAE,MAAM,CAAC;CACjB;AAED,MAAM,WAAW,cAAc;IAC7B,4BAA4B;IAC5B,MAAM,EAAE,MAAM,CAAC;CAChB;AAED,MAAM,WAAW,aAAa;IAC5B,MAAM,EAAE,MAAM,CAAC;IACf,MAAM,EAAE,MAAM,CAAC;CAChB;AAED,MAAM,WAAW,cAAc;IAC7B,mEAAmE;IACnE,KAAK,EAAE,MAAM,CAAC;CACf;AAED,MAAM,WAAW,YAAY;IAC3B,kFAAkF;IAClF,KAAK,CAAC,IAAI,EAAE,eAAe,GAAG,OAAO,CAAC;QAAE,MAAM,EAAE,MAAM,CAAA;KAAE,CAAC,CAAC;IAC1D,uDAAuD;IACvD,IAAI,CAAC,IAAI,EAAE,cAAc,GAAG,OAAO,CAAC,IAAI,CAAC,CAAC;IAC1C,4FAA4F;IAC5F,IAAI,CAAC,IAAI,EAAE,cAAc,GAAG,OAAO,CAAC;QAAE,MAAM,EAAE,MAAM,CAAA;KAAE,CAAC,CAAC;IACxD,yEAAyE;IACzE,GAAG,CAAC,IAAI,EAAE,aAAa,GAAG,OAAO,CAAC,IAAI,CAAC,CAAC;IACxC,uFAAuF;IACvF,IAAI,CAAC,IAAI,EAAE,cAAc,GAAG,OAAO,CAAC;QAAE,MAAM,EAAE,MAAM,CAAA;KAAE,CAAC,CAAC;IACxD,mGAAmG;IACnG,YAAY,CAAC,KAAK,EAAE,MAAM,GAAG,OAAO,CAAC,MAAM,CAAC,CAAC;CAC9C;AAID,MAAM,WAAW,cAAc;IAC7B,iFAAiF;IACjF,OAAO,EAAE,MAAM,CAAC;CACjB;AAED,MAAM,WAAW,kBAAkB;IACjC,8EAA8E;IAC9E,KAAK,CAAC,IAAI,EAAE,cAAc,GAAG,OAAO,CAAC;QAAE,YAAY,EAAE,MAAM,CAAC;QAAC,KAAK,EAAE,MAAM,CAAA;KAAE,CAAC,CAAC;CAC/E;AAID,MAAM,WAAW,aAAa;IAC5B,MAAM,EAAE,YAAY,CAAC;IACrB,KAAK,EAAE,kBAAkB,CAAC;CAC3B;AAcD,eAAO,MAAM,UAAU,EAAE,YA+BxB,CAAC;AA6BF,wHAAwH;AACxH,wBAAgB,iBAAiB,IAAI,aAAa,CAEjD;AAKD,+FAA+F;AAC/F,wBAAgB,oBAAoB,IAAI,aAAa,CAGpD;AAED,sFAAsF;AACtF,wBAAgB,KAAK,CAAC,EAAE,EAAE,MAAM,GAAG,OAAO,CAAC,IAAI,CAAC,CAE/C"}

package/dist/components/verbs/component-bom.d.ts

@@ -0,0 +1,103 @@
+/**
+ * Component-level BOM aggregation (#614, epic #551 follow-up to #613).
+ *
+ * A component may produce more than one leaf BOM: a software SBOM
+ * (./sbom.ts's `generate-sbom`, over an image/jar/zip/dir) for its built
+ * artifact, and/or an IaC config-BOM (./config-bom.ts's `extract-config-bom`)
+ * for its synthesized template. Each leaf BOM already validates as its own
+ * standalone SPDX/CycloneDX document (#613). This module composes every leaf
+ * BOM a component's build archive carries into **one** component-level BOM —
+ * a real assembly (CycloneDX `metadata.component` + nested `components` +
+ * `compositions` + `dependencies`, or SPDX `documentDescribes`-equivalent
+ * `CONTAINS`/`DEPENDS_ON` relationships), not a re-implementation of the
+ * writer: `aggregateComponentBom` below reads each leaf BOM's own structural
+ * inventory back out (it does not re-parse the leaf's serialized bytes) and
+ * hands the result to ./bom-writer.ts's `writeBom`, which gained
+ * `BomInput.subDocuments` support for exactly this purpose.
+ *
+ * **Why not just concatenate/parse the leaf documents' bytes.** The leaf BOM
+ * bytes are the source of truth for each artifact independently, but this
+ * module needs each leaf's package list as structured data to nest it
+ * correctly in the assembly — reparsing SPDX/CycloneDX JSON back into
+ * `BomPackage[]` would be a second, format-aware reader this codebase does
+ * not otherwise need. Callers therefore pass each leaf's already-known
+ * `BomPackage[]` (what `generate-sbom`/`extract-config-bom` built before
+ * calling `writeBom` themselves) plus the archive entry it produced — see
+ * `ComponentBomLeaf` below. A caller assembling a component's archive
+ * end-to-end has both on hand already; nothing here re-derives them from
+ * scratch.
+ *
+ * **Single-artifact = 1:1, multi-artifact = a real assembly.** A component
+ * with exactly one leaf BOM produces a component BOM whose only "assembly"
+ * is itself — see `aggregateComponentBom`'s single-leaf fast path, which
+ * still runs through the same writer and produces a valid document, just
+ * with an empty `subDocuments` composition (nothing to nest). A component
+ * with two or more leaves gets `subDocuments` populated, the real multi-leaf
+ * case #614 asks for.
+ *
+ * **Release-level rollup is out of scope here** (deferred per #614's note) —
+ * this module aggregates *within* one component's archive, never across
+ * components/releases.
+ */
+import type { BuildArchiveEntry, BuildArchiveManifest } from "./build-archive.js";
+import { type BomPackage } from "./bom-writer.js";
+import { type SbomDocument, type SbomFormat } from "./sbom-generator.js";
+/**
+ * One leaf BOM a component produced, ready to fold into the component-level
+ * aggregate. `entry` is the `sbom`-kind `BuildArchiveEntry` `generate-sbom`/
+ * `extract-config-bom` already wrote into the manifest (carries `bomKind`,
+ * `subjectDigest`, `packageCount`, `generator`); `packages` is the same
+ * `BomPackage[]` that capability built before calling `writeBom` for its own
+ * standalone document.
+ */
+export interface ComponentBomLeaf {
+    /** The `sbom`-kind manifest entry this leaf corresponds to (see `findSbomForSubject`/`findConfigBomForSubject`, ./build-archive.ts). */
+    entry: BuildArchiveEntry;
+    /** The leaf's own enumerated packages/components/resources. */
+    packages: BomPackage[];
+}
+export interface AggregateComponentBomInput {
+    /** Component name — becomes the aggregate BOM's subject name. */
+    component: string;
+    /** The build archive manifest this component's leaves live in — used to derive a stable subject id from `manifestDigest` and to validate that every leaf's `entry` actually belongs to this manifest. */
+    manifest: BuildArchiveManifest;
+    /** Every leaf BOM to compose. Order is preserved in the resulting `subDocuments`/nested components. Must be non-empty — a component with no BOM to aggregate has nothing for this function to do (see module doc's "skips cleanly" convention elsewhere in this directory). */
+    leaves: ComponentBomLeaf[];
+    /** BOM format for the aggregate document. Defaults to `DEFAULT_SBOM_FORMAT` (SPDX), same precedence convention as every other BOM-producing capability in this directory. */
+    format?: SbomFormat;
+    /** Clock override for deterministic tests. */
+    now?: () => Date;
+}
+export interface AggregateComponentBomOutput {
+    /** The composed component-level BOM document. */
+    bom: SbomDocument;
+    /** Total package/component count across every leaf (the sum `chant components status` surfaces, see ../../lifecycle/build-ledger.ts). */
+    totalPackageCount: number;
+    /** How many leaf BOMs were composed — 1 for a single-artifact component (still a valid document, just with nothing to nest), 2+ for a real multi-artifact assembly. */
+    leafCount: number;
+}
+/**
+ * Compose a component's leaf BOMs (a software SBOM and/or an IaC config-BOM,
+ * per `input.leaves`) into one component-level BOM via ./bom-writer.ts's
+ * assembly support (`BomInput.subDocuments`). Pure — no I/O, no manifest
+ * mutation; the caller decides whether/where to write the result to disk
+ * (mirroring `extract-config-bom`'s `outDir` convention) and whether to fold
+ * it back into the archive as its own entry.
+ *
+ * Throws if `input.leaves` is empty — aggregation over zero leaves is a
+ * caller bug (compose only when at least one BOM exists), not a case this
+ * function silently no-ops on.
+ */
+export declare function aggregateComponentBom(input: AggregateComponentBomInput): AggregateComponentBomOutput;
+/**
+ * Convenience for the common case: given a manifest that already carries
+ * `sbom`-kind entries (written by `generate-sbom`/`extract-config-bom`) and
+ * the `BomPackage[]` each one was built from (keyed by archive path, since
+ * that's the one stable identifier a caller has for "which leaf is this"),
+ * assemble the `ComponentBomLeaf[]` `aggregateComponentBom` expects. Kept
+ * separate from `aggregateComponentBom` itself so a caller that already has
+ * `ComponentBomLeaf[]` in hand (e.g. straight from the capabilities that just
+ * ran) can skip this lookup entirely.
+ */
+export declare function componentBomLeavesFromManifest(manifest: BuildArchiveManifest, packagesByPath: Map<string, BomPackage[]>): ComponentBomLeaf[];
+//# sourceMappingURL=component-bom.d.ts.map

package/dist/components/verbs/component-bom.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"component-bom.d.ts","sourceRoot":"","sources":["../../../src/components/verbs/component-bom.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAwCG;AAEH,OAAO,KAAK,EAAE,iBAAiB,EAAE,oBAAoB,EAAE,MAAM,iBAAiB,CAAC;AAE/E,OAAO,EAAY,KAAK,UAAU,EAAuB,MAAM,cAAc,CAAC;AAC9E,OAAO,EAAuB,KAAK,YAAY,EAAE,KAAK,UAAU,EAAE,MAAM,kBAAkB,CAAC;AAI3F;;;;;;;GAOG;AACH,MAAM,WAAW,gBAAgB;IAC/B,wIAAwI;IACxI,KAAK,EAAE,iBAAiB,CAAC;IACzB,+DAA+D;IAC/D,QAAQ,EAAE,UAAU,EAAE,CAAC;CACxB;AAED,MAAM,WAAW,0BAA0B;IACzC,iEAAiE;IACjE,SAAS,EAAE,MAAM,CAAC;IAClB,yMAAyM;IACzM,QAAQ,EAAE,oBAAoB,CAAC;IAC/B,+QAA+Q;IAC/Q,MAAM,EAAE,gBAAgB,EAAE,CAAC;IAC3B,6KAA6K;IAC7K,MAAM,CAAC,EAAE,UAAU,CAAC;IACpB,8CAA8C;IAC9C,GAAG,CAAC,EAAE,MAAM,IAAI,CAAC;CAClB;AAED,MAAM,WAAW,2BAA2B;IAC1C,iDAAiD;IACjD,GAAG,EAAE,YAAY,CAAC;IAClB,yIAAyI;IACzI,iBAAiB,EAAE,MAAM,CAAC;IAC1B,uKAAuK;IACvK,SAAS,EAAE,MAAM,CAAC;CACnB;AAKD;;;;;;;;;;;GAWG;AACH,wBAAgB,qBAAqB,CAAC,KAAK,EAAE,0BAA0B,GAAG,2BAA2B,CA4DpG;AAUD;;;;;;;;;GASG;AACH,wBAAgB,8BAA8B,CAC5C,QAAQ,EAAE,oBAAoB,EAC9B,cAAc,EAAE,GAAG,CAAC,MAAM,EAAE,UAAU,EAAE,CAAC,GACxC,gBAAgB,EAAE,CAIpB"}

package/dist/components/verbs/index.d.ts

@@ -0,0 +1,49 @@
+/**
+ * The starter verb set, grouped by family, per epic #551 and
+ * docs/components/capabilities.mdx. The pilot AWS leaves — `docker-build`,
+ * `publish-image`, `load-image-on-host`, `cfn-deploy`, `ecs-update-service`,
+ * `code-deploy`, `wait-for-stack`, `wait-steady-state`, `wait-cluster-healthy`
+ * — are real implementations over the injectable `CloudExecutor` (#557/#564,
+ * epic #551, see ./cloud-executor.ts); every other verb remains a typed stub
+ * (../capability.ts). `generate-sbom` (#606) is a real implementation over
+ * the injectable, artifact-type-keyed `SbomGenerator` (./sbom-generator.ts);
+ * `./lockfile-sbom-generator.ts` (#613) is a real, hermetic backend for it
+ * (lockfile/manifest parsing, no external tool), and `./tool-sbom-generator.ts`
+ * (#610) is a real, deep-scan backend for it (`syft`/`docker buildx --sbom`/
+ * `cyclonedx-maven`/`cdxgen`, shelling out through the injectable
+ * `ProcessRunner`, ./process-runner.ts). `extract-config-bom` (#613) parses a
+ * synthesized CloudFormation template, so it moved to the aws lexicon (#684);
+ * core keeps the agnostic SPDX/CycloneDX writer, ./bom-writer.ts, which both it
+ * and `generate-sbom` share. ./component-bom.ts
+ * (#614) composes a component's leaf BOMs into one component-level BOM over
+ * that same writer, and ./reproducibility.ts (#614) records per-artifact
+ * reproducibility + provenance on each `BuildArchiveEntry`. `publish-image`
+ * (#610) also gained a best-effort OCI-referrer attach step (`oras attach`,
+ * also via `ProcessRunner`) for a supplied SBOM/component BOM — see ./publish.ts.
+ * `sign`/`attest-provenance` (#622, ./sign.ts) are real implementations over
+ * the same injectable `ProcessRunner`: keyless-by-default `cosign sign`/
+ * `cosign attest` for signature + SLSA provenance, reusing #614's
+ * `ProvenanceLink` material. `verify` (#622, ./verify.ts) is the matching
+ * deploy-time gate — `cosign verify`/`verify-attestation` against a
+ * configured identity policy, mirroring ../../lint/policy.ts's `policyGate`.
+ */
+export * from "./build-archive.js";
+export * from "./build.js";
+export * from "./bom-writer.js";
+export * from "./sbom-generator.js";
+export * from "./sbom.js";
+export * from "./lockfile-sbom-generator.js";
+export * from "./tool-sbom-generator.js";
+export * from "./component-bom.js";
+export * from "./reproducibility.js";
+export * from "./sign.js";
+export * from "./verify.js";
+export * from "./vuln-scan.js";
+export * from "./vex.js";
+export * from "./license-policy.js";
+export * from "./vuln-gate.js";
+export * from "./wait-verify.js";
+export * from "./shell.js";
+export * from "./cloud-executor.js";
+export * from "./process-runner.js";
+//# sourceMappingURL=index.d.ts.map

package/dist/components/verbs/index.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../../src/components/verbs/index.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA4BG;AAEH,cAAc,iBAAiB,CAAC;AAChC,cAAc,SAAS,CAAC;AACxB,cAAc,cAAc,CAAC;AAC7B,cAAc,kBAAkB,CAAC;AACjC,cAAc,QAAQ,CAAC;AACvB,cAAc,2BAA2B,CAAC;AAC1C,cAAc,uBAAuB,CAAC;AACtC,cAAc,iBAAiB,CAAC;AAChC,cAAc,mBAAmB,CAAC;AAClC,cAAc,QAAQ,CAAC;AACvB,cAAc,UAAU,CAAC;AACzB,cAAc,aAAa,CAAC;AAC5B,cAAc,OAAO,CAAC;AACtB,cAAc,kBAAkB,CAAC;AACjC,cAAc,aAAa,CAAC;AAC5B,cAAc,eAAe,CAAC;AAC9B,cAAc,SAAS,CAAC;AACxB,cAAc,kBAAkB,CAAC;AACjC,cAAc,kBAAkB,CAAC"}