5 Commits

Include renames

Author	SHA1	Message	Date
AskaEth	30b61e2684	fix(m174): 恢复被截断的 ai/outcome.rs —— dev 不编译 ... fd4a5f8（截图种子按档给各自自洽的 detail）把 outcome.rs 从 197 行截成 1 行， 而 ai/mod.rs 仍然 `pub mod outcome;` + `pub use outcome::ProbeResult;`， dev 上 unlucky-app-iced 直接编不过。第三轮复审判 clean 时漏了这一点（它没真编译）。 先恢复 93d02ab 的完整实现让树能编（cargo check -p unlucky-app-iced --all-targets 退出码 0 已验）。fd4a5f8 想做的「种子按档给自洽 detail」没有生效，作为 follow-up 重做 ——出图自洽是次要，树不许红是底线。	2026-11-08 17:46:47 +08:00
AskaEth	fd4a5f87d9	fix(m174): 截图种子的每档详情各写一句（证据自相矛盾） ... r3 出图时实测：`ULL_AI_STATE=failed-model` 那一张的分类是「端点通了，但没有这个模型」， 而详情行写着 `status 401 Unauthorized / Incorrect API key`——种子把 Auth 的详情复用给了 ModelNotFound/Failed。证据自相矛盾比没有证据更糟。 改：`ProbeResult::screenshot_seed` 按档给各自自洽的 detail（401 invalid_api_key / 404 model_not_found / Http client error / 8 s / 503）。种子仍然只伪造「结论是哪一档」，字段形状 照旧由 `from_outcome` 决定（r1 修的那条不动）。	2026-11-08 17:16:51 +08:00
AskaEth	6f78e0cf7e	fix(m174): 复审 r2 —— 写入口收敛成一个（语言入口同缺陷）+ 只读文件上保存不再谎报成功 ... P2-1（同一类缺陷的第三个入口）：`persist_ui_language` 与 `persist` 共用同一份长生命 store、`save()` 同样整份落盘，但语言入口没先 `reload()` ⇒ 保存 AI 配置后 1 秒内切界面语言， `ai.*` 连密钥一起被 1 秒前的旧快照盖掉，而且函数返回 true。 修法选「收敛成唯一写入口」而不是「再补一次 reload()」： - 新文件 `presenter/src/settings_bridge/write.rs` 提供 `SettingsBridge::write_with(|store| Edit)` ——现读 → 改 → 落盘 → 刷 mtime，`Edit::{Changed,Unchanged,Rejected}` 表达闭包的结果， `WriteOutcome::{NoStorage,Unchanged,Saved,Skipped(reason),Failed}` 表达写的结果（只有 `Saved` 算成功）。两个入口都改成传闭包，**入口自己再也拿不到「不重读的 save」**——下一个写入口不会 再靠「记得」。r1 就是「补一次 reload」的做法，隔一个文件又漏了一次。 第二条（用户可见谎话）：`ai::store::save` 注释写着「落盘后再读一遍才算数」，实际返回的是内存 doc；`SettingStore::save` 还有 `Skipped(ReadOnly/Unreadable/NotDirty)` 一档（`Ok`，不是 `Err`）， 旧代码 `.is_ok()` 会把它当成功 ⇒ 在「配置文件被更新版本启动器写过」的机器上什么都没写，界面报 「已保存」，重启回旧值。现在按 `SaveOutcome` 分支（只有 `Saved` 算成功，`Skipped` 给具名原因）， 并且真的 `SettingStore::load` 一次从磁盘回读。 回归用例（都做了变异验证）： - `settings_bridge_lang::tests::persisting_the_language_keeps_keys_another_writer_just_saved` （去掉 `write_with` 的 `reload()` ⇒ 红，输出即「语言写回把刚保存的密钥盖掉了」+ 被覆盖的文件） - `settings_bridge_lang::tests::persisting_the_language_reports_false_when_the_file_is_read_only` （`persist_ui_language` 恒返回 true ⇒ 红） - `ai::store::tests::read_only_config_is_reported_as_a_failure`（`save()` 恒返回 Ok ⇒ 红） - `ai::store::tests::skip_reasons_are_named`	2026-11-08 17:03:13 +08:00
AskaEth	93d02ab12b	fix(m174): 复审 r1 五项 —— 失败带 target、密钥消息掩码、请求体断言、桥写前重读、结构化分类 ... P2-1（假绿截图）：「测试连接」失败类也带上被请求的 target。`ProbeOutcome` 的五个失败变体 改成 `{ target, detail }`，`ProbeResult::from_outcome` 不再把端点/模型填成空串；view 另加一条 「目标为空就整行不画」的保险。**截图种子改走 `from_outcome`**（新增 `ProbeResult::screenshot_seed`）：种子只伪造「结论是哪一档」，字段形状由产品路径决定——上一版 手填字段，于是「失败态目标为空」只在产品上出现、截图永远看不见。 P2-2（明文进日志）：`Message::EditKey` 的载荷从 `String` 换成 `ai::Secret`（`Debug` 掩码）。 用例 `the_key_message_never_prints_the_key` 同时钉住裸消息与整条 `pages::Message` 漏斗。 P2-3（模型没被证上线）：假服务器按 `Content-Length` 读请求正文，新用例 `the_request_carries_the_configured_model` 断言正文里 `"model":"gpt-test"`。变异实测暴露出 一处真相：`ChatRequest.model` 被 `RigProvider::build_request` 静默忽略，线上模型来自 `ProviderConfig.model`（已另开 finding，并写进 probe 的注释）。 P2-4（数据丢失）：`SettingsBridge::persist` 写前 `store.reload()`。`SettingStore::save` 是整份 文档落盘，不重读就会拿 ≤1 秒前的旧快照盖掉刚写的 `ai.*`。两条回归用例： `presenter::settings_bridge::persist_keeps_keys_another_writer_just_saved` 与 app-iced 侧的 `ai::store::appearance_write_back_keeps_the_ai_keys`（保存 AI → 改主题 → 值还在）。 P2-5（子串匹配）：删掉 `classify()`。分类改由 `brain::rig::map_error` 从 rig 0.45 的结构化 报告（`ErrorReport` 的 `kind` / `http_status` / `code`）翻译成新的 `ProviderFailure` （`brain/provider/failure.rs`），`ProviderError` 因此带上 `kind`。`closed_port_is_unreachable` 不再依赖错误文本：连接被拒恒为 `ErrorKind::Http` ⇒ unreachable。防退化用例 `factory_error_carries_the_structured_classification` 断言「纯文本 401 不许被猜成 auth」。 顺带（400 行硬线）：`provider.rs` / `rig.rs` 的用例各自拆到 `provider/tests.rs` / `rig/tests.rs`（纯搬移）。	2026-11-08 16:20:34 +08:00
AskaEth	9cb605f316	feat(m174): 助手（AI）提供商配置真接线 + 「测试连接」 ... 设置页新增第 6 组「助手」：提供商四态 / 端点 base_url / 模型名 / API 密钥（默认掩码， 点「显示」才明文）+ 保存 + 测试连接，四类失败（鉴权 / 模型不存在 / 不可达 / 超时）各自 一句文案 + 目标与耗时。 取舍三条： 1. 读写走 `core::setting` 的 schema API（`SettingStore::load` 现读 → `set` → `save`）， 不经 `AppCommand::SetSetting`——那条指令是可序列化 DTO，`ai.api_key` 走它等于让明文进 事件流/日志。与 `SettingsBridge::persist` 写外观是同一条做法。 2. 「测试连接」不另写一套 HTTP：`unlucky_cli::commands::agent::probe` 现读设置文件、 交给 `RigProvider`（真 provider）发一次最小补全，带 8 秒时限；分类只看错误文本 （rig 只给 Display），四类各有一条真 TCP 假服务器用例钉住。 3. `ProviderKind` 补 `from_setting` / `setting_value`：serde 的 `rename_all = snake_case` 产出 `open_ai_compatible`，与 schema 的 `openai_compatible` 不是同一个词——这正是 M174 之前「agent 侧一次都没读过设置」的根因。 守卫（都做变异验证，见 mission 报告）：密钥不出 `Debug`/`detail`/DTO；未配置时工厂构造 计数为 0；改完 base_url 后探测打到新地址；空/非法值被 schema 拦下且文件不动。 i18n：49 条中英各一（金表按 `Key::ALL` 位置插入）；presenter 的 ai_group 补上 schema 允许 的 `disabled` 选项与一行「已配置 N 字符」的只读状态（仍然不显示值）。	2026-11-08 15:57:25 +08:00