verifyhash 0.1.1 → 0.1.2

package/docs/ANCHORING.md

@@ -43,11 +43,12 @@ logged), and a chainId outside the known local/testnet set refuses without `--i-
 Exit contract: `0` anchored / `3` named reject (an invalid artifact, or the registry's own revert
 such as `AlreadyAnchored`) / `2` usage / `1` IO-network-key.
 
-`verify-anchored` is **OFFLINE by default** — no key, no network (but it runs through the producer
-`cli/` stack, which loads `ethers`; "OFFLINE" here means **no key and no network**, NOT "no producer
-stack" — the standalone `verifier/` tree does not yet verify anchored receipts, see **Independent
-verification** below): it validates the receipt strictly and **recomputes** the artifact's digest
-through the same closed table; any deviation is a specific named reject (`digest-mismatch` /
+`verify-anchored` is **OFFLINE by default** — no key, no network. The same offline binding leg also
+runs with **zero producer stack**: the standalone `verifier/` tree recognizes `vh-anchored-receipt@1`
+(`verify-vh <receipt> --anchored-artifact <sealed-file>`, see **Independent verification** below), so
+"verify without installing the producer's stack" now covers the receipt too. Either way the check is
+the same: the receipt is validated strictly and the artifact's digest is **recomputed** through the
+same closed table; any deviation is a specific named reject (`digest-mismatch` /
 `kind-mismatch` / `how-mismatch` / `bad-receipt` / the artifact's own named reject). With **both** `--rpc` and `--contract` it additionally authenticates the registry
 (the standing identity probe — no record is believed until the contract self-identifies) and
 re-checks every chain fact the receipt claims. Exit `0` ACCEPTED / `3` REJECTED / `2` / `1` — the
@@ -86,31 +87,51 @@ Spelled out:
   `timestamp-request`/`timestamp-wrap`/`verify-timestamp`) is a third party's *existed-by-genTime*
   attestation. An on-chain anchor (C) complements them; it does not replace them.
 
-## Independent verification — the one axis this does NOT yet cover
+## Independent verification — the anchored receipt verifies standalone too (T-70.4)
 
 The verifyhash family's headline is that a counterparty can verify a sealed artifact **OFFLINE,
 without installing the producer's stack**: the standalone `verifier/` bundle
 ([`../verifier/dist/verify-vh-standalone.js`](../verifier/dist/verify-vh-standalone.js)) is a single,
 dependency-free file — **no `ethers`, no `npm install`** — that re-derives an evidence packet's or
-agent packet's digest by itself. That promise **DOES** cover the **sealed artifact underneath** an
+agent packet's digest by itself. That promise DOES cover the **sealed artifact underneath** an
 anchored receipt: hand a counterparty the `*.vhevidence.json` (or any closed-table artifact) and they
 verify it standalone, exactly as before, with no producer code.
 
-It does **NOT yet extend to the anchored receipt itself.** `vh verify-anchored` — including its
-OFFLINE binding leg — runs **only through the producer `cli/` stack, which loads `ethers` at module
-load** (`cli/anchor-artifact.js` → `cli/core/attestation.js`); and `vh-anchored-receipt@1` is **NOT a
-recognized kind** in the standalone `verifier/verify-vh.js` tree, which scopes itself to sealed
-artifacts and explicitly puts on-chain anchoring out of scope. So the family's zero-install
-"verify without the producer's stack" promise **does not YET reach the anchored-receipt binding
-leg**: a counterparty who wants to check the receipt's binding today must run the producer cli
-(`node cli/vh.js verify-anchored`).
-
-This is a **packaging gap, not a proof gap.** (1) The binding check is pure hashing — the standalone
-verifier already re-derives evidence-seal and agent-packet digests with no `ethers` — so
-`vh-anchored-receipt@1` can be added to the standalone tree to actually close it (tracked as
-**T-70.4**). (2) The `--rpc` chain re-check needs the chain anyway, so the offline binding leg's
-standalone value is limited until then. Until T-70.4 lands: verify the **sealed artifact** standalone
-(zero-install, independent), and verify the **anchor** via the producer cli.
+Since **T-70.4** it also covers the **anchored receipt's OFFLINE binding leg itself**:
+`vh-anchored-receipt@1` **IS a recognized kind in the standalone `verifier/verify-vh.js` tree**. A
+counterparty handed a receipt plus the sealed artifact it anchors checks the binding with zero
+producer code — from this repo, or from the single-file bundle:
+
+```bash
+node verifier/verify-vh.js examples/anchoring/anchored-receipt.local.json \
+  --anchored-artifact examples/anchoring/sample-seal.vhevidence.json
+# zero-install, same command: node verify-vh-standalone.js <receipt> --anchored-artifact <sealed-file>
+```
+
+The standalone validates the receipt strictly (an edited in-band trust note is the named
+`bad-receipt`) and **recomputes** the artifact's digest through the SAME closed kind table the
+producer core uses — each leg re-validating the artifact through a strict, `ethers`-free port of its
+shipped validator, over the verifier's own dependency-free keccak/sha256. The verdicts match the
+producer cli's on the same inputs: ACCEPTED exit `0`, or the specific named reject
+(`digest-mismatch` / `kind-mismatch` / `how-mismatch` / `bad-receipt` / the artifact's own named
+reject) exit `3` — the packaging gap disclosed here before T-70.4 is **closed**.
+
+**Chain-class guidance (so a local-dev receipt is never mistaken for a public proof).** On ACCEPT the
+standalone also classifies the chain the receipt *claims* and surfaces it as a stable, machine-gateable
+part of the `--json` contract — `chainClass` (`local-dev` / `public-testnet` / `unknown`) plus a
+`publiclyMeaningful` boolean (and a leading human-readable `WARNING`/`ADVISORY` line). The offline leg
+cannot (by definition) confirm the digest is actually on-chain, but it *can* tell a counterparty that a
+receipt from a **local dev chain** proves mechanism only and is worth nothing publicly (STRATEGY.md
+**P-2**) — the committed `chainId 31337` fixture is flagged exactly that way. The classification never
+changes the accept/reject decision; it is additive trust context the counterparty's own tooling can
+gate on. The id sets mirror the producer's `cli/anchor.js` known-testnet set (pinned by a drift guard).
+
+**The honest remaining boundary.** The standalone checks the OFFLINE **binding leg only**: the
+receipt's `chain` facts remain the **anchorer's claim** until re-checked against the chain, and that
+re-check needs a chain endpoint by definition — it stays with the producer cli
+(`vh verify-anchored --rpc <url> --contract <addr>`, whose `cli/` stack loads `ethers` at module
+load: `cli/anchor-artifact.js` → `cli/core/attestation.js`). What a receipt proves — and does NOT
+prove — is unchanged either way (see the trust note above).
 
 ## The free line
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "verifyhash",
-  "version": "0.1.1",
+  "version": "0.1.2",
   "description": "Tamper-evident, permissionless on-chain registry of code-contribution hashes, plus an offline data-provenance toolkit (the `vh` CLI).",
   "license": "Apache-2.0",
   "main": "index.js",
@@ -38,7 +38,8 @@
     "!docs/ADOPTION.json",
     "!docs/DECIDE.md",
     "!docs/DEPLOY-PUBLIC-SITE.md",
-    "!docs/AUDIT.md"
+    "!docs/AUDIT.md",
+    "!docs/VENDOR-PROVENANCE.md"
   ],
   "engines": {
     "node": ">=18"

package/verifier/README.md

@@ -403,6 +403,35 @@ self-asserted (the packet's own in-band trust note says the same).
 
 ---
 
+## 2d. Verify an ANCHORED RECEIPT's binding (`vh-anchored-receipt@1`) — zero producer stack (T-70.4)
+
+The producer's `vh anchor-artifact` binds a sealed artifact's ONE canonical digest into an on-chain
+registry record and emits a canonical **`vh-anchored-receipt@1`** container. The receipt's OFFLINE
+**binding leg** verifies here — same zero-install posture, no `ethers`, no producer code:
+
+```bash
+node verify-vh.js receipt.vhanchored.json --anchored-artifact packet.vhevidence.json
+# same flags on the single-file bundle: node verify-vh-standalone.js <receipt> --anchored-artifact <sealed-file>
+```
+
+The receipt is validated STRICTLY (unknown/missing fields, malformed chain facts, or an edited
+in-band trust note are each a named `bad-receipt`), and the sealed artifact's digest is RECOMPUTED
+through the SAME closed six-kind table the producer core uses (evidence seal, agent-session packet,
+journal tree head, TrustLedger reconciliation seal, dataset/parcel attestation — each re-validated
+through a strict, dependency-free port of its shipped validator first). ACCEPT is exit `0`; any
+deviation is the specific named reject — `digest-mismatch` / `kind-mismatch` / `how-mismatch` /
+`bad-receipt` / the artifact's own named reject — exit `3`, matching the producer cli's verdicts on
+the same inputs. On ACCEPT the verdict also **classifies the chain the receipt claims** — `chainClass`
+(`local-dev` / `public-testnet` / `unknown`) and a `publiclyMeaningful` boolean in `--json`, plus a
+leading `WARNING`/`ADVISORY` line — so a receipt from a **local dev chain** (worth nothing publicly,
+STRATEGY.md P-2) is never mistaken for a public proof. **The honest boundary:** this is the OFFLINE
+binding leg ONLY — the receipt's `chain` facts remain the *anchorer's claim* until re-checked against
+the chain, which needs a chain endpoint by definition and stays with the producer cli
+(`vh verify-anchored --rpc --contract`). See
+[`docs/ANCHORING.md`](../docs/ANCHORING.md) for what an anchored receipt proves and does NOT.
+
+---
+
 ## 3. The exact bytes verified, and the scheme
 
 Nothing here is magic; it is two standard primitives you can re-implement in an afternoon.

package/verifier/dist/BUILD-PROVENANCE.json

@@ -5,9 +5,9 @@
     "verify": {
       "bundle": "verify-vh-standalone.js",
       "sidecar": "verify-vh-standalone.js.sha256",
-      "bundleBytes": 199362,
-      "bundleSha256": "371b904b0275ed85606510472570c49a99fc70a5f4e258e7d8fd0e52a26c30bd",
-      "sidecarLine": "371b904b0275ed85606510472570c49a99fc70a5f4e258e7d8fd0e52a26c30bd  verify-vh-standalone.js",
+      "bundleBytes": 247462,
+      "bundleSha256": "6de719e11e3885c733aca329a10e4d25f0dff1e5f24d85934a43b3f766d4c0b0",
+      "sidecarLine": "6de719e11e3885c733aca329a10e4d25f0dff1e5f24d85934a43b3f766d4c0b0  verify-vh-standalone.js",
       "modules": [
         {
           "id": "keccak256-vendored",
@@ -69,8 +69,8 @@
           "id": "verify-vh",
           "synthetic": false,
           "sourceFile": "verifier/verify-vh.js",
-          "sourceSha256": "0e948e5973cd0faf3acda4fb14640feed13fde6190e345b2aea083addeb4b662",
-          "inlinedSha256": "ad89a1d71240c725255633f27f7f3298c8c9718b33eea7c640cae8d62eea8054",
+          "sourceSha256": "35e04d3adc1f66125f282c76553a33d5551f6c9783948d410c6a52ffa401a807",
+          "inlinedSha256": "fd2eb607800118cafc0d5a79c077150cbe9eb03f5de4a8898cbd30031d412ccc",
           "entry": true
         }
       ]
@@ -183,7 +183,7 @@
           "id": "verify-vh-engine",
           "synthetic": false,
           "sourceFile": "verifier/verify-vh.js",
-          "sourceSha256": "0e948e5973cd0faf3acda4fb14640feed13fde6190e345b2aea083addeb4b662",
+          "sourceSha256": "35e04d3adc1f66125f282c76553a33d5551f6c9783948d410c6a52ffa401a807",
           "inlinedSha256": "0e7069b4e04d7602110fed07f90a086822750040054da07335b8bbae16c945c0",
           "entry": true,
           "note": "the marked T-66.1 pure-engine slice of verifier/verify-vh.js (the bytes between its BEGIN/END engine markers), wrapped in a build-generated __require preamble + exports postamble; sourceSha256 pins the WHOLE verify-vh.js source file"