chore(release): prepare v0.9.7

[Hmbown]

No-Issue: release preparation and public-surface alignment chore — the issue-fixing PRs (#5319, #5320, #5321) landed separately and their issues (e.g. #5314) are already closed.

Summary

Codewhale v0.9.7 keeps the catalog ordinary. Grok 4.6 lands as a normal catalog row instead of a provider-shaped pile of special cases, OrcaRouter joins as a named provider, and a panic-safety advisory in lru is cleared by lifting the pin that caused it rather than living around it. Three external contributor PRs — canonical message copy, a session snapshot/recovery split, and the OrcaRouter registration — are harvested with full credit. The README and install docs now record DeepSeek's live V4 Pro backend (DeepSeek-V4-Pro-0813, callable as deepseek-v4-pro).

Punch list (new commits since v0.9.6)

• 464d5658b feat(xai): add Grok 4.6 as the direct default
• 26037c45c fix(tui): move lru to 0.18 and unpin ratatui-core (RUSTSEC-2026-0253)
• c0e69f4ab fix(session): separate snapshot reads from crash recovery (fix(session): separate snapshot reads from crash recovery #5320)
• 2a7634e8c feat: register OrcaRouter as a named provider (feat: register OrcaRouter as a named provider #5321)
• 9f1815279 fix(tui): copy canonical message content (fix(tui): copy messages without visual rails #5319)

Security

• RUSTSEC-2026-0253: lru moves to 0.18; LruCache::pop() was not panic-safe and could leave dangling list pointers. The ratatui-core =0.1.0 pin that transitively forced lru ^0.16 is lifted, so ColorCompatBackend now answers get_cursor_position() from tracked cursor state — the upstream-recommended workaround for the startup CPR race (Rendering fails due to Ratatui and the app race stdin ratatui/ratatui#2483, Inline viewport construction and Terminal::clear still issue CPR queries that race stdin (follow-up to #2483) ratatui/ratatui#2640) that the pin originally worked around. ratatui itself stays pinned at =0.30.0, so the API surface is unchanged.

Contributors

Thank you to the community contributors who shaped this release:

• XhesicaFrost (@XhesicaFrost) — canonical message copy (fix(tui): copy messages without visual rails #5319)
• h3c-hexin (@h3c-hexin) — session snapshot and crash-recovery split (fix(session): separate snapshot reads from crash recovery #5320)
• XiaoHuo888-hue (@XiaoHuo888-hue) — OrcaRouter provider registration (feat: register OrcaRouter as a named provider #5321)

Known issues

• The integration test exec_persistent_service::failed_exec_kills_pending_service_and_exits_nonzero is a confirmed flake under parallel load ("service pid file never appeared"). It passes in isolation and is unrelated to any v0.9.7 change.

Gates

• prepare-release.sh 0.9.7: Version state OK: workspace=0.9.7, npm=0.9.7, lockfile in sync.; OHOS linker/graph/bindgen checks OK; npm/deepseek-tui left unbumped.
• cargo fmt --all -- --check, cargo check --workspace --all-targets --locked, cargo clippy --workspace --all-targets --all-features --locked -- -D warnings: clean.
• cargo test --workspace --all-features --locked --no-fail-fast: complete run; the only failure was the documented flake, which passes in isolation.
• publish-crates.sh dry-run: verified package contents for all 13 release crates (exit 0).
• npm wrapper smoke: passed; the release binary reports codewhale 0.9.7 (dev).
• codewhale model resolve grok → grok-4.6, provider xai, used_fallback: false.
• Web gates: check:facts OK, check:docs OK, full vitest suite 258/258, ESLint clean, tsc --noEmit clean.

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[claude]

Claude finished @Hmbown's task in 2m 57s —— View job

---

Review complete

• Gather context (PR description, changed files list)
• Review diff against origin/main
• Check correctness bugs (panics/unwraps/error handling)
• Check provider/model/route safety invariant (EPIC v0.8.65 EPIC: Separate provider facts, model facts, offerings, and route resolution #2608)
• Check reuse/simplification/dead code
• Check test coverage
• Check security (secrets, exec policy)
• Post final review

Summary

Only two commits are actually new on this branch relative to origin/main (464d565 feat(xai): Grok 4.6, and 9fcc75d chore(release): v0.9.7 prep); the other four items in the PR description's punch list are already merged onto main and not part of this diff. I reviewed both commits in full.

Note: I was unable to execute cargo build/cargo check/cargo test in this environment (tool permission restrictions blocked all cargo/git fetch invocations), so this is a static/code review only — I could not independently verify the PR's self-reported gate results. If you'd like compilation/test verification, please grant Bash access to cargo.

Findings

1. crates/tui/src/client/chat.rs:118 — "off" maps to "high" for Grok 4.6 reasoning effort. Initially looked like an inversion bug (every other always-thinking route in this file, e.g. Kimi K3 at line 179/222, maps off to its lowest tier), but this is correct and intentional: xAI's Models.dev catalog row (crates/config/assets/models_dev.bundled.json) declares "default": "high" for grok-4.6, and the new generic ReasoningEffort::catalog_default/clamp_to_catalog_efforts machinery (crates/tui/src/tui/app/types.rs:388) maps Off to the catalog default for any model that publishes an effort list — not a Grok-specific special case. Confirmed by the new test grok_46_uses_exact_first_party_reasoning_effort_ladder and documented in docs/CONFIGURATION.md. No action needed, just noting it took a second look.

2. Provider/model/route safety (EPIC #2608 invariant): clean. All new gating is provider-enum + exact-route + exact-model, never string-prefix inference:

• is_exact_xai_grok_4_6_route (crates/tui/src/config.rs:8705) requires ApiProvider::Xai + is_exact_xai_platform_route (exact https://api.x.ai/v1, case/slash-normalized only) + exact grok-4.6 model match before the wire-level reasoning_effort field is added.
• Grok 4.6's usage-aware 200K-token pricing tier (crates/tui/src/pricing.rs:1255) is gated on provider == ApiProvider::Xai, and a new test explicitly asserts OpenRouter serving a model literally named "grok-4.6" gets no owned pricing row (direct_xai_grok_46_owns_usage_tier_without_leaking_to_other_providers).
• The new is_exact_xai_platform_route helper in crates/config/src/provider.rs:478 follows the same exact-match pattern (host+path, no substring/prefix check) as the existing Moonshot/Z.ai helpers, with a thorough negative test table (query strings, fragments, double slashes, wrong scheme, port, neighboring host).

3. Good generalization, not a one-off hack. Rather than hard-coding Grok 4.6's reasoning ladder, the PR adds ReasoningEffort::catalog_default/catalog_effort_values/clamp_to_catalog_efforts, driven by the model's reasoning_options in the Models.dev-shaped catalog. This is reusable for future models that publish an effort list, and is exercised at both provider-switch time (app.rs:4926) and app-init time (app/init.rs:471-479), correctly deferring to any explicit user-configured reasoning_effort_preference first.

4. Version bump / release-prep commit (9fcc75d) is mechanical and consistent. Workspace version, per-crate path-dependency version pins, npm wrapper versions, and the [0.9.7] CHANGELOG entry (with compare-URL footer) all line up. npm/deepseek-tui is called out in the PR body as intentionally unbumped.

5. Test coverage is solid for the new behavior: route resolution/capabilities (crates/config/src/route/tests.rs), catalog row shape and honest-pricing omission (crates/config/src/catalog/tests.rs), reasoning-effort wire shaping (chat.rs), pricing tier boundary at exactly 200K tokens (pricing.rs), and model-picker ordering (model_picker.rs).

No correctness bugs, no dead code, and no security concerns found in the diff.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 9fcc75d70b

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Align the install guide with the 0.9.7 candidate

After bumping the workspace to 0.9.7, the public install guide still identifies the branch and platform matrix as the “v0.9.6 source candidate” (docs/INSTALL.md:11, :31, :55, and :67). Users consulting the 0.9.7 source tree will therefore be told they are building or testing the previous candidate; update the current-candidate references while retaining genuinely historical v0.9.6 notes.

Useful? React with 👍 / 👎.

[claude]

Claude finished @Hmbown's task in 1m 13s —— View job

---

Review complete

• Gather context (PR description, prior review, Codex bot comment)
• Identify what's new since the last review (this is a synchronize event)
• Review new commit 4334e2f in full
• Verify factual claims in docs against the actual catalog/code
• Post final review

Summary

Since my prior review comment covered 464d565 (Grok 4.6) and 9fcc75d (release-prep bump), one new commit landed: 4334e2f — docs: align the v0.9.7 public surface. It's docs-only (README.md, docs/INSTALL.md, docs/CONTRIBUTORS.md, docs/public-surface-facts.json, web/lib/release-credits.ts), no Rust/TS code paths touched, so none of the correctness/provider-safety/test-coverage categories apply here.

This commit directly resolves Codex's P2 finding (inline comment on Cargo.toml:28) that docs/INSTALL.md still said "v0.9.6 source candidate" after the version bump — all four call sites (branch banner, candidate matrix intro, Android npm-wrapper footnote, musl candidate-assets line) are now updated to v0.9.7.

Findings:

1. docs/INSTALL.md: no remaining v0.9.6 source-candidate references. Confirmed via diff — Codex's finding is fully addressed.
2. Factual claims checked against code, all accurate:
   • orcarouter/auto — real alias, defined at crates/config/src/provider_defaults.rs:36 (ORCAROUTER_AUTO_MODEL).
   • deepseek-v4-pro as the callable ID for the DeepSeek-V4-Pro-0813 backend — matches docs/PROVIDERS.md:396 and docs/CONFIGURATION.md:1657, a pre-existing catalog fact, not a new claim invented by this commit.
   • docs/public-surface-facts.json / web/lib/release-credits.ts credits (@XhesicaFrost, @h3c-hexin, @XiaoHuo888-hue) match the PR body's Contributors section and docs/CONTRIBUTORS.md's new v0.9.7 band — consistent across all three sources.
3. docs/CONTRIBUTORS.md correctly nests the new v0.9.7 <details open> block above the now-closed v0.9.6 block (<details> without open), preserving history rather than deleting it — consistent with prior release-note conventions in the file.

No issues found in this commit. Combined with the earlier review of 464d565/9fcc75d (clean — provider/model/route-safety invariant upheld via exact-match gating, solid new test coverage, no dead code), I have no outstanding correctness, safety, or security concerns on this PR as it currently stands.

Note: As before, I don't have cargo/git fetch access in this environment, so I could not independently run the web gates (check:facts, check:docs, vitest) that the commit message claims were verified locally — this was a static diff/content review only.

[claude]

Claude finished @Hmbown's task in 1m 15s —— View job

---

Review complete

• Gather context (PR description, prior reviews, Codex bot comment)
• Identify what's new since the last review (this is a synchronize event)
• Review new commit 512137c in full
• Verify factual claims in the README translations against the actual catalog
• Post final review

Summary

Since the last review (which covered 464d565, 9fcc75d, and 4334e2f), one new commit landed: 512137c — docs: sync all nine README translations with the v0.9.7 catalog note. It's translation-only (all nine README.*.md files), no code paths touched, so the correctness/provider-safety/test-coverage categories don't apply.

Findings:

1. Source stamps are correct. Every translation's `` stamp was refreshed to 3a759de92f8b, which I confirmed is the actual current `sha256sum` (first 12 hex chars) of `README.md` on this branch — matches what `scripts/check-readme-translations.py` computes and requires (`scripts/check-readme-translations.py:56`). I couldn't execute the script directly in this sandbox (no bash approval), so I walked its four checks by hand:

   • Stamp match: confirmed above.
   • Fenced code blocks: this commit only edits prose inside the "Any model, any provider" bullet — no fences added/removed/reordered in any file.
   • URL check: no new links introduced in the English source's edited sentence, so nothing new for translations to be missing.
   • ## section count: unchanged in all files.

   All four gate conditions hold, so check:readme-translations (referenced in the PR's gate list) should stay green.

2. Content is faithfully translated and factually consistent with the English source (README.md:69-72) across all nine languages — each correctly states: DeepSeek's V4 Pro backend labeled DeepSeek-V4-Pro-0813 stays callable as deepseek-v4-pro, Grok 4.6 is xAI's direct default, and OrcaRouter routes through orcarouter/auto. These same facts were already verified against the catalog/code in the prior review pass (orcarouter/auto alias at crates/config/src/provider_defaults.rs:36, deepseek-v4-pro documented in docs/PROVIDERS.md/docs/CONFIGURATION.md).

3. Minor, non-blocking nuance: README.ko-KR.md renders "direct xAI default" as "xAI의 기본값" (xAI's default), dropping the word "direct" that the other eight translations preserve. Not a factual error and not worth a fix-up commit on its own.

No correctness, safety, or security issues. Combined with the earlier findings on 464d565/9fcc75d (provider/model/route-safety invariant upheld via exact-match gating, solid new test coverage, no dead code) and 4334e2f (INSTALL.md version references fixed, addressing Codex's P2 finding), I have no outstanding concerns on this PR as it currently stands.

Note: As before, I don't have cargo/git fetch/general bash execution access in this environment, so I could not run scripts/check-readme-translations.py or the other gates directly — the checks above were done by manual inspection against the script's logic.