List the tenant's rail commands and the operations that leave no record

Walks the tenant’s rail-command book, newest invocation first: what this gateway told the payroll rail to do, and what the rail answered.

It records TWELVE commands, the twelve migration 000078 admits: refinanciamento, its reversal, renegociação, the origin-side portability exclusion, both antecipação de parcela operations, all three empréstimo legado operations, and the three contract-management ones (suspensão, reativação, alteração de termos). Each row carries the situation it is durably parked in, reported exactly as it stands: an invoking row whose deadline has passed is the row the recovery sweep will convert, and this read never anticipates that conversion.

‘unlogged_operations’ is a FIXED list rather than anything derived from the rows, and it names TWO operations, both on the portability path: averbarConsignadoPortabilidade and respondConsignadoPortabilityAuction. Their command services hold no durable store of any kind, so nothing on this side can report what the rail was told or what it answered, and an empty book is NOT evidence that no call departed — which matters because portability moves a consignado contract between institutions. The list held five ids until migration 000078 (the two antecipação de parcela operations and the three legado ones), each for the same reason, and those five left it by the opposite route: they now claim a durable row before the call departs and close it after the answer lands. These two leave the list the same way, and only that way, once their services gain that write. The field is published even when empty, so a client can tell “no operation is unlogged” from “this gateway stopped reporting it”; a rail operation added later with no durable record of its own appears here too.

Not every command is CONVERGIBLE. A Manual 005 contract read decides the outcome of refinanciamento, its reversal, renegociação and the portability exclusion, so an ambiguous row of those four leaves outcome_unknown once the recovery pass reads the registry. The other eight have no such decisive read. A legado contract number, for instance, may be registered by an earlier attempt, another channel or the institution itself, so its presence proves the number is taken and not that this command committed. One of their rows that reaches outcome_unknown STAYS there. That is the truth about the call, not a queue nobody drains, and the situation filter is how you find them.

‘unknown_at’ SURVIVES on a closed row. An outcome that passed through ambiguity keeps that evidence, which is what lets a screen tell a clean acceptance from a recovered one. ‘response_code’ and ‘response_message’ are null on an invoking row, which the ledger’s own constraint demands, and they are the refusal reason an operator came to this screen to read.

Three columns of the stored row never leave: the rail’s raw answer, the request digest and the idempotency key. The first can carry fields no screen was meant to publish; the other two are the money fence’s own transport evidence.

‘command’ and ‘status’ may each be repeated to narrow the page to several values at once (status=invoking&status=outcome_unknown). Omitting a filter means ALL of its values, never none. A value outside either vocabulary is refused with 422 rather than matching nothing, because a page that matched nothing is indistinguishable from a tenant that never called the rail.

Paging is keyset over the invocation instant and the row id, both frozen for the life of the row by the ledger’s own trigger, which is what makes the position safe against a book the money path is still writing. 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, so a client loop may terminate on either. The cursor never expires; a cursor this service did not mint is refused with 422 rather than silently restarting the walk from the top.

It answers from a LOCAL table and never reaches the Dataprev rail, so it cannot answer 501 and it is served on a deployment with the rail off entirely. That deployment simply has an empty book. The tenant is derived from the validated identity and is never read from the request.