Skip to content

BYOK SDK 0.26.0 · keys 0.11.0

Choose a tag to compare

@Ancienttwo Ancienttwo released this 11 Oct 04:57
· 1139 commits to main since this release
34c0e50

0.26.0 publication record

Date: 2026-10-11 (Asia/Singapore).
Status: all nine packages are published on latest and complete registry
readback passed.

On 2026-10-11 the owner authorized stable 0.26.0 / keys 0.11.0 on the
dist-tag latest, before the end-to-end run that the rc route named. 0.26.0
adds #347, #348 and #349 over the published rc.4. No RC carried them.

Source and artifact identity

  • Source: 34c0e504a9439ad1cc402aba7ff3f6b074e56cad.
  • Preparation PR: #350,
    merge 34c0e504.
  • Artifact: release-pack-34c0e504a9439ad1cc402aba7ff3f6b074e56cad from
    push CI 38111346268.
    That run passed every job.
  • The PR CI for #350 passed 48 of 48 checks. One Node 26 job first failed in
    the cloud-do wake-inbox deadline test. The rerun of that job passed.
  • The publisher dry run and the --execute run verified the frozen artifacts
    against the source SHA. No package was repacked.

npm execution

The authenticated account was ancienttwo, with auth-and-writes 2FA.
The owner completed a web authentication for each of the nine packages.
This local publication has no GitHub OIDC provenance attestation.

The publish order was cloud-do, core, protocol, client, cloud, keys,
cloud-dataplane, server, ui-runtime. All nine npm publish calls returned
success.

Publisher step 7 (registry readback) then failed once with E404 for
@byok-sdk/server@0.26.0. This was registry propagation lag. The driver
therefore did not create the tag. No upload was repeated.

Closure

A standalone run of node scripts/release/registry-readback.mjs --manifest <artifacts>/release-manifest.json passed on its fifth attempt, about two
minutes later. All nine integrities and runtime dependency maps match the
frozen artifact. The install tree closes to exactly nine SDK packages.
npm ls @byok-sdk/core --all --json resolves only 0.26.0. The official Pi
direct pins match bun.lock and the official tarball.

Registry SHA-512 integrities checked for three of the packages:

  • core: sha512-PO9WiBm/zxCepvrqcuvgkUGPjH/ewxU9aza/euHNbX+tpdZQGy+Tc5z5JfExoPwLBsTedJY3tg03lI6k+OX8nw==
  • protocol: sha512-qLwlXKqxd/Y8A1/CYhtPncvbsZA3DXFyVgqk4UVubCUxxHJeEUGWTmB29yZkWu0kfZtBpqJPOnhD4sepGquDiQ==
  • client: sha512-4JqKF8TYFQszNyB26cCq5/q/GPNvgoZljcTMNTXzjHvIM2gFuIe1CSRCArYkDTtyQ9YwDlZh/SG2fTsEfOBRGg==

The dist-tags now read latest = 0.26.0 for the eight aligned packages and
latest = 0.11.0 for keys. rc still reads 0.26.0-rc.4 / keys 0.11.0-rc.4.

Because step 7 failed, the driver did not create the release tag. The
annotated tag v0.26.0 was created manually with the exact step-8 format
(message v0.26.0 followed by sourceGitSha 34c0e504...) on 34c0e504 and
pushed. The remote tag object 4176d474 peels to 34c0e504.

This record does not establish live Host acceptance, the end-to-end run or
production rollout.