# Claims review — 0.2.33 - base: v0.2.32 - head: b8756f3 - surface: sha256:8eeabf25cea27362e070789c61c828eea291bd3c155362f098894d868f0f9b4b - verdict: pass - reviewer: Claude, reading on the maintainer's instruction — an assistant read, not an independent human one One surface changed and one surface was added: `docs/security/NPM-PROVENANCE.md` is rewritten and listed. Eighteen documents are now read at release time. This release exists because of an external review of the repository, which flagged the provenance page as stale. Reading it confirmed two defects that are worse than staleness, and both are recorded below as findings rather than as housekeeping — a reader who followed that page would have drawn a false conclusion about whether this package can be trusted. ## Findings ### 1. docs/security/NPM-PROVENANCE.md:6 — the page denied a fact about itself - Claim: `"This is **not** a published release."`, followed by a verification section headed `"How to verify (after a provenance-backed release exists)"` and a setup section headed `"One-time setup before the first publish"`. - Mechanism: the npm registry, which records what was actually published. - Why it falls short: measured on 0.2.32 — `npm view @conarium-ai/core@0.2.32 dist --json` returns an `attestations` block naming `https://slsa.dev/provenance/v1` plus a registry `signatures` entry, and eight versions have shipped since the sentence was written. The page described a pre-release state inside a released package, and it ships in the tarball, so the reader most likely to open it is someone who already has the published artefact in their hands. - Disposition: rewritten. The page now states what exists, and the verification section carries the measured output rather than a promise that something will one day be verifiable. ### 2. docs/security/NPM-PROVENANCE.md — the verification command cannot succeed - Claim: `"or, with GitHub CLI, verify the attestation against this repo: gh attestation verify --owner dogrucanemek-alt "` - Mechanism: `gh attestation verify` reads GitHub's own attestation store, which is populated by `actions/attest-build-provenance`. - Why it falls short: `npm publish --provenance` writes to the npm registry and the public transparency log, not to GitHub's store. Both forms were run against the published 0.2.32 tarball and both answered **HTTP 404** — `--owner dogrucanemek-alt` (which additionally targets an org endpoint for what is a user account) and `--repo dogrucanemek-alt/conarium`. The failure mode is the dangerous direction: a reader checking our provenance would see 404 and reasonably conclude the attestation is missing, when it exists and verifies by another route. - Disposition: replaced with two commands that were run and do work — `npm view … dist --json` and `npm audit signatures` (107 registry signatures and 11 attestations verified on a clean install, exit 0). The `gh` command is kept in the page as an explicit warning, with the reason, so the next person who tries it does not repeat the diagnosis. ### 3. test/denetci.mjs — the page was never on the claim surface list - Claim: not a sentence — the absence of a reader. The page ships in the tarball and its whole subject is how much of what we say can be checked without us. - Mechanism: the `SURFACES` list in `test/denetci.mjs`. - Why it falls short: it was unlisted, so both defects above survived eight releases and were found by someone outside this process rather than by the gate. This is the third instance of the same shape — `docs/PRICING.md` in 0.2.31, the tool descriptions in 0.2.32, and now this — which is enough of a pattern to state plainly: the list is hand-written, and things that ship keep arriving outside it. - Disposition: listed. The structural repair suggested by 0.2.32 — deriving reviewable surfaces rather than maintaining a list — is still not done, and this finding is the argument for doing it. Nothing else on the claim surface moved: the surface hash covers eighteen documents and only this one differs from 0.2.32.