|
|
560c462768
|
feat(mcp): GET /api/v1/mcp —— 投递侧事件流（让接入方被动收信，不用轮询）
## 这半边解决什么
工具面（POST）只解决「接入方**问**」。这一条解决「服务端**说**」：
邮件投递时把 new_mail / session_update 推给接入方，让它**拉起对话** ——
与各桥靠 /api/v1/events/stream 收信是同一件事，只是方言不同：
桥: id: 7\nevent: new_mail\ndata: {…}\n\n
MCP: {"jsonrpc":"2.0","method":"notifications/message","params":{…}}
## 为什么复用 sse.Manager 而不是另起一套
Manager 里那些东西**都是踩过坑才对的**：writeMu 串行化（2026-09-28 -race
实测 http.ResponseWriter 并发写会把 JSON 劈成半截，800 帧只切出 459 个完整）、
Last-Event-ID 回放（宁可重复也不丢失）、心跳（反代按空闲 30-58s 掐连接）、
环形缓冲上限、断线清理。复制一份等于把那些坑再踩一遍，
而两边的修复从此各走各的。
代价是 `sse.Client` 多了一个可选 `Frame` 钩子：
**nil = AgentMail 原格式，各桥与 WebUI 行为一字未变**（默认值即历史行为）。
## ★ 回放是第三条写路径，漏了就只在断线时现形
`Send` / `SendWithID` / `replay` 是三条写 Res 的路径。原先**三条都把格式写死**，
只改前两条的话：MCP 客户端**平时**一切正常，只有带 `Last-Event-ID` 重连时
才会收到一批自己解不开的帧 —— 同一个连接上两种方言。
判据 `TestCustomFrameAppliesToReplayToo` 专门钉这条，并带反向对照
（nil 帧必须回落 AgentMail 格式）。
`Frame` 必须在**注册时**传入（`AddClientWithFrame`），不能事后设 ——
回放发生在「先写响应、再注册」的前半段，事后设只影响之后推来的事件。
原先 `AddClient` 保留为薄封装，各桥与 WebUI 调用点一字未改。
## 判据（6 格）
Frame 是 JSON-RPC 2.0 通知 + 帧完整性（单事件、\n\n 结尾）
payload 原样嵌入（不是 JSON 字符串）—— 再 marshal 会让客户端解析两次
event_id / event_type 必带（前者是 Last-Event-ID 续传的依据）
Accept 判定（含 q 值、大小写）
匿名 GET → 401（不能变成静默的匿名订阅）
缺 Accept → 406（接错的客户端会静默收不到东西）
## 顺带修：TestAdvanceRecurrenceLunar 的时区缺陷（★ 今天第三次假红）
全量测试红了，查下来是**我今天早些时候改判据时引入的**，与本次改动无关。
农历换算必须按**本地公历日**算（`AdvanceRecurrence` 里那句
`eventTime.In(time.Local)` 就是这条规则）。库里读回的 EventTime 是 **UTC**
（DSN 用 `_timezone=UTC`），UTC 比本地晚 8 小时，跨零点时农历日差一天：
start (Local) = 2026-10-04 农历日 24
after (UTC) = 2026-11-01 16:00 农历日 23 ← 断言没换算时区（错）
after.In(Local) = 2026-11-02 00:00 农历日 24 ← 正确
服务端代码一直是对的，是判据没照做。失败信息里现在打印时区，
免得下次要重新推导一遍。变异验证：去掉 `.In(time.Local)` → 红 1 ✓
（这条判据是农历的第三次假红了：3459605「断言要求不存在的农历日」、
今天早些「起点写死日期 + advanceToFuture 跳过过期月份」、现在「没换算时区」——
三次都是判据自己写错，代码三次都对。它依赖 Local 时区与「今天」，
天生脆弱，值得记着。）
## 验证
go test ./... 14 包全绿
go test ./internal/sse/ 含新判据绿
go test ./internal/mcp/ 6 格新判据 + 原 19 格全绿
|
2026-10-02 15:37:34 +08:00 |
|
|
|
6757644756
|
fix(判据): 农历推进的起点必须在未来 —— 否则 advanceToFuture 跳过过期月份必假红
## 现象
部署被测试闸拦下（这正是纪律该做的事）：`TestAdvanceRecurrenceLunar` 报
「间隔 58 天不像一个农历月」。已确认与本次 SSE 改动无关
（把我的改动全部 stash 后它同样红）。
## 根因（实测复算，不是推测）
`AdvanceRecurrence` 走 `advanceToFuture`，职责是「推进到**未来**」：
已经过去的农历月会被跳过（`if cur.After(now) { return }` 那个循环）。
原起点写死 `2026-09-03`，而今天已是 10-02 ⇒ 那个农历月（10-02）已过去
⇒ 循环再推一个月。探针实测：
起点 2026-09-03 ⇒ 落点 2026-10-31 间隔 58 天 ← 旧起点，今天跑必红
起点 2026-10-03 ⇒ 落点 2026-11-01 间隔 29 天 ← 明天，正确
农历库本身是对的：直接调 `AddMonths(1).ToSolar()` 得到的落点恰好 29 天。
所以**不是代码缺陷，是判据的期望依赖了「今天离起点不到一个月」**这个
随日期漂移的前提。
## 修法
起点改为「明天」起算（不写死具体日期 ⇒ 明年跑也成立），
农历日的期望也跟着起点走。
★ 不用 `time.Now().AddDate(0,1,0)` 那种相对写法：农历月 29/30 天不定，
起点落在月末时下一个同农历日可能被夹（commit 3459605 记的同族假红）。
明天起算同时满足「确保在未来」与「落点就是下一个农历月」。
## ★★ 修判据时差点削弱了它（变异验证抓出来的）
把起点改成明天后判据绿了，但我立刻做变异验证：
变异：advanceToFuture 不跳过已过期月份 ⇒ TestAdvanceRecurrenceLunar **全绿**
因为起点在未来，第一个落点本来就在未来，循环与单步没有区别 ——
**我修好了假红，却顺手删掉了「跳过过期」这个真行为的判别力。**
补了一格：用**已过期 70 天**的起点单独钉它，落点必须在未来，
否则「每次扫描都重复触发同一封提醒」。变异重测 ⇒ 红 1 格。
这是同一天内第二次判据自身缺陷（第一次是 SSE 那格只查文本不查控制流）。
**改判据后必须变异验证判别力还在**，否则就是用改测试掩盖问题。
|
2026-10-02 10:57:59 +08:00 |
|
|
|
3459605dc0
|
修复: TestStaleLunarRecurringDoesNotFlood 是**日期相关的假红** —— 它要求一个不存在的日期
这条红不是"既有代码缺陷"，是**测试的期望写错了**。`go test ./...` 现已 **rc=0 全绿**。
## 形状：断言要求「农历日原样保持」，而目标月可能根本没那一天
if d := lunar.FromSolar(after.EventTime.In(time.Local)); d.Day != lunar.FromSolar(e.EventTime).Day
起点是 `time.Now().AddDate(-1,0,0)`，推进落到哪个农历月**随日期浮动**。
农历月 29/30 天不定 ⇒ 落到 29 天的月份时，"30 日"**不存在**，夹到 29 是
`ToSolar` 明确设计的行为（它连 `clamped` 都返回了）。旧断言却要求 30 ⇒ 必红。
实测（2026-09-21，起点 = 农历七月三十）：
落点 = 2026 年农历**八月廿九**，而该月只有 **29** 天
⇒ 正确结果就是 29；旧断言要 30 ⇒ 无论代码对不对都红。
**所以它是一条"日期相关"的假红**：每年那几天必红，与 `git bisect` 的结果无关。
pi 独立复核过它在**上次部署时的 HEAD `e8b260d`** 上同样 FAIL —— 与我一致。
## 我不是靠"看不见"修的：先排除了另外两种解释
- **不是时区/基准不一致**（我第一版猜这个）：探针打印了两个基准，
`e.EventTime` 未转本地 / 转本地，**农历日都是 30**，而左侧是 29 ⇒ 基准不是原因。
- 也不是推进逻辑多走了一步：`AddMonths(1)` 对 7月30 得 8月30（`Date` 只加月份），
是**后面 `ToSolar` 往 29 天的月里落时才夹**。
## 修法：期望取 `min(原日, 目标月天数)`
days, err := lunar.DaysInMonth(got.Year, got.Month) // 读不到就 Fatal，不静默
if want > days { want = days }
**没有放松真正的约束**：落到**长月**却少一天，仍然红。
变异验证：把 `RecurLunarMonthly` 的 `AddMonths(1)` 改成 `AddMonths(2)` ⇒
`农历日从 30 变成 29（目标月 30 天，期望 30）` **红**（在最终代码上重跑确认）。
## 由此**新发现**一条真缺陷（本次**不修**，因为要改产品语义）
顺着"夹取"往下量，发现 `addSolarMonthClamped` / 农历 `AddMonths` 的夹取是**粘的**：
公历 每月31日: 1-31 → 2-28 → 3-28 → 4-28 … （3 月有 31 天却停在 28）
农历 每月30日: 7月30 → 8月29 → 9月29 → 10月29 …（9 月有 30 天却停在 29）
一旦被夹过一次，**此后再也回不到原始日**。而 `calendar.go:401-405` 的注释恰恰把
"一次溢出永久改变规则"称作**要避免的** bug —— **注释说的和实现对不上**。
根因：落点被写回 `event_time`，而**没有一列保存原始锚点日**（`calendar_events` 无此列）。
要真修得加锚点列 + 迁移，改的是**产品语义**，不是本次部署能顺带做的 ⇒ 已如实报给 pi。
|
2026-09-21 05:06:53 +08:00 |
|
|
|
dc7bf57ceb
|
fix(calendar): 农历提醒按本地公历日推进，修正凌晨跨 UTC 日期错一天
# 现象
全量服务端测试稳定失败：
--- FAIL: TestStaleLunarRecurringDoesNotFlood
calendar_test.go:869: 农历日从 21 变成 20
不是随机失败，也不是测试写错 —— 是产品逻辑的真实缺陷。
# 根因
SQLite 的 DSN 带 `_timezone=UTC`（为了让 `expires_at > NOW()` 这类字符串比较
同一时间轴，见 db.sqliteDSN 的注释）。因此从库里 Scan 出来的 `event_time` 是
UTC 时刻的表示。
对公历重复规则，这无关紧要 —— `AddDate` 操作的是同一时刻的另一种表示。
但**农历换算直接读取 Year/Month/Day**：
本地 2025-09-12 07:00 (+0800) → 存库 → 读出 UTC 2025-09-11 23:00
农历(本地) = 七月廿一 → 农历(UTC 字段) = 七月二十 ← 少一天
后果：在本地时间 0:00–8:00（+0800）创建的农历提醒，之后每次推进都按前一天
计算，日期永久偏一天；而且只有等到下一次该提醒时才暴露，没有任何报错。
# 修法
在 `AdvanceRecurrence` 里，仅对两条农历规则把 event_time 转回 `time.Local`
再交给 `NextOccurrence`。
只转农历规则而不是无条件转：公历规则不需要，且 UTC 与 Local 表示同一时刻，
`AddDate` 在两者上结果相同 —— 无条件转会掩盖「DSN 时间是 UTC」这个事实，
让后来者更难判断该在哪一层做时区处理。
# 测试
新增 `TestAdvanceRecurrenceLunarUsesLocalCalendarDay`，用**固定日期**
（2025-09-12 07:00 本地）而不是 `time.Now()`，因此任何时刻跑都稳定；
并且它先断言测试前提成立：
- 库里读回的时刻确实与输入跨了不同公历日
- 直接按 UTC 字段做农历换算确实会得到不同的农历日
前提不成立就直接 Fatal —— 否则这个用例可能在某个时区/时段下变成永远通过的
空壳（那正是它要防的那类假绿）。
# 验证
- 新用例与原有的两条农历用例 ×10 连跑全绿（`-count=10`）
- `go vet ./...` 干净；`go test ./... -count=1` 全量通过
- 修复前该用例 5/5 失败，修复后 10/10 通过
|
2026-09-12 08:01:59 +08:00 |
|
|
|
f9d757b5e5
|
chore: directory migration - gateway→server, web→client/electron
|
2026-09-08 19:16:35 +08:00 |
|
