2 Commits

Author	SHA1	Message	Date
JianFeeeee	ed0ad2508e	跨端: feat(推送客户端): 按线上形状补契约层（DELETE 也带 body / 未知字段 400 / provider 无白名单 / 错误是 {"error"}） ... pi 2026-09-14 给的线上形状（从 handler/push.go 读的，不是猜的）逐条落成可判的： - **请求体只放已知键**：`PUSH_BODY_KEYS` 登记四个键，**未知字段服务端直接 400**（不是静默忽略） ⇒ 拼错会立刻可见；可选字段为空就不放（空串虽合法，但不放更不容易踩校验）。 - **provider 只做形状校验、没有白名单**（`^[a-z0-9_-]{1,32}$`）：判据断言 `apns`/`fcm` 也合法 —— 客户端**不许**硬编码"只有 hms 合法"去先拦一道（服务端没实现的通道不该变成客户端的 400）。 这正是"校验的范围必须等于它真正知道的事"的又一落点。 - **token**：空非法、512 上限；形状不合法 ⇒ `buildTokenBody` 返回 undefined，调用侧**静默跳过**， 不去打一次注定 400 的请求。 - **错误体是 `{"error"}` 不是 `{"message"}`**：判据专门断言 `{"message":"x"}` 解析出 undefined （用错键会把"没有消息"当有消息）。 - **注销：`deleted:false`（本来没登记）不是失败** ⇒ 它**不改变分类**，所以**不再是入参** （一个不影响结果的入参只会让人误以为它影响结果），判据断 `classifyUnregister.length === 2` 钉住这点。 - **`ApiClient.del` 补可选 JSON body**：DELETE 端点是 JSON body 形状（不是 query、不是 path 参数）， 原来只有 `path` ⇒ 注销会无效。不传 body 时行为与旧版完全一致（向后兼容）。 EOF	2026-09-15 11:43:22 +08:00
JianFeeeee	8fed8401de	跨端: feat(推送客户端): 契约层 model/PushContract.ts + 6 条设备无关判据（静默失败/enabled:false 正常态/按 provider+tail 比/按 mail_id 去重） ... pi 2026-09-14 推送契约的客户端半边。四条不变量里**三条是纯逻辑**，所以先落这三条， 平台调用（Push Kit 取 token、通知权限）留在下一步的 `PushService.ets` 里。 - `shouldReportToken`：取不到 token 不上报；与上次相同不重复上报（否则每次启动打一次接口）； - `tokenTail` / `isRegistered`：GET **只回尾 6 位** ⇒ "登记过没有"必须按 `provider + tail` 比。 比全文是**看起来更严、其实永远为假**的写法（全文永不等于尾 6 位 ⇒ 每次启动重复上报）， 所以有判据钉它，并在注释里写明"同尾 6 位即视为同一条 —— 这是服务端给的信息量的上界，不是我们的选择"； - `classifyRegister`：`ok-enabled` / `ok-disabled` / `silent-skip` —— **三种里没有一种是"提示失败"** （`enabled:false` 是自部署常态 ⇒ 不重试、不提示）； - `parseNotificationData`：不满足约定形状就返回 undefined（坏 JSON 不抛、缺 mail_id/动作不符都忽略）—— 推送是可选通道，收到不认识的东西不许有任何副作用； - `NotificationLedger`：服务端**无幂等键**（至多一次、无重试/去重表）⇒ 重复保护落客户端；台账**有界**。 另有一条判据禁止契约层引入 `@ohos`/`@kit`（否则这些判据会退化成必须上设备）。 它第一次跑**咬到了解释这条规则的那行注释** ⇒ 改扫 `code()`（去注释），与前面扫描口径那次同族。 `npm test`（install 相位）全绿；余额 `debts=13`。	2026-09-15 11:40:54 +08:00