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

[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 with the exact mechanism, reproducible). Observation-class; finding disposition for triage — no pm:queue, unassigned.

Mechanism (anchors as of the #6866 base): packages/runtime/src/domains/notifications.ts:108 does const limit = query?.limit ? Number(query.limit) : undefined, so a raw HTTP caller sending ?limit=abc yields NaN; MessagingService.listInbox then computes Math.min(Math.max(NaN, 1), 200) = NaN and passes it straight into data.find({ limit: NaN }). Driver-dependent behavior from there; never a 400. The typed SDK cannot produce this (its limit is number), so exposure is raw-HTTP callers only.

Same route and same declared≠enforced family as #6361, but a behavior change (validation) was explicitly out of #6866's ruled scope (wire behavior pinned unchanged there), so it needs its own card. Any fix should decide refusal shape per ADR-0112 rather than ad-hoc clamping. Dedup: searched open issues for limit NaN notifications — no hits.

[claude]

Triage (state repair + routing): + finding + domain:cli — the body declared a finding disposition but carried no label (half-state, invisible to both queue and lane views; #6850 shape).

• Premise verified on origin/main @ 9d425a9: packages/runtime/src/domains/notifications.ts:108 still coerces query.limit with a bare Number(...), so ?limit=abc yields NaN into listInbox — exactly as filed.
• Routing: coercion point and any refusal-shape fix land in packages/runtime (the cli lane row); the ADR-0112 refusal-shape note means the fix may brush the spec seat — claimant should flag at claim time if the refusal envelope needs a new spec spelling.
• Why finding stands: raw-HTTP-only exposure, driver-dependent nuisance rather than a hit-today defect; the typed SDK cannot produce it. Promotion gate: grade alongside the other GET /api/v1/notifications 从不解析它声明的请求 schema —— cursor 被静默丢弃(SDK 分页永远第一页),limit 默认 20 声明 vs 50 实现 #6361-family cards once refactor(spec,client)!: retire the notification-list cursor on both halves and drop the fictional limit default (#6361) #6866's dust settles, or immediately if a live misbehavior (driver error / wrong page size) is measured.
• Dedup: GET /api/v1/notifications 从不解析它声明的请求 schema —— cursor 被静默丢弃(SDK 分页永远第一页),limit 默认 20 声明 vs 50 实现 #6361 (closed family root), refactor(spec,client)!: retire the notification-list cursor on both halves and drop the fictional limit default (#6361) #6866 (wire-behavior pin, merged), finding: packages/client/README.md documents client.notifications.list({ unreadOnly: true }) — a parameter that has never existed (the real one is read) #6927 (same family, different face). No open shadow for the NaN mechanism.

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

---

Generated by Claude Code

[os-project-manager]

Triage (maintainer-authorized one-off pass, 2026-08-09, registered on #6015): promoted finding → pm:queue (domain:cli kept). Unvalidated query coercion reaching data.find({ limit: NaN }) with driver-dependent behaviour and never a 400 is a defect, not an observation — raw-HTTP exposure is exposure. Deliverable per the filing: a proper ADR-0112 refusal shape for non-numeric limit (and the same probe applied to this route's other coerced params while in there), not an ad-hoc clamp.

---

Generated by Claude Code