provared 0.6.0 → 0.8.0

package/CHANGELOG.md

@@ -1,5 +1,728 @@
 # Changelog
 
+## 0.8.0 (1 November 2026)
+
+Version 0.8.0 changes the library's browser part, `src/passkey-browser.js`, which a web page uses to have a person sign with a passkey. A new function, `signChallengeWithChosenPasskey`, lets a page whose browser has forgotten which passkey signed before ask the device to offer the passkeys it holds for the website; the page must then check what comes back against the key it expects. Every signing function now also says which passkey signed (`credentialId`). What changes for a user: every other signing function now refuses, before the device is asked, a passkey that does not name its identifier as text of at least one character, with a `PasskeyError` of code `cancelled` and the words "No passkey was named, so nothing was signed." A missing or non-text identifier already failed with that code, with other words; a passkey whose identifier was empty text was handed to the device, and now throws instead. The signing page uses all this to open as a small window for another page (the Provared application), sign a new permission, a renewal or a cancellation there, and hand the record back; the signing page is served at sign.prova.red and is not in the npm package. Nothing else in the library changes: no record's bytes, no rule of the checker, nothing in the Python version but its version number, so a book checks with 0.8.0 exactly as with 0.7.0. Beside the library, in this repository, with entries in the list below: `provared-mcp-executor` 0.2.0, with rules on the content of a tool call, already published on npm on 1 November 2026; and a reader of Agent Middleware's receipts, `provared-agent-middleware`, not published. The framework packages `provared-langchain` and `pydantic-ai-provared` stay at 0.2.0, unchanged.
+
+- **Versions.** The library is 0.8.0, in `package.json` and `python/pyproject.toml`. The Hermes plugin (not published) asks for `provared>=0.4.0,<0.9`, where it asked for `<0.8`, which left 0.8.0 out; the test workflow checks that bound. `examples/frameworks/package-lock.json` gives the library's version as 0.8.0. No other package's range changes: the others' tests run against the repository's own library whatever range they state, and the ranges of the published `provared-mcp-executor` 0.2.0 (`^0.7.0`) and `provared-claude-code` 0.1.0 (`>=0.6.0 <0.8.0`) are left as published, since neither needs anything of 0.8.0. The README, the guide, the Python README and three pages say 0.8.0, and the guide gives the checking page's new fingerprint.
+
+- **The signing page opened as a small window by another page** (the
+  Provared application, which signs nothing itself). `page/sign.html` and
+  `page/sign-page.js` take a request after `#request=` in the address: a
+  new permission, a renewal or a cancellation, with the fields to fill,
+  the earlier signed permission, the passkey's public key, the address to
+  hand the result back to, and a short text handed back unchanged. The
+  page trusts the earlier permission only once the library's checker has
+  confirmed its passkey signature, then shows what the new permission
+  changes against it, part by part. It shows the return address before
+  signing, and warns, asking for a second press, before a new passkey is
+  made, before an agent's key set is signed for the first time on that
+  device, before a passkey other than the earlier one signs, and where the
+  return address is not one of the application's own two addresses,
+  exactly (`https://app.prova.red:8443` and `https://app.prova.red`;
+  `http://localhost` is taken and always warned of). The warnings are
+  worked out again at every press, and a press signs only where every
+  warning that stands then was shown and confirmed; a passkey prompt that
+  fails, or a passkey this browser forgets, takes the confirmation back. A
+  passkey is made only where the warning that one will be made was among
+  those confirmed. Where the browser has forgotten which passkey signed
+  before, the device is asked to offer the passkeys it holds for the
+  website, and what it signs is kept only if the checker passes it with
+  the expected public key. A cancellation is signed only by the passkey
+  that signed the permission, at this page's own website name and
+  address: a request to cancel one signed elsewhere, or with a passkey for
+  another website name (a parent name included), is refused, and a
+  cancellation never makes a passkey. A cancellation for an address that
+  is not the application's asks for a second press too. The signed record
+  is sent by `postMessage` to the exact return address, and the page says
+  it was handed over only once that page answers; it closes once that page
+  answers, from the window that opened it and from the return address
+  exactly, that it kept the record (`{ provared: 'received', kind, state,
+  kept }`), and stays open with the file offered where it says it did not,
+  or says nothing within ten seconds. With no window that opened it, the
+  page offers the file first, then a button that goes back with the record
+  after `#signed=`. A signature that arrives after the permission was
+  changed is not kept. A page shown inside another page still offers
+  nothing.
+- `src/passkey-browser.js`: `signChallengeWithChosenPasskey(challenge,
+  rpId)` asks the device to offer the passkeys it holds for the website,
+  for a caller that checks the answer against the key it expects; the
+  answer of every signing function now names the passkey's identifier
+  (`credentialId`). Every other function still refuses a passkey with no
+  identifier, so that no caller is offered a choice it did not ask for.
+- Tests: `test/sign-request.test.mjs` (the request, the return address,
+  what changed, the messages each way) and `test/sign-window.test.mjs`
+  (the window driven in a browser with a virtual passkey, at phone and
+  desktop width: a new permission, a renewal and a cancellation handed
+  back; the wrong passkey refused; the answer that the record was not
+  kept, and no answer; the way back by a link for all three kinds; a
+  request that cannot be read; a framed page),
+  `test/sign-window-review.test.mjs` (the cases an independent review
+  found, at made-up https addresses: a failed passkey prompt, a passkey
+  forgotten between two presses, a cancellation for a parent website name
+  or another address, a cancellation for an unknown address, a record
+  sent to a page at another address, an answer from another window, a
+  change while the passkey is asked, a cancellation by another passkey)
+  and `test/passkey-browser-guard.test.mjs` (a passkey with no identifier
+  is refused before the device is asked).
+- **After an independent re-check of the signing window, 1 November
+  2026:** once a cancellation asked for by a request has been signed and
+  handed back (or offered to take back by a link), the "sign the
+  cancellation" button stays off: while the page that asked waits, after
+  it says it did not keep it, and after no answer. Before, it was switched
+  on again, and a second press signed a second cancellation with no new
+  warning. The file stays offered; a new request starts the page afresh.
+  Held by `test/sign-window.test.mjs`.
+
+- **`provared-mcp-executor` 0.2.0** (published on npm on 1 November 2026
+  and listed in the official MCP Registry as
+  `io.github.provared/mcp-executor`; the library stays at 0.7.0, and the
+  executor still asks for `^0.7.0`). It carries the rules
+  on the content of a change, below (choices X56 to X77), and names itself
+  for the official MCP Registry: `package.json` gains
+  `"mcpName": "io.github.provared/mcp-executor"`, and
+  `mcp-executor/server.json` describes the package for the registry, with
+  the command line `stdio --config <settings file>` (choices X78 to X81 in
+  `mcp-executor/DESIGN.md`). `server.json` is not in the npm package; the
+  registry's publishing tool reads it from the folder. Beside it,
+  `mcp-executor/demo/` (not in the package): the executor in front of a
+  made-up tool server with two harmless tools, set up on its first start
+  with a permission signed by the library's development stand-in for a
+  passkey, so that a directory of MCP servers can start it with no
+  settings and no secret; a `Dockerfile` on the official `node` image,
+  pinned by digest; its records prove nothing about anyone, as its README
+  says (choices X82 to X89). One new test starts it as a real process.
+  After an independent review (choices X90 to X99): the README and the
+  design say that only an Owner of the organisation may publish to the
+  registry, with a token that can read its members, and only after the
+  npm version is out; the demonstration uses only an empty folder or one
+  it marked as its own, keeps each set-up in a folder of its own and never
+  renames or empties a folder, writes its paths afresh on every start (so
+  it survives a move or a new Node.js), lets two starts at once on an
+  empty folder each set up, says plainly when a folder cannot be written,
+  and its server compares the made-up credential's value; the container
+  is built from four named files, with a packed executor handed over as
+  a context of its own and never copied in. Four more tests. After a
+  second, narrow review (choice X100): an empty mark left by a start that
+  was stopped no longer refuses the folder for good, a file error inside
+  the folder gets the same plain words, and a name that is a file is said
+  to be one. Two more tests.
+- **The MCP executor tests rules on the content of a change before a
+  call is let through** (F-157, F-158; `mcp-executor/rules.mjs`; choices
+  X56 to X70 in `mcp-executor/DESIGN.md`). A permission allows kinds of
+  action; being allowed to change a file is not being allowed to change
+  everything the file controls. The new setting `contentRules` names a
+  JSON file of rules: each names a tool, says which calls it applies to
+  (`when`: conditions on the arguments), where the proposed content is
+  and how to read it (`content`: a JSON Pointer, as JSON text or as plain
+  data) and what must hold in it (`test`: `equals`, `oneOf`, `absent`,
+  `matches` a plain glob, each at a JSON Pointer, with `orAbsent`). A rule
+  with no `test` refuses every call it applies to, which is how a tool
+  that carries only a partial edit is closed: the executor reads no file
+  and keeps no content. A call a rule refuses (`content-rule`), or whose
+  content the rule cannot read exactly (`content-unreadable`: not JSON, a
+  member named twice or twice once folded, a number beyond 2^53 - 1,
+  nothing at the pointer, not text, a text too long to match), is not
+  sent; the model is told which rule and what it asked for, never a value
+  from the arguments, and a denial is written. Every receipt and denial
+  names `executor.rules`, the SHA-256 of the rules file's parsed content
+  in the one form of RFC 8785; a denial by a rule also names
+  `executor.rule`, the fingerprint of the rule's name; both are labels.
+  The person puts the same fingerprint into the permission's
+  `agent.software` (`keys` prints the entry); where the permission states
+  software and the rules in force are not among it, the executor does not
+  start; where it states nothing, it warns. `check` reports the rules and
+  whether the permission states them; `compare` reports which rules
+  fingerprints the records name and whether a slip states each. The
+  README says plainly what the rules can never promise: an edit by
+  another route, a tool whose arguments do not show the resulting file, a
+  file type the executor cannot read, a pattern that matches characters
+  rather than files. Content in YAML, TOML or line-based forms is later
+  work. No record and no rule of the format changes. 12 new tests, among
+  them a label change let through and the same edit with a hidden setting
+  switched on refused.
+  After an independent review (choices X71 to X77): with `unlisted`
+  `forward`, a content rule for a tool that `tools` does not name stops
+  the start, since such a call was sent on before any content rule was
+  tested and the warning said the opposite; a permission whose
+  `agent.software` states rules on content (an entry named `Content rules
+  of …`) stops the start where the settings name no rules file, and
+  `compare` lists the executor's receipts and denials under such a slip
+  that name no rules file (`withoutRules`); a `/` or a `\` in a pattern
+  matches either separator, as promised, so `**/settings.json` matches
+  `C:\proj\settings.json`; a rules file holds at most 20,000 pattern parts
+  in all, which keeps one call to about a quarter of a second where a
+  chosen file took 9.6 seconds; the file is decoded as strict UTF-8; a
+  JSON Pointer with a `~` not followed by `0` or `1` is refused. Four more
+  limits are stated in the README: a `when` value that is not text does
+  not match; a member in other capitals in the content passes an
+  `absent` or `orAbsent` test; a path with a trailing full stop is another
+  text; JSON text inside a JSON string is not read. 7 new tests.
+- **A reader of another project's receipts: Agent Middleware (AMW)**,
+  `integrations/agent-middleware/` (`provared-agent-middleware` 0.1.0, not
+  published): the first of the plan's readers of the closest other
+  projects' receipts. It checks an AMW permit or receipt by the gateway's
+  published Ed25519 key (the key found by `kid`, its status read; an
+  envelope compared with the signed content; AMW's own six answers,
+  reproduced for every one of its 96 published test cases, which are
+  copied into `test/vectors/` under their Apache License 2.0 with a notice
+  of where they came from), maps each verified receipt onto the fields
+  the checker compares (the tool as the action, `credits_charged` as the
+  amount in a unit and scale the reader states, `created_at` as the time,
+  `permit_id` as the permit it names), and judges a set of receipts
+  against a Provared slip that names the AMW gateway in `with`: the
+  checker's own codes where they apply (`action-not-allowed`,
+  `prohibited`, `outside-valid-time`, `over-limit`, `over-each-limit`,
+  `over-count-limit`, `over-period-limit`, `amount-missing`,
+  `approval-missing`), with words that say "AMW receipt"; codes of its
+  own (`amw-permit-…`) where only the AMW permit can be compared; and a
+  stated list of what cannot be judged (no chain, so omission and cut
+  ends do not show; no countersignature; no signature of the person on
+  the AMW permit; approvals by identifier only; which agent; with whom).
+  A denied AMW receipt is shown as the gateway's refusal and never
+  counted against the agent; a receipt that does not verify is not shown.
+  `receiptDocument` carries an AMW receipt by its fingerprint in a
+  Provared receipt's `details` under the name `agent-middleware.receipt`.
+  A command, `provared-agent-middleware verify | judge`, with the
+  checker's exit codes. Written from AMW's published data and the
+  standards alone; no AMW program was read or run. Its tests run in the
+  test workflow beside the other packages.
+- **The AMW reader after an independent review**, each fix held by a
+  test (`test/review.test.mjs`): a slip's countersignature condition, or
+  an approval named by identifier only, is listed on the receipt it
+  applies to (`notJudged`), and such a receipt is never said to be within
+  the slip (`withinSlip` is `null`, not known) nor gives exit code 0
+  (before, both gave "within" and 0); a P-256 key over content that says
+  "Ed25519" reads `unsupported` (before, `verified`); signed text that is
+  not well-formed Unicode, names a member twice in one object, or gives a
+  `kid` that is not text is `malformed`; times are compared to the
+  nanosecond (before, cut to milliseconds, so two receipts 3,599.9996
+  seconds apart fell in different hours); a receipt handed over twice is
+  counted once and listed as a duplicate; a receipt that fails its check
+  shows no identifier (the envelope's is not signed), only its place; the
+  command shows control and invisible characters as a mark, and escapes
+  them in `--json`; `verify` loads no library, and the README's `judge`
+  command works from a copy of the repository; `cannotShow` also states
+  that cancellations cannot be handed over, that outcomes other than
+  success are left out of totals, and that retired keys check receipts
+  of any date. The package no longer pins a development copy of
+  `provared` 0.6.0, which its peer range excludes.
+
+## 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.