[asto18089]

背景

三条 RustSec 通告使 cargo deny advisories / cargo-audit 硬门禁转红：

• RUSTSEC-2026-0459（CVE-2026-119375）：libsqlite3-sys 0.38.2 捆绑的 SQLite <3.54.0 在打开 db+wal 页大小不一致的文件对时可返回未初始化页缓存内存；
• RUSTSEC-2026-0462：rmcp <3.9.0 的 Streamable HTTP 客户端把非流式响应体无界读入内存；
• RUSTSEC-2026-0430：rio-vt ≤0.5.28 的 Kitty 图形协议路径穿越可致越权文件删除/读取（本仓锁内 0.5.28，fix 0.5.29 已发布）。

变更

• rusqlite 0.40.2 → 0.41.1（随附 libsqlite3-sys 0.38.2 → 0.39.1，捆绑修补版 SQLite 3.54.1）：Cargo.toml req 升级 + 锁更新；
• rmcp 3.7.0 → 3.9.0（spec "3.7.0" 未动，锁更新；随附 sha2 转为硬依赖）；
• rio-vt 0.5.28 → 0.5.29（仅锁，rio 家族六包同步 0.5.29：rio-vt/teletypewriter/rio-graphics/rio-unicode/rio-grapheme-width，corcovado 随 teletypewriter 依赖升级）；
• rust-version 1.88 → 1.89（Cargo.toml 声明对齐，唯一一处非锁变更）：锁图内 uuid 1.29.0（本 PR 之前已在锁内）与 rusqlite 0.41.1 均声明 rust-version 1.89，1.88 工具链在锁上必然失败，故同步声明下限；aes 0.9.2 锁针保留（与 MSRV 脱钩）。

锁随附的重归一（均为 cargo 解析器强制、非手改，逐字节可复现）：

• rmcp 3.9 波：windows-sys 引用 0.61.2→0.59.0 ×10 包、tempfile 内 getrandom 0.4.3→0.3.4；
• rio-vt 0.5.29 波：windows-sys 引用再统一（0.59.0→0.52.0 ×8、0.59.0→0.61.2 ×3）、serde-saphyr 内 base64 0.23.1→0.22.1。

自上级锁以对应 cargo update -p … 精确复现，两波 diff 均 exit=0（cargo 1.99.1）；总包数 669 不变，无新增传递依赖、无 git/path 源替换。

基分支 pinvou3-clean（父仓 gitlink 门禁要求 gitlink == 本分支头）。父仓 PR codewhale-hq#2519（含本 gitlink 与其余四份 lock 升级）交叉引用本 PR；合入后父仓「公开底座 gitlink 可达性」门禁即满足。

验证

• 全 workspace cargo check --locked --all-targets 通过，零调用点变更；
• cargo metadata --locked exit 0（锁与 manifest 一致）；rio-vt 六包新校验和由 cargo 从 crates.io 实取；
• 三条通告的受影响区间（libsqlite3-sys ≤0.38.2、rmcp <3.9.0、rio-vt ≤0.5.28）均不再含本锁版本，以 CI cargo-deny/cargo-audit 腿为准；
• 本地 cargo deny check advisories exit 0；codewhale-state 28+6 通过；tui lib 套件 12,407 通过 / 0 失败（arm64 本地默认 2MiB 测试栈下 runtime_api::tests::create_thread_accepts_dynamic_tools_and_environments 在 fresh build 触栈沿溢出，base 同样复现、与本 PR 无关，CI nextest 腿绿）。

No-Issue: 依赖升级（RUSTSEC 通告清扫，无对应 Issue）

[asto18089]

随父仓 PR codewhale-hq#2519 从零复审跟进的修复波说明（对第三提交 e6bdda45cd 的核验记录）：

• 第三提交 e6bdda45cd：cargo update -p rio-vt 0.5.28→0.5.29 修 RUSTSEC-2026-0430（本仓 cargo-deny advisories / cargo-audit 门禁红的残留因），随附同工作区 rio-graphics/rio-unicode/teletypewriter 0.5.29；仅动 Cargo.lock，零源码改动，cargo metadata --locked exit 0，Signed-off-by 与作者一致（Check Signed-off-by 腿绿）。
• 正文：补 No-Issue: 行修 link 门禁；标题与变更/验证段落同步覆盖三条通告。
• CI 实证（本头）：cargo-deny (advisories) 与 cargo-audit 已转绿；link 一腿已绿、另一腿为正文修订前的陈旧失败已触发 rerun。
• 复审记录（父仓侧七分片）见 Pinvou/pinvou3#2519 评审 COMMENT 5836998103：rusqlite 0.41 / rmcp 3.9 两项与本提交的兼容性与登记一致性均已 execution-verified；父仓 gitlink/登记已同步至本头（96 提交 / r1 之上 81 / 94 DCO / drift 540 files +119219/-49674，实测重算）。

[asto18089]

Fresh full review (5 parallel shards + main-agent forensics; head 4adbbb9 exactly on latest pinvou3-clean 11cba40, zero rebase needed, mergeable).

What the PR genuinely delivers — verified:

• RUSTSEC-2026-0459 / CVE-2026-119375: advisory verified (affected libsqlite3-sys >=0.6.0, <=0.38.2; patched >=0.39.0). Base pins 0.38.2 (bundled SQLite 3.53.2, confirmed in vendored source); PR pins 0.39.1 whose vendored SQLite is 3.54.1 — confirmed both in registry source and in the compiled libsqlite3-sys-*.o objects. Clear of the affected range.
• RUSTSEC-2026-0462: advisory verified (affected rmcp >=0.2.0, <3.9.0; patched >=3.9.0, the 16 MiB/64 KiB body caps, both reqwest and unix-socket clients named). Base 3.7.0 is inside; PR 3.9.0 clears. cargo deny check advisories on the base tree reproduces both findings; both disappear on the PR tree.
• Zero source changes — true. Diff is exactly Cargo.toml (1 line, bundled feature preserved) + Cargo.lock. No feature drift (rmcp ["auth","client"] untouched), no new transitive packages beyond sha2 0.11.1 (already in the lock, refs 6→7), 669 packages before and after, no git/path deps.
• The suspicious-looking lock diff is clean. The windows-sys 0.61.2→0.59.0 flips (10 packages) and getrandom 0.4.3→0.3.4 (tempfile) are forced resolver normalization: starting from the base lock, cargo update -p rusqlite@0.40.2 --precise 0.41.1 && cargo update -p rmcp@3.7.0 --precise 3.9.0 with cargo 1.99.1 reproduces the PR lock byte-identically. Not hand-editing, not smuggling.
• Compile + runtime: cargo check --locked --workspace --all-targets exits 0 with zero warnings; no rusqlite 0.41 or rmcp 3.9 breaking change touches any call site (usage census: rusqlite ~139 sites in state/tui using only stable APIs; rmcp auth-only, additive variants caught by existing _ => arms). Tests: codewhale-state 28+6 passed (incl. migration-integrity tests), tui lib suite 12,407 passed; 0 failed at --test-threads=2, mcp 236 passed, native_memory 19 passed, cucumber 13 passed. No bump-attributable failure. (Full libtest at default parallelism wedges in pre-existing forkguard_* serialization — not bump-attributable, CI runs nextest and is immune.)
• Parent-repo cross-reference checks out: Pinvou/pinvou3#2519 is OPEN with the CodeWhale gitlink pointing at exactly 4adbbb9 plus the four other lock upgrades, as claimed.

MAJOR 1 — the PR leaves its own motivating gate red (incomplete). The stated premise is that the cargo deny advisories hard gate went red; after this PR it is still red, and mergeable_state is unstable:

1. RUSTSEC-2026-0430 — rio-vt 0.5.28 Kitty-graphics path traversal (substring-only "tty-graphics-protocol" guard, no ../canonicalization; untrusted PTY output can delete + read files outside the temp dir; patched >=0.5.29, CVSS 3.1 4.7). Reached via teletypewriter (dev-dep of codewhale-tui). Both cargo-audit and cargo-deny (advisories) required checks fail on the PR head, on exactly this advisory. Same trivially bumpable class as the rest of this PR: cargo update --dry-run -p rio-vt --precise 0.5.29 succeeds cleanly (bumps rio-vt 0.5.29 + teletypewriter 0.5.29, nothing else). Please include it, or restate the PR's scope and get an explicit decision on 0430 — as-is this PR cannot turn the gate green it was written to fix.
2. The required link check fails: the body has no Closes/Fixes #N and no No-Issue: line (a body edit fixes it on rerun; the check's own message names No-Issue: as the escape hatch for dependency bumps).

Also a claim correction while you're editing the body: "硬门禁自 2026-11-09 起对所有分支转红" understates — the gate has been red since at least 2026-11-01 (0430's advisory date), and remains red after this PR.

MAJOR 2 — commit identity probe <probe@l4>. Both commits are authored, committed, and Signed-off-by an identity with zero commits in this repo's history, not GitHub-linked, and different from the PR author. Every recently merged dep-bump in this repo lands with committer = PR author at a GitHub-linked address (asto <asto18089@126.com>), and CONTRIBUTING requires credit addresses to be GitHub-linked so the contribution graph records the work. The DCO check here is advisory-only (greps for any Signed-off-by:, exit 0 unconditionally), so it cannot catch this. Please rewrite author/committer to your GitHub-linked identity (as in prior merges) before merging, or add the proper Co-authored-by credit trail.

MINOR 1 — title scope mismatch. Title names only the rusqlite/RUSTSEC-2026-0459 half; the PR also fixes RUSTSEC-2026-0462 (rmcp). Repo norm names all bumps (#135 names both; your own parent PR codewhale-hq#2519 title names both). Suggest build(deps): 升级rusqlite 0.41与rmcp 3.9修RUSTSEC-2026-0459/0462.

MINOR 2 — disclose the resolver side effects. Neither the body nor commit 2's message mentions that pinning rmcp 3.9.0 forces 11 downward reference flips (windows-sys 0.61.2→0.59.0 ×10 packages — arboard, colored, dirs-sys, errno, nu-ansi-term, rustix, rustls-platform-verifier, tempfile, terminal_size, winapi-util; getrandom 0.4.3→0.3.4 ×1). Verified forced-and-harmless here (all reqs permit 0.59/0.3.4, no advisories touched, only Windows-target transitive graph), but a dependency-bump PR that silently net-downgrades shared platform deps should say so. Note also that this PR's CI ran no Windows-target lane.

Cosmetic: manifest req is 0.41.0 while body/message/lock say 0.41.1 (caret resolves fine); commits are cleanly separable and order-independent.

Verdict: the two named advisory fixes are real, root-caused, minimal, reproducible, and fully validated (compile + 12.4k tests + deny repro) — but as-is the PR cannot merge green and does not fully deliver its stated purpose, and the commit identity breaks repo norms. Fix MAJOR 1 (rio-vt 0.5.29 + body/link line) and MAJOR 2 (identity), and this is a clean approve.

[asto18089]

随父仓 Pinvou/pinvou3#2519 评审落实新增第四提交 a4c83ad12（build(deps): 声明 1.89 与锁定图实际下限对齐）：

• 父仓评审（zhuowp，APPROVED 评语）非阻断建议指出：uuid 1.29.0 在 2026-11 通告升级前已入锁图且声明 rust-version 1.89，本 PR 的 rusqlite 0.41.1 再加同一下限，工作区声明的 1.88 与锁图矛盾且 1.88 构建失败不应归因本次升级。已实测确认（11cba403 锁中 uuid 即 1.29.0；本 PR 图中 rusqlite 0.41.1 与 uuid 1.29.0 均要求 1.89）。
• 变更：rust-version = "1.88" → "1.89"，注释改写（aes 0.9.2 锁针与 MSRV 脱钩、保留自身可复现性理由；回落条件 = 整个锁图不再含 1.89 要求 crate）。Cargo.lock 零改动，cargo metadata --locked exit 0。
• 父仓已同步 gitlink、fork-guard 钉头/计数与候选/维护头区分文档（821145fab）。

[asto18089]

两轮 fixwave 已核实并推送（新头 ceecedd94，树与 a4c83ad12 逐字节一致）：

采纳的修复（均已独立复验）

1. M1（门红）：e6bdda45c 补上 rio-vt 0.5.29（RUSTSEC-2026-0430）——本地 cargo deny check advisories 由红转 advisories ok；link 门已随 body 修复转绿；cargo-audit/cargo-deny CI 腿均 pass。锁逐字节复现：自 4adbbb9ed 锁执行 cargo update -p rio-vt -p teletypewriter -p rio-graphics -p rio-unicode -p rio-grapheme-width 得到与 e6bdda45c 完全一致的锁（diff exit=0），windows-sys 再统一与 serde-saphyr/base64 0.22.1 均为解析器强制。本地补验：cargo check --locked --workspace --all-targets exit 0、codewhale-state 28+6 绿、tui lib 12,407/0。
2. rust-version 1.88→1.89（a4c83ad12）：主张核实为真——uuid 1.29.0 在 base 锁内已存在且声明 rust-version 1.89（crates.io 实查），rusqlite 0.41.1 亦 1.89；1.88 声明确已不可信。采纳为 M1 的正确延伸，并已在 PR body 中如实披露这处非锁变更（原 body"零源码改动"不再成立）。
3. M2（probe@l4 身份）：四提交已重铸为统一 asto <asto18089@126.com>（author=committer=sign-off），树零变化（git diff a4c83ad12 cw-pr152-fixed 为空）；c2/c3 补记两条重归一披露，c3 补齐缺失正文。

本机（arm64）补充发现——非本 PR 所致，已记录不阻塞

runtime_api::tests::create_thread_accepts_dynamic_tools_and_environments 在 arm64 debug fresh build、默认 2MiB 测试栈下确定性栈溢出（套件跑至 ~5.5k 处 abort）。归因实验：base 11cba403d fresh build 同样溢出；4adbbb9ed 锁（回退后）同样溢出；RUST_MIN_STACK=8388608 即通过且全套件 12,407/0 绿。CI x86_64 nextest 腿（run 42774347833 "Test workspace: success"）绿。属 arm64 本地栈沿脆性，与本 PR 无因果——留档供后续单独处理（如测试内显式加大栈或拆深 future）。

[zhuowp]

批准固定提交 ceecedd 的源码变更，目标为 pinvou3-clean / 11cba40。累计 2 文件、32 个变更片段及 SQLite、MCP/OAuth、开发 PTY、锁引用和交付链已审核闭合，未确认阻断缺陷。

本波仅重写四个提交的身份与说明，整棵源码树及实际目标、消费者、配置和依赖均与已审 a4c83ad 相同；原五份独立源码凭据按范围重新限定，当前身份、消息、线上意见与交付影响另行核查，未把旧批准或旧测试冒作新首报/新执行。现四提交作者、提交者与签署一致且关联贡献者账号。

锁定的 libsqlite3-sys 0.39.1（bundled SQLite 3.54.1）、rmcp 3.9.0、rio-vt 0.5.29 达到三条目标通告修复线，实际功能选择与消费者相符。Rust 声明 1.89 与锁图对齐；CONTRIBUTING 的旧 1.88 文字可非阻断跟进。

同源码树的历史 a4c83ad CI 有 locked all-features nextest 15002 通过、15 跳过（1 slow / 2 leaky），以及原始 audit/deny 正向结果；audit 有既有 async-executor yanked 允许警告。当前 ceec 快照为 11 成功、1 neutral、2 进行中，不能称新提交全部门禁通过。现有证据不认证最低 Rust 1.89、所有平台、真实存量 DB 升级、在线 MCP/PTY 或安装发布；旧 SHA 的构建产物也不等于新 SHA 发行产物。

这是源码批准。合入仍须满足当前提交与目标的适用门禁和仓库流程；父 codewhale-hq#2519 仍固定 a4c83ad，须在子仓实际公开落地后核对维护头、gitlink、登记和适用 CI，不能以同树替代 SHA 等式或绕过门禁。本结论不授权合并或发布。

[asto18089]

rebase 到最新 base 37be2844f（#136 仅动 tui 源码，与本 PR 的 Cargo.toml/Cargo.lock 零交集，零冲突；delta 与 rebase 前逐字节一致，cargo metadata --locked / cargo deny advisories 复验 exit 0）。新头 a1b49087b，CI 重跑中。