v0.13.1

v0.13.1

Patch release: the native rerank stage now actually reaches installed binaries, and ee model status no longer misclassifies healthy reranker metadata.

Fixed

• GH#26 — reranker registry metadata misclassified as corrupt. ee model status parsed every model-registry row's metadata_json as an embedding metadata record, so a valid rerank-default-v1 row (schema ee.rerank_model_registry_metadata.v1) was reported as model_asset_corrupt with an embedding-oriented repair hint, and v0.13.0 search stayed fusion-only. Lifecycle rows now validate against the schema matching their ModelPurpose; malformed reranker metadata still surfaces model_asset_corrupt with a reranker-specific repair (ee model fetch rerank-default). (76c7773)
• Envelope honesty: ee model status mirrors modelLifecycle.degraded[] into the top-level ee.response.v2 degraded[] (deduped by code+message), so a high-severity lifecycle degradation can no longer coexist with an empty top-level degraded[].
• Clean-clone builds restored. Cargo.toml, Cargo.lock, and franken-stack.lock had drifted mutually inconsistent (ed25519-dalek pin vs lock, asupersync =0.3.10 pin vs 0.4.4 APIs), breaking --locked builds. The pins are reconciled (asupersync =0.4.4, sqlmodel 0.4.0, ed25519-dalek 3.0.0 closure in the lock) and franken-stack.lock is refreshed to the validated sibling revisions.
• Windows asset restored (2026-08-17). v0.13.1 initially published with zero Windows assets, because CI's Windows leg hit an upstream rustc nightly internal compiler error (asupersync::Cx import resolution failing under this repo's floating channel = "nightly" toolchain pin) — confirmed not a source defect and confirmed toolchain-specific by a controlled rebuild: identical source and sibling pins, only the nightly date changed, and the failure went away. ee-x86_64-pc-windows-msvc.tar.xz (+ .sha256) is now attached, built and executed on real Windows hardware (ee --version reports ee 0.13.1), and independently re-verified by downloading the published asset back from GitHub and re-hashing it. install.ps1's existing fallback-to-newest-Windows-release logic remains as defense-in-depth for future incomplete releases; it is no longer needed to reach v0.13.1 specifically. The underlying floating-nightly toolchain issue is unresolved upstream and could recur on a future cut.

Changed

• Everything merged to main since v0.13.0, including the native reranker completion wave (rerank-default-v1 bootstrap, checksum and publication hardening) that v0.13.0 binaries could not execute.

Assets

This release ships locally built, checksum-verified binaries for:

• ee-aarch64-apple-darwin.tar.xz (+ .sha256)
• ee-x86_64-unknown-linux-gnu.tar.xz (+ .sha256)
• ee-x86_64-pc-windows-msvc.tar.xz (+ .sha256) — added 2026-08-17, see Fixed above

install.sh / install.ps1 are attached as usual. Targets from the v0.13.0 matrix still not attached here: x86_64-apple-darwin, aarch64-unknown-linux-gnu, x86_64-unknown-linux-musl.

Known limitation: no provenance or Sigstore attestation on this release (any platform)

v0.13.1 ships without SLSA provenance or Sigstore attestation for any platform — a release-wide regression from v0.13.0 (which shipped both for five targets), not specific to any one platform including Windows. A client running with --require-provenance will fail identically on all three attached platforms until this is fixed. install.sh/install.ps1 treat the missing signature bundles as a warning rather than a hard failure by design, so a default install is unaffected.

Remedy: this needs a genuine CI signing run — cosign sign-blob --tlog-upload=true requires a GitHub-Actions-issued OIDC identity token to produce a .sigstore.json bundle that means anything (it binds the signature to a specific verified CI run in the public Rekor transparency log). There is no local or manual equivalent: a signature produced any other way would not be this attestation, and a .provenance.json manually assembled outside CI would misrepresent its own runDetails.builder.id/workflowRef/invocationId fields, which are supposed to identify the actual CI run that built the artifact. Producing either by hand was considered and rejected for v0.13.1's Windows asset specifically for this reason — a fabricated attestation is worse than an absent one, because absence is visible and a fake would verify as if it meant something it does not. Fixing this requires re-running the release workflow's signing steps on a real GitHub Actions runner against the already-published artifacts, not a local patch.