MailUI4Agents

jianf/MailUI4Agents

Fork 0

Commit Graph

Author	SHA1	Message	Date
JianFeeeee	d5cfcbdc9c	fix(权限): 409 的第二种含义是「本档不该问」——四桥都补上；状态写入点不再兜默认档线上事故（jianf 经 pi 转达）：补投路径漏传 permission_mode，插件拿 undefined 兜了 workspace 档，把 full 档会话写成 workspace-write + ask —— 不是"拦一次"，是一整轮工具能力降级，且状态留在会话里；随后该会话每次受守卫调用都撞 409。四件事： 1. 状态写入点不接受默认值（新增共享 `modeForStateWrite`）：缺字段/脏值 → `null` = 不写状态。"默认值可以出现在决策里，不可以出现在状态写入里。" 同时保留共享契约的 fail-closed：真读到 workspace 才写 workspace。 2. 409 的两种含义分开处理。`allowed-once` 只绕过审批，改不了沙箱 —— 所以 dsh 桥在放行前先把服务端给的权威档位写回会话（这也就成了自愈路径：已经降级的会话，下一次带档位的 409 会把它修回来）；只认服务端明说的 full， plan 与"链上没有人类"照旧 fail closed。 3. 同一处缺陷在 zcode / opencode 也在（`hooks/permission.mjs` 与 `index.js` 都把 409 当永久失败拒绝）。我先前在回信里写过"这两个桥不转发权限询问，不需要改" —— 那句话是错的，我当时的搜索面只有 `<plugin>/src/.mjs`。按 pi 的要求把这条否定性事实变成常驻判据后，它第一次运行就红给我看。四桥现在都有「409 + full → 放行」，且排在永久失败分支之前（含顺序变异自检）。 4. 共用测试重新同源：`test/catchup.test.mjs` 从 `153985e` 起就是分叉的（我那版把平台专属路径写进了共用文件），而 `deploy/install.sh` 第 24 行会跑 `check-shared-libs.sh` —— 也就是说部署一直是红的*，我没跑过那个脚本。共用文件只放契约（值/行为），跨平台配对judge 移到平台专属文件，四份逐字节相同。另外把"判代码 vs 判理由"从记忆变成代码：`test/lib/read.mjs` 提供 `code()/prose()/bytes()`，判据目录里不得再裸用 `readFileSync`（新判据 `criteria-hygiene` 管，含读取器自检）。判据证据（每条都做过"能不能红"的变异）： - 写回去掉 → 红；纠正块挪到普通 409 之后 → 红；状态写入点退回兜默认 → 红； - zcode/opencode 的放行分支拿掉 → 各自红；共用测试分叉 → check-shared-libs 红。各套件：dsh 388、pi 443、zcode 387、opencode 333（均经 npm test，含 tsc）； electron `npm test` 15/15 判据绿 + vitest 266 + typecheck；`check-shared-libs.sh` 退出 0； Go `go test ./...` 全 ok。	2026-09-14 16:21:27 +08:00
JianFeeeee	7028c244fd	dsh 桥同一处缺陷：409 带 full 档时也当场拒绝（并且把会话降级了） pi 报的是它自己的桥，但同一处缺陷 dsh 桥也有（`src/index.ts` 的 409 分支无条件 `return 'rejected'`），而且后果多一层 —— dsh 的档位是通过 `applyPermissionMode()` 写进会话的（沙箱 + 审批策略）。补投漏传档位时 `applyPermissionMode(session, '')` 把会话降级成 workspace：`danger-full-access → workspace-write`、 `never → ask`，于是每个受守卫的工具调用都去问一次，再被 409 拒绝 —— 一条 full 档会话只要有一封补投邮件，这一轮的工具调用全被自己人拦死，顺带把自己的权限也降了。修法同 pi 桥：409 分支先认回包里的 `permission_mode`，是 full 就 `return 'allowed-once'`（DSH 的 ApprovalOutcome 只认 allowed-once/rejected/cancelled/unavailable）； plan 档与"链上没有人类"照旧 `return 'rejected'`。放行分支排在普通 409 之前，否则不可达。判据 `test/permission-409-full.test.mjs`（含自检：拿掉放行分支必须红）。自检那步发现我第一版判据又踩了同一个坑：「普通 409 分支里不许出现 allowed-once」读的是含注释的正文，而那段的注释正好写着 "ApprovalOutcome 只认 allowed-once / rejected / …" → 误报。改成读剥注释的源码（规范里那条：判"代码里有什么"读剥离版，判"理由写清了没"读原文）。 zcode / opencode 不转发权限询问（没有 409 分支），无需改。验证：dsh 套件 383 通过（+2）；变异（拿掉放行分支）→ 自检红。	2026-09-14 15:51:38 +08:00

Author

SHA1

Message

Date

JianFeeeee

d5cfcbdc9c

fix(权限): 409 的第二种含义是「本档不该问」——四桥都补上；状态写入点不再兜默认档

线上事故（jianf 经 pi 转达）：补投路径漏传 permission_mode，插件拿 undefined 兜了
workspace 档，把 full 档会话写成 workspace-write + ask —— 不是"拦一次"，是一整轮
工具能力降级，且状态留在会话里；随后该会话每次受守卫调用都撞 409。

四件事：

1. **状态写入点不接受默认值**（新增共享 `modeForStateWrite`）：缺字段/脏值 → `null`
   = 不写状态。"默认值可以出现在**决策**里，不可以出现在**状态写入**里。"
   同时保留共享契约的 fail-closed：真读到 workspace 才写 workspace。

2. **409 的两种含义分开处理**。`allowed-once` 只绕过**审批**，改不了**沙箱** ——
   所以 dsh 桥在放行前先把服务端给的权威档位**写回会话**（这也就成了自愈路径：
   已经降级的会话，下一次带档位的 409 会把它修回来）；只认服务端明说的 full，
   plan 与"链上没有人类"照旧 fail closed。

3. **同一处缺陷在 zcode / opencode 也在**（`hooks/permission.mjs` 与 `index.js`
   都把 409 当永久失败拒绝）。我先前在回信里写过"这两个桥不转发权限询问，不需要改"
   —— 那句话是错的，我当时的搜索面只有 `<plugin>/src/*.mjs`。按 pi 的要求把这条
   **否定性事实变成常驻判据**后，它第一次运行就红给我看。四桥现在都有
   「409 + full → 放行」，且**排在永久失败分支之前**（含顺序变异自检）。

4. **共用测试重新同源**：`test/catchup.test.mjs` 从 `153985e` 起就是分叉的
   （我那版把平台专属路径写进了共用文件），而 `deploy/install.sh` 第 24 行会跑
   `check-shared-libs.sh` —— 也就是说**部署一直是红的**，我没跑过那个脚本。
   共用文件只放契约（值/行为），跨平台配对judge 移到平台专属文件，四份逐字节相同。

另外把"判代码 vs 判理由"从记忆变成代码：`test/lib/read.mjs` 提供 `code()/prose()/bytes()`，
判据目录里不得再裸用 `readFileSync`（新判据 `criteria-hygiene` 管，含读取器自检）。

判据证据（每条都做过"能不能红"的变异）：
- 写回去掉 → 红；纠正块挪到普通 409 之后 → 红；状态写入点退回兜默认 → 红；
- zcode/opencode 的放行分支拿掉 → 各自红；共用测试分叉 → check-shared-libs 红。

各套件：dsh 388、pi 443、zcode 387、opencode 333（均经 npm test，含 tsc）；
electron `npm test` 15/15 判据绿 + vitest 266 + typecheck；`check-shared-libs.sh` 退出 0；
Go `go test ./...` 全 ok。

2026-09-14 16:21:27 +08:00

JianFeeeee

7028c244fd

dsh 桥同一处缺陷：409 带 full 档时也当场拒绝（并且把会话降级了）

pi 报的是它自己的桥，但**同一处缺陷 dsh 桥也有**（`src/index.ts` 的 409 分支无条件
`return 'rejected'`），而且后果多一层 —— dsh 的档位是通过 `applyPermissionMode()`
写进会话的（沙箱 + 审批策略）。补投漏传档位时 `applyPermissionMode(session, '')`
把会话**降级**成 workspace：`danger-full-access → workspace-write`、
`never → ask`，于是每个受守卫的工具调用都去问一次，再被 409 拒绝 ——
一条 full 档会话只要有一封补投邮件，这一轮的工具调用全被自己人拦死，
**顺带把自己的权限也降了**。

修法同 pi 桥：409 分支先认回包里的 `permission_mode`，是 full 就
`return 'allowed-once'`（DSH 的 ApprovalOutcome 只认 allowed-once/rejected/cancelled/unavailable）；
plan 档与"链上没有人类"照旧 `return 'rejected'`。放行分支排在普通 409 之前，否则不可达。

判据 `test/permission-409-full.test.mjs`（含自检：拿掉放行分支必须红）。
自检那步发现我第一版判据又踩了同一个坑：「普通 409 分支里不许出现 allowed-once」
读的是**含注释**的正文，而那段的注释正好写着 "ApprovalOutcome 只认
allowed-once / rejected / …" → 误报。改成读剥注释的源码（规范里那条：
判"代码里有什么"读剥离版，判"理由写清了没"读原文）。

zcode / opencode 不转发权限询问（没有 409 分支），无需改。

验证：dsh 套件 383 通过（+2）；变异（拿掉放行分支）→ 自检红。

2026-09-14 15:51:38 +08:00

2 Commits