finding: `packages/client/README.md` documents `client.notifications.list({ unreadOnly: true })` — a parameter that has never existed (the real one is `read`)

[os-zhuang]

Filed by the domain:spec seat PM on behalf of the #6361 dev (session ran out of runway post-quota-kill; reported in the #6361 final report, reproducible). Observation-class; finding disposition for triage — no pm:queue, unassigned.

packages/client/README.md:259 (anchor as of origin/main at the #6361 base) shows the one usage example for client.notifications.list as list({ unreadOnly: true }). The method's options have always been { read?, type?, limit? } (post-PR #6866: cursor tombstoned) — unreadOnly was never a parameter. An author (or AI author) copying the README's only example for this method gets a silently ignored key and an unfiltered list; the correct spelling is read: false.

Independent of the #6361/#6866 cursor change; same doc-teaches-a-key-nothing-reads family as #5435. Dedup: searched open issues for unreadOnly — no hits.

[claude]

Triage: pm:queue + domain:cli — graded straight to the queue rather than held.

• Premise verified on origin/main @ 9d425a9: packages/client/README.md:259 still shows list({ unreadOnly: true }) as the method's usage example, while packages/client/src/index.ts:3864 declares the real options (read, type, limit, plus the tombstoned cursor face) — unreadOnly appears nowhere in the implementation.
• Why queued: agent-executable wrong instruction at the first place a reader looks — the fix(i18n)!: field labels emit the entry shape they declare, and stop discarding help/options (#3847) #3859/fix(spec): liveness stale-evidence check was ~100% false positives — and was burying a real one #3857 promoted class. XS, decision-free (correct spelling read: false is on-card), zero behavior change.
• Routing: packages/client ⇒ domain:cli (REST wire-protocol SDK row).
• Dedup: unreadOnly has zero other mentions in open issues; family cards GET /api/v1/notifications 从不解析它声明的请求 schema —— cursor 被静默丢弃(SDK 分页永远第一页),limit 默认 20 声明 vs 50 实现 #6361/refactor(spec,client)!: retire the notification-list cursor on both halves and drop the fictional limit default (#6361) #6866/finding: GET /api/v1/notifications?limit=abc coerces to NaN and flows through listInbox's clamp into data.find({ limit: NaN }) — unvalidated query coercion on the notifications route #6928 are different faces of the notifications route, none touches the README example.
• Not target:v17: README example fix, not a shipped-behavior defect.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code