JianFeeeee
863b583838
fix(已读/文档): 空 reader 报错（把约定变成做错会红）；P6 方案补分支声明与可验收性；"与 X 一致"入册
pi 2026-09-14 对 P6 方案的五条，逐条处理（都不改方向）。
1. **§4 已读按读者的强制点** —— 他说得对，但实际情况比他担心的更靠前也更靠后：
HTTP 层取的是 `user.Username`（**不是请求参数**，所以根本不可能"省略 reader"），
但 **repo 函数本身接受空串**：`MarkMailRead(ctx, id, reader)` 会照写一行
`reader_name=''` —— 不属于任何人，却会让"未读"统计出偏差，而且没有任何东西会红。
已加守卫（空/纯空白 → 报错，不兜底）＋判据（不仅"不许插垃圾行"，且**必须返回错误**；
另含正例，防止把守卫写成"一律拒绝"）。变异验证：撤掉守卫 → `空 reader（""）必须报错`。
顺带一条给他的更正：同一个函数结尾还有 `UPDATE mails SET status='read'`（**行级**全局写），
所以"按读者"这个性质只对**用 `mail_reads` 派生的数据**成立（`CountUnread`/`ListInbox` 是），
读 `mails.status` 的客户端仍然是邮件级语义 —— 两件事在同一个函数里，容易被看漏。
2. **§2 手势阈值**：核实结果 —— **WebUI 侧没有被任何判据钉住**（`CalendarView.tsx:204`
裸字面量 `Math.abs(dx) < 40 || Math.abs(dx) < Math.abs(dy) * 1.5 || !fast(600ms)`）。
所以撤掉"与 WebUI 一致"的写法，改标 **「待两边对齐」**（文档两处），并把他给的推广写成
规范 `CRITERIA.md` §12：**凡"与 X 一致"的判据，前置条件是 X 侧那个值自己有判据钉住**，
否则测的是"我抄的那一份" —— 与"两张表各缺一半时必须按 id 联接"同一族。
3. **§1 分支声明（最要紧的一条）**：写进 P6 分期段 —— 本步实现的是**窄屏那条**
（**容器自身带圆角 + 那一层能裁剪**）；宽屏那条（起始侧/结束侧分开给）**不适用**，
因为它的理由是"中间是分隔线、四角全给会露底色"，而手机是单栏、中间没有分隔线。
并写死这句：**"给对边"是跟着"中间有没有分隔线"来的，不是无条件的三件套。**
同时核实并写清现状：鸿蒙侧**还没有日历页**（全 ets 树无任何 calendar 提及）⇒ P6 是整页新建。
4. **§3 可验收性**：P6 三步各加一列 —— 第 1、2 步**本工作区可验收**（读 `.ets` 层结构），
并明确"**第 2 步不需要设备，不许登记成 `static` 欠账**"（那会虚增余额）；第 3 步
**必然进欠账**（要设备：能装、能点），到期前提见探针表。
5. **§5 路由**：不再把 WebUI 改动挂成"等 pi"（他这条链上没有 shell）。按他给的三级路由执行：
优先在鸿蒙侧引用**已有令牌**解决；必须动 WebUI 时找 gui-lab 或按先例自己改。
2026-09-14 17:03:16 +08:00
..
2026-09-14 11:07:03 +08:00
2026-09-14 17:03:16 +08:00
2026-09-08 19:16:35 +08:00
2026-09-08 19:16:35 +08:00