@typedstandards/verify-core 0.8.0 → 0.9.0

package/CHANGELOG.md

@@ -6,6 +6,76 @@ references are to `npstorey/civic-ai-tools-website` (#119 is the offline-crypto
 hardening arc; #116 is the standalone-verifier arc this package was extracted
 in).
 
+## 0.9.0 — 2026-08-19
+
+Vocabulary settlement (spec v0.1.5 Appendix J; registry Q50/Q66, ADR-0025,
+anchored at `civic-ai-tools#160`). "Evidence" is retired from the artifact and
+infrastructure brand role and retained only for the epistemic
+Question/Evidence/Claim role. **A minor bump** — a new export, no removals, no
+behavior change.
+
+- **`verifyRecord` is the canonical §9.2 entry point.** `verifyEvidence` remains
+  exported as a **deprecated alias**, and it is the same function object
+  (`verifyEvidence === verifyRecord`), not a wrapper — every existing caller
+  keeps working unchanged and gets byte-identical results. The alias is removed
+  no earlier than the next MAJOR version. Migration class `alias-and-deprecate`
+  (Appendix J).
+- Package `description` and one `keywords` entry now say "record packages"
+  rather than "evidence packages"; the README's usage example imports
+  `verifyRecord` and states the alias explicitly. Present-tense references to
+  the entry point in published JSDoc (`VerifyInput`, `lifecycle.ts`) name
+  `verifyRecord`; past-tense historical narration of what the function did at
+  earlier versions is left as written, since it remains accurate.
+- New regression guard in `package-exports.test.ts`: both names must resolve
+  and must be the same function object, so the alias cannot silently become a
+  second implementation or disappear.
+- No wire, algorithm, check-depth, or result-shape change. Already-signed
+  packages are byte-identical and verify exactly as before.
+
+## 0.8.1 — 2026-08-17
+
+- Removed the `prepare` (install-time build) script (typedstandards#39).
+  A fresh `npm ci` at the monorepo root previously failed in workspace
+  `prepare` ordering (produce-core's tsc ran before this package's dist
+  existed), and npm 10.x runs workspace `prepare` even under
+  `--ignore-scripts`. Builds are now explicit (`npm run build:verify-core`,
+  then `npm run build`; CI does the same). Published tarballs are unchanged —
+  `prepublishOnly` still builds at publish — but installing this package from
+  git no longer auto-builds `dist`.
+- Docs only, no behavior change: removed reference-deployment framing from
+  published JSDoc/README (typedstandards#44 P3, findings B10/B11). Four
+  sites — `verifyBlobRef`'s JSDoc, the exported `FetchLike` type's JSDoc, the
+  README's Fetch note, and `trust-registry.ts` — no longer treat
+  civicaitools.org as the rule's rationale or "the platform" as the sole
+  publisher. The plain-GET/no-custom-headers requirement now derives from
+  CORS behavior itself (a custom header triggers a preflight, rejectable at
+  a redirecting host), with the reference redirect kept as a named example;
+  `trust-registry.ts`'s header states its actual contract (pure, registry
+  passed in, loading is the caller's job) instead of pointing at an unshipped
+  server file; each publisher is understood to have its own registry, named
+  by `trustRegistryUrl`. No exported type, signature, or runtime behavior
+  changed — most consumer-visible via `FetchLike`'s JSDoc in the published
+  `.d.ts`.
+- Docs correction, no behavior change: scopes the plain-GET/CORS claim above
+  by execution environment (typedstandards#44 P4). The unscoped version was
+  disproved during a live browser session: a cross-origin redirect response
+  must itself carry CORS headers, or a browser's fetch fails regardless of
+  how simple the triggering request was — a plain GET only avoids the
+  *preflight* rejection, it does not make a redirect chain transparent in a
+  browser. The claim had been verified only from Node/curl, where that
+  constraint does not exist, then stated unconditionally. Now scoped: a
+  plain GET avoids the preflight failure mode (kept, unchanged); a browser
+  additionally needs the redirect response itself to carry CORS headers
+  (the missing half, now stated); server-side/Node fetches follow redirects
+  without that constraint (why the unscoped claim read true when written).
+  Same three verify-core sites P3 touched for this class — `verifyBlobRef`'s
+  JSDoc (`blob-ref.ts`), the exported `FetchLike` type's JSDoc (`types.ts`),
+  and the README's Fetch note — plus the equivalent explanation and its
+  cross-reference in typedstandards.org's client-side verify flow
+  (`apps/web`, outside this published package). No exported type, signature,
+  or runtime behavior changed — consumer-visible via `FetchLike`'s JSDoc in
+  the published `.d.ts` and the README.
+
 ## 0.8.0 — 2026-08-01
 
 - New export: `ED25519_SPKI_PREFIX` (`signature.ts`) — the fixed 12-byte

package/README.md

@@ -1,6 +1,6 @@
 # @typedstandards/verify-core
 
-The portable, **browser-safe** verification core for [Typed Standards][ts] evidence
+The portable, **browser-safe** verification core for [Typed Standards][ts] record
 packages — the spec §9.2 check suite, factored so it runs **identically** on a
 server (e.g. civicaitools.org's verify route) and in the browser (the
 typedstandards.org client-side verifier). One implementation, so a tampered
@@ -34,14 +34,18 @@ edge, and in Node.
   injects its `fetch`, the browser injects `window.fetch`, tests inject a stub.
 
 > **Fetch note.** A `FetchLike` should issue **plain GETs with no custom request
-> headers**. A custom header triggers a CORS preflight, and a preflight `OPTIONS`
-> hitting civicaitools.org's site-wide 307 to its canonical host can be rejected.
-> A simple GET follows the 307 transparently.
+> headers**. A custom header makes the request non-simple and triggers a CORS
+> preflight; a preflight `OPTIONS` against a host that redirects can be rejected
+> there, so a plain GET avoids that failure mode — e.g. civicaitools.org's
+> site-wide 307 to its canonical host. That's necessary but not sufficient in a
+> browser, though: a cross-origin redirect response must itself carry CORS
+> headers, or the fetch fails regardless of the request's simplicity.
+> Server-side/Node fetches follow redirects without that constraint.
 
 ## Usage
 
 ```ts
-import { verifyEvidence, type VerifyInput, type TrustRegistry } from '@typedstandards/verify-core';
+import { verifyRecord, type VerifyInput, type TrustRegistry } from '@typedstandards/verify-core';
 
 const input: VerifyInput = {
   package: pkg,            // the parsed package JSON
@@ -52,7 +56,7 @@ const input: VerifyInput = {
   lifecycle,              // optional sidecar lifecycle state
 };
 
-const result = await verifyEvidence(input, {
+const result = await verifyRecord(input, {
   registry,               // a TrustRegistry (fetched from the package's trustRegistryUrl)
   fetch: globalThis.fetch,
 });
@@ -60,6 +64,14 @@ const result = await verifyEvidence(input, {
 // contentHash, typeResolution, signerIdentity, lifecycle, ...
 ```
 
+> **`verifyEvidence` is the same function.** The 2026-08-19 vocabulary settlement
+> renamed the entry point to `verifyRecord` (spec Appendix J) — "evidence" is
+> retired from the artifact/infrastructure brand role and kept only for the
+> epistemic Question/Evidence/Claim role. `verifyEvidence` is still exported as a
+> **deprecated alias of this exact function object**, so existing code keeps
+> working unchanged and returns identical results. The alias is removed no
+> earlier than the next MAJOR version; new code should use `verifyRecord`.
+
 The barrel (`.`) also exports the individual check functions
 (`recomputePackageHash`, `verifySignature`, `verifyKeyTrust`, `verifyContentHash`,
 …), the canonicalization primitives (`computeEnvelopeHash`,

package/dist/blob-ref.d.ts

@@ -43,9 +43,15 @@ export interface BlobFetchOptions {
  * Fetch a blob and verify that its SHA-256 matches the reference hash and that
  * its byte size matches the metadata. Returns a structured result; never throws.
  *
- * Fetches over HTTPS without auth (Vercel Blob public access is the storage
- * default for evidence content). A plain GET with no custom headers, so it
- * follows civicaitools.org's canonical-host 307 without a CORS preflight.
+ * Fetches over HTTPS with no auth and no custom request headers — evidence
+ * content is expected to be publicly readable, and a custom header would make
+ * the request non-simple, triggering a CORS preflight. A preflight `OPTIONS`
+ * against a host that redirects can be rejected there, so a plain GET avoids
+ * that failure mode — e.g. civicaitools.org's canonical-host 307. That's
+ * necessary but not sufficient in a browser, though: a cross-origin redirect
+ * response must itself carry CORS headers, or the fetch fails regardless of
+ * the request's simplicity. Server-side/Node fetches follow redirects
+ * without that constraint.
  */
 export declare function verifyBlobRef(ref: BlobRef, options?: BlobFetchOptions): Promise<BlobRefVerifyResult>;
 /**

package/dist/blob-ref.js

@@ -1,4 +1,4 @@
-// Content-addressable blob references for evidence package fields (spec §9.2
+// Content-addressable blob references for record package fields (spec §9.2
 // check #9) — browser-safe.
 //
 // Large fields (full output text, trace JSON, composed skill guidance) can be
@@ -56,9 +56,15 @@ function resolveFetch(options) {
  * Fetch a blob and verify that its SHA-256 matches the reference hash and that
  * its byte size matches the metadata. Returns a structured result; never throws.
  *
- * Fetches over HTTPS without auth (Vercel Blob public access is the storage
- * default for evidence content). A plain GET with no custom headers, so it
- * follows civicaitools.org's canonical-host 307 without a CORS preflight.
+ * Fetches over HTTPS with no auth and no custom request headers — evidence
+ * content is expected to be publicly readable, and a custom header would make
+ * the request non-simple, triggering a CORS preflight. A preflight `OPTIONS`
+ * against a host that redirects can be rejected there, so a plain GET avoids
+ * that failure mode — e.g. civicaitools.org's canonical-host 307. That's
+ * necessary but not sufficient in a browser, though: a cross-origin redirect
+ * response must itself carry CORS headers, or the fetch fails regardless of
+ * the request's simplicity. Server-side/Node fetches follow redirects
+ * without that constraint.
  */
 export async function verifyBlobRef(ref, options = {}) {
     let parsed;

package/dist/index.js

@@ -1,4 +1,4 @@
-// @typedstandards/verify-core (in-repo) — the portable, browser-safe evidence
+// @typedstandards/verify-core (in-repo) — the portable, browser-safe record
 // verification core (civic-ai-tools-website#116 WS2).
 //
 // Pure functions over provided data: no `node:crypto` / `fs` / `path` / `process`

package/dist/lifecycle.js

@@ -11,7 +11,7 @@
 // verification logic (factored from the server `verify.ts`). The DB + blob fetch
 // orchestration that assembles the chain stays in the server `lifecycle.ts`,
 // which imports these. WS2's portable orchestrator (`verify.ts` →
-// `verifyEvidence`) consumes lifecycle at STATE depth (the sidecar's
+// `verifyRecord`) consumes lifecycle at STATE depth (the sidecar's
 // status/withdrawnAt/reason) rather than re-running the chain — verifying the
 // signed attestation chain independently in the browser is civic-ai-tools-website#119.
 import { computeEnvelopeHash } from "./canonicalization.js";

package/dist/trust-registry.d.ts

@@ -40,8 +40,8 @@ export interface KeyTrustResult {
  */
 export declare function legacyEmbeddedKeyTrust(): KeyTrustResult;
 /**
- * Verify that a `(kid, publicKey)` pair is trusted by the platform registry,
- * applying the rotation semantics documented in the P5 plan:
+ * Verify that a `(kid, publicKey)` pair is trusted by the registry, applying
+ * the rotation semantics documented in the P5 plan:
  *   - `active` → trusted.
  *   - `deprecated` → trusted only when `packageIntegratedTime` precedes
  *     `deprecatedAt` (preventive rotation — pre-deprecation signatures remain

package/dist/trust-registry.js

@@ -1,16 +1,19 @@
 // Trust registry types + key-trust evaluation (spec §8.3.3, §9.2 check #5) —
 // browser-safe.
 //
-// The platform publishes its authorized signing keys at a `/.well-known/*`
-// registry. Verification treats it as the source of truth for which
-// `(kid, publicKey)` pairs are allowed and their rotation state: keys absent or
-// revoked fail verification regardless of cryptographic correctness — a locally
-// valid signature from an unrecognised key is still not "trusted evidence".
+// Each publisher publishes its own authorized signing keys at a
+// `/.well-known/*` registry, named by the package's declared
+// `trustRegistryUrl`. Verification treats the resolved registry as the source
+// of truth for which `(kid, publicKey)` pairs are allowed and their rotation
+// state: keys absent or revoked fail verification regardless of cryptographic
+// correctness — a locally valid signature from an unrecognised key is still
+// not "trusted evidence".
 //
-// These functions are pure (registry passed IN as data). The server `verify.ts`
-// keeps the registry LOADER (build-time embedded import + fs + fetch fallback,
-// all server-only); WS3's browser client fetches the registry from the sidecar's
-// `trustRegistryUrl`. Both then hand the parsed registry to `verifyKeyTrust`.
+// These functions are pure: the registry is passed IN as already-parsed data.
+// Loading it — however a caller chooses to (a build-time embed, a filesystem
+// read, a network fetch, or some mix) — is entirely the caller's job; this
+// module has no opinion on how a registry was obtained, only on what it means
+// once handed to `verifyKeyTrust`.
 export const KEY_TRUST_STATUSES = [
     'active', // active key — package is trusted
     'deprecated_valid', // deprecated key, but package was signed before deprecation
@@ -30,8 +33,8 @@ export function legacyEmbeddedKeyTrust() {
     return { status: 'legacy_embedded', verified: false };
 }
 /**
- * Verify that a `(kid, publicKey)` pair is trusted by the platform registry,
- * applying the rotation semantics documented in the P5 plan:
+ * Verify that a `(kid, publicKey)` pair is trusted by the registry, applying
+ * the rotation semantics documented in the P5 plan:
  *   - `active` → trusted.
  *   - `deprecated` → trusted only when `packageIntegratedTime` precedes
  *     `deprecatedAt` (preventive rotation — pre-deprecation signatures remain

package/dist/types.d.ts

@@ -24,10 +24,15 @@ export type CaptureMethod = 'chat-flow-stream' | 'claude-code-jsonl-readback' |
  * never reaches for `node:*` or a hardcoded global — see the ESLint
  * `no-restricted-imports` guard scoped to this directory.
  *
- * Per the WS1 prod smoke test: the injected fetcher should issue plain GETs with
- * NO custom request headers (a custom header triggers a CORS preflight, and a
- * preflight OPTIONS hitting civicaitools.org's site-wide 307 to its canonical
- * host can be rejected). A simple GET follows the 307 transparently.
+ * Per the WS1 prod smoke test: the injected fetcher should issue plain GETs
+ * with NO custom request headers — a custom header makes the request
+ * non-simple and triggers a CORS preflight; a preflight `OPTIONS` against a
+ * host that redirects can be rejected there, so a plain GET avoids that
+ * failure mode — e.g. civicaitools.org's site-wide 307 to its canonical
+ * host. That's necessary but not sufficient in a browser, though: per the
+ * Fetch spec, a cross-origin redirect response must itself carry CORS
+ * headers, or the fetch fails regardless of the request's simplicity.
+ * Server-side/Node fetches follow redirects without that constraint.
  */
 export type FetchLike = (input: string, init?: {
     signal?: AbortSignal;

package/dist/verify.d.ts

@@ -48,7 +48,7 @@ export interface CommitmentLifecycleState {
     reinstatedReason?: string;
 }
 /**
- * Everything `verifyEvidence` needs, aligned to the WS1 commitment sidecar +
+ * Everything `verifyRecord` needs, aligned to the WS1 commitment sidecar +
  * the package JSON the sidecar's `packageUrl` resolves to.
  */
 export interface VerifyInput {
@@ -150,5 +150,20 @@ export interface VerifyResult {
  * Run the §9.2 check suite. The step order mirrors the server route exactly
  * (notably: Rekor before key-trust, because a deprecated-key trust decision is
  * time-bounded by the Rekor `integratedTime`).
+ *
+ * Named `verifyEvidence` before the 2026-08-19 vocabulary settlement; that
+ * name remains exported as a deprecated alias of this exact function.
  */
-export declare function verifyEvidence(input: VerifyInput, deps: VerifyDeps): Promise<VerifyResult>;
+export declare function verifyRecord(input: VerifyInput, deps: VerifyDeps): Promise<VerifyResult>;
+/**
+ * @deprecated Renamed to {@link verifyRecord} in the 2026-08-19 vocabulary
+ * settlement — "evidence" is retired from the artifact/infrastructure brand
+ * role and retained only for the epistemic Question/Evidence/Claim role (spec
+ * §6.3, Appendix J; migration class `alias-and-deprecate`).
+ *
+ * This is the SAME function object, not a wrapper: `verifyEvidence ===
+ * verifyRecord`. Existing callers keep working unchanged and get identical
+ * results; the alias is removed no earlier than this package's next MAJOR
+ * version. New code should import `verifyRecord`.
+ */
+export declare const verifyEvidence: typeof verifyRecord;

package/dist/verify.js

@@ -1,6 +1,6 @@
 // Portable verification orchestrator (spec §9.2) — browser-safe.
 //
-// `verifyEvidence` runs the §9.2 check suite over an already-resolved package +
+// `verifyRecord` runs the §9.2 check suite over an already-resolved package +
 // its proofs, returning one structured verdict. It is the SINGLE orchestration
 // both consumers run: the civicaitools.org server route (which injects its
 // `fetch`, its loaded trust registry, and — to preserve its current output — its
@@ -11,9 +11,14 @@
 // test pins this.
 //
 // `VerifyInput` is shaped to align field-for-field with the WS1 commitment
-// sidecar (`buildCommitmentView`) so WS3 can wire sidecar → verifyEvidence with
+// sidecar (`buildCommitmentView`) so WS3 can wire sidecar → verifyRecord with
 // no glue. The server route adapts its DB row to the same shape.
 //
+// The entry point was named `verifyEvidence` before the 2026-08-19 vocabulary
+// settlement (spec Appendix J, migration class `alias-and-deprecate`). That
+// name is still exported, still the same function object, and still works;
+// see the deprecated alias at the bottom of this file.
+//
 // Check depth: fully client-side for #1/#2/#3/#4/#5/#6/#9/#12/#13/#14/#15; #7 (RFC
 // 3161) is PRESENCE (`hasTimestamp`) AND, when a token is present, cryptographic TSA
 // verification against the pinned FreeTSA anchor (civic-ai-tools-website#119 P2a —
@@ -35,8 +40,11 @@ import { resolveLifecycleFromLegacyColumns, } from "./lifecycle.js";
  * Run the §9.2 check suite. The step order mirrors the server route exactly
  * (notably: Rekor before key-trust, because a deprecated-key trust decision is
  * time-bounded by the Rekor `integratedTime`).
+ *
+ * Named `verifyEvidence` before the 2026-08-19 vocabulary settlement; that
+ * name remains exported as a deprecated alias of this exact function.
  */
-export async function verifyEvidence(input, deps) {
+export async function verifyRecord(input, deps) {
     const { package: pkg, packageHash } = input;
     // Step 1 — recompute the envelope hash (checks #1 + #13). Tri-state: a present
     // package recomputes to `verified` / `altered`; a null package is `unavailable`
@@ -180,3 +188,15 @@ export async function verifyEvidence(input, deps) {
         lifecycle,
     };
 }
+/**
+ * @deprecated Renamed to {@link verifyRecord} in the 2026-08-19 vocabulary
+ * settlement — "evidence" is retired from the artifact/infrastructure brand
+ * role and retained only for the epistemic Question/Evidence/Claim role (spec
+ * §6.3, Appendix J; migration class `alias-and-deprecate`).
+ *
+ * This is the SAME function object, not a wrapper: `verifyEvidence ===
+ * verifyRecord`. Existing callers keep working unchanged and get identical
+ * results; the alias is removed no earlier than this package's next MAJOR
+ * version. New code should import `verifyRecord`.
+ */
+export const verifyEvidence = verifyRecord;

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@typedstandards/verify-core",
-  "version": "0.8.0",
-  "description": "Portable, browser-safe verification core for Typed Standards evidence packages — the §9.2 check suite, single-sourced so it verifies identically on a server and in the browser.",
+  "version": "0.9.0",
+  "description": "Portable, browser-safe verification core for Typed Standards record packages — the §9.2 check suite, single-sourced so it verifies identically on a server and in the browser.",
   "license": "MIT",
   "author": "Nathan Storey",
   "type": "module",
@@ -28,7 +28,6 @@
     "clean": "rm -rf dist tsconfig.tsbuildinfo",
     "typecheck": "tsc -p tsconfig.json --noEmit",
     "test": "node --test --experimental-strip-types \"src/**/*.test.ts\"",
-    "prepare": "npm run build",
     "prepublishOnly": "npm run clean && npm run build"
   },
   "dependencies": {
@@ -56,7 +55,7 @@
   },
   "keywords": [
     "typed-standards",
-    "evidence",
+    "record-package",
     "verification",
     "provenance",
     "ed25519",