[ajianaz]

What

Patch release v0.20.1: v0.20.0 plus exactly two fixes, cherry-picked from develop onto main:

• fix(docker): skip the ONNX download for non-onnx backends and fail clearly on unwritable /data (#1398) #1400 (fix(docker): entrypoint downloads the ONNX model for non-onnx backends and loops when /data is not writable #1398): the Docker entrypoint skips the ONNX download for openai/ollama backends and exits with an actionable message when /data is not writable.
• fix(server): honour [embedding]/[vector] config and UTEKE_EMBEDDING_BACKEND (#1399) #1401 (fix(server): uteke-serve ignores [embedding]/[vector] config and UTEKE_EMBEDDING_BACKEND #1399): uteke-serve honours [embedding] / [vector] and UTEKE_EMBEDDING_BACKEND, so an external OpenAI-compatible or Ollama embedder can be used.
  Plus the release bookkeeping: workspace version and internal deps, Cargo.lock, both READMEs, both skill copies, docs/core-contract.json (regenerated), CHANGELOG [0.20.1].

Why

Owner decision 2026-10-09: ship the embedder fixes as a fix-only patch (same pattern as 0.18.2) so a labs instance configured with an external embedder (embor) can be tested, and keep everything else (schema v21, MCP additions, the cosign signing step) for 0.21.0. This branch is cut from origin/main (v0.20.0, 9c55dbc), so it does not carry those changes.

Testing

• fmt, clippy -D warnings, cargo test --workspace and the vecq-only core lib tests (653) green on this branch
• Both fixes were exercised end to end before merging to develop: the real Dockerfile built into an image, embor as the embedder, remember/recall through env-only and toml-only config, embor stopped to prove traffic goes to it, and the unwritable-data-dir message (details in fix(docker): skip the ONNX download for non-onnx backends and fail clearly on unwritable /data (#1398) #1400 and fix(server): honour [embedding]/[vector] config and UTEKE_EMBEDDING_BACKEND (#1399) #1401)
• Mutation gate: git diff v0.20.0 -- crates/uteke-core is empty (the patch touches uteke-server, the entrypoint and tests only), so there are no uteke-core mutants to run
• CORE contract: no endpoint or MCP semantic changes; the change is server start-up configuration and the container entrypoint. No cloud contract issue needed
• Not tested: the Release workflow itself (it runs on the tag), and the fix on the real labs host

🤖 Generated with Claude Code

[github-actions]

🔍 Cora AI Code Review

❌ Blocked — critical issues found.

🔴 Error (3)

• benchmarks/longmemeval/results/default-500q-v0.19.0.jsonl:94 — Static security scanner detected: SQL injection via string concatenation in benchmarks/longmemeval/results/default-500q-v0.19.0.jsonl:94
• benchmarks/longmemeval/results/default-500q-v0.19.0.jsonl:124 — Static security scanner detected: SQL injection via string concatenation in benchmarks/longmemeval/results/default-500q-v0.19.0.jsonl:124
• benchmarks/longmemeval/results/default-500q-v0.19.0.jsonl:166 — Static security scanner detected: SQL injection via string concatenation in benchmarks/longmemeval/results/default-500q-v0.19.0.jsonl:166

---

Review powered by cora-code · BYOK · MIT

[ajianaz]

Cora "Blocked" verdict: validated as a false positive, with evidence

The 3 findings are all benchmarks/longmemeval/results/default-500q-v0.19.0.jsonl (lines 94, 124, 166, "SQL injection via string concatenation"). None of them applies to this PR:

1. The file is not in this PR: git diff --name-only origin/main chore/release-v0.20.1-main | grep -c benchmarks is 0 (the PR changes 14 files: the entrypoint, the server config and its tests, and version/changelog files).
2. The review ran against the wrong base. The job log shows base-branch: origin/develop / INPUT_BASE: origin/develop. The fix that passes the PR base (origin/${{ github.base_ref }}, ci: pass the PR base branch to the Cora review action #1386) is on develop but not on main (v0.20.0), and this branch is cut from main, so the old workflow ran. That is the known "PR into main reviewed against develop" failure from chore: release v0.20.0 to main #1380.
3. The flagged lines are data, not code: each is a JSON object {question_id, question_type, retrieval_results} of a committed benchmark result file, with no SQL text in it.

Not re-run: re-running would use the same old workflow file. The two code changes in this PR (#1400, #1401) each passed Cora with a real "No issues found" verdict against develop before being merged there. The base fix reaches main with the next release (0.21.0).