@senguoyun/dsh-arkme 0.1.44 → 0.1.46

package/cordis.patch.yml

@@ -42,5 +42,6 @@
         updateCheckIntervalHours: 12
         updateAllowLocalInstall: true
         richMediaRenderEnabled: true
+        markdownQuickNotesEnabled: true
         richMediaSendEnabled: true
         maxUploadBytes: 104857600

package/docs/direct-message-refusal.md

@@ -0,0 +1,39 @@
+# 私聊拒收能力
+
+Chat 服务持有方向性拒收事实，并在新消息建立接收方可见关系前最终校验。插件只通过账号绑定的 sourceRef 访问它，不复用员工封禁、群成员限制或通知静音。读取历史、重新编辑、撤回与删除不受拒收影响。
+
+## 能力矩阵与验收状态
+
+| 能力面 | 入口与合同 | 验收证据 |
+| --- | --- | --- |
+| Tools | 查询及设置自己的拒收；business/hybrid，写操作要求 explicit-user-write 和目标/版本确认；沿用正式注册/grant 链 | 官方 ToolRuntime 注册、可见性、grant、确认和执行测试通过；已登录的真实 DSH 会话调用仍待验收 |
+| SDK | 公开类型、能力探测、账号绑定 sourceRef、AbortSignal；不持久化状态 | 独立 tgz Consumer 可编译，查询/设置/不支持版本处理通过；请求使用模拟 Host 响应，不代表上游联调 |
+| UI | 右上角更多菜单中的固定“拒收对方消息”勾选项；勾选仅表示自己的拒收。已知拒收时禁用新消息编辑并保留草稿；未知状态不禁发 | React 交互、extension 输入与终态附件测试通过；隔离官方 DSH 的 tgz 页面验证已知拒收、解除、查询失败可输入及单次点击恢复设置；响应为受控测试数据，双账号真实私聊仍待验收 |
+| Host owner | 独立 DirectMessageAdmissionService；三个适配器共用；新消息 Gateway 解释业务响应 | owner/适配器一致性、账号隔离、终态错误与安全投影测试通过 |
+
+## 边界与恢复
+
+- 不新增全局业务错误码。上游通用权限失败仍为 1004；业务 Handler 验证响应体后只输出无内部 ID 的准入投影，且不可重试。2002 仅表示拒收设置的版本冲突，需刷新后由用户重新决定。
+- 仅 Chat 明确的真人 Direct 适用，不从 private_chat 展示分类推断 PendingPrivate 或 Bot 会话的准入。
+- 现有 projection.invalidated.v1 只负责失效通知。浏览器重查当前账号当前会话；断线重连/恢复焦点也重新查询，不共享跨账号状态，不以事件内容当作业务事实。
+- DSH 只使用公开 dsh-tools 与 Host Web Server 扩展点；不修改 DSH，不影响常驻实例。验收须区分单测、构建、tgz 安装和真实环境行为。
+- 后端先发布；Subject 旧直写客户端按产品决定排除，不新增其维护逻辑。拒收采用最终一致性，允许操作时在途消息的并发窗口，不以分布式锁串行化正常发送。
+- Chat 的 `direct_message_refusal_creation_enabled` 默认关闭。投影的 `refusalCreationEnabled=false` 只禁用新增拒收入口，不关闭正常消息发送，不阻止解除既有拒收，也不绕过已有 active 事实。
+- 新准入契约要求完整的布尔权限字段；缺失字段不推断为已开放。设置请求防止同一帧重复提交；失败后重新查询权威状态，恢复响应丢失或请求期间收到失效通知的情况，不自动重放设置或发送。
+- 终态发送失败不自动重试、不允许附件手动重试，也不会在解除拒收或重启后自动复活。重新编辑已有记录与 World 公开复制链接延展不属于私聊新消息，不混用该限制。
+- 多目标转发独立校验每个收件人；选中后某个收件人拒收，不中止其他正常目标，沿用原有部分成功反馈。
+- 查询失败保留当前账号、当前会话最近成功的投影；无投影时输入继续可用，发送由 Chat 最终校验。设置操作不能把未知状态当作 revision=0；一次点击先读取有效状态，再确认并提交。取消确认不写入，读取失败不自动循环重试，切换会话或账号取消旧操作。
+
+## 菜单交互修复验收（2026-09-07）
+
+本轮仅修改 UI 展示与客户端操作编排，没有新增 Host 查询、命令或持久化合同；Tools/SDK 的业务入口与 Host owner 保持不变，真实 Tools/SDK 联调不作为本轮 UI 修复的新增验收项。
+
+- Node 24：类型检查、完整测试（3752 通过、5 跳过）、构建通过。
+- 不变版本的 `.tgz` 经官方 DSH 0.1.1-rc.2 安装，全新 Profile、独立凭据命名空间和状态目录完成浏览器验收。模拟 Host 响应覆盖菜单勾选、输入框内提示、解除恢复输入、查询失败仍可输入、网络恢复后一次点击设置；未发送真实消息。
+- 浏览器场景无页面异常。未替换常驻插件，未发布；Windows/Linux 本轮未做实际设备验收。
+
+## 本地验证
+
+本次完整 `pnpm typecheck`、`pnpm test`、`pnpm build` 的执行结果记录在跨仓任务验收文档；新增批量转发部分拒收回归。打包保持仓库版本不变，使用官方 DSH 0.1.0-rc.8、全新隔离 Profile 和独立凭据命名空间验收；未修改 DSH 或替换常驻实例。Chat 侧真实 Mongo/Redis/RabbitMQ/IM 的本地 E2E 覆盖本人两个设备与对方设备的 SSE 失效通知、回查及幂等无通知。
+
+此状态不等于发布放行：仍缺已授权双测试账号的真实 DSH Tool/私聊 UI 场景，以及 Windows/Linux 实际目标环境验收。不能据 macOS 本机测试宣称所有平台和历史客户端均已覆盖。

package/docs/plugin-release.md

@@ -1,13 +1,38 @@
 # 插件自动发版
 
-日常功能分支不修改 `package.json.version` 或 `arkme.updateNotice`。功能合并到 `master` 后，由发版负责人在 GitHub 的 **Actions → 准备插件发版 → Run workflow** 中选择发版级别并填写一句更新说明。
+日常功能分支不修改 `package.json.version` 或 `arkme.updateNotice`。普通 PR 合并到 `master` 后，发布工作流自动确定版本，更新版本号、插件内更新说明和 GitHub Release 链接，再安装依赖，执行完整测试、类型检查、资源校验和构建。验证成功后会创建并合并 `release/v<版本号>` 发版 PR。
 
-该工作流会自动创建 `release/v<版本号>` 发版 PR，并在其中更新版本号、插件内更新说明和 GitHub Release 链接，随后执行完整测试、类型检查和构建。
+需要手动指定发版级别时，由发版负责人在 GitHub 的 **Actions → 准备插件发版 → Run workflow** 中选择级别并填写一句更新说明。该工作流先更新版本元数据，再安装依赖，执行完整测试、类型检查和构建，验证成功后创建发版 PR，等待合并。
 
-合并该发版 PR 后，发布工作流会再次验证代码，发布 npm 包、创建 `v<版本号>` Git Tag，并生成 GitHub Release。随后由独立的 production workflow 校验 npm、Tag、GitHub Release 与发布 SHA，检出该精确 SHA，构建 `tar.zst`，通过 Backend 获取单对象 STS 上传 OSS，并在 Runtime 校验通过后自动激活。
+发布工作流在 `publish` job 检出合并后的精确发布 SHA，完成类型检查、资源校验和构建，发布 npm 包、创建 `v<版本号>` Git Tag，并生成 GitHub Release。随后由独立的 production workflow 校验 npm、Tag、GitHub Release 与发布 SHA，检出该精确 SHA，构建 `tar.zst`，通过 Backend 获取单对象 STS 上传 OSS，并在 Runtime 校验通过后自动激活。
+
+npm 接受发布请求后仍可能异步处理版本。工作流以 15 分钟为等待窗口，每次未通过后间隔 5 秒回读精确版本，并在等待窗口结束时再检查一次；单次请求（含最后一次检查）最多 30 秒。日志会输出 HTTP 状态、网络或 JSON 错误，以及版本、integrity、provenance 的具体缺失或不一致字段。只有全部校验通过后才会继续创建 Tag、GitHub Release 和派发生产 Runtime 发布。
 
 `pre-release` 分支的每次 push 会走同一套 Runtime 发布链路，但不会发布 npm。测试版本由稳定基准版本的下一补丁与 GitHub run number 组成，例如 `0.1.34` 在 run `128` 中生成 `0.1.35-pre.128`；版本修改只存在于 Action 临时工作区。
 
+## Runtime 测试开关
+
+两个 Runtime workflow 分别通过文件顶部的 `env.RUN_TESTS` 控制批量测试：
+
+| 发布路径 | Workflow | 默认值 |
+| --- | --- | --- |
+| `master` 发版成功后派发生产 Runtime | `.github/workflows/publish-production-runtime.yml` | `'false'`：跳过 Runtime 批量测试 |
+| `pre-release` push 后构建测试 Runtime | `.github/workflows/publish-pre-release-runtime.yml` | `'true'`：执行 Runtime 批量测试 |
+
+需要调整时，在对应 workflow 中把 `RUN_TESTS` 改为字符串 `'true'` 或 `'false'`。`执行 Runtime 测试` 是独立步骤，仅在值为 `'true'` 时运行 `pnpm test`，测试失败会阻止后续构建和发布；关闭时该步骤显示为跳过。开关只控制批量测试，类型检查、资源校验、构建、打包和发布校验仍然执行。
+
+生产 Runtime 默认跳过测试，依赖正式发版的前置测试：普通 PR 在 npm 发布 workflow 的 `prepare` job 中执行测试；`release/v*` PR 会跳过该测试步骤，应由“准备插件发版”workflow 创建并完成测试。手工创建或修改发版 PR 时，需要另行确认最终发布内容已通过测试；无法确认时，应先把生产 Runtime 的 `RUN_TESTS` 设为 `'true'`。该开关本身不验证前置测试记录。
+
+## CI 构建开关
+
+四个发版 workflow 通过 `env.ARKME_SKIP_PREPARE_BUILD: 'true'` 跳过项目自身的 `prepare` 隐式构建，安装依赖和 Runtime 的 `pnpm pack` 不再重复编译。每个需要构建的 job 仍显式执行一次 `pnpm run build`，该命令不受开关影响；依赖安装脚本的执行策略保持原样。
+
+普通 PR 合并到 `master` 后，完整构建由原来的 8 次减少为 3 次：npm `prepare`、npm `publish`、生产 Runtime 各 1 次。重跑并复用已有发布提交或合并 `release/v*` PR 时，npm `prepare` 会跳过验证和构建。批量测试内部用于验证产物的 `bundle` 调用单独保留，不计入这 3 次完整构建。
+
+正式版本元数据在安装依赖前写入，避免安装后修改版本导致 pnpm 再次安装。Pre-Release 仍先安装依赖并测试稳定源码，再生成测试版本、显式构建和打包；即使 pnpm 因版本变化重新检查或安装依赖，`prepare` 也会跳过构建。
+
+本地不设置该变量或设为 `'false'` 时，安装和打包仍自动构建。仅精确值 `'true'` 会跳过隐式构建；它与 `RUN_TESTS` 相互独立。CI 打包使用显式构建生成的产物，Runtime 打包器仍检查必需文件和版本，缺少入口文件会失败。
+
 ## 一次性配置
 
 在 npm 包 `@senguoyun/dsh-arkme` 的发布设置中创建 GitHub Trusted Publisher，绑定：