Shipped hardened: pinning every byte before it reaches a consumer

Before anything gets published, the question a security tool should be able to answer about itself is: where did every byte of this thing come from? The release-readiness and supply-chain wave was built to make that question answerable — not in marketing, but in the diff. It is the same philosophy as the engine, applied to the toolchain: no step is trusted because it sounds right; every input is pinned, verified, or explicitly labeled as an assumption.

Nothing in the pipeline moves

Every GitHub Action in ci.yml, veylqorix-gate.yml, and release.yml is pinned to a commit SHA, with the release tag recorded in a trailing comment — none of them floats on a moving ref. pnpm is pinned to a concrete version so every runner resolves the major the lockfile was produced with, and the lockfile itself ships SHA-512 integrity entries for the full tree: install steps run frozen, so a byte that changed after the commit fails the build rather than sneaking in.

Eight advisories, closed by overrides

The audit found eight vulnerabilities in the web dashboard’s tree — postcss and sharp, pulled transitively by next 15.5.28. They were not fixed by bumping versions the lead would have to schedule; they were closed in place with pnpm overrides pinning both to the patched releases inside the range next already accepts. The CLI, the API, the MCP server, and the engine core came back with zero findings, and cargo audit against the engine lockfile is clean across all 37 crates. Where a tool cannot be proven clean, we say so; here the proof is the audit run itself.

Provenance, fail-closed

The release workflow publishes with npm provenance attestation over GitHub OIDC: no registry token, no bot account, no login — the publish step carries an id-token that npm accepts only when a trusted-publisher record points at this exact workflow. Until that record exists the publish fails. That is deliberately fail-closed: there is no configuration state in which something untrusted ships.

The honest line

The Rust engine is not distributed as a binary at all — there is no download path, no signed artifact story yet. A consumer builds it from source and points the runtime at it with VEYLQORIX_ENGINE; if the binary is absent, the audit degrades to the byte-compatible TypeScript engine and the report says so in every surface. And the @veylqorix packages are not on npm yet: nothing has been published, no tag pushed. Today the honest instruction is run it from source — and that line stays in the docs until the trusted-publisher setup is actually complete.