test: Go/JS SDK 接入清单集成测与 README 示例

docs/DEVIATIONS.md

@@ -764,11 +764,48 @@
 - 原因：`onSession` 作方法名在部分风格指南中易被误认为事件订阅属性。
 - 备选：完全同名方法；可在任务 5 文档化时再加别名。
 
-### S1.6 未做范围
+### S1.6 任务 1–3 当时未做范围（已被 S1.7 取代）
 
-- 任务 4 真实服务器接入清单（15 条）未做，按总控安排留给后续波次。
-- 任务 5 打包试跑/README/示例未做（本期只完成任务 1–3 与许可证文件副本；JS 已能 `npm run build` 出 ESM+CJS，但未发布 npm）。
-- Go 裸 TCP（`AllowTCP`）与 JS `allowTcp` 已接线，但无集成级验证（属接入清单）。
+- 当时：任务 4 真实服务器接入清单、任务 5 README/示例/打包试跑未做。
+- 现况：见 S1.7。
+
+### S1.7 2026-09-30 任务 4–5 接入清单与打包文档
+
+1. **集成测试自建启动器（不 import 根模块 harness）**  
+   - 原条款：TASKS 用 T0.5 harness 起真实服务端。  
+   - 实际做法：`sdk/go` / `sdk/js` 各自在测试里向上查找含 `cmd/nixmsg` 的仓库根，编译二进制，`admin init` + `listen: 127.0.0.1:0` + 临时 `data_dir` 后 `serve`；注册开关与安全码走管理 `PUT /api/admin/registration`。  
+   - 原因：`sdk/go` 是独立 Go 模块，从该目录跑测时 `harness.Binary` 会先命中 `sdk/go/go.mod` 找不到 `./cmd/nixmsg`；JS 也无法直接 import Go 包。  
+   - 备选：给 harness 加 `NIXMSG_ROOT` 环境变量；未改共享目录以免越界。  
+   - 影响：行为与 harness 一致，仅实现重复约百行。
+
+2. **清单第 4 条「ack 丢失后自动再确认」**  
+   - 原条款：模拟 ack 丢失后服务器重推，SDK 自动再确认且不重复回调。  
+   - 实际做法：真实服务用 `ManualAck` + `keep` 消息：收一次不 ack → 管理踢线重连 → 断言回调仍为 1（去重），再手动 `Ack`；「已确认后再推则自动再 ack」仍由 FakeTransport 单测覆盖。  
+   - 原因：自动模式下难以在不改服务器的前提下可靠丢掉已发出的 ack；确认超时默认约 5 分钟，不适合常规集成测。  
+   - 备选：缩短测试用 ack_timeout（需改服务配置/代码，越界）。  
+   - 影响：真实环境覆盖「不重复回调 + 终态确认」；自动再 ack 路径依赖既有单测。
+
+3. **断线期间发送**  
+   - 实际做法：管理 `POST .../kick`（AdministrativeAction，非 `0x8E`）断开连接，SDK 按网络故障重连；在重连窗口调用 `send` 入队，恢复后送达且回调一次。  
+   - 原因：文档写明管理员踢下线只断线、令牌仍可用、SDK 应重连。  
+   - 备选：本地 TCP 代理掐线；未采用以减少测试基础设施。
+
+4. **JS 第 14 条跨源**  
+   - 实际做法：另起本地 HTTP 端口作为「页面」Origin，对注册接口发带 `Origin` 的 OPTIONS/POST，断言 `Access-Control-Allow-Origin: *`；再用 SDK 从「页面」视角连服务器另一端口的 `/mqtt`。未起真实浏览器。  
+   - 原因：Vitest/Node 无完整浏览器；服务端 CORS 与 WS Origin 策略已由身份/连接线保证。  
+   - 备选：Playwright 实浏览器；本期为控制依赖未引入。
+
+5. **任务 5 打包与文档**  
+   - Go：`sdk/go/README.md` + `example/minimal`；不打 `sdk/go/v*` git tag（发布在 Z3）。  
+   - JS：`README.md` + `example/minimal.mjs`；`license` 已为 `SEE LICENSE IN LICENSE`；`npm pack --dry-run` 试跑，**不** `npm publish`。  
+   - 影响：无。
+
+6. **真实 MQTT 收包路径与 request 死锁**  
+   - 原条款：DEVELOPMENT 第 9 节收发/确认；回调串行。  
+   - 实际做法：`resp` 在 MQTT `OnPublishReceived` 路径同步解挂起；`msg`/`receipt`/事件进入 `downCh` 由 `downLoop` 串行处理（可在其中 `request` 发 ack）。  
+   - 原因：若在收包回调里同步 `request` 等 `resp`，而 `resp` 也走同一回调，真实 autopaho 会卡死；假传输因同栈注入 `resp` 掩盖了问题。  
+   - 备选：ack 发后不等 `resp`；未采用，以免丢「ack 结果当 revoked」语义。  
+   - 影响：行为更接近文档；单测仍绿。
 
 ## SDK 二 S2