/** * @fileoverview `sarif-export` subcommand mode helper (DEC-498, opensip * Phase 2/Phase 6). * * Builds the run's signal envelope (applying the OpenSIP rule-ID convention — * Option A — at assembly) and writes the SARIF v2.1.0 document to the * `--output-sarif ` file via the root-owned SARIF-file sink * (`cli.writeSarif`, ADR-0011 Phase 5). The opensip * `EngineSubprocessPort.runSarifExport` invokes this per commit-sync / * dead-code run, then lands the file on opensip's `SarifProvider`. Its * external behavior (the `--output-sarif` flag, byte-identical OpenSIP SARIF) * is unchanged: the canonical signal → SARIF formatter (`formatSignalSarif` in * `@opensip-cli/output`) emits the same bytes graph's former adapter did * once the envelope carries the OpenSIP-mapped rule IDs. * * Per ADR-0011 (file is a sink; the root renders/delivers), SARIF-to-file is a * root seam — graph no longer imports `@opensip-cli/output`. Validates the * provenance flags the consumer contract requires (`--tenant-id`/`--repo-id`) * so a misinvocation fails loudly (exit 2) rather than emitting an unscoped * file. */ import type { Signal, ToolCliContext } from '@opensip-cli/core'; /** Options consumed by the `sarif-export` subcommand. */ export interface SarifExportOptions { readonly outputSarif: string; readonly tenantId?: string; readonly repoId?: string; readonly runId?: string; } /** * Build the OpenSIP-convention SARIF envelope from the engine's findings and * write it to `opts.outputSarif` through the root-owned `cli.writeSarif` seam. * * `tenantId` / `repoId` are not embedded in the SARIF body today — the SARIF * shape carries no `properties` bag — but they are required at the boundary * (the opensip side always supplies them and scopes the ingest by them) and * `runId` is threaded into the log line for trace correlation. */ export declare function runSarifExportMode(opts: SarifExportOptions, signals: readonly Signal[], cli: ToolCliContext): Promise; //# sourceMappingURL=sarif-export.d.ts.map