provared 0.5.0 → 0.6.0

package/CHANGELOG.md

@@ -1,5 +1,987 @@
 # Changelog
 
+## 0.6.0 (25 October 2026)
+
+Version 0.6.0 adds three kinds of record and the services that use them: the denial (the agent's own side states that an action it was asked for was not taken), seals held elsewhere and handed over beside a book, and witness statements beside a seal, with consistency proofs; and, beside the library, a central sealer, a gateway that writes the receipts for agents that cannot be wrapped, and a recorder beside Claude Code that numbers its books and has them witnessed (none of these three programs is published). What a reader of a book made by 0.5.0 or earlier must know: every such book reads as it did, apart from the cases below; but a checker of 0.5.0 or earlier refuses a book that holds a denial, a seal that gives `book`, or a seal that holds `witnesses`, so a book made with these needs a checker of 0.6.0. The fingerprint of a tool call's arguments is now named `provared.arguments` by default, where it was `arguments`; the fingerprint itself is the same. And a checker of 0.6.0 refuses some time-stamps and keys that 0.5.0 accepted, each listed below: a time-stamp that is not strict DER, that names its signing certificate twice in the same form, or that is signed with Ed25519 under a method other than SHA-512 or with parameters; an ES256 key that is not a point on its curve; and an Ed25519 signature whose number S is not below the order L. A passkey and a time-stamp service that follow their standards produce none of these; the sample record gets the same findings and the same exit code from the command-line checker of both versions, and 0.6.0 adds only a line on witnesses and, with `--json`, the empty members for denials and witnesses.
+
+- **The fingerprint of a tool call's arguments is named
+  `provared.arguments` by default**, in both languages (24 October 2026).
+  `recordTools`, `record_tools` and `record_function` name the one
+  document they write by default with the reserved name of section 27 of
+  the format description, where 0.5.0 and earlier named it `arguments`
+  (the default was kept in 0.5.0 so that the published framework packages
+  would not change what they write without a version of their own). The
+  fingerprint is the same; only the name changes, and every checker reads
+  both: one of 0.5.0 or later knows the reserved name, an earlier one
+  reads it as a label. A tool that names its own documents through
+  `details` is unchanged, and so are the recorder beside Claude Code, the
+  gateway and the Hermes plugin, which name their documents themselves.
+  No rule of the format changes. Shared test files: `tool-scenarios.json`
+  and `denial-scenarios.json` are made again; their stored answers differ
+  only in that name, and every record in them is signed afresh. The name
+  comes with the library: a framework package of an earlier version writes
+  the new name too once `provared` is upgraded to 0.6.0. The two published
+  framework packages gain versions that require it, `provared-langchain`
+  0.2.0 and `pydantic-ai-provared` 0.2.0, whose READMEs say what changes,
+  and which can be installed only once `provared` 0.6.0 is published; `provared-agno` (not published)
+  requires 0.6.0 too. The Hermes plugin's bound is raised to below 0.7;
+  it does not use the default. The version in `package.json` and
+  `python/pyproject.toml` is now 0.6.0, so that the packages' bounds hold
+  against the library in this repository. Tests:
+  `test/documents.test.mjs` and `python/tests/test_record_function.py`.
+- **One correction and three smaller changes from a narrow review of the
+  five fixes below (24 October 2026)**, in both languages. None changes
+  the bytes of any record; one widens what a checker accepts back to what
+  services in use write.
+  - *The order of a set is held only where a standard requires DER.* The
+    five fixes held every set the checker reads as a set to the order of
+    X.690, section 11.6, the list of certificates among them. The review
+    found three genuine time-stamps of 2017 from a public service, kept
+    as test data by the open-source Go library digitorus/timestamp
+    (nothing of which is copied here), that list their two certificates
+    in chain order, the signing certificate before its issuer, which is
+    the reverse of DER order: before the five fixes they checked as valid,
+    and the five fixes refused them in both languages. RFC 5652 requires
+    DER of the signed attributes alone, "even if the rest of the structure
+    is BER encoded" (section 5.3). So now the signed attributes (RFC 5652,
+    section 5.3) and every set inside them, the statement (RFC 3161,
+    section 2.4.2) and every set inside it, and each certificate (RFC
+    5280, section 4.1) and every set inside it are held to that order;
+    the signed data's own sets (the list of fingerprint methods, the list
+    of certificates, the list of withdrawn certificates and the list of
+    signers) and the parts of a signer outside its signed attributes may
+    be in any order. Every other rule of strict DER still holds everywhere
+    (format description, section 21.2, item 1, which now names the sets
+    held to order). A test in each language builds a time-stamp with its
+    certificates out of DER order and expects it to pass; the made-up
+    time-stamps are enough for that.
+  - *What is walked under a tag that hides its kind*, said exactly. The
+    five fixes said such a part "is read as bytes only". In both
+    languages a part written in parts under such a tag has the parts
+    inside it read like any other (the review's probe, an `otherName`
+    holding a whole number not in its shortest form, is refused as such);
+    the tagged part itself is only neither refused as a string written in
+    parts nor held to the order of a set; and one written in one piece is
+    read as bytes only. The format description, the code's own notes and
+    the two entries below now say so.
+  - *RFC 5652, section 11*, forbids a second instance, and a second value,
+    of the signing-time attribute too (section 11.3), not of the
+    content-type and message-digest attributes only; corrected below.
+  - *The count of sets in the real time-stamps*, below, was wrong: the
+    sample record holds one time-stamp (`samples/office-supplies.jsonl`,
+    line 10), repeated in its Show, not two; and the four real time-stamps
+    hold 43 sets between them, not 53. Each of the 43 is in DER order, so
+    the five fixes refused none of them.
+  - *Shared test files remade:* `stamps`, `stamps-openssl`,
+    `stamps-flips-ecdsa`, `stamps-flips-ed25519` and `stamps-flips-rsa`.
+    Three stored answers of `stamps` change in substance: "certificates:
+    two certificates out of DER order" and "wrapper: two fingerprint
+    methods listed out of DER order" are now valid, and "wrapper: the
+    signed data that is a set" is refused for its kind, not its order.
+    Fifteen changed-byte cases that tripped the order of a set before
+    anything else (four of `stamps-openssl`, six of `stamps-flips-ecdsa`,
+    three of `stamps-flips-ed25519`, two of `stamps-flips-rsa`) are now
+    refused for what the changed byte does next. Every other difference
+    is a made-up service's fresh key (`stamps-flips-ecdsa` has one case
+    more, its signature a byte longer). A re-check then found the three
+    re-walks held by no deliberate case (weakened, every test still
+    passed), so `stamps` gains three refused cases, each caught in both
+    languages: a message-digest attribute whose second, larger value
+    stands before its first; a relative distinguished name out of DER
+    order inside a certificate; and one inside the statement's name of
+    the service. The JavaScript unit test builds the first of these too,
+    and checks that the list of fingerprint methods may be in any order,
+    as the Python test did. The tests are `test/audit-fixes.test.mjs` and
+    `python/tests/test_audit_fixes.py`.
+- **Five fixes from the independent review of the audit fixes (24 October
+  2026)**, in both languages. None changes the bytes of any record; four
+  narrow what a checker accepts, and one adds to the shared test files.
+  - *Strict DER is now what the checker enforces.* A string of bits, bytes
+    or characters, or a time, written in parts (the constructed form,
+    which X.690, section 10.2, forbids in DER) is refused
+    (`stamp-bad-data`); before, a certificate whose signature was a bit
+    string in two parts passed in both languages. The items of a set must
+    be in the order X.690, section 11.6, requires, where a standard
+    requires DER of the set (narrowed to those places by the review
+    above; as first made, every set the checker read as a set was held to
+    it). Every real time-stamp the repository holds was checked first:
+    the three made with the OpenSSL program (`test/fixtures/stamps.json`)
+    and the one in the sample record (repeated in its Show) hold 43 sets
+    between them, every one in that order. The made-up services of the
+    tests now write their sets in that order, as a real service does;
+    before, the one that makes the shared test files wrote the signed
+    attributes of its SHA-512 cases out of order (format description,
+    section 21.2, item 1).
+  - *A time-stamp signed with Ed25519 gives its fingerprint method and
+    its signing method no parameters*, as RFC 8419, section 3.1, requires
+    (`stamp-invalid`); before, only the method's name was checked, and
+    the made-up services wrote NULL parameters, which that section
+    forbids. The refusal has words of its own that name the cause (a
+    method other than SHA-512, or parameters), where before it said the
+    signature did not fit the certificate. The list of fingerprint methods
+    in the signed data is read for its form only (section 21.2, item 4).
+  - *A second written form of a P-256 key* is in the shared test files:
+    the point with x = 5 and the point with y = 5, each as itself
+    (accepted) and with that half written as 5 plus the prime (refused as
+    `bad-key`), so that a checker that reduced a half instead of refusing
+    it would fail `keys.json`. Before, every case at or above the prime
+    also failed the curve's equation.
+  - *Citations.* The one-instance rule for the signing-certificate
+    attribute is RFC 5035's (section 3 for the newer form; section 5,
+    which writes section 5.4.2 of RFC 2634, for the older), not RFC 5652
+    section 5.3's, which requires DER; RFC 5652 forbids a second instance,
+    and a second value, of the content-type, message-digest and
+    signing-time attributes (sections 11.1 to 11.3) and says nothing of
+    this one. Corrected in
+    the entry below, the format description, the list of threats and the
+    code. The format description now says that using the newer form where
+    both are present, without comparing the two, is this format's choice
+    (section 15, item 22): RFC 5035, section 7, lets a reader refuse such
+    a time-stamp.
+  - *Reach.* "Every bit string in a time-stamp" and "every part is read"
+    now say what the checker reads as such: a value inside an octet string
+    (an extension's value) is read as bytes only, as is a part written in
+    one piece under a tag that hides its kind; one written in parts has
+    the parts inside it read like any other (made exact by the review
+    above).
+  - *Shared test files remade:* `keys` (four cases added: the point of
+    P-256 with x = 5 and the point with y = 5, each as itself and with
+    that half written as 5 plus the prime); `der-strict` (thirteen added,
+    for strings written in parts and sets in and out of DER order; twelve
+    stored answers change: "a constructed octet string", "an unknown
+    constructed tag", which is a character string in parts, and ten random
+    cases are now refused, or refused in other words, for a string in
+    parts or a set out of order); `stamps` (eleven added, among them an
+    Ed25519 service with parameters in each place and sets out of DER
+    order; "attributes: in another order" is now refused as not DER,
+    "signing method: Ed25519 named with parameters" is now refused, and
+    the two Ed25519 cases that name another method have the new words;
+    the "unused bits" cases of a certificate's key are now two each, one
+    with the unused bit zero and one with it set, where before the answer
+    depended on the last bit of a key made at random);
+    `stamps-strict-keys` (the same split of its three "unused bit"
+    cases); `stamps-openssl`, `stamps-flips-ecdsa` and `stamps-flips-rsa`
+    (thirteen, fourteen and fifteen changed bytes of the real and made-up
+    time-stamps now trip the order of a set before anything else, and
+    fifty cases of the RSA set hit other bytes because its signed
+    attributes are now written in DER order); `stamps-flips-ed25519` (the
+    time-stamp is four bytes shorter, its two NULLs gone, so its cases do
+    not compare by name with the earlier set). The reviewer's probes were
+    run again on the fixed code: its 16 ways round the checks and 2,534
+    random cases give the same answer in both languages, words included.
+    The tests are `test/audit-fixes.test.mjs` and
+    `python/tests/test_audit_fixes.py`; each new refusal fails without its
+    fix.
+- **Eight fixes from the audit of the Internet-Draft (24 October 2026)**,
+  in both languages, for version 0.6.0. None changes the bytes of any
+  record. Five narrow what a checker accepts, so that two checkers built
+  from the format description cannot disagree; three change the documents
+  only.
+  - *A time-stamp that names the certificate that signed it more than once
+    in the same form* (two ESSCertIDv2 attributes, or two ESSCertID
+    attributes) is refused (`stamp-invalid`), as RFC 5035 requires
+    (section 3 for the newer form; section 5, which writes section 5.4.2
+    of RFC 2634, for the older). Before, the last ESSCertIDv2 was used or,
+    where there was none, the first ESSCertID. Where both forms appear
+    once each, the newer still names the certificate (format description,
+    section 21.2, item 3).
+  - *A DER bit string whose unused bits are not zero* is not strict DER
+    and is refused (`stamp-bad-data`), as X.690, section 11.2.1, requires;
+    before, only the count of unused bits was checked. A string of no bits
+    must count none. This reaches every bit string the checker reads as
+    such (not one inside an octet string's value, such as an extension's,
+    nor one written in one piece under a tag that hides its kind), not
+    only the key's (section 21.2, item 1).
+  - *An ES256 key that is not a point on the curve P-256*, or either half
+    of which is not below the curve's prime, is refused as `bad-key`
+    wherever a key is checked, before any signature is tried (section
+    3.8). Before, it passed the key check and was reported as
+    `signature-invalid` when a signature was checked under it. A slip, an
+    approval, a cancellation or a vouching record that names such a key
+    now fails on the key.
+  - *An Ed25519 signature whose number S is not below the order L* is
+    refused by the library itself, in every record and in a time-stamp, as
+    RFC 8032, section 5.1.7, requires (section 3.8). Before, both
+    languages relied on the library beneath them (OpenSSL), which refuses
+    it; a third implementation on another library might not. The twelve
+    cases of the paper "Taming the many EdDSAs" (Chalkias, Garillot, Kondi
+    and Nikolaenko, 2020) are a new shared test file,
+    `test-vectors/ed25519-signatures.json`, with ten cases made here, each
+    with the answer the format's rules give, so that the rules are pinned
+    and not the library: a small-order or non-canonical key is `bad-key`;
+    a small-order or non-canonical R, or an S not below L, is invalid; a
+    mixed-order key is checked without the cofactor and may pass.
+  - *A time-stamp signed with Ed25519 must name SHA-512* as the signer's
+    fingerprint method, as RFC 8419, section 3.1, requires; one that names
+    SHA-256 or SHA-384 is refused (`stamp-invalid`), on every device, as a
+    mismatched method is for RSA and ECDSA (section 21.2, item 4). This
+    settles open issue 4 of the Internet-Draft. A service that follows RFC
+    8419 produces nothing else; the made-up service of the tests now does
+    the same, and writes the method with no parameters, as that section
+    also requires (see the entry above).
+  - *The format description* now says that a time-stamp's time is read to
+    the millisecond and compared in milliseconds between seals (sections
+    21.2 and 21.3), which is what the code always did ("taken to the
+    second, rounded down" described only how it is shown); that a checker
+    SHOULD bound the total size of a book it accepts and MAY stop at the
+    first problem, since 100,000 entries of 131,072 bytes would be about
+    13 gigabytes (section 9); and the rules above, in sections 3.8, 14, 15
+    and 21.2.
+  - *The list of threats, section 3,* states a limit the audit found: a
+    passkey used for anything else at the same website is a signing
+    oracle. Any page at an origin under the slip's `rpId` can hand the
+    device a record's fingerprint as an ordinary sign-in challenge and have
+    it signed; the person sees a sign-in prompt. So records should be
+    signed only with a passkey registered to a relying party used for
+    nothing else, and a signing page should show the record first. The
+    checker has no option yet to name the origin a reader expects.
+  - *Shared test files remade:* `keys` (six cases added for P-256);
+    `der-strict` (six added; "a bit string with 7 bits unused" and
+    thirteen random cases now refused); `stamps` (nine added and two
+    removed, the sound Ed25519 cases being remade with SHA-512; the four
+    cases with the signing-certificate attribute twice now refused);
+    `stamps-strict-keys`, `stamps-openssl`, `stamps-flips-ecdsa`,
+    `stamps-flips-rsa` and `stamps-flips-ed25519` (changed bytes that now
+    trip the bit-string rule first; the Ed25519 token names SHA-512);
+    `vouching-contents` and `vouchings-written` (the made-up passkey is
+    now a point on the curve). New: `ed25519-signatures`. The tests are
+    `test/audit-fixes.test.mjs` and `python/tests/test_audit_fixes.py`;
+    each refusal fails without its fix.
+
+- **Witnesses, and consistency proofs** (format description, section 29),
+  in both languages. Whoever keeps a book could show one history to one
+  reader and another to another, each sealed. A witness is a party, with
+  a key set of its own, that keeps for each book the latest seal it has
+  signed for, and signs a statement for a new seal only where the new
+  seal extends that one.
+  - *Consistency proofs*, exactly as RFC 9162, section 2.1.4, sets out:
+    `consistencyProof(leaves, m)` and `verifyConsistency(m, n, rootM,
+    rootN, proof)` (Python: `consistency_proof`, `verify_consistency`).
+    For m equal to n the proof is empty and the roots must be the same;
+    for m of 0 the proof is empty and the earlier root must be that of the
+    empty tree. A second implementation, written in the tests from the RFC
+    alone, is compared with the library's for every pair of sizes up to 64
+    leaves, with every value of every proof changed and left out.
+  - *A new kind of record, the witness statement*: label
+    `vnd.provared.witness.v0+json`, two signatures (Ed25519 and
+    ML-DSA-87), content `type`, `id`, `seal` (the seal's fingerprint),
+    `size` and `root` (repeated from the seal), `by` (`{keys, name}`)
+    and `when`. `writeWitness(fields, signers)` (Python:
+    `write_witness`); signers may be keys or signer objects. There are now
+    twenty-six labels.
+  - *Beside a seal*: a seal's line may hold `witnesses`, 1 to 4
+    statements, none from the same key set twice; and a seal handed over
+    beside the book (`seals`, `--seal`) may hold statements that came
+    later. A checker checks each: its signatures, that it speaks of that
+    very seal (its `seal`, `size` and `root`), and that it is not dated
+    more than 300 seconds before the seal. One new code,
+    `witness-invalid`; it joins the format's own list of finding codes.
+    A statement that does not pass is a problem with its entry, or, handed
+    over, with the whole check (the seal it came with is used all the
+    same).
+  - *Which witnesses count*: the option `witnesses` (the fingerprints of
+    the key sets of the witnesses the person trusts), `--witness
+    <fingerprint>` on the command line (may be repeated), and a box on the
+    checking page. A statement counts only where its witness is named,
+    both its signatures were checked on the device, **the book's first
+    line is a permission that passed, signed by a passkey the person
+    named (`issuerKeys`), the person named the recorders they expect
+    (`sealKeys`)**, and its seal passed with its Ed25519 and ML-DSA-87
+    signatures checked there (its third, SLH-DSA, may not be: the Python
+    version and browsers count on the first two). A witness knows a book
+    only by its permission and its recorder's keys, which the recorder
+    chooses; without both fixed by the reader, a recorder could start a
+    second history with another first line and have the same witness
+    sign for it (found by the independent review). Where a statement
+    from a trusted witness is not counted for that reason, the answer
+    says why. One from a witness not named is shown and not counted.
+  - *What the answer says*: each seal entry, and each seal handed over,
+    gains `witnesses` (each statement with its fingerprint, its witness's
+    key set fingerprint, its name as a label, its `when`, its signatures,
+    `state`, `trusted` and `counted`); the summary gains `witnessed`: the
+    latest seal for which a statement counts, the entries it covers, the
+    witnesses, and every seal witnessed, or null. Where a seal is
+    witnessed, the answer's list of what the check does not show says what
+    a witness shows and what it does not. Being witnessed excuses nothing,
+    is never said of a book with a problem, and is not needed for exit
+    code 0. The command-line checker prints "Witnessed by a witness you
+    trust?".
+  - *The witness itself*, in the library (it needs Node.js, because it
+    checks SLH-DSA): `openWitness({ by, signers, state, clock })`, with
+    `witness(entry, proof, firstLine)`, `update`, `ready`, `latest(book)`
+    and `state()`. It knows a sequence of books by the recorder's key set
+    with the passkey and the agent of the permission on the first line
+    (`bookIdentity`); ties the first
+    line to the seal with an audit path when it first sees a sequence and
+    at each new book, and keeps it
+    tied with each consistency proof (`witnessProof` makes the proof to
+    send); signs only for a seal whose three signatures it checked, which
+    names the seal it holds, is not dated before it, extends it, and is
+    dated no more than 300 seconds after its clock; never signs two
+    different seals of one book at one size (the same seal again gets the
+    same statement); checks every signature it makes before it keeps or
+    gives out a statement; and hands back its state with each statement,
+    to be saved first. Opened from a saved state, it signs nothing until
+    it has been brought up to date from a copy of what it gave out
+    (`update`) and told so (`ready`). A witness running as a service is
+    not part of this change. The Python version has no witness.
+  - The check before acting, the stub writer and a checker that is
+    carried on read statements as a whole check does; a statement's
+    signatures that the device cannot check leave the record not fully
+    checked, as for any record.
+  - *The books of one permission* (format description, section 21.6): a
+    seal may give `book`, its book's number among the books its recorder
+    keeps under one permission (2 or more; absent for the first book, so
+    every seal written before reads as it did; `1` is refused, and a seal
+    with `book` must give `previous`). The first seal of a later book
+    names, as `previous`, the last seal of the book before: a checker of
+    that book alone does not compare it, says so, and, handed that seal,
+    says whether the book follows on from it (`seal-chain-broken` where it
+    is by other keys, `time-went-backwards` where it is dated after the
+    first seal); a seal of another number is not compared by its place.
+    Every seal of a book gives the same number (`seal-chain-broken`).
+    `writeSeal` takes `book` (Python: `write_seal`). The recorder beside
+    Claude Code does not yet number its books.
+  - *The witness keeps every book of one recorder, person and agent as
+    one sequence*: it knows a sequence by the recorder's keys with the
+    passkey and the agent's key set of the permission on the book's first
+    line, so a renewal (another permission from the same passkey to the
+    same agent) is the same sequence, and a book that starts with it must
+    follow on from the seal the witness holds (found by the second round
+    of the review: known by the permission alone, a book that began with
+    a renewal forked the history). It keeps no book whose first line is
+    not a permission (`slip-missing`; a first line given with its line
+    feed is `bad-field`), signs for the first seal of the next book only
+    where that seal names the latest seal it holds and its first line is
+    tied to it, and never again signs for the book before; a fork across
+    books is refused. Its state names each sequence by its passkey and
+    agent. One recorder key set keeps one sequence for each person and
+    agent: books kept side by side for one agent need recorder keys of
+    their own.
+  - *Every permission before a witnessed seal must name the first line's
+    passkey and agent* (found by the third round of the review: a book
+    that started with agent Y's permission, then held agent X's
+    permission and stubs with the one over the limit left out, was signed
+    as the first book of the person and agent Y and read as witnessed).
+    A statement now counts only where every permission among the entries
+    its seal covers names the same passkey key and agent key set as the
+    first line's; otherwise a note says why. A renewal by the same person
+    for the same agent, and each agent's own book under one recorder (as
+    the gateway keeps them), are witnessed as before. A Show counts a
+    statement only where its pages hold every entry the seal covers, so it
+    never counts one the whole book would not. The witness cannot apply
+    this itself: it sees a book's first line, not its entries.
+  - *A seal held elsewhere that gives another book number than the book
+    is not compared with it, and gives no pass* (found by the second
+    round of the review: a book cut short and sealed again as "book 2"
+    otherwise hid the cut). It is not used; its note says what it shows
+    and that this book does not show whether that book was cut short;
+    the command-line checker says "Seals held elsewhere compared? NO" and
+    does not end with code 0, and the checking page gives no green
+    answer.
+  - New shared test files: `tree-consistency`, `tree-consistency-checks`,
+    `witness-contents`, `witnesses-written`, `witness-books`,
+    `witness-shows`, `witness-before`, `seal-books`, `chained-books`,
+    `chained-shows`, `renewal-books`, `renewal-shows`, `two-agent-books`
+    and `two-agent-shows`. **Every stored answer of a whole
+    book, a Show or the stub writer changes**, and only by the new
+    members: `summary.witnessed: null`, and `witnesses: []` on every seal
+    entry and every seal handed over; `denial-constants` gains
+    `witness-invalid`. Eleven files change, each checked case by case to
+    differ in those members alone (`books`, `denial-books`,
+    `denial-constants`, `denial-scenarios`, `denial-shows`,
+    `held-seal-shows`, `held-seals`, `recorder-details-after`,
+    `recorder-scenarios`, `shows`, `tool-scenarios`); no record was
+    signed again.
+  - Section 28's list of finding codes now also names `book-cut-short`
+    and `seal-not-in-book`, which the library already gave.
+  - **A checker of version 0.5.0 or earlier refuses a seal's line that
+    holds `witnesses`** (`unknown-entry`), **and a seal that gives `book`**
+    (`bad-field`).
+- **A witness that runs as a service, and the recorder beside Claude Code
+  numbering its books and asking witnesses** (`integrations/claude-code`:
+  `witness.mjs`, the new command `provared-witness`, `witnessed.mjs` and
+  `proofs.mjs`). The package now needs `provared` 0.6.0 or later.
+  - *The recorder numbers and chains its books* (format description,
+    section 21.6). The first seal of a new book gives the book's number
+    and names the last seal of the book before; its later seals give the
+    same number. "The book before" is the latest kept book whose first
+    line is a permission from the same passkey, for the same agent, sealed
+    with the recorder's keys, as a witness knows a sequence; it is read
+    from the kept files, so the numbers hold across a restart, and a kept
+    book that cannot be read stops the seal rather than give it a number
+    that may be wrong. A book that begins with another passkey's
+    permission begins a sequence of its own, with no number. The first
+    book gives no number, so the record so far reads as it did, and a book
+    whose seals give no number goes on giving none. Before the book in
+    force is first sealed, every kept book a late call could still come
+    back to is closed, and sealed again where something came after its
+    seal; such a call is then recorded in the book in force. Every seal's
+    line is made sure to be on the disk (fsync), and a book is kept as
+    `book-<n>.jsonl` only once it is.
+  - *`provared-witness`*, a small service on 127.0.0.1 (port 8796 by
+    default) around the library's witness (`openWitness`), in a folder of
+    its own: its keys (Ed25519 and ML-DSA-87), a token for the recorders
+    it serves and another for its operator, its settings (`witness.json`:
+    its name, the fingerprints of the recorders it serves, its port and
+    limits), a journal, a state and a checkpoint. For each new statement
+    the journal line and then the state are made sure to be on the disk
+    (fsync) before the statement is given out; what it says it holds
+    (`/latest`, `status`) is what it last saved, never what the library's
+    witness holds in memory, and once anything cannot be saved it gives
+    out nothing more, by any route, until it is started again. Every 256
+    journal lines it writes a checkpoint (the latest seal of each sequence,
+    with its statement) and begins the journal again; a start reads the
+    journal a line at a time, and in full only the lines its state does
+    not yet reflect. At every start, the first included, it signs nothing
+    (`witness-not-ready`) until its operator says that its folder was not
+    put back to an older copy (`ready`, or `start --ready`); `update <book>
+    [--seal <file>]` hands it, from a copy, the statements it signed for a
+    book's seals, and `forget <sequence>` makes it hold a sequence no more
+    (it then signs whatever it is next shown for that sequence). It
+    refuses to start where its journal has gone while its keys are there,
+    where a journal line is not one it writes or lines are numbered out of
+    order, where its state reflects more lines than the journal holds, or
+    where the journal follows a checkpoint it does not have; a last journal
+    line cut off by a stop is taken off; a lost state is rebuilt from the
+    checkpoint and the journal; a stop between the steps of a checkpoint
+    is mended at the next start. One witness at a time on a folder
+    (`witness.lock`, taken over from a process that has ended under a
+    second file only one start can make). Who may ask: a program proves
+    that it holds the token, which never travels, as for the recorder's
+    feed (a hello, then HMAC-SHA-256 over the question, its body included,
+    and over the answer), one question to a conversation; the operator's
+    commands (`status`, `ready`, `update`, `forget`, `stop`) take the
+    operator's token; it signs only for seals of the recorders named, and
+    starts a new sequence only from a permission whose passkey signature
+    the library's checker passes. Limits: 120 new statements in any hour
+    (shared by every recorder it serves), 64 sequences, 8 questions that
+    sign at once, bodies of 1 MiB. Library refusals keep the library's
+    codes.
+  - *The recorder asks the witnesses named in `witnesses.json`* (at most
+    four, each on 127.0.0.1, with the fingerprint of its key set and its
+    token; written by the new commands `add-witness`, which checks that the
+    witness answers, holds the token and signs with that key set, and
+    `remove-witness`). After each seal it asks each witness what it holds
+    and whether it signs now, and shows one that does, in order, the seals
+    it has not signed for whose lines are on the disk, with the proof RFC
+    9162 sets out, made from the book's line fingerprints kept as the book
+    grows (`proofs.mjs`, the same proofs as the library's `witnessProof`
+    without reading the book again), and the book's first line; a witness
+    that holds none of this sequence is shown the latest only. For the
+    seal that `seal` makes, the seal's entry is first kept apart on the
+    disk (`pending-seal.json`, written at its place at the next start if a
+    stop comes first, or let go where its line is in the book or in a book
+    kept since; one at a time), the witnesses are asked, and the
+    statements that come within five seconds stand beside the seal on its
+    line; the wait ends at once when any other request arrives, so no tool
+    call waits for a witness. A statement is taken only where the
+    library's checker passes it for that seal, as signed by the witness
+    named; one that comes later is kept beside the book in
+    `witnessed/<seal>.json`, in the form the checker takes with `--seal`,
+    and `check` hands those of the book checked over, names the witnesses,
+    and says plainly that those copies are the book's own seals from the
+    recorder's folder, not seals held elsewhere, and cannot show the book
+    cut short. A witness that is down, refuses, could not save, or hands
+    back what does not pass never stops recording: `status` shows, for
+    each, the seal it holds, whether that is the latest, and why not; one
+    that holds a seal of this sequence in none of the recorder's books is
+    reported (`witness-holds-another`) and is sent no seal. The record page
+    tool, tried on a numbered book with statements, reads the books as
+    before (it names no witness, and hands over no statement kept beside
+    the book); the application's uploader reads the books through the
+    feed, which is unchanged. Measured on a book of 93.5 MB with four
+    witnesses: a tool call's two questions took at most 67 and 99
+    thousandths of a second after a seal; during any seal a call waits for
+    the seal itself, about 3.3 seconds on such a book, with or without
+    witnesses.
+  - *After its independent review*: a statement that could not be
+    journaled was still given out through `/latest`, and after a restart
+    the witness signed a different seal at the same size (fixed: only what
+    is saved is given out, and nothing once a save has failed); a folder
+    put back to a copy taken before the first statement started ready and
+    signed a fork (fixed: never ready at a start until told); the journal
+    was read whole at each start and could no longer be read at about
+    8,000 lines (fixed: checkpoints, and a line at a time); proofs read the
+    whole book each time (fixed: line fingerprints kept); and the low
+    findings on the seal kept apart, the lock, the agent in the book
+    before, `check`'s words and the passkey signature of a new sequence.
+  - Stated: on one computer under one user account the agent can reach
+    the witness's folder, so a witness means more under another account,
+    on another computer through a tunnel, or run by someone else; a
+    witness on another computer reached directly is not built; what
+    travels is proved, not encrypted; one token serves every recorder the
+    witness serves, and each can read what it holds for any of them, fill
+    its sequences with permissions signed by passkeys of its own, and use
+    up the shared statements; a witness put back to an older copy and told
+    it is ready can be made to sign a fork (a test shows it); forgetting a
+    sequence a recorder still uses lets that recorder have a second
+    history witnessed. 51 new tests in the package (181 in all). Of 61 checks broken in turn, before and after the review, 59 are caught by a test; the two that are not (a stale lock taken without the second file, which only a race between two starts reaches, and the in-time ask kept to a book that passes its check, which no book the recorder holds fails) are stated.
+- **The recorder beside Claude Code offers its books to a reader on this
+  computer, through a feed on its own port** (`integrations/claude-code`,
+  `feed.mjs`), so that no other program need open a book file. On
+  11 October 2026 an uploader reading `book.jsonl` made the recorder's
+  rename of it fail on Windows, and seven receipts were lost; the
+  application's uploader now asks the recorder instead. `GET /books`
+  lists the books oldest first (the kept ones by number, the one in force
+  last), each named by its file's identity (the volume, the file's number
+  and its creation time, which a rename keeps, reckoned as the uploader
+  reckons it), with its size; `GET /lines?id=<identity>&from=<n>` (or
+  `book=<name>`, or neither for the book in force) answers with up to 500
+  lines (and at most 4 MiB) from place n, where each is in the file, the
+  line before place n with its fingerprint, the number of lines and the
+  fingerprint of the last; `max` asks for fewer, and 0 for none. Lines are
+  counted as the uploader and the checker count them (an empty line and a
+  carriage return set aside, a line with no line break not yet a line).
+  Where the book holds nothing at place n yet, the question waits up to
+  25 seconds (`wait`) and is answered as soon as any book is written, a
+  late receipt or a seal again in a kept book included; at most 8 wait at
+  once, and one more is told to ask again (429). The recorder writes a
+  token into its folder at its first start (`feed-token`, 32 random
+  bytes, readable by its owner only where the file system keeps such
+  rights), and **the token never travels**: a reader opens a conversation
+  (`GET /hello`) with a random number; the recorder answers with a random
+  number of its own and HMAC-SHA-256 over both, keyed by the token, and
+  the reader trusts nothing until that proof checks; each question then
+  carries an HMAC under a key both sides work out from the token and the
+  two numbers, with a number used once, and each answer an HMAC under the
+  same key over the question's number, its code and every byte; every
+  proof is compared in constant time, and a question asked twice is
+  refused. Each of these 32-byte values is read only in the one way it can
+  be written in base64url, so none can be given again under another
+  spelling of the same bytes. A hello keeps nothing: the recorder's number for a conversation
+  is worked out from the time, the reader's number and a secret only the
+  running recorder holds, and a conversation is kept only from its first
+  proved question; only proved conversations (at most 16, each ended
+  after 10 minutes unused) give way to one another, so a program without
+  the token cannot push out one in use. Each question, refused or not,
+  still costs the recorder about a thousandth of a second, so very many at
+  once slow the hook in proportion. A token file that holds no token is not replaced, and the feed
+  then refuses every question and `status` says why. One answer is made
+  at a time, with a pause between two, and at most 16 are taken on at
+  once (429 beyond). The books the recorder holds open are read from its
+  own copy in memory, only as far as it has written them to their files,
+  so the feed answers while another program holds `book.jsonl` open with
+  no sharing and never gives out a receipt whose save failed; a kept book
+  it no longer writes is read from its file, 4 MiB at a time, and closed
+  again. Measured on the author's computer with a book of 98 MB: about
+  110 thousandths of a second for the first question, 1.8 seconds to read
+  the whole book; a hook's two questions took a median of 61 thousandths
+  of a second with no reader and of 160 (at most 266) with two readers
+  reading the whole book again and again, and a hook's question 971
+  thousandths with 1,500 feed questions at once. The service still listens
+  on 127.0.0.1 only. Nothing of the record or the format changes.
+- **The recorder never replaces its book because it could not read it**
+  (`integrations/claude-code`). Where another program held `book.jsonl`
+  for a few seconds while a receipt was saved, the recorder took the
+  failed read as "no book yet" and replaced the whole file, which then had
+  a new identity; an uploader following it stopped for good. Now the
+  reading and the adding are tried again for up to ten seconds while the
+  file is busy, a read that fails otherwise fails the save and leaves the
+  file as it is, and the file is replaced only where it was read and no
+  longer holds the book's start. Found by the independent review of the
+  feed, with four faults of the feed itself, each fixed and tested: the
+  token sent to whatever listened (now never sent); questions that do not
+  wait had no limit (on a 98 MB book, 1,500 at once held a hook up for 22
+  seconds); a receipt whose save failed could be given out; and a kept
+  book of exactly 4 MiB that ended part way through a line lost that
+  line's start. A second review found that a hello kept a conversation,
+  so that a program without the token could push out the uploader's (now
+  a hello keeps nothing). Where a save fails after the ten seconds, the
+  hook is now told the truth: the stub is signed and held by the
+  recorder, not yet in the book file, and written with the next save, and
+  `status` counts it as recorded. A third review found that an ended
+  conversation could be begun again under another spelling of its number
+  (now refused), and that no test held the refusal of a hello dated ahead
+  of the clock (now tested). 37 tests of the feed; the package's 130 pass.
+- **Seals held elsewhere, handed over beside the book** (format
+  description, section 21.5), in both languages. Whoever keeps a book
+  could cut off its end, the last seal with it, and what is left still
+  checks. Now anyone who keeps a copy of a seal (the person, an auditor, a
+  second copy out of the recorder's reach) can hand up to 64 of them to
+  the checker, each as the entry it is in the book: the option `seals`,
+  `--seal <file>` on the command line (may be repeated), and a file
+  chooser in the checking page's panel "What you were handed with the
+  record". A seal at entry n must stand at entry n of the book. Two new
+  codes, both problems with the book: `book-cut-short` (the book ends
+  before that place) and `seal-not-in-book` (the entry there is not a
+  seal with the same content; the same content with other signatures is
+  the same seal, and is said). Nothing in a seal names its book, so a
+  seal of another book by the same recorder is reported against the book
+  being checked. Each seal handed over is checked as any seal is, once
+  for a checker that is carried on and for the stub writer; it counts
+  only where its recorder is named in `sealKeys` (`--sealer`), and on a
+  device without SLH-DSA (the Python version, and browsers that have
+  ML-DSA) on its Ed25519 and ML-DSA-87 signatures, which the answer says.
+  Seals handed over without `--sealer` give no pass (code 1), and a line
+  of their own says why, on the command line and on the checking page. One that does not pass its own check is a problem with
+  the whole check. Its own time-stamps are shown, and are not used for the
+  entries of the book; where they differ from those the book holds beside
+  the same seal, the answer says so. A Show does not use seals held
+  elsewhere, and says so. Each one is given in the answer's `held` list,
+  after any cancellations, with `kind: "seal"`, `place`, `inBook`,
+  `sealer`, `used`, `verified`, its signatures and time-stamps; the
+  type declarations give `held` as `(HeldCancellation | HeldSeal)[]`.
+  The check before acting and the stub writer take the option too, and a
+  seal held elsewhere whose third signature this device cannot check is
+  excused there as a seal in the book is. No new kind of record. The two
+  codes join the format's own list of finding codes (`FINDING_CODES`).
+  New shared test files: `held-seals`, `held-seal-shows` and
+  `held-seals-before`; `denial-constants` changes for the two new codes,
+  and no other shared file changes.
+- **A new kind of record: the denial** (format description, section 28),
+  in both languages. It is the agent's own side's signed statement that it
+  did not take an action that was asked for, and who said no: the check
+  before acting (with the finding codes it gave, from the format's own
+  list, now written out in section 28), the person, or a rule of the
+  software around the agent. It is signed with the agent's two keys, or a
+  helper's under its pass, with the new labels
+  `vnd.provared.denial.v0+json` (twenty-four labels in all). In a book it
+  comes after its slip, is in no chain and is compared with nothing; a
+  checker shows it as the agent's side's own word, counts it
+  (`summary.counts.denials`, new in every answer), and never counts it
+  against the agent. `writeDenial` (`write_denial`), `denialCodes`,
+  `FINDING_CODES` and `DENIAL_SOURCES` are new. The stub writer writes a
+  denial whenever `act` does not take an action if it is opened with
+  `denials: true` (`more.denial: false` writes none for one call);
+  `deny` writes one for a refusal from elsewhere; at most
+  `denialsPerHour` (600 by default) are written in any hour of the
+  writer's clock, each counted at the clock's time when it joins the
+  book (whatever date it states), the answers count those left out, and
+  a stub is never kept out. `deny` records what its caller states. `recordTools` and
+  `record_function` pass it on (`NotTaken.denial`), and where the person
+  may yet approve a call they write none until it is known the call will
+  not run, so one call never leaves both a stub and a denial. The
+  command-line checker and the checking page show denials. **A checker of
+  an earlier version refuses a book that holds a denial** (`unknown-entry`).
+  New shared test files: `denial-contents`, `denials-written`,
+  `denial-codes`, `denial-constants`, `denial-books`, `denial-shows`,
+  `denial-before` and `denial-scenarios`; `books`, `shows`,
+  `recorder-scenarios`, `recorder-details-after` and `tool-scenarios`
+  gain `denials: 0` in their stored counts, and nothing else changes in
+  them.
+- **`provared-hermes` 0.1.0, a plugin for Hermes Agent**
+  (`python/integrations/provared-hermes/`): every tool call of a Hermes
+  agent is checked against the slip before it runs, and a stub is
+  written once it has run; a call the slip does not allow is not run,
+  and the model is told why. It runs no recorded call on a Hermes it was
+  not tested with (0.21.7 and later 0.21 versions) unless told to, and
+  it loads on any Hermes so that its own check can refuse. Its commands
+  are named by the same reading of the command text as the recorder
+  beside Claude Code (below), with shared test rows that both languages
+  answer alike. Checked by independent reviewers over eight rounds, the
+  last six with the shared reading of commands, the last three clean;
+  71 tests. Not on the Python Package Index yet: the README gives the
+  command to install it from this repository.
+- **The recorder beside Claude Code reads commands more closely**
+  (`integrations/claude-code/`, not published), with the same reading
+  as the Hermes plugin. A deletion or a publication is now named as one
+  where it sits inside `"$( … )"` or back-quotes in double quotes, with
+  quotation marks, `case` choices and comments inside; after a shell,
+  `eval`, `ssh`, `watch` or another program that runs a command line;
+  in a quoted command after `-c`, `-Command` or `-ArgumentList`; where a
+  program is written as a path; or in text piped or handed into a
+  shell. More publishing and deleting commands are named (among them
+  `gem push`, `helm push`, `dotnet nuget push`, `docker buildx --push`,
+  `rsync --delete`, `DELETE FROM` given to a database client and
+  `redis-cli FLUSHALL`). Quoted words that run nothing, such as a commit
+  message holding `rm`, are no longer named deletions; a back-quoted
+  command in double quotes is, because the shell runs it. On a varied
+  set of 11,340 deleting and publishing lines, none is named less
+  strictly than before; on 109 everyday commands, 2 are named deletions,
+  as before. The longest lines tried (about 900,000 characters) are read
+  in under a second. The README lists what the reading still misses: a
+  command line kept in a file or a variable, `-EncodedCommand`, and
+  others. Writing the book file, the slip and the list of trusted
+  passkeys is retried for up to ten seconds where Windows holds the file
+  busy, and leaves no temporary file behind; a renewal held by a busy
+  file can keep the service waiting about 40 seconds, during which calls
+  are refused, never let through. Checked by an independent reviewer
+  over six rounds, the last three clean; 60 tests.
+- **The recorder beside Claude Code starts a new book at 90,000 entries
+  or 100 MB** (`integrations/claude-code/`, not published). A book holds
+  at most 100,000 entries, and once full every call would be refused. At
+  90,000 entries or 100,000,000 bytes of text, whichever comes first, or
+  on the command `new-book`, the recorder seals the book, keeps it beside
+  the new one as `book-1.jsonl`, then `book-2.jsonl` and so on, and
+  starts a new `book.jsonl` that begins with the permission in force,
+  with no gap in recording; a call that ends during the switch is written
+  into the kept book, which is then sealed again. Every limit is counted
+  across the books, from the kept books' receipts and the calls still
+  running, so a new book, by command, by size or after a restart, starts
+  no limit afresh. A checker given one book still counts limits within
+  that book only, so around a switch the record shown to a checker can
+  hold up to twice a limit within one period across two books, though the
+  agent was held to it. The README states what this does not close: a
+  kept book moved, renamed or removed while the recorder is stopped is
+  no longer counted, and nothing in the record shows it. The record page
+  (`tools/make-record-page.mjs`) lists each kept book with its own
+  checker's answer, and points out a gap in their numbers; the site's
+  publishing run fetches them from the release "record". Checked by an
+  independent reviewer over four rounds; 93 tests.
+- **The recorder beside Claude Code numbers its books, chains each new book
+  to the last seal of the book before, and asks witnesses; and a local
+  witness service, `provared-witness`** (`integrations/claude-code`:
+  `recorder.mjs`, `witness.mjs`, `witnessed.mjs`, `proofs.mjs`; live for the
+  published record since 24 October 2026, 15:38 UTC). A book's number
+  follows the passkey of its first line: a book that holds a seal goes on as
+  its first seal says; one that holds none takes the latest kept book's
+  number and one, where that book began with a permission from the same
+  passkey and its last seal is by this recorder's keys, and its first seal
+  names that book's last seal; where there is no such book it gives no
+  number, so the record so far reads exactly as it did and its next book is
+  book 2. The numbers are read from the kept files, never kept in a file of
+  their own. Before the book in force is first sealed, every kept book that
+  a late call could still come back to is closed and, where something came
+  after its seal, sealed again, so that the first seal of book n names the
+  last seal of book n - 1; a kept book that cannot be read when that seal
+  needs it stops the seal, and the error says why. Every seal's line is
+  made sure to be on the disk, and a witness is shown only such seals. A
+  renewal with a new passkey starts no new book; the next book then begins a
+  sequence of its own.
+  - *Witnesses*: `witnesses.json` names at most four, each
+    `{address, key, token}` at `http://127.0.0.1:<port>`, written by
+    `add-witness` (which reads the token from the witness's token file and
+    checks that the witness answers, holds the token and signs with that key
+    set) and `remove-witness`. After the seal that `seal` makes (the
+    command, `POST /seal` or the service's own) the recorder keeps the seal
+    apart on the disk (`pending-seal.json`) before any witness is asked,
+    shows each witness every seal after the one it holds (at first contact,
+    the latest only), and waits at most five seconds, and no longer than
+    until any tool call arrives; statements that come in time stand on the
+    seal's own line, and every other statement is kept beside the book in
+    `witnessed/<seal fingerprint>.json`. Each statement is checked with the
+    library's own checker before it is kept. It asks again after each seal
+    and every minute while a witness is behind; a witness that holds a seal
+    of this sequence that is in none of the recorder's books is reported
+    (`witness-holds-another`) and asked no more. A seal kept apart that the
+    book changed under while the recorder was stopped is moved aside
+    (`pending-seal-not-placed-<time>.json`) and `status` says so. `check`
+    hands over the kept statements of the seals in the book checked (the
+    latest 64) and names the witnesses of `witnesses.json`, unless `--seal`
+    or `--witness` is given. `status` gains `witnesses`, `witnessesProblem`
+    and `pendingSealProblem`; `seal` answers with `book` and `witnessed`.
+  - *The witness service* (`provared-witness`: `init`, `start`, `status`,
+    `ready`, `update`, `forget`, `stop`) listens on 127.0.0.1:8796 with a
+    folder of its own (`witness-keys.jwk`, two tokens, `witness.json`,
+    `journal.jsonl`, `state.json`, `checkpoint.json`, `journal-mark.json`,
+    `witness.lock`). One token is for the recorders it serves and one for
+    its operator; questions and answers are proved as the feed's are
+    (HMAC-SHA-256 under a key worked out from the token and two random
+    numbers; one question to a conversation). It signs only for the
+    recorders its operator named, by the fingerprint of their key sets, and
+    only after the journal line, then the state, then the mark, are on the
+    disk; after a save that fails it answers 503 until it is started again;
+    at every start it signs nothing until its operator says it is up to date
+    (`ready`), after taking its own journal again, and it refuses to start
+    where the journal has gone while the keys are there, where a line is not
+    one it writes, or where its state reflects more lines than the journal
+    holds. Limits: 120 new statements in any hour, 64 sequences, 8 signing
+    or updating questions at once, bodies of 1 MiB. There is no background
+    start: whoever runs a witness decides how it is kept running. Stated in
+    the README: a witness is only as sound as its folder, and whoever can
+    change it, or put back an older copy whole, can make it forget a
+    sequence.
+  - The package depends on `provared` 0.6.0 or later. Three independent
+    reviews: the first found one serious fault (a statement given out that
+    was never saved, so after a restart the witness could sign a fork) and
+    three medium; the second and third found nothing serious or medium.
+    189 tests, and the three test fixes of 21 October brought across.
+- **`provared-gateway` 0.1.0, a reverse proxy that writes the receipts**
+  (`gateway/`, not published). It sits in front of the web interfaces an
+  agent acts through, holds the agent's keys (in memory or through
+  signers) and each interface's credential, and for every call: checks
+  the agent's own secret, names the call from a rules file the company
+  writes (paths by the WHATWG URL Pattern standard, amounts by a fixed
+  value, a JSON Pointer of RFC 6901 or the length of a list), removes
+  the agent's own credentials from the headers and the address, asks the
+  stub writer's check before acting, sends the call, and writes a stub
+  that names `provared.http-request`, `provared.http-response` or
+  `provared.error`, and the upstream's own identifier where it gives one.
+  A call that is not allowed is not sent, is answered `403` with the
+  checker's words, and is written as a denial; a call that matches no
+  rule is refused by default. A call once sent always gets its stub,
+  whatever the upstream did. An upstream the company runs may
+  countersign. Books are sealed on demand with the recorder's keys
+  (`provared-gateway seal`); `provared-gateway check` says what each rule
+  maps to and what is wrong. Each book is a file appended line by line;
+  the feed to the application is not built. It is the gateway's record
+  only, and proves nothing about calls that do not go through it, as its
+  README says first. An independent review found one serious point: a
+  body naming `hosts` and `HOSTS` was recorded with the first's amount,
+  while an upstream that reads names whatever their case acts on the last.
+  Now a body whose names some readers take as one (differing only in
+  capitals, or in the long s or the Kelvin sign) gives no amount, and the
+  call is not sent. Also from the review: method and address override
+  headers and `_method` are removed, with every `X-Forwarded-*` and the
+  other client-address headers; a `;` in a path is refused unless the
+  upstream allows it, and then the rules match each segment without what
+  follows its `;`; overlong UTF-8 and full-width `/` or `.` in a path are
+  refused; each agent may have only so many calls and bytes waiting; a
+  journal beside each book lets a start find a call that was sent when the
+  gateway stopped, and stops that agent until the administrator
+  acknowledges it (`provared-gateway acknowledge`), when a stub saying the
+  outcome is not known is written; header names with `_` and a
+  `Connection` header that names other headers are refused; more
+  credential headers and query forms are removed; a character set other
+  than UTF-8 gives no amount; a credential that cannot be sent as a header
+  is refused at start; a stub for a call that never reached the upstream is
+  labelled `gateway.not-delivered`; two agents may not share a secret or a
+  book file; and the status answers while a call is out. A second review
+  found two medium points in the journal: one call could get two receipts
+  (a stop between its stub and the journal's "done" line, or an
+  acknowledgement tried again after a failure), and any program that could
+  write the journal could have the gateway sign stubs of its choosing. Now
+  every stub names its call (a label, `gateway.call`), and a start takes a
+  call whose stub the book holds as done; each journal line carries an
+  HMAC-SHA-256 tag under a journal key of the agent's own, and a line
+  whose tag does not check is never acted on; each line is checked against
+  the rules before a stub is written from it; the status shows each
+  waiting line whole; and the administrator can set aside a line
+  (`acknowledge --set-aside`). Also from that review: JSON names are
+  folded beyond ASCII (Greek final sigma, the dotless i and others), so an
+  unrelated `ID` and `id` in one object now give no amount; an encoded
+  character in a path whose NFKC form differs from itself is refused;
+  `provared-gateway repair` takes off a book's last line that a stop left
+  part-written; and two agents may not share a book, a journal, a journal
+  key or a key file. A third review found one medium point: a stub
+  written on acknowledgement went under the slip in force at the restart,
+  not the one the call was sent under. Now each journal line names its
+  slip, and the stub is written under that slip (by a stub writer for it,
+  opened on the same book), or, where the book does not hold it, the line
+  can only be set aside. Also from that review: two agents' files are also
+  compared by each existing file's device and file numbers (a link to
+  the file is followed), so, where the file itself exists, a hard link or
+  a link to the file counts as the same file; a journal that none of its
+  lines checks under the journal key in place stops the start; a
+  journal that holds lines and has lost its key stops the start (each of
+  these two stops the whole gateway, not that agent alone); a line
+  whose rule was taken out can still be acknowledged, with a warning; a
+  clock behind the journal's times is said plainly; calls set aside are
+  kept in a file a clean start does not empty; the library's own checks of
+  a request's fields decide whether a line is usable; the dotted capital
+  `İ` folds with `i`; `repair` takes its byte count only in digits and can
+  put back a lost line ending; and the README lists which honest path
+  forms are refused. 68 tests, all on 127.0.0.1, with a file of 145 calls
+  and the action, amount and service each must map to.
+- **A central sealer** (format description, section 21.7, new; no record
+  changes). The recorder's three keys can now sit apart from the agent,
+  with a party that never sees the book.
+  - *In the library*: `leafFingerprint(line)` (Python:
+    `leaf_fingerprint`), the SHA-256 of the byte 0x00 and one line of a
+    book, refused where the line is empty, holds a line feed, is not
+    well-formed Unicode or is over 131,072 bytes; and `openSealer({by,
+    signers, stamp, state, clock, signWithin})`, which takes the leaf
+    fingerprints of each book's lines (`extend(book, at, leaves)`, only
+    at the place it holds, so a line is never taken twice), keeps the
+    same running tree the checker keeps, and signs a seal over its own
+    number of entries and top fingerprint (`seal(book, {previous})`),
+    through the same keys and signers `writeSeal` takes, each signer
+    given 30 seconds. The seal is the one `writeSeal` signs over the same
+    book, with the same time and unique number. It signs only where
+    `previous`, the seal the caller's book names, is the latest it
+    holds of that book (`not-up-to-date`): a sealer whose state is
+    behind the book signs nothing until it is brought up to date with
+    `update(book, entry, leaves)`, from a later seal it signed and the
+    leaf fingerprints since its own latest seal, which must give that
+    seal's top fingerprint; it is never moved back. `latest(book)` hands
+    back its latest seal, for a book that lost it. A book is known by
+    its first line's leaf fingerprint and its number; a later book names
+    the book it follows, its first seal names that book's last seal, and
+    that book is then closed (also where that first seal is brought in
+    with `update`, which waits, `not-up-to-date`, while the sealer holds
+    that book at an earlier seal than the one named). Every book with one first line is one chain: a book
+    whose first line the sealer holds starts only as the next book after
+    the latest with that first line (`not-next-book`). One sealer may
+    serve several recorders, through `forRecorder(name)`: a book, and
+    every book after it, belongs to the recorder that started it
+    (`other-recorder`). A recorder may be given rules,
+    `forRecorder(name, {agents, books})`: the fingerprints of the key
+    sets of the agents whose permissions it may start books with (an
+    agent belongs to one recorder), and the most books it may hold
+    (`too-large`). Where any recorder has a list of agents, every book is
+    started with its first line itself (`line`, beside `extend`, or
+    `update` for a book brought in), which must be a permission for one
+    of the caller's own agents (`agent-not-allowed`, `other-recorder`);
+    so no recorder can start a book whose first line is a permission for
+    another recorder's agent, nor bring another's book in first after a
+    lost state. The sealer then learns each first line; it does not check the
+    passkey's signature. `releaseUnsealed({recorder})` takes off books
+    that hold no seal, for which nothing was signed. A book started
+    after a book that another book now follows takes no first seal
+    (`book-closed`). Every seal is checked (all three signatures)
+    before it is kept; the state is handed back with a seal, a book
+    started and `update`, to be saved before the answer is given out. Of
+    a seal entry brought in with `update` only the seal, whose three
+    signatures it checks, and its time-stamps are kept, the time-stamps
+    read for their form only (at most four, each at most 12,288 bytes,
+    in base64url, none twice; no time-stamp's signature is checked); its
+    witness statements are not, and an entry longer than a line of a
+    book is refused (`too-large`), so that no recorder can make the
+    state too large to save. The entry is read once, and what is
+    measured, checked and kept is that one copy, so a member that gives
+    another value at each reading cannot slip past the checks. A
+    book is kept in the state at its latest seal, or with none at its
+    first line, so a sealer started again asks for the lines since; at
+    most 1,000 books, about 52 KB of state for each sealed book. With
+    its state kept it never signs two histories of one first line; a
+    book from another permission for the same agent that repeats sealed
+    lines, and a lost or older state, still need a witness. It sees only
+    fingerprints after the first line, so a recorder can start a book
+    from a permission for its own agent, copy into it another
+    recorder's agent's permissions and stubs with some left out, and
+    have it sealed: where one person's passkey signed the permissions
+    for both agents,
+    the book reads as intact and within its slips, and a witness
+    statement on its seal is not counted. A seal of the other
+    recorder's own book held elsewhere shows it (`book-cut-short` or
+    `seal-not-in-book`; where the two books' numbers differ, it cannot
+    be compared, and gives no pass); readers of books from a shared sealer should
+    hold each recorder's own seals elsewhere, or run a sealer for each
+    recorder. It needs SLH-DSA built in, so
+    Node.js; Python has no sealer. `writeSeal` and the sealer share one
+    signing path (`sealOver`, not exported). The tree builder gains
+    `addLeafHash` and `parts` (Python: `add_leaf_hash`).
+  - *A new shared test file*, `sealer-trees.json`: lines or leaf
+    fingerprints, and the number of entries and top fingerprint after
+    each; both languages give every answer.
+  - *`provared-sealer`* (`sealer/`, version 0.1.0, not published): the
+    sealer as a program on 127.0.0.1 (port 8797 by default), with its
+    keys in a file for its owner alone or reached through signer modules
+    named in its settings, a token for each recorder, the agents whose
+    permissions each recorder may start books with and the most books
+    it may hold (100 unless it says; all recorders' books add up to at
+    most 1,000), and one state for every recorder's books, each book
+    bound to its recorder; `release-unsealed` takes off, while it is
+    stopped, the books that hold no seal. A question proves its
+    recorder, and an answer its sealer, with HMAC-SHA-256 under the
+    token over a time, a number used once and the body; the token never
+    travels; each recorder's numbers used once are kept apart, for as
+    long as its question's time could be taken by a clock that never
+    goes back; the recorder's name, the time, the number and a first
+    proof over the body's declared length are checked before the body
+    is read, so no body is read for a program without the token, and at
+    most 16 MiB of bodies being read are held for one recorder. A
+    question waits for its turn as the bytes of its body only, at most
+    16 questions and 32 MiB for one recorder, and its body is read as
+    JSON only in its turn, so one read body exists at a time. A body
+    must be a JSON object, and may hold only the members its path takes
+    (`bad-field`); `connectSealer`, the recorder's side, refuses before
+    sending any member of `more` the path does not take (`id` for a
+    seal among them), so `more` cannot replace `book`, `at`, `leaves`
+    or `entry`, and sends a `when` given as a `Date` as its
+    milliseconds. A question
+    turned away as `busy` keeps no number. Questions are answered one at a
+    time; the state is made sure to be on the disk before an answer to a
+    question that changed it; a seal is never given out before the state
+    that holds it is saved, and after a failed save every question taken
+    up is answered `sealer-stopped` until it is started again. A missing
+    state stops the start, and adding a recorder (`--fresh` begins it
+    again); `add-recorder` refuses a name that has books in the state
+    (a recorder written into `recorders.json` by hand is not checked so); one
+    sealer on a folder at a time. It names no time-stamp service and
+    asks no witness yet.
+
 ## 0.5.0 (17 October 2026)
 
 - **The README's count of review rounds: 50.** The 40 recorded by