XiaChangSong/BPOS-TMP-REPO
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
239 Commits 1 Branch 0 Tags
d133d6c2a89f0f92a8fa8cac77a53dc5fe54e08e
Commit Graph
14 Commits
Author SHA1 Message Date
xcsandClaude Fable 5 816389a185 邮件收发终审修复轮:token 按凭证指纹、毒信有退路、只改发信设置不丢信、重发先抢、列表不搬原件、save 不盖运行列、重锚出声、脏游标不炸页、线程口径归一 
全分支终审(跨任务视角)逮出的十条 P0 + 八条 P1,一次修完。每条都配了测试。

P0-1 企业微信 token 缓存改按**凭证指纹**(sha256(corpId,corpSecret),secret 不进 Map 的键):
  按 account.id 存有两条真实串号路径 —— 草稿探测共用 'draft'(探完 A 公司再探 B 公司会命中 A 的
  token,回的是 A 的应用邮箱地址,凭证填错的 B 也显示成功);已存账号换了凭证 id 不变,
  下一轮轮询继续拿旧 token 拉旧 corp 的收件箱,分发给新账号绑的通道(窗口 ≤ 7200s)。
P0-2 一封「毒信」不许卡死整条路:①domain 的 buildInboundRecord 把落 text/jsonb 的字段一律剥 NUL
  (PG 拒收它,MIME 解出二进制垃圾时真会出现);②单封失败先落**降级骨架**(原件原样存、
  主题从原始字节扒、正文写明失败原因)→ 落成了就推进游标并把「第 N 封(providerRef)解析失败,
  已降级存档」写进 last_poll_error;骨架也落不下才停在这一封,那时 error **点名是哪一封**。
  降级行不自动分发(正文是失败原因,不是客户的话)。
P0-3 cursorReset 只比**收侧**键(imapHost/imapPort/imapTls/login/folder;corpId/apiBase):
  从前比全部 settings,把 465 改成 587 也会清游标 → IMAP 重锚 → 上次游标到重锚之间的来信永远不拉。
P0-4 复用旧行重发**先抢**(OutboundStore.claimForResend,一条条件更新;真 store 与内存件同款):
  两个后端连同一个库,两台同时重放同一次放行都判「超时可复用」→ 两封真邮件,破掉「同键不发两封」。
P0-5 列表与只要元信息的读**不取 raw**(一封上限 16MB × 200 行);rawAvailable 由 `raw is not null`
  投影,不靠取回字节再判;只有「下载原件」走全列的 get()。InboundRecord 新增 rawAvailable。
P0-6 账号 save() 只写**配置列**:运行列(cursor/last_polled_at/last_poll_error/last_inbound_at/
  polling_until)只经 savePoll/claimPolling/releasePolling 改 —— 整行 upsert 会把另一台正持着的租约
  与刚推进的游标盖回读那一刻的快照(08-24 loop_state 整份覆盖同款指纹)。清游标改为显式单写那一列。
P0-7 UIDVALIDITY 变化不再静默:provider 回 note,用例落进 last_poll_error(「已重锚在当下;
  期间来信未拉取」)—— 丢了一段信而账号页一片绿是界面撒谎。
P0-8 parseCursor 连取值范围一起查(非负安全整数 + 界内:UID ≤ 0xFFFFFFFF、秒 ≤ Date 上限)——
  1e13 正是安全整数,乘 1000 出界,一行脏游标能让 listAccounts 整页 500。debt ⑨ 划线销账。
P0-9 线程口径归一:threadIdOf 改成**取根**(references[0] ?? inReplyTo,ADR-013 决策 3),
  mail-wiring 调它、不再内联一份。原测试改断言,不删。
P0-10 文档说老实话:mail.send 工具路发出的信**不登记 outbound_ref**(recordOutbound 的唯一调用方
  channel.sendMail 在 src 里零调用方)—— API 文档 §4 与 ADR-013 决策 6 各补一段,根治记 debt。

P1:imap anchor 的 Math.min(...uids) 改 reduce(十万级 UID 会栈溢出)· wecom 翻页加页数上限
(服务端一直回 has_more:1 会死循环)· MAIL_TOOL 导出并对**真契约**断言(原 v1/v2 是手抄夹具、
自证,且 v1 版本号写错)· reset-runs 清运行数据时把邮箱账号的游标与拉取状态一并清(留着游标而信没了,
wecom 十分钟重叠窗会把最近的信当新信再投一次)· due.test 的 leaseMsFor(30) 断言改写死 300_000(原为自证)·
cursor.test 删掉指向评审报告的注释 · 设计稿稿头标注三处已被 ADR-013 取代 · ADR-013 补记 wecom
compose_send 不带 inReplyTo/references(它发出的信在对方那里不串线程)。

契约变更(§12.4):port.ts 的 InboundStore 加 getMeta、OutboundStore 加 claimForResend、
savePoll 的 cursor 允许显式 null、MailProvider.pull 回参可带 note —— 实现方只有本模块 adapter 与
__tests__/fakes.ts 的内存件(两边语义一致,已同改),CONTRACT.md 已同步,api-report 已刷新。

测试:1922 → 1942(mail 模块 102 → 113,含真 PG 的 save 不盖运行列 / 不搬原件 / 两条真连接抢同一行)。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TM4kUBvekALu9qqmp7D3wr
 2026-08-26 03:47:48 +08:00
xcsandClaude Fable 5 ab30ce56c5 计划修:入站线程取根不取最近一跳,附件缺 uploadRef 不静默丢 
评审逐跳走了一遍:我方出站登记的 threadId 恒是这一串的首封,而归属解析①级是精确等值。
入站若取 In-Reply-To(最近一跳),跑一个来回就漂 —— 我方 M1 → 客户回 M1(命中)→ 我方再回
(实际 M2、仍记在 M1 名下)→ 客户回 M2 → 库里从没记过 M2 ⇒ ①级落空,退到③地址+时间窗。
取 references[0](根)才稳定;客户端只给 In-Reply-To 时退回它。

同批:app 层丢掉没给 uploadRef 的附件却照回 queued:true —— 模块自己那一层是硬的(抛 MailSendInvalidError),
app 层比它松,活动说「带上 q.pdf」而信发了附件没了、没人吭声。翻成 invalid。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TM4kUBvekALu9qqmp7D3wr
 2026-08-26 02:16:41 +08:00
xcsandClaude Fable 5 58358210e2 计划再修:游标推进与 more 必须同一个判据 —— 「页翻完」不等于「新信吃完」 
上一次修的是「多页时截断不许推进游标」,但漏了一形:最后一页可能同时 has_more:0
且新信多过本轮预算(LIST_PAGE 是 100,与 perTick 的 50 无关)—— 那时 exhausted 为真、
游标照推,而 wanted 截掉的那几封从此永久丢(重叠窗只兜 10 分钟)。

评审的话说得准:more 的判据是对的,cursor 的不是,两者本该是同一个。
改成 `const more = !exhausted || fresh.length > wanted.length; cursor: more ? cursor : 推进`。
补两条测试:单页 has_more:0 但新信超预算(游标不许动)、-1 连击到边界不再重试。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TM4kUBvekALu9qqmp7D3wr
 2026-08-26 02:05:39 +08:00
xcsandClaude Fable 5 f04c64926b 计划修死企业微信那条路的游标丢信:截断时不许把游标推到窗口上沿,且滤重要在截断之前 
Task 9 的评审点过「批末无条件覆盖游标、没有单调性护栏」,当时两个适配器还没落地、判不了实情。
照原计划的 wecom pull 读下来是两个真缺陷,都只在积压超过一轮预算(50 封)时现形:

① 被 limit 截断时仍把游标推到窗口上沿 —— 没读到的那几封从此跳过去了;
   重叠窗只兜 10 分钟,兜不住一次积压(停机重启、首次回填)。
② 滤重(known)发生在截断**之后** —— 一个窗口里若前 50 条恰好都已入库,这一轮交出 0 封,
   而引擎见空批即收工、游标又没动,下一轮还是这 0 封,永远吃不到后面的新信。

改法:滤重提到分页循环里(每页先滤再数够不够),游标只在把窗口翻完时才推进,
截断时原样退回 —— 已入库的下一轮被 known 滤掉,每轮照旧往前吃一批,不卡也不丢。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TM4kUBvekALu9qqmp7D3wr
 2026-08-26 01:42:10 +08:00
xcsandClaude Fable 5 43bacffd90 计划裁决:邮件路由的读也归运营中心,不去撑大「两端共用读路由」那份名单 
全仓测试 route-access.test.ts 钉着一份有意枚举、随 Keycloak spec 审过的名单:哪些读路由被两个端共用。
计划原把邮件的 7 条 GET 标成 design|ops,名单就从八条长到十四条。裁决改路由、不改名单:
①邮箱那一屏按本计划自己的前端说明落在运营中心,设计端没有消费方(测试台读的是通道,不是邮箱账号);
②入站正文装的是客户来往内容 —— ADR-012 已把「设计端能读客户主数据」记为一处有意承担的代价,不再无故加宽;
③要往那份名单里加,得有真实消费方撑着。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TM4kUBvekALu9qqmp7D3wr
 2026-08-26 01:34:24 +08:00
xcsandClaude Fable 5 58d6d778ea 计划勘误:cursor 测试的 wecom epoch 字面量错了整一年(1756116000 是 2025-08-25) 
实现 Task 4 时逼出来的:那条断言期望 2026-08-25T10:00:00Z,而字面量落在 2025 —— 整套夹具都锚在
2026-08-25T10:00:00Z,改输入而不是改期望,才不会留下唯一一个锚在别的年份的夹具。
代码侧已在 83f65b2 修正,这里把计划文本对齐。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TM4kUBvekALu9qqmp7D3wr
 2026-08-26 00:14:53 +08:00
xcsandClaude Fable 5 649cec1197 邮件收发模块实施计划:17 个任务(契约 / 迁移与 store / domain / 用例 / 两条 provider / app 装配 / 路由 / 工具契约 2.0.0 / 文档) 
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TM4kUBvekALu9qqmp7D3wr
 2026-08-25 23:21:52 +08:00
xcsandClaude Fable 5 ebc6f778df 邮件收发模块设计稿:两条接入路(IMAP/SMTP · 企业微信邮件 API)、订阅分发、出站留痕、跨进程租约 
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TM4kUBvekALu9qqmp7D3wr
 2026-08-25 22:36:58 +08:00
xcsandClaude Fable 5 094386f02c 文档:前端对接说明与 API 文档(鉴权 / 人员 / 角色→端);计划加 Task 12 按契约核对两份文档 
前端对接说明:要改哪些文件、/api/me 与端、401/403/410 处置、SSE 与下载的 60s 票据、
运营中心员工页的新接口、接入完成判据。API 文档:通则与状态码、每条新接口的出入参与示例、
退役八条的替代、全部 95 条契约路由的端归属总表、schema 附录、curl 实录。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015kAzS35kMnZNt4YGgJXtfw
 2026-08-25 15:25:30 +08:00
xcsandClaude Fable 5 8ba4ab339e 实施计划:统一鉴权中心(Keycloak)后端接入 —— 11 个任务,每任务自带测试与门禁 
按 spec 拆:契约归属 → org 纯函数 → jose 验签 / Admin 名册两个 adapter → 注册表 / 票据 /
中间件三件 app 小件 → 一次提交的大切换(org 重写 + app 重接线 + 迁移 0032)→ 启动自检与
路由覆盖 fail-closed → e2e 改服务账号 → ADR-012 与文档。执行前置:用户先处理工作树里未提交的改动。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015kAzS35kMnZNt4YGgJXtfw
 2026-08-25 15:15:56 +08:00
xcsandClaude Fable 5 98ce2966a2 设计:统一鉴权中心(Keycloak)后端接入 —— 资源服务器 + 角色→端 + 名册同步 
推翻 ADR-010 的口令/会话/岗位授权:身份只认 Bearer JWT(jose 本地验签),
权限只到三个端(design/ops/workbench),角色→端一张表运营中心可改;
岗位本地 + 名册经 Admin API 同步;SSE 与下载走 60s 票据;退役契约留一轮回 410。
只做后端,web 不动。四问与三取舍已由用户裁决,记在 §2。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015kAzS35kMnZNt4YGgJXtfw
 2026-08-25 14:37:24 +08:00
ChaiHaoandClaude Opus 5 1d2d5ebb53 归档过时文档,立仓库根 CLAUDE.md 记最新状态 
**归档四份**(docs/archive/,每份头部带归档说明与现行去向,另配 archive/README.md 索引):
  · MVP规格包-README.md(原 docs/README.md)—— 从零实现的启动包,MVP 已建成,
    启动提示词与里程碑纪律不再是现行指引;代码注释「README《归一化对照表》」等引用
    的各节原文保留,查历史语境仍来这里;
  · PROGRESS.md —— M0-M6 全部完成后停止维护,「下一步」多数已做完或被后续决策取代;
  · plan-2026-07-27-{mvp-foundation,three-surfaces}.md —— 两份已执行完毕的实施计划
    (三面形态此后又有演进:运营撤数据区、触发器与大模型独立成区)。
  语义源三份 html(操作系统/活动模型/MVP示例)不归档 —— 仍是 OS/AM 条款的出处,
  只是 flow 相关章节读作历史记述。

**新立 CLAUDE.md**(仓库根,每会话装载):现状快照(三面一体 · 编排层测死 · 范式退役
一律案例模型 · 无模型密钥时三套 e2e 跳过 · 下一件大事 = 按活动开发规范第 12 章销账)、
文档权威地图(活文档/语义源/前端权威/归档)、八条铁规矩(五闸以退出码验 · 契约四步 ·
§12.5 禁止清单 · mock 只在外界 · 密钥只从环境 · 试跑用 AI 账号测完清数据 ·
安装恒新增改必升版 · 界面不撒谎)、常用命令与结构速查。

五闸绿。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KeDBx2PHLavbURXB8LJJ7m
 2026-07-30 03:15:00 +08:00
ChaiHaoandClaude Fable 5 5f9625efbb MVP底座⓪:计划与依据入库 —— MVP示例工作流.html + 实施计划 
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KeDBx2PHLavbURXB8LJJ7m
 2026-07-27 22:36:58 +08:00
ChaiHaoandClaude Fable 5 ac85ecf2ea 基线:鉴权会话+工作组+工作台三区修复+编排工作区+产品设计文档 
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KeDBx2PHLavbURXB8LJJ7m
 2026-07-27 20:43:35 +08:00