Prepare useid 1.0.0 rc.2

CHANGELOG.md

@@ -1,5 +1,15 @@
 # Changelog
 
+## [1.0.0-rc.2] - 2026-05-05
+
+`@pyyush/useid@1.0.0-rc.2` republishes the RC after PR review fixes landed on `main`: release-policy checks now run in the tag workflow before publish, shipped docs describe the RC support matrix honestly, and the extraction performance gate was stabilized for Node 20/22.
+
+### Fixed
+
+- Enforced release policy in both verify and publish workflow phases.
+- Stabilized extractor hot-path performance checks used by `release:verify`.
+- Narrowed runtime support to the tested Node 20/22 matrix.
+
 ## [1.0.0-rc.1] - 2026-05-04
 
 `@pyyush/useid@1.0.0-rc.1` is published on npm under the `rc` dist-tag. The npm `latest` dist-tag remains `0.1.0` as of May 5, 2026, so install this release candidate with `npm install @pyyush/useid@rc`.

RC_VALIDATION.md

@@ -1,24 +1,24 @@
 # uSEID RC Validation Handoff
 
-This handoff validates `@pyyush/useid@1.0.0-rc.1` before the stable `1.0.0` release. The RC exists on npm under the `rc` dist-tag and as a GitHub prerelease.
+This handoff validates `@pyyush/useid@1.0.0-rc.2` before the stable `1.0.0` release. The RC is intended to replace `1.0.0-rc.1` on npm's `rc` dist-tag and as the current GitHub prerelease.
 
 ## Version And RC Naming Policy
 
 The repository package version was bumped to `1.0.0-rc.1` in the RC version-bump commit and tagged as `v1.0.0-rc.1`. Later RCs use `1.0.0-rc.2`, `1.0.0-rc.3`, and so on. The release workflow rejects tags that do not exactly match `package.json`, accepts only stable `x.y.z` or RC `x.y.z-rc.N` versions, publishes RCs with the npm `rc` dist-tag, and marks RC GitHub releases as prereleases. The final stable release uses `1.0.0`, tag `v1.0.0`, npm dist-tag `latest`, and a non-prerelease GitHub release.
 
 ## RC Artifact
 
-- RC version: `1.0.0-rc.1`
+- RC version: `1.0.0-rc.2`
 - npm dist-tag install: `npm install @pyyush/useid@rc`
-- explicit npm version install: `npm install @pyyush/useid@1.0.0-rc.1`
-- tarball URL: `https://registry.npmjs.org/@pyyush/useid/-/useid-1.0.0-rc.1.tgz`
+- explicit npm version install: `npm install @pyyush/useid@1.0.0-rc.2`
+- tarball URL: `https://registry.npmjs.org/@pyyush/useid/-/useid-1.0.0-rc.2.tgz`
 - npm integrity: `sha512-G8wvm6PIQlIH0rvhLJNC43pRiGfsKQHiTqyC73YKnhzzlKaZ0aA6ewZDeF73Asds1la7t9s4HgKinBwcfVhxuA==`
 - npm shasum: `e35a3a16386110137f8e116435be9bf9858636c9`
-- Git tag: `v1.0.0-rc.1`
-- GitHub prerelease: `https://github.com/pyyush/useid/releases/tag/v1.0.0-rc.1`
+- Git tag: `v1.0.0-rc.2`
+- GitHub prerelease: `https://github.com/pyyush/useid/releases/tag/v1.0.0-rc.2`
 - Release workflow: `https://github.com/pyyush/useid/actions/runs/25339009937`
 
-`latest` remains `0.1.0`; `rc` points at `1.0.0-rc.1`.
+`latest` remains `0.1.0`; `rc` should point at `1.0.0-rc.2` after the release workflow completes.
 
 ## Release Owner Evidence
 

README.md

@@ -49,17 +49,17 @@ The signature hash is a **capture fingerprint**, not a promise of permanent iden
 npm install @pyyush/useid
 ```
 
-Zero config. One dependency (zod). The `1.0.0-rc.1` package is tested and supported on Node.js 20 and 22, matching CI and release verification.
+Zero config. One dependency (zod). The `1.0.0-rc.2` package is tested and supported on Node.js 20 and 22, matching CI and release verification.
 
 ## Release Status
 
-The npm `latest` dist-tag is verified as `0.1.0` and the npm `rc` dist-tag is verified as `1.0.0-rc.1` as of May 5, 2026. Install the release candidate with `npm install @pyyush/useid@rc`. The examples below describe the `1.0.0-rc.1` API and intended stable contract unless the changelog says otherwise.
+The npm `latest` dist-tag is verified as `0.1.0`; the current release-candidate target is `1.0.0-rc.2` as of May 5, 2026. Install the release candidate with `npm install @pyyush/useid@rc`. The examples below describe the `1.0.0-rc.2` API and intended stable contract unless the changelog says otherwise.
 
 For a first working check in under five minutes with the RC: capture one DOM snapshot plus one accessibility snapshot from your browser tool, choose the intended element from `extractElements()`, call `buildUSEID()`, then call `resolveUSEID()` before taking the browser action.
 
 ## Migration Notes For The 1.0.0 RC
 
-If you are moving from the published `0.1.0` package toward the `1.0.0-rc.1` contract:
+If you are moving from the published `0.1.0` package toward the `1.0.0-rc.2` contract:
 
 - Branch on `result.resolved` before reading success or failure fields.
 - Handle all stable abstention reasons: `binding_mismatch`, `no_candidates`, `below_threshold`, and `ambiguous_match`.
@@ -267,7 +267,7 @@ Use this mapping when a browser-harness-style agent wants safe grounding:
 
 See `examples/grounding-gate.ts` for a browser-harness-facing example that resolves a target only after the uSEID confidence and abstention gate passes.
 
-## What Works Today (`1.0.0-rc.1`)
+## What Works Today (`1.0.0-rc.2`)
 
 | | Supported | Behavior |
 |-|-----------|----------|

package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pyyush/useid",
-  "version": "1.0.0-rc.1",
+  "version": "1.0.0-rc.2",
   "description": "uSEID - Universal Semantic Element ID for stable cross-run element identity",
   "author": "Piyush Vyas",
   "license": "Apache-2.0",