# Claims review — 0.2.32

- base: v0.2.31
- head: 4614ed4
- surface: sha256:a07a8a6e91f86dc4c34a343a4d76cb9213ccb509b9b4db578e6abf5890e97291
- verdict: pass
- reviewer: Claude, reading on the maintainer's instruction — an assistant read, not an independent human one

The surface hash is unchanged from 0.2.31: none of the seventeen listed documents
was touched. Everything claimed in this release is claimed somewhere the list does
not look, which is the finding below.

`CHANGELOG.md` gained four entries and is deliberately not a claim surface — it
records what happened rather than promising what the product does. It was three
versions behind the package, which is its own kind of dishonesty in a file that
ships in the tarball, and that is repaired here.

## Findings

### 1. src/server.ts — the tool descriptions are a claim surface with no reader

- Claim: not one sentence but a location. The four MCP tool descriptions ship in
  the tarball, are handed to the model on every session, and this release
  rewrote all of them to make behavioural promises: what is read-only, what the
  output looks like, what the policy has already done to it.
- Mechanism: the `SURFACES` list in `test/denetci.mjs`, which decides what a
  release reviewer is shown.
- Why it falls short: `src/server.ts` is not on that list and cannot usefully be
  added — it is a code file, and listing it would put every unrelated diff in
  front of the reviewer until the reviewer stops reading. So the most-read text
  in the package, the text an agent actually acts on, went past the gate
  unexamined. This review caught the two findings below only because the same
  person happened to write them.
- Disposition: accepted, not fixed here. The repair is to derive the descriptions
  from one file that can be listed, which is a change to how the server is
  assembled and does not belong in a release about wording.

### 2. src/server.ts — "Every call is recorded in a signed receipt"

- Claim: `"Every call is recorded in a signed receipt."` — written into all four
  tool descriptions in this release's first draft.
- Mechanism: `AuditLog` in `src/audit.ts`, whose receipt chain is guarded by
  `receiptSink`.
- Why it falls short: receipts are opt-in. `src/audit.ts:291` states it plainly —
  *"Makbuz zinciri durumu — opt-in (receiptSink verilirse aktif)"* — and
  `src/audit.ts:415` returns early when no sink is set. With no `receiptSink` in
  the config there is no receipt at all, so "every call" describes a
  configuration rather than the product. What *is* unconditional is the ledger
  entry; and where a sink is configured the signature is guaranteed, because the
  server refuses to start with a sink and no Ed25519 key.
- Disposition: reworded before commit. The descriptions now say the call is
  written to the audit ledger, and to a signed receipt as well when a receipt
  sink is configured.

### 3. src/server.ts — "Scopes outside the policy are skipped rather than searched"

- Claim: `"Scopes outside the policy are skipped rather than searched."` — first
  draft of the `search` description.
- Mechanism: the `search` branch in `src/server.ts`.
- Why it falls short: I could not find the skip. The branch records a denial and
  raises, which reads as a refused call rather than a narrowed one, and "skipped"
  asserts a specific behaviour a caller would plan around — silently getting
  fewer scopes is a different contract from being refused.
- Disposition: reworded before commit to what the code does establish: the policy
  decides which scopes are searchable at all.

Two of the three findings are sentences written in this release and corrected
before it left. That is the gate working in the only way it can here, and also
the reason finding 1 matters: nothing structural would have caught them.