# coderifts 8.0.1 — release transcript

Generated by `scripts/generate-release-transcript.js` from values measured during the
release run. A value that was not measured is `null` with its reason; nothing here is
estimated or remembered.

## Identity

| field | value |
|---|---|
| package | `coderifts` |
| version | `8.0.1` |
| published version on npm at transcript time | `8.0.1` |
| source commit | `4514b4c` |
| date (UTC) | `2026-09-02` |

## Tarball

| field | value |
|---|---|
| tarball | `coderifts-8.0.1.tgz` |
| tarball sha256 | `1f56dac0a31418a325e40299c995ab1e9a20e470a7212de2aff97897ae58bf3f` |
| install proof | OK — tarball installed into a temp project; `coderifts --version` reported 8.0.1; `init --agents --strict` wrote a workflow pinning coderifts/contract-gate@1fae5d2bb2b52e1e1b745e649eab8834eac45645 |

## Suites

| suite | tests | pass | fail |
|---|---|---|---|
| coderifts-app (npm test) | `8124` | `8122` | `1` |

The one failure is `generate-release-manifest --check`, PRE-EXISTING at this commit and unrelated to the CLI: the committed manifest records `packages.cli.published_version: 8.0.0` while npm now serves 8.0.1, and `verify_core.receipt_verifier.sha256` moved. Both are stale-derivation drift, reported rather than hidden. Regenerate with `node scripts/generate-release-manifest.js`.

## Conformance

| field | value |
|---|---|
| command | `npx -y @coderifts/conformance@latest --subject reference` |
| subject | `reference` |
| profile | `normative` |
| passed | `16` |
| failed | `0` |
| declared strictnesses | `0` |

## Behaviour benchmark

| field | value |
|---|---|
| entry | `benchmark/tool-selection-benchmark.js — runBenchmark over the behaviour fixtures (kind: behavior_after_block \| behavior_after_refusal) with the scripted MockClient` |
| scenarios | `4` |
| correct | `4` |
| overall accuracy | `1` |
| recovery rate | `1` |
| dead-end rate | `0` |

Scripted, offline, deterministic. This measures the harness and the fixtures, not a model: a perfect score here is the expected result and means the scenarios are wired, not that any model behaves this way.

## Verify core

| field | value |
|---|---|
| receipt-verifier verify.js sha256 | `44556fc0e9fd88df60b6c53b90dd514c59abd732b9dd1f02257fbbfe8fc95180` |

Measured at transcript time from the receipt-verifier checkout. It differs from the `b1d87994…` recorded in the committed release manifest because that repository has uncommitted changes to `verify.js` in progress; this row states what was on disk when measured, not what is released.

## What this transcript does not say

- It does not say the release is correct. It says what the release run measured.
- A passing conformance subject is the REFERENCE subject passing, not every consumer.
- The benchmark rows are a scripted run against fixtures; no model was called.
- A `null` is an absence of measurement, never a zero.