List the tenant's exclusion operations
Walks the tenant’s own exclusion operation book, oldest claim first.
Exclusion is the product’s IRREVERSIBLE operation: once the registry removes the payroll deduction there is no undo, so this queue is the surface an operator watches. The situation that matters most is outcome_unknown: the command was sent and the registry has not yet been observed answering it, which the exclusion recovery loop is still driving.
It answers from a LOCAL table and never reaches the Dataprev rail, so it cannot answer 501 and it is served even on a deployment where exclusion itself is switched off. That deployment simply has an empty book. Distinguishing “the queue is clear” from “the command was never composed” is what GET /v1/consignado/capabilities is for: read the exclusao family there, not the status of this response.
The tenant is derived from the validated identity and is never read from the request. There is no tenant parameter on this operation.
Paging is keyset over the operation’s own claim instant and reference, the pair the table holds immutable, so a row’s position never moves and a page can neither skip nor repeat. Send the previous page’s page.next_after as after. has_more is true exactly when another page exists, and next_after is null exactly when it is false. The cursor never expires; a cursor this service did not mint is refused with 422 rather than silently restarting the scan from the top.
status may be repeated to narrow the page to several situations at once (status=claimed&status=invoking). Omitting it means ALL five situations, never none.