# Workify 0.1.3 release notes

`@newvexa/workify@0.1.3` is the stable promotion of `0.1.3-beta.1`, using production tag `v0.1.3` and npm channel `latest`. The promotion retains the dependency-free TypeScript engine and brings the beta's documentation regression coverage and verified tag-based publishing process to the stable release line.

These notes describe version 0.1.3 and its reviewed changes. Package/CDN availability follows successful tag publication; use registry metadata to confirm installation availability. The historical OIDC evidence section is explicitly scoped to the preceding beta, not reused as a stable artifact checksum.

## What changes from the beta

The version change is `0.1.3-beta.1` → `0.1.3` in `package.json` and both root version locations in `package-lock.json`. README package/CDN links move to the same exact stable version. This release also adds the consolidated changelog entry, these release notes, and README badge work for automated build/test verification and the npm version.

This is a new npm version with its own immutable tarball, not a relabeling or overwrite of the published beta. The beta tarball, integrity, and tag remain historical artifacts. A stable release needs its own tested artifact, checksum, workflow outcome, and registry verification; the beta checksum must not be presented as the stable checksum.

Stable publication through the existing workflow uses `--tag latest`. It does not run a separate `npm dist-tag` operation or retarget `next`. With no separately authorized channel change, the intended result is `latest: 0.1.3` while `next` remains `0.1.3-beta.1`. The beta verification recorded `latest: 0.1.2` and `next: 0.1.3-beta.1`; that earlier snapshot is not a post-stable status claim.[3] [5]

Here, “stable” means a version without a SemVer prerelease suffix and the stable npm channel. The package remains on the `0.x` line; this promotion is not a claim of a new 1.0 API contract or exhaustive production compatibility.

## Changes traced to merged PRs

[PR #1 — documentation regressions and tagged npm publishing](https://github.com/NEWVEXA/workify/pull/1) introduced the source-based documentation test harness, isolated framework test workspace, Node 22/24 CI, release guards, and the split validation/OIDC publishing workflow. It merged on November 3, 2026, at `63177b39c68f00593cbe5090bb9ce83ee71aa911`.[1]

That PR also synchronized the GitHub source baseline with the already-published `@newvexa/workify@0.1.2` metadata, English README, banner, guide, and runnable demo. The earlier repository baseline still used the provisional `workify@0.0.0` identity and lacked those published documentation updates. This source synchronization was not a new publication of 0.1.2, and it must never be used to republish changed bytes under that existing version. The original source commit, `92d973b8ecdd17e82a1e4c7f1b900c2584c7f3bc`, already contained the core and separate HTTP retry example. PR #1 did not change `src/`.[1] [8]

The initial testing/automation commit was `1b8d73f7e45b167a6551efb133f3383342516e9a`. Its follow-up, [a84bf7e — cold-cache documentation consumer fix](https://github.com/NEWVEXA/workify/commit/a84bf7ed610bfa6a0ebfe8a11155bd70975a5efb), made the suite work on fresh hosted runners. Installing a tarball back into the framework workspace with `--offline` could require uncached registry metadata while re-resolving that dependency graph. The corrected runner restores locked framework dependencies separately, installs only the dependency-free candidate tarball into a fresh offline consumer, and exposes that installed candidate with a temporary filesystem link. It preserves both lockfiles and tests the local candidate, not a live registry release.[1] [4] [9]

[PR #2 — 0.1.3-beta.1 OIDC integration prerelease](https://github.com/NEWVEXA/workify/pull/2) changed only package/lockfile versions, version-pinned README links, the changelog, and publishing documentation. The preparation commit was `8ec78840e928457493ab22ccfc4c0d6f23e5379c`; the merge commit was `503bb5f96c315c18405feee175b84a81fe8c72f2`, whose tree matched that reviewed preparation. The beta tag points to this merge commit. Core source, public API, runtime dependencies, MIT license, private repository visibility, and the separately imported HTTP adapter were unchanged.[2]

The stable promotion builds on that beta baseline. The added tests are regression protection and release safety, not new workflow-engine capabilities.

## Validated test baseline

The merged-main and final beta review passed **181 distinct project test cases** with no failures, cancellations, skips, or pending cases: 63 core tests, 13 release-guard tests, 19 simulated HTTP-adapter tests, and 86 documentation tests. PR #1 records passing checks on Node 22.23.4 and Node 24.22.2. The final beta candidate passed again with Node 24.22.2 and npm 11.21.0, matching the publishing workflow toolchain.[1] [2]

Stable validation adds **eight badge/check-wrapper cases**, for **189 distinct project cases** overall: 63 core, 13 release guards, 19 HTTP, 86 documentation, and eight badge cases. The final candidate is checked with Node 24.22.2 and npm 11.21.0, matching the publication toolchain. Counts come from actual successful summaries; repeated release-guard invocations do not create extra distinct cases. The version-pinned public validation record contains the per-suite results.

### Core and release safety

The core suite covers graph and metadata validation, immutable descriptor capture, JSON boundary validation and copying, If/Else and Switch routing, fan-out/fan-in and input ordering, inactive versus blocked branches, isolated node/link failures, the shared concurrency budget, cancellation and draining, state/events/history, and descriptor search.[6]

The release-guard suite checks full SemVer parsing and tag syntax, explicit stable/prerelease channels, package identity, lockfile synchronization, dependency/export boundaries, safe archive paths, checksum/integrity preservation, and registry failures. It verifies that an identical already-published version is an immutable no-op, that different bytes at the same version fail, and that authentication/network/server problems are never mistaken for version absence.[1] [5]

### Documentation and packed consumers

All **18 executable README/API-guide snippets** are registered and extracted directly from Markdown: 17 TypeScript snippets compile with strict checks against the installed tarball's declarations, and one CommonJS snippet is checked at runtime. Shipped TypeScript, framework, and HTTP examples are type-checked separately. Strict settings include `noUncheckedIndexedAccess`, `exactOptionalPropertyTypes`, and declaration checking without `skipLibCheck`.[1] [4]

Behavioral coverage includes the import-safe quick-start factory and the explicit demo's `succeeded`/`42` output; invalid business shapes versus invalid JSON; transforms and abort propagation; present null/falsy values and the exact routing threshold; observer cleanup on success and rejection; status history without payloads or replay; guide error handling; cancellation/draining; search filters; and priority/standard order branches. Structure checks protect snippet registration and extraction, local anchors, package files, exact-version README pins, ESM/CommonJS availability, and the dependency-free core boundary.[4]

The beta artifact audit resolved 28 package documentation links without errors or warnings and compared 31 runtime/declaration/map files byte-for-byte with the published 0.1.2 package. That establishes the beta's reviewed runtime baseline; it is not a claim that the entire beta tarball equals 0.1.2, a comprehensive secret scan, or a substitute for final stable artifact review.[2]

### Actual framework lifecycles, with defined limits

Framework dependencies are exact-version locked in the separate private `tests/docs` workspace: React 19.3.1, Vue 3.5.44, and Angular 22.2.4, with their required test dependencies. They are not runtime or peer dependencies of Workify.[1] [4]

React checks exercise real renderer mount/update/unmount behavior, stable subscriptions, explicit component actions, and server rendering of the complete hook with a consistent server snapshot. They also verify that the minimal client-side README hook requires a server snapshot for SSR. Vue checks use real active effect scopes, state updates, overlap guards, disposal cleanup, and cancellation/draining of an owned run. Angular checks use actual injection, signals, independent view injectors, busy/cancellation behavior, and `DestroyRef` cleanup with the compiler loaded for JIT.[4]

These are not real browser DOM/hydration tests, a full browser-mounted Vue application, or Angular template AOT tests. They do not guarantee every browser or framework version. The original v0 report's Bun and Chromium checks remain historical validation; they were not rerun by this documentation suite or established anew for the stable candidate.[4] [6]

### Preserved HTTP adapter

The existing `createApiNode` HTTP example remains separately imported and is not exported by the core entry. Its 19 simulated tests cover transient-status handling, idempotency restrictions and stable request bodies, timeouts through response-body reading, cancellation, retry backoff, `Retry-After`, and JSON parsing. No external HTTP service is contacted by those tests.[1] [7]

Timeouts, exponential backoff/jitter, and HTTP retries are policies of that example, not automatic engine behavior. A timeout or cancellation does not guarantee that a remote server rolled back an operation. Retrying POST/PATCH requires an explicit provider-backed idempotency contract; an idempotency header alone is not such a guarantee.[7]

## First live OIDC publication evidence

The beta's [Publish npm package run 41723649529](https://github.com/NEWVEXA/workify/actions/runs/41723649529) completed successfully for the push of `v0.1.3-beta.1` at `503bb5f96c315c18405feee175b84a81fe8c72f2`. Both jobs succeeded, including the actual “Publish only an absent version using npm trusted publishing” step. This was a real beta publication, not a dry run or an identical-version no-op.[3]

The release review verified the downloaded CI tarball against the publicly served beta tarball. Both matched SHA-256 `5a314c88ad25769d561f5824d8878af67e5bc456d7943745cb3487d59121039e`. Fresh-cache registry installs exercised ESM and CommonJS consumers; both ran the documented workflow with status `succeeded` and output `42`. The beta banner, API guide, testing guide, publishing guide, HTTP guide, and demo were available through version-pinned CDN URLs with HTTP 200. Verification completed on November 3, 2026, at 21:43:11 UTC.[10] [11]

The reviewed trusted publisher reported **Valid** after that first live publish and is bound to `NEWVEXA/workify`, workflow filename `publish.yml`, and environment `npm`. The environment permits `v*` deployment tags and had no branch policy or npm secret. Trust allows direct `npm publish` together with the platform's default staged-publish permission; separate dist-tag management remains disabled. Existing two-factor/token-access policy and private GitHub visibility were preserved.[5] [12]

Only the publish job receives `id-token: write`; validation and PR/main CI do not. Publication has no npm token or manual-publish fallback. Because the GitHub repository is private, the workflow disables npm provenance for this repository. Successful OIDC authentication is not a claim that public source provenance is available.[5]

## README badges

Stable preparation adds publicly served generated SVG build/test badges and a JSON verification record under `assets`. The README pins their URLs to the package version and links them to that public record. They describe validation of the published version, not the continuously changing state of `main`. GitHub's native workflow badge for a private repository is inaccessible to external viewers; this approach does not change repository visibility or expose private CI through a native badge.

The `npm run check` wrapper retains every existing stage: `typecheck`, `test`, `test:http`, and `test:docs`. It writes pending/failed states before successful completion and may emit passed build/test states with derived counts only when all real checks pass. The generated verification files are npm-allowlisted, and the release guard validates the declared badge evidence. The generator and wrapper are Node-only development/release helpers outside the isomorphic core, not new runtime imports or package APIs. Eight additional regression cases cover summary parsing, invalid counts, pending/failed states, stale versions and tampering, deterministic accessible SVG, successful stage order and fail-closed orchestration. Normal `npm pack` now runs the full check; standalone documentation tests prepare neutral records rather than claiming all checks passed. The OIDC job checks both the passing record and its matching SVG without installing project dependencies or running package lifecycle scripts.

The existing live npm-version badge is retained with an updated style. Its value comes from registry metadata rather than the release verification record; until the stable channel moves, it may still display 0.1.2. Public build/test badges must be honestly labeled **release-verified**, and badge caching is never publication evidence. The beta receipt does not establish stable badge values, stable test counts, or successful stable publication.

## Install or upgrade after stable publication

After the stable publication is confirmed, install or upgrade to the exact release:

```sh
npm install @newvexa/workify@0.1.3
```

Alternatively, `npm install @newvexa/workify@latest` selects the stable channel after `latest` has been verified to point to 0.1.3. Do not use `@next` to select stable if that tag remains on the beta. Always use the scoped name `@newvexa/workify`; the unscoped `workify` package belongs to another publisher.

No migration of the documented public API is expected from 0.1.2 or 0.1.3-beta.1. ESM imports and CommonJS `require` keep the same scoped entry, and the package continues to ship declarations for both module formats. No forced cache cleanup, deletion of `node_modules`, lockfile removal, framework migration, or application-state reset is required by this promotion. Update the dependency through your normal package-manager workflow, review the resulting dependency/lockfile diff, and run your application's checks.

The included zero-build demo remains an explicit opt-in smoke check:

```sh
node ./node_modules/@newvexa/workify/examples/run-quick-start.mjs
```

Its expected output is `succeeded` followed by `42`. Importing the example factory alone starts no work; the demo and factory are shipped examples, not core exports.[4]

After publication, use the version-specific [npm page](https://www.npmjs.com/package/@newvexa/workify/v/0.1.3), [API guide](https://unpkg.com/@newvexa/workify@0.1.3/docs/guide.md), [testing guide](https://unpkg.com/@newvexa/workify@0.1.3/docs/testing.md), [publishing guide](https://unpkg.com/@newvexa/workify@0.1.3/docs/publishing.md), and [changelog](https://unpkg.com/@newvexa/workify@0.1.3/CHANGELOG.md). These stable destinations are forward-looking until registry/CDN verification is complete; their inclusion here is not an availability assertion.

## Future authorized release process

1. Prepare a new version through a reviewed change on `main`. Synchronize `package.json`, the root lockfile's top-level and root-package versions, README package/CDN pins, and release documentation. Keep the scoped identity, MIT license, documented exports, and dependency-free core boundary intact unless a separately reviewed change intentionally revises them.
2. Run `npm ci` and `npm run check` on the final candidate. Retain core, release-guard, HTTP-example, and documentation checks, including any new stable-preparation tests. Confirm the candidate package contents, imports, declaration consumers, link targets, and honest badge values. Record the actual results rather than copying beta totals.
3. After the release is explicitly authorized and the matching trusted publisher/environment are confirmed, push the exact matching `v*` tag to a commit already in `origin/main`. Version `0.1.3` requires `v0.1.3`; a future `0.2.0-rc.1` requires `v0.2.0-rc.1`. A matching tag triggers a real public publish, not a dry run. Do not move an existing release tag or reuse a published version for different bytes.
4. Let `publish.yml` validate the tag and metadata, run the project checks, pack and smoke-test the checked distribution, and hand the exact same-run artifact to the isolated OIDC publish job. The publishing job verifies the artifact identity and checksum, then checks the public registry. Stable versions target `latest`; prereleases target `next`. npm-incompatible release build metadata is rejected, and a new release cannot move its target channel backwards or sideways.
5. Verify the completed publish step, registry version/integrity and dist-tags, fresh-install ESM/CommonJS behavior, and version-pinned README/CDN assets. Record the new release's own run URL, hashes, test results, and publication time before claiming availability or updating release-verified badges.

The pipeline serializes releases and fails closed on registry/authentication/network errors. An existing version is skipped only when its integrity exactly matches the tested tarball, with existing dist-tags left unchanged. A rerun is safe only if it recreates identical bytes; changed bytes intentionally fail rather than overwrite a version. Inspect a failed run before retrying, and do not add a token fallback or broaden trust to compensate for a configuration error.[5]

## Compatibility and remaining limits

The promotion does not change the core TypeScript source, documented public API, module entry points, runtime dependencies, MIT license, or private repository visibility. Workify remains a headless ES2022 DAG engine using standard `Promise` and `AbortController`/`AbortSignal` APIs. Framework adapters, example factories, and Node-only integrations remain separate application-level code, not hidden core dependencies or newly exported APIs.[1] [2] [4]

Cancellation is cooperative. The engine stops new starts and forwards its signal, but cannot kill an arbitrary promise or undo an external effect. It permits one active run per instance, including the draining period; await the original run before reusing that engine. Unsubscribing an observer is not cancellation.[6]

History contains bounded status metadata and immutable snapshots, not business payloads, durable storage, or effect replay. `historyLimit` bounds entries rather than bytes. Recursive JSON validation/copying is not intended for unbounded payload nesting, and synchronous CPU work still blocks the event loop. No new performance benchmark or scalability guarantee is claimed.[6]

The core still excludes cycles, persistent scheduling, storage/resumption, distributed execution, automatic retries, a visual editor, and replay of external effects. Applications remain responsible for domain schemas, authorization, secrets, external side effects, and adapter resource cleanup. The framework and historical portability limitations above remain applicable to this stable promotion.[4] [6] [7]

## References

GitHub PR, commit, and Actions links require authorized access to the private repository. The version-pinned beta documentation provides publicly served context without changing repository visibility.

[1]: https://github.com/NEWVEXA/workify/pull/1 "Merged PR 1: documentation regressions, source synchronization, and tagged npm publishing"
[2]: https://github.com/NEWVEXA/workify/pull/2 "Merged PR 2: approved 0.1.3-beta.1 metadata preparation and validation"
[3]: https://github.com/NEWVEXA/workify/actions/runs/41723649529 "Successful first live beta tag-triggered OIDC publishing run"
[4]: https://cdn.jsdelivr.net/npm/@newvexa/workify@0.1.3-beta.1/docs/testing.md "Beta-pinned documentation regression testing guide and scope limits"
[5]: https://cdn.jsdelivr.net/npm/@newvexa/workify@0.1.3-beta.1/docs/publishing.md "Beta-pinned tagged publishing workflow, guard behavior, and trust configuration"
[6]: https://unpkg.com/@newvexa/workify@0.1.3-beta.1/docs/validation-v0.md "Preserved historical Workify v0 validation report and engine limits"
[7]: https://cdn.jsdelivr.net/npm/@newvexa/workify@0.1.3-beta.1/examples/http/README.md "Preserved separately imported HTTP retry adapter and simulated test scope"
[8]: https://github.com/NEWVEXA/workify/commit/92d973b8ecdd17e82a1e4c7f1b900c2584c7f3bc "Original repository core and HTTP retry example baseline"
[9]: https://github.com/NEWVEXA/workify/commit/a84bf7ed610bfa6a0ebfe8a11155bd70975a5efb "Merged cold-cache documentation consumer installation fix"
[10]: https://www.npmjs.com/package/@newvexa/workify/v/0.1.3-beta.1 "Published immutable 0.1.3-beta.1 package"
[11]: https://cdn.jsdelivr.net/npm/@newvexa/workify@0.1.3/docs/beta-publication-receipt.json "Archived beta publication receipt: hashes, channels, fresh installs, CDN results, and verification time"
[12]: https://cdn.jsdelivr.net/npm/@newvexa/workify@0.1.3/docs/beta-verification.md "Archived beta test and release review: distinct test baseline, artifact audit, and valid scoped trust"