C12.5: mail accounts, add and remove

ElyMail's window lists accounts and adds Gmail, Microsoft, iCloud
(app-specific password), IMAP and POP3 ones; a check logs in to both
servers and reports each. Accounts live in the store as JSON with a
case-insensitive unique address; secrets go to the keychain. Removal
names the cache it deletes, takes the secret first and puts it back
when local removal fails. Originals are set aside until commit and
restored after a crash. Requests are numbered so late results stay
with their own dialog. The account list is keyboard-navigable.

tasks/TASKS.md

@@ -138,7 +138,7 @@
 - [x] C12.2 MIME（MAIL-04、05 的基础）：mail-parser 读出头、纯文本、HTML、cid 内嵌图片、附件与原始头；mail-builder 写出多部分邮件、附件、Message-ID、In-Reply-To 与 References；样本 EML 往返测试。已做：`read` 得 `Mail`（主题、发件人、收件人、抄送（分组展开）、日期、Message-ID、In-Reply-To、References、纯文本、HTML、`inline`、`attachments`、原始头块）；按 MIME 树与所在容器读（不用 mail-parser 摊平的列表）：正文只取发件人写的部分（mail-parser 会把 HTML 转成文字或反之顶替缺的一种，不取）；alternative 里纯文本与 HTML 各取最后一个（RFC 2046 §5.1.4），其余版本不并入，没有正文的版本（如日历）为附件；related 的根照 `start`，无 `start` 取首个（RFC 2387），其余带 Content-ID 的即 cid 目标，不论处置；mixed 等的部分依次并成正文；处置为 attachment 的实体整个是附件，多部分实体连同其头（RFC 2183 §2.9），子孙不进正文；附件字节只解传输编码，文字附件不按字符集转换；不在 related 里的部分，带 Content-ID 且不是 attachment 的为 cid 目标；无 Content-Type 照 RFC 2045 为 text/plain，digest 的子部分为 message/rfc822；解码有问题的部分与无地址的收件人记警告。`build` 由 `Draft` 写出（密送不进信头，留在 SMTP 信封）：Message-ID 为 16 字节随机数加发件人的域（mail-builder 默认写本机主机名，不用），交回供发件记录；地址照 SMTP 的 Mailbox 核对，主题、姓名、Message-ID、文件名、类型带换行即拒绝；附件须有文件名，Content-ID 照写（带换行即拒绝）；正文与附件自己组成 mixed 与 alternative。`tests/fixtures/mail/sample.eml` 读全；由它回复写出再读回，各字段与附件（名、类型、Content-ID、含 0 至 255 每个字节）相同；第 1 轮审查后另 7 个结构测试（`tests/mime_tree.rs`：Latin-1 文字附件、`start` 在图后、related 里标为附件的图、附件化的多部分、同型 alternative、digest），去掉各自的修复即失败；第 2 轮审查后：嵌套深于 64 层即报错（先以迭代算出深度，原递归在 2048 层时栈溢出、进程退出）；mail-parser 开 `full_encoding`（原 GB2312 等多字节字符集读成替换字符）；`Part::params` 带 Content-Type 的参数（不含 name），写出时照写，转发的 Latin-1 附件收件方读出 Café；多部分与 message 附件照原样写出（不编码，7bit 或 8bit，多部分带原分界，RFC 2045 §6.4），SMTP 遇 8 位正文即带 `BODY=8BITMIME`，服务器不支持即在发出前拒绝；related 的根不看处置，其余每个资源整个是一个实体（多部分资源带其 Content-ID 与文件名）；带 Content-ID 的正文文字部分另为 cid 目标（related 的根除外）；未知处置照附件（RFC 2183 §2.8）。另 9 个测试（`tests/mime_edges.rs`、`tests/mime_forward.rs`，SMTP 一个），去掉各自的修复即失败；第 3 轮审查（最后一轮，修完不再审查）后：深度也数内嵌的邮件（mail-parser 以迭代读出层层相套的 message/rfc822，丢弃时却递归，8192 层即栈溢出），超深的解析结果以迭代逐层拆开再丢；带 Content-ID 的多部分实体（related 的根除外）连同其头另为 cid 目标，子孙照常读；SMTP 按每一层的头块判定是否需 SMTPUTF8（转发的 message/global 里的中文主题），只深入未经传输编码的内嵌邮件；每次发送都先解析邮件，不是邮件即拒绝。另 5 个测试（`tests/mime_deep.rs` 四个、`tests/smtp_utf8.rs` 一个；SMTP 的编码测试与辅助函数移入 `tests/smtp_utf8.rs` 与 `tests/fake/smtp.rs`），去掉各自的修复即失败或栈溢出；原往返测试按子串查 bcc，随机的 Message-ID 约四十次一次含 bcc 而误报，改为查 `Bcc:` 头行；引擎共 61 个测试
 - [x] C12.3 本地存储（§12.3、§18.1、§18.3）：SQLite 索引（账号、邮箱、消息身份为账号加邮箱加 UIDVALIDITY 加 UID、标记、头字段）、原文按内容存进内容目录、FTS5 全文索引（可重建）、结构版本与升级前备份、升级失败只读；各类大小可查。已做：`Store`（rusqlite，自带 SQLite 3.53.2，FTS5 与 dbstat）在给定文件夹开 `mail.db`（WAL，外键开）；表 accounts、mailboxes（账号加名字唯一）、messages（身份为邮箱加 UIDVALIDITY 加 UID，POP3 为邮箱加 UIDL，两者恰居其一，各有部分唯一索引；头字段：Message-ID、In-Reply-To、References、主题、发件人、收件人、抄送（JSON）、日期；附件数在整封到达前为空）、flags（每标记一行）；原文按 SHA-256 存在 `content/前两位/散列`（暂存后改名，同内容只存一份，读时核对散列，不符即报“已损坏”，最后一封引用它的邮件删去时删文件）；同一身份再来头部只改标记，整封到达即补原文、附件数与正文索引；FTS5 表 `search`（主题、人、正文、附件名，无内容副本，trigram 分词，删邮件的触发器同删索引行），HTML 独有的正文以 html5ever 分词器取文字（略去 script 与 style，标签处断词）；`rebuild_search` 由索引行与原文重建；`PRAGMA user_version` 记结构版本，升级前以 `VACUUM INTO` 备份到 `backups/`，各步在一个事务里，备份或升级失败即以只读重开、写入报 `ReadOnly` 并带原因，更新的版本写的库同样只读；`sizes` 给索引、全文索引（dbstat）与原文三类字节数。测试：结构版本 5 个（新库、升级先备份、失败回滚且只读、更新的版本只读、无备份不升级），存储 6 个（整封、先头后整封、UIDVALIDITY 与 POP 身份、共用原文、损坏原文、HTML 正文与重建），去掉各自的规则即失败；引擎共 72 个测试。第 1 轮审查后：重建先删去整张全文表再按库里记的定义重建（损坏的段删不掉）；存原文时已有的文件先核对散列，坏了即以本次收到的字节改写；写库失败时删去本次新建且无人引用的原文；`sizes` 的索引按 `mail.db`、`-wal`、`-shm` 的实际字节减去全文页；HTML 取文字照树构建器给分词器的状态（script 为脚本数据，style、iframe、noembed、noframes 为原始文本，title 与 textarea 为 RCDATA，xmp 与 plaintext 照显示，自闭合在 HTML 元素上无效；SVG 与 MathML 里自闭合有效、script 与 style 的文字略去）；给不存在的邮件设标记即报错。`tests/store_repair.rs` 6 个，去掉各自的修复即失败；引擎共 78 个测试。第 2 轮审查后：HTML 取文字改走 html5ever 的整个树构建器（`store/html.rs`，自建的节点表作 `TreeSink`，脚本关闭），命名空间、整合点与插入模式全由它定，不再自仿分词器状态；不画的元素照 HTML 渲染规则（script、style、title、head、iframe、template 等）略去；树构建器每个开始标签都扫一遍开放元素栈，嵌套越深越慢（实测 release：十万层 div 28 秒），故按 4 KB 分块喂入，元素深过 512 层（同 Blink 的上限）即停，已读的文字照常入索引，警告写明哪封邮件；暂存原文写入或改名失败时删去暂存文件，删不掉即连同原因报错。`tests/store_repair.rs` 共 8 个；去掉清理、不画元素、MathML 整合点、深度上限即各自失败。第 3 轮审查后（最后一轮，修完不再审查）：删除与替换邮件时，原文文件在同一事务提交之前删去，删不掉即整步回滚，邮件与原文都留着、可重试（原先先提交再删文件，失败后失去引用，文件永久残留）；提交在删文件之后失败时，下次清理遇文件已不在只记警告；两处超长注释缩短。`tests/store_release.rs`（Windows，以只读共享占住文件）2 个，删去与替换各一，改回先提交即失败；引擎共 82 个测试
 - [x] C12.4 凭据与 OAuth（MAIL-02，§18.2）：密码与刷新令牌只进系统凭据库（不可用即只留到本次退出并写明）；Gmail 与 Microsoft 的授权码加 PKCE、本机回环、换令牌与刷新；客户端 ID 编进构建，缺 ID 即写明不可用；刷新被拒转为“需重新登录”；替身授权端点测试。已做：`Vault`（keyring：钥匙串、Windows 凭据、Secret Service；拒绝时只在内存，`Kept::Session` 带原因）；`oauth::SignIn` 在 127.0.0.1 随机端口等回跳（Google 写 127.0.0.1，Microsoft 写 localhost），state 与 S256 PKCE 各 32 随机字节，回跳的 state 不符或带 error 即报错，其余请求答 404；换令牌与刷新经 ureq（后台线程，30 秒），刷新答 invalid_grant 或 interaction_required 即 `SignInAgain`，其余为 `SignIn`；邮箱取 ID 令牌的 email，Microsoft 无则 preferred_username；客户端 ID 由 build.rs 读环境变量或项目根 `oauth.env`（坏行、未知键即构建失败），缺即 `Unavailable`；`tests/oauth.rs` 以替身令牌端点与替身浏览器核对，`tests/vault.rs` 以替身凭据库核对。审查三轮：第 1 轮四处（Google 授权带 `access_type=offline` 与 `prompt=consent`、换码无刷新令牌即报错；Microsoft 另要 `profile`；`oauth.env` 读不出即构建失败、不存在为未配置；超长注释）、第 2 轮一处（ureq 在 trace 级写出令牌与客户端密钥，`ely_platform::logging` 不记 `ureq`、`ureq_proto` 低于 info 的日志；`tests/private_oauth_logs.rs` 以真日志器在 trace 下核对，改回即失败）已修，第 3 轮通过
-- [ ] C12.5 账号（MAIL-01、02）：ElyMail 主窗口与添加账号对话框：Gmail、Microsoft、iCloud（应用专用密码向导）、其他 IMAP/SMTP、POP3/SMTP；服务器、端口、TLS 方式、认证方式；连通性检查逐项报结果；多账号；删除账号先写明删去的本地缓存、草稿与凭据，不动服务端
+- [x] C12.5 账号（MAIL-01、02）：ElyMail 主窗口与添加账号对话框：Gmail、Microsoft、iCloud（应用专用密码向导）、其他 IMAP/SMTP、POP3/SMTP；服务器、端口、TLS 方式、认证方式；连通性检查逐项报结果；多账号；删除账号先写明删去的本地缓存、草稿与凭据，不动服务端。已做：引擎 `Account`（地址、用户名、`Auth` 为密码或 Google、Microsoft 的 OAuth，`Protocol` 为 IMAP 或 POP3，收发两个 `Server`），以 JSON 存在 accounts 表的 settings 列（结构 v1 未发布，直接改，不加升级步）；`valid` 照 SMTP 的 Mailbox 核对地址，用户名不空不带换行，主机不空不带空白，端口非零；`check` 同时登录收发两个服务器再退出，各自报结果；`Store::cached` 给该账号的邮件数与只属它的原文字节，`remove_account` 在一个事务里删账号（邮箱、邮件、标记随外键删去）与只属它的原文，原文在提交前删、删不掉即回滚，与别的账号共用的原文留着；凭据库名为 `account:地址`。应用：主窗口左栏列出账号（地址与协议、收信主机），中间为所选账号的地址、用户名、收发服务器、登录方式与“删除账号…”，无账号时为空状态与“添加账号…”；“账号”菜单两项。添加对话框分 Gmail、Microsoft、iCloud、IMAP、POP3：Gmail 与 Microsoft 填可选的地址作登录提示，“以 Google/Microsoft 登录”开浏览器，回来后以 ID 令牌的地址与访问令牌检查两台服务器，构建缺客户端 ID 即提示条写明并禁用按钮；iCloud 写明生成应用专用密码的步骤并可开 Apple 账户，服务器固定（imap.mail.me.com:993 TLS，smtp.mail.me.com:587 STARTTLS，两者用户名都用完整地址，Apple 写明可用）；IMAP 与 POP3 填地址、登录方式（密码或两种 OAuth）、用户名、密码、收发主机、端口与加密，改加密时端口随之换成惯用的，手填的端口不动。“检查”逐项报收信与发信服务器（连不上、TLS 失败、拒绝登录及服务器原话等，按界面语言），通过才可“添加账号”，之后改任一字段即回到编辑；后到的检查与登录按编号丢弃，关对话框即中止网络任务；同一地址（不分大小写）不重复添加。保存先写库再存凭据，凭据库拒绝即提示只保留到退出。删除先在后台量出缓存，对话框写明删去的邮件数与大小、草稿与保存的密码或登录、服务器上的邮件不动；先删凭据，删不掉即不删账号并报错。库与网络都在后台（库在锁后，网络在两线程的 tokio 运行时），提示文字不进日志（可能含地址）。测试：引擎 `tests/accounts.rs` 6 个（往返、地址唯一、删去时留下共用原文与量缓存、两台服务器都登录、各自报结果、不合的设置），应用窗口测试 8 个（缺项逐个写明、端口随加密、检查逐项报连不上且改字段回到编辑、iCloud 的服务器、缺客户端 ID、凭据库拒绝仍保存并留在本次、保存与重开读回再删去且凭据随之删、凭据删不掉即留账号），去掉各自的规则即失败；真窗口冒烟（`ELY_SMOKE=1`）画出一帧。未验证：真实的 Gmail、Microsoft、iCloud 与其他服务器（须用户的客户端 ID 与账号）。第 1 轮审查后：删去或替换的原文先改名留在原处，提交后才删、失败即改回，打开库时收拾中断留下的（引擎 `tests/aside.rs`：第二个原文删不掉时两个都还读得到，重开后放回或删去）；删除确认按钮带着所删的账号（原先关闭回调先清掉状态，按了什么也不删），测试改按真的按钮；端口以上次自动填入的值判断是否键入（原先把惯用端口当未键入，IMAP 收信填 995 会被冲掉）；请求在整个窗口编号，保存的结果只作用于仍在等它的对话框（原先会关掉或改写之后新开的对话框），测试 `a_late_save…`、`a_late_failed_save…`；去掉各修复即失败。第 2 轮审查后：本地删除失败即把读出的凭据放回（凭据库拒绝时只放回本次并写明），账号仍可登录（`a_failed_removal_puts_the_secret_back`：原文的停放处被占，删除失败后凭据、账号与原文都在）；地址唯一由库保证（`address` 不分 ASCII 大小写，`add_account` 遇冲突报 `Error::Taken`，对话框写明已添加），两个在途的保存不再都成功（`two_saves_in_flight_add_an_address_once`）；左栏账号列表改用组件库 `SelectableList`（一个 Tab 停靠点，上下键选账号，`the_keyboard_picks_another_account`）；去掉各修复即失败。第 3 轮审查后：凭据库删不掉时内存里的凭据照留（`Vault::remove` 先删凭据库，成功才清内存），凭据库不可用时添加的账号删除失败后仍能取回凭据（`a_Line truncated
 - [ ] C12.6 IMAP 同步（MAIL-14，§12.3，QA-18）：文件夹列表与特殊用途；邮件头全部、正文只取 90 天内；UIDVALIDITY 变化即重建该邮箱；服务端删除与标记变化随之；后台任务执行，界面显示最后同步时间、下载范围、未缓存的数量与失败原因
 - [ ] C12.7 POP3 收取（MAIL-01，§12.3）：按 UIDL 去重下载到本地收件箱，“保留服务端副本”默认开，不做伪文件夹同步
 - [ ] C12.8 同步控制（MAIL-14）：手动刷新、运行期间定时同步、暂停、按文件夹完整离线下载

tasks/reviews/C12.5-r1.md

@@ -0,0 +1,11 @@
+FAIL
+
+1. **[P1] crates/ely-mail-engine/src/store/accounts.rs:74** — 删除账号逐个永久删除原文，后续失败时只回滚 SQLite，已删除的文件无法恢复。Windows 探针给同一账号存两份不同原文，占住删除顺序中后一份文件；`remove_account` 报共享冲突，账号和两条消息仍在，但前一份原文已丢失，`original` 报文件不存在。这违背删除失败保留数据、可重试的行为。应让整批原文删除可恢复，任一文件操作或提交失败时恢复之前处理的原文，并补上多文件中途失败的回归测试。复现见 `.work/C12.5-r1/engine-probe.log`。
+
+2. **[P1] apps/ely-mail/src/view.rs:120** — 删除确认按钮实际不删除任何账号。钉住的 `ConfirmDialog` 先调用关闭回调，再调用 `on_confirm`；这里关闭时先将 `mail.removing` 清空，随后 `Mail::remove` 在 `removing.rs:49` 直接返回。窗口探针按 Tab、Tab、Enter 确认，日志记录了 confirmed 和 closed，但账号数仍为 1，凭据也没有删除。现有测试直接调用 `Mail::remove`，绕过了此路径。应把待删目标捕获并传给确认操作，使其不依赖关闭时清掉的状态，并通过真实确认按钮测试。复现见 `.work/C12.5-r1/ui-probe.log`。
+
+3. **[P2] apps/ely-mail/src/adding.rs:148** — 是否自动填写端口仅按数值是否属于六个惯用端口判断，且修改任一服务器的加密方式都会重写两个端口，无法保留手填值。探针在 IMAP 表单手填收信端口 995，再仅将 SMTP 从 STARTTLS 改成 TLS，收信端口即被静默改为 993。自定义端口的账号因此会检查错误的端点，也与 C12.5 所述“手填的端口不动”不符。应逐字段记录自动值与用户编辑状态，只更新相应服务器尚未手填的端口，并覆盖手填值恰为其他协议惯用端口的测试。复现见 `.work/C12.5-r1/ui-probe.log`。
+
+4. **[P2] apps/ely-mail/src/flow.rs:239** — 保存结果未绑定发起保存的对话框，会清掉后来打开的另一份添加表单。保存账号 A 的后台库操作尚未结束时，用户仍可取消对话框、重新添加并填写账号 B；A 保存完成后无条件执行 `mail.adding = None`，B 的输入全部消失。探针用存储锁延迟 A 的保存，重开并填写 B 后释放锁，稳定复现。失败回调的 `halt` 同样会改写新对话框。应将保存回调绑定其所属对话框；账号列表照常更新，只对仍匹配的表单更新状态或关闭。复现见 `.work/C12.5-r1/ui-probe.log`。
+
+5. **[P3] apps/ely-mail/src/mail.rs:1；apps/ely-mail/src/removing.rs:1** — 两条新增模块注释各有 11 个词，超过项目规定的十词上限。运行 `python tests/scripts/comments.py` 会将两处列为失败。应将它们缩短到十词以内。检查输出见 `.work/C12.5-r1/comments.log`。

tasks/reviews/C12.5-r2.md

@@ -0,0 +1,7 @@
+FAIL
+
+1. **[P2] apps/ely-mail/src/removing.rs:62** — 凭据先被永久删除，随后本地账号删除失败时没有恢复。Windows 探针以只读共享占住原文，再通过真实确认按钮删除：文件操作失败后账号和原文仍在，但 `vault.get` 已为 `None`，留下无法继续登录的账号；界面只报账号未删除。应在存储失败时恢复原有凭据，保持失败后的账号可用，并覆盖文件删除失败与只读存储的回归路径。复现见 `.work/C12.5-r2/ui-probe.log`。
+
+2. **[P2] apps/ely-mail/src/side.rs:28** — 账号行使用只有鼠标点击的 `ListItem`，没有 Tab 停靠或键盘选择。已有两个账号时，键盘用户无法切到第二个账号，也无法操作它的删除；窗口探针循环 Tab、方向键、Enter 后仍选中第一个账号。此处违反项目对可按压元素的焦点规则。应使用组件库带键盘导航的列表，把选择事件接到 `pick`，并添加键盘切换账号的窗口测试。复现见 `.work/C12.5-r2/ui-probe.log`。
+
+3. **[P2] crates/ely-mail-engine/src/store/accounts.rs:23** — 存储层按原样插入地址，只防止大小写完全相同的重复；界面不分大小写的检查只看已返回的账号列表。第一次保存 `ann@example.com` 尚未完成时，取消并重新添加 `ANN@example.com`，两次检查都能通过，两个保存最终都成功。探针用存储锁延迟保存，确认重现两个重复账号，违背 C12.5 声称的同地址不重复添加。应在存储层原子地执行与界面一致的地址唯一约束，并覆盖两次保存尚未返回的情形。复现见 `.work/C12.5-r2/ui-probe.log`。

tasks/reviews/C12.5-r3.md

@@ -0,0 +1,3 @@
+FAIL
+
+1. **[P2] apps/ely-mail/src/removing.rs:63** — 凭据删除自身失败时仍会丢失本次会话的密码或刷新令牌。`Vault::remove` 先移除内存副本，再尝试系统凭据库；这里的 `?` 直接返回，绕过后面的凭据恢复。Windows 窗口探针让凭据库拒绝写入与删除，添加账号后确认密码仍在本次会话，再通过真实确认按钮删除：账号保留，但 `vault.get` 已为 `None`，未退出应用就失去登录凭据。第 2 轮修复只覆盖了本地数据库删除失败。应让凭据删除失败也保留或恢复先前读出的会话凭据，并补上凭据库不可用时添加账号、删除失败后仍能取回凭据的回归测试。复现见 `.work/C12.5-r3/ui-probe.log`。