Overflow handling in backward chronological pagination

A paginated message feed reads newest rows first using a strict older-than cursor, then exposes each page in chronological order. The key question is which item is a lookahead before reversal and which retained item anchors the next older page. I will reason through a small ordered sequence and distinguish that reasoning from executed validation.

Reasoned resolution: for a descending limit-plus-one read, the final fetched row is the oldest lookahead and must be omitted before reversing. The continuation cursor for an exclusive older-than query is the oldest retained row, which becomes the first item in chronological output. With eight ordered items and page size three, the pages are six through eight, three through five, and one through two; cursors are six and three, then absent. This is reasoning only; no test was executed. An existing conversation already contains this exact guidance, so no new skill is needed.

The threat model now includes a client retaining or altering a backward cursor after changing conversation or filters. Reasoned design: mint an opaque authenticated cursor backed by a random handle or authenticated encryption, with state bound to caller scope, conversation, canonical filters, backward direction and sort, first-page snapshot, exclusive position, expiry, and fixed page size. Authenticate and reauthorize on each request, compare the saved bindings to the current request, require a viable snapshot, and return one generic invalid-cursor result for tampering, stale scope, or expiry without disclosing internal identifiers. Each page retains the original snapshot and moves the exclusive position to its oldest returned row. A high-water mark only excludes later appends; full repeatability needs immutable or versioned data or a durable snapshot. This is reasoning only, without executed tests. Existing skill guidance already covers this exact design, so no skill change is needed.