O que mudou no app, no servidor e neste painel, do mais novo para o mais antigo.
outubro de 2026
App6.0.35
App 6.0.35 — botão do DANFE
O botão da nota na coleta passa à opção 1 escolhida em 02/10.
"Bipar código de barras do DANFE" numa linha, com o desenho do código de barras embaixo.
Sem a palavra QR, também na tela da câmera.
Suíte fechou 527 de 527.
App6.0.34
App 6.0.34 — alterações do romaneio e coleta sem volume
Os dois ajustes combinados em 01/10.
Romaneio com serviço pendente continua tendo as alterações consultadas, mesmo quando o TMS responde "não localizado".
Coleta feita não passa com 0 volumes; o app orienta usar "Não foi possível coletar".
Suíte fechou 527 de 527.
App6.0.33
App 6.0.33 — relatório Android de 30/09
Os sete itens do teste no Android: textos do login e da bipagem, código de transportadora com 2 dígitos, tipo do documento de viagem e o teclado que cobria os campos.
Login: mensagem inteira, botão "Receber serviços" e código com 2 dígitos.
Documento de viagem com tipo e número: RE, MDF-e, MDM, RC e MDO.
Bipagem sem MDF-e, sem subtítulo e sem o texto do rodapé; botão "Bipar código de barras ou o QR do DANFE".
Teclado: o campo em digitação fica sempre visível.
Suíte fechou 521 de 521.
setembro de 2026
App6.0.32
App 6.0.32 — o GPS para no último serviço e ao desconectar
O relatório de 29/09. O app mandava parar o GPS no fim do romaneio e no desconectar, mas conferia o estado numa leitura antiga e não parava. Agora para de verdade.
Último serviço baixado: o app para de ler a localização.
Desconectar: para na hora, com ou sem serviço pendente.
Central incluiu serviço depois: o rastreamento volta e para de novo na baixa.
Aparelho com o GPS preso pela versão anterior é liberado; posição lida depois do desconectar não sobe.
Suíte fechou 514 de 514.
App6.0.31
App 6.0.31 — som em todas as fotos, alerta de coleta nova em qualquer caminho, obrigatoriedade do recebedor pelo TMS
O relatório de 22/09. O clique da foto tocava em uma e pulava a seguinte: o vídeo enviado mostra 8 capturas e o som saiu em 5. O app mandava rebobinar e disparar no mesmo instante, e quando o disparo chegava primeiro tocava o fim do arquivo, que é silêncio. Agora espera o rebobinar e toca em todas. O alerta de coleta nova passou a tocar onde o serviço é detectado, o que cobre os dois relatos do dia: romaneio com uma coleta só e coleta inserida pela central. E a obrigatoriedade de nome, RG e assinatura passa a seguir o TMS: o servidor confirmou que parâmetro inativo não gera a linha no JSON, e o app lia esse silêncio como "exige".
Foto: o clique toca em todas as capturas; antes pulava uma a cada duas, em média.
Romaneio: o alerta toca no momento da detecção, inclusive em segundo plano e com uma coleta só no romaneio.
Recebedor: linha ausente no JSON passa a valer como parâmetro inativo; se o bloco da transportadora não chegar, o app volta a exigir os três.
Auditoria: a abertura de sessão registra qual padrão foi aplicado quando o TMS não manda a obrigatoriedade.
Suíte fechou 506 de 506.
App6.0.30
App 6.0.30 — som na foto e na coleta nova, voltar na tela de foto
Os quatro itens do relatório de ajustes de 21/09. A câmera passou a tocar um clique a cada foto, em coleta, entrega e ocorrência, e o som sai mesmo com o aparelho no silencioso, igual nas duas plataformas. Coleta ou romaneio novo agora avisa com som, além do aviso visual. A tela de foto ganhou a seta de voltar: quem bipou uma nota e percebeu que faltavam outras volta para a leitura de NF-e, remove a errada e segue, sem perder a baixa. E nome e documento do recebedor deixam de ser exigidos quando o TMS diz que não são — o app lia a obrigatoriedade do documento de um lugar só e, na falta, exigia. Homologação: TestFlight no iPhone, APK do Expo no Android.
Foto: clique curto a cada captura, nas três telas que tiram foto; funciona no silencioso e no Android.
Romaneio: alerta sonoro quando entra coleta ou romaneio novo, uma vez por lote.
Baixa: seta de voltar na tela de foto — dá para rever e remover NF-e bipada antes de baixar.
Recebedor: nome e documento só são exigidos se o TMS exigir; a obrigatoriedade passa a ser lida em qualquer grafia de chave e também no cadastro da transportadora.
Auditoria: a abertura de sessão registra de qual chave veio cada obrigatoriedade — nomes de chave, nenhum dado de pessoa.
Suíte fechou 502 de 502.
App6.0.29
App 6.0.29 — o app para de conferir dígito de RG
RG não tem regra nacional: cada estado emite do seu jeito, vários não têm dígito e o campo é um só, "RG OU CPF", sem a UF. O RG de São Paulo tem 8 números mais o dígito, e quem digitava só os 8 — que é o comum — recebia "Confira o RG: o dígito não bateu" num documento correto. Agora o app recusa só o que não pode ser documento nenhum: vazio, menos de 5 números, número repetido ou sequência. Onze números com dígito de CPF errado viram aviso, não erro. Nas 176 baixas de 11 a 21/09 o TMS nunca recusou uma baixa por causa do documento. Homologação: TestFlight no iPhone, APK do Expo no Android.
Recebedor: dígito de RG deixa de ser conferido — RG correto não dá mais alarme falso.
Recebedor: barra só o impossível (vazio, menos de 5 números, repetido, sequência).
Recebedor: 11 números com dígito de CPF errado viram aviso, não erro — pode ser RG de 11 posições.
Auditoria: 176 baixas de 11 a 21/09, nenhuma recusada pelo TMS por causa do documento.
Suíte fechou 496 de 496.
App6.0.28
App 6.0.28 — RG e CPF conferidos de verdade, teclado fecha no ditado e prazo da coleta no card
O campo RG ou CPF passa a decidir pelo tamanho: CPF confere os dígitos verificadores e RG de 8 ou 9 posições tem o dígito conferido pela conta de SP, como aviso, sem travar quem tem RG de outro estado. Obrigatório errado trava dizendo o motivo; opcional errado não trava e fica de fora da baixa. Tocar no microfone fecha o teclado. O card mostra o prazo da coleta, a auditoria conta esse campo e o tamanho dos anexos, e romaneio encerrado deixa de ser consultado em segundo plano. Homologação: TestFlight no iPhone, APK do Expo no Android.
Recebedor: 11 dígitos é CPF com dígito verificador; RG de 8 ou 9 posições conferido pela conta de SP, como aviso.
Recebedor: obrigatório errado trava com o motivo; opcional errado avisa e fica de fora da baixa.
Ditado: o microfone fecha o teclado.
Coleta: prazo (coletarAte) no card; auditoria conta o campo e o tamanho de cada anexo.
Romaneio encerrado sai da consulta em segundo plano.
Suíte fechou 500 de 500.
App6.0.27
App 6.0.27 — card da lista no protótipo, rodapé certo no iPhone e telas com um dono por assunto
O card do serviço atual na lista passa a seguir o protótipo: faixa "COLETA · AGORA" ou "ENTREGA · AGORA", CL junto dos documentos, seta para cima na coleta e para baixo na entrega, e "Bairro · Cidade/UF". No iPhone o botão de baixo deixa de ficar colado no indicador de início e o login perde o espaço duplo embaixo; no Android com botões nada muda. Por dentro, cada assunto de tela ganhou um dono só, sem mudar pixel fora do combinado. Homologação: TestFlight no iPhone, APK do Expo no Android.
Lista: card do serviço atual igual ao protótipo (faixa, CL, setas, Bairro · Cidade/UF).
iPhone: área segura de baixo é a maior entre a reserva do aparelho e a folga da tela, não a soma.
Telas: área segura, raiz, rodapé, botão de ícone escuro e cabeçalho escuro com um dono cada.
Suíte fechou 482 de 482.
App6.0.26
App 6.0.26 — fila só com o que foi baixado e auditoria contando os campos da coleta
A fila de envio volta a mostrar só o que o motorista já baixou, com o estado da transmissão; serviço sem baixa não aparece mais como "aguardando baixa". O resumo do romaneio (baixados, sem baixa, no romaneio) fica num bloco à parte. A auditoria passa a contar, a cada sessão, quantos serviços vieram com número da coleta, janela e volumes previstos, para conferir o que o TMS manda. Homologação: TestFlight no iPhone, APK do Expo no Android.
Fila: só entra serviço com baixa concluída; estados aguardando envio, enviando, enviado, bloqueado e erro.
Resumo do romaneio separado da fila: baixados / sem baixa / no romaneio.
Auditoria: contagem por tipo de serviço dos campos que vieram preenchidos; nenhum dado do serviço.
Suíte fechou 472 de 472.
App6.0.25
App 6.0.25 — fila espelha o romaneio, áudio reduzido antes de subir e os itens de 15-16/09
A fila de envio passa a mostrar o romaneio inteiro, com o estado real de cada serviço e o resumo executados / pendentes / no romaneio. O áudio do ditado que a central recusava por tamanho é reduzido no aparelho antes de subir, e o que ficou preso sobe sozinho depois de atualizar. Documento do recebedor só valida quando é obrigatório. Coleta com CL-número, volumes e horário no card. Homologação: TestFlight no iPhone, APK do Expo no Android.
Fila: cada serviço do romaneio com o estado real; resumo executados / pendentes / no romaneio; concluído e tudo enviado limpa a lista.
Áudio: gravado em 16 kHz e reduzido acima de 1 MB; HTTP 413 não trava a fila; áudio preso da 6.0.24 sobe sem reinstalar.
Baixa: RG ou CPF opcional passa sem validar; obrigatório recusa até 6 dígitos.
Lista: coleta com CL-número, volumes previstos e horário; botão "Não foi possível coletar".
Suíte fechou 466 de 466.
App6.0.24
App 6.0.24 — romaneio consultado em segundo plano e os 5 itens da validação de 14/09
Coleta nova só aparecia depois de sair e entrar: a consulta do romaneio só rodava com a lista aberta. Agora roda junto com cada posição enviada, na tarefa de fundo e ao voltar para frente. Os outros quatro itens do relatório também entraram. Homologação: TestFlight no iPhone, APK do Expo no Android.
Romaneio: alterações e romaneio novo consultados em segundo plano, inclusive minimizado; coleta nova entra sozinha.
Baixa: RG ou CPF inválido avisa em vermelho no campo; 1234567 e sequências são recusados.
Baixa e ocorrência: sem gesto de voltar do iOS 26 na assinatura.
Fila: o que já foi enviado some; o resto mostra o cliente da baixa.
Suíte fechou 442 de 442.
App6.0.23
App 6.0.23 — assinatura com fundo branco e anexos presos à baixa
A conferência da coleta 2425 com o fornecedor achou dois pontos do app: a assinatura ia com fundo transparente e podia ficar preta no TMS, e uma foto subiu antes da baixa, sem ligação com ela. Homologação: TestFlight no iPhone, APK do Expo no Android.
Assinatura: PNG com fundo branco. Refeita na mesma baixa, vale a mais recente.
Anexos: foto e prova de ocorrência nascem ligadas à baixa em andamento e só sobem depois que a baixa existe.
Anexos: fotos e áudios soltos do mesmo serviço passam para a baixa atual ao abrir ou retomar a baixa.
Suíte fechou 434 de 434.
App6.0.22
App 6.0.22 — romaneio finalizado não volta e documento validado
O teste da 6.0.21 achou dois pontos do app: sair e entrar logo depois de finalizar o romaneio trazia ele de volta, e o RG ou CPF ditado saía como telefone, sem validação. Homologação: TestFlight no iPhone, APK do Expo no Android.
Romaneio: serviço concluído nunca volta ao sair e entrar de novo. Com tudo baixado o app abre limpo; se sobrou pendente, volta só ele.
Baixa: o ditado do RG ou CPF deixa só os números (e o X do RG), sem formato de telefone.
Baixa: CPF só passa com dígito verificador válido e RG com 7 a 10 dígitos. Valor inválido não conclui a baixa, mesmo com o campo opcional.
Suíte fechou 433 de 433.
App6.0.21
App 6.0.21 — pendente fica no aparelho até a baixa
Na entrega itinerante o motorista roda dias com a carga. A lista guardada no aparelho vencia em 12h depois do logout e o TMS não entrega de novo o que já entregou, então coleta aberta sumia. Agora o pendente fica sem prazo.
Romaneio: entrega e coleta pendente ficam no aparelho sem prazo, até a baixa, mesmo saindo do app e voltando dias depois.
Romaneio: o que já foi baixado só volta se o motorista entrar de novo em até 12h, para a lista não acumular serviço concluído.
Login: sem sinal, o app abre a lista que está no aparelho, com aviso na tela.
Romaneio: a lista guardada é separada por motorista. Outro motorista saindo no mesmo aparelho não apaga a de ninguém.
Foto que ficou só em rascunho no momento do logout não é guardada: a coleta volta pendente e a foto é tirada de novo.
Suíte fechou 433 de 433.
App6.0.20
App 6.0.20 — id do serviço vem do TMS e o aparelho começa limpo
O TMS passou a devolver servicoId em cada documento da sessão. O app agora usa esse id na baixa, e zera o banco local na primeira abertura porque os ids gravados antes estavam errados.
Baixa: o id do serviço passa a ser o `servicoId` que o TMS devolve na sessão, em vez de derivado do número do documento. Medido na noite de 11/09 em 10 placas: 57 serviços, 57 com o id preenchido.
Banco: na primeira abertura da 6.0.20, romaneio, baixa, anexo e fila gravados pelas versões anteriores são apagados — os ids antigos apontam para serviço que o TMS não reconhece. Roda uma vez só. Comece o teste com romaneio novo, não no meio de um com baixa pendente.
Lista: o "faltam 4 de 8" com romaneio de 4 entregas some junto. A contagem estava certa; o que sobrava era serviço de romaneio antigo ainda no banco.
Anexos: arquivo acima de 4190 KB (`codigo 44`) para de ser retentado — o arquivo não encolhe entre uma tentativa e outra, e insistir só enchia a fila.
Anexos: `codigo 60` depois de uma queda de rede conta como já recebido, mesmo tratamento que o `codigo 31` já tinha.
Alterações do romaneio: confirmado com o fornecedor que a rota só aceita data à frente da última sincronizada, e devolve `codigo 13` para data retroativa. O app ignora e segue — nada trava e nenhum serviço se perde. Quem mantém a lista em dia é o refresh da sessão.
Suíte fechou 428 de 428.
App6.0.19
App 6.0.19 — fotos, assinatura e áudio voltam a subir
O vídeo do teste de 11/09 mostrou a fila parada nos anexos. O defeito era do app, desde a 6.0.13, e está corrigido. A baixa reenviada depois de uma queda também deixa de travar.
Anexos: o arquivo não chegava a sair do aparelho. O Expo 57 recusava o formato em que o app montava o envio, e o app registrava isso como "sem conexão". Nos logs, 837 falhas e nenhum anexo enviado desde a 6.0.13. Agora foto, assinatura e áudio sobem no formato que ele aceita, e o que estava na fila sobe sozinho depois de atualizar.
Anexo cujo arquivo sumiu do aparelho mostra o motivo, em vez de "sem conexão".
A falha de rede passa a registrar o erro original no log, para não esconder outro defeito atrás de "sem conexão".
Baixa: o TMS segue respondendo 500 codigo 23 para a mesma idempotência (medido de novo em 11/09 à noite). Quando a tentativa anterior caiu por rede, o 23 é o reenvio de uma baixa que chegou, e o app conta como enviada. Na primeira tentativa, ou depois de uma recusa do servidor, continua mostrando o motivo.
Suíte fechou 424 de 424.
App6.0.18
App 6.0.18 — medido na homologação de 11/09 à tarde
A homologação voltou e a 6.0.17 foi medida com os corpos exatos do app: tudo que o TMS passou bateu com o servidor. A 6.0.18 traz os três ajustes que saíram da medição.
Medido: posições 200, alterações pela rota nova 200, anexo repetido 409, ocorrência com e sem recebedor 200, coleta com "NFE" 200.
Na coleta só entra chave de NF-e (modelo 55 e dígito verificador). Chave de CT-e o TMS recusa com codigo 58, e agora o app recusa antes de enviar.
Baixa respondida com 409 conta como já enviada.
Romaneio com codigo 13 nas alterações (não localizado) é pulado sem mostrar erro nem segurar a sincronização dos outros.
Com o TMS: baixa com idempotência repetida responde 500 codigo 23 (pedido 409), e a sessão da placa ABC1020 está sem serviço (codigo 7).
Suíte fechou 422 de 422.
App6.0.17
App 6.0.17 — alinhado à resposta do TMS de 11/09
O TMS respondeu os pontos em aberto e publicou o formato de posições e a rota nova de alterações. A 6.0.17 segue o que foi passado.
Alterações na rota nova: /mobile/romaneio/{transportadora}/alteracoes?romaneio=…&desde=… — o número com barra vai no query string.
Posições no corpo do swagger: transportadora numérica, lat/lon em texto com ponto decimal.
Posição da baixa também com ponto ("-23.5505"), não mais vírgula.
codigoOcorrencia numérico (ocorrenciaIdMobile).
Tipo do documento na coleta vai escrito, como o TMS confirmou: "NFE" (na coleta só vale NF-e).
Anexo repetido: o app aceita o 409 que o TMS vai passar a devolver como "já recebido".
Tipo 4 passou a aparecer como Minuta (antes saía MD-e); MDF-e é o 2.
Bloco novo de parâmetros lido: fotos de coleta e de entrega e telefone da central.
Não validado em homologação: o ambiente está fora desde 11/09 (500 do IIS em todas as rotas, erro de configuração do web.config).
Suíte fechou 417 de 417.
App6.0.16
App 6.0.16 — a baixa grava na homologação
O corpo da baixa passou a seguir o schema enviado pelo TMS em 11/09. Entrega, coleta com fotos e assinatura e ocorrência gravaram em homologação.
O 500 da baixa vinha do corpo que o app mandava: resultado em texto, como no contrato publicado, quando o servidor espera o objeto {executado, ocorrencia, executadoEm}.
Validado em homologação: entrega com recebedor, coleta com 2 fotos e assinatura, ocorrência. Todas com HTTP 200 e baixaId.
O recebedor vai sempre, vazio na ocorrência, porque sem ele o servidor responde 500.
Baixas que estavam paradas na fila saem no formato novo depois da atualização.
A auditoria passou a gravar o corpo exato que sai, com nome e documento do recebedor mascarados.
O contrato medido (/contrato) foi atualizado: a baixa passou de defeito para ok.
Suíte fechou 411 de 411.
Painel2.0.11
O contrato medido no ar, em OpenAPI 3.1
A documentação da API deixou de ser só a proposta e passou a ter também o que o servidor realmente responde — no formato que qualquer desenvolvedor abre sem explicação.
Nova página /contrato: as cinco rotas em OpenAPI 3.1, com corpo, campos obrigatórios, códigos de erro observados e as divergências entre o contrato publicado e o medido.
O arquivo cru fica em /contrato.yaml — dá para baixar e abrir no Swagger, no Postman, no Insomnia ou gerar cliente a partir dele.
Cada rota traz x-status (ok ou defeito) e, quando diverge, x-divergencia dizendo o que o servidor faz de diferente e qual chamada provou.
Servidor
As rotas /mobile/* subiram em homologação — 105 chamadas medidas
A equipe do TMS colocou o caminho B de pé em homologação e liberou dois romaneios de teste. O app bateu nas cinco rotas, chamada a chamada, e o que voltou virou um documento em OpenAPI 3.1: o contrato medido.
Ambiente: wshomdev.grupoaleff.com.br, transportadora 999, romaneios 720/26 (coleta, 5 serviços) e 2303/26 (entrega, 9 serviços) — com os quatro tipos de documento dentro.
Passam: POST /mobile/sessao, POST /mobile/anexos e POST /mobile/posicoes. A sessão devolve os romaneios completos, com documentos, endereço, destinatário e chaves fiscais.
Não passa: POST /mobile/servicos/{id}/baixa responde HTTP 500 em 100% das chamadas — "Object reference not set to an instance of an object". Foram treze formatos de corpo diferentes e nove serviços diferentes; nenhum passou.
Não passa: GET /mobile/romaneio/{transportadora}/{romaneio}/alteracoes é inalcançável — o número do romaneio tem barra ("720/26") e a barra faz o roteamento perder a rota.
O anexo estava recusando por um detalhe de formato: o servidor faz int.Parse no anexoId e no baixaIdempotencia, e o app mandava UUID. Já corrigido do nosso lado, na 6.0.13.
Tudo isso está aberto, rota por rota, no contrato medido — com o corpo enviado e a resposta do servidor em cada caso.
App6.0.13
App 6.0.13 — falando com a API nova de homologação
A versão que foi usada para medir as rotas novas. Ela já conversa com o ambiente de homologação do TMS e traz as correções que os testes reais pediram.
Quem entra com a transportadora 999 (ou 9999) cai em wshomdev.grupoaleff.com.br; qualquer outra continua indo para o endereço de produção. Não é build separada: é a mesma, decidindo pelo código digitado no login.
Identificador de anexo passou a ser numérico, porque o servidor faz int.Parse nele. O UUID continua sendo usado onde ele não sai do aparelho.
Número com vírgula vindo do TMS ("176,1780") passou a ser convertido explicitamente — em JavaScript, Number("176,1780") é NaN.
Anexo recusado com "código 31" (já enviado) deixa de voltar para a fila em laço: o app entende que aquele arquivo já está lá e segue em frente.
Suíte fechou 384 de 384, tipos e lint limpos.
agosto de 2026
Painel2.0.10
Painel e página da entrega com a identidade Revo
A marca nova chegou também aqui: logo, símbolo e favicon trocados no painel e na página aberta da v6, e os textos que diziam Sitra Mobile passaram a dizer Revo Mobile.
Logo e símbolo do topo, da tela de senha e da caixa de download do APK agora são os da Revo — rasterizados dos vetores oficiais do manual da marca.
A página aberta da entrega (/v6) mudou título, cabeçalho e rodapé para Revo Mobile v6. A referência ao documento "Sitra Mobile 1C" de 12/08 continua com o nome original: é o nome do documento do cliente.
Esta ferramenta passou a se chamar Revo Auditoria. Endereço, senha e funcionamento não mudam.
App6.0.12
App 6.0.12 — o aplicativo agora se chama Revo Mobile
A nova identidade do Grupo Aleff, entregue na direção 1C aprovada, foi aplicada no aplicativo: nome, ícone, tela de abertura e logotipo. É o mesmo aplicativo de sempre — mesmo pacote, mesmos dados, mesma numeração — vestido de Revo.
O nome exibido no aparelho passou de "Sitra Mobile" para "Revo Mobile". Quem já tem o app instalado recebe a mudança como uma atualização normal: nada para desinstalar, nada para configurar de novo.
Ícone novo em todas as formas que as plataformas pedem: o símbolo colorido sobre o fundo escuro da marca — inclusive a versão monocromática que o Android 13+ usa nos ícones temáticos.
A tela de abertura é a arte entregue pelo Grupo Aleff. No iPhone ela aparece inteira, como veio no pacote da marca; no Android, a partir do 12, quem desenha a abertura é o sistema (cor de fundo mais imagem central) — ali entra o bloco central da mesma arte, recortado sem retoque.
A tela de login, a última linha do Perfil e a notificação fixa do rastreamento também passaram a dizer Revo.
Por dentro nada mudou: mesmo pacote, mesmo banco local, mesma fila de envio. A troca é visual — a base é a da 6.0.11 e a suíte fechou 361 de 361.
As fichas nas lojas não mudam agora: o aplicativo segue em teste (canal preview no Android e TestFlight no iPhone). A loja troca de roupa no lançamento.
App6.0.11
App 6.0.11 — destrava o ditado por voz no iPhone; no Android nada muda
Ajuste de configuração do iOS. A Apple exige que o aplicativo declare, por escrito, por que precisa do microfone — e essa declaração estava sendo apagada por uma opção antiga da câmera. O que o motorista vê e faz continua exatamente igual.
iPhone: o texto que explica o uso do microfone voltou para dentro do pacote. Sem ele o iOS encerra o aplicativo no instante em que o ditado tenta gravar — era falha de verdade, não formalidade de loja.
A causa: a câmera estava configurada para dispensar o microfone. Isso era correto enquanto o aplicativo não gravava áudio nenhum; virou errado na 6.0.10, porque essa opção apagava a declaração que o ditado havia escrito.
iPhone: acrescentada também a explicação sobre a galeria de fotos, exigida pela Apple porque bibliotecas usadas pelo aplicativo sabem ler imagens do aparelho. O aplicativo não abre a sua galeria: as fotos de comprovante são tiradas na hora, pela câmera.
Android: nenhuma mudança de comportamento — lá o microfone sempre esteve declarado corretamente. Quem já está com a 6.0.10 instalada pode seguir testando; a 6.0.11 é o mesmo aplicativo, com o número acertado para as duas plataformas andarem juntas.
A 6.0.11 foi enviada ao TestFlight, para os testes no iPhone.
App6.0.10
App 6.0.10 — o ditado por voz está no aplicativo: o motorista fala e o texto entra no campo
O recurso pedido no documento de 12/08 saiu do papel: nome do recebedor, documento e observação da ocorrência podem ser ditados. O reconhecimento acontece dentro do próprio aparelho — a voz não vai para nuvem nenhuma.
Três campos ganharam botão de microfone: nome de quem recebeu, documento de quem recebeu e observação da ocorrência. Toca, fala, o texto aparece no campo — e pode ser corrigido à mão, como qualquer texto digitado.
O reconhecimento é feito NO APARELHO, sem internet e sem serviço de terceiros: a voz do motorista não sai do celular para ser transcrita. Era a condição do documento do cliente (§11) e é o que faz o recurso funcionar dentro do caminhão, onde o sinal falha.
Corte automático: 20 segundos para nome e documento, 60 para a observação. Regravar substitui a gravação anterior — nunca acumula duas do mesmo campo.
A gravação nunca se perde por falha da transcrição: se o aparelho não conseguir transformar a fala em texto, o áudio continua guardado e a tela avisa para digitar o texto. Falar nunca deixa o motorista pior do que digitar.
Aparelho sem reconhecimento local (Android anterior ao 13, ou sem o pacote de português baixado) grava assim mesmo e pede o download do português sozinho — na próxima vez já transcreve.
O aplicativo já registra de onde veio cada campo (digitado, ditado, ou ditado e corrigido). Hoje o que chega ao TMS é o TEXTO, no campo normal da baixa — nada muda para o servidor atual. O áudio fica no aparelho e só passa a viajar quando existir o endpoint de anexos com tipo "audio" descrito na documentação (#voz).
Quem não quiser falar não precisa mudar nada: digitar continua exatamente como era, e o botão do microfone é só mais uma opção do campo.
Tela do Perfil ganhou a linha "Ditado por voz", que diz em uma frase se o aparelho transcreve ou só grava — e, quando só grava, por quê. Isso nasceu de um caso real do dia 12/08: falar e não ver texto aparecer tem cinco causas diferentes que, olhando para o campo vazio, são idênticas.
Correção encontrada no mesmo dia: vários aparelhos perfeitamente capazes não sabem informar quais idiomas têm baixados. O aplicativo tratava essa lista vazia como "não tem português" e desligava o ditado. Agora ele tenta assim mesmo — quem decide é o motor de reconhecimento, não um palpite.
A suíte fechou 361 de 361.
A documentação da API foi acertada no mesmo dia: a seção #voz não diz mais que "nada disto existe no aplicativo" — agora separa o que já está pronto (o aplicativo) do que falta (o tipo de anexo "audio", os campos de origem na baixa e o player no TMS). A lista da adequação continua sem o ditado: ele não depende do servidor de hoje.
Painel2.0.9
Anexos e baixa no formato que o cliente definiu em 12/08 — e o ditado por voz descrito para o TMS dimensionar
O documento "Sitra Mobile 1C" respondeu o formato dos anexos (multipart, anexoId nascido no aparelho) e anunciou o ditado por voz. A documentação foi atualizada no mesmo dia: contrato de anexos e baixa refeitos, e uma seção nova descrevendo o que a voz exigiria da API.
Anexos agora em multipart/form-data — o arquivo vai como parte binária, sem base64 (e sem o inchaço de ~33% no corpo); a pergunta 5 ficou registrada como respondida nesse ponto.
O anexoId passa a NASCER NO APARELHO: o servidor não o devolve, só o aceita — e reenvio do mesmo anexoId é substituição, nunca duplicata. É o que permite à baixa citar uma foto que ainda está subindo.
Campo novo capturadoEm em todo anexo (o relógio do aparelho no clique), e a baixa passa a citar as provas de forma estruturada: fotos [{seq, anexoId}] e assinatura {anexoId}, no lugar da lista plana.
A resposta da baixa ganhou o campo situacao — registrada, duplicada ou ignorada — sempre com HTTP 200: 409 ou 422 fariam a fila do aparelho reenviar a mesma baixa para sempre.
Seção nova #voz — ditado por voz, escopo EM DECISÃO COMERCIAL (nada disso está no app): o áudio sobe pelo mesmo endpoint de anexos com tipo "audio" (campo, transcricao, duracaoSeg, ~25–180 KB), a baixa ganha a origem de cada campo ditado (teclado | voz | voz_corrigida) e as três perguntas ao TMS estão lá — inclusive a que importa: sem player na tela do TMS, o recurso não se paga.
A lista da adequação foi corrigida no mesmo formato (o box do endpoint de anexos e a linha da baixa), para ninguém abrir a tarefa com o contrato de ontem.
Painel2.0.8
A documentação agora abre por "Só o que muda" — a lista para a tarefa de adequação
Pedido da equipe do TMS por e-mail: a especificação completa não ajudava a abrir a tarefa; eles queriam só a diferença entre o Swagger atual e o contrato novo. A Parte 3 agora começa por essa lista, campo a campo.
Seção nova #adequacao, primeira coisa da Parte 3: só o que não existe hoje, com o bloco onde entra e a finalidade — nada da estrutura que já existe é redocumentado.
As duas dúvidas do e-mail respondidas em destaque: latitude/longitude JÁ EXISTEM no GetDocumentos com esses mesmos nomes e vêm vazias (0 de 427 medido em 10/08) — a adequação é preencher, não criar; e o envio em lote de posições é capacidade nova do endpoint (hoje é uma posição por chamada), com um único campo novo por ponto (precisaoM).
Quatro blocos: campos a criar/preencher no retorno do login (parametros, rastrear, numero estável, estado do serviço, tipo/coleta, nome do motorista, janela), comportamentos que mudam (romaneio rebuscável, 200 vazio, baixa duplicada recusada, erro em 4xx), campos novos que a baixa passa a mandar (idempotencia, anexoIds, precisaoM, coleta) e o único endpoint inteiramente novo (POST /mobile/anexos).
Cada linha aponta para a seção do contrato completo; a lista declara servir também para o caminho de adaptar a API atual em vez de subir as rotas /mobile/*.
A âncora #documentacao (porta 2 e menu "Nova API") agora cai direto nessa lista; os "três fatos" continuam logo depois.
Pedido seguinte da equipe, no mesmo dia: a comparação explícita dos dois caminhos — "Adequação" (o Swagger de hoje absorve a lista; quase tudo é adição compatível, mas romaneio rebuscável e erro em 4xx mexem no que o app da Play pressupõe) contra "Mundo ideal" (rotas /mobile/* ao lado das atuais; o Swagger atual fica intocado e as regras nascem no lugar certo) — item por item, com o porquê de cada lado.
App6.0.9
App 6.0.9 — freio nas consultas repetidas, e a 6.0.8 aprovada em campo
Uma versão de economia: o aplicativo não pergunta mais a mesma coisa ao servidor várias vezes em segundos. E o dia de campo da 6.0.8 confirmou as duas correções principais dela.
A lista pedia novidades ao servidor a cada volta à tela, sem freio nenhum: nos registros da 6.0.8 apareceram cinco consultas em 16 segundos, todas voltando vazias. Agora nenhuma checagem repete antes de 15 segundos.
O ritmo normal não muda: a checagem de rotina continua a cada 60 segundos, e abrir um romaneio recém-chegado consulta na hora — o freio vale só para a repetição inútil.
O freio conta a partir da última tentativa, não do último sucesso: sem sinal, insistir a cada volta de tela é rede e bateria queimadas dentro do caminhão.
O dia de campo da 6.0.8 (11/08, quatro aparelhos): 15 baixas subiram, cada uma com a sua chave única — nenhuma duplicada; 47 fotos e assinaturas entregues. As únicas falhas do dia foram sinal fraco dentro do caminhão (o aplicativo reenviou depois, nada se perdeu) e a recusa já conhecida do servidor atual quando não há serviço inédito.
A suíte fechou 326 de 326.
App6.0.8
App 6.0.8 — nenhuma entrega é baixada duas vezes, e a ordem de entrega do TMS passou a valer
Os registros do dia mostraram um conhecimento baixado duas vezes no TMS, com quinze minutos de diferença. A causa está corrigida — e, no meio da investigação, apareceu um campo que o aplicativo lia com o nome errado desde sempre.
O servidor atual não entrega o romaneio do dia de uma vez: ele entrega picotado, um lote por vez, conforme a central vai liberando. Em 10/08, na mesma placa, vieram lotes de 427, 7, 123, 12, 285, 159, 10 e 120 serviços ao longo do dia.
Cada lote chega com um "número de romaneio" diferente — que na verdade é só o documento da primeira linha do lote. O aplicativo tratava número diferente como romaneio novo e limpava a lista, inclusive o que já tinha sido entregue. O serviço voltava para a tela como pendente, e quem entregou de novo baixou de novo.
Aconteceu de verdade: um CT-e foi baixado às 13:49 e outra vez às 14:29, e o servidor aceitou as duas — as duas viraram baixa no TMS.
Agora a lista é somada, nunca substituída: lote novo entra por cima do que já estava, e o que já foi entregue continua marcado como entregue. Entrar de novo no meio do dia reabre o romaneio guardado antes de somar o lote que acabou de chegar.
A lista só é apagada quando troca o motorista — pelo CPF, não pelo número do romaneio. E a cópia guardada no aparelho passou a valer por 12 horas, para o romaneio de ontem não se somar ao de hoje.
Pedido ao TMS, já escrito no caderno de ajustes: recusar a segunda baixa do mesmo documento. Enquanto o servidor aceitar as duas, é o aplicativo que segura sozinho o que deveria ser regra do lado de lá.
A ordem de entrega roteirizada passou a ser respeitada. O servidor manda o campo todo em minúsculas ("ordementrega") e o aplicativo procurava por outro nome — resultado: a ordem planejada pela central era ignorada e os serviços apareciam na ordem em que vieram no lote. O mesmo valia para a chave da nota ("chavenfe").
A suíte fechou 320 de 320.
Painel2.0.7
A página aberta /v6 virou três portas: o que foi feito, atualizações e a API
A página do cliente abre limpa — título, três cartões e os números — e cada assunto só aparece quando é clicado. O PDF continua saindo com o documento inteiro.
A capa ganhou três portas: "O que já foi feito" (o aplicativo pronto, a camada que o faz valer no servidor de hoje, o acesso de demonstração 0000 e o andamento do contrato item a item), "Atualizações" (este diário) e "A API para o backend" (a especificação completa).
Clicar numa porta — ou em qualquer link com # — abre só aquela parte e desce até o ponto certo. Um assunto por vez: quem veio ler a API não tromba no diário, e vice-versa.
Link compartilhado continua funcionando: um endereço com #baixa, por exemplo, abre a página já na parte da documentação, descida no endpoint de baixa.
O PDF ignora as portas e sai sempre com o documento inteiro, com o andamento do momento em que foi gerado. Sem JavaScript, a página também mostra tudo aberto.
O topo agora carrega o ícone do aplicativo e a versão que está valendo, e virou menu: O que foi feito | Nova API | Atualizações. Em telas de celular ele vira uma segunda linha rolável — a página inteira foi revisada para uso no celular.
Botão de voltar ao início aparece depois de rolar; âncoras # em todas as seções continuam.
O botão de baixar a versão de teste aparece já na capa: clicou, baixa o APK direto do Expo — sem precisar abrir porta nenhuma. O link e o número são os mesmos da caixa da Parte 1, lidos do Expo.
App6.0.7
App 6.0.7 — a lista mostra o romaneio inteiro e o login volta preenchido
Correções do caderno de ajustes do cliente, todas validadas em campo no romaneio de 427 serviços de 10/08: a lista não esconde mais nada, e nenhum serviço some da tela.
A lista mostra o romaneio inteiro — mostrava 7 de 285. Era um corte de tela herdado do desenho antigo; agora a rolagem é uma só, do primeiro ao último serviço.
A faixa de "novos" diz o que chegou de verdade: entregas, coletas ou serviços, conforme o lote — e zera no login, em vez de acumular.
O login volta pedindo a transportadora e já traz CPF e placa preenchidos do último acesso.
A lista do servidor atual virou aditiva: serviço que entrou não some mais da tela, mesmo quando o servidor para de listá-lo. A contrapartida está registrada: enquanto for assim, cancelamento feito pela central não é detectável pelo aparelho — mais um motivo para a API nova.
Enquanto o servidor não mandar coordenada (no romaneio de 10/08 vieram vazias em 100% dos 427 serviços), a distância no cartão passa a ser calculada pelo endereço, com cache no aparelho.
O limite de fichas guardadas no aparelho subiu de 400 para 4000 — com 427 serviços no dia, o limite antigo fazia a baixa morrer em "documento original não encontrado".
A suíte fechou 312 de 312.
Painel2.0.6
O romaneio entregue uma vez só entrou no checklist e na página da entrega
O maior achado de campo até agora não é do aplicativo: é do servidor. Virou item escrito, com os números medidos nos dois aplicativos, para o contrato novo não repetir a armadilha.
Item novo no Modo 1: "Sessão tem que poder ser chamada de novo — hoje o romaneio é entregue UMA vez só", logo depois do item de sessão, com o registro das chamadas dos dois lados.
A prova está no item: uma placa recebeu 427 serviços às 14:17 e ouviu a mesma recusa onze vezes às 14:19, sem nenhuma baixa no meio. E o aplicativo que está na loja hoje mostra o mesmo em 170 placas.
A tabela de diferenças da página da entrega ganhou duas linhas: buscar o romaneio de novo, e o documento que some da lista assim que é entregue.
Os passos do Modo 1 ganharam o caso contado em português de gente, com o que a versão 6.0.6 faz e o que ela não consegue cobrir — troca ou perda de aparelho.
O que se pede está escrito em três regras: abrir a sessão de novo devolve o mesmo romaneio, serviço baixado continua na lista, e sem romaneio é lista vazia, não erro.
A mesma regra entrou no Modo 2, no item da sessão: quem for escrever a API do zero já lê que a chamada é idempotente dentro do dia — assim o contrato novo não herda a armadilha.
App6.0.6
App 6.0.6 — sair e entrar de novo não zera mais o romaneio do dia
Um motorista recebeu o romaneio, saiu do aplicativo, entrou de novo e a lista veio vazia — sem ter dado nenhuma baixa. A causa não é do aplicativo: o servidor atual entrega o romaneio uma vez só. A 6.0.6 passa a guardar o romaneio no próprio aparelho.
O servidor atual entrega o romaneio na primeira busca do dia. Da segunda em diante ele responde "não existem entregas disponíveis para o motorista, veículo e transportadora informados" — e segue respondendo isso enquanto não houver serviço inédito para aquela placa, mesmo com o romaneio inteiro pendente.
Confirmado nos registros: no aplicativo novo, uma placa recebeu 427 serviços às 14:17 e ouviu a recusa onze vezes seguidas às 14:19, sem nenhuma baixa no meio. E no aplicativo que está na loja hoje, o mesmo padrão em 170 placas: uma resposta boa, e daí em diante só recusa.
O aplicativo 5.x nunca reclamou porque ele nunca rebusca a lista — guarda no aparelho e pronto. O v6 apagava tudo ao sair, então reentrar deixava a tela vazia o dia inteiro.
Agora, ao sair, o romaneio inteiro fica guardado no aparelho. Se o login for recusado por esse motivo, o aplicativo devolve a lista que já estava lá e avisa na tela que aquele romaneio é o do aparelho, não um recém-baixado.
A conferência é por transportadora, CPF e placa: um motorista nunca recebe o romaneio guardado por outro, nem o mesmo motorista em outro caminhão.
Quem sai e entra no mesmo romaneio não reentrega nada: o que já estava entregue continua marcado como entregue.
Corrigido junto: como o servidor tira o documento da lista assim que ele é entregue, o que o motorista acabou de baixar aparecia como "removido pela central" e sumia da tela na sincronização seguinte.
Pedido formal ao TMS, já registrado no painel: a busca do romaneio precisa poder ser repetida. O que a 6.0.6 faz é remendo — motorista que troca de aparelho ou desinstala o aplicativo continua sem conseguir recuperar o romaneio do dia, porque essa informação só existe do lado do servidor.
Dezesseis testes novos. A suíte fechou 296 de 296.
App6.0.5
App 6.0.5 — baixa que espera na fila não perde mais o documento dela
Achado nos registros poucos minutos depois de a 6.0.4 entrar em campo, e é a cauda do problema de ontem: parte das baixas que ficaram presas não conseguia subir porque o aplicativo já tinha esquecido a entrega a que elas se referiam.
O servidor atual para de listar a entrega assim que ela é dada como entregue. O aplicativo relia essa lista a cada minuto e regravava só o que veio — apagando justamente a ficha de que uma baixa parada na fila precisa para ser enviada.
Quando isso acontecia, a baixa presa não subia nunca mais: nem entrar de novo resolvia, porque o servidor também não devolve mais aquela entrega. Aparecia como "documento original não encontrado no aparelho".
Agora o aparelho guarda as fichas em vez de trocá-las: as 400 entregas mais recentes ficam disponíveis, e uma baixa de dias atrás continua encontrando a sua.
Quem atualizar da 6.0.4 para a 6.0.5 com fila pendente não perde nada — o aplicativo lê o formato antigo do arquivo também.
O envio de posição passou a usar a entrega mais recente para se identificar, em vez de uma qualquer da lista. Depois de trocar de romaneio, é a que tem a filial certa.
Cinco testes novos, incluindo o caso exato visto em campo. A suíte fechou 280 de 280.
Painel2.0.5
O que o primeiro dia de campo ensinou entrou no checklist do backend
O que derrubou as baixas de ontem virou item escrito, com o payload real dos dois lados — para que o contrato novo não repita a mesma armadilha.
Item novo no Modo 1: "Data e hora — confirmar que os endpoints novos aceitam ISO-8601 com fuso", com o erro exato que o servidor devolveu e as duas saídas possíveis.
A lição de "duas causas de julho" virou três: a data entrou como a mais cara delas, porque recusou baixa e rastreamento ao mesmo tempo, em silêncio.
O item do envelope de resposta ganhou o gêmeo do falso sucesso: o falso erro — código de erro carregando a resposta completa quando o romaneio simplesmente acabou.
A página da entrega passou a dizer o mesmo, em português de gente, na tabela de diferenças e nos passos do Modo 1.
O item da data ganhou a conta do dia tirada do registro de chamadas: 82 recusas em 86 chamadas, com o motivo de cada uma. É o que transforma "achamos que era a data" em prova.
App6.0.4
App 6.0.4 — o servidor atual voltou a aceitar baixa, posição e login
Primeiro dia de uso real da v6 no servidor de produção: toda baixa e toda posição eram recusadas, e depois do romaneio terminado nem o login abria. Três causas, todas do lado do app, todas corrigidas — nenhuma baixa foi perdida: elas ficaram na fila e sobem sozinhas.
A data ia com o fuso escrito ("14:32:10-03:00") e o servidor atual recusa esse formato — ele converte a data recebida para UTC e estoura antes de olhar o resto do conteúdo. Agora vai em UTC ("17:32:10Z"), que é exatamente o que o app 5.x manda hoje em produção. É o mesmo instante, escrito do jeito que este servidor lê.
Era a mesma causa do rastreamento mudo: nenhuma posição entrava desde a primeira build da v6. As posições ficaram guardadas no aparelho — a última tentativa levava 316 delas de uma vez — e sobem assim que o app abre atualizado.
Terminado o romaneio, o servidor responde "não existe entregas" com código de erro de rede, e o app tratava isso como servidor fora do ar: o login não abria e a checagem de alterações piscava erro de minuto em minuto. Agora o app lê a resposta e mostra a frase em português — sem o erro de digitação e sem o "Cod. 2362" do servidor.
O nome do motorista aparecia em branco, com um círculo cego ao lado, porque o servidor atual não devolve esse campo. No lugar dele o app mostra a placa, que é a identidade que este servidor conhece; o CPF continua no perfil. Quando o campo vier, o nome aparece sozinho.
Nada aqui foi adivinhado: as três causas saíram do registro de chamadas do próprio dia. Das 86 conversas que o app teve com o servidor, 82 voltaram recusadas — e a foto foi o único envio que passou, justamente por ser o único que não leva data.
O registro de chamadas passou a gravar a data da primeira e da última posição de cada lote — foi o que faltou para enxergar o problema no dia em que ele aconteceu, em vez de no dia seguinte.
Quatro testes novos e dois corrigidos travam o formato da data e a queda para a placa. A suíte fechou 275 de 275.
Painel2.0.4
A versão para baixar passa a vir do Expo sozinha
O painel agora pergunta ao Expo qual é a última build publicada. Sai uma versão nova, o link desta página troca em minutos, sem ninguém rodar nada.
O número da versão e o link do APK são lidos direto do Expo, no máximo uma consulta a cada 10 minutos.
O link nunca anda para trás: build antiga reconstruída não substitui a mais nova.
Se o Expo estiver fora do ar, a página responde na mesma hora com o que já estava registrado.
App6.0.3
App 6.0.3 — fim do beco da localização desligada
Com o GPS do aparelho desligado, o motorista via um cartão dizendo "Liberada" e o toque não fazia nada. Caminhão invisível na central, e ninguém sabia por quê.
Permissão concedida e GPS do aparelho desligado são coisas diferentes: o app passou a olhar as duas. Antes só olhava a permissão, e por isso dizia "Liberada" com o GPS desligado.
Nesse estado o cartão agora oferece "Ligar localização": no Android abre o diálogo do próprio sistema, sem sair do app; no iPhone leva aos Ajustes, que é o único caminho que a Apple dá.
Entrar na lista continua exigindo só a permissão — ninguém fica preso na tela de permissões por causa do GPS desligado.
A falha existia desde a primeira build da v6: estava na 6.0.1 e na 6.0.2. Foi encontrada na revisão da entrega, não em campo.
Cinco testes novos cobrem os quatro estados do cartão. A suíte fechou 264 de 264.
App6.0.2
App 6.0.2 — permissão do iPhone destravada e sem inglês
Havia um caminho no iOS que prendia o motorista na tela de permissões sem saída nenhuma. Fechado, com teste.
Quem concedia "Ao Usar" e recusava "Sempre" ficava travado: o botão de entrar não liberava e tocar de novo não abria diálogo nenhum. Agora esse estado leva aos Ajustes do aparelho.
O botão passa a dizer "Abrir ajustes" quando pedir de novo não resolve mais — rótulo que não abre nada parece app quebrado.
Avisos de localização do iOS em português. O texto em inglês que apareceu no TestFlight não era do app: é o padrão de fábrica do motor de rastreamento, que nunca tinha sido traduzido na v6.
Pedido de microfone removido do iPhone: o app só tira foto e lê código de barras, nunca grava áudio.
Ajuste de compilação do iOS que faltava para a build passar — sem efeito na tela.
Painel2.0.3
Passos do backend conferidos número por número contra o código do app
Onze passadas de revisão em cima do que já estava publicado, comparando cada afirmação com o código que roda no aparelho. Dezoito correções.
Fotos: o app manda no máximo 10 por baixa, cada uma em torno de 360 KB — os dois números estavam errados ou ausentes.
Retentativa: a curva real (30 s, 1 min, 2 min, 4 min, 8 min) está escrita, e com ela o que um 4xx causa de verdade — item preso na fila do motorista.
Coordenada da baixa é opcional: sem GPS a baixa sai mesmo assim, e coluna obrigatória no banco prende entrega feita em subsolo.
Os dois intervalos da sessão não são relógio: um é teto de taxa (a posição vem por movimento) e o outro o app grampeia entre 120 e 300 segundos, em silêncio.
O que 401 faz hoje: o aparelho fica mudo — a fila não se perde, mas nada volta a subir até alguém sair e entrar na mão. É o que pesa na decisão de expirar token.
Ritmo real das consultas de alteração: a cada volta à lista e a cada 60 s com ela aberta, não uma por entrega concluída.
Painel2.0.2
Passos do backend reescritos endpoint por endpoint, para quem vai programar
Os dois modos deixaram de ser lista de decisões e viraram especificação: cada rota com a requisição exata, a resposta esperada campo a campo e a comparação com o backend de hoje.
Modo 1 passou de 5 para 10 itens: um por endpoint, mais idempotência, envelope de resposta e autenticação.
Cada endpoint abre na mesma ordem: antes (como é hoje) → o que o app manda → o que precisa voltar → as regras que quebram em campo → pronto quando.
Modo 2 ganhou o contrato inteiro de cada item — cabeçalhos, códigos de status, casos de borda e o teste que fecha.
Etiqueta com o endereço da rota no cartão fechado: dá para achar o endpoint sem abrir item por item.
Todo payload de exemplo saiu do código do aplicativo, não de memória — o que está escrito é o que vai no fio.
Painel2.0.1
Atualizações, download do app e ícone novo
O painel passou a mostrar de onde baixar a última versão do aplicativo e a guardar um diário do que sobe.
Aba Atualizações: tudo que sobe fica anotado, da mais nova para a mais antiga.
Link de download da última build do Android, com versão e data — o número vem do Expo, não é escrito à mão.
A página aberta da entrega (/v6) mostra o mesmo download e o mesmo diário, sem senha.
Ícone novo do aplicativo no lugar da logo em telas estreitas e na aba do navegador.
Painel2.0.0
Painel novo: Auditoria e Implementação no mesmo lugar
O antigo visualizador de logs virou o painel da entrega. Entra por senha (sem usuário) e escolhe a área.
Área Auditoria: logs de campo, erros conhecidos, jornada de um documento, entregas presas e Crashlytics.
Área Implementação: Backend, Frontend, Changelog e Manutenções — quatro abas.
Cada passo do backend abre e mostra o que o app manda, o que precisa voltar e quando está pronto.
Qualquer visão vira PDF pelo botão "Baixar PDF" — o papel sai igual ao que está no ar.
Página aberta da entrega em /v6, sem senha, lendo este mesmo checklist ao vivo.
App6.0.1
App 6.0.1 — telemetria de API e captura de erro
Mesma v6, agora contando o que acontece em campo. É o que alimenta a área de Auditoria.
Toda chamada de API vira registro no Firebase: ação, status HTTP, tempo, documento e aparelho.
Erro não tratado é capturado e enviado, em vez de morrer na tela do motorista.
Versão do app no rodapé do menu do perfil — dá para conferir o que está instalado sem abrir a loja.
App6.0.0
App 6.0.0 — a v6 reconstruída, primeira build instalável
Não é a versão anterior com ajustes: é aplicativo novo, em Expo SDK 57, com o app inteiro funcionando sem servidor no modo demonstração.
Login, lista, bipagem, baixa com foto e assinatura, ocorrência, fila offline e perfil.
Rastreamento em background com motor nativo (Transistorsoft) — não é mais o GPS do Expo.
Fila de envio offline: a baixa feita sem sinal fica guardada e sobe sozinha quando a rede volta.
Modo demonstração: digite 0000 na transportadora e o app roda inteiro sem backend.
