CI Recipes architecture

Scope & responsibilities

Curate deterministic CI pipeline templates for ingestion, scanning, policy evaluation, export, and notifications.
Capture provenance for each recipe (inputs, pinned tool versions, checksum manifests) and keep offline/air-gap parity.
Provide reusable fragments (YAML/JSON) plus guardrails (AOC checks, DSSE attestation hooks, Rekor/Transparency toggles).

Recipe catalogue (recipes.md) — Source of truth for pipeline snippets; sorted deterministically and annotated with required secrets/scopes.
Guardrail hooks — Inline steps for schema validation, SBOM/VEX signing, and attestation verification; reuse Authority/Signer/Export Center helpers.
Observability shim — Optional steps to emit structured logs/metrics to Telemetry Core when allowed; defaults to no-op in sealed/offline mode.
Offline bundle path — Scripts/guides to package recipes and pinned tool archives for air-gapped runners; hashes recorded in release notes.

All generated artifacts (templates, manifests, example outputs) must sort keys and lists, emit UTC ISO-8601 timestamps, and avoid host-specific paths.
DSSE/attestation helpers should target the platform trust roots defined in Authority/Sigstore docs; prefer BLAKE3 hashing where compatible.
Keep retry/backoff logic deterministic for reproducible CI runs; avoid time-based jitter unless explicitly documented.

Authority/Signer for DSSE + Rekor publication; Export Center for bundle assembly; Notify for preview hooks; Telemetry Core for optional metrics.
Recipes must remain compatible with CLI/SDK surface referenced in docs/modules/cli/guides/ and devportal snippets.

Track active work in docs/implplan/SPRINT_0315_0001_0001_docs_modules_ci.md and mirror statuses in ./TASKS.md.
When adding new recipes, include offline notes, determinism checks, and minimal test harness references in docs/benchmarks or tests/** as applicable.