[leandrotcawork]

O que muda

A U2b de "O Sync de qualquer conector": as quatro respostas reais do Mercado Livre entram no repositório com todos os valores trocados por inventados (T29, S40), o gravador que as produz, e o dublê passa a responder pelas formas gravadas. Já traz o commit 9df1bbce (as declarações de lista e a paginação do dublê, da branch da U3) mesclado: a resposta gravada vence onde divergiam.

• scripts/record-connector.ts (+ -calls, -swap, teste): o pedido sai da declaração da operação, os bytes ficam crus só em pasta fora do repositório, e --swap troca cada valor por um inventado da mesma forma (o mesmo valor real vira sempre o mesmo inventado; datas movidas juntas) e grava em recordings/ com serviço, rota, data e os campos trocados. --plan imprime os quatro pedidos para quem grava de uma máquina onde só roda Python.
• packages/connectors/src/mercado-livre/recordings/: pedidos-alterados, anuncios-varredura-1, anuncios-varredura-2, perguntas-varredura; todos com status 200, gravados em 2026-11-12 pela loja do fundador, só leitura.
• O dublê (fake-data.ts, fake-routes*.ts) lê as gravações (recordings.ts, só quando pedido): as 120 linhas de pedidos e as perguntas têm a forma gravada, e os envelopes das quatro respostas (query, orders, available_orders, filters, available_sorts…) saem delas. O comprador e o autor da pergunta continuam plantados com texto pessoal, de propósito, para o corte provar (critério 10); o serviço real não os manda nessas rotas e o teste os nomeia.
• fake.test.ts, "as respostas gravadas" (critério 11): rota e nomes de query do pedido que a declaração monta == o gravado; cada caminho e tipo gravado existe na resposta do dublê; nada além do plantado.
• operations-list.test.ts: o teste do cursor da varredura usa os corpos gravados no lugar dos digitados à mão; a recusa de offset com varredura (N3) ganha as linhas. O arquivo segue a divisão que a branch da U3 já fez (operations.test.ts passava de 300 linhas).
• conformance-list.ts: a chave da caminhada é o primeiro campo escalar da linha (a primeira chave da linha gravada de um pedido não é texto).
• anuncios e perguntas: o probe deixa de mandar offset: 0 (o padrão da API é 0): a caminhada o carregava como entrada fixa e a recusa de offset com varredura (N3) a derrubava.
• biome.json: recordings/ fora da checagem de formato, como o logo.svg: são os bytes gravados, trocados.

O que a gravação mostrou

• A varredura de anúncios devolve scroll_id na primeira página e também na página sem linhas que a segue; paging traz só total e limit (sem offset). Com limit maior que o total, a primeira página já traz tudo e a segunda vem vazia: o fim é a página sem linhas, como a declaração e o dublê já diziam.
• A varredura de perguntas (search_type=scan) devolve scroll_id: F-U2a-2 respondida, a "Parar se" do cartão não vale.
• Pedidos por order.date_last_updated.from: paging com total, offset e limit; o comprador vem só com id e nickname.
• Não verificado: se as páginas seguintes de perguntas repetem search_type; a validade de 5 minutos (só a documentação a diz).

Troca de valores

Campos trocados por gravação (caminhos sem índice, valores nunca impressos): pedidos 66, anúncios página 1 10, página 2 9, perguntas 19. A conferência contra os corpos crus: nenhum valor sensível (ids, apelidos, nomes, endereços, documentos, preços, scroll_id) de 166 conferidos aparece nas gravações. A conferência achou um vazamento que a troca ainda não cobria, filters.caller (o id da conta, ecoado nos filtros das perguntas); a regra agora o cobre, com teste.

Como foi provado

Testes tocados de packages/connectors e scripts/record-connector.test.ts (194 testes, 0 falhas), tsc do pacote e dos scripts, biome check, npm run docs. Os testes do servidor que usam o dublê (connections-copies, connections-oauth-logs) precisam do banco de teste e ficam para o CI.