@typedstandards/verify-core 0.8.0 → 0.8.1

package/CHANGELOG.md

@@ -6,6 +6,50 @@ 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.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

@@ -34,9 +34,13 @@ 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
 

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

@@ -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/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/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@typedstandards/verify-core",
-  "version": "0.8.0",
+  "version": "0.8.1",
   "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.",
   "license": "MIT",
   "author": "Nathan Storey",
@@ -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": {