Release 0.1.5 trust downgrade (missing provenance attestation): Fails to install in pnpm/aube

[iki]

Steps to reproduce

Check trust using aube command trust check:

$ aube trust check @yc-software/qm@0.1.5
@yc-software/qm@0.1.5: downgrade
published: 2026-08-17T21:25:49.084Z
current evidence: none
strongest earlier evidence: provenance attestation (0.1.0)
ERR_AUBE_TRUST_DOWNGRADE
  × trust downgrade for @yc-software/qm@0.1.5 (trustPolicy=no-downgrade): earlier published version 0.1.0 had provenance attestation but this version has no trust evidence

Temporary workaround

Add @yc-software/qm@0.1.5 to trustPolicyExclude in global ~/.config/aube/config.toml or ~/.config/pnpm/config.yaml

[yzxcj797]

Root cause is in the repo, not the registry: d931fe9 (#568, the 0.1.5 correction) restructured the publish step so the already-published branch exit 0s early — and the new else branch is the one that publishes. That part is fine, but the history shows the first 0.1.5 publish happened through the deprecation-correction run: the workflow originally published 1.0.5 (wrong version), then the correction republished as 0.1.5 — and the correction publish went through a path where npm publish --provenance depends on the OIDC id-token: write permission being intact for that specific run's ref/event, which the manually-dispatched correction run (workflow_dispatch after a version-metadata commit) evidently didn't satisfy for the attestation.

The actionable in-repo hardening: make the attestation verifiable at publish time instead of trusting that it landed. Adding a post-publish check that fetches the attestation (npm view @yc-software/qm@$version attestations --json) and fails the job when it comes back empty turns a silent trust downgrade into a loud CI failure — the next 0.1.5-shaped incident (early-exit path, manual correction run, permission hiccup) breaks the build instead of shipping a downgrade.

A republish of 0.1.5 itself isn't possible from my side (immutable registry, maintainer credentials); for the current release the trustPolicyExclude workaround in the issue is the answer. PR with the publish-time verification incoming.