ajianaz · Oct 15, 2026 · Aug 14, 2026 · Aug 14, 2026 · Aug 14, 2026 · Aug 15, 2026
diff --git a/.agents/skills/uteke-memory/SKILL.md b/.agents/skills/uteke-memory/SKILL.md
@@ -5,7 +5,7 @@ description: "Persistent memory engine for AI agents via the uteke CLI — remem
 # Uteke Memory Skill
 
 Persistent memory engine for AI agents via the `uteke` CLI.
-Version: **0.21.0** — SQLite + HNSW vector index (usearch default, or vecq) + FTS5 hybrid search (RRF k=60); `fusion` (weighted RRF of the vector and hybrid rankings) is the default recall strategy since 0.16.0. `unsafe_code = "forbid"` workspace-wide.
+Version: **0.21.1** — SQLite + HNSW vector index (usearch default, or vecq) + FTS5 hybrid search (RRF k=60); `fusion` (weighted RRF of the vector and hybrid rankings) is the default recall strategy since 0.16.0. `unsafe_code = "forbid"` workspace-wide.
 
 > This skill ships with each release — its version tracks the CLI version
 > (a CI gate fails when they drift, see `skill-version-parity` test).

diff --git a/.github/workflows/release-signature-reminder.yml b/.github/workflows/release-signature-reminder.yml
@@ -0,0 +1,47 @@
+name: Release Signature Reminder
+
+# Opens (and re-pings) a "Sign release vX.Y.Z (minisign)" issue while the latest
+# release has no checksums-sha256.txt.minisig, and closes it once the signature
+# is uploaded. It signs nothing and holds no signing secret: the minisign key
+# stays offline (scripts/sign-release.sh, AGENTS.md "Release procedure" step 6).
+#
+# workflow_run is used because a release created with GITHUB_TOKEN does not
+# trigger `release` events; the schedule re-pings and notices the signature.
+
+on:
+  workflow_run:
+    workflows: ["Release"]
+    types: [completed]
+  schedule:
+    - cron: "17 */6 * * *"
+  workflow_dispatch:
+
+concurrency:
+  group: release-signature-reminder
+  cancel-in-progress: false
+
+permissions:
+  contents: read
+  issues: write
+
+env:
+  FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true
+
+jobs:
+  remind:
+    name: Remind to sign
+    if: github.event_name != 'workflow_run' || github.event.workflow_run.conclusion == 'success'
+    runs-on: ubuntu-latest
+    timeout-minutes: 5
+    steps:
+      - uses: actions/checkout@v7
+        with:
+          persist-credentials: false
+
+      - name: Check the latest release for a signature
+        env:
+          GH_TOKEN: ${{ github.token }}
+          GH_REPO: ${{ github.repository }}
+          RELEASE_SIGNER: ajianaz
+          REMINDER_AFTER_HOURS: "12"
+        run: bash scripts/release-signature-reminder.sh
diff --git a/AGENTS.md b/AGENTS.md
@@ -83,7 +83,31 @@ Rust workspace: uteke-core (engine), uteke-cli, uteke-server, uteke-mcp, docgen.
    the tag at the previous release (v0.15.0). The Release workflow takes ~35 min
    (the legacy-ORT build is the long pole) and publishes GitHub assets, crates.io
    (uteke-core/cli/mcp), Docker tags and opens the Homebrew tap PR.
-6. **After the tag.** Merge the homebrew-tap PR the workflow opened (its title/body
+6. **Sign the checksums (offline).** After the Release workflow is green, run
+   `scripts/sign-release.sh vX.Y.Z` on the owner's machine (`--dry-run` stops before
+   upload). It first verifies the release's cosign bundle (so `cosign` must be installed on the
+   signing machine), shows the checksums and asks for confirmation, then signs
+   `checksums-sha256.txt` with the minisign key (trusted comment
+   `uteke vX.Y.Z`), verifies it against `scripts/uteke-release.pub` and uploads
+   `checksums-sha256.txt.minisig` after a confirmation. Key custody: password
+   manager plus an offline backup; never in CI or GitHub secrets. It can only sign releases that carry a cosign
+   bundle (v0.21.0 and later). Test it with `bash scripts/tests/sign-release.test.sh`
+   (stub gh/cosign, throwaway key; not wired into CI). Verify the
+   `.minisig` is on the release before announcing. Until it is uploaded,
+   `uteke upgrade` fails closed for that release (#1327).
+   Reminder: `.github/workflows/release-signature-reminder.yml` runs after the
+   Release workflow and every 6 hours. While the latest release has a bundle but no
+   `.minisig` it opens the issue `Sign release vX.Y.Z (minisign)` (assigned to the
+   owner), re-pings it every 12 h and closes it itself once the `.minisig` is
+   uploaded. Reminders for older releases are closed automatically, as superseded
+   (`uteke upgrade` only installs the latest release) or when their `.minisig`
+   appears. "Latest" follows GitHub's definition (by creation date, the same release
+   `uteke upgrade` installs), so a backport patch published after a newer minor
+   supersedes the newer release's reminder. Only issues and comments authored by the
+   Actions bot or the owner are acted on. It signs nothing and holds no key. Test its
+   script with `bash scripts/tests/release-signature-reminder.test.sh` (stub gh, not
+   wired into CI).
+7. **After the tag.** Merge the homebrew-tap PR the workflow opened (its title/body
    follow the tap's rules since #1384, and the job already re-verified every SHA256
    against `checksums-sha256.txt`; Cora there was fixed in homebrew-tap#6), then
    `brew update && brew upgrade codecoradev/tap/uteke`. Verify crates.io and the

diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -2,6 +2,34 @@
 
 ## [Unreleased]
 
+## [0.21.1] - 2026-10-15
+
+Patch release. Theme: **`uteke upgrade` verifies a minisign signature, Homebrew
+installs keep their embeddings, and `--json` output stays clean.** 0.21.1 is the
+first release whose `checksums-sha256.txt` carries a minisign signature. A
+0.21.0 binary only checks the SHA-256 and never verifies the signature, so the
+signature protects `uteke upgrade` from 0.21.1 on.
+
+### ⚠️ Behavior Change
+
+- **`uteke upgrade` is stricter (#1327, #1462)** - it installs only stable releases (`vX.Y.Z`), refuses to downgrade, and fails closed unless the release has a valid minisign signature for `checksums-sha256.txt`. A release without a `.minisig` cannot be installed by `uteke upgrade` until the maintainer signs it.
+- **CLI log lines go to stderr (#1461, #1471)** - scripts that read log lines from stdout must read stderr instead; `--json` output is now parseable even when a warning is logged.
+
+### Security
+
+- **`uteke upgrade` verifies a minisign signature over `checksums-sha256.txt` (#1327)** - the release maintainer signs the checksums offline (`scripts/sign-release.sh`) and uploads `checksums-sha256.txt.minisig`; the embedded public key (`scripts/uteke-release.pub`) and the trusted comment `uteke <tag>` are checked before any hash in the file is trusted, so a tampered file is rejected, one release's files cannot be served as another's (the signature is bound to the tag), and `uteke upgrade` now refuses to downgrade to an older release. It also installs only stable releases (`vX.Y.Z`), never a pre-release or build-metadata tag. The signature is checked by `uteke upgrade` only: `install.sh`, `install.ps1` and Homebrew do not verify it (verify manually per SECURITY.md). A missing or invalid signature is a hard failure; `UTEKE_UPGRADE_SKIP_CHECKSUM=1` skips it too. Manual steps are in SECURITY.md.
+- **rustls 0.23.46 (#1455)** - fixes RUSTSEC-2026-0346 to RUSTSEC-2026-0349 in the TLS stack used by the HTTP client.
+
+### Fixed
+
+- **`ORT_LIB_PATH` pointing at a directory no longer leaves uteke without embeddings (#1459)** - the Homebrew shims exported the `libexec` directory (v0.19.0 onwards), `dlopen` failed on it, and every such install silently stored memories FTS5-only (`embedding_written: false`, `uteke verify` MISMATCH). A directory that holds the platform library (`libonnxruntime.so`, `libonnxruntime.dylib` or `onnxruntime.dll`) is now accepted with a warning; a directory without it is a clear error that says to set the library file. The tap fix is codecoradev/homebrew-tap#10 (`brew update && brew reinstall codecoradev/tap/uteke`). Docker and the release tarballs were not affected.
+- **CLI log lines no longer corrupt `--json` output (#1461)** - the console log layer wrote to stdout, so any WARN or ERROR (for example a failed embedding) was printed in front of the command's JSON and `json.loads(stdout)` failed. Console logs now go to stderr; the log file and the command output are unchanged.
+
+### Changed
+
+- Internal: the server dispatch is split into one named handler per route group (#1344, #1458); dependabot batch for `toml`, `usearch`, `uuid` and `serde_json` (#1457).
+- Internal: `release-signature-reminder` workflow and script open and re-ping a `Sign release vX.Y.Z (minisign)` issue until the offline minisign signature is on the release, and close reminders for superseded releases automatically (#1327).
+
 ## [0.21.0] - 2026-10-13
 
 Minor release. Theme: **honest recall feedback, one access policy for MCP over

diff --git a/Cargo.lock b/Cargo.lock
diff --git a/Cargo.toml b/Cargo.toml
@@ -9,7 +9,7 @@ members = [
 ]
 
 [workspace.package]
-version = "0.21.0"
+version = "0.21.1"
 edition = "2024"
 license = "Apache-2.0"
 repository = "https://github.com/codecoradev/uteke"

diff --git a/README.id.md b/README.id.md
@@ -392,7 +392,7 @@ Bisa. Uteke punya MCP server yang langsung pakai dengan Claude Code, Cursor, dan
 <details>
 <summary><strong>Sudah production-ready?</strong></summary>
 
-Uteke sekarang v0.21.0 dengan 200+ test, CI/CD di setiap commit, dan benchmark harness. Dipakai production oleh tim CodeCora dan early adopter lain. Masih di versi 0.x, jadi mungkin ada rough edges, tapi core-nya udah stabil.
+Uteke sekarang v0.21.1 dengan 200+ test, CI/CD di setiap commit, dan benchmark harness. Dipakai production oleh tim CodeCora dan early adopter lain. Masih di versi 0.x, jadi mungkin ada rough edges, tapi core-nya udah stabil.
 </details>
 
 ---

diff --git a/README.md b/README.md
@@ -353,7 +353,7 @@ Yes. Uteke ships with an MCP server that works with Claude Code, Cursor, and Her
 <details>
 <summary><strong>Is it production-ready?</strong></summary>
 
-Uteke is at v0.21.0 with 200+ tests, CI/CD on every commit, and a benchmark harness. It's used in production by the CodeCora team and other early adopters. Still in 0.x, so expect rough edges, but the core is stable.
+Uteke is at v0.21.1 with 200+ tests, CI/CD on every commit, and a benchmark harness. It's used in production by the CodeCora team and other early adopters. Still in 0.x, so expect rough edges, but the core is stable.
 </details>
 
 ---

diff --git a/SECURITY.md b/SECURITY.md
@@ -68,6 +68,34 @@ cosign verify-blob \
 sha256sum --check --ignore-missing checksums-sha256.txt
 ```
 
-`uteke upgrade` does not verify this signature yet; it still checks the archive
-against the unsigned `checksums-sha256.txt` of the same release (corruption
-detection only).
+### minisign signature
+
+The release maintainer also signs `checksums-sha256.txt` offline with a
+[minisign](https://jedisct1.github.io/minisign/) key that never leaves their
+machine (CI holds no signing key). The signature is published as
+`checksums-sha256.txt.minisig`; its trusted comment is `uteke <tag>`, binding it
+to one release. The public key is `scripts/uteke-release.pub`, key id
+`96924B76E31B048B`.
+
+```bash
+curl -fsSLO "https://github.com/codecoradev/uteke/releases/download/$VER/checksums-sha256.txt.minisig"
+
+minisign -Vm checksums-sha256.txt \
+  -P RWSLBBvjdkuSlvaQ/yoyoMlpQAOLTt5jACZGTgSOCKb+/1JoqhjOmT8G
+# the output must show: Trusted comment: uteke vX.Y.Z  (your $VER)
+```
+
+Since the release that ships this change, `uteke upgrade` verifies this
+minisign signature over `checksums-sha256.txt` before trusting any hash in it,
+then checks the archive against that file. The signature is bound to the tag
+(the trusted comment must be `uteke <tag>`), so one release's files cannot be
+served as another's, and `uteke upgrade` refuses to downgrade to an older
+release. It installs only stable, published releases (`vX.Y.Z`): a pre-release
+or build-metadata tag is refused. A missing or invalid signature is a hard failure, never a silent
+downgrade to checksum-only. Setting `UTEKE_UPGRADE_SKIP_CHECKSUM=1` skips both
+checks (not recommended). Releases published before the signature existed
+cannot be installed with `uteke upgrade` from a build that verifies it.
+
+The minisign signature is checked by `uteke upgrade` ONLY. `install.sh`,
+`install.ps1` and Homebrew do not verify it: Homebrew relies on the SHA256s in
+the formula, and for the scripts you should verify manually as described above.