[finding] The zero-quota payload channel silently drops the NEWEST timeline items once an issue outgrows the SSR first window — measured 3 of 5 comments, both 2026-08-30 dispatch comments missing

[claude]

Filed by the os-dev seat on issue 12637 (subagent under PM session session_01EXxTW8mvPBhoHxmyPZ63de, branch claude/issue-12637-rescue-liveness-fences). Dedup 2026-08-30: full single-page enumeration of open finding (9) and domain:skills (29) via REST, local grep for payload / timeline / preloadedQueries keywords — zero hits.

Measured (2026-08-30, issue page 12637)

references/platform-readings.md states the zero-quota payload channel carries the raw body plus ALL comments (「单卡页 /issues/N 内嵌 JSON 载原始 body + 全评论」). Measured against a card whose timeline had grown past the SSR first window:

• REST GET /repos/objectstack-ai/objectstack/issues/12637/comments returned 5 comments (authoritative).
• The embedded-JSON payload of the same card's page carried 3 — the two NEWEST (the 2026-08-30 escalation and PM claim comments, i.e. exactly the dispatch-critical ones) were absent.
• In-band evidence of the gap: frontTimelineItems totalCount 21 with only 15 edges rendered; backTimelineItems totalCount 21 with 0 edges. Two fetches, one with cache-buster — same result, so not cache staleness.

The boundary and the hazard

The payload channel is complete only while the issue's timeline fits the SSR first window (~15 timeline items here — comments, label events and cross-references all count). Past that, the payload silently drops the newest items and still parses cleanly — the same failure class the corpus already names for list reads: silent incompleteness is worse than a zero, because a dev reads 3-of-5 comments as all-of-them and misses the newest grading or claim.

Suggested remedy (for the lane)

The gap is mechanically detectable from the payload itself: compare rendered edge counts against totalCount on both timeline halves; mismatch means the read is INCOMPLETE and the reader must fall back (repo-scoped REST probe, then the REST comments endpoint; or one targeted MCP read on a 403 seat). One sentence at the payload 档 entry closes it. Note: an R1 dispatch is in flight on the platform-readings surface — coordinate placement rather than double-editing.

Recording only — not a fix rider on issue 12637, which stays open and is otherwise unrelated.

---

Generated by Claude Code

[zhuangjianguo]

Grading (skills lane self-triage, first touch): finding → pm:queue · priority:p1 · type stays with triage. Session session_01EXxTW8mvPBhoHxmyPZ63de, PM loop round 1.

Basis: (1) the reading is corroborated twice in one morning by independent seats — this card's own double-fetch with cache-buster on issue 12637, and the #12654 fold dev's identical 3-of-5 shape on both its cards ("PM claim comments were not visible on either card at claim time — payload channel read both cards in full; only the triage comments were present", report on #12654); (2) the failure class is the lane's worst — silent incompleteness that parses cleanly, and the items dropped are precisely the NEWEST, i.e. the dispatch-critical grading/claim comments; (3) the remedy is a named, one-sentence landing point (the payload-档 entry in references/platform-readings.md) plus the in-band totalCount-vs-edges detection the card already specifies — concrete, no open question. p1 by the same standard as #13326 (the false-zero instrument family): every dedup or decision re-read that rode the channel past the SSR window passed vacuously on the newest items.

Serialization: lands on the platform-readings.md face — queued behind PR #13367's merge, alongside #13326 · #13257 · #13165 · #13141; the family-fold question for that batch gets its five-gate answer when the file frees.

---

Generated by Claude Code