rcf-lite 0.13.0 → 0.14.0

package/blueprints/ci-pipeline/assets/ci-provider-examples/github-actions.yml

@@ -1,61 +0,0 @@
-# Illustrative GitHub Actions workflow for the ci-pipeline blueprint.
-# Copy this file into the host project as `.github/workflows/rcf-ci.yml`
-# and adjust the `node-version`, package-manager setup, and entry-point
-# path to match the project's realised gate runner (TAC-701).
-#
-# The workflow runs one CI-provider-neutral Node entry point that
-# invokes `rcf define validate` and `rcf audit coverage --strict`,
-# writes per-gate and aggregate JSON reports under `.rcf/reports/ci/`,
-# and uploads the report directory as a workflow artefact for
-# downstream readers.
-#
-# See `guide/ci-pipeline.md` (four-point mapping) for translating
-# this workflow to GitLab CI, CircleCI, Buildkite, or Jenkins.
-
-name: rcf-ci
-
-on:
-  push:
-    branches: [main]
-  pull_request:
-    branches: [main]
-
-jobs:
-  rcf-gates:
-    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
-
-      # Single-line invocation of the project's realised gate runner.
-      # The runner spawns `rcf define validate` then `rcf audit coverage --strict`,
-      # writes `.rcf/reports/ci/<gate>.json` per gate, and writes
-      # `.rcf/reports/ci/pipeline.json` as the aggregate. Its exit code
-      # is the pipeline's aggregate exit code.
-      - name: run rcf ci gates
-        run: node scripts/rcf-ci.js
-
-      - name: upload rcf ci reports
-        if: always()
-        uses: actions/upload-artifact@v4
-        with:
-          name: rcf-ci-reports
-          path: .rcf/reports/ci/
-          if-no-files-found: warn
-          retention-days: 30

package/blueprints/ci-pipeline/assets/ci-provider-examples/notes.md

@@ -1,50 +0,0 @@
-# Wiring the gate runner on alternate CI providers
-
-The blueprint ships one illustrative provider example (GitHub Actions, `github-actions.yml`). Every mainstream provider hosts the same pipeline by translating four points and keeping the Node entry-point invocation unchanged. These notes are read alongside `guide/ci-pipeline.md`, not instead of it.
-
-## The four mapping points
-
-1. Job trigger. Fire the job on a push to the default branch AND on every pull request opened, synchronised, or reopened against the default branch.
-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); upload the configured report directory as a run artefact for downstream readers.
-
-The blueprint does not ship provider-specific configuration files for the providers below at v1.0.0. A project hand-authors the first three points in the provider's own runner language and keeps the fourth unchanged.
-
-## GitLab CI (`.gitlab-ci.yml`)
-
-- Trigger: `rules:` with `if: $CI_COMMIT_BRANCH == "main"` for the push half, `if: $CI_PIPELINE_SOURCE == "merge_request_event" && $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "main"` for the merge-request half.
-- 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`.
-- Artefact upload: `artifacts: { when: always, paths: [.rcf/reports/ci/] }`.
-
-## CircleCI (`.circleci/config.yml`)
-
-- Trigger: `workflows:` with `filters: { branches: { only: [main] } }` for the push half; pull-request contexts are handled through CircleCI's GitHub integration or via the `pull_request_number` pipeline parameter.
-- Node setup: `cimg/node:24.19` or the `node/install` orb command.
-- Install: `pnpm install --frozen-lockfile`.
-- Invoke: `node scripts/rcf-ci.js`.
-- Artefact upload: `store_artifacts: { path: .rcf/reports/ci }`.
-
-## Buildkite (`.buildkite/pipeline.yml`)
-
-- Trigger: pipeline-level branch conditions or per-step `branches: main` with additional pull-request-only steps triggered through Buildkite's GitHub integration.
-- 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: `node scripts/rcf-ci.js`.
-- Artefact upload: `artifact_paths: [".rcf/reports/ci/**"]`.
-
-## Jenkins (declarative pipeline)
-
-- Trigger: `triggers { githubPush() }` plus a multibranch pipeline configured to build pull requests against the default branch.
-- 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'`.
-- Artefact upload: `archiveArtifacts artifacts: '.rcf/reports/ci/**', allowEmptyArchive: true`.
-
-## Cross-provider notes
-
-- The Node entry-point path is 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 report.
-- 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.

package/blueprints/ci-pipeline/blueprint.json

@@ -1,46 +0,0 @@
-{
-  "slug": "ci-pipeline",
-  "version": "1.0.0",
-  "category": "delivery",
-  "contributions": [
-    { "id": "ci-pipeline-REQ-001", "kind": "req", "path": "requirements/ci-pipeline-req-001.json" },
-    { "id": "ci-pipeline-REQ-002", "kind": "req", "path": "requirements/ci-pipeline-req-002.json" },
-    { "id": "ci-pipeline-REQ-003", "kind": "req", "path": "requirements/ci-pipeline-req-003.json" },
-    { "id": "ci-pipeline-REQ-004", "kind": "req", "path": "requirements/ci-pipeline-req-004.json" },
-    { "id": "ci-pipeline-REQ-005", "kind": "req", "path": "requirements/ci-pipeline-req-005.json" },
-    { "id": "ci-pipeline-REQ-006", "kind": "req", "path": "requirements/ci-pipeline-req-006.json" },
-    { "id": "ci-pipeline-REQ-007", "kind": "req", "path": "requirements/ci-pipeline-req-007.json" },
-    { "id": "ci-pipeline-REQ-008", "kind": "req", "path": "requirements/ci-pipeline-req-008.json" },
-    { "id": "ci-pipeline-REQ-009", "kind": "req", "path": "requirements/ci-pipeline-req-009.json" },
-    { "id": "ci-pipeline-REQ-010", "kind": "req", "path": "requirements/ci-pipeline-req-010.json" },
-    { "id": "ci-pipeline-US-6101", "kind": "us", "path": "user-stories/ci-pipeline-us-6101.json" },
-    { "id": "ci-pipeline-US-6102", "kind": "us", "path": "user-stories/ci-pipeline-us-6102.json" },
-    { "id": "ci-pipeline-US-6103", "kind": "us", "path": "user-stories/ci-pipeline-us-6103.json" },
-    { "id": "ci-pipeline-US-6104", "kind": "us", "path": "user-stories/ci-pipeline-us-6104.json" },
-    { "id": "ci-pipeline-US-6105", "kind": "us", "path": "user-stories/ci-pipeline-us-6105.json" },
-    { "id": "ci-pipeline-US-6106", "kind": "us", "path": "user-stories/ci-pipeline-us-6106.json" },
-    { "id": "ci-pipeline-US-6107", "kind": "us", "path": "user-stories/ci-pipeline-us-6107.json" },
-    { "id": "ci-pipeline-US-6108", "kind": "us", "path": "user-stories/ci-pipeline-us-6108.json" },
-    { "id": "ci-pipeline-US-6109", "kind": "us", "path": "user-stories/ci-pipeline-us-6109.json" },
-    { "id": "ci-pipeline-US-6110", "kind": "us", "path": "user-stories/ci-pipeline-us-6110.json" },
-    { "id": "TAC-701-ci-pipeline-gate-runner", "kind": "tac", "path": "tacs/tac-701-ci-pipeline-gate-runner.json" },
-    { "id": "TAC-702-ci-pipeline-gate-report", "kind": "tac", "path": "tacs/tac-702-ci-pipeline-gate-report.json" },
-    { "id": "TAC-703-ci-pipeline-aggregate-report", "kind": "tac", "path": "tacs/tac-703-ci-pipeline-aggregate-report.json" },
-    {
-      "id": "ADR-701-ci-pipeline-ci-gates",
-      "kind": "adr",
-      "path": "adrs/adr-701-ci-pipeline-ci-gates.json",
-      "scope": "global",
-      "topic": "ciGates"
-    },
-    {
-      "id": "ADR-702-ci-pipeline-strict-coverage-gate",
-      "kind": "adr",
-      "path": "adrs/adr-702-ci-pipeline-strict-coverage-gate.json",
-      "scope": "global",
-      "topic": "strictCoverageGate"
-    },
-    { "id": "ADR-703-ci-pipeline-node-only-runner", "kind": "adr", "path": "adrs/adr-703-ci-pipeline-node-only-runner.json" },
-    { "id": "ADR-704-ci-pipeline-report-shape", "kind": "adr", "path": "adrs/adr-704-ci-pipeline-report-shape.json" }
-  ]
-}

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

@@ -1,25 +0,0 @@
-{
-  "adrId": "ADR-701-ci-pipeline-ci-gates",
-  "prdId": "PRD-001",
-  "tadId": "TAD-001",
-  "version": "1.0.0",
-  "status": "accepted",
-  "title": "The project's CI runs a fixed ordered required-gate set (validate then coverage-strict at v1.0.0) 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 gate set: which gates run, in which order, and what does 'the pipeline passed' mean. A project that changes its gate set silently loses the property that the pipeline meant the same thing across two runs. The rcf-lite tier this blueprint targets is small greenfield: one tree, one default branch, one merge policy. Naming the gate set as a decision area (not a runtime knob) is what makes the pipeline a stable contract.",
-  "decision": "The project's CI runs a fixed ordered required-gate set. At v1.0.0 the set is exactly two gates in order: `validate` (running `rcf define validate`) followed by `coverage-strict` (running `rcf audit coverage --strict`). The pipeline passes if and only if every required gate's outcome is `passed`; a `failed` or `missing` outcome on any required gate fails the pipeline. Adding a required gate is a project-level or blueprint-level ADR: a project that wants an extra required gate (a linter, a unit-test runner, an adherence pack) supersedes this ADR with a project-level ADR listing the extended set; a future blueprint that ships a new required gate (an observability probe pack) is a blueprint version bump on this ADR's topic. The set is deliberately kept small at v1.0.0: two gates that speak to the RCF chain and its coverage. Every additional gate is a decision the project owes an ADR for.",
-  "consequences": "The pipeline's verdict is stable across runs of the same commit under the same rcf CLI version. Adding a gate is a visible decision, not a diff to a job file. A project that wants a hotter set of gates (adherence packs, browser-verify smokes, style linters) owes a project-level ADR that supersedes this one and lists the extended set; the aggregate report's `gates[]` array then reflects the extended set on every run. Composing blueprints that hold an opinion on the required-gate 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-gate set at v1.0.0 (validate + coverage-strict + adherence packs + browser-verify)",
-      "summary": "The pipeline runs every gate the mechanism offers as required by default.",
-      "reasonNotChosen": "The mechanism-reach principle for blueprints (authoring standard, section 7) says a blueprint should not compel a gate 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. Two gates the mechanism already ships and every project can satisfy is the right v1.0.0 floor."
-    }
-  ],
-  "createdAt": "2026-08-24T00:00:00Z",
-  "updatedAt": "2026-08-24T00:00:00Z"
-}

package/blueprints/ci-pipeline/contributions/requirements/ci-pipeline-req-001.json

@@ -1,18 +0,0 @@
-{
-  "reqId": "ci-pipeline-REQ-001",
-  "prdId": "PRD-001",
-  "title": "Every push and pull request into the default branch runs the RCF gate suite as a required check",
-  "description": "The project's continuous integration pipeline runs the RCF gate suite on every push to the default branch and on every pull request that targets the default branch. The suite's aggregate exit status is the merge criterion: the branch protection or equivalent policy refuses to merge a pull request whose most recent suite run did not exit zero. No manual override path bypasses the suite; a hotfix that skips the suite requires a documented ADR trail.",
-  "category": "functional",
-  "domain": "continuous-integration",
-  "priority": "must",
-  "rationale": "Gates that run sometimes are gates that fail sometimes. Wiring the suite as a required check on every push and pull request into the default branch turns the RCF chain 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.",
-  "tags": [
-    "blueprint:ci-pipeline",
-    "category:01-required-check"
-  ],
-  "version": "1.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-009.json

@@ -1,18 +0,0 @@
-{
-  "reqId": "ci-pipeline-REQ-009",
-  "prdId": "PRD-001",
-  "title": "The blueprint documents one illustrative GitHub Actions workflow; alternate providers wire the same entry point per their own runner language",
-  "description": "The blueprint's package resources include one illustrative GitHub Actions workflow file (`assets/ci-provider-examples/github-actions.yml`) that names the required repository events (push to default branch, pull_request into default branch), sets up Node and the package manager, installs dependencies, invokes the Node gate entry point, 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 mapping (job trigger, Node setup, single-line entry-point invocation, artefact upload), and states that the blueprint does not ship provider-specific configuration for those runners.",
-  "category": "functional",
-  "domain": "continuous-integration",
-  "priority": "must",
-  "rationale": "One worked example spelled in one runner language is more useful to the reader than a matrix of half-specified examples. GitHub Actions is the illustrative pick because it is the most widely deployed among rcf-lite candidate projects, not because it is privileged. The mapping to other providers is small enough that a paragraph of guide prose plus the one worked example is the right cost.",
-  "tags": [
-    "blueprint:ci-pipeline",
-    "category:09-provider-example"
-  ],
-  "version": "1.0.0",
-  "status": "approved",
-  "createdAt": "2026-08-24T00:00:00Z",
-  "updatedAt": "2026-08-24T00:00:00Z"
-}

package/blueprints/ci-pipeline/contributions/user-stories/ci-pipeline-us-6101.json

@@ -1,37 +0,0 @@
-{
-  "usId": "ci-pipeline-US-6101",
-  "prdId": "PRD-001",
-  "reqId": "ci-pipeline-REQ-001",
-  "version": "1.0.0",
-  "status": "approved",
-  "title": "Every push and pull request into the default branch runs the RCF gate suite as a required check",
-  "asA": "operator merging changes to the default branch of an rcf-lite project",
-  "iWant": "the RCF gate suite to run automatically on every push to the default branch and every pull request into it, and its outcome to be the merge criterion",
-  "soThat": "no change lands on the default branch without the chain and its coverage having been verified against the tree at the head commit",
-  "acceptanceCriteria": [
-    {
-      "id": "AC-6101-1",
-      "description": "The CI provider's job for the pipeline is triggered by a push to the default branch and by every pull request opened, synchronised, or reopened against the default branch. The trigger configuration is committed under source control, not set through a provider UI.",
-      "given": "the project's CI configuration and repository state at the head commit",
-      "when": "a push lands on the default branch or a pull request is opened, synchronised, or reopened against the default branch",
-      "then": "the aggregate pipeline report at the configured stable path (default `.rcf/reports/ci/pipeline.json`) is written by the resulting CI job, and its `trigger` field records the event kind",
-      "testable": true,
-      "scope": "runtime"
-    },
-    {
-      "id": "AC-6101-2",
-      "description": "The pull-request merge policy blocks a merge whose most recent pipeline run did not exit zero. The block is enforced by the repository's branch protection or equivalent policy configured for the default branch.",
-      "given": "a pull request whose most recent pipeline run's aggregate report records `verdict: failed`",
-      "when": "the operator or an automated merge tool attempts to merge the pull request through the standard merge path",
-      "then": "the merge is refused by the platform's branch-protection surface, and the refusal reason references the failed required check that corresponds to the pipeline job",
-      "testable": true,
-      "scope": "runtime"
-    }
-  ],
-  "tacIds": [
-    "TAC-701-ci-pipeline-gate-runner",
-    "TAC-703-ci-pipeline-aggregate-report"
-  ],
-  "createdAt": "2026-08-24T00:00:00Z",
-  "updatedAt": "2026-08-24T00:00:00Z"
-}

package/blueprints/ci-pipeline/contributions/user-stories/ci-pipeline-us-6109.json

@@ -1,36 +0,0 @@
-{
-  "usId": "ci-pipeline-US-6109",
-  "prdId": "PRD-001",
-  "reqId": "ci-pipeline-REQ-009",
-  "version": "1.0.0",
-  "status": "approved",
-  "title": "The blueprint provides one illustrative GitHub Actions example; alternate providers wire the same entry point",
-  "asA": "operator setting up CI on an rcf-lite project for the first time",
-  "iWant": "one worked example that shows the entire trigger, setup, invoke, and artefact-upload shape",
-  "soThat": "I have a copy-paste starting point regardless of which provider I use",
-  "acceptanceCriteria": [
-    {
-      "id": "AC-6109-1",
-      "description": "The applied blueprint's source path (recorded on `manifest.blueprints[ci-pipeline].source`) contains an illustrative GitHub Actions workflow at `assets/ci-provider-examples/github-actions.yml`. The workflow defines the required triggers (push to the default branch and pull_request into it), sets up Node and the package manager, installs dependencies, invokes the Node entry point as a single command line, and uploads the report directory as a workflow artefact.",
-      "given": "an rcf-lite project that has applied this blueprint",
-      "when": "the operator opens the blueprint's source path and reads `assets/ci-provider-examples/github-actions.yml`",
-      "then": "the workflow file exists at that path, its `on:` block names `push` on the default branch and `pull_request`, its steps include a Node setup and a package-manager setup, one step invokes the gate entry point as a single `node <path>` line (or a package-manager script that resolves to the same), and a final step uploads the configured report directory as a workflow artefact",
-      "testable": true,
-      "scope": "runtime"
-    },
-    {
-      "id": "AC-6109-2",
-      "description": "The applied blueprint's guide names GitLab CI, CircleCI, Buildkite, and Jenkins as equally supported providers, states the mapping (job trigger, Node setup, single-line entry-point invocation, artefact upload), and states that the blueprint does not ship provider-specific configuration for those runners.",
-      "given": "an rcf-lite project that has applied this blueprint",
-      "when": "the operator opens `guide/ci-pipeline.md` from the blueprint's source path",
-      "then": "the guide's `when to reach for it` or an adjacent section names GitLab CI, CircleCI, Buildkite, and Jenkins by name, describes the four mapping points, and states that no provider-specific configuration file for those runners is shipped by the blueprint at v1.0.0",
-      "testable": true,
-      "scope": "runtime"
-    }
-  ],
-  "tacIds": [
-    "TAC-701-ci-pipeline-gate-runner"
-  ],
-  "createdAt": "2026-08-24T00:00:00Z",
-  "updatedAt": "2026-08-24T00:00:00Z"
-}

package/blueprints/ci-pipeline/docs/topics.md

@@ -1,49 +0,0 @@
-# ci-pipeline blueprint coordination vocabulary
-
-This file is the ci-pipeline half of the cross-blueprint contract. The Phase 1 conflict detector matches scope:global ADR topics by EXACT string equality, and AC ids are unnamespaced by the 0.4.4 grammar. Any blueprint intended to compose with this one must reuse these exact strings and respect these bands.
-
-## Global ADR topics this blueprint contributes (exact strings)
-
-| Topic string | ci-pipeline contribution | Origin | Composition note |
-|---|---|---|---|
-| `ciGates` | ADR-701-ci-pipeline-ci-gates | Minted here; pre-cleared as unclaimed against application-spa (`clientRouting`, `theming`, `clientState`, `errorEnvelope`, `authModel`), application-api-rest (`errorEnvelope`, `authModel`, `apiVersioning`, `logging`), security-auth-magic-link (`authModel`), persistence-data-sqlite (`persistenceStore`, `migrationDiscipline`), and the hello-panel walkthrough exemplar (`operatorPanel`) | The fixed ordered required-gate set the pipeline runs. Any composing blueprint that ships its own required-gate opinion (an adherence-pack blueprint, a browser-verify blueprint, an observability probe blueprint) contributes its own scope:global ADR on this exact string and lets composition surface the pairing. Expected resolution: one project-level ADR that fixes the extended set and states the reasoning |
-| `strictCoverageGate` | ADR-702-ci-pipeline-strict-coverage-gate | Minted here; pre-cleared as unclaimed against application-spa, application-api-rest, security-auth-magic-link, persistence-data-sqlite, and hello-panel | The coverage-mode posture for the required gate (per-AC strict, not shallow-any). A composing blueprint that holds an opinion on coverage-mode policy (a shallow-any-for-early-projects blueprint, a coverage-with-grace-window blueprint) conflicts here by design. Expected resolution: one project-level ADR fixing the coverage posture |
-
-The ci-pipeline blueprint claims two global topics. Every other contribution is scope-local (ADR-703 on node-only runner shape and ADR-704 on report shape do not contribute global topics; a composing blueprint that holds an opinion on runner language or report shape authors its own project-level ADR if it wants to override).
-
-Note on the delineation from the application-api-rest blueprint's `logging` topic and the persistence-data-sqlite blueprint's store event log: `logging` (owned by application-api-rest ADR-304) governs the wire-log shape of the HTTP tier; persistence ADR-603 governs the store-event log shape. This blueprint's report shape (ADR-704) governs the pipeline-run report shape, which is a build-time artefact, not a runtime log. The three surfaces may share a shipper but do not share a topic. A blueprint that contributes a unified telemetry discipline across build-time and runtime surfaces would author its own scope:global ADR and expect to conflict with all three, not just here.
-
-Rules for new topics (inherited from the application-spa, application-api-rest, security-auth-magic-link, and persistence vocabularies, restated as law): lower camel case, one concept per topic, no version suffixes. A topic names the decision area, not the chosen answer. Do not mint variants of existing strings (`ciChecks`, `pipelineGates`, `strictCoverage`, `coverageStrict` are all wrong when `ciGates` and `strictCoverageGate` already exist).
-
-## Id number bands (registry bootstrap)
-
-AC ids (and therefore US numeric ids, which anchor them) are NOT namespaced by the 0.4.4 schema grammar; the band allocation IS the AC-collision enforcement mechanism. Composing blueprints take a fresh band rather than proposing namespaced AC ids. Band allocation is ratified policy (2026-08-19); this table is the shared registry-bootstrap replicated across every shipped and forthcoming blueprint's `docs/topics.md` until a mechanism-side central registry lands (v1.1 candidate).
-
-This table is maintained shelf-wide across every blueprint's `docs/topics.md`. Rows are recorded at ship, never predicted.
-
-| Blueprint | US band | ADR/TAC suffix block | Status | Global topics |
-|---|---|---|---|---|
-| application-spa | 1101-1899 | 2xx | shipped v1.3.0 | `clientRouting`, `theming`, `clientState`, `errorEnvelope`, `authModel` |
-| application-api-rest | 2101-2899 | 3xx | shipped v1.0.0 | `errorEnvelope`, `authModel`, `apiVersioning`, `logging` |
-| security-auth-magic-link | 3101-3899 | 5xx | shipped v1.0.0 | `authModel` |
-| email-smtp-resend | 4101-4899 | 4xx | shipped v1.0.0 | none |
-| hello-panel (walkthrough exemplar) | 4101-4899 | 4xx | doc-reserved; teaching exemplar in `packages/rcf-lite/docs/blueprint-authoring-walkthrough.md`, not shipped as a blueprint directory | `operatorPanel` |
-| persistence-data-sqlite | 5101-5899 | 6xx | shipped v1.0.0 | `persistenceStore`, `migrationDiscipline` |
-| ci-pipeline | 6101-6899 | 7xx | shipped v1.0.0 | `ciGates`, `strictCoverageGate` |
-| observability-essentials | 7101-7899 | 8xx | shipped v1.0.0 | `healthProbes`, `readinessSemantics`, `statusPageContract` |
-| security-secrets-management | 8101-8899 | 9xx | shipped v1.0.0 | `secretsSource` |
-| security-auth-clerk | 9101-9899 | 10xx | shipped v1.0.0 | `authModel` |
-| security-auth-oauth2 | 10101-10899 | 11xx | shipped v1.0.0 | `authModel` |
-| security-auth-keycloak | 11101-11899 | 12xx | shipped v1.0.0 | `authModel` |
-| deploy-cloudflare-workers | 12101-12899 | 13xx | shipped v1.0.0 | `deploymentTarget` |
-| persistence-data-d1 | 13101-13899 | 14xx | shipped v1.0.0 | `persistenceStore`, `migrationDiscipline` |
-| observability-probe-endpoints | 14101-14899 | 15xx | shipped v1.0.0 | `healthProbes`, `readinessSemantics` |
-
-US 6101-6110 sit at the LOW end of the 6101-6899 band on purpose. A project-side story that mechanically derives from `ci-pipeline-REQ-011` into the number `6111` would collide against ci-pipeline-US-6111 in this package; the band leaves headroom at the HIGH end (US 6181-6899) so a project's own stories anchored to ci-pipeline REQs can allocate without conflict. The watchpost run4 lesson applies here too.
-
-## Shared expectations for future composing blueprints
-
-- Reuse `ciGates` exactly as spelled here when your blueprint holds an opinion on the required-gate set the pipeline runs; contribute your own scope:global ADR on that string and let composition surface the pairing. An observability-essentials blueprint that ships health-probe or status-page gates as required will conflict here by design.
-- Reuse `strictCoverageGate` exactly as spelled here when your blueprint holds an opinion on the coverage-mode policy (strict per-AC versus shallow-any versus grace-window); a blueprint that ships a different posture conflicts here.
-- This blueprint's decision states the two required gates at v1.0.0 (`validate` and `coverage-strict` in that order) and the Node-only entry-point shape. Compose compatible adherence packs, browser-verify shipping, or observability probes, or expect the operator to supersede with one project-level ADR per topic.
-- Global topics that plausibly belong to a future blueprint and are NOT claimed by any shipped blueprint: `healthProbes`, `statusPageContract`, and `readinessSemantics` (an observability-essentials blueprint's natural globals), `adherencePack` (an adherence-shipping blueprint's natural global), and `mutationSampling` (a mutation-testing blueprint's natural global). Define any of these in your own package's topics doc, in this file's format, and consider whether the band-registry table above needs your slug added.

package/blueprints/ci-pipeline/guide/ci-pipeline.md

@@ -1,79 +0,0 @@
-# Ci-pipeline blueprint guide
-
-## What it is
-
-A default CI floor for rcf-lite projects. The blueprint contributes the WHAT of a pipeline pattern: which gates run, in which order, what constitutes a passed run, what report files land on disk after every run, and how a failing run surfaces the failing gate in the operator's own log tail. The pipeline is a single Node entry-point script the CI job invokes with one line, and the gate set at v1.0.0 is exactly two required gates: `rcf define validate` followed by `rcf audit coverage --strict`.
-
-Concretely, the blueprint ships ten requirements, ten user stories (twenty acceptance criteria), three architecture components, and four architecture decision records. Two ADRs are `scope: global` on the topics `ciGates` (the fixed required-gate set) and `strictCoverageGate` (the per-AC strict coverage posture); the other two are scope-local (the Node-only runner shape and the JSON report shape) that a composing blueprint does not conflict with by default.
-
-## What it is not
-
-Not a matrix of provider-specific configuration files. One illustrative GitHub Actions workflow ships under `assets/ci-provider-examples/github-actions.yml` as a copy-paste starting point. Alternate providers (GitLab CI, CircleCI, Buildkite, Jenkins) wire the same Node entry point per the four-point mapping named below; the blueprint does not carry a per-provider configuration file for those runners at v1.0.0.
-
-Not a source-code contribution. The blueprint contributes the gate-runner contract, the per-gate report writer contract, the aggregate report writer contract, and the discipline that binds them. The project realises the Node entry point against those contracts in its own build cycle; the blueprint does not ship the entry-point source.
-
-Not a linter, formatter, or unit-test gate. The v1.0.0 required-gate set is two gates that speak to the RCF chain and its coverage. A project that wants to add a linter or a unit-test gate authors a project-level ADR superseding ADR-701 and lists the extended gate set; the runner set is a decision area, not a runtime knob.
-
-Not a merge-queue integration. A project that wants a merge queue reads the aggregate report from the queue tool of its choice; the blueprint owns the aggregate report shape and stability, not the queue tool wiring.
-
-Not a coverage-trend dashboard. A project that wants one reads the aggregate reports over time and layers the dashboard on top; the blueprint owns the per-run reports, not the trend view.
-
-Not a branch-protection or merge-policy configuration. AC-6101-2 states the property the project owes on the platform's own configuration surface (branch protection, required checks, or the equivalent), but the blueprint does not ship that configuration file.
-
-## When to reach for it
-
-Reach for the ci-pipeline blueprint when:
-
-- The project is an rcf-lite deployment with an RCF chain and a default branch merged into through pull requests.
-- The project's CI provider can run Node 24 or later on its runner (every mainstream provider can: GitHub Actions, GitLab CI, CircleCI, Buildkite, Jenkins).
-- The project wants the RCF chain and its per-AC strict coverage to be a merge-blocking property, not an author-time habit.
-- The project wants a stable per-run report artefact any downstream reader (dashboard, audit tool, merge queue) can pick up without scraping the CI provider's log surface.
-- The project wants the same command line to reproduce a CI failure on a developer's machine.
-
-## When it does not fit
-
-Do not reach for the ci-pipeline blueprint when:
-
-- The project does not use RCF (no `rcf/` tree, no `rcf define validate` invocation makes sense). A project without an RCF chain does not need this blueprint; its pipeline is a different shape entirely.
-- The project runs on a CI provider whose runners cannot execute Node 24 or later (a legacy internal Jenkins pool locked to Node 12, an embedded hardware CI). Upgrade the runner or supersede ADR-703 with a project-level ADR selecting a different runner shape.
-- The project's default branch model is trunk-based with no pull requests. The `push to default branch` half of the trigger still applies, but the pull-request half of AC-6101-1 does not; a project on trunk-based development authors a project-level ADR narrowing the trigger set.
-- The project wants a coverage-mode grace window on newly introduced ACs. Supersede ADR-702 with a project-level ADR stating the grace window and the reasoning.
-- The project wants the pipeline to include gates that are not shipped by any rcf-lite blueprint (a linter, a mutation-testing gate, a stack-specific unit-test runner). Supersede ADR-701 with a project-level ADR listing the extended set; the runner then invokes the added gates alongside the two required ones.
-
-## What a good outcome looks like
-
-A project applies the ci-pipeline blueprint on a fresh tree, realises the three TACs in project-authored FBSes, wires a CI job per the illustrative GitHub Actions workflow (or per the four-point mapping for its own provider), configures its branch protection to require the pipeline job as a merge-blocking check, and lands on a deployed pipeline where:
-
-- Every push to the default branch and every pull request into it fires the CI job automatically; the job's aggregate report at `.rcf/reports/ci/pipeline.json` records the trigger event, the timing, and the ordered gate outcomes.
-- A pull request whose head commit fails `rcf define validate` sees `validate` outcome as `failed` in the aggregate, sees the specific schema or reference issue in the per-gate report, and cannot be merged through the platform's standard merge path.
-- A pull request whose head commit passes `rcf define validate` but leaves an AC without a resolving TC sees `coverage-strict` outcome as `failed`, sees the specific `covered-unresolved` AC in the per-gate report, and cannot be merged.
-- A pull request whose head commit passes both gates sees `verdict: passed` in the aggregate, sees green on the platform's required-check surface, and can be merged.
-- A runner crash mid-suite (a killed Node child, a report write failure) produces an aggregate with `outcome: missing` for the affected gate and `verdict: failed`; the crash is not silently indistinguishable from a pass.
-- A developer reproducing a CI failure on their machine runs the same one-line invocation the CI job's step recorded and sees the same per-gate outcomes at the same report paths.
-- A downstream reader (a coverage-trend dashboard the project may add later) picks up successive aggregate reports over time without any scraping or provider-API integration.
-
-## Wiring alternate CI providers (four-point mapping)
-
-Every mainstream CI provider ships the same four ingredients under a different runner language. The blueprint's Node entry point is the fourth ingredient; the other three are provider-specific. The illustrative GitHub Actions workflow shows all four; alternate providers translate the first three and keep the fourth unchanged:
-
-1. Job trigger. GitHub Actions uses `on: push` and `on: pull_request` YAML; GitLab CI uses `rules:` with `if:` predicates on `$CI_COMMIT_BRANCH` and `$CI_MERGE_REQUEST_TARGET_BRANCH_NAME`; CircleCI uses `workflows:` with `filters:` on branches; Buildkite uses pipeline conditions on the branch name; Jenkins declarative pipelines use `when { branch }` blocks.
-2. Node setup. GitHub Actions uses `actions/setup-node@vX`; GitLab CI images typically pre-install Node or use a Docker image; CircleCI uses `cimg/node` orbs; Buildkite installs Node in the queue's setup hook; Jenkins agents install Node through a tool config.
-3. Package-manager setup and install. Whichever manager the project uses (pnpm, npm, yarn, bun); the same `install --frozen-lockfile` (or equivalent) pattern applies everywhere.
-4. Node entry-point invocation and artefact upload. `node <path>` (or a package-manager script that resolves to the same); every provider ships an artefact-upload primitive that reads the configured report directory.
-
-The blueprint does not ship provider-specific configuration files for GitLab CI, CircleCI, Buildkite, or Jenkins at v1.0.0. A project on one of those providers hand-authors the trigger, setup, install, and artefact-upload steps in that provider's runner language and invokes the Node entry point unchanged.
-
-## Operator decisions that remain open after apply
-
-- Report directory path (default `.rcf/reports/ci/`; a project that wants a different location changes the configuration input to the runner). Blueprint owns the schema and the file names; project owns the path.
-- Gate set beyond the two required ones. Blueprint owns the required set (`validate` then `coverage-strict`); project supersedes ADR-701 with a project-level ADR to add gates.
-- Coverage-mode posture. Blueprint owns strict per-AC as the required posture; project supersedes ADR-702 with a project-level ADR if a different posture (shallow-any, grace-window) is thoughtfully accepted.
-- CI provider choice. Blueprint owns the Node entry-point shape and one illustrative provider example; project picks the provider and wires the trigger, setup, install, and artefact-upload steps.
-- Branch protection and merge-policy configuration on the default branch. Blueprint states the property (AC-6101-2); project configures the platform surface.
-- Artefact upload retention and destination. Blueprint owns the report directory and its stable paths; project owns how long the CI provider keeps the artefact and where a downstream reader picks it up.
-- Merge-queue integration, if any. Blueprint owns the aggregate report as the single-record verdict; project wires the merge-queue tool to read it.
-- Coverage-trend dashboard or audit-log integration, if any. Blueprint owns the aggregate schema stability; project owns the reader.
-
-## Cost-honesty paragraph
-
-Shipping this doc set costs the project the following. Every push and every pull request into the default branch runs both gates every time; on a small tree that is seconds, on a large tree with a deep chain it can be tens of seconds of pipeline wall time per run. The strict-coverage posture makes every new AC a two-file edit (author the AC and author the TC that resolves it); a project that skips the TC hits the strict-coverage gate on the pull request rather than at merge time. Adding a gate is a project-level ADR and a code change to the entry-point runner, not a knob-flip in a config file, which is the intended shape but does cost the ADR. The illustrative GitHub Actions workflow is a starting point; a project on another provider owes the translation of the first three of the four mapping points. Branch-protection configuration is not shipped by the blueprint; a project that forgets to configure it satisfies every AC on the doc set and still ships a pipeline that does not block merges. The report directory grows one per-gate file per gate per run; a project that runs the pipeline against a very short-lived branch may accumulate reports until the CI provider's artefact retention rolls them off. The atomic-write posture for report files costs one extra file-system syscall per report; the 256KB truncation cap on stdout and stderr costs the tail of a very verbose gate on runaway output.

package/rcf/.identity/profile.md

@@ -1,37 +0,0 @@
-# Operator profile
-
-This file describes you (the operator) to any agent working on this
-repo. It lives in `rcf/.identity/` and is gitignored by default, so
-it is per-clone: another developer's clone of the same repo has their
-own profile, not yours.
-
-Fill in what is useful. Leave the rest. Freeform prose is fine; a
-bulleted list is fine. Nothing here is enforced by tooling.
-
-## Name
-
-_(who you are; how you want the agent to address you)_
-
-## Role
-
-_(what you do; what perspective you bring to this project)_
-
-## Working preferences
-
-_(how you like to work: casual or formal register, verbose or terse
-responses, willingness to be pushed back on, anything the agent should
-know before choosing its default posture)_
-
-## Project-scoped notes
-
-_(anything specific to this project that would be useful for the agent
-to know but does not belong in the shared requirements tree: a local
-dev workflow quirk, an in-flight side-experiment, a "do not touch this
-directory yet" flag)_
-
----
-
-If you want to share your profile with the team, remove the
-`rcf/.identity/` line from the managed block in `.gitignore` (or `git
-add -f rcf/.identity/profile.md` for one-off sharing). The default is
-per-clone. Sharing is deliberate.

package/rcf/knowledge/INDEX.md

@@ -1,12 +0,0 @@
-# Knowledge index
-
-The human table of contents for `rcf/knowledge/`. Add a bullet when you
-add a file. Keep it grouped by area if it grows.
-
-## Notes
-
-_(none yet)_
-
-## Docs
-
-_(none yet)_

package/rcf/knowledge/README.md

@@ -1,41 +0,0 @@
-# Knowledge
-
-This directory is the project's memory. Everything an agent working on
-this repo should not have to relearn from scratch belongs here.
-
-## The convention
-
-- **`notes/`**: internal facts. Decisions, gotchas, runtime facts,
-  the small things that always cost time to rediscover ("the CI matrix
-  uses Node 22 not 24", "the pnpm store path on this machine is
-  non-default", "the local Postgres is on port 5433 not 5432"). Written
-  for future agents and future you, not for public readers.
-- **`docs/`**: user-facing prose the project might surface elsewhere.
-  Design notes the operator wants tidy, sections that might land in a
-  README or a spec, prose intended for a wider audience.
-
-## The rules
-
-1. **One topic per file.** The filename is the topic
-   (`notes/ci-node-version.md`, not `notes/general.md`). One paragraph
-   is enough. An empty file that only carries a pointer to somewhere
-   else is fine. A file called `misc.md` or `general.md` is not.
-2. **Write on learn.** If this session established a fact the next
-   session should not have to rediscover, write it here before the
-   session ends.
-3. **Grep before asking.** Before asking the stakeholder a question,
-   `rg -n '<topic>' rcf/knowledge/` to see whether the answer is
-   already here.
-
-## `INDEX.md`
-
-`INDEX.md` is a human table of contents. Add a bullet when you add a
-file. Keep it grouped by area if it grows. Nobody scans it
-programmatically in v1; it is for the person landing on the repo cold.
-
-## What this is not
-
-This is not a knowledge graph. There is no CLI verb, no indexer, no
-vector search. If a project needs one, that is a v2 decision, not a v1
-default. The convention above is deliberately cheap. The value is in
-the discipline of using it.