human-machine-swapper 1.0.0 → 1.0.2

package/README.md

@@ -254,19 +254,34 @@ and a Subresource Integrity hash:
 ```html
 <script
   src="https://unpkg.com/human-machine-swapper@1.0.0/src/human-machine-swapper.js"
-  integrity="sha384-REPLACE_WITH_THE_HASH_FOR_THIS_VERSION"
+  integrity="sha384-VetnLEfznYITII6EqUattgN+0Zd72RZXzBhdJjM/mAi6300cT3fUfvg7hN9JeMbH"
   crossorigin="anonymous"
   defer
 ></script>
 ```
 
-Generate the hash yourself, so you are trusting the bytes you checked rather than our word:
+That hash is for **1.0.0**. Every version has its own, so generate the one you are pinning —
+and generate it rather than taking ours, so you are trusting bytes you checked:
 
 ```bash
 curl -s https://unpkg.com/human-machine-swapper@1.0.0/src/human-machine-swapper.js \
   | openssl dgst -sha384 -binary | openssl base64 -A
 ```
 
+### Provenance
+
+From 1.0.2 this package is published by GitHub Actions through npm's trusted publishing, with
+no long-lived token anywhere. Every release carries a signed attestation naming the commit and
+the workflow that built it, so you can check the tarball came from this repo rather than from
+somebody's credentials:
+
+```bash
+npm audit signatures
+```
+
+That is a stronger claim than an integrity hash. A hash says the bytes did not change in
+transit; the attestation says where the bytes came from.
+
 A pinned build does not update, so you take on watching for releases. Self-hosting the file is
 the third option and works identically: it is one dependency-free script with no network calls
 of its own beyond reading your `llms.txt`.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "human-machine-swapper",
-  "version": "1.0.0",
+  "version": "1.0.2",
   "description": "A web component that adds a Human / Machine pill to any website. Machine shows the site's llms.txt, the plain-text reading written for language models, rendered in place. One file, about 6 KB gzipped, no dependencies and no build step.",
   "keywords": [
     "llms.txt",