provared 0.6.0 → 0.7.0

package/CHANGELOG.md

@@ -1,5 +1,519 @@
 # 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.

package/README.md

@@ -1,5 +1,7 @@
 # <img src="https://prova.red/favicon.svg" alt="" width="36"> Provared
 
+[![OpenSSF Scorecard](https://api.scorecard.dev/projects/github.com/provared/provared/badge)](https://scorecard.dev/viewer/?uri=github.com/provared/provared)
+
 Proof of what an AI agent was allowed to do, and what it then did.
 
 A person signs the permission with a passkey. The agent signs a receipt
@@ -88,6 +90,8 @@ agent = create_agent(model, tools=[order_supplies, send_message],
 
 The package is listed among the middleware in
 [LangChain's own documentation](https://docs.langchain.com/oss/python/integrations/middleware).
+For JavaScript agents, [examples/frameworks/](examples/frameworks/) shows the
+same with the Vercel AI SDK, through `recordTools`.
 
 ## The four parts
 
@@ -139,6 +143,14 @@ each part protects against, is in
 - **[The Python version](python/README.md)**, which gives the same
   answers, with examples for three agent frameworks and packages for
   two of them.
+- **Two programs beside an agent, each on npm with its own README:**
+  [the recorder beside Claude Code](integrations/claude-code/README.md)
+  (`npm install -g provared-claude-code`, also installable as a Claude
+  Code plugin), which checks and receipts every tool call Claude Code
+  makes; and [the executor for MCP tool servers](mcp-executor/README.md)
+  (`npm install -g provared-mcp-executor`), which stands between an
+  agent and its tool servers, holds their credentials, and countersigns
+  each receipt with keys of its own.
 - **[The pages at prova.red](https://prova.red/)**: the checker's answer
   for the sample record, a worked example for developers, and the same
   in plain words for a reader who does not write code.
@@ -159,7 +171,7 @@ each part protects against, is in
 
 ## Status
 
-**Version 0.6.0, a draft.** Published as it is, by one author in their
+**Version 0.7.0, a draft.** Published as it is, by one author in their
 own time, built with AI tools since 3 October 2026; fixes as time
 allows. The code has been through more than 80 rounds of review by AI reviewers,
 each reviewer a fresh session given the code, the documents and a brief