Reference — generated from the toolkit

Source of truth: toolkit/scaffold/ci/README.md. Edit it there; this page is regenerated on build.

Shared CI/CD pipeline template

The CI/CD pipeline standard made instantiable — the one pipeline shape every scaffolded repo inherits, so every product reaches production the same automated way. This directory is the shape: the canonical stage list, its mapping to the gates that consume each stage, and an annotated merge-gate workflow (merge-gate.example.yml, alongside this file) as policy-as-code. A concrete, runnable per-stack workflow lands with each golden-path stack selection from the radar — the shape is fixed now precisely so those workflows are ports, not designs.

The canonical stages

build → unit → static analysis → secrets scan → SCA → integration
      → artefact signing → ephemeral preview env → e2e → promote

Stage	What it produces	Consumed by
build	Compiled artefact + SBOM (CycloneDX)	Merge gate; SBOM travels to Production Readiness
unit	Test results + coverage on changed code, mutation score	Merge gate (thresholds as policy-as-code)
static analysis	Lint/format + SAST findings	Merge gate — zero critical SAST, never waivable
secrets scan	Zero-tolerance secret detection	Merge gate; the steady-state half of the secrets sweep
SCA	Dependency CVEs + licence check against the allowed list	Merge gate — zero criticals; new packages need the approval label
integration	Contract/integration test results	Merge gate
artefact signing	SLSA provenance on the exact artefact that will ship	Production Readiness
ephemeral preview env	A per-PR environment seeded with synthetic data (never production PII — UK GDPR applies to test estates too)	Substrate for e2e; reviewable evidence on the PR
e2e	End-to-end results against the preview env	Merge gate (per PR) and Production Readiness (per release)
promote	The deploy — prepared by the pipeline, authorised by a named human	Production Readiness; authorise-the-irreversible

Every stage is a gate condition, not decoration: the merge gate consumes the per-PR stages, Production Readiness consumes the per-release ones, and nothing reaches promote without the chain above it green.

Where DORA is emitted

The pipeline instruments itself — the four keys are emitted as events, never hand-reported (see the metrics framework):

• Deployment frequency — one event per successful promote.
• Lead time for change — first commit timestamp → promote timestamp, computed per change.
• Change-failure rate — a promote later linked to a rollback or incident marks the deployment failed; the linkage hook lives at promote.
• MTTR — incident-open → restoring promote; the pipeline emits the restore half, the incident tooling the open half.

The legacy estate's before-photo is taken manually once (DORA baseline); everything built on this template measures itself from the first deploy.

What lands later

• Per-stack workflows — one runnable workflow per adopted golden-path stack (build/test/lint commands, cache config, preview-env provisioning), added when the tech-selection pass locks each stack. Pending: stack selection.
• Concrete tool choices — SAST, SCA, secrets and mutation tooling are placeholders in merge-gate.example.yml until the tooling evaluation selects them. Pending: tooling selection.
• Thresholds — coverage and mutation numbers are policy decisions taken with evidence from the first builds, not defaults copied from a blog post. Pending: a human decision per the test pyramid standard.

Standards referenced: SLSA, DORA, CycloneDX, trunk-based development.