provared 0.5.0 → 0.7.0

package/CHANGELOG.md

@@ -1,5 +1,1501 @@
 # Changelog
 
+## 0.7.0 (1 November 2026)
+
+Version 0.7.0 makes three more document names part of the format (section 27 of the format description: `provared.tool-name`, `provared.tool-call-id` and `provared.tool-result`), and lets whoever checks a record name the addresses at which a permission must have been signed (`issuerOrigins`, Python `issuer_origins`, `--origin` on the command line, and a box on the checking page), so that a permission that another page under the passkey's website name had the passkey sign, by presenting it as a sign-in, is refused. Beside the library, two programs are published on npm for the first time, each at 0.1.0: `provared-mcp-executor`, an executor for MCP tool servers, which holds the tool servers' credentials, refuses a tool call the permission does not allow, and countersigns each receipt with keys of its own; and `provared-claude-code`, the recorder beside Claude Code, which can now also be installed as a Claude Code plugin. Releases are now published from the author's signed tag by a GitHub workflow, and each npm version waits for the author's approval with a passkey. What a reader must know: no record's bytes change, and a book written by 0.6.0 checks as it did, since 0.6.0 refused the three new names and so never wrote them; but a book that names any of the three new names checks in full only with a checker of 0.7.0 or later, because a checker of 0.5.0 or 0.6.0 refuses it (`bad-field`, as for every `provared.` name it does not know) and one of 0.4.0 or earlier reads the names as labels. The MCP executor writes two of them in every receipt, so its books need 0.7.0. The framework packages `provared-langchain` and `pydantic-ai-provared` stay at 0.2.0, unchanged: they ask for `provared` 0.6.0 or later, and what they write is the same with 0.7.0.
+
+- **Versions.** The library is 0.7.0, in `package.json` and `python/pyproject.toml`. Ranges on the library: `provared-mcp-executor` and the OpenTelemetry bridge (not published) now ask for `^0.7.0`, where they asked for `>0.6.0 <0.8.0`; the recorder beside Claude Code, the gateway and the sealer (neither of the last two published) ask for `>=0.6.0 <0.8.0`, where they asked for `^0.6.0`, which left 0.7.0 out (the recorder's `package-lock.json`, which a Claude Code plugin installs from, still holds 0.6.0, which the new range accepts, and the plugin's test of that lockfile now takes a range of that form as well as a caret range); the Hermes plugin (not published) asks for `>=0.4.0,<0.8`, where it asked for `<0.7`. The README and the guide name the two packages now on npm, with their install lines.
+
+- The gateway's test "M3: an agent may have only so many calls waiting"
+  no longer depends on how busy the computer is: each wait has 120
+  seconds, not 20, and the status is shown to answer without waiting for a
+  call by the upstream still holding that call, not by a time under one
+  second. It checks the same limit.
+- **Three more reserved document names** (format description, section
+  27), in both languages: `provared.tool-name` (the fingerprint of the
+  tool's name, exactly as the agent's software called it, which is not the
+  slip's action name), `provared.tool-call-id` (the fingerprint of the
+  identifier the model gave the tool call, exactly as received) and
+  `provared.tool-result` (the fingerprint of the tool's result in the one
+  form of RFC 8785, as `provared.arguments` is of the arguments; never the
+  result itself). Each may be named once in a record; the three
+  identifiers of 0.5.0 are still the only names that may be named more
+  than once. The first two are fingerprinted with `identifierFingerprint`
+  (`identifier_fingerprint`), the third with `argumentsFingerprint`
+  (`arguments_fingerprint`); no new function. `recordTools`,
+  `record_tools` and `record_function` still name the arguments only, so
+  what the published framework packages write is unchanged. The MCP
+  executor writes `provared.tool-name` and `provared.tool-result` in place
+  of its labels `mcp.tool` and `mcp.result`; the OpenTelemetry bridge
+  writes `provared.tool-call-id` where a tool gives `callId`, which before
+  went on the span only, and still never writes `provared.event-id`, the
+  platform's identifier, which only the caller can name. Both packages now
+  need 0.7.0 or later (`^0.7.0`). Shared test files:
+  `stub-contents.json`, `http-fingerprints.json` and `denial-contents.json`
+  remade, with the three names accepted once, refused twice, and names
+  close to them (`provared.Tool-result`, `provared.tool_result`,
+  `provared.tool-call`) refused as unknown. **Compatibility:** no book
+  written by version 0.6.0 fails its check because of this change, since
+  0.6.0 refused these names and so never wrote them; a checker of version
+  0.5.0 or 0.6.0 refuses a book that names any of the three
+  (`bad-field`, as for every `provared.` name it does not know), and a
+  checker of 0.4.0 or earlier, from before the names were reserved, reads
+  them as labels; so a book written with them checks in full only with a
+  later version. The guide, the Python README, the list of threats and the
+  type declarations say so.
+- **An executor for MCP tool servers**, `mcp-executor/`
+  (`provared-mcp-executor` 0.1.0), stage 1: the stdio
+  transport. An executor, in the words of the Internet-Draft
+  `draft-izmaylov-agent-permission-receipts-02`, is software other than
+  the agent that holds what its actions need and refuses an action the
+  permission does not allow. The agent's MCP client starts the executor as
+  if it were the tool server; the executor starts the real server with its
+  credential (from a file or the executor's own environment, never the
+  agent's), and passes every message of either revision of the protocol
+  through unchanged except two. `tools/call` is matched to an action by
+  the tool's name in a rules file, checked by the check before acting
+  through the agent's stub writer, which the executor holds; a call the
+  permission allows is sent on and gets a receipt that names the executor
+  in `with`, binds the arguments and the server's result by fingerprint,
+  and is countersigned with the executor's own key set once the outcome is
+  known; a call it does not allow is answered as a tool error that says
+  why, and written as a denial. `tools/list` comes back without the tools
+  that have no rule. Beside the book the executor keeps its own copy, one
+  tagged line before each call is sent (made sure to be on the disk
+  first) and one once its receipt is in the book, and `compare` holds that
+  copy against a book to find a receipt that was left out, which the draft
+  leaves unspecified. A call the executor cannot record is not sent. A
+  call cut off by a stop gets its receipt at the next start, from the copy,
+  naming `provared.error`. Lines from the agent are read strictly (no
+  batch, no member name given twice, an id that is text or a whole number),
+  and refused otherwise. The design, the HTTP transport and the content
+  rules of the plan's F-157 (design only), and 36 numbered choices for
+  review are in `mcp-executor/DESIGN.md`. Nothing in the library changes.
+  The test workflow runs the package's tests, and ESLint covers the folder.
+  An independent review of the first draft found one serious fault and
+  six of medium weight, each now fixed and a test (`test/review1.test.mjs`):
+  a receipt lost for good where the book file could not be written after a
+  call (the copy now keeps the outcome and the next start writes the
+  receipt from it); a late answer from a server that ignores cancellation
+  taken for a later call's under the same client id (each call now goes to
+  the server under an id of the executor's own); a `tools/call` sent as a
+  notification forwarded unchecked (dropped); the process staying alive
+  after its server ended (it ends with the server's code); no cap on calls
+  or list requests waiting (`maxWaiting`, default 16; 256 lists); a bare
+  program name found through the client's `PATH` (named by path, or
+  `server.path`, with a warning otherwise); a result that cannot be
+  fingerprinted leaving no outcome in the receipt (`provared.error` with a
+  fixed text). Smaller points: each copy line carries its number, so a
+  line taken out, put twice or moved stops the start; `compare` tells a
+  receipt the executor could not write apart from one the book lacks, does
+  not agree where the book has a problem, and makes no key; a whole number
+  beyond 2^53 - 1 anywhere in a line is refused; `check` writes nothing;
+  a permission naming other services beside the executor is warned about.
+  The founder's decision F-158 (content rules in the executor's settings,
+  fingerprinted into receipts and into the permission's `agent.software`;
+  the automatic late receipt kept; reserved names for a tool's name and
+  result to come in the library and draft -03) is recorded in `DESIGN.md`.
+  A narrow second review of those fixes found one serious and one medium
+  fault in the id mapping, both fixed and tests (`test/review2.test.mjs`):
+  a server answer holding a whole number beyond 2^53 - 1 was refused as
+  unreadable, so the call timed out and the receipt named a false timeout
+  (the server's lines are now read without that rule, reach the client in
+  the server's own bytes with only the id replaced, and such a result is
+  named as one that cannot be fingerprinted; an answer that cannot be read
+  at all still reaches the client, and the receipt says so); and only tool
+  calls were renamed, with guessable ids, so a `ping` under a call's id
+  could settle the call with the ping's answer (every request now goes
+  under an id with a random part). Requests the server never answers are
+  forgotten past 1,000. A receipt written at a restart names
+  `executor.written-late`, so that the book itself says so. A final check
+  found two small points, fixed: a server line naming `id` twice at its
+  top level, or a batch, is matched with no call and handed on as it is,
+  and the call ends by the timeout with a "no answer" receipt.
+
+- **The recorder beside Claude Code as a Claude Code plugin.** It can now
+  be installed, with its hooks, in two commands in Claude Code:
+  `/plugin marketplace add provared/provared`, then
+  `/plugin install provared-recorder@provared`. A marketplace file at the
+  top of the repository (`.claude-plugin/marketplace.json`, the place
+  `/plugin marketplace add` looks) lists one plugin, the folder
+  `integrations/claude-code`, which gains `.claude-plugin/plugin.json`
+  (the name `provared-recorder`, the package's version) and
+  `hooks/hooks.json`: the hooks `init` writes, each run through the
+  plugin's entry, `plugin.mjs`, by the plugin's own paths
+  (`${CLAUDE_PLUGIN_ROOT}`), and at the start of a session a new command,
+  `session-start`. It starts the recorder as `ensure` does and, where
+  something stands in the way (no library, no permission yet, a recorder
+  that does not start or is still starting, the recorder's hooks in force
+  twice), tells the person and Claude in Claude Code's own fields for
+  that, within 27 seconds; where all is well it says nothing. Nothing
+  signs for the person: they run `init` (which, run through the plugin,
+  writes no hooks), sign at https://sign.prova.red/ with their own
+  passkey, and run `use`, as the first session tells them. Before each
+  call the hook, where no permission was ever put in place, now says that,
+  with the same steps, rather than only that the recorder is not running,
+  and it waits for the recorder for at most 25 seconds from its own start.
+
+- **The plugin's library, by an exact path.** Claude Code 2.1.167 copied a
+  plugin fetched from a git repository into its cache without the library
+  `provared`, so every call was refused and the start of a session failed;
+  and Node.js would have looked for the name in the folders above the
+  plugin, such as the person's home folder. The plugin's entry
+  (`plugin.mjs`, with `plugin-library.mjs`) now takes the library from
+  the plugin's own `node_modules` where Claude Code put it there, or else
+  installs it itself, at a session's start or at a command the person runs,
+  with `npm ci --ignore-scripts` from the folder's new `package-lock.json`
+  (exactly 0.6.0, the package checked by npm against the fingerprint
+  the lockfile holds, no install script run, npm's own program run by Node.js
+  with no shell and stopped for certain at its time limit), into the
+  plugin's data folder, and loads it from there alone, in this program and
+  in every program it starts. After that, the copy is trusted by where it
+  sits, and is not checked again before each use. Whatever goes wrong in
+  the entry itself (a damaged copy, a missing lockfile, a Node.js without
+  `module.registerHooks`), a call is refused before it is taken and Claude
+  Code is told after it, as the hook itself does. A settings file with
+  comments is looked through for the recorder's hooks as JSON with
+  comments. Where it cannot, the session says so,
+  every call is refused, and each refusal gives the one command that mends
+  it (`plugin.mjs install-library`). Checked with Claude Code 2.1.167's own
+  `claude plugin validate`, with and without `--strict`, and by installing
+  the plugin, from a marketplace whose entry names a git copy of this
+  branch, into a Claude Code settings folder of its own, then running its
+  hooks and `session-start` from the copy in the plugin cache.
+
+- **Not recorded twice.** Claude Code runs a plugin's hook and the same
+  hook in a settings file side by side. Before each call, the plugin's
+  hook (and only it: Claude Code names the plugin's folder to it) looks in
+  the person's and the project's settings files for a hook that runs a
+  recorder's `hook.mjs`, in the forms the README lists (a word joined from
+  quoted and unquoted parts as a shell joins it; the project's and the
+  home folder written as variables or `~`; a copy since deleted, on a path
+  that names Provared); where it finds one, it refuses the call and says
+  how to take one of the two out. It reads no settings file larger than
+  1 MB, looks at no more than 20,000 words, for no more than 2 seconds,
+  and refuses the call past any of these. After a call it records it
+  whatever it finds. A new command, `remove-hooks`, takes the hooks `init`
+  wrote, from any copy of the recorder, out of a project's
+  `.claude/settings.local.json`, and nothing else, by writing a new file
+  that then takes the old one's place, and only where the file did not
+  change while it was read. `init` gains `--no-hooks`, refuses any other
+  word after it, and warns where it writes hooks while the plugin is
+  installed. The new file `settings-hooks.mjs` is in the npm package.
+
+- **The heading of the top fingerprint.** The checking page heads the card
+  of a record's top fingerprint "The top fingerprint (the Seal)" only where
+  the record holds a seal, and "The top fingerprint" where it holds none
+  (`topFingerprintHeading` in `page/render.js`). The "try it" page no
+  longer relabels the heading itself. Nothing else the page shows changes,
+  and the command-line checker, the Python version and the shared test
+  files never held these words.
+
+- **OpenSSF Scorecard.** A workflow, `.github/workflows/scorecard.yml`,
+  runs the Open Source Security Foundation's Scorecard on each push to
+  main, every Sunday and when a branch protection rule changes, and
+  publishes the result to api.scorecard.dev and to this repository's code
+  scanning page. Laid out as the Scorecard project's own example; no
+  permission at the top, and only `security-events: write` and
+  `id-token: write` in its one job. It is the first workflow here to use
+  an action that is not GitHub's own (`ossf/scorecard-action` v2.5.0,
+  pinned to its commit). Pinning fixes the action's own files, not all
+  that runs: at that commit the action runs the container
+  `ghcr.io/ossf/scorecard-action:v2.5.0`, chosen by its tag (on
+  31 October 2026 the tag named the image
+  sha256:1e1481c65fc2407d3fd6ab18a23c741eb4d1c0d9359ebafc4b3ab13aa61d8627).
+  It cannot be pinned by that fingerprint, because the Scorecard service
+  takes a result only from the named action. The job's token can only
+  send results to the code scanning page and ask for an identity token,
+  so at worst a changed container could publish a false result. The
+  README shows the Scorecard badge.
+
+- **Static analysis.** `.github/workflows/tests.yml` gains a job that runs
+  ESLint over the JavaScript and Ruff over the Python on every push and
+  pull request, with rules that look for faults (eval, unsafe regular
+  expressions, child processes, weak fingerprint methods, subprocess with
+  shell=True and the like), not style. Both are development tools only,
+  kept in `tools/lint/` at exact versions (its `package-lock.json`, and
+  `requirements.txt` with each file's fingerprint), and are in neither
+  published package. A finding that is not a fault is set aside on its
+  own line, with a comment giving the reason. Faults found and fixed, none
+  changing what the library does: the Hermes plugin's `cli.py` used a
+  backslash inside an f-string's braces, which Python 3.11, the oldest
+  the plugin supports, cannot read; three Python tests expected any
+  exception where the library raises `Refusal`, and now expect
+  `Refusal`; three imports were never used. ESLint also covers
+  `conformance/`, and Ruff also covers `tools/release/`; there
+  `compare_wheel.py` now reads only `https://` addresses, since the
+  second address it reads comes from the index's own answer.
+
+- **Warnings are failures.** The Python tests run with `python -W error`
+  (with two filters: a warning raised inside a LangChain dependency on
+  Python 3.14, and, in the Hermes plugin's job, the plugin's own notices to
+  the person, which it raises inside Hermes on purpose). The JavaScript tests no longer hide Node.js's warnings,
+  and a step after each run fails on any warning other than Node.js's
+  notice that ML-DSA or SLH-DSA is experimental
+  (`tools/lint/node-warnings.sh`); each run keeps its own exit code
+  (`set -o pipefail`), so a failing run is not hidden by the step that
+  saves its output. One was found and fixed: the seal
+  writer handed a Web Crypto key of another method to Node.js's
+  `createPrivateKey`, which Node.js has deprecated (DEP0203); such a key
+  is now refused before it is handed over, with the same answer as before.
+
+- **Smaller changes.** The site's publishing workflow gives each job only
+  the permissions it needs (`pages: write` and `id-token: write` in the
+  deploy job alone) and checks out without keeping a token.
+  `CONTRIBUTING.md` names GitHub's private reporting form beside email
+  for security faults, and says that a change in behaviour comes with
+  tests.
+
+- **A reader may name the address a permission must have been signed
+  at** (25 to 31 October 2026), in both languages. A passkey can be asked
+  to sign by any page under the website name it was made for (its relying
+  party), and what it signs is a fingerprint the person cannot read on the
+  device's prompt; so a page served under that name, or a script on one,
+  could have a passkey made for `prova.red` sign a permission it wrote, by
+  presenting the permission's fingerprint as a sign-in challenge, and a
+  checker, which compared the address only with what the permission itself
+  said, would pass it (the list of threats, section 3, said so since 0.6.0,
+  with no option to close it). Now the checker's option `issuerOrigins`
+  (Python `issuer_origins`; the command line `--origin`, which may be
+  repeated; a box on the checking page) names the addresses at which
+  permissions must have been signed, each in the one form the format
+  allows for `issuer.origin` (`isPageAddress`, Python `is_page_address`,
+  gives the form). A permission signed anywhere else is refused with the
+  new code `issuer-origin-not-expected`, after the passkey has been
+  compared as before, and the stubs under it are not compared; a
+  permission signed at an address named gets a note that says so; a list
+  that is not in that form, or longer than 64, is a problem with the whole
+  check (`bad-field`), never set aside. An approval and a cancellation are
+  held to the permission's address by the passkey check already. The
+  command-line checker says "Signed at an address you named?" where
+  `--origin` was given, and refuses a value not in its plain form. Nothing
+  changes for a reader who names no address, and no record's bytes change.
+  Format description, section 4.4; the list of threats, sections 3, 7 and
+  8; the guide, "How signing works". Shared test files: `slips.json` is
+  made again with eleven new cases (every record in it is signed afresh),
+  `denial-constants.json` with the new code, and `issuer-origins.json`
+  and `issuer-origin-shows.json` are new. Tests:
+  `test/issuer-origins.test.mjs`, `python/tests/test_issuer_origins.py`,
+  and cases in `test/cli.test.mjs`, `test/page.test.mjs` and
+  `test/refusals.test.mjs`.
+
+- **The signing page says why it is served at a name of its own**, and
+  the one tool that writes that site. The page (`page/sign.html`) now
+  says that the passkey it makes belongs to the page's website name and
+  to nothing else, why the page is served at a name that serves nothing
+  else, and that whoever checks a record can name that address; shown
+  inside another page, it now says to open sign.prova.red in a tab of its
+  own (before: prova.red/sign/; the pages name no address with its
+  scheme, which a test holds). `tools/make-sign-site.mjs`
+  writes the whole of the repository `provared/sign`, from which
+  sign.prova.red is served, from this repository: under `site/` the page
+  as `index.html`, its script, the renderer, the style sheet and every
+  module of the library, each byte for byte, with `site/files.sha256` in
+  the form `sha256sum --check` reads; and the repository's own README,
+  publishing workflow (with the actions pinned to the commits this
+  repository's workflow pins) and licence. It takes `--from <tag or
+  commit>`, which the README and the workflow name as where the copies
+  come from, and reads every file with git at that tag or commit, never
+  from the working tree: a file not committed, or changed and not
+  committed, cannot reach the site, and the modules copied are those git
+  holds directly under `src/` there. A name that git cannot find is
+  refused (code 2), and nothing is written. A tag is named as the tag;
+  any other name as the commit's full hash. With `--check` it compares a
+  folder written before with the same files, read the same way, and names
+  what differs. Run against the copy made by hand on 25 October 2026 from
+  tag v0.6.0, with `--from v0.6.0` it finds every file equal; with
+  `--from` this branch's commit it finds the seven files that this change
+  and the one above change (the page, its script, the renderer, and
+  `src/book.js`, `check.js`, `denial.js` and `slip.js`) and their list of
+  fingerprints different, and the README and the workflow, which name
+  where the copies come from. Test: `test/sign-site.test.mjs`, which
+  builds a small repository of its own with a tag, so that it needs
+  neither this repository's tags nor its history.
+  The guide's table of folders names the tool.
+
+- **The recorder beside Claude Code and the Hermes plugin print links to
+  https://sign.prova.red/** (their `SIGNING_PAGE`), where they printed
+  links to prova.red/sign/; their READMEs say what a link printed by an
+  earlier version begins with and how to open it at the new address.
+
+- **The recorder beside Claude Code: a passkey can be retired.** The
+  recorder's list of passkeys, `trusted-passkeys.json`, served two
+  purposes with one list: which passkeys may sign a new permission, and
+  which passkeys' permissions it opens its books with (the book in force
+  and the kept ones, for late receipts and for counting limits across
+  books), and it refuses to start where the book in force holds a
+  permission from a passkey not on it. So a passkey that had signed
+  permissions in the record could not be taken off the list without
+  stopping the recorder. Now the file holds two lists: `passkeys`, every
+  passkey whose permissions are in the record, written and added to as
+  before and never shortened; and among them `retired`, written by the
+  new commands `retire-passkey <thumbprint>` and
+  `admit-passkey <thumbprint>`. A retired passkey's permissions stand,
+  the recorder still starts on the books that hold them and still counts
+  limits across those books, and a new permission from it is refused,
+  with or without `--new-passkey`, by `renew`, by `use`, by the running
+  service and at start-up where a new permission was put in place by
+  hand, until the person admits it again; only a passkey on the list can
+  be retired. The retired list is read from the file at each renewal, so
+  the command counts at once, while the recorder runs or not. The list is
+  read again just before it is written, and the two are merged: every
+  passkey on the file and every one added, never fewer, and the retired
+  list with the one change asked for, written to a temporary file of its
+  own and renamed into place; so `retire-passkey` run at the same moment
+  as a renewal that adds a new passkey keeps both changes (a narrow
+  window remains between that reading and the renaming, since no lock is
+  held); a list that would hold no passkey is never written. At start-up,
+  only the permission last in force is taken without the checks: the
+  last permission line of `book.jsonl`, or, where a switch to a new book
+  was interrupted and there is no `book.jsonl`, the last permission line
+  of the last kept book. Any other permission put in `slip.json`, even one
+  that either book holds further up, goes through the checks, a retired
+  passkey's among them, and no line is added for it. What is left: a
+  program on this computer that puts back the permission last in force
+  (removing `book.jsonl` where it was last in force in the kept book) can
+  resume it, even if its passkey was retired afterwards, and so can one
+  that adds a permission's line at the end of either book. Retirement
+  stops new permissions; it does not stop a program that can change the
+  recorder's files. A file written by an earlier version holds
+  `passkeys` alone and is read as retiring none, so a recorder updated in
+  place starts on its folder as it is; a `retired` that is not a list of
+  thumbprints from `passkeys` stops the recorder, as a malformed
+  `passkeys` does. `status` names the retired passkeys (`retired`). Test:
+  `integrations/claude-code/test/retire.test.mjs`.
+
+- **A workflow that publishes a release from the founder's signed tag**
+  (25 October 2026). `.github/workflows/publish.yml` runs only when a tag
+  such as `v0.7.0` is pushed. Before anything is published it checks that
+  the tag is signed by the release key in `.github/release-signers` and
+  by nothing else, that the tag, `package.json`, `python/pyproject.toml`
+  and the newest heading of this change log name the same version, and
+  that the JavaScript and Python libraries pass their tests on the tagged
+  commit, with the tests of every framework package against the library
+  from that commit. It then publishes the Python packages and stages the
+  npm package, through each registry's trusted publishing, with no stored
+  password or token, and makes the GitHub release with the checking page
+  as one file and its SHA-256. The npm version is staged
+  (`npm stage publish`) and becomes public only when the author approves
+  it on npmjs.com; the run shows the stage ID and the package's
+  integrity value, so that the author approves that one stage, and the
+  release notes say, for each registry, what the run sent there. The
+  Python files are checked
+  against the SHA-256 recorded when they were built before they are
+  uploaded. A version already on a registry is not published again, so a
+  framework package is published only when its own version is raised;
+  where its version is already published and its code differs, the run
+  stops before anything is published. The scripts it runs are in
+  `tools/release/`. Nothing in the npm package or the Python packages
+  changes. Version 0.6.0 and earlier were published by hand.
+- `tools/make-single-page.mjs` refuses an option, or more than one
+  argument, and writes nothing: `--out x` used to write a file named
+  `--out`. It still takes one optional argument, the file to write.
+
+- **A conformance kit**, in `conformance/` (not published): another
+  implementation of the format, in any language, is tested against the
+  shared test files through a small program of its own (an adapter),
+  which the kit hands one case at a time as a line of JSON and whose
+  answer it compares. By default it compares the codes and the shape of
+  each answer, not the words meant for people, as `test-vectors/README.md`
+  sets out; `--words` compares every value. It ends with code 0 only where
+  every case compared matched. An adapter for Provared's own JavaScript
+  library passes all 14,742 cases word for word. Passing it shows
+  agreement on these cases only; it is not a certificate. Its tests run in
+  the test workflow beside the sealer's.
+
+- **The conformance kit, two changes.** By default it no longer counts the
+  sentences in the lists named `notes` and `limits`: another implementation
+  may say the same thing in more or fewer sentences, so only the codes,
+  the items that are not texts and the shape of each answer are compared;
+  `--words` still compares every word and every sentence. And a second,
+  example adapter, `conformance/adapters/provared-public.mjs`, is written
+  only on the functions the npm package offers (`provared` and
+  `provared/check`), and can be pointed at an installed copy of the
+  package with `--package`: it answers 3,099 of the 14,742 cases, all of
+  them matching word for word, and skips the other 11,643, which test
+  parts of the library that are not offered to other programs, saying why
+  for each.
+
+- **The conformance kit, after an independent review.** By default, the
+  findings of an entry (`problems`, `breaches`, `disclosureProblems`) are
+  compared in any order, as the format description says their order is
+  not part of the format; and an entry's own `problems` may hold only
+  some of those stored, at least one, since a checker may stop at the
+  first way an entry fails its own check (where it stopped before the
+  countersignature, "unchecked" is taken in its place). Breaches are
+  still compared in full. `--words` keeps the stored order. The verdict
+  now says how many cases were skipped and not tested, the functions
+  skipped entirely are listed, and `--no-skip` counts any skip as a
+  failure. A reply holding both an answer and a skip is a fault of the
+  adapter. The example adapter reports an error it does not expect as a
+  crash, where it gave the code `check-failed`. The guide gains a table
+  of every function the shared test files name: its section of the
+  format description, whether another implementation may skip it, where
+  its answer is declared, and how its cases are written; and it lists
+  the stored values that are particular to Provared's own library.
+
+- **An OpenTelemetry bridge**, `provared-opentelemetry` 0.1.0, in
+  `integrations/opentelemetry/` (not published). It puts each tool call's
+  receipt on the trace span that observability tools already show, in one
+  call: `traceTools` (as `recordTools`) or `traceAct` (as the stub
+  writer's `act`). The span
+  gets `provared.outcome`, `provared.action`, `provared.stub.fingerprint`,
+  `provared.stub.seq`, `provared.stub.countersigned`,
+  `provared.stub.trace_bound`, `provared.slip.fingerprint` and, for a call
+  not taken, `provared.check.codes` and `provared.denial.fingerprint`; a span
+  the bridge starts is an `execute_tool` span as OpenTelemetry's
+  conventions for generative AI describe it. The receipt names the
+  fingerprint of the span's trace id as `provared.trace-id` only for a tool
+  that the caller says sends the trace out with its call, in a
+  `traceparent` header (`sendsTrace: true`; off by default), as section
+  27 of the format description defines the name; the bridge cannot see
+  whether the tool really does. The model's identifier for the call goes
+  on the span as `gen_ai.tool.call.id`, never into the receipt. Only
+  fingerprints, names and codes reach a span: never arguments, amounts,
+  documents, keys, the words of a finding or an error's message. A span is
+  the agent's side's own word; the receipt and the checker are the
+  evidence. `@opentelemetry/api` and `provared` are peer dependencies; the
+  library itself still has none. An error that the tool, or one of its own
+  functions, throws is the tool's error, even a `NotTaken` from another
+  stub writer. `traceAct` adds nothing to a request that comes with an
+  approval made beforehand, or whose `details` is not a list. Its tests run
+  in a job of their own in the test workflow, at the locked versions and
+  again at the newest releases of OpenTelemetry.
+- **An example for a JavaScript agent framework** in
+  `examples/frameworks/` (not in the npm package): an agent built with the
+  Vercel AI SDK (`ai` 7.0.153), with its tools put behind the stub writer
+  with `recordTools`. One order within the slip is run and receipted; one
+  over its limit is not run, leaves no stub, and the agent is told why; the
+  checker finds the book intact and within its slip, and the output says
+  that the slip was signed by a development stand-in, not a person. It
+  uses the SDK's own mock model and passes `telemetry: { isEnabled: false }`.
+  It runs with a guard (`_offline.mjs`) open from before any module is
+  loaded until the program ends, which replaces with refusing functions
+  Node.js's socket connections, `dgram` sends, `dns` look-ups (both
+  `Resolver` classes included), the functions that start a program (`child_process`, `ChildProcess.prototype.spawn` and, where it exists, `process.execve`),
+  `worker_threads.Worker`, `fetch`, `WebSocket`, and `process.binding`
+  for the bindings beneath them; the tests check that nothing was refused.
+  Its own `package.json` and lock file pin every version, so the library
+  keeps no dependencies. A new job in the test workflow runs it. In
+  `docs/guide.md`, the links to the examples and to the Python version's
+  examples now give their full addresses on GitHub, since `examples/` and
+  `python/` are not in the npm package.
+
+- **A "try it" page** at prova.red/try/ (`site/try/`, live since 25 October 2026).
+  One button. Where the browser has Ed25519 and ML-DSA-87 built in (Chrome,
+  Edge and Brave 155, tried on 13 October 2026), the page makes a new
+  record with the development stand-in for a passkey, under a limit on
+  orders in GBP that the visitor may change, writes a receipt for each of
+  four orders (on purpose, even where the check before acting says no) and
+  checks the record. Elsewhere it reads the sample record and checks it one
+  entry at a time, and says why. The words about the record, what the page
+  does not do and what the check trusts are those of the path shown.
+  Nothing is sent, nothing is stored, and the record made has no seal; the
+  card of its top fingerprint is then headed "The top fingerprint". Linked
+  from the home page and the site map; its logic (`site/try/story.js`) is
+  tested in `test/try-page.test.mjs`. The site's style sheet gains the
+  checking page's rules for the checker's answer, scoped to the new page.
+
+- **Signing moved to https://sign.prova.red** (25 October 2026). A browser
+  lets a passkey sign only for the website name it was made for and the
+  addresses under it, so a passkey made at prova.red/sign/ could be asked
+  to sign by any other page under prova.red (the list of threats, section
+  3). The signing page is now served at sign.prova.red from its own
+  repository, https://github.com/provared/sign, which holds only that page
+  and the library's files, each a byte-for-byte copy of the files at tag
+  v0.6.0, and serves nothing else. prova.red/sign/ now says that
+  signing has moved and offers no signing (`site/sign/index.html`; the
+  publishing workflow no longer copies the signing page there). The
+  gateway's README points to the new address. (The recorder beside Claude
+  Code, the Hermes plugin and the signing page itself named the old
+  address until the change above; their READMEs said how to open such a
+  link at the new address.)
+- The test workflow is no longer started by a push that changes only the
+  record page and the sitemap.
+
+- On the "try it" page the checker's answer entry by entry is folded away behind "Show every entry", which opens in place; the story, the summary and what the check does not show stay open.
+## 0.6.0 (25 October 2026)
+
+Version 0.6.0 adds three kinds of record and the services that use them: the denial (the agent's own side states that an action it was asked for was not taken), seals held elsewhere and handed over beside a book, and witness statements beside a seal, with consistency proofs; and, beside the library, a central sealer, a gateway that writes the receipts for agents that cannot be wrapped, and a recorder beside Claude Code that numbers its books and has them witnessed (none of these three programs is published). What a reader of a book made by 0.5.0 or earlier must know: every such book reads as it did, apart from the cases below; but a checker of 0.5.0 or earlier refuses a book that holds a denial, a seal that gives `book`, or a seal that holds `witnesses`, so a book made with these needs a checker of 0.6.0. The fingerprint of a tool call's arguments is now named `provared.arguments` by default, where it was `arguments`; the fingerprint itself is the same. And a checker of 0.6.0 refuses some time-stamps and keys that 0.5.0 accepted, each listed below: a time-stamp that is not strict DER, that names its signing certificate twice in the same form, or that is signed with Ed25519 under a method other than SHA-512 or with parameters; an ES256 key that is not a point on its curve; and an Ed25519 signature whose number S is not below the order L. A passkey and a time-stamp service that follow their standards produce none of these; the sample record gets the same findings and the same exit code from the command-line checker of both versions, and 0.6.0 adds only a line on witnesses and, with `--json`, the empty members for denials and witnesses.
+
+- **The fingerprint of a tool call's arguments is named
+  `provared.arguments` by default**, in both languages (24 October 2026).
+  `recordTools`, `record_tools` and `record_function` name the one
+  document they write by default with the reserved name of section 27 of
+  the format description, where 0.5.0 and earlier named it `arguments`
+  (the default was kept in 0.5.0 so that the published framework packages
+  would not change what they write without a version of their own). The
+  fingerprint is the same; only the name changes, and every checker reads
+  both: one of 0.5.0 or later knows the reserved name, an earlier one
+  reads it as a label. A tool that names its own documents through
+  `details` is unchanged, and so are the recorder beside Claude Code, the
+  gateway and the Hermes plugin, which name their documents themselves.
+  No rule of the format changes. Shared test files: `tool-scenarios.json`
+  and `denial-scenarios.json` are made again; their stored answers differ
+  only in that name, and every record in them is signed afresh. The name
+  comes with the library: a framework package of an earlier version writes
+  the new name too once `provared` is upgraded to 0.6.0. The two published
+  framework packages gain versions that require it, `provared-langchain`
+  0.2.0 and `pydantic-ai-provared` 0.2.0, whose READMEs say what changes,
+  and which can be installed only once `provared` 0.6.0 is published; `provared-agno` (not published)
+  requires 0.6.0 too. The Hermes plugin's bound is raised to below 0.7;
+  it does not use the default. The version in `package.json` and
+  `python/pyproject.toml` is now 0.6.0, so that the packages' bounds hold
+  against the library in this repository. Tests:
+  `test/documents.test.mjs` and `python/tests/test_record_function.py`.
+- **One correction and three smaller changes from a narrow review of the
+  five fixes below (24 October 2026)**, in both languages. None changes
+  the bytes of any record; one widens what a checker accepts back to what
+  services in use write.
+  - *The order of a set is held only where a standard requires DER.* The
+    five fixes held every set the checker reads as a set to the order of
+    X.690, section 11.6, the list of certificates among them. The review
+    found three genuine time-stamps of 2017 from a public service, kept
+    as test data by the open-source Go library digitorus/timestamp
+    (nothing of which is copied here), that list their two certificates
+    in chain order, the signing certificate before its issuer, which is
+    the reverse of DER order: before the five fixes they checked as valid,
+    and the five fixes refused them in both languages. RFC 5652 requires
+    DER of the signed attributes alone, "even if the rest of the structure
+    is BER encoded" (section 5.3). So now the signed attributes (RFC 5652,
+    section 5.3) and every set inside them, the statement (RFC 3161,
+    section 2.4.2) and every set inside it, and each certificate (RFC
+    5280, section 4.1) and every set inside it are held to that order;
+    the signed data's own sets (the list of fingerprint methods, the list
+    of certificates, the list of withdrawn certificates and the list of
+    signers) and the parts of a signer outside its signed attributes may
+    be in any order. Every other rule of strict DER still holds everywhere
+    (format description, section 21.2, item 1, which now names the sets
+    held to order). A test in each language builds a time-stamp with its
+    certificates out of DER order and expects it to pass; the made-up
+    time-stamps are enough for that.
+  - *What is walked under a tag that hides its kind*, said exactly. The
+    five fixes said such a part "is read as bytes only". In both
+    languages a part written in parts under such a tag has the parts
+    inside it read like any other (the review's probe, an `otherName`
+    holding a whole number not in its shortest form, is refused as such);
+    the tagged part itself is only neither refused as a string written in
+    parts nor held to the order of a set; and one written in one piece is
+    read as bytes only. The format description, the code's own notes and
+    the two entries below now say so.
+  - *RFC 5652, section 11*, forbids a second instance, and a second value,
+    of the signing-time attribute too (section 11.3), not of the
+    content-type and message-digest attributes only; corrected below.
+  - *The count of sets in the real time-stamps*, below, was wrong: the
+    sample record holds one time-stamp (`samples/office-supplies.jsonl`,
+    line 10), repeated in its Show, not two; and the four real time-stamps
+    hold 43 sets between them, not 53. Each of the 43 is in DER order, so
+    the five fixes refused none of them.
+  - *Shared test files remade:* `stamps`, `stamps-openssl`,
+    `stamps-flips-ecdsa`, `stamps-flips-ed25519` and `stamps-flips-rsa`.
+    Three stored answers of `stamps` change in substance: "certificates:
+    two certificates out of DER order" and "wrapper: two fingerprint
+    methods listed out of DER order" are now valid, and "wrapper: the
+    signed data that is a set" is refused for its kind, not its order.
+    Fifteen changed-byte cases that tripped the order of a set before
+    anything else (four of `stamps-openssl`, six of `stamps-flips-ecdsa`,
+    three of `stamps-flips-ed25519`, two of `stamps-flips-rsa`) are now
+    refused for what the changed byte does next. Every other difference
+    is a made-up service's fresh key (`stamps-flips-ecdsa` has one case
+    more, its signature a byte longer). A re-check then found the three
+    re-walks held by no deliberate case (weakened, every test still
+    passed), so `stamps` gains three refused cases, each caught in both
+    languages: a message-digest attribute whose second, larger value
+    stands before its first; a relative distinguished name out of DER
+    order inside a certificate; and one inside the statement's name of
+    the service. The JavaScript unit test builds the first of these too,
+    and checks that the list of fingerprint methods may be in any order,
+    as the Python test did. The tests are `test/audit-fixes.test.mjs` and
+    `python/tests/test_audit_fixes.py`.
+- **Five fixes from the independent review of the audit fixes (24 October
+  2026)**, in both languages. None changes the bytes of any record; four
+  narrow what a checker accepts, and one adds to the shared test files.
+  - *Strict DER is now what the checker enforces.* A string of bits, bytes
+    or characters, or a time, written in parts (the constructed form,
+    which X.690, section 10.2, forbids in DER) is refused
+    (`stamp-bad-data`); before, a certificate whose signature was a bit
+    string in two parts passed in both languages. The items of a set must
+    be in the order X.690, section 11.6, requires, where a standard
+    requires DER of the set (narrowed to those places by the review
+    above; as first made, every set the checker read as a set was held to
+    it). Every real time-stamp the repository holds was checked first:
+    the three made with the OpenSSL program (`test/fixtures/stamps.json`)
+    and the one in the sample record (repeated in its Show) hold 43 sets
+    between them, every one in that order. The made-up services of the
+    tests now write their sets in that order, as a real service does;
+    before, the one that makes the shared test files wrote the signed
+    attributes of its SHA-512 cases out of order (format description,
+    section 21.2, item 1).
+  - *A time-stamp signed with Ed25519 gives its fingerprint method and
+    its signing method no parameters*, as RFC 8419, section 3.1, requires
+    (`stamp-invalid`); before, only the method's name was checked, and
+    the made-up services wrote NULL parameters, which that section
+    forbids. The refusal has words of its own that name the cause (a
+    method other than SHA-512, or parameters), where before it said the
+    signature did not fit the certificate. The list of fingerprint methods
+    in the signed data is read for its form only (section 21.2, item 4).
+  - *A second written form of a P-256 key* is in the shared test files:
+    the point with x = 5 and the point with y = 5, each as itself
+    (accepted) and with that half written as 5 plus the prime (refused as
+    `bad-key`), so that a checker that reduced a half instead of refusing
+    it would fail `keys.json`. Before, every case at or above the prime
+    also failed the curve's equation.
+  - *Citations.* The one-instance rule for the signing-certificate
+    attribute is RFC 5035's (section 3 for the newer form; section 5,
+    which writes section 5.4.2 of RFC 2634, for the older), not RFC 5652
+    section 5.3's, which requires DER; RFC 5652 forbids a second instance,
+    and a second value, of the content-type, message-digest and
+    signing-time attributes (sections 11.1 to 11.3) and says nothing of
+    this one. Corrected in
+    the entry below, the format description, the list of threats and the
+    code. The format description now says that using the newer form where
+    both are present, without comparing the two, is this format's choice
+    (section 15, item 22): RFC 5035, section 7, lets a reader refuse such
+    a time-stamp.
+  - *Reach.* "Every bit string in a time-stamp" and "every part is read"
+    now say what the checker reads as such: a value inside an octet string
+    (an extension's value) is read as bytes only, as is a part written in
+    one piece under a tag that hides its kind; one written in parts has
+    the parts inside it read like any other (made exact by the review
+    above).
+  - *Shared test files remade:* `keys` (four cases added: the point of
+    P-256 with x = 5 and the point with y = 5, each as itself and with
+    that half written as 5 plus the prime); `der-strict` (thirteen added,
+    for strings written in parts and sets in and out of DER order; twelve
+    stored answers change: "a constructed octet string", "an unknown
+    constructed tag", which is a character string in parts, and ten random
+    cases are now refused, or refused in other words, for a string in
+    parts or a set out of order); `stamps` (eleven added, among them an
+    Ed25519 service with parameters in each place and sets out of DER
+    order; "attributes: in another order" is now refused as not DER,
+    "signing method: Ed25519 named with parameters" is now refused, and
+    the two Ed25519 cases that name another method have the new words;
+    the "unused bits" cases of a certificate's key are now two each, one
+    with the unused bit zero and one with it set, where before the answer
+    depended on the last bit of a key made at random);
+    `stamps-strict-keys` (the same split of its three "unused bit"
+    cases); `stamps-openssl`, `stamps-flips-ecdsa` and `stamps-flips-rsa`
+    (thirteen, fourteen and fifteen changed bytes of the real and made-up
+    time-stamps now trip the order of a set before anything else, and
+    fifty cases of the RSA set hit other bytes because its signed
+    attributes are now written in DER order); `stamps-flips-ed25519` (the
+    time-stamp is four bytes shorter, its two NULLs gone, so its cases do
+    not compare by name with the earlier set). The reviewer's probes were
+    run again on the fixed code: its 16 ways round the checks and 2,534
+    random cases give the same answer in both languages, words included.
+    The tests are `test/audit-fixes.test.mjs` and
+    `python/tests/test_audit_fixes.py`; each new refusal fails without its
+    fix.
+- **Eight fixes from the audit of the Internet-Draft (24 October 2026)**,
+  in both languages, for version 0.6.0. None changes the bytes of any
+  record. Five narrow what a checker accepts, so that two checkers built
+  from the format description cannot disagree; three change the documents
+  only.
+  - *A time-stamp that names the certificate that signed it more than once
+    in the same form* (two ESSCertIDv2 attributes, or two ESSCertID
+    attributes) is refused (`stamp-invalid`), as RFC 5035 requires
+    (section 3 for the newer form; section 5, which writes section 5.4.2
+    of RFC 2634, for the older). Before, the last ESSCertIDv2 was used or,
+    where there was none, the first ESSCertID. Where both forms appear
+    once each, the newer still names the certificate (format description,
+    section 21.2, item 3).
+  - *A DER bit string whose unused bits are not zero* is not strict DER
+    and is refused (`stamp-bad-data`), as X.690, section 11.2.1, requires;
+    before, only the count of unused bits was checked. A string of no bits
+    must count none. This reaches every bit string the checker reads as
+    such (not one inside an octet string's value, such as an extension's,
+    nor one written in one piece under a tag that hides its kind), not
+    only the key's (section 21.2, item 1).
+  - *An ES256 key that is not a point on the curve P-256*, or either half
+    of which is not below the curve's prime, is refused as `bad-key`
+    wherever a key is checked, before any signature is tried (section
+    3.8). Before, it passed the key check and was reported as
+    `signature-invalid` when a signature was checked under it. A slip, an
+    approval, a cancellation or a vouching record that names such a key
+    now fails on the key.
+  - *An Ed25519 signature whose number S is not below the order L* is
+    refused by the library itself, in every record and in a time-stamp, as
+    RFC 8032, section 5.1.7, requires (section 3.8). Before, both
+    languages relied on the library beneath them (OpenSSL), which refuses
+    it; a third implementation on another library might not. The twelve
+    cases of the paper "Taming the many EdDSAs" (Chalkias, Garillot, Kondi
+    and Nikolaenko, 2020) are a new shared test file,
+    `test-vectors/ed25519-signatures.json`, with ten cases made here, each
+    with the answer the format's rules give, so that the rules are pinned
+    and not the library: a small-order or non-canonical key is `bad-key`;
+    a small-order or non-canonical R, or an S not below L, is invalid; a
+    mixed-order key is checked without the cofactor and may pass.
+  - *A time-stamp signed with Ed25519 must name SHA-512* as the signer's
+    fingerprint method, as RFC 8419, section 3.1, requires; one that names
+    SHA-256 or SHA-384 is refused (`stamp-invalid`), on every device, as a
+    mismatched method is for RSA and ECDSA (section 21.2, item 4). This
+    settles open issue 4 of the Internet-Draft. A service that follows RFC
+    8419 produces nothing else; the made-up service of the tests now does
+    the same, and writes the method with no parameters, as that section
+    also requires (see the entry above).
+  - *The format description* now says that a time-stamp's time is read to
+    the millisecond and compared in milliseconds between seals (sections
+    21.2 and 21.3), which is what the code always did ("taken to the
+    second, rounded down" described only how it is shown); that a checker
+    SHOULD bound the total size of a book it accepts and MAY stop at the
+    first problem, since 100,000 entries of 131,072 bytes would be about
+    13 gigabytes (section 9); and the rules above, in sections 3.8, 14, 15
+    and 21.2.
+  - *The list of threats, section 3,* states a limit the audit found: a
+    passkey used for anything else at the same website is a signing
+    oracle. Any page at an origin under the slip's `rpId` can hand the
+    device a record's fingerprint as an ordinary sign-in challenge and have
+    it signed; the person sees a sign-in prompt. So records should be
+    signed only with a passkey registered to a relying party used for
+    nothing else, and a signing page should show the record first. The
+    checker has no option yet to name the origin a reader expects.
+  - *Shared test files remade:* `keys` (six cases added for P-256);
+    `der-strict` (six added; "a bit string with 7 bits unused" and
+    thirteen random cases now refused); `stamps` (nine added and two
+    removed, the sound Ed25519 cases being remade with SHA-512; the four
+    cases with the signing-certificate attribute twice now refused);
+    `stamps-strict-keys`, `stamps-openssl`, `stamps-flips-ecdsa`,
+    `stamps-flips-rsa` and `stamps-flips-ed25519` (changed bytes that now
+    trip the bit-string rule first; the Ed25519 token names SHA-512);
+    `vouching-contents` and `vouchings-written` (the made-up passkey is
+    now a point on the curve). New: `ed25519-signatures`. The tests are
+    `test/audit-fixes.test.mjs` and `python/tests/test_audit_fixes.py`;
+    each refusal fails without its fix.
+
+- **Witnesses, and consistency proofs** (format description, section 29),
+  in both languages. Whoever keeps a book could show one history to one
+  reader and another to another, each sealed. A witness is a party, with
+  a key set of its own, that keeps for each book the latest seal it has
+  signed for, and signs a statement for a new seal only where the new
+  seal extends that one.
+  - *Consistency proofs*, exactly as RFC 9162, section 2.1.4, sets out:
+    `consistencyProof(leaves, m)` and `verifyConsistency(m, n, rootM,
+    rootN, proof)` (Python: `consistency_proof`, `verify_consistency`).
+    For m equal to n the proof is empty and the roots must be the same;
+    for m of 0 the proof is empty and the earlier root must be that of the
+    empty tree. A second implementation, written in the tests from the RFC
+    alone, is compared with the library's for every pair of sizes up to 64
+    leaves, with every value of every proof changed and left out.
+  - *A new kind of record, the witness statement*: label
+    `vnd.provared.witness.v0+json`, two signatures (Ed25519 and
+    ML-DSA-87), content `type`, `id`, `seal` (the seal's fingerprint),
+    `size` and `root` (repeated from the seal), `by` (`{keys, name}`)
+    and `when`. `writeWitness(fields, signers)` (Python:
+    `write_witness`); signers may be keys or signer objects. There are now
+    twenty-six labels.
+  - *Beside a seal*: a seal's line may hold `witnesses`, 1 to 4
+    statements, none from the same key set twice; and a seal handed over
+    beside the book (`seals`, `--seal`) may hold statements that came
+    later. A checker checks each: its signatures, that it speaks of that
+    very seal (its `seal`, `size` and `root`), and that it is not dated
+    more than 300 seconds before the seal. One new code,
+    `witness-invalid`; it joins the format's own list of finding codes.
+    A statement that does not pass is a problem with its entry, or, handed
+    over, with the whole check (the seal it came with is used all the
+    same).
+  - *Which witnesses count*: the option `witnesses` (the fingerprints of
+    the key sets of the witnesses the person trusts), `--witness
+    <fingerprint>` on the command line (may be repeated), and a box on the
+    checking page. A statement counts only where its witness is named,
+    both its signatures were checked on the device, **the book's first
+    line is a permission that passed, signed by a passkey the person
+    named (`issuerKeys`), the person named the recorders they expect
+    (`sealKeys`)**, and its seal passed with its Ed25519 and ML-DSA-87
+    signatures checked there (its third, SLH-DSA, may not be: the Python
+    version and browsers count on the first two). A witness knows a book
+    only by its permission and its recorder's keys, which the recorder
+    chooses; without both fixed by the reader, a recorder could start a
+    second history with another first line and have the same witness
+    sign for it (found by the independent review). Where a statement
+    from a trusted witness is not counted for that reason, the answer
+    says why. One from a witness not named is shown and not counted.
+  - *What the answer says*: each seal entry, and each seal handed over,
+    gains `witnesses` (each statement with its fingerprint, its witness's
+    key set fingerprint, its name as a label, its `when`, its signatures,
+    `state`, `trusted` and `counted`); the summary gains `witnessed`: the
+    latest seal for which a statement counts, the entries it covers, the
+    witnesses, and every seal witnessed, or null. Where a seal is
+    witnessed, the answer's list of what the check does not show says what
+    a witness shows and what it does not. Being witnessed excuses nothing,
+    is never said of a book with a problem, and is not needed for exit
+    code 0. The command-line checker prints "Witnessed by a witness you
+    trust?".
+  - *The witness itself*, in the library (it needs Node.js, because it
+    checks SLH-DSA): `openWitness({ by, signers, state, clock })`, with
+    `witness(entry, proof, firstLine)`, `update`, `ready`, `latest(book)`
+    and `state()`. It knows a sequence of books by the recorder's key set
+    with the passkey and the agent of the permission on the first line
+    (`bookIdentity`); ties the first
+    line to the seal with an audit path when it first sees a sequence and
+    at each new book, and keeps it
+    tied with each consistency proof (`witnessProof` makes the proof to
+    send); signs only for a seal whose three signatures it checked, which
+    names the seal it holds, is not dated before it, extends it, and is
+    dated no more than 300 seconds after its clock; never signs two
+    different seals of one book at one size (the same seal again gets the
+    same statement); checks every signature it makes before it keeps or
+    gives out a statement; and hands back its state with each statement,
+    to be saved first. Opened from a saved state, it signs nothing until
+    it has been brought up to date from a copy of what it gave out
+    (`update`) and told so (`ready`). A witness running as a service is
+    not part of this change. The Python version has no witness.
+  - The check before acting, the stub writer and a checker that is
+    carried on read statements as a whole check does; a statement's
+    signatures that the device cannot check leave the record not fully
+    checked, as for any record.
+  - *The books of one permission* (format description, section 21.6): a
+    seal may give `book`, its book's number among the books its recorder
+    keeps under one permission (2 or more; absent for the first book, so
+    every seal written before reads as it did; `1` is refused, and a seal
+    with `book` must give `previous`). The first seal of a later book
+    names, as `previous`, the last seal of the book before: a checker of
+    that book alone does not compare it, says so, and, handed that seal,
+    says whether the book follows on from it (`seal-chain-broken` where it
+    is by other keys, `time-went-backwards` where it is dated after the
+    first seal); a seal of another number is not compared by its place.
+    Every seal of a book gives the same number (`seal-chain-broken`).
+    `writeSeal` takes `book` (Python: `write_seal`). The recorder beside
+    Claude Code does not yet number its books.
+  - *The witness keeps every book of one recorder, person and agent as
+    one sequence*: it knows a sequence by the recorder's keys with the
+    passkey and the agent's key set of the permission on the book's first
+    line, so a renewal (another permission from the same passkey to the
+    same agent) is the same sequence, and a book that starts with it must
+    follow on from the seal the witness holds (found by the second round
+    of the review: known by the permission alone, a book that began with
+    a renewal forked the history). It keeps no book whose first line is
+    not a permission (`slip-missing`; a first line given with its line
+    feed is `bad-field`), signs for the first seal of the next book only
+    where that seal names the latest seal it holds and its first line is
+    tied to it, and never again signs for the book before; a fork across
+    books is refused. Its state names each sequence by its passkey and
+    agent. One recorder key set keeps one sequence for each person and
+    agent: books kept side by side for one agent need recorder keys of
+    their own.
+  - *Every permission before a witnessed seal must name the first line's
+    passkey and agent* (found by the third round of the review: a book
+    that started with agent Y's permission, then held agent X's
+    permission and stubs with the one over the limit left out, was signed
+    as the first book of the person and agent Y and read as witnessed).
+    A statement now counts only where every permission among the entries
+    its seal covers names the same passkey key and agent key set as the
+    first line's; otherwise a note says why. A renewal by the same person
+    for the same agent, and each agent's own book under one recorder (as
+    the gateway keeps them), are witnessed as before. A Show counts a
+    statement only where its pages hold every entry the seal covers, so it
+    never counts one the whole book would not. The witness cannot apply
+    this itself: it sees a book's first line, not its entries.
+  - *A seal held elsewhere that gives another book number than the book
+    is not compared with it, and gives no pass* (found by the second
+    round of the review: a book cut short and sealed again as "book 2"
+    otherwise hid the cut). It is not used; its note says what it shows
+    and that this book does not show whether that book was cut short;
+    the command-line checker says "Seals held elsewhere compared? NO" and
+    does not end with code 0, and the checking page gives no green
+    answer.
+  - New shared test files: `tree-consistency`, `tree-consistency-checks`,
+    `witness-contents`, `witnesses-written`, `witness-books`,
+    `witness-shows`, `witness-before`, `seal-books`, `chained-books`,
+    `chained-shows`, `renewal-books`, `renewal-shows`, `two-agent-books`
+    and `two-agent-shows`. **Every stored answer of a whole
+    book, a Show or the stub writer changes**, and only by the new
+    members: `summary.witnessed: null`, and `witnesses: []` on every seal
+    entry and every seal handed over; `denial-constants` gains
+    `witness-invalid`. Eleven files change, each checked case by case to
+    differ in those members alone (`books`, `denial-books`,
+    `denial-constants`, `denial-scenarios`, `denial-shows`,
+    `held-seal-shows`, `held-seals`, `recorder-details-after`,
+    `recorder-scenarios`, `shows`, `tool-scenarios`); no record was
+    signed again.
+  - Section 28's list of finding codes now also names `book-cut-short`
+    and `seal-not-in-book`, which the library already gave.
+  - **A checker of version 0.5.0 or earlier refuses a seal's line that
+    holds `witnesses`** (`unknown-entry`), **and a seal that gives `book`**
+    (`bad-field`).
+- **A witness that runs as a service, and the recorder beside Claude Code
+  numbering its books and asking witnesses** (`integrations/claude-code`:
+  `witness.mjs`, the new command `provared-witness`, `witnessed.mjs` and
+  `proofs.mjs`). The package now needs `provared` 0.6.0 or later.
+  - *The recorder numbers and chains its books* (format description,
+    section 21.6). The first seal of a new book gives the book's number
+    and names the last seal of the book before; its later seals give the
+    same number. "The book before" is the latest kept book whose first
+    line is a permission from the same passkey, for the same agent, sealed
+    with the recorder's keys, as a witness knows a sequence; it is read
+    from the kept files, so the numbers hold across a restart, and a kept
+    book that cannot be read stops the seal rather than give it a number
+    that may be wrong. A book that begins with another passkey's
+    permission begins a sequence of its own, with no number. The first
+    book gives no number, so the record so far reads as it did, and a book
+    whose seals give no number goes on giving none. Before the book in
+    force is first sealed, every kept book a late call could still come
+    back to is closed, and sealed again where something came after its
+    seal; such a call is then recorded in the book in force. Every seal's
+    line is made sure to be on the disk (fsync), and a book is kept as
+    `book-<n>.jsonl` only once it is.
+  - *`provared-witness`*, a small service on 127.0.0.1 (port 8796 by
+    default) around the library's witness (`openWitness`), in a folder of
+    its own: its keys (Ed25519 and ML-DSA-87), a token for the recorders
+    it serves and another for its operator, its settings (`witness.json`:
+    its name, the fingerprints of the recorders it serves, its port and
+    limits), a journal, a state and a checkpoint. For each new statement
+    the journal line and then the state are made sure to be on the disk
+    (fsync) before the statement is given out; what it says it holds
+    (`/latest`, `status`) is what it last saved, never what the library's
+    witness holds in memory, and once anything cannot be saved it gives
+    out nothing more, by any route, until it is started again. Every 256
+    journal lines it writes a checkpoint (the latest seal of each sequence,
+    with its statement) and begins the journal again; a start reads the
+    journal a line at a time, and in full only the lines its state does
+    not yet reflect. At every start, the first included, it signs nothing
+    (`witness-not-ready`) until its operator says that its folder was not
+    put back to an older copy (`ready`, or `start --ready`); `update <book>
+    [--seal <file>]` hands it, from a copy, the statements it signed for a
+    book's seals, and `forget <sequence>` makes it hold a sequence no more
+    (it then signs whatever it is next shown for that sequence). It
+    refuses to start where its journal has gone while its keys are there,
+    where a journal line is not one it writes or lines are numbered out of
+    order, where its state reflects more lines than the journal holds, or
+    where the journal follows a checkpoint it does not have; a last journal
+    line cut off by a stop is taken off; a lost state is rebuilt from the
+    checkpoint and the journal; a stop between the steps of a checkpoint
+    is mended at the next start. One witness at a time on a folder
+    (`witness.lock`, taken over from a process that has ended under a
+    second file only one start can make). Who may ask: a program proves
+    that it holds the token, which never travels, as for the recorder's
+    feed (a hello, then HMAC-SHA-256 over the question, its body included,
+    and over the answer), one question to a conversation; the operator's
+    commands (`status`, `ready`, `update`, `forget`, `stop`) take the
+    operator's token; it signs only for seals of the recorders named, and
+    starts a new sequence only from a permission whose passkey signature
+    the library's checker passes. Limits: 120 new statements in any hour
+    (shared by every recorder it serves), 64 sequences, 8 questions that
+    sign at once, bodies of 1 MiB. Library refusals keep the library's
+    codes.
+  - *The recorder asks the witnesses named in `witnesses.json`* (at most
+    four, each on 127.0.0.1, with the fingerprint of its key set and its
+    token; written by the new commands `add-witness`, which checks that the
+    witness answers, holds the token and signs with that key set, and
+    `remove-witness`). After each seal it asks each witness what it holds
+    and whether it signs now, and shows one that does, in order, the seals
+    it has not signed for whose lines are on the disk, with the proof RFC
+    9162 sets out, made from the book's line fingerprints kept as the book
+    grows (`proofs.mjs`, the same proofs as the library's `witnessProof`
+    without reading the book again), and the book's first line; a witness
+    that holds none of this sequence is shown the latest only. For the
+    seal that `seal` makes, the seal's entry is first kept apart on the
+    disk (`pending-seal.json`, written at its place at the next start if a
+    stop comes first, or let go where its line is in the book or in a book
+    kept since; one at a time), the witnesses are asked, and the
+    statements that come within five seconds stand beside the seal on its
+    line; the wait ends at once when any other request arrives, so no tool
+    call waits for a witness. A statement is taken only where the
+    library's checker passes it for that seal, as signed by the witness
+    named; one that comes later is kept beside the book in
+    `witnessed/<seal>.json`, in the form the checker takes with `--seal`,
+    and `check` hands those of the book checked over, names the witnesses,
+    and says plainly that those copies are the book's own seals from the
+    recorder's folder, not seals held elsewhere, and cannot show the book
+    cut short. A witness that is down, refuses, could not save, or hands
+    back what does not pass never stops recording: `status` shows, for
+    each, the seal it holds, whether that is the latest, and why not; one
+    that holds a seal of this sequence in none of the recorder's books is
+    reported (`witness-holds-another`) and is sent no seal. The record page
+    tool, tried on a numbered book with statements, reads the books as
+    before (it names no witness, and hands over no statement kept beside
+    the book); the application's uploader reads the books through the
+    feed, which is unchanged. Measured on a book of 93.5 MB with four
+    witnesses: a tool call's two questions took at most 67 and 99
+    thousandths of a second after a seal; during any seal a call waits for
+    the seal itself, about 3.3 seconds on such a book, with or without
+    witnesses.
+  - *After its independent review*: a statement that could not be
+    journaled was still given out through `/latest`, and after a restart
+    the witness signed a different seal at the same size (fixed: only what
+    is saved is given out, and nothing once a save has failed); a folder
+    put back to a copy taken before the first statement started ready and
+    signed a fork (fixed: never ready at a start until told); the journal
+    was read whole at each start and could no longer be read at about
+    8,000 lines (fixed: checkpoints, and a line at a time); proofs read the
+    whole book each time (fixed: line fingerprints kept); and the low
+    findings on the seal kept apart, the lock, the agent in the book
+    before, `check`'s words and the passkey signature of a new sequence.
+  - Stated: on one computer under one user account the agent can reach
+    the witness's folder, so a witness means more under another account,
+    on another computer through a tunnel, or run by someone else; a
+    witness on another computer reached directly is not built; what
+    travels is proved, not encrypted; one token serves every recorder the
+    witness serves, and each can read what it holds for any of them, fill
+    its sequences with permissions signed by passkeys of its own, and use
+    up the shared statements; a witness put back to an older copy and told
+    it is ready can be made to sign a fork (a test shows it); forgetting a
+    sequence a recorder still uses lets that recorder have a second
+    history witnessed. 51 new tests in the package (181 in all). Of 61 checks broken in turn, before and after the review, 59 are caught by a test; the two that are not (a stale lock taken without the second file, which only a race between two starts reaches, and the in-time ask kept to a book that passes its check, which no book the recorder holds fails) are stated.
+- **The recorder beside Claude Code offers its books to a reader on this
+  computer, through a feed on its own port** (`integrations/claude-code`,
+  `feed.mjs`), so that no other program need open a book file. On
+  11 October 2026 an uploader reading `book.jsonl` made the recorder's
+  rename of it fail on Windows, and seven receipts were lost; the
+  application's uploader now asks the recorder instead. `GET /books`
+  lists the books oldest first (the kept ones by number, the one in force
+  last), each named by its file's identity (the volume, the file's number
+  and its creation time, which a rename keeps, reckoned as the uploader
+  reckons it), with its size; `GET /lines?id=<identity>&from=<n>` (or
+  `book=<name>`, or neither for the book in force) answers with up to 500
+  lines (and at most 4 MiB) from place n, where each is in the file, the
+  line before place n with its fingerprint, the number of lines and the
+  fingerprint of the last; `max` asks for fewer, and 0 for none. Lines are
+  counted as the uploader and the checker count them (an empty line and a
+  carriage return set aside, a line with no line break not yet a line).
+  Where the book holds nothing at place n yet, the question waits up to
+  25 seconds (`wait`) and is answered as soon as any book is written, a
+  late receipt or a seal again in a kept book included; at most 8 wait at
+  once, and one more is told to ask again (429). The recorder writes a
+  token into its folder at its first start (`feed-token`, 32 random
+  bytes, readable by its owner only where the file system keeps such
+  rights), and **the token never travels**: a reader opens a conversation
+  (`GET /hello`) with a random number; the recorder answers with a random
+  number of its own and HMAC-SHA-256 over both, keyed by the token, and
+  the reader trusts nothing until that proof checks; each question then
+  carries an HMAC under a key both sides work out from the token and the
+  two numbers, with a number used once, and each answer an HMAC under the
+  same key over the question's number, its code and every byte; every
+  proof is compared in constant time, and a question asked twice is
+  refused. Each of these 32-byte values is read only in the one way it can
+  be written in base64url, so none can be given again under another
+  spelling of the same bytes. A hello keeps nothing: the recorder's number for a conversation
+  is worked out from the time, the reader's number and a secret only the
+  running recorder holds, and a conversation is kept only from its first
+  proved question; only proved conversations (at most 16, each ended
+  after 10 minutes unused) give way to one another, so a program without
+  the token cannot push out one in use. Each question, refused or not,
+  still costs the recorder about a thousandth of a second, so very many at
+  once slow the hook in proportion. A token file that holds no token is not replaced, and the feed
+  then refuses every question and `status` says why. One answer is made
+  at a time, with a pause between two, and at most 16 are taken on at
+  once (429 beyond). The books the recorder holds open are read from its
+  own copy in memory, only as far as it has written them to their files,
+  so the feed answers while another program holds `book.jsonl` open with
+  no sharing and never gives out a receipt whose save failed; a kept book
+  it no longer writes is read from its file, 4 MiB at a time, and closed
+  again. Measured on the author's computer with a book of 98 MB: about
+  110 thousandths of a second for the first question, 1.8 seconds to read
+  the whole book; a hook's two questions took a median of 61 thousandths
+  of a second with no reader and of 160 (at most 266) with two readers
+  reading the whole book again and again, and a hook's question 971
+  thousandths with 1,500 feed questions at once. The service still listens
+  on 127.0.0.1 only. Nothing of the record or the format changes.
+- **The recorder never replaces its book because it could not read it**
+  (`integrations/claude-code`). Where another program held `book.jsonl`
+  for a few seconds while a receipt was saved, the recorder took the
+  failed read as "no book yet" and replaced the whole file, which then had
+  a new identity; an uploader following it stopped for good. Now the
+  reading and the adding are tried again for up to ten seconds while the
+  file is busy, a read that fails otherwise fails the save and leaves the
+  file as it is, and the file is replaced only where it was read and no
+  longer holds the book's start. Found by the independent review of the
+  feed, with four faults of the feed itself, each fixed and tested: the
+  token sent to whatever listened (now never sent); questions that do not
+  wait had no limit (on a 98 MB book, 1,500 at once held a hook up for 22
+  seconds); a receipt whose save failed could be given out; and a kept
+  book of exactly 4 MiB that ended part way through a line lost that
+  line's start. A second review found that a hello kept a conversation,
+  so that a program without the token could push out the uploader's (now
+  a hello keeps nothing). Where a save fails after the ten seconds, the
+  hook is now told the truth: the stub is signed and held by the
+  recorder, not yet in the book file, and written with the next save, and
+  `status` counts it as recorded. A third review found that an ended
+  conversation could be begun again under another spelling of its number
+  (now refused), and that no test held the refusal of a hello dated ahead
+  of the clock (now tested). 37 tests of the feed; the package's 130 pass.
+- **Seals held elsewhere, handed over beside the book** (format
+  description, section 21.5), in both languages. Whoever keeps a book
+  could cut off its end, the last seal with it, and what is left still
+  checks. Now anyone who keeps a copy of a seal (the person, an auditor, a
+  second copy out of the recorder's reach) can hand up to 64 of them to
+  the checker, each as the entry it is in the book: the option `seals`,
+  `--seal <file>` on the command line (may be repeated), and a file
+  chooser in the checking page's panel "What you were handed with the
+  record". A seal at entry n must stand at entry n of the book. Two new
+  codes, both problems with the book: `book-cut-short` (the book ends
+  before that place) and `seal-not-in-book` (the entry there is not a
+  seal with the same content; the same content with other signatures is
+  the same seal, and is said). Nothing in a seal names its book, so a
+  seal of another book by the same recorder is reported against the book
+  being checked. Each seal handed over is checked as any seal is, once
+  for a checker that is carried on and for the stub writer; it counts
+  only where its recorder is named in `sealKeys` (`--sealer`), and on a
+  device without SLH-DSA (the Python version, and browsers that have
+  ML-DSA) on its Ed25519 and ML-DSA-87 signatures, which the answer says.
+  Seals handed over without `--sealer` give no pass (code 1), and a line
+  of their own says why, on the command line and on the checking page. One that does not pass its own check is a problem with
+  the whole check. Its own time-stamps are shown, and are not used for the
+  entries of the book; where they differ from those the book holds beside
+  the same seal, the answer says so. A Show does not use seals held
+  elsewhere, and says so. Each one is given in the answer's `held` list,
+  after any cancellations, with `kind: "seal"`, `place`, `inBook`,
+  `sealer`, `used`, `verified`, its signatures and time-stamps; the
+  type declarations give `held` as `(HeldCancellation | HeldSeal)[]`.
+  The check before acting and the stub writer take the option too, and a
+  seal held elsewhere whose third signature this device cannot check is
+  excused there as a seal in the book is. No new kind of record. The two
+  codes join the format's own list of finding codes (`FINDING_CODES`).
+  New shared test files: `held-seals`, `held-seal-shows` and
+  `held-seals-before`; `denial-constants` changes for the two new codes,
+  and no other shared file changes.
+- **A new kind of record: the denial** (format description, section 28),
+  in both languages. It is the agent's own side's signed statement that it
+  did not take an action that was asked for, and who said no: the check
+  before acting (with the finding codes it gave, from the format's own
+  list, now written out in section 28), the person, or a rule of the
+  software around the agent. It is signed with the agent's two keys, or a
+  helper's under its pass, with the new labels
+  `vnd.provared.denial.v0+json` (twenty-four labels in all). In a book it
+  comes after its slip, is in no chain and is compared with nothing; a
+  checker shows it as the agent's side's own word, counts it
+  (`summary.counts.denials`, new in every answer), and never counts it
+  against the agent. `writeDenial` (`write_denial`), `denialCodes`,
+  `FINDING_CODES` and `DENIAL_SOURCES` are new. The stub writer writes a
+  denial whenever `act` does not take an action if it is opened with
+  `denials: true` (`more.denial: false` writes none for one call);
+  `deny` writes one for a refusal from elsewhere; at most
+  `denialsPerHour` (600 by default) are written in any hour of the
+  writer's clock, each counted at the clock's time when it joins the
+  book (whatever date it states), the answers count those left out, and
+  a stub is never kept out. `deny` records what its caller states. `recordTools` and
+  `record_function` pass it on (`NotTaken.denial`), and where the person
+  may yet approve a call they write none until it is known the call will
+  not run, so one call never leaves both a stub and a denial. The
+  command-line checker and the checking page show denials. **A checker of
+  an earlier version refuses a book that holds a denial** (`unknown-entry`).
+  New shared test files: `denial-contents`, `denials-written`,
+  `denial-codes`, `denial-constants`, `denial-books`, `denial-shows`,
+  `denial-before` and `denial-scenarios`; `books`, `shows`,
+  `recorder-scenarios`, `recorder-details-after` and `tool-scenarios`
+  gain `denials: 0` in their stored counts, and nothing else changes in
+  them.
+- **`provared-hermes` 0.1.0, a plugin for Hermes Agent**
+  (`python/integrations/provared-hermes/`): every tool call of a Hermes
+  agent is checked against the slip before it runs, and a stub is
+  written once it has run; a call the slip does not allow is not run,
+  and the model is told why. It runs no recorded call on a Hermes it was
+  not tested with (0.21.7 and later 0.21 versions) unless told to, and
+  it loads on any Hermes so that its own check can refuse. Its commands
+  are named by the same reading of the command text as the recorder
+  beside Claude Code (below), with shared test rows that both languages
+  answer alike. Checked by independent reviewers over eight rounds, the
+  last six with the shared reading of commands, the last three clean;
+  71 tests. Not on the Python Package Index yet: the README gives the
+  command to install it from this repository.
+- **The recorder beside Claude Code reads commands more closely**
+  (`integrations/claude-code/`, not published), with the same reading
+  as the Hermes plugin. A deletion or a publication is now named as one
+  where it sits inside `"$( … )"` or back-quotes in double quotes, with
+  quotation marks, `case` choices and comments inside; after a shell,
+  `eval`, `ssh`, `watch` or another program that runs a command line;
+  in a quoted command after `-c`, `-Command` or `-ArgumentList`; where a
+  program is written as a path; or in text piped or handed into a
+  shell. More publishing and deleting commands are named (among them
+  `gem push`, `helm push`, `dotnet nuget push`, `docker buildx --push`,
+  `rsync --delete`, `DELETE FROM` given to a database client and
+  `redis-cli FLUSHALL`). Quoted words that run nothing, such as a commit
+  message holding `rm`, are no longer named deletions; a back-quoted
+  command in double quotes is, because the shell runs it. On a varied
+  set of 11,340 deleting and publishing lines, none is named less
+  strictly than before; on 109 everyday commands, 2 are named deletions,
+  as before. The longest lines tried (about 900,000 characters) are read
+  in under a second. The README lists what the reading still misses: a
+  command line kept in a file or a variable, `-EncodedCommand`, and
+  others. Writing the book file, the slip and the list of trusted
+  passkeys is retried for up to ten seconds where Windows holds the file
+  busy, and leaves no temporary file behind; a renewal held by a busy
+  file can keep the service waiting about 40 seconds, during which calls
+  are refused, never let through. Checked by an independent reviewer
+  over six rounds, the last three clean; 60 tests.
+- **The recorder beside Claude Code starts a new book at 90,000 entries
+  or 100 MB** (`integrations/claude-code/`, not published). A book holds
+  at most 100,000 entries, and once full every call would be refused. At
+  90,000 entries or 100,000,000 bytes of text, whichever comes first, or
+  on the command `new-book`, the recorder seals the book, keeps it beside
+  the new one as `book-1.jsonl`, then `book-2.jsonl` and so on, and
+  starts a new `book.jsonl` that begins with the permission in force,
+  with no gap in recording; a call that ends during the switch is written
+  into the kept book, which is then sealed again. Every limit is counted
+  across the books, from the kept books' receipts and the calls still
+  running, so a new book, by command, by size or after a restart, starts
+  no limit afresh. A checker given one book still counts limits within
+  that book only, so around a switch the record shown to a checker can
+  hold up to twice a limit within one period across two books, though the
+  agent was held to it. The README states what this does not close: a
+  kept book moved, renamed or removed while the recorder is stopped is
+  no longer counted, and nothing in the record shows it. The record page
+  (`tools/make-record-page.mjs`) lists each kept book with its own
+  checker's answer, and points out a gap in their numbers; the site's
+  publishing run fetches them from the release "record". Checked by an
+  independent reviewer over four rounds; 93 tests.
+- **The recorder beside Claude Code numbers its books, chains each new book
+  to the last seal of the book before, and asks witnesses; and a local
+  witness service, `provared-witness`** (`integrations/claude-code`:
+  `recorder.mjs`, `witness.mjs`, `witnessed.mjs`, `proofs.mjs`; live for the
+  published record since 24 October 2026, 15:38 UTC). A book's number
+  follows the passkey of its first line: a book that holds a seal goes on as
+  its first seal says; one that holds none takes the latest kept book's
+  number and one, where that book began with a permission from the same
+  passkey and its last seal is by this recorder's keys, and its first seal
+  names that book's last seal; where there is no such book it gives no
+  number, so the record so far reads exactly as it did and its next book is
+  book 2. The numbers are read from the kept files, never kept in a file of
+  their own. Before the book in force is first sealed, every kept book that
+  a late call could still come back to is closed and, where something came
+  after its seal, sealed again, so that the first seal of book n names the
+  last seal of book n - 1; a kept book that cannot be read when that seal
+  needs it stops the seal, and the error says why. Every seal's line is
+  made sure to be on the disk, and a witness is shown only such seals. A
+  renewal with a new passkey starts no new book; the next book then begins a
+  sequence of its own.
+  - *Witnesses*: `witnesses.json` names at most four, each
+    `{address, key, token}` at `http://127.0.0.1:<port>`, written by
+    `add-witness` (which reads the token from the witness's token file and
+    checks that the witness answers, holds the token and signs with that key
+    set) and `remove-witness`. After the seal that `seal` makes (the
+    command, `POST /seal` or the service's own) the recorder keeps the seal
+    apart on the disk (`pending-seal.json`) before any witness is asked,
+    shows each witness every seal after the one it holds (at first contact,
+    the latest only), and waits at most five seconds, and no longer than
+    until any tool call arrives; statements that come in time stand on the
+    seal's own line, and every other statement is kept beside the book in
+    `witnessed/<seal fingerprint>.json`. Each statement is checked with the
+    library's own checker before it is kept. It asks again after each seal
+    and every minute while a witness is behind; a witness that holds a seal
+    of this sequence that is in none of the recorder's books is reported
+    (`witness-holds-another`) and asked no more. A seal kept apart that the
+    book changed under while the recorder was stopped is moved aside
+    (`pending-seal-not-placed-<time>.json`) and `status` says so. `check`
+    hands over the kept statements of the seals in the book checked (the
+    latest 64) and names the witnesses of `witnesses.json`, unless `--seal`
+    or `--witness` is given. `status` gains `witnesses`, `witnessesProblem`
+    and `pendingSealProblem`; `seal` answers with `book` and `witnessed`.
+  - *The witness service* (`provared-witness`: `init`, `start`, `status`,
+    `ready`, `update`, `forget`, `stop`) listens on 127.0.0.1:8796 with a
+    folder of its own (`witness-keys.jwk`, two tokens, `witness.json`,
+    `journal.jsonl`, `state.json`, `checkpoint.json`, `journal-mark.json`,
+    `witness.lock`). One token is for the recorders it serves and one for
+    its operator; questions and answers are proved as the feed's are
+    (HMAC-SHA-256 under a key worked out from the token and two random
+    numbers; one question to a conversation). It signs only for the
+    recorders its operator named, by the fingerprint of their key sets, and
+    only after the journal line, then the state, then the mark, are on the
+    disk; after a save that fails it answers 503 until it is started again;
+    at every start it signs nothing until its operator says it is up to date
+    (`ready`), after taking its own journal again, and it refuses to start
+    where the journal has gone while the keys are there, where a line is not
+    one it writes, or where its state reflects more lines than the journal
+    holds. Limits: 120 new statements in any hour, 64 sequences, 8 signing
+    or updating questions at once, bodies of 1 MiB. There is no background
+    start: whoever runs a witness decides how it is kept running. Stated in
+    the README: a witness is only as sound as its folder, and whoever can
+    change it, or put back an older copy whole, can make it forget a
+    sequence.
+  - The package depends on `provared` 0.6.0 or later. Three independent
+    reviews: the first found one serious fault (a statement given out that
+    was never saved, so after a restart the witness could sign a fork) and
+    three medium; the second and third found nothing serious or medium.
+    189 tests, and the three test fixes of 21 October brought across.
+- **`provared-gateway` 0.1.0, a reverse proxy that writes the receipts**
+  (`gateway/`, not published). It sits in front of the web interfaces an
+  agent acts through, holds the agent's keys (in memory or through
+  signers) and each interface's credential, and for every call: checks
+  the agent's own secret, names the call from a rules file the company
+  writes (paths by the WHATWG URL Pattern standard, amounts by a fixed
+  value, a JSON Pointer of RFC 6901 or the length of a list), removes
+  the agent's own credentials from the headers and the address, asks the
+  stub writer's check before acting, sends the call, and writes a stub
+  that names `provared.http-request`, `provared.http-response` or
+  `provared.error`, and the upstream's own identifier where it gives one.
+  A call that is not allowed is not sent, is answered `403` with the
+  checker's words, and is written as a denial; a call that matches no
+  rule is refused by default. A call once sent always gets its stub,
+  whatever the upstream did. An upstream the company runs may
+  countersign. Books are sealed on demand with the recorder's keys
+  (`provared-gateway seal`); `provared-gateway check` says what each rule
+  maps to and what is wrong. Each book is a file appended line by line;
+  the feed to the application is not built. It is the gateway's record
+  only, and proves nothing about calls that do not go through it, as its
+  README says first. An independent review found one serious point: a
+  body naming `hosts` and `HOSTS` was recorded with the first's amount,
+  while an upstream that reads names whatever their case acts on the last.
+  Now a body whose names some readers take as one (differing only in
+  capitals, or in the long s or the Kelvin sign) gives no amount, and the
+  call is not sent. Also from the review: method and address override
+  headers and `_method` are removed, with every `X-Forwarded-*` and the
+  other client-address headers; a `;` in a path is refused unless the
+  upstream allows it, and then the rules match each segment without what
+  follows its `;`; overlong UTF-8 and full-width `/` or `.` in a path are
+  refused; each agent may have only so many calls and bytes waiting; a
+  journal beside each book lets a start find a call that was sent when the
+  gateway stopped, and stops that agent until the administrator
+  acknowledges it (`provared-gateway acknowledge`), when a stub saying the
+  outcome is not known is written; header names with `_` and a
+  `Connection` header that names other headers are refused; more
+  credential headers and query forms are removed; a character set other
+  than UTF-8 gives no amount; a credential that cannot be sent as a header
+  is refused at start; a stub for a call that never reached the upstream is
+  labelled `gateway.not-delivered`; two agents may not share a secret or a
+  book file; and the status answers while a call is out. A second review
+  found two medium points in the journal: one call could get two receipts
+  (a stop between its stub and the journal's "done" line, or an
+  acknowledgement tried again after a failure), and any program that could
+  write the journal could have the gateway sign stubs of its choosing. Now
+  every stub names its call (a label, `gateway.call`), and a start takes a
+  call whose stub the book holds as done; each journal line carries an
+  HMAC-SHA-256 tag under a journal key of the agent's own, and a line
+  whose tag does not check is never acted on; each line is checked against
+  the rules before a stub is written from it; the status shows each
+  waiting line whole; and the administrator can set aside a line
+  (`acknowledge --set-aside`). Also from that review: JSON names are
+  folded beyond ASCII (Greek final sigma, the dotless i and others), so an
+  unrelated `ID` and `id` in one object now give no amount; an encoded
+  character in a path whose NFKC form differs from itself is refused;
+  `provared-gateway repair` takes off a book's last line that a stop left
+  part-written; and two agents may not share a book, a journal, a journal
+  key or a key file. A third review found one medium point: a stub
+  written on acknowledgement went under the slip in force at the restart,
+  not the one the call was sent under. Now each journal line names its
+  slip, and the stub is written under that slip (by a stub writer for it,
+  opened on the same book), or, where the book does not hold it, the line
+  can only be set aside. Also from that review: two agents' files are also
+  compared by each existing file's device and file numbers (a link to
+  the file is followed), so, where the file itself exists, a hard link or
+  a link to the file counts as the same file; a journal that none of its
+  lines checks under the journal key in place stops the start; a
+  journal that holds lines and has lost its key stops the start (each of
+  these two stops the whole gateway, not that agent alone); a line
+  whose rule was taken out can still be acknowledged, with a warning; a
+  clock behind the journal's times is said plainly; calls set aside are
+  kept in a file a clean start does not empty; the library's own checks of
+  a request's fields decide whether a line is usable; the dotted capital
+  `İ` folds with `i`; `repair` takes its byte count only in digits and can
+  put back a lost line ending; and the README lists which honest path
+  forms are refused. 68 tests, all on 127.0.0.1, with a file of 145 calls
+  and the action, amount and service each must map to.
+- **A central sealer** (format description, section 21.7, new; no record
+  changes). The recorder's three keys can now sit apart from the agent,
+  with a party that never sees the book.
+  - *In the library*: `leafFingerprint(line)` (Python:
+    `leaf_fingerprint`), the SHA-256 of the byte 0x00 and one line of a
+    book, refused where the line is empty, holds a line feed, is not
+    well-formed Unicode or is over 131,072 bytes; and `openSealer({by,
+    signers, stamp, state, clock, signWithin})`, which takes the leaf
+    fingerprints of each book's lines (`extend(book, at, leaves)`, only
+    at the place it holds, so a line is never taken twice), keeps the
+    same running tree the checker keeps, and signs a seal over its own
+    number of entries and top fingerprint (`seal(book, {previous})`),
+    through the same keys and signers `writeSeal` takes, each signer
+    given 30 seconds. The seal is the one `writeSeal` signs over the same
+    book, with the same time and unique number. It signs only where
+    `previous`, the seal the caller's book names, is the latest it
+    holds of that book (`not-up-to-date`): a sealer whose state is
+    behind the book signs nothing until it is brought up to date with
+    `update(book, entry, leaves)`, from a later seal it signed and the
+    leaf fingerprints since its own latest seal, which must give that
+    seal's top fingerprint; it is never moved back. `latest(book)` hands
+    back its latest seal, for a book that lost it. A book is known by
+    its first line's leaf fingerprint and its number; a later book names
+    the book it follows, its first seal names that book's last seal, and
+    that book is then closed (also where that first seal is brought in
+    with `update`, which waits, `not-up-to-date`, while the sealer holds
+    that book at an earlier seal than the one named). Every book with one first line is one chain: a book
+    whose first line the sealer holds starts only as the next book after
+    the latest with that first line (`not-next-book`). One sealer may
+    serve several recorders, through `forRecorder(name)`: a book, and
+    every book after it, belongs to the recorder that started it
+    (`other-recorder`). A recorder may be given rules,
+    `forRecorder(name, {agents, books})`: the fingerprints of the key
+    sets of the agents whose permissions it may start books with (an
+    agent belongs to one recorder), and the most books it may hold
+    (`too-large`). Where any recorder has a list of agents, every book is
+    started with its first line itself (`line`, beside `extend`, or
+    `update` for a book brought in), which must be a permission for one
+    of the caller's own agents (`agent-not-allowed`, `other-recorder`);
+    so no recorder can start a book whose first line is a permission for
+    another recorder's agent, nor bring another's book in first after a
+    lost state. The sealer then learns each first line; it does not check the
+    passkey's signature. `releaseUnsealed({recorder})` takes off books
+    that hold no seal, for which nothing was signed. A book started
+    after a book that another book now follows takes no first seal
+    (`book-closed`). Every seal is checked (all three signatures)
+    before it is kept; the state is handed back with a seal, a book
+    started and `update`, to be saved before the answer is given out. Of
+    a seal entry brought in with `update` only the seal, whose three
+    signatures it checks, and its time-stamps are kept, the time-stamps
+    read for their form only (at most four, each at most 12,288 bytes,
+    in base64url, none twice; no time-stamp's signature is checked); its
+    witness statements are not, and an entry longer than a line of a
+    book is refused (`too-large`), so that no recorder can make the
+    state too large to save. The entry is read once, and what is
+    measured, checked and kept is that one copy, so a member that gives
+    another value at each reading cannot slip past the checks. A
+    book is kept in the state at its latest seal, or with none at its
+    first line, so a sealer started again asks for the lines since; at
+    most 1,000 books, about 52 KB of state for each sealed book. With
+    its state kept it never signs two histories of one first line; a
+    book from another permission for the same agent that repeats sealed
+    lines, and a lost or older state, still need a witness. It sees only
+    fingerprints after the first line, so a recorder can start a book
+    from a permission for its own agent, copy into it another
+    recorder's agent's permissions and stubs with some left out, and
+    have it sealed: where one person's passkey signed the permissions
+    for both agents,
+    the book reads as intact and within its slips, and a witness
+    statement on its seal is not counted. A seal of the other
+    recorder's own book held elsewhere shows it (`book-cut-short` or
+    `seal-not-in-book`; where the two books' numbers differ, it cannot
+    be compared, and gives no pass); readers of books from a shared sealer should
+    hold each recorder's own seals elsewhere, or run a sealer for each
+    recorder. It needs SLH-DSA built in, so
+    Node.js; Python has no sealer. `writeSeal` and the sealer share one
+    signing path (`sealOver`, not exported). The tree builder gains
+    `addLeafHash` and `parts` (Python: `add_leaf_hash`).
+  - *A new shared test file*, `sealer-trees.json`: lines or leaf
+    fingerprints, and the number of entries and top fingerprint after
+    each; both languages give every answer.
+  - *`provared-sealer`* (`sealer/`, version 0.1.0, not published): the
+    sealer as a program on 127.0.0.1 (port 8797 by default), with its
+    keys in a file for its owner alone or reached through signer modules
+    named in its settings, a token for each recorder, the agents whose
+    permissions each recorder may start books with and the most books
+    it may hold (100 unless it says; all recorders' books add up to at
+    most 1,000), and one state for every recorder's books, each book
+    bound to its recorder; `release-unsealed` takes off, while it is
+    stopped, the books that hold no seal. A question proves its
+    recorder, and an answer its sealer, with HMAC-SHA-256 under the
+    token over a time, a number used once and the body; the token never
+    travels; each recorder's numbers used once are kept apart, for as
+    long as its question's time could be taken by a clock that never
+    goes back; the recorder's name, the time, the number and a first
+    proof over the body's declared length are checked before the body
+    is read, so no body is read for a program without the token, and at
+    most 16 MiB of bodies being read are held for one recorder. A
+    question waits for its turn as the bytes of its body only, at most
+    16 questions and 32 MiB for one recorder, and its body is read as
+    JSON only in its turn, so one read body exists at a time. A body
+    must be a JSON object, and may hold only the members its path takes
+    (`bad-field`); `connectSealer`, the recorder's side, refuses before
+    sending any member of `more` the path does not take (`id` for a
+    seal among them), so `more` cannot replace `book`, `at`, `leaves`
+    or `entry`, and sends a `when` given as a `Date` as its
+    milliseconds. A question
+    turned away as `busy` keeps no number. Questions are answered one at a
+    time; the state is made sure to be on the disk before an answer to a
+    question that changed it; a seal is never given out before the state
+    that holds it is saved, and after a failed save every question taken
+    up is answered `sealer-stopped` until it is started again. A missing
+    state stops the start, and adding a recorder (`--fresh` begins it
+    again); `add-recorder` refuses a name that has books in the state
+    (a recorder written into `recorders.json` by hand is not checked so); one
+    sealer on a folder at a time. It names no time-stamp service and
+    asks no witness yet.
+
 ## 0.5.0 (17 October 2026)
 
 - **The README's count of review rounds: 50.** The 40 recorded by