MailUI4Agents

jianf/MailUI4Agents

Fork 0

Commit Graph

Author	SHA1	Message	Date
JianFeeeee	f86f08c7dc	fix(桥): read_inbox 在非邮件驱动会话上也得带 workspace —— homeagent 与 opencode 两处同一个形状的缺陷在两个桥上，根因都是架构差异，不是"忘了写"： pi/opencode/dsh 的工具只在邮件驱动回合里装配 ⇒ workspace 永远有值； homeagent 的 15 个工具是 `registerTool` 全局注册（webui/a2a/对话都能调）， opencode 是 `export default` 全局插件 ⇒ 非邮件驱动会话上查不到工作区 ⇒ 拼不出 `&workspace=` ⇒ 服务端 400。实测：homeagent 2026-10-01 14:32:26 一次真实失败，近 24h 3 失败 / 0 成功。 opencode 那次是静默失败（工具返回错误文本，模型照走）⇒ 线上 0 次报错不代表没问题，是靠两桥的架构差异推出来的，不是靠日志。修法不同（各自的可用信号不同）： - homeagent: `effectiveWorkspace()` = 信封 → 回落到进程 cwd。 cwd 是对的默认值：homed 按调用上下文以子进程拉起插件，实测对话中那个桥 cwd=/home/program/agentmail，而从插件目录拉起的那个是 plugins/...。 ⚠ 只是默认不是保证（库里 17 个工作区），收窄语义不变。 - opencode: handler 拿得到 `context.sessionID`，而 opencode `Session` 带 directory（types.gen.d.ts 的 `export type Session` 可见），且 `client.session.get` 本桥已在用 ⇒ 现场问权威值，不猜也不另存一份。 readInboxTool 是模块级常量，故新增 hostClient 在 init 时捕获。部署：homeagent 首次走正规 hmap 路径（解包 + cp manifest + install -m 0755， skill §5 四步全绿）。判据：homeagent 新增 4 格 + 修正 3 条失效的既有断言（补 cwd 回落使其旧前提失效：整串相等 vs 分片包含、"q[1:] 不能有 &" vs 合法分隔符、 "没工作区就不带"vs"带的是不是真值"——判据失败时先判断是判据错了还是行为错了）。 opencode 新增 5 格。全量：server 全绿 + race 干净；opencode 桥 359/359。端到端：homeagent webui 一轮 `tool read_inbox result: {"content":[{"text":"收件箱为空。" （修复前是 400）；opencode 两条非邮件驱动会话均 status: completed， "空"是正确的收窄结果（74 封全是 read/archived，unread=0），近 10 分钟 0 次 400。	2026-10-01 19:41:16 +08:00
JianFeeeee	2a5e3d7d15	fix(auth): 四家桥的读端点也带上会话收窄 + 转发同一条命（工作区隔离第 2 步）第 1 步（1b8cd43）把工作区判据放在服务端、pi 桥接上了线。这一步补齐另外四家，并把转发纳入：转发是"把原文引出去"，能转发就等于能读到那条线索的全部内容，与 read_mail 同一条命（服务端 ForwardMail 也加了同一道校验）。四家各自的会话来源，与各自的 read_inbox 同一处（不引入第二个来源）： - dsh：`mailSessionOf(exec)`（工具第二个参数）—— 五个读工具原本没接 exec，这次补上 - opencode：`reverseMap.get(context.sessionID)` - zcode：`process.env.AGENTMAIL_SESSION_ID`（一轮一个进程） - homeagent：`p.currentSessionID`（新增 `scopeQuery(sep)`，与 inboxURL 同构）判据（每条两侧都钉：包住了 / 没包住的不存在）： - dsh：静态对照，且额外钉 dist —— 那是真被 dsh 加载的那份（main: dist/index.js）， src 改了忘了 build 就是"源码对、线上旧代码" - opencode / zcode：同上（opencode 还钉"会话来自 context 而不是模块级变量"） - homeagent：起 httptest 当网关，五个读工具 + 转发真调一遍，断言请求 URL 带 session_id；对照侧：不在回合里（currentSessionID 为空）时不许带 - pi：把 post 的 URL 也纳入记录，forward 进用例表 ★ zcode 那条判据我第一版对照组写错了：对照组只写裸 URL，而它本来就是 `withScope(\`裸URL\`)` 的子串 ⇒ `!includes(bare)` 恒假。夹具形状不对时判据会以 "恒红/恒绿"的方式骗人（这次是恒红，一眼可见；恒绿就麻烦了）。变异：homeagent 去掉 read_mail 的收窄 ⇒ 恰好那条断言红。（工作区共享，只 add 了上面这 12 个文件；dsh 的 dist 是 gitignore 的，由 redeploy-plugin.sh 在 staging 里构建。）	2026-09-14 23:18:12 +08:00

Author

SHA1

Message

Date

JianFeeeee

f86f08c7dc

fix(桥): read_inbox 在非邮件驱动会话上也得带 workspace —— homeagent 与 opencode 两处

同一个形状的缺陷在两个桥上，**根因都是架构差异，不是"忘了写"**：
pi/opencode/dsh 的工具**只在邮件驱动回合里装配** ⇒ workspace 永远有值；
homeagent 的 15 个工具是 `registerTool` **全局注册**（webui/a2a/对话都能调），
opencode 是 `export default` 全局插件 ⇒ 非邮件驱动会话上查不到工作区
⇒ 拼不出 `&workspace=` ⇒ 服务端 400。

实测：homeagent 2026-10-01 14:32:26 一次真实失败，近 24h **3 失败 / 0 成功**。
opencode 那次是**静默**失败（工具返回错误文本，模型照走）⇒ 线上 0 次报错
不代表没问题，是靠两桥的架构差异推出来的，不是靠日志。

修法不同（各自的可用信号不同）：
- homeagent: `effectiveWorkspace()` = 信封 → **回落到进程 cwd**。
  cwd 是对的默认值：homed 按调用上下文以子进程拉起插件，实测对话中那个桥
  cwd=/home/program/agentmail，而从插件目录拉起的那个是 plugins/...。
  ⚠ 只是默认不是保证（库里 17 个工作区），收窄语义不变。
- opencode: handler 拿得到 `context.sessionID`，而 opencode `Session`
  **带 directory**（types.gen.d.ts 的 `export type Session` 可见），
  且 `client.session.get` 本桥已在用 ⇒ 现场问权威值，不猜也不另存一份。
  readInboxTool 是模块级常量，故新增 hostClient 在 init 时捕获。

部署：homeagent 首次走正规 hmap 路径（解包 + cp manifest + install -m 0755，
skill §5 四步全绿）。判据：homeagent 新增 4 格 + 修正 3 条失效的既有断言
（补 cwd 回落使其旧前提失效：整串相等 vs 分片包含、"q[1:] 不能有 &" vs 合法分隔符、
"没工作区就不带"vs"带的是不是真值"——判据失败时先判断是判据错了还是行为错了）。
opencode 新增 5 格。全量：server 全绿 + race 干净；opencode 桥 359/359。

端到端：homeagent webui 一轮 `tool read_inbox result: {"content":[{"text":"收件箱为空。"
（修复前是 400）；opencode 两条非邮件驱动会话均 status: completed，
"空"是正确的收窄结果（74 封全是 read/archived，unread=0），近 10 分钟 0 次 400。

2026-10-01 19:41:16 +08:00

JianFeeeee

2a5e3d7d15

fix(auth): 四家桥的读端点也带上会话收窄 + 转发同一条命（工作区隔离第 2 步）

第 1 步（1b8cd43）把工作区判据放在服务端、pi 桥接上了线。这一步补齐另外四家，
并把**转发**纳入：转发是"把原文引出去"，能转发就等于能读到那条线索的全部内容，
与 read_mail 同一条命（服务端 ForwardMail 也加了同一道校验）。

四家各自的会话来源，与各自的 read_inbox 同一处（不引入第二个来源）：
- dsh：`mailSessionOf(exec)`（工具第二个参数）—— 五个读工具原本没接 exec，这次补上
- opencode：`reverseMap.get(context.sessionID)`
- zcode：`process.env.AGENTMAIL_SESSION_ID`（一轮一个进程）
- homeagent：`p.currentSessionID`（新增 `scopeQuery(sep)`，与 inboxURL 同构）

判据（每条两侧都钉：包住了 / 没包住的不存在）：
- dsh：静态对照，且额外钉 **dist** —— 那是真被 dsh 加载的那份（main: dist/index.js），
  src 改了忘了 build 就是"源码对、线上旧代码"
- opencode / zcode：同上（opencode 还钉"会话来自 context 而不是模块级变量"）
- homeagent：起 httptest 当网关，**五个读工具 + 转发真调一遍**，断言请求 URL 带
  session_id；对照侧：不在回合里（currentSessionID 为空）时不许带
- pi：把 post 的 URL 也纳入记录，forward 进用例表

★ zcode 那条判据我第一版**对照组写错**了：对照组只写裸 URL，而它本来就是
`withScope(\`裸URL\`)` 的子串 ⇒ `!includes(bare)` 恒假。夹具形状不对时判据会以
"恒红/恒绿"的方式骗人（这次是恒红，一眼可见；恒绿就麻烦了）。

变异：homeagent 去掉 read_mail 的收窄 ⇒ 恰好那条断言红。

（工作区共享，只 add 了上面这 12 个文件；dsh 的 dist 是 gitignore 的，由
redeploy-plugin.sh 在 staging 里构建。）

2026-09-14 23:18:12 +08:00

2 Commits