rcf-lite 0.13.0 → 0.14.0

package/blueprints/delivery-ci-workflows/contributions/adrs/adr-706-delivery-ci-workflows-branch-model-defaults.json

@@ -0,0 +1,25 @@
+{
+  "adrId": "ADR-706-delivery-ci-workflows-branch-model-defaults",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "2.0.0",
+  "status": "accepted",
+  "title": "branchModel defaults to feature; trunk is a first-class option; both share the check catalogue and report shape",
+  "context": "The operator ruling names feature-branch as the good default standard and trunk-based as an option to support. The workflow set differs across the two shapes at the trigger and merge-policy level but shares the check catalogue and the report shape. A branch-model policy that is not stated as an ADR risks silent drift when a project migrates between shapes.",
+  "decision": "The blueprint sets `branchModel: feature` as the default when the project supplies a profile alias that composes it (`smallLibrary`, `smallService`, `internalPackage`). Trunk-based is a first-class option elicited by `branchModel: trunk` with a nested `trunkPullRequests` sub-shape (`never`|`sometimes`, default `never`). Both branch models share the check catalogue (mandatory tier plus every `checkSet` flag) and the report shape (per-gate JSON + aggregate); they differ only in the workflow trigger set and the merge-policy AC binding. `branchModel` is deliberately NOT minted as a global topic because a sibling blueprint has no legitimate opinion on branch model; if evidence emerges to the contrary, the topic can be minted global in a v2.x minor bump.",
+  "consequences": "A project migrating between branch models changes the elicitation surface, not the check catalogue or the report shape. The merge-policy AC binds a different property per shape (default-branch protection on a PR aggregate; trunk push protection on a commit aggregate), keeping the two shapes explicit without duplicating the check contracts. The topic-not-minted decision keeps the composition surface clean until a case for the global is made.",
+  "alternativesConsidered": [
+    {
+      "name": "Ship trunk-based as a project-level override of a feature-branch default",
+      "summary": "The default is feature; a trunk project supersedes the branch-model choice with a project-level ADR.",
+      "reasonNotChosen": "Trunk-based is not a workaround around feature-branch; it is a distinct workflow shape widely adopted in high-throughput teams. Treating it as an ADR override signals second-class status the operator ruling does not intend."
+    },
+    {
+      "name": "Mint `branchModel` as a global topic to force resolution with composing blueprints",
+      "summary": "A sibling blueprint that opines on branch model conflicts here; a project-level ADR resolves.",
+      "reasonNotChosen": "No sibling blueprint has a legitimate opinion on branch model (a `security-*` blueprint's scope is orthogonal to branch model choice). Minting the global creates a resolution surface for a conflict no shipped or plausible blueprint would generate."
+    }
+  ],
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

package/blueprints/delivery-ci-workflows/contributions/adrs/adr-707-delivery-ci-workflows-release-workflow-shape.json

@@ -0,0 +1,25 @@
+{
+  "adrId": "ADR-707-delivery-ci-workflows-release-workflow-shape",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "2.0.0",
+  "status": "accepted",
+  "title": "The release workflow scales across four discrete modes (none, tagOnly, tagPlusArtefact, deployHandoff); releaseMode absent means no release workflow (Q6-B)",
+  "context": "A release workflow that only ever ships a maximum shape punishes projects with no release path; a release workflow that scales continuously along an infinite axis is not testable. The operator ruling names a scaled release workflow whose shape follows the project shape; the ratified spec fixes the four discrete modes and (per Q6-B) leaves `releaseMode` OPTIONAL, meaning an absent field signals no release workflow at all.",
+  "decision": "The release workflow shape is fixed at four discrete modes: `none` (no release workflow ships), `tagOnly` (release entity only), `tagPlusArtefact` (artefact-publish step added), `deployHandoff:<slug>` (promote workflow invocation added). `releaseMode` is OPTIONAL in the elicitation surface (Q6-B ratification): an absent field has the same effect as `releaseMode: none`, meaning no release workflow ships. Not having a release flow yet is a common scenario when starting a project; requiring an explicit `none` value would impose paperwork on a case the ratification chose to make ergonomic. A field that IS present must carry one of the four enumerated values; an unrecognised value flips the boot-check to fail. The mode enumeration is stable across a major version; adding a fifth mode is a major bump. The four modes cover the maturity range from internal package (no release) to paired service (deploy handoff).",
+  "consequences": "A project chooses a release mode once; the workflow set follows. Excluding the required check set from the release workflow avoids the redundant run-and-lengthen pattern the ratified spec calls out. The manifest boot-check on `deployHandoff:<slug>` prevents a handoff to an unapplied deploy target; the cross-blueprint composition works because the deploy blueprint's promote-workflow shape is already ratified.",
+  "alternativesConsidered": [
+    {
+      "name": "Ship a continuous release-workflow-complexity dial rather than four discrete modes",
+      "summary": "The elicitation surface accepts a numeric level; the workflow-materialiser interpolates.",
+      "reasonNotChosen": "Continuous dials are neither legible nor testable; four discrete modes cover the maturity range with named archetypes the operator can reason about."
+    },
+    {
+      "name": "Fold the artefact-publish step into a separate blueprint",
+      "summary": "A `delivery-artefact-publish` blueprint contributes the artefact step; this blueprint stays at tagOnly.",
+      "reasonNotChosen": "The artefact-publish step is trivially small when named as an AC contract (produce a verified artefact at a stable identifier); minting a whole blueprint for it costs more than the contract does. A future security-provenance blueprint can compose here on `releaseArtefacts`."
+    }
+  ],
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

package/blueprints/delivery-ci-workflows/contributions/adrs/adr-708-delivery-ci-workflows-provider-hint-shape.json

@@ -0,0 +1,25 @@
+{
+  "adrId": "ADR-708-delivery-ci-workflows-provider-hint-shape",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "2.0.0",
+  "status": "accepted",
+  "title": "providerHint selects which provider's illustrative asset set the blueprint ships; v2.0.0 ships GHA only",
+  "context": "v1 shipped one illustrative GitHub Actions workflow and a four-point mapping doc for GitLab CI, CircleCI, Buildkite, and Jenkins. v2 has three or four workflows in the matrix. Shipping full asset sets for every provider would triple or quadruple the asset payload; shipping for none would leave every operator writing YAML from a mapping table.",
+  "decision": "v2.0.0 ships illustrative assets for `providerHint: githubActions` only (one workflow file per workflow in the matrix). Every other `providerHint` value is accepted at the elicitation surface but does not seed provider assets; operators using those providers translate the GHA assets per the four-point mapping doc, which extends to cover the full matrix at v2.0.0. Shipping per-provider full asset sets is a v2.1 candidate driven by demand.",
+  "consequences": "The asset payload stays small; the AC contracts (provider-neutral by design) remain the load-bearing surface. Projects on GHA get a working starting point; projects on other providers get the same starting point after the mapping doc's four-point translation. A sibling asset pack (an npm package materialising other providers' YAML from the same `workflowShape`) can ship independently.",
+  "alternativesConsidered": [
+    {
+      "name": "Ship full asset sets for every provider at v2.0.0",
+      "summary": "Five provider directories, four workflow files each.",
+      "reasonNotChosen": "Twenty asset files to keep in sync across v2.x bumps for demand that is currently unproven for four of the five providers."
+    },
+    {
+      "name": "Ship no illustrative assets and rely on the mapping doc",
+      "summary": "Every operator writes their own YAML from the AC contracts and the mapping doc.",
+      "reasonNotChosen": "v1 shipped a GHA workflow because the working example carries the AC contracts more clearly than the doc alone; removing that reference regresses the operator experience for the majority provider."
+    }
+  ],
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

package/blueprints/delivery-ci-workflows/contributions/adrs/adr-709-delivery-ci-workflows-release-artefacts.json

@@ -0,0 +1,25 @@
+{
+  "adrId": "ADR-709-delivery-ci-workflows-release-artefacts",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "2.0.0",
+  "status": "accepted",
+  "title": "The releaseArtefacts global topic names the decision area of what the release workflow produces on a release trigger",
+  "context": "The v2 release workflow ships four discrete modes governing what the workflow produces on a release trigger (nothing, a tag, a tag plus artefact, or a tag plus artefact plus deploy handoff). The choice of what a project releases is a decision area a future release-notes blueprint or an artefact-provenance blueprint would also opine on. Naming the decision area as a scope:global topic reserves the string for composition; scope-local answers this blueprint contributes (the `releaseMode` enumeration) are the concrete answers.",
+  "decision": "The blueprint mints a new global topic `releaseArtefacts` (exact string, lowerCamelCase, one concept per topic, no version suffix). ADR-709 (this ADR) is the delivery-ci-workflows contribution on that topic and states the four-mode release shape as the delivery-side answer. Future composing blueprints (a `security-release-provenance` blueprint minting a signature-attestation opinion, a `delivery-release-notes` blueprint minting a changelog opinion, an `observability-release-tracking` blueprint minting a deployment-marker opinion) contribute their own scope:global ADR on the same string; the mechanism's conflict detector surfaces the pairing; expected resolution is one project-level ADR that fixes the extended answer.",
+  "consequences": "The composition surface for release artefact decisions is reserved; a future provenance or notes blueprint does not have to mint a new string. The topic is category-agnostic by design; a security-side or observability-side blueprint contributing here is not misusing the delivery category. `branchModel` is deliberately NOT minted as a topic because no shipped or plausible sibling blueprint has a legitimate opinion on branch model; if that changes, `branchModel` can be added in a v2.x minor bump.",
+  "alternativesConsidered": [
+    {
+      "name": "Do not mint a new global topic",
+      "summary": "The release workflow's output shape is a scope-local decision only; future composing blueprints coordinate at the project level.",
+      "reasonNotChosen": "A future provenance blueprint's opinion on artefact signatures overlaps with the delivery-side artefact-publish step; leaving the topic unminted means the conflict-detector cannot surface the pairing. Minting the string reserves the composition surface without forcing an answer."
+    },
+    {
+      "name": "Mint the topic string as `releaseWorkflow` instead",
+      "summary": "The name spans the whole workflow, not only its artefact production.",
+      "reasonNotChosen": "The workflow includes trigger and orchestration decisions that are delivery-side by nature; the ARTEFACT is the piece a security or observability blueprint would opine on. Naming the topic narrowly keeps the composition surface aligned with the plausible composers."
+    }
+  ],
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

package/blueprints/delivery-ci-workflows/contributions/adrs/adr-710-delivery-ci-workflows-scheduled-audit.json

@@ -0,0 +1,25 @@
+{
+  "adrId": "ADR-710-delivery-ci-workflows-scheduled-audit",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "2.0.0",
+  "status": "accepted",
+  "title": "scheduledAudit is a top-level optional fifth dimension on workflowShape, defaulting to false",
+  "context": "The scheduled-audit workflow catches drift (dependency updates, secret rotations) that does not coincide with a merge. Whether to ship it is genuinely optional and does not fit cleanly under the four elicited dimensions. Two shapes considered: a fifth top-level field, and a nested cadence flag under `checkSet.securityScan.cadence`.",
+  "decision": "A fifth top-level field `scheduledAudit: boolean` (default `false`) governs whether the `scheduled-audit` workflow ships. When true, the workflow runs the same required check set the commit-triggered workflows run on a cron cadence and writes to a distinct aggregate report path (`.rcf/reports/ci/scheduled-audit.json`). When false or absent, no scheduled workflow ships. If future need arises for scheduled cadence on other checks, the field generalises to `scheduledCadence: string` accepting cron expressions without displacing the fifth dimension.",
+  "consequences": "The scheduled-audit dimension is explicit and independent of any specific check; the aggregate report path is distinct so scheduled-run outcomes never overwrite commit-triggered outcomes. Adopting the scheduled workflow is one boolean flip; opting out is the default. The forward path to a `scheduledCadence` generalisation is clear.",
+  "alternativesConsidered": [
+    {
+      "name": "Fold under `checkSet.securityScan.cadence`",
+      "summary": "A nested cadence flag on the security-scan check governs whether the scan runs on cron.",
+      "reasonNotChosen": "Conflates the check kind with its cadence; a project that wants the linter (not the security scan) on a cron cadence would need a second nested cadence field, blowing up the check-set shape."
+    },
+    {
+      "name": "Ship the scheduled-audit workflow always on",
+      "summary": "Every shape gets a scheduled workflow by default.",
+      "reasonNotChosen": "Small projects with no dependency exposure do not need scheduled scans; running them by default wastes CI minutes and lengthens noise."
+    }
+  ],
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

package/blueprints/delivery-ci-workflows/contributions/requirements/delivery-ci-workflows-req-001.json

@@ -0,0 +1,18 @@
+{
+  "reqId": "delivery-ci-workflows-REQ-001",
+  "prdId": "PRD-001",
+  "title": "The materialised commit-triggered workflows run the required check set on every trigger event the branch model defines",
+  "description": "The commit-triggered workflows the materialiser produces (per REQ-014 for feature-branch and REQ-015 for trunk-based) run the required check set on every trigger event the elicited branch model defines: for feature-branch, pushes to the default branch and pull requests targeting the default branch; for trunk-based, pushes to the trunk branch (and, in the sub-shape where `trunkPullRequests: sometimes`, pull requests targeting the trunk branch). The workflows' aggregate exit status is the merge criterion: the branch protection or equivalent policy refuses to admit a change whose most recent aggregate run did not exit zero, per the merge-policy AC binding for the branch model in play (AC-6114-3, AC-6115-1, AC-6115-2). No manual override path bypasses the required check set; a hotfix that skips it requires a documented ADR trail.",
+  "category": "functional",
+  "domain": "continuous-integration",
+  "priority": "must",
+  "rationale": "Gates that run sometimes are gates that fail sometimes. Binding the required check set to every trigger event the branch model defines turns the RCF chain and the elicited checks from a habit into a build property, and removes the class of drift where a chain-authoring seat's fix passes locally but the tree ships already broken. The branch-model dimension controls the trigger set; the merge-policy AC per shape is what wires the aggregate into the platform surface.",
+  "tags": [
+    "blueprint:delivery-ci-workflows",
+    "category:01-required-check"
+  ],
+  "version": "2.0.0",
+  "status": "approved",
+  "createdAt": "2026-08-24T00:00:00Z",
+  "updatedAt": "2026-08-24T00:00:00Z"
+}

package/blueprints/{ci-pipeline/contributions/requirements/ci-pipeline-req-002.json → delivery-ci-workflows/contributions/requirements/delivery-ci-workflows-req-002.json}

@@ -1,5 +1,5 @@
 {
-  "reqId": "ci-pipeline-REQ-002",
+  "reqId": "delivery-ci-workflows-REQ-002",
   "prdId": "PRD-001",
   "title": "The gate suite is invoked as one Node entry point that is CI-provider-neutral",
   "description": "The project realises a single Node entry point script that runs every RCF gate in order. The entry point is a plain Node process invoked by whatever runner the project's CI provider ships (GitHub Actions job step, GitLab job script, CircleCI step, Buildkite command, Jenkins stage). The CI-provider job definition contains one invocation line and the standard Node and package-manager setup steps; every gate-specific piece of logic lives in the Node entry point.",
@@ -8,7 +8,7 @@
   "priority": "must",
   "rationale": "A gate suite spelled in one CI provider's runner language locks the project to that provider and makes local reproduction of a CI failure expensive. A Node entry point is portable across every provider that can run Node, local machines included, and keeps the gate logic under one source-controlled file the project's own tests can cover.",
   "tags": [
-    "blueprint:ci-pipeline",
+    "blueprint:delivery-ci-workflows",
     "category:02-provider-neutral"
   ],
   "version": "1.0.0",

package/blueprints/{ci-pipeline/contributions/requirements/ci-pipeline-req-003.json → delivery-ci-workflows/contributions/requirements/delivery-ci-workflows-req-003.json}

@@ -1,5 +1,5 @@
 {
-  "reqId": "ci-pipeline-REQ-003",
+  "reqId": "delivery-ci-workflows-REQ-003",
   "prdId": "PRD-001",
   "title": "The suite runs the schema-and-reference validation gate and refuses on non-zero exit",
   "description": "The Node entry point invokes `rcf define validate` as a required gate. The gate runs with the project's tree at the pull request's head commit. A non-zero exit code from `rcf define validate` terminates the suite and marks the aggregate result as failed. The failing invocation's stdout and stderr are captured to the gate report file so the reviewer can read the specific schema or reference issue without re-running the gate.",
@@ -8,7 +8,7 @@
   "priority": "must",
   "rationale": "Schema and cross-reference integrity is the floor every other gate stands on: `rcf audit coverage --strict` cannot answer honestly against a tree with broken references. Running `rcf define validate` first, failing fast on non-zero exit, and preserving its output for the reviewer is the shape that makes the mechanism useful in review, not just at author time.",
   "tags": [
-    "blueprint:ci-pipeline",
+    "blueprint:delivery-ci-workflows",
     "category:03-validate-gate"
   ],
   "version": "1.0.0",

package/blueprints/{ci-pipeline/contributions/requirements/ci-pipeline-req-004.json → delivery-ci-workflows/contributions/requirements/delivery-ci-workflows-req-004.json}

@@ -1,5 +1,5 @@
 {
-  "reqId": "ci-pipeline-REQ-004",
+  "reqId": "delivery-ci-workflows-REQ-004",
   "prdId": "PRD-001",
   "title": "The suite runs the per-AC strict coverage gate and refuses on non-zero exit",
   "description": "The Node entry point invokes `rcf audit coverage --strict` as a required gate. The gate runs against the tree at the pull request's head commit and reports per-AC coverage: every AC on every US must resolve to a TC whose testPointer points at a real test. A non-zero exit code (mechanism exit 4 on gaps) terminates the suite and marks the aggregate result as failed. The strict-flag invocation is the sole coverage mode the suite runs; shallow-any is not accepted as a substitute.",
@@ -8,7 +8,7 @@
   "priority": "must",
   "rationale": "Shallow-any coverage will declare a REQ covered when any AC on any US has any resolving TC, which is exactly the shape the watchpost run4 icon and token gap slipped through. Per-AC strict coverage is what makes the mechanism refuse to declare a shipped floor met while any AC still floats without a resolving TC.",
   "tags": [
-    "blueprint:ci-pipeline",
+    "blueprint:delivery-ci-workflows",
     "category:04-strict-coverage-gate"
   ],
   "version": "1.0.0",

package/blueprints/{ci-pipeline/contributions/requirements/ci-pipeline-req-005.json → delivery-ci-workflows/contributions/requirements/delivery-ci-workflows-req-005.json}

@@ -1,17 +1,17 @@
 {
-  "reqId": "ci-pipeline-REQ-005",
+  "reqId": "delivery-ci-workflows-REQ-005",
   "prdId": "PRD-001",
   "title": "Each gate writes a machine-readable JSON report file at a stable path on every invocation",
-  "description": "Every gate the suite invokes writes a JSON report file at a stable relative path under a project-configured report directory (default `.rcf/reports/ci/`). The per-gate report file is written whether the gate passed or failed. The report file carries the gate name, the underlying CLI invocation, the exit code, the start and end ISO-8601 timestamps, the duration in milliseconds, the tool version invoked, and the captured stdout and stderr strings. The report file's schema is stable within a blueprint major version.",
+  "description": "Every gate the suite invokes writes a JSON report file at a stable relative path under a project-configured report directory (default `.rcf/reports/ci/`). The per-gate report file is written whether the gate passed or failed. The report file carries the gate name, the underlying CLI invocation, the exit code, the start and end ISO-8601 timestamps, the duration in milliseconds, the tool version invoked, the captured stdout and stderr strings, and (v2 addition) a `checkKind` field naming the elicited-check kind (`validate`, `coverage-strict`, `linter`, `formatter`, `typecheck`, `unitTest`, `securityScan`, or `custom:<name>`). The report file's schema is stable within a blueprint major version; v1 additive fields (the `checkKind` addition) are preserved from v1.0.0 to v2.0.0.",
   "category": "functional",
   "domain": "continuous-integration",
   "priority": "must",
   "rationale": "A gate that only leaves human-readable text behind forces the reviewer to re-run it to answer any question the log did not surface. A stable JSON report at a stable path turns the gate's outcome into review-time data: what version of the tool ran, how long it took, what did it print. A downstream reader (a coverage-trend dashboard, an audit log) picks up the report by file path without needing to parse the CI provider's own artefact API.",
   "tags": [
-    "blueprint:ci-pipeline",
+    "blueprint:delivery-ci-workflows",
     "category:05-per-gate-report"
   ],
-  "version": "1.0.0",
+  "version": "2.0.0",
   "status": "approved",
   "createdAt": "2026-08-24T00:00:00Z",
   "updatedAt": "2026-08-24T00:00:00Z"

package/blueprints/{ci-pipeline/contributions/requirements/ci-pipeline-req-006.json → delivery-ci-workflows/contributions/requirements/delivery-ci-workflows-req-006.json}

@@ -1,5 +1,5 @@
 {
-  "reqId": "ci-pipeline-REQ-006",
+  "reqId": "delivery-ci-workflows-REQ-006",
   "prdId": "PRD-001",
   "title": "The suite emits an aggregate pipeline report summarising every gate's outcome at a stable path",
   "description": "The suite writes a single aggregate JSON report at a stable path under the same report directory (default `.rcf/reports/ci/pipeline.json`). The aggregate report carries the suite's own start and end ISO-8601 timestamps, the total duration, an overall pass/fail verdict, the fixed ordered list of gates the suite ran, and for each gate an entry naming the gate, its outcome, its duration, and the relative path to the per-gate report file. The aggregate schema is stable within a blueprint major version.",
@@ -8,7 +8,7 @@
   "priority": "must",
   "rationale": "The per-gate reports are the detail; the aggregate report is the single record the reviewer reads first. Its stable path and stable schema make the pipeline's verdict pluckable by any downstream reader (a merge-queue tool, a dashboard, an audit trail) without knowing the gate set or its ordering.",
   "tags": [
-    "blueprint:ci-pipeline",
+    "blueprint:delivery-ci-workflows",
     "category:06-aggregate-report"
   ],
   "version": "1.0.0",

package/blueprints/{ci-pipeline/contributions/requirements/ci-pipeline-req-007.json → delivery-ci-workflows/contributions/requirements/delivery-ci-workflows-req-007.json}

@@ -1,5 +1,5 @@
 {
-  "reqId": "ci-pipeline-REQ-007",
+  "reqId": "delivery-ci-workflows-REQ-007",
   "prdId": "PRD-001",
   "title": "Gate failures produce operator-readable output naming the failing gate and pointing to the per-gate report",
   "description": "When any gate in the suite fails, the Node entry point writes an operator-readable failure summary to its own stderr and to the aggregate report's `failure` field. The summary names the failing gate, the failing invocation's exit code, the first few lines of the captured stderr, and the relative path to the per-gate report file the reviewer can open for the full detail. The suite continues past a failing gate to run the remaining required gates and record their outcomes; the aggregate exit is non-zero if any gate failed.",
@@ -8,7 +8,7 @@
   "priority": "must",
   "rationale": "A failed CI job shows the reviewer the tail of the runner's own output. If the failing gate does not surface its name and its report path in that tail, the reviewer clicks around the provider's UI to find the artefact. Naming the gate and its report path in the surface the reviewer already sees is the fix. Continuing past a failing gate matters because a reviewer running two failing gates should see both, not just the first.",
   "tags": [
-    "blueprint:ci-pipeline",
+    "blueprint:delivery-ci-workflows",
     "category:07-failure-surfacing"
   ],
   "version": "1.0.0",

package/blueprints/{ci-pipeline/contributions/requirements/ci-pipeline-req-008.json → delivery-ci-workflows/contributions/requirements/delivery-ci-workflows-req-008.json}

@@ -1,5 +1,5 @@
 {
-  "reqId": "ci-pipeline-REQ-008",
+  "reqId": "delivery-ci-workflows-REQ-008",
   "prdId": "PRD-001",
   "title": "The suite refuses to declare a pipeline pass when any required gate report is missing from the aggregate",
   "description": "The aggregate report's `gates` array lists every required gate in fixed configured order. If the suite completes without a corresponding per-gate report on disk for any required gate (a runner crash, an unhandled exception in a gate invocation, a report directory that was not writable), the aggregate report records the missing gate as `missing` with an explanatory reason, the aggregate verdict is `failed`, and the suite exits non-zero. A missing report is never treated as an implicit pass.",
@@ -8,7 +8,7 @@
   "priority": "must",
   "rationale": "The failure mode this REQ closes is silent gate skipping: a runner that dies mid-suite, a gate whose Node child process was killed, a report-directory permission error that swallowed the write. Any of those is indistinguishable from 'the gate passed' unless the suite explicitly refuses on missing reports. The aggregate report is the sole ledger of what actually ran.",
   "tags": [
-    "blueprint:ci-pipeline",
+    "blueprint:delivery-ci-workflows",
     "category:08-missing-gate-refusal"
   ],
   "version": "1.0.0",

package/blueprints/delivery-ci-workflows/contributions/requirements/delivery-ci-workflows-req-009.json

@@ -0,0 +1,18 @@
+{
+  "reqId": "delivery-ci-workflows-REQ-009",
+  "prdId": "PRD-001",
+  "title": "The blueprint ships illustrative GitHub Actions workflow files for every workflow the matrix materialises; alternate providers wire the same entry points per the four-point mapping",
+  "description": "The blueprint's package resources include one illustrative GitHub Actions workflow file per workflow the v2 matrix materialises (`pull-request-checks.yml`, `default-branch-checks.yml`, `release.yml`, and `scheduled-audit.yml` under `assets/ci-provider-examples/github-actions/`). Each file names the required trigger set for its workflow, sets up Node and the package manager, installs dependencies, invokes the corresponding Node entry point (gate-runner for the check-set workflows, release orchestrator for the release workflow, scheduled-audit runner for the cron workflow), and uploads the report directory as a workflow artefact. The blueprint's guide names GitLab CI, CircleCI, Buildkite, and Jenkins as equally supported providers, calls out the four-point mapping (job trigger, Node setup, single-line entry-point invocation, artefact upload) applied to each workflow in the matrix, and states that the blueprint does not ship provider-specific configuration for those runners in v2.0.0; sibling asset packs (v2.1 candidate) can ship them without changing the AC contracts.",
+  "category": "functional",
+  "domain": "continuous-integration",
+  "priority": "must",
+  "rationale": "One worked example per workflow spelled in one runner language is more useful to the reader than a matrix of half-specified examples across five providers. GitHub Actions is the illustrative pick because it is the most widely deployed among rcf-lite candidate projects, not because it is privileged. The four-point mapping applies uniformly across the workflow set; extending the mapping doc to cover three or four workflows instead of one is a linear amount of writing, not a combinatorial one.",
+  "tags": [
+    "blueprint:delivery-ci-workflows",
+    "category:09-provider-examples"
+  ],
+  "version": "2.0.0",
+  "status": "approved",
+  "createdAt": "2026-08-24T00:00:00Z",
+  "updatedAt": "2026-08-24T00:00:00Z"
+}

package/blueprints/{ci-pipeline/contributions/requirements/ci-pipeline-req-010.json → delivery-ci-workflows/contributions/requirements/delivery-ci-workflows-req-010.json}

@@ -1,5 +1,5 @@
 {
-  "reqId": "ci-pipeline-REQ-010",
+  "reqId": "delivery-ci-workflows-REQ-010",
   "prdId": "PRD-001",
   "title": "The gate suite entry point is the same code path locally and in CI",
   "description": "The Node entry point script is invocable on a developer's machine with the same command the CI provider invokes, against the same tree the developer has checked out, and produces the same per-gate reports and aggregate report at the same stable paths. A developer reproducing a CI failure runs the same one line the CI job ran; no CI-only wrapper or environment shim is on the CI code path but not the developer's.",
@@ -8,7 +8,7 @@
   "priority": "must",
   "rationale": "A gate that only works inside the CI runner leaves the developer guessing which flag or setup step produced the failure. The Node entry point is the CI's code path and the developer's code path; a CI-only wrapper is the shape that produces 'green locally, red in CI' and slows every review. Same entry point, same reports, same failure mode.",
   "tags": [
-    "blueprint:ci-pipeline",
+    "blueprint:delivery-ci-workflows",
     "category:10-local-parity"
   ],
   "version": "1.0.0",

package/blueprints/delivery-ci-workflows/contributions/requirements/delivery-ci-workflows-req-011.json

@@ -0,0 +1,18 @@
+{
+  "reqId": "delivery-ci-workflows-REQ-011",
+  "prdId": "PRD-001",
+  "title": "The project declares its CI workflow shape in a stable in-repo configuration file the workflow-materialiser reads",
+  "description": "The project ships a `workflowShape` declaration at the stable path `.rcf/config/delivery-ci-workflows.json` on the project tree. The declaration carries three required top-level fields (`branchModel`, `checkSet`, `providerHint`), one optional top-level field (`releaseMode`; absent has the same effect as `releaseMode: none`, per Q6-B ratification), one optional fifth field (`scheduledAudit`, default false), and one optional sub-field (`trunkPullRequests`) that qualifies `branchModel: trunk`. The four-field composed form (`branchModel`, `checkSet`, `releaseMode`, `providerHint`, with `releaseMode` defaulted to `none` when absent) is the authoritative representation the downstream workflow-materialiser (TAC-704) and every AC in this blueprint bind against; the profile-alias convenience surface (REQ-013) expands to the same composed form before any consumer reads it. The declaration is a data file, not code; the workflow-materialiser reads it once at the start of every materialisation run and refuses to proceed when the file is absent or malformed.",
+  "category": "functional",
+  "domain": "continuous-integration",
+  "priority": "must",
+  "rationale": "A workflow set that scales along size and complexity axes needs a place the project declares its shape once and every workflow materialisation reads. Naming the location (`.rcf/config/delivery-ci-workflows.json`), the file shape (four required fields + optional dimensions), and the authoritative representation (four-field form) turns the elicitation surface into a stable contract the workflow-materialiser and every downstream reader can depend on. A manifest-embedded location was considered and deferred; the in-repo file surface ships with v2.0.0 without waiting on a per-blueprint mechanism-side config surface.",
+  "tags": [
+    "blueprint:delivery-ci-workflows",
+    "category:11-elicitation-surface"
+  ],
+  "version": "2.0.0",
+  "status": "approved",
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

package/blueprints/delivery-ci-workflows/contributions/requirements/delivery-ci-workflows-req-012.json

@@ -0,0 +1,18 @@
+{
+  "reqId": "delivery-ci-workflows-REQ-012",
+  "prdId": "PRD-001",
+  "title": "A missing or unrecognised workflowShape field is refused at boot with a stable-coded error naming the field",
+  "description": "The workflow-materialiser performs a boot-check on the `workflowShape` declaration before any workflow file is produced. Any of the three required top-level fields (`branchModel`, `checkSet`, `providerHint`) being absent causes the materialiser to exit non-zero with a stable-coded error message that names the missing field. Any field (required or optional) carrying a value not in the recognised enumeration causes the same failure shape, with the message additionally naming the value it received and the allowed set. `releaseMode` being absent is NOT a failure (Q6-B ratification): the materialiser treats it as `releaseMode: none` and ships no release workflow. A `releaseMode: deployHandoff:<slug>` value additionally triggers a manifest boot-check (REQ-022) that names the required deploy blueprint if it is missing from `manifest.blueprints[]`. The boot-check runs before any workflow file is written; a partial workflow set never lands on disk.",
+  "category": "functional",
+  "domain": "continuous-integration",
+  "priority": "must",
+  "rationale": "Silent defaults on missing configuration lead to workflow sets that materialise wrong-shaped without the operator noticing. Failing fast with a message that names the missing field is what turns the elicitation surface from advisory into contractual. Stable error codes let downstream automation (a project scaffolder, an rcf-lite doctor check) match on the failure without parsing free-form text.",
+  "tags": [
+    "blueprint:delivery-ci-workflows",
+    "category:12-boot-check"
+  ],
+  "version": "2.0.0",
+  "status": "approved",
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

package/blueprints/delivery-ci-workflows/contributions/requirements/delivery-ci-workflows-req-013.json

@@ -0,0 +1,18 @@
+{
+  "reqId": "delivery-ci-workflows-REQ-013",
+  "prdId": "PRD-001",
+  "title": "Named profile aliases expand to the authoritative four-field workflowShape form before any consumer reads it",
+  "description": "The elicitation surface accepts a named profile alias (`smallLibrary`, `smallService`, `internalPackage`, `trunkLibrary`) in place of the four-field form. On boot the workflow-materialiser detects the alias, expands it to the shipped four-field composition, and treats the expanded form as authoritative for every downstream. Every AC in this blueprint binds to the four-field form only; the alias layer is a convenience surface, not an authoritative representation. An unrecognised alias name is refused at boot with a stable-coded error naming the alias and listing the shipped set. A project that wants a shape the shipped aliases do not name uses the four-field form.",
+  "category": "functional",
+  "domain": "continuous-integration",
+  "priority": "should",
+  "rationale": "Profile aliases keep the common cases (published library, greenfield service, internal package) short and legible while preserving the four independent axes for shapes the aliases do not cover. Expanding aliases to the four-field form at boot means every downstream reader (workflow-materialiser, deploy handoff, scheduled-audit) sees one representation regardless of how the project declared it; adding an alias is additive; renaming or removing an alias is a minor bump per §2.3.",
+  "tags": [
+    "blueprint:delivery-ci-workflows",
+    "category:13-profile-aliases"
+  ],
+  "version": "2.0.0",
+  "status": "approved",
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

package/blueprints/delivery-ci-workflows/contributions/requirements/delivery-ci-workflows-req-014.json

@@ -0,0 +1,18 @@
+{
+  "reqId": "delivery-ci-workflows-REQ-014",
+  "prdId": "PRD-001",
+  "title": "The feature-branch shape materialises pull-request-checks and default-branch-checks workflows against the required check set",
+  "description": "When `workflowShape.branchModel` is `feature`, the workflow-materialiser produces two workflows sharing the same required check set: `pull-request-checks` firing on pull requests targeting the default branch, and `default-branch-checks` firing on pushes to the default branch. Both workflows invoke the same Node gate-runner entry point (TAC-701) with the required check set produced by the two-tier catalogue (mandatory tier plus the elicited subset from `checkSet`). Both workflows write their aggregate report to the stable path and preserve the ordering discipline. The blueprint contributes an AC that the project configure default-branch protection to require the `pull-request-checks` aggregate as a merge-blocking check; the configuration itself is a project responsibility on the platform's own surface.",
+  "category": "functional",
+  "domain": "continuous-integration",
+  "priority": "must",
+  "rationale": "Feature-branch is the good default the operator ruling names and the shape the widely-adopted GitHub-flow convention describes. Naming the two workflows the shape materialises, binding both to the same check set, and stating the merge-policy property as an AC (rather than shipping a branch-protection configuration file) keeps the blueprint provider-neutral while giving the project a stated property it can verify on any platform.",
+  "tags": [
+    "blueprint:delivery-ci-workflows",
+    "category:14-branch-model-feature"
+  ],
+  "version": "2.0.0",
+  "status": "approved",
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

package/blueprints/delivery-ci-workflows/contributions/requirements/delivery-ci-workflows-req-015.json

@@ -0,0 +1,18 @@
+{
+  "reqId": "delivery-ci-workflows-REQ-015",
+  "prdId": "PRD-001",
+  "title": "The trunk-based shape is a first-class option with a sub-shape for optional pull-request use",
+  "description": "When `workflowShape.branchModel` is `trunk`, the workflow-materialiser produces `default-branch-checks` as the always-on workflow firing on every push to the trunk branch. A nested `trunkPullRequests` field qualifies the shape: `never` (default) ships only `default-branch-checks`; `sometimes` additionally ships `pull-request-checks` against the same check set. The merge-policy AC states the property differently per sub-shape: without PRs, the trunk branch's push protection admits only commits whose `default-branch-checks` aggregate passed; with PRs, the trunk branch's protection admits only PRs whose `pull-request-checks` aggregate passed. Every other contract (check catalogue, report shape, ordering) is shared with the feature-branch shape.",
+  "category": "functional",
+  "domain": "continuous-integration",
+  "priority": "must",
+  "rationale": "Trunk-based development is a first-class shape the operator ruling named, not an afterthought. The two sub-shapes (with and without PRs) cover the archetypal trunk-based posture and the common hybrid; the nested sub-field keeps the top-level enumeration at the two archetypes. Sharing the check catalogue and report shape across both branch models means a project that migrates between them changes trigger sets, not check contracts.",
+  "tags": [
+    "blueprint:delivery-ci-workflows",
+    "category:15-branch-model-trunk"
+  ],
+  "version": "2.0.0",
+  "status": "approved",
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

package/blueprints/delivery-ci-workflows/contributions/requirements/delivery-ci-workflows-req-016.json

@@ -0,0 +1,18 @@
+{
+  "reqId": "delivery-ci-workflows-REQ-016",
+  "prdId": "PRD-001",
+  "title": "A linter check the project realises produces a stable-shape lint report and fails non-zero on any lint error",
+  "description": "The elicited `linter` check, when the project enables it in `workflowShape.checkSet.linter`, runs a lint gate that exits non-zero on any lint error the project treats as blocking. The gate writes its per-gate report to `.rcf/reports/ci/lint.json` in the shared per-gate report shape (with `checkKind: \"linter\"`). The blueprint does not pick the linter tool; the project realises the runner over the tool of its choice and satisfies the runner-contract interface the gate-runner TAC binds. Warnings that the project does not treat as blocking are reported in the per-gate report without flipping the exit code.",
+  "category": "functional",
+  "domain": "continuous-integration",
+  "priority": "must",
+  "rationale": "A lint gate that runs but does not gate is a lint gate that quietly rots; a lint gate whose report shape drifts across projects is a gate downstream readers cannot depend on. Naming the exit-code semantic, the report path, and the report shape as an AC contract turns the linter check into a stable surface without forcing a tool choice.",
+  "tags": [
+    "blueprint:delivery-ci-workflows",
+    "category:16-check-linter"
+  ],
+  "version": "2.0.0",
+  "status": "approved",
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

package/blueprints/delivery-ci-workflows/contributions/requirements/delivery-ci-workflows-req-017.json

@@ -0,0 +1,18 @@
+{
+  "reqId": "delivery-ci-workflows-REQ-017",
+  "prdId": "PRD-001",
+  "title": "A formatter check the project realises produces a stable-shape formatter report and fails non-zero on any unformatted file",
+  "description": "The elicited `formatter` check, when the project enables it in `workflowShape.checkSet.formatter`, runs a formatter check gate (not a formatter write) that exits non-zero when any tracked file would be rewritten by the formatter. The gate writes its per-gate report to `.rcf/reports/ci/format.json` in the shared per-gate report shape (with `checkKind: \"formatter\"`). The blueprint does not pick the formatter; the project realises the runner and satisfies the runner-contract interface.",
+  "category": "functional",
+  "domain": "continuous-integration",
+  "priority": "must",
+  "rationale": "A formatter used as a WRITE step masks unformatted commits; a formatter used as a CHECK step fails the pipeline on any unformatted file. Binding the check-mode semantic and the report shape as an AC contract keeps the property stable while leaving the tool choice to the project.",
+  "tags": [
+    "blueprint:delivery-ci-workflows",
+    "category:17-check-formatter"
+  ],
+  "version": "2.0.0",
+  "status": "approved",
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

package/blueprints/delivery-ci-workflows/contributions/requirements/delivery-ci-workflows-req-018.json

@@ -0,0 +1,18 @@
+{
+  "reqId": "delivery-ci-workflows-REQ-018",
+  "prdId": "PRD-001",
+  "title": "A typecheck the project realises produces a stable-shape typecheck report and fails non-zero on any type error",
+  "description": "The elicited `typecheck` check, when the project enables it in `workflowShape.checkSet.typecheck`, runs a typechecker gate that exits non-zero on any type error. The gate writes its per-gate report to `.rcf/reports/ci/typecheck.json` in the shared per-gate report shape (with `checkKind: \"typecheck\"`). The check is applicable only when the project uses a typed language or a TypeScript-style build; the workflow-materialiser turns the check on by default when the project tree contains a `tsconfig.json` or an equivalent tool marker, off otherwise. The project overrides the auto-detection by setting the check-set flag explicitly.",
+  "category": "functional",
+  "domain": "continuous-integration",
+  "priority": "must",
+  "rationale": "A typecheck gate belongs on any project with a typechecker; a project without one has no runner to satisfy the contract. Auto-detecting from a stable marker (a `tsconfig.json` or equivalent) keeps the default aligned with project shape while preserving the explicit override.",
+  "tags": [
+    "blueprint:delivery-ci-workflows",
+    "category:18-check-typecheck"
+  ],
+  "version": "2.0.0",
+  "status": "approved",
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

package/blueprints/delivery-ci-workflows/contributions/requirements/delivery-ci-workflows-req-019.json

@@ -0,0 +1,18 @@
+{
+  "reqId": "delivery-ci-workflows-REQ-019",
+  "prdId": "PRD-001",
+  "title": "A unit-test check the project realises produces a stable-shape test report and fails non-zero on any failing test",
+  "description": "The elicited `unitTest` check, when the project enables it in `workflowShape.checkSet.unitTest`, runs the project unit-test suite as a gate that exits non-zero on any failing test. The gate writes its per-gate report to `.rcf/reports/ci/test.json` in the shared per-gate report shape (with `checkKind: \"unitTest\"`). The blueprint does not pick the test runner; the project realises the runner and satisfies the runner-contract interface. A missing runner (an empty test suite before the project has any tests) is recorded in the per-gate report and does not by itself fail the gate.",
+  "category": "functional",
+  "domain": "continuous-integration",
+  "priority": "must",
+  "rationale": "A unit-test gate is table stakes for any greenfield project; naming it in the elicited catalogue keeps the default set aligned with what a project engineer expects to find in a CI floor. Preserving the tool choice at the project layer is what keeps the blueprint neutral across test frameworks.",
+  "tags": [
+    "blueprint:delivery-ci-workflows",
+    "category:19-check-unit-test"
+  ],
+  "version": "2.0.0",
+  "status": "approved",
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

package/blueprints/delivery-ci-workflows/contributions/requirements/delivery-ci-workflows-req-020.json

@@ -0,0 +1,18 @@
+{
+  "reqId": "delivery-ci-workflows-REQ-020",
+  "prdId": "PRD-001",
+  "title": "A security-scan check the project realises produces a stable-shape scan report and fails non-zero on findings above the project threshold",
+  "description": "The elicited `securityScan` check, when the project enables it in `workflowShape.checkSet.securityScan`, runs a dependency-and-secret scan gate that exits non-zero when the scan finds any advisory at or above the project-configured severity threshold. The gate writes its per-gate report to `.rcf/reports/ci/security.json` in the shared per-gate report shape (with `checkKind: \"securityScan\"`). Findings below the threshold are reported in the per-gate report without flipping the exit code. The severity threshold is a project decision; the blueprint does not opine on the threshold.",
+  "category": "functional",
+  "domain": "continuous-integration",
+  "priority": "must",
+  "rationale": "A security scan whose severity threshold is a build-in choice punishes projects whose risk posture is different from the blueprint author's; a threshold the project owns keeps the gate applicable across risk postures. Binding the exit-code semantic and the report shape as an AC contract preserves the stable surface downstream readers depend on.",
+  "tags": [
+    "blueprint:delivery-ci-workflows",
+    "category:20-check-security-scan"
+  ],
+  "version": "2.0.0",
+  "status": "approved",
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

package/blueprints/delivery-ci-workflows/contributions/requirements/delivery-ci-workflows-req-021.json

@@ -0,0 +1,18 @@
+{
+  "reqId": "delivery-ci-workflows-REQ-021",
+  "prdId": "PRD-001",
+  "title": "The release workflow shape scales with the releaseMode dimension across four discrete modes",
+  "description": "When `workflowShape.releaseMode` is `none`, no release workflow ships. When `tagOnly`, a release workflow fires on the project-declared release trigger (a `release` event, a `workflow_dispatch`, or both) and creates a release entity on the CI provider's own release surface (a GitHub Release, a GitLab release, whatever the provider ships). When `tagPlusArtefact`, the release workflow also runs the project-realised artefact-publish step and uploads its output to the release entity; the AC contract requires the artefact-publish step to produce a verified artefact reachable at a stable identifier. When `deployHandoff:<slug>`, the release workflow additionally invokes the named deploy blueprint's promote workflow per REQ-022. The release workflow does not run the required check set; the check set already ran on the default-branch-checks workflow at the commit the release points at.",
+  "category": "functional",
+  "domain": "continuous-integration",
+  "priority": "must",
+  "rationale": "Release workflow shape scales with project maturity: an internal package has no release path (mode `none`); a documented release stamps a tag (`tagOnly`); a published library adds an artefact (`tagPlusArtefact`); a paired service hands off to deploy (`deployHandoff`). Four discrete modes cover the maturity range without inventing intermediate states the operator has to reason about. Excluding the check set from the release workflow avoids the redundant run-and-lengthen pattern.",
+  "tags": [
+    "blueprint:delivery-ci-workflows",
+    "category:21-release-mode"
+  ],
+  "version": "2.0.0",
+  "status": "approved",
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

package/blueprints/delivery-ci-workflows/contributions/requirements/delivery-ci-workflows-req-022.json

@@ -0,0 +1,18 @@
+{
+  "reqId": "delivery-ci-workflows-REQ-022",
+  "prdId": "PRD-001",
+  "title": "The deployHandoff release mode invokes the named deploy blueprint's promote workflow and refuses at boot when that blueprint is absent",
+  "description": "When `workflowShape.releaseMode` is `deployHandoff:<slug>`, the release workflow invokes the named deploy blueprint's `promote` workflow via that blueprint's declared invocation contract (a `workflow_dispatch` event carrying the just-published version identifier as the `versionId` input). The release workflow's aggregate outcome is `passed` only when the promote workflow's outcome is `passed`. The workflow-materialiser performs a boot-check that refuses the value when the named deploy blueprint is absent from `manifest.blueprints[]`; the error names the missing blueprint by slug and points at `rcf define blueprint add <deploy-slug>` as the resolution.",
+  "category": "functional",
+  "domain": "continuous-integration",
+  "priority": "must",
+  "rationale": "Cross-blueprint composition works when the composing blueprint reaches for a stated invocation contract on the composed side, not when it duplicates the composed side's implementation. The `versionId`-optional-input contract on the deploy blueprint's promote workflow is already ratified; the release workflow calls it and inherits the promote workflow's outcome. The manifest boot-check catches the misconfiguration case (a project declaring a handoff to a target it has not applied) before the release workflow lands on disk.",
+  "tags": [
+    "blueprint:delivery-ci-workflows",
+    "category:22-deploy-handoff"
+  ],
+  "version": "2.0.0",
+  "status": "approved",
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}