rcf-lite 0.12.0 → 0.14.0

package/blueprints/delivery-ci-workflows/assets/ci-provider-examples/github-actions/release.yml

@@ -0,0 +1,71 @@
+# Illustrative release workflow for the delivery-ci-workflows blueprint.
+# Copy this file into the host project as `.github/workflows/release.yml`
+# and adjust the `node-version`, package-manager setup, and release
+# orchestrator path to match the project's realised release runner (TAC-705).
+#
+# This file materialises when workflowShape.releaseMode is `tagOnly`,
+# `tagPlusArtefact`, or `deployHandoff:<slug>`. When releaseMode is `none`
+# or absent, the workflow does not ship at all (Q6-B ratification).
+#
+# The workflow does NOT run the required check set: that already ran on the
+# default-branch-checks workflow at the commit the release points at.
+#
+# See `guide/delivery-ci-workflows.md` for the four release-mode shapes and
+# the deploy handoff invocation contract (AC-6122-1..3).
+
+name: release
+
+on:
+  release:
+    types: [created]
+  workflow_dispatch:
+    inputs:
+      versionId:
+        description: 'Version identifier to release (optional; omitted defaults to the release event tag)'
+        required: false
+        type: string
+
+jobs:
+  release-flow:
+    runs-on: ubuntu-latest
+    permissions:
+      contents: write
+      packages: write
+    steps:
+      - name: checkout
+        uses: actions/checkout@v4
+
+      - name: setup pnpm
+        uses: pnpm/action-setup@v4
+        with:
+          version: 9
+
+      - name: setup node
+        uses: actions/setup-node@v4
+        with:
+          node-version: 24
+          cache: pnpm
+
+      - name: install dependencies
+        run: pnpm install --frozen-lockfile
+
+      # The release orchestrator reads the releaseMode from its environment
+      # (RCF_RELEASE_MODE) and runs the appropriate step sequence:
+      # tagOnly: create release entity only
+      # tagPlusArtefact: create release entity, run artefact-publish step
+      # deployHandoff:<slug>: create release entity, run artefact-publish
+      #   step, dispatch <slug>'s promote workflow with versionId
+      # It writes .rcf/reports/ci/release.json as the aggregate.
+      - name: run release orchestrator
+        env:
+          RCF_RELEASE_MODE: tagPlusArtefact
+        run: node scripts/rcf-release.js
+
+      - name: upload release reports
+        if: always()
+        uses: actions/upload-artifact@v4
+        with:
+          name: release-reports
+          path: .rcf/reports/ci/
+          if-no-files-found: warn
+          retention-days: 90

package/blueprints/delivery-ci-workflows/assets/ci-provider-examples/github-actions/scheduled-audit.yml

@@ -0,0 +1,61 @@
+# Illustrative scheduled-audit workflow for the delivery-ci-workflows blueprint.
+# Copy this file into the host project as `.github/workflows/scheduled-audit.yml`
+# and adjust the `node-version`, package-manager setup, and scheduled runner
+# path to match the project's realised scheduled-audit runner (TAC-706).
+#
+# This file materialises when workflowShape.scheduledAudit is `true`. When
+# `false` or absent, the workflow does not ship at all.
+#
+# The workflow runs the same required check set as the commit-triggered
+# workflows and writes to a distinct aggregate report path
+# (.rcf/reports/ci/scheduled-audit.json) so scheduled-run outcomes never
+# overwrite the most recent commit-triggered outcome.
+#
+# See `guide/delivery-ci-workflows.md` for the cron cadence discussion and
+# AC-6123-1/AC-6123-2 for the report-path property.
+
+name: scheduled-audit
+
+on:
+  schedule:
+    # Every day at 06:00 UTC. Adjust to your project's cadence.
+    - cron: '0 6 * * *'
+  workflow_dispatch: {}
+
+jobs:
+  scheduled-check-set:
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+    steps:
+      - name: checkout
+        uses: actions/checkout@v4
+
+      - name: setup pnpm
+        uses: pnpm/action-setup@v4
+        with:
+          version: 9
+
+      - name: setup node
+        uses: actions/setup-node@v4
+        with:
+          node-version: 24
+          cache: pnpm
+
+      - name: install dependencies
+        run: pnpm install --frozen-lockfile
+
+      # The scheduled runner is a thin wrapper around the gate-runner
+      # (TAC-701) that overrides the aggregate report path to the
+      # scheduled-audit path and forwards the elicited check set.
+      - name: run scheduled audit
+        run: node scripts/rcf-scheduled-audit.js --report-path .rcf/reports/ci/scheduled-audit.json
+
+      - name: upload scheduled audit reports
+        if: always()
+        uses: actions/upload-artifact@v4
+        with:
+          name: scheduled-audit-reports
+          path: .rcf/reports/ci/
+          if-no-files-found: warn
+          retention-days: 30

package/blueprints/delivery-ci-workflows/assets/ci-provider-examples/notes.md

@@ -0,0 +1,61 @@
+# Wiring the workflow set on alternate CI providers
+
+The blueprint ships one illustrative provider example (GitHub Actions, four workflow files under `github-actions/`). Every mainstream provider hosts the same workflow set by translating four points per workflow and keeping the Node entry-point invocations unchanged. These notes are read alongside `guide/delivery-ci-workflows.md`, not instead of it.
+
+## The workflow set the matrix materialises
+
+Which workflow files exist depends on `workflowShape`:
+
+- Always: `default-branch-checks` (pushes to the default or trunk branch).
+- Feature-branch, or trunk-based with `trunkPullRequests: sometimes`: `pull-request-checks` (pull requests targeting the branch).
+- `releaseMode` not `none` and not absent: `release` (release-trigger events; four shapes per mode).
+- `scheduledAudit: true`: `scheduled-audit` (cron cadence).
+
+## The four mapping points (applied per workflow)
+
+1. Job trigger. Fire the workflow's job on the trigger set defined for that workflow (see the corresponding GHA file's `on:` block for the reference shape).
+2. Node setup. Install Node 24 or later on the runner.
+3. Package-manager setup and install. Install the project's dependencies with the frozen-lockfile discipline of whichever manager the project uses.
+4. Node entry-point invocation and artefact upload. Run `node <path>` (or a package-manager script that resolves to the same) for the workflow's entry point (gate-runner for `pull-request-checks` and `default-branch-checks`, release orchestrator for `release`, scheduled-audit runner for `scheduled-audit`); upload the aggregate report directory as a run artefact for downstream readers.
+
+The blueprint does not ship provider-specific configuration files for the providers below at v2.0.0. A project hand-authors the first three points in the provider's own runner language and keeps the fourth unchanged per the workflow's entry point.
+
+## GitLab CI (`.gitlab-ci.yml`)
+
+- Triggers: for `pull-request-checks` use `rules: { if: $CI_PIPELINE_SOURCE == "merge_request_event" && $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "main" }`; for `default-branch-checks` use `rules: { if: $CI_COMMIT_BRANCH == "main" }`; for `release` use `rules: { if: $CI_COMMIT_TAG }` plus a `workflow_dispatch`-equivalent through GitLab's manual jobs; for `scheduled-audit` use a scheduled pipeline.
+- Node setup: use a `node:24` image or install through the runner's setup hook.
+- Install: `pnpm install --frozen-lockfile` (or equivalent).
+- Invoke: `node scripts/rcf-ci.js` for check-set workflows; `node scripts/rcf-release.js` for release; `node scripts/rcf-scheduled-audit.js --report-path .rcf/reports/ci/scheduled-audit.json` for scheduled-audit.
+- Artefact upload: `artifacts: { when: always, paths: [.rcf/reports/ci/] }`.
+
+## CircleCI (`.circleci/config.yml`)
+
+- Triggers: `workflows:` with branch and PR filters for the two check-set workflows; scheduled workflows for `scheduled-audit`; the release workflow fires from tag-triggered pipelines.
+- Node setup: `cimg/node:24.19` or the `node/install` orb command.
+- Install: `pnpm install --frozen-lockfile`.
+- Invoke: as above.
+- Artefact upload: `store_artifacts: { path: .rcf/reports/ci }`.
+
+## Buildkite (`.buildkite/pipeline.yml`)
+
+- Triggers: pipeline-level branch conditions or per-step `branches: main` for check-set workflows; separate pipelines for release (tag-triggered) and scheduled-audit (Buildkite scheduled builds).
+- Node setup: install Node 24 in the queue's setup hook or use a Docker plugin (`docker#v5.0.0`).
+- Install: `pnpm install --frozen-lockfile`.
+- Invoke: as above.
+- Artefact upload: `artifact_paths: [".rcf/reports/ci/**"]`.
+
+## Jenkins (declarative pipeline)
+
+- Triggers: `triggers { githubPush() }` plus a multibranch pipeline configured to build pull requests against the default branch; a separate tag-triggered pipeline for release; `triggers { cron('H 6 * * *') }` for scheduled-audit.
+- Node setup: install Node 24 via `tools { nodejs '24' }` or provision the agent with Node preinstalled.
+- Install: `sh 'pnpm install --frozen-lockfile'`.
+- Invoke: `sh 'node scripts/rcf-ci.js'` (or the appropriate script per workflow).
+- Artefact upload: `archiveArtifacts artifacts: '.rcf/reports/ci/**', allowEmptyArchive: true`.
+
+## Cross-provider notes
+
+- The Node entry-point paths are the same on every provider. A project that changes providers rewrites its trigger, setup, install, and artefact-upload steps; the entry-point step is unchanged.
+- The report directory (default `.rcf/reports/ci/`) is the same on every provider. Downstream readers do not need per-provider knowledge to pick up the aggregate reports.
+- The tool-version pin (which `rcf` version to run) is the project's decision. The runner records the installed version on every per-gate report's `toolVersion` field; a mismatch across two runs is visible in the reports without re-running the gate.
+- The release workflow's `deployHandoff:<slug>` mode dispatches the named deploy blueprint's `promote` workflow. On GHA that means a `workflow_dispatch` call to the deploy blueprint's workflow file; on other providers, translate to the equivalent workflow-dispatch primitive (GitLab's pipeline API trigger, CircleCI's trigger-pipeline API, Buildkite's Trigger step, Jenkins parameterised build). The `versionId` input contract is unchanged across providers.
+- Sibling asset packs (a v2.1 candidate) that ship per-provider full asset sets from the same `workflowShape` are the natural way to skip this hand-translation work for projects that live on one provider.

package/blueprints/delivery-ci-workflows/assets/report-samples/per-gate.json

@@ -0,0 +1,13 @@
+{
+  "gate": "validate",
+  "command": ["rcf", "validate"],
+  "toolVersion": "0.7.4",
+  "startedAt": "2026-08-24T10:15:03.221Z",
+  "endedAt": "2026-08-24T10:15:04.891Z",
+  "durationMs": 1670,
+  "exitCode": 0,
+  "outcome": "passed",
+  "stdout": "[rcf] validate: 0 issue(s) across 47 document(s)\n",
+  "stderr": "",
+  "checkKind": "validate"
+}

package/blueprints/delivery-ci-workflows/assets/report-samples/pipeline.json

@@ -0,0 +1,28 @@
+{
+  "verdict": "failed",
+  "trigger": "pull_request",
+  "startedAt": "2026-08-24T10:15:03.100Z",
+  "endedAt": "2026-08-24T10:15:12.045Z",
+  "durationMs": 8945,
+  "runner": {
+    "entryPoint": "scripts/rcf-ci.js",
+    "environment": {
+      "provider": "github-actions",
+      "runId": "8214332015"
+    }
+  },
+  "gates": [
+    {
+      "gate": "validate",
+      "outcome": "passed",
+      "durationMs": 1670,
+      "reportPath": "validate.json"
+    },
+    {
+      "gate": "coverage-strict",
+      "outcome": "failed",
+      "durationMs": 7220,
+      "reportPath": "coverage-strict.json"
+    }
+  ]
+}

package/blueprints/delivery-ci-workflows/blueprint.json

@@ -0,0 +1,87 @@
+{
+  "slug": "delivery-ci-workflows",
+  "version": "2.0.0",
+  "category": "delivery",
+  "contributions": [
+    { "id": "delivery-ci-workflows-REQ-001", "kind": "req", "path": "requirements/delivery-ci-workflows-req-001.json" },
+    { "id": "delivery-ci-workflows-REQ-002", "kind": "req", "path": "requirements/delivery-ci-workflows-req-002.json" },
+    { "id": "delivery-ci-workflows-REQ-003", "kind": "req", "path": "requirements/delivery-ci-workflows-req-003.json" },
+    { "id": "delivery-ci-workflows-REQ-004", "kind": "req", "path": "requirements/delivery-ci-workflows-req-004.json" },
+    { "id": "delivery-ci-workflows-REQ-005", "kind": "req", "path": "requirements/delivery-ci-workflows-req-005.json" },
+    { "id": "delivery-ci-workflows-REQ-006", "kind": "req", "path": "requirements/delivery-ci-workflows-req-006.json" },
+    { "id": "delivery-ci-workflows-REQ-007", "kind": "req", "path": "requirements/delivery-ci-workflows-req-007.json" },
+    { "id": "delivery-ci-workflows-REQ-008", "kind": "req", "path": "requirements/delivery-ci-workflows-req-008.json" },
+    { "id": "delivery-ci-workflows-REQ-009", "kind": "req", "path": "requirements/delivery-ci-workflows-req-009.json" },
+    { "id": "delivery-ci-workflows-REQ-010", "kind": "req", "path": "requirements/delivery-ci-workflows-req-010.json" },
+    { "id": "delivery-ci-workflows-REQ-011", "kind": "req", "path": "requirements/delivery-ci-workflows-req-011.json" },
+    { "id": "delivery-ci-workflows-REQ-012", "kind": "req", "path": "requirements/delivery-ci-workflows-req-012.json" },
+    { "id": "delivery-ci-workflows-REQ-013", "kind": "req", "path": "requirements/delivery-ci-workflows-req-013.json" },
+    { "id": "delivery-ci-workflows-REQ-014", "kind": "req", "path": "requirements/delivery-ci-workflows-req-014.json" },
+    { "id": "delivery-ci-workflows-REQ-015", "kind": "req", "path": "requirements/delivery-ci-workflows-req-015.json" },
+    { "id": "delivery-ci-workflows-REQ-016", "kind": "req", "path": "requirements/delivery-ci-workflows-req-016.json" },
+    { "id": "delivery-ci-workflows-REQ-017", "kind": "req", "path": "requirements/delivery-ci-workflows-req-017.json" },
+    { "id": "delivery-ci-workflows-REQ-018", "kind": "req", "path": "requirements/delivery-ci-workflows-req-018.json" },
+    { "id": "delivery-ci-workflows-REQ-019", "kind": "req", "path": "requirements/delivery-ci-workflows-req-019.json" },
+    { "id": "delivery-ci-workflows-REQ-020", "kind": "req", "path": "requirements/delivery-ci-workflows-req-020.json" },
+    { "id": "delivery-ci-workflows-REQ-021", "kind": "req", "path": "requirements/delivery-ci-workflows-req-021.json" },
+    { "id": "delivery-ci-workflows-REQ-022", "kind": "req", "path": "requirements/delivery-ci-workflows-req-022.json" },
+    { "id": "delivery-ci-workflows-REQ-023", "kind": "req", "path": "requirements/delivery-ci-workflows-req-023.json" },
+    { "id": "delivery-ci-workflows-US-6101", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6101.json" },
+    { "id": "delivery-ci-workflows-US-6102", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6102.json" },
+    { "id": "delivery-ci-workflows-US-6103", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6103.json" },
+    { "id": "delivery-ci-workflows-US-6104", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6104.json" },
+    { "id": "delivery-ci-workflows-US-6105", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6105.json" },
+    { "id": "delivery-ci-workflows-US-6106", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6106.json" },
+    { "id": "delivery-ci-workflows-US-6107", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6107.json" },
+    { "id": "delivery-ci-workflows-US-6108", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6108.json" },
+    { "id": "delivery-ci-workflows-US-6109", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6109.json" },
+    { "id": "delivery-ci-workflows-US-6110", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6110.json" },
+    { "id": "delivery-ci-workflows-US-6111", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6111.json" },
+    { "id": "delivery-ci-workflows-US-6112", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6112.json" },
+    { "id": "delivery-ci-workflows-US-6113", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6113.json" },
+    { "id": "delivery-ci-workflows-US-6114", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6114.json" },
+    { "id": "delivery-ci-workflows-US-6115", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6115.json" },
+    { "id": "delivery-ci-workflows-US-6116", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6116.json" },
+    { "id": "delivery-ci-workflows-US-6117", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6117.json" },
+    { "id": "delivery-ci-workflows-US-6118", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6118.json" },
+    { "id": "delivery-ci-workflows-US-6119", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6119.json" },
+    { "id": "delivery-ci-workflows-US-6120", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6120.json" },
+    { "id": "delivery-ci-workflows-US-6121", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6121.json" },
+    { "id": "delivery-ci-workflows-US-6122", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6122.json" },
+    { "id": "delivery-ci-workflows-US-6123", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6123.json" },
+    { "id": "TAC-701-delivery-ci-workflows-gate-runner", "kind": "tac", "path": "tacs/tac-701-delivery-ci-workflows-gate-runner.json" },
+    { "id": "TAC-702-delivery-ci-workflows-gate-report", "kind": "tac", "path": "tacs/tac-702-delivery-ci-workflows-gate-report.json" },
+    { "id": "TAC-703-delivery-ci-workflows-aggregate-report", "kind": "tac", "path": "tacs/tac-703-delivery-ci-workflows-aggregate-report.json" },
+    { "id": "TAC-704-delivery-ci-workflows-workflow-materialiser", "kind": "tac", "path": "tacs/tac-704-delivery-ci-workflows-workflow-materialiser.json" },
+    { "id": "TAC-705-delivery-ci-workflows-release-workflow", "kind": "tac", "path": "tacs/tac-705-delivery-ci-workflows-release-workflow.json" },
+    { "id": "TAC-706-delivery-ci-workflows-scheduled-audit", "kind": "tac", "path": "tacs/tac-706-delivery-ci-workflows-scheduled-audit.json" },
+    {
+      "id": "ADR-701-delivery-ci-workflows-ci-gates",
+      "kind": "adr",
+      "path": "adrs/adr-701-delivery-ci-workflows-ci-gates.json",
+      "scope": "global",
+      "topic": "ciGates"
+    },
+    {
+      "id": "ADR-702-delivery-ci-workflows-strict-coverage-gate",
+      "kind": "adr",
+      "path": "adrs/adr-702-delivery-ci-workflows-strict-coverage-gate.json",
+      "scope": "global",
+      "topic": "strictCoverageGate"
+    },
+    { "id": "ADR-703-delivery-ci-workflows-node-only-runner", "kind": "adr", "path": "adrs/adr-703-delivery-ci-workflows-node-only-runner.json" },
+    { "id": "ADR-704-delivery-ci-workflows-report-shape", "kind": "adr", "path": "adrs/adr-704-delivery-ci-workflows-report-shape.json" },
+    { "id": "ADR-705-delivery-ci-workflows-elicitation-surface", "kind": "adr", "path": "adrs/adr-705-delivery-ci-workflows-elicitation-surface.json" },
+    { "id": "ADR-706-delivery-ci-workflows-branch-model-defaults", "kind": "adr", "path": "adrs/adr-706-delivery-ci-workflows-branch-model-defaults.json" },
+    { "id": "ADR-707-delivery-ci-workflows-release-workflow-shape", "kind": "adr", "path": "adrs/adr-707-delivery-ci-workflows-release-workflow-shape.json" },
+    { "id": "ADR-708-delivery-ci-workflows-provider-hint-shape", "kind": "adr", "path": "adrs/adr-708-delivery-ci-workflows-provider-hint-shape.json" },
+    {
+      "id": "ADR-709-delivery-ci-workflows-release-artefacts",
+      "kind": "adr",
+      "path": "adrs/adr-709-delivery-ci-workflows-release-artefacts.json",
+      "scope": "global",
+      "topic": "releaseArtefacts"
+    },
+    { "id": "ADR-710-delivery-ci-workflows-scheduled-audit", "kind": "adr", "path": "adrs/adr-710-delivery-ci-workflows-scheduled-audit.json" }
+  ]
+}

package/blueprints/delivery-ci-workflows/contributions/adrs/adr-701-delivery-ci-workflows-ci-gates.json

@@ -0,0 +1,30 @@
+{
+  "adrId": "ADR-701-delivery-ci-workflows-ci-gates",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "2.0.0",
+  "status": "accepted",
+  "title": "The project's CI runs a fixed ordered required check set (mandatory tier plus the elicited subset from workflowShape.checkSet) whose completeness is the merge criterion",
+  "context": "Continuous integration surfaces are a matrix of trigger events, runner definitions, and gates. The interesting decision area is not the runner or the trigger (a small dial with obvious answers) but the check set: which checks run, in which order, and what does 'the pipeline passed' mean. A project that changes its check set silently loses the property that the pipeline meant the same thing across two runs. Naming the check set as a decision area (not a runtime knob) is what makes the pipeline a stable contract. v2 broadens the answer surface from the fixed v1.0.0 two-gate set to a two-tier catalogue: a mandatory tier (the two v1 gates, preserved verbatim) plus an elicited tier (linter, formatter, typecheck, unitTest, securityScan) the project turns on and off through `workflowShape.checkSet`.",
+  "decision": "The project's CI runs a fixed ordered required check set at every workflow that carries one. The mandatory tier runs first, in order, on every check-set workflow: `validate` (running `rcf define validate`) followed by `coverage-strict` (running `rcf audit coverage --strict`). The elicited tier runs after the mandatory tier: the checks the project turned on in `workflowShape.checkSet` (default: every catalogued check on) run in a stable but non-load-bearing order documented in the guide. The pipeline passes if and only if every required check's outcome is `passed`; a `failed` or `missing` outcome on any required check fails the pipeline. Adding a check kind the catalogue does not name (mutation-testing, contract-test, accessibility scan) is a project-level or blueprint-level ADR: a project that wants an extra required check supersedes this ADR with a project-level ADR listing the extended catalogue; a future blueprint that ships a new required check (a browser-verify pack, an observability probe pack) contributes its own scope:global ADR on the `ciGates` topic and lets composition surface the pairing.",
+  "consequences": "The pipeline's verdict is stable across runs of the same commit under the same rcf CLI version and the same `workflowShape`. Adding a check is a visible decision (either a `workflowShape.checkSet` flag flip or a project-level ADR); changing the check catalogue itself is a v2.x major bump. A project that wants a check the catalogue does not name owes a project-level ADR that supersedes this one and names the extended catalogue; the aggregate report's `gates[]` array then reflects the extended catalogue on every run. Composing blueprints that hold an opinion on the required-check set conflict on the `ciGates` topic: an observability-essentials blueprint that ships health-probe gates as required conflicts here by design and expects a project-level ADR to resolve the pairing (or the operator adopts one of the two blueprints).",
+  "alternativesConsidered": [
+    {
+      "name": "Ship the gate set as a runtime configuration knob rather than as an ADR",
+      "summary": "The runner reads the gate set from a config file or environment variable, and any project reconfigures without a decision record.",
+      "reasonNotChosen": "A gate set that can silently change is one whose meaning drifts. The value of the aggregate report as a stable contract collapses if two runs of the same commit can have different gate sets. Making the gate set an ADR forces the reasoning to be recorded and forces a composing blueprint to conflict explicitly."
+    },
+    {
+      "name": "Ship a maximal required-check set at v2.0.0 (mandatory tier plus every plausible elicited check plus adherence packs plus browser-verify)",
+      "summary": "The pipeline runs every check the mechanism offers as required by default, with no elicitation surface.",
+      "reasonNotChosen": "The mechanism-reach principle for blueprints (authoring standard, section 7) says a blueprint should not compel a check the project has no reasonable path to satisfy. Adherence packs and browser-verify probes belong in future blueprints that ship the surface they enforce; requiring them here would leave every fresh project failing its pipeline until it realises those surfaces. The mandatory tier plus the five elicited checks the project turns on and off is the right v2.0.0 floor."
+    },
+    {
+      "name": "Keep the v1.0.0 fixed two-gate set at v2",
+      "summary": "The check set stays at `validate` + `coverage-strict`; the elicited tier does not ship.",
+      "reasonNotChosen": "Lint, formatter, typecheck, unit-test, and security-scan are checks a project engineer expects to find in a general-purpose CI floor; leaving v2 at the v1 two-gate set does not close that gap and leaves every consuming project reinventing the elicited tier as a project-level ADR."
+    }
+  ],
+  "createdAt": "2026-08-24T00:00:00Z",
+  "updatedAt": "2026-08-24T00:00:00Z"
+}

package/blueprints/delivery-ci-workflows/contributions/adrs/adr-702-delivery-ci-workflows-strict-coverage-gate.json

@@ -0,0 +1,25 @@
+{
+  "adrId": "ADR-702-delivery-ci-workflows-strict-coverage-gate",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "1.0.0",
+  "status": "accepted",
+  "title": "Coverage runs as per-AC strict; shallow-any is not accepted as a substitute in the required gate set",
+  "context": "The `rcf audit coverage` CLI runs in two modes: the default `shallow-any` (a REQ counts as covered when any AC on any US has any resolving TC) and the opt-in `--strict` (per-AC: every AC on every US must have a resolving TC). Shallow-any is useful for author-time exploration; it is the wrong mode for a merge-blocking gate because it hides the failure mode watchpost run4 caught in categories 5, 6, and 11 (an AC bound but no TC resolves it, and the REQ still reads as covered because some other AC's TC resolved). Choosing which coverage mode the pipeline runs is a policy decision distinct from choosing whether coverage runs at all.",
+  "decision": "The required-gate coverage invocation is `rcf audit coverage --strict`. Every AC on every US must resolve to a TC whose testPointer points at a real test; a `covered-unresolved` or uncovered AC fails the gate. Shallow-any is not accepted as a substitute in the required-gate set. A project that needs an author-time shallow-any view for exploration runs `rcf audit coverage` locally without `--strict`; the pipeline's gate is unaffected. Composing blueprints that ship a coverage gate hold this topic (`strictCoverageGate`) and conflict here by design: a hypothetical `delivery-ci-workflows-shallow` blueprint or a project that wants the shallow-any mode as its floor supersedes this ADR with a project-level ADR stating the reasoning.",
+  "consequences": "Every AC the RCF chain contributes must have a TC bound in the project's own build cycle before the pipeline turns green. That is the mechanism-reach discipline the strict mode enforces: shipping an AC without a TC is caught here, not in production. Composing blueprints (this one and any coverage-shipping blueprint the ecosystem grows) conflict on `strictCoverageGate` for one project-level ADR to fix. A project that thoughtfully accepts a shallow-any floor (small project, exploration phase, no operator-facing surface yet) authors that ADR and the pipeline follows.",
+  "alternativesConsidered": [
+    {
+      "name": "Run shallow-any as the required mode with strict as a warning gate",
+      "summary": "The pipeline runs `rcf audit coverage` in shallow-any mode as required and `rcf audit coverage --strict` as a soft advisory gate whose outcome does not block merge.",
+      "reasonNotChosen": "A warning gate people learn to ignore is a gate that does not exist. The strict-mode failures watchpost run4 caught were exactly the ones a warning-only gate would have surfaced and been dismissed. Strict as required is the shape that makes the mechanism useful in review."
+    },
+    {
+      "name": "Run strict only after a grace period per REQ / US",
+      "summary": "Newly introduced ACs get a configurable grace window during which strict does not enforce coverage; established ACs must have coverage.",
+      "reasonNotChosen": "A grace window is another gate-set knob whose meaning drifts across projects. The current shape (project-level ADR to relax) is the sharper knob; a project that genuinely needs a rolling window authors it as a project-level ADR and lists the reasoning."
+    }
+  ],
+  "createdAt": "2026-08-24T00:00:00Z",
+  "updatedAt": "2026-08-24T00:00:00Z"
+}

package/blueprints/delivery-ci-workflows/contributions/adrs/adr-703-delivery-ci-workflows-node-only-runner.json

@@ -0,0 +1,25 @@
+{
+  "adrId": "ADR-703-delivery-ci-workflows-node-only-runner",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "1.0.0",
+  "status": "accepted",
+  "title": "The gate runner is a single Node entry point; one illustrative GitHub Actions workflow is shipped; alternate providers wire the same script",
+  "context": "A blueprint that ships CI configuration has two shapes to pick between. Shape one: contribute a provider-specific configuration file (a GitHub Actions workflow YAML, a GitLab CI YAML, a CircleCI config) with every gate spelled in that provider's runner language. Shape two: contribute a Node entry-point script that any provider invokes with one command line, and ship one illustrative provider example as a starting point. Shape one locks the project to the picked provider; shape two lets any provider that can run Node host the pipeline. The rcf-lite tier does not privilege one provider.",
+  "decision": "The blueprint ships shape two. The gate runner is a single Node entry-point script the project realises under its source tree; every gate-specific piece of logic (spawning the child, capturing streams, writing per-gate reports, writing the aggregate report, surfacing failure) lives in Node. The blueprint's package resources include exactly one illustrative provider workflow: `assets/ci-provider-examples/github-actions.yml`, chosen because GitHub Actions is the most widely deployed among rcf-lite candidate projects. The guide names GitLab CI, CircleCI, Buildkite, and Jenkins as equally supported and describes the four-point mapping (job trigger event, Node setup, single-line entry-point invocation, artefact upload) for each. No provider-specific configuration file for those runners is shipped at v1.0.0. A future blueprint that ships one, or a project that hand-authors one, wires the same Node entry point.",
+  "consequences": "A project on any CI provider that can run Node (every mainstream provider) hosts the pipeline with a one-line invocation. Moving between providers is a rewrite of the trigger definition and the artefact-upload step, not a rewrite of the gates. The illustrative GitHub Actions workflow is a starting point, not a blessed choice: an operator moving to another provider translates the four mapping points and keeps the entry-point invocation unchanged. The blueprint does not carry the maintenance cost of a matrix of provider examples; each example would need to track that provider's syntax changes and version pins, which is a per-provider decision the project owns.",
+  "alternativesConsidered": [
+    {
+      "name": "Ship a matrix of provider-specific configuration files (GHA + GitLab CI + CircleCI + Buildkite + Jenkins) at v1.0.0",
+      "summary": "The blueprint contributes one configuration file per supported provider so the operator can copy the one that matches.",
+      "reasonNotChosen": "Every provider file needs its own version pins, its own action or plugin references, and its own syntax bumps. Five files stale at different rates and the blueprint's ship gate would include verifying every one still works on every provider. One worked example plus the mapping paragraph is the sharper contribution."
+    },
+    {
+      "name": "Ship a bash gate runner instead of Node",
+      "summary": "The gate runner is a shell script the CI provider invokes.",
+      "reasonNotChosen": "Bash is not portable across the operator's development host (macOS default bash is 3.2, Windows has no bash without WSL, and cross-platform bash gymnastics are the shape that ships broken). Node runs identically on every host that ships an rcf-lite project, and the same Node runtime that runs the underlying rcf CLI runs the gate runner without a second toolchain."
+    }
+  ],
+  "createdAt": "2026-08-24T00:00:00Z",
+  "updatedAt": "2026-08-24T00:00:00Z"
+}

package/blueprints/delivery-ci-workflows/contributions/adrs/adr-704-delivery-ci-workflows-report-shape.json

@@ -0,0 +1,25 @@
+{
+  "adrId": "ADR-704-delivery-ci-workflows-report-shape",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "2.0.0",
+  "status": "accepted",
+  "title": "Per-gate and aggregate reports are JSON files at stable paths under a configured report directory; missing reports are never treated as an implicit pass",
+  "context": "A pipeline whose only artefact is the CI provider's own runner-log surface leaves every downstream reader (reviewer, dashboard, audit tool) parsing text or hitting the provider's artefact API. A pipeline whose reports are files at stable paths with stable schemas turns every downstream reader into a JSON reader. The reporting shape is a decision that binds the runner (TAC-701), the per-gate writer (TAC-702), the aggregate writer (TAC-703), and every future consumer.",
+  "decision": "Every gate the suite runs writes a per-gate JSON report at `<reportDir>/<gate>.json` with a fixed key set (gate, command, toolVersion, startedAt, endedAt, durationMs, exitCode, outcome, stdout, stderr, checkKind). The v2 addition `checkKind` records the elicited-check kind (`validate`, `coverage-strict`, `linter`, `formatter`, `typecheck`, `unitTest`, `securityScan`, or `custom:<name>`); the v1 key set is preserved verbatim as a strict subset. The suite writes one aggregate JSON report at `<reportDir>/pipeline.json` with a fixed key set (verdict, trigger, startedAt, endedAt, durationMs, runner, gates[]); v2 preserves this shape unchanged. The default report directory is `.rcf/reports/ci/`. Distinct workflows write to distinct aggregate paths where their outcomes are semantically different (the release workflow writes to `.rcf/reports/ci/release.json`; the scheduled-audit workflow writes to `.rcf/reports/ci/scheduled-audit.json`); the commit-triggered aggregate stays at `.rcf/reports/ci/pipeline.json`. Both schemas are stable within a blueprint major version: additive fields are a minor bump, renamed or removed fields are a major bump. Reports are written atomically (temp file plus rename) so a killed writer leaves either the previous file or no file. A required gate whose per-gate report is missing from disk at end-of-suite is recorded in the aggregate as `outcome: missing` with a reason string, and the aggregate verdict is `failed`. A missing report is never treated as an implicit pass.",
+  "consequences": "Downstream readers pick up per-run outcomes without re-running gates and without scraping the CI provider's log surface. Long-lived tools (a coverage-trend dashboard, an audit log, a merge-queue gate) depend on stable paths and stable schemas; the discipline here is what makes those tools cheap to write. The aggregate report is the single record the reviewer opens first; its `gates[]` array in fixed configured order is the ordering contract. A runner crash mid-suite (the failure mode REQ-008 closes) is visible in the aggregate rather than silently omitted. The atomic-write posture costs one extra file-system syscall per report; the truncation cap on stdout/stderr costs the tail of a very verbose gate.",
+  "alternativesConsidered": [
+    {
+      "name": "Use JUnit XML as the per-gate report format",
+      "summary": "The runner emits per-gate JUnit XML files so the CI provider's own JUnit ingestor can parse them.",
+      "reasonNotChosen": "JUnit XML is a test-report format, not a gate-invocation format; the schema does not carry the fields the aggregate report needs (tool version, captured streams, structured exit code, gate ordering). A downstream reader that wants a JUnit view of the pipeline layers a JUnit converter over the JSON reports on the side; the blueprint does not ship it as the primary surface."
+    },
+    {
+      "name": "Rely on the CI provider's artefact system without writing report files",
+      "summary": "The runner writes to stdout only; every downstream reader retrieves outcomes through the provider's artefact or annotation API.",
+      "reasonNotChosen": "That posture couples every downstream reader to the CI provider's API and breaks the local-parity property REQ-010 mandates (the developer running the entry point locally has no report file to inspect). Files at stable paths under a configured directory are equally available in CI (uploaded as artefacts) and locally (read from disk)."
+    }
+  ],
+  "createdAt": "2026-08-24T00:00:00Z",
+  "updatedAt": "2026-08-24T00:00:00Z"
+}

package/blueprints/delivery-ci-workflows/contributions/adrs/adr-705-delivery-ci-workflows-elicitation-surface.json

@@ -0,0 +1,25 @@
+{
+  "adrId": "ADR-705-delivery-ci-workflows-elicitation-surface",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "2.0.0",
+  "status": "accepted",
+  "title": "The workflowShape elicitation surface lives in the in-repo file `.rcf/config/delivery-ci-workflows.json` at v2.0.0",
+  "context": "The v2 workflow set scales along four elicited dimensions the project declares once. Two candidate locations for the declaration were considered: an in-repo config file at a stable path, and a manifest-embedded per-blueprint config slot (`manifest.blueprints[<slug>].config`). The manifest slot is the natural mechanism-side home if and when rcf-lite grows a per-blueprint config surface; that facility does not ship at v2.0.0.",
+  "decision": "v2.0.0 requires the project to ship the `workflowShape` declaration at the stable path `.rcf/config/delivery-ci-workflows.json`. The path is documented in the blueprint guide and the mechanism does not extend the manifest for it. The workflow-materialiser reads this file on every run and refuses to boot when it is missing or malformed. If and when rcf-lite ships a per-blueprint manifest-embedded config surface, this ADR is superseded by a v2.x ADR that widens the source to accept either the manifest entry or the in-repo file (with the manifest entry taking precedence when both are present).",
+  "consequences": "The elicitation surface ships without waiting on a mechanism-side extension. The location is greppable and version-controllable; a project change to the workflow shape is a diff on one file. The workflow-materialiser has a single source of truth. When the manifest-embedded surface lands in the future, the migration is additive and does not break existing v2 projects.",
+  "alternativesConsidered": [
+    {
+      "name": "Ship the elicitation surface manifest-embedded from v2.0.0",
+      "summary": "The mechanism extends `manifest.blueprints[<slug>]` with a `config` slot; the blueprint's validation runs on apply.",
+      "reasonNotChosen": "The mechanism-side extension is a separate rcf-lite work item outside v2.0.0's scope; blocking v2 on it delays a feature-gap fix the strongly-recommended list names as biggest."
+    },
+    {
+      "name": "Ship the elicitation surface as environment variables the CI provider supplies",
+      "summary": "The workflow-materialiser reads `RCF_BRANCH_MODEL`, `RCF_CHECK_SET`, etc. from the provider environment.",
+      "reasonNotChosen": "Environment variables that gate control flow break the local-parity property REQ-010 (v1) mandates and every AC that binds to the declaration would have to work equally in CI and on a developer machine. A file at a stable path in the project tree is equally available in both."
+    }
+  ],
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

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"
+}