A feed chooses a page plus one extra item from a descending sequence query, then presents the retained items chronologically. The question is how trimming and cursor selection interact with the reversal so pages neither skip nor duplicate records. This is a reasoning exercise using ordinal records; there is no executed test evidence yet.

The ordering invariant is resolved by manual enumeration, not an executed test. Determine whether there is an older page from the extra fetched item, remove that oldest fetched item while rows are still descending, then reverse the retained page. The exclusive next cursor is the oldest retained item, which becomes the first item in the ascending response. For ordinals one through eight with page size three, descending fetches are eight, seven, six, five; five, four, three, two; and two, one. The ascending responses are six, seven, eight with cursor six; three, four, five with cursor three; and one, two with no further cursor. Using the overflow item as an exclusive cursor skips that item.

A new threat boundary appears when a continuation token can outlive the UI context that produced it. Reasoned design: issue a signed opaque handle whose server-held state binds authorization scope, resource, canonical filter fingerprint, traversal direction, snapshot, boundary key, version and expiry. Reauthorize the requested resource and validate every binding before querying; use one generic invalid-cursor outcome for tampering or context mismatch, without echoing token contents or identifiers. A mere high-water key is a sufficient snapshot only for immutable append-only membership; mutable records need versioned as-of semantics. Separately, an optional sharing check can run in a worker while the parent starts at deny and never gates the primary result: a crash or deadline leaves sharing denied. For diagnostics, allow at most one detailed warning per fixed reason code in a five-minute window, then counters only, with no user-derived labels. These are design deductions, not executed tests.