git:20260905.4402562 to git:20260905.7aa6da5

- - Follow `docs/publishing.md` for the interactive npm bootstrap and later stage-only trusted publishing. A monotonically greater stable version reaching `main` must automatically enter the exact staging pipeline; an unchanged version must no-op, and manual dispatch remains the current-`main` recovery path. Keep the minimal OIDC job behind the main-only `npm-stage` environment with no required GitHub deployment reviewers, and bind npm trust to that exact environment and stage-only action. CI must stage automatically after verification. Bind the staged artifact to source commit `C`; protected `main` may advance only by proven linear ancestry while the long gate runs, and the terminal job must observe two equal combined main-plus-tag-absence advertisements around that ancestry proof immediately before staging. Human inspection and two-factor approval of the npm stage remain mandatory before the version becomes public. Verify that exact public artifact before creating its tag. Treat a raw `v*` tag as a release request, not a completed release; completed immutable Releases define ordering. Keep the requested tag as a direct lightweight tag on package commit `C`, with protected linear `main` equal to or descended from `C`; the read-only release gate must rebuild and compare the public npm tarball before its sole `contents: write` job creates or verifies the immutable Latest GitHub Release with `make_latest=legacy`. Immediately before tag dispatch, require signed-in administrator readback that immutable Releases are enabled; do not grant Administration to the workflow, and treat the residual setting-toggle window as a trusted control-plane boundary. The Release workflow must never read, create, or update `website-production`, receive the release App key, or wait for Vercel. Load the separate production-promotion workflow from reviewed main source `W`; prove release `C<=W<=M` for protected current main `M`, allowing only linear descendant movement after dispatch; bind its automatic `workflow_run` to Wrench repository ID `1316443113` and Release workflow ID `323493609` plus the exact path, tag-push event, first attempt, success, head repository, tag, and peeled immutable release SHA. Manual recovery on that same main-origin workflow accepts an untrusted stable-tag input and no upstream SHA. Record the complete bounded Vercel Production baseline before any key-environment wait. An already-exact ref must take a separate read-only path with no environment, App variable, private key, token mint, or Git push.

- - A required fast-forward must enter `production-ref-writer-key` with `deployment: false`, reviewer `0thernet`, `prevent_self_review=false`, and no administrator bypass; revalidate source and immutable release authority after approval; and authenticate one private Hraness App. The App registration and every minted token must close to exactly `metadata:read`, `contents:write`, and `workflows:write`, with no Administration or other permission. Workflows write is required because an admitted fast-forward may introduce reviewed `.github/workflows` changes. Runtime must request and validate a token narrowed to Wrench repository ID `1316443113`; privileged setup must separately enumerate the installation-wide selected-repository set and prove it contains only Wrench before key admission. The writer's retained admission proof is workflow run `33691443614`: an ordinary `P` to `C` update was denied, the dedicated App performed the only leased fast-forward, the stale lease was rejected, and token revocation converged to two stable authorization denials. Retain persistent canary `refs/heads/website-production-canary` at exact `C=0bf88a064233635e0c5485c61f9c533974a7dca4`; never reset, delete, or repurpose it. Keep the production lifecycle and App-only update rules mirrored on that ref, keep the single-use canary source removed, and retain the exact run, ref, ruleset, rule-suite, denial, and token-revocation evidence. Keep the production helper hard-bound to `website-production`. Never broaden permissions silently. Scrub every `WRENCH_RELEASE_APP_*` value from read-only `gh` children. Fetch only the exact verified tag through the private askpass token, peel it locally to the independently verified SHA without executing tagged code, and then push that admitted object through the same ephemeral credential boundary with explicit `--force-with-lease=refs/heads/website-production:<expected-old>`. Mask the installation token around that exact fetch and one leased push, then send exactly one empty-204 revocation request and require two stable authorization denials from the exact Wrench installation-repository endpoint inside the reviewed ten-slot, 30-second monotonic operational window before the exact ref post-read. Require canonical GitHub `Date` headers strictly before the minted `expires_at` on that DELETE 204 and every accepted 200 or 401. In the sanitized receipt, `propagationObserved=false` means the first two probes were the stable 401 pair with no observed 200; `propagationObserved=true` means at least one exact 200 preceded the final two stable 401s. Bind that exact bounded object as `releaseAppRevocation` in every advanced `wrench-provider-promotion-v2` receipt, and bind `null` on the separate no-write `already-exact` path. Treat the window as a fail-closed ceiling, not a GitHub propagation SLA; reject a denial that returns to authorization, nonconvergence, indeterminate timing or transport, and any malformed or unexpected response. Never retry the action, retain concurrent operation and revocation failures, and cap the App path at fourteen REST requests. Require bounded read-only jobs to bracket promotion with authenticated GitHub server time, fingerprint the complete current state and `latestStatus` of at most 500 Production deployments, and exhaustively audit only the pinned candidate's REST status history. Reject any retained failure, error, or inactive candidate status even after success. Bind the REST deployment's lowercase commit `.ref` and `.sha` to the verified release while GraphQL reports a null `ref` and the same `commitOid`. Keep 20 observation slots at absolute minute offsets zero through 19 inside one injected monotonic 20-minute `[start, deadline)` interval and a separate 30-minute read-only job. Charge API latency to that window without sliding later slots, and never start a provider read at the deadline. Bind one exact successful Vercel Production deployment plus stable terminal tag, Release, Latest, workflow source, ref, inventory, status, and canonical-host readbacks before promotion succeeds. A verified Production build emits one exact seven-key `/.well-known/wrench-release.json` after its site build, binding the verifier-proven local HEAD and release tag to the strict unique Vercel deployment URL. The provider baseline reads it twice; only exact v0.16.5 may begin from 404. Outcome requires that deployment URL to equal the pinned status URLs, permits only baseline-to-target movement, and finishes with two stable apex marker/health snapshots plus one exact no-follow `www` 308 in each snapshot. Preview and local builds emit no marker. Do not make correctness depend on bypassing Vercel's static cache, and do not make the global receipt depend on previous deployment statuses that GitHub deletes after 90 days; GitHub preserves the current status on the deployment.

- - Before every stable tag push, a signed-in administrator must freshly prove both immutable Releases enabled and one exact active repository tag ruleset targeting only `refs/tags/v*`, with no bypass actors and exact deletion plus update rules while creation remains allowed. Current ruleset `19989752` / `Immutable version tags` is retained evidence; its semantics, not its ID or name, are authority. The Release workflow must not receive Administration permission or call ruleset endpoints. The only manual branch-create exception is the documented one-time Vercel bootstrap at the exact current immutable Latest Release commit. After it, a missing production branch is a hard failure. Live ruleset `21832074` supplies no-bypass creation, deletion, and non-fast-forward protection to the production and persistent canary refs. Live ruleset `21887484` supplies the sole update restriction and exact App `4783991` `Integration` bypass with `bypass_mode=always`; no other actor may update either ref. Incident freeze ruleset `22182820` was removed by captured numeric ID during the audited v0.16.4 production promotion and is historical, not a live control. Checked-in `CODEOWNERS` supplies ownership and notification only. Protect-main has no bypass actors and retains pull-request admission plus the exact Required CI check. Keep its approval minimum at zero and `require_code_owner_review=false` until a second eligible independent code owner exists. Keep Vercel's Production Branch on `website-production`; keep exact project `prj_TZbDZ38ABPan158IqnczgsuTu6Ue`, team `team_UAd1iD2XogJlbFg4h14mRaPM`, GitHub repository ID `1316443113`, `link.productionBranch=website-production`, `autoExposeSystemEnvs=true`, and persistent `autoAssignCustomDomains=true`. False may stage without moving the canonical domains and is never a release-time toggle. Require exact setting-only before/after readback for first enablement and the full persistent project/target/domain preflight thereafter. Ambiguity is readback-only; recovery never blindly reruns, rewrites the ref, or individually aliases a candidate. `main` and pull requests are preview sources, never production website sources.