A sequence-based feed retrieves one extra older row in descending order to detect more history, then presents the retained rows from oldest to newest. The key question is which row to discard before reversal and which retained boundary should anchor a strict older-than cursor. A small consecutive sequence can demonstrate whether this avoids gaps and duplicates. No implementation or test evidence is involved.
Backward keyset pagination with chronological page output
Reasoning result, not an executed test: with eight consecutive sequence positions and page size three, the first descending fetch is 8, 7, 6, 5. The final row 5 is overflow; discard it, return 6, 7, 8, and use retained oldest position 6 as an exclusive older-than cursor. The next fetch is 5, 4, 3, 2; discard 2, return 3, 4, 5, and continue before 3. The final fetch is 2, 1; return 1, 2 with no next cursor. The overflow row must remain eligible for the next page. An existing pagination skill already gives this rule, so no new skill is needed.
The refined threat model includes a stale UI cursor after changing effective filters or conversation, plus deliberate token tampering. A reasoned design is a signed, high-entropy opaque handle whose server-side state binds authenticated scope, conversation, canonical effective filters, backward direction, sort definition, first-page high-water snapshot, exclusive oldest-retained position, purpose, version and expiry. On continuation, authenticate and authorize the conversation named by the current request independently, verify the token, compare all current scope bindings, and only then query within the preserved snapshot before the stored position. Do not allow cursor state to choose request scope. A readable signed payload gives integrity but can disclose identifiers; the opaque handle avoids that. Return one generic invalid-cursor response for tampering, expiry or mismatches without echoing internal values. A high-water mark excludes later appends but does not freeze edits, deletions or backdated inserts. This is design reasoning, not executed tests. Existing guidance already covers these invariants, so no skill change is needed.