0.2.0-alpha.0 publication and recovery
Status
The eight candidate packages were published. The complete verify:release gate passed, but the original workflow failed during registry-propagation verification. Independent registry recovery is verified, and all eight GitHub prereleases and their package-version tags have been reconciled to the release source. This does not turn the original failed workflow into a successful run. Official-site deployment is tracked separately in the Pages deployment history; merging documentation alone does not deploy it.
- Release source:
62955969c35df4beb6a278e65bcea62cd33df526. - Publication run: 37315595525.
- Channel:
alpha; exact candidate version:0.2.0-alpha.0. - Installation and scope: 0.2 alpha guide.
Package graph
| Package | Version | This publication |
|---|---|---|
@vooya/build-core | 0.2.0-alpha.0 | Candidate |
@vooya/preset | 0.2.0-alpha.0 | First publication |
@vooya/provider-rust | 0.2.0-alpha.0 | First publication |
@vooya/react | 0.2.0-alpha.0 | Candidate |
@vooya/rspack | 0.2.0-alpha.0 | Candidate |
@vooya/vite | 0.2.0-alpha.0 | Candidate |
@vooya/vue | 0.2.0-alpha.0 | Candidate |
@vooya/webpack | 0.2.0-alpha.0 | Candidate |
@vooya/core, @vooya/compiler | 0.1.0-beta.0 | Unchanged dependencies |
@vooya/solid, @vooya/svelte | 0.1.0-beta.2 | Unchanged adapters |
Octane remains private and is excluded. This alpha publication does not publish the separate 0.1 maintenance backports or advance existing beta tags.
Failure and preserved baseline
The publication log records successful publication of all eight candidates after the full gate. The subsequent exact-registry check exceeded its propagation window, so the workflow ended in failure. A metadata timeout is not evidence that the packages were never published; do not issue new versions or republish them to work around that outcome.
The original pre-publication latest-before.json has been preserved unchanged. Its SHA-256 is a6851aa452f45e7485c691d624d71eaa3e77301ec5ac3d9002763cb12648bf4e. It is the authority for existing latest, beta and unchanged-package tags; recovery must not recapture or rewrite it after publication. The independent recovery receipt must identify the same source commit and candidate set.
The two previously absent packages, preset and provider-rust, acquired latest alongside alpha on their first publication. Attempts through npm CLI to remove latest returned HTTP 400. A similar observation appears in npm/cli issue #8490; this is not a permanent npm platform guarantee.
This first-publication deviation is recorded separately from the immutable baseline. It does not authorize changing existing package tags or broadly allowing later prereleases to advance latest. The future pre-publication baseline rule is documented in release operations.
Executed registry consumers
Local clean Vue and React applications installed the exact expected registry versions and verified archive provenance, integrity and dependency pins. Both passed doctor, strict generated declarations, Rust Component/Store builds, Chromium interaction and unmount/remount. The transitive provider was resolved through the published dependency graph, not a workspace alias.
A separate local macOS arm64 consumer installed preset and its complete Vooya graph from the public registry, with a fresh npm cache and no packed/workspace runtime fallback. It passed concurrent preparation, managed doctor, ordinary npm run dev, Component/Store browser interaction, Rust editing, deliberate compiler error and recovery, and npm run build. Ambient cargo, rustc, rustup and wasm-bindgen commands were blocked; the host SDK/linker remained available.
The managed Rust cache already existed and was reused. This run is not a fresh Rust download, interrupted-install test, clean-machine certification or a new Windows/Linux registry claim. Fresh-cache platform evidence belongs to the separate named candidate CI jobs. The ordinary Vue/React registry consumer does not cover optional preset behavior; that is why the separate consumer was run. Webpack/Rspack and Solid/Svelte retain their named source-fixture boundaries; metadata checks alone do not establish registry browser coverage for them.
Verified recovery and announcements
The independent verifier passed against fresh metadata for all twelve public packages: exact versions, internal dependencies and protected tags, with only the two first-publication latest exceptions above. Both original GitHub artifact ZIPs were bound to this workflow, source commit and attempt and checked against GitHub's SHA-256 digests; their extracted members matched the preserved evidence. All eight original package tarballs matched registry SHA-512 integrity and the actual downloaded registry tarball bytes. The original baseline was not edited.
The preset alpha.0 GitHub Release contains the sanitized public-receipt.json, verify-recovery.mjs and recovery-summary.md, together with the original baseline, archive-integrity evidence and artifact-provenance evidence. These release attachments are the durable public evidence; local temporary paths are not required to locate them. The public receipt's SHA-256 is be5b73ac9a0d54e2f58f60250379c60da0b7185bc7e3189c6d5021e63af86479. The verifier checks saved consumer evidence rather than rerunning consumers; reproduction also requires the original evidence and GitHub artifact access.
All eight candidate GitHub Releases were separately checked as prereleases, with every package-version tag pointing to 62955969c35df4beb6a278e65bcea62cd33df526. The receipt's registry verification and this announcement reconciliation are separate from the failed workflow.
The frozen published tarballs contain the README text present at the release commit. Subsequent repository documentation corrections do not rewrite those tarballs; no extra package publication is implied by a README edit.
Official documentation
A read-only proxied HTTP fetch of https://vooyajs.com/project/status returned 200 but still described the older alpha.10/eight-package release state. The observation predates the planned post-merge documentation deployment. The existing Cloudflare Pages project is vooya-docs; vooyajs.com and docs.vooyajs.com are active domains. The project has no Git connection, and the dashboard showed its last deployment 43 days earlier when inspected on 2026-10-05. Documentation CI builds the static site but does not deploy it. At this record’s preparation, the post-merge deployment and rendered EN/ZH content checks had not yet run. Record their deployment URL and reviewed commit separately; the stale snapshot above is historical evidence, not a claim that the site must remain outdated.
Manual deployment to the existing project
Use the existing authenticated Cloudflare account and Pages project vooya-docs; its production branch is main. There is no automatic deployment from a Git merge. From the reviewed documentation commit, verify and build first:
npm run verify:docs
npm run docs:build
wrangler pages deploy docs/.vitepress/dist --project-name vooya-docs --branch main --commit-hash <reviewed-full-sha>Replace <reviewed-full-sha> with the full commit actually built. This command shape was checked with Wrangler 4.147.0. Retain the returned deployment URL and commit, then inspect both vooyajs.com and docs.vooyajs.com: EN/ZH home, project status, alpha installation and API pages must render the intended versions and boundaries. A successful upload or docs CI build alone is not this content check. Use the existing domains; do not create another Pages project or change DNS as part of this update.