Central de dadosData centerCentro de datos

Pendências / roadmapPending items / roadmapPendientes / roadmap

• Só visitas têm fila offline; todo o resto vira erro definitivo. O dispatch() só enfileira quando o tipo é visit; qualquer outra transação feita offline atravessa até o gateway, é recusada pela guarda de offline e é gravada como error. E o flush() lê apenas as visitas pendentes, então essas linhas nunca são reenviadas sozinhas — dependem de alguém abrir esta tela e tocar em Reenviar. É a razão de existir do botão manual, e o maior candidato a evolução do subsistema. Only visits have an offline queue; everything else becomes a permanent error. dispatch() only enqueues when the type is visit; any other transaction made offline travels down to the gateway, is refused by the offline guard and is stored as error. And flush() reads only the pending visits, so those rows are never retried on their own — they depend on someone opening this screen and tapping Resend. It's the reason the manual button exists, and the subsystem's biggest candidate for evolution. Solo las visitas tienen cola offline; todo lo demás se vuelve error definitivo. El dispatch() solo encola cuando el tipo es visit; cualquier otra transacción hecha offline atraviesa hasta el gateway, es rechazada por la guarda de offline y se graba como error. Y el flush() lee solo las visitas pendientes, así que esas filas nunca se reenvían solas — dependen de que alguien abra esta pantalla y toque Reenviar. Es la razón de ser del botón manual, y el mayor candidato a evolución del subsistema.
• Os dois contadores de "não sincronizado" contam coisas diferentes — e o que bloqueia é o mais cego. O encerramento da visita conta tudo o que não é sucesso (inclui os erros); o encerramento da jornada conta só o que está pendente. Como só visitas chegam a pendente, o contador da jornada não vê nenhum erro de despacho — e é justamente ele que, no Chile, impede o rep de fechar o dia. Resultado: a tela que enxerga os erros não bloqueia, e a que bloqueia não enxerga os erros. The two "unsynced" counters count different things — and the blocking one is the blinder. The visit wrap-up counts everything that isn't a success (errors included); the journey wrap-up counts only what is pending. Since only visits ever become pending, the journey counter sees no dispatch error at all — and it is exactly the one that, in Chile, stops the rep from closing the day. Net result: the screen that sees the errors doesn't block, and the one that blocks doesn't see the errors. Los dos contadores de "no sincronizado" cuentan cosas distintas — y el que bloquea es el más ciego. El cierre de la visita cuenta todo lo que no es éxito (incluye los errores); el cierre de la jornada cuenta solo lo pendiente. Como solo las visitas llegan a pendiente, el contador de la jornada no ve ningún error de despacho — y es justamente el que, en Chile, impide al rep cerrar el día. Resultado: la pantalla que ve los errores no bloquea, y la que bloquea no ve los errores.
• Uma falha de rede no reenvio apaga a chave de idempotência. Quando o backend recusa, o identificador da transação dele é guardado e o próximo reenvio o repete — replay idempotente. Mas o ramo de falha de transporte reescreve a linha sem preservar esse identificador, que volta a zero. Sequência real: envia → backend recusa com um id → reenvia → dá timeout → o id se perde → todos os reenvios seguintes vão com zero e o servidor os trata como transações novas. A network failure during a resend erases the idempotency key. When the backend rejects, its transaction id is stored and the next resend repeats it — idempotent replay. But the transport-failure branch rewrites the row without preserving that id, which goes back to zero. Real sequence: send → backend rejects with an id → resend → it times out → the id is lost → every later resend goes with zero and the server treats them as new transactions. Un fallo de red en el reenvío borra la clave de idempotencia. Cuando el backend rechaza, su identificador de transacción se guarda y el próximo reenvío lo repite — replay idempotente. Pero la rama de fallo de transporte reescribe la fila sin preservar ese identificador, que vuelve a cero. Secuencia real: envía → el backend rechaza con un id → reenvía → da timeout → el id se pierde → todos los reenvíos siguientes van con cero y el servidor los trata como transacciones nuevas.
• Todo erro de servidor é reportado como erro de rede. O repository de transporte captura Object e converte tudo em falha de rede, apagando a classificação que o tratador de gRPC já tinha feito (400, 401, 404, 409, 500…). Duas consequências concretas: o flush() interrompe a fila inteira ao ver uma recusa de servidor numa visita, como se o aparelho estivesse offline; e o fluxo de visita relata "enfileirado para depois" numa rejeição real do backend — quando nada foi enfileirado. Every server error is reported as a network error. The transport repository catches Object and turns everything into a network failure, erasing the classification the gRPC handler had already made (400, 401, 404, 409, 500…). Two concrete consequences: flush() breaks the whole queue on seeing a server rejection on one visit, as if the device were offline; and the visit flow reports "queued for later" on a genuine backend rejection — when nothing was queued. Todo error de servidor se reporta como error de red. El repository de transporte captura Object y convierte todo en fallo de red, borrando la clasificación que el manejador de gRPC ya había hecho (400, 401, 404, 409, 500…). Dos consecuencias concretas: el flush() interrumpe la cola entera al ver un rechazo de servidor en una visita, como si el dispositivo estuviera offline; y el flujo de visita reporta "encolado para después" en un rechazo real del backend — cuando nada se encoló.
• Três tipos de transação aparecem sem nome traduzido. O título do cartão é montado como dispatcher_type_<nome> e o resolvedor de traduções devolve a chave crua quando não a encontra. Faltam exatamente três chaves, nos seis mercados: smartInvestmentAnswer, imageRecognitionAudit e notes — e os três têm builder, logo são despacháveis de verdade. Um despacho de qualquer um deles mostra literalmente dispatcher_type_notes como título do cartão, no dropdown de filtro e no detalhe. No caminho inverso sobra uma chave órfã, dispatcher_type_merchandisingAudit, sem valor correspondente no enum. Three transaction types show up with no translated name. The card title is composed as dispatcher_type_<name> and the translation resolver returns the raw key when it can't find it. Exactly three keys are missing, in all six markets: smartInvestmentAnswer, imageRecognitionAudit and notes — and all three have a builder, so they really are dispatchable. A dispatch of any of them shows literally dispatcher_type_notes as the card title, in the filter dropdown and in the detail. In the opposite direction there's a leftover orphan key, dispatcher_type_merchandisingAudit, with no matching enum value. Tres tipos de transacción aparecen sin nombre traducido. El título de la tarjeta se compone como dispatcher_type_<nombre> y el resolvedor de traducciones devuelve la clave cruda cuando no la encuentra. Faltan exactamente tres claves, en los seis mercados: smartInvestmentAnswer, imageRecognitionAudit y notes — y los tres tienen builder, así que son despachables de verdad. Un despacho de cualquiera de ellos muestra literalmente dispatcher_type_notes como título de la tarjeta, en el dropdown de filtro y en el detalle. En el camino inverso sobra una clave huérfana, dispatcher_type_merchandisingAudit, sin valor correspondiente en el enum.
• Uma falha "leve" de sincronia deixa o cartão vermelho e sem explicação. Quando a estrutura devolve falha sem lançar exceção — o caminho mais comum — o registro é gravado com mensagem de erro vazia; só o caminho de exceção carrega texto. E a linha de detalhe do erro só aparece se a mensagem não estiver vazia. O resultado é um status "Erro" sem código, sem descrição e sem nada para buscar. O identificador de rastreio da falha existe no repository e não é levado para o registro. A "soft" sync failure leaves the card red and unexplained. When the structure returns a failure without throwing — the commonest path — the record is written with an empty error message; only the exception path carries text. And the error detail row only shows when the message is non-empty. The result is an "Error" status with no code, no description and nothing to search for. The failure's trace identifier exists in the repository and is not carried into the record. Un fallo "blando" de sincronización deja la tarjeta roja y sin explicación. Cuando la estructura devuelve fallo sin lanzar excepción — el camino más común — el registro se graba con mensaje de error vacío; solo el camino de excepción lleva texto. Y la fila de detalle del error solo aparece si el mensaje no está vacío. El resultado es un estado "Error" sin código, sin descripción y sin nada que buscar. El identificador de rastreo del fallo existe en el repository y no se lleva al registro.
• Um registro com erro exibe o horário do último acerto. A gravação do resultado lê o lastSyncAt do cache da feature depois da tentativa, inclusive quando ela falhou — e o cache continua com o valor da última sincronização bem-sucedida. O cartão então diz "Erro" ao lado de uma hora que não é a da falha. Não existe distinção entre "última tentativa" e "último sucesso" na estrutura. An errored record displays the timestamp of the last success. Writing the outcome reads the feature cache's lastSyncAt after the attempt, including when it failed — and the cache still holds the value of the last successful sync. The card then reads "Error" next to a time that isn't the failure's. There is no distinction between "last attempt" and "last success" in the structure. Un registro con error muestra la hora del último acierto. La grabación del resultado lee el lastSyncAt del caché de la feature después del intento, incluso cuando falló — y el caché sigue con el valor de la última sincronización exitosa. La tarjeta entonces dice "Error" al lado de una hora que no es la del fallo. No existe distinción entre "último intento" y "último éxito" en la estructura.
• A varredura sincroniza estruturas que o mercado não tem, e grava registros que ninguém vê. O campo enabledMarkets do DataSyncType tem um único consumidor em todo o app: a montagem das linhas desta aba. O registro de alvos e os lotes da carga inicial não o consultam, então em ZA a varredura busca sete estruturas exclusivas de outros mercados a cada volta, e grava um registro para cada — registros que a aba filtra fora e que nada no app pode apagar. The sweep syncs structures the market doesn't have, and writes records nobody sees. DataSyncType's enabledMarkets field has a single consumer in the whole app: building this tab's rows. The target registry and the initial-load batches don't consult it, so in ZA the sweep fetches seven structures exclusive to other markets on every round, and writes a record for each — records the tab filters out and that nothing in the app can delete. El barrido sincroniza estructuras que el mercado no tiene, y graba registros que nadie ve. El campo enabledMarkets del DataSyncType tiene un único consumidor en toda la app: el armado de las filas de esta pestaña. El registro de objetivos y los lotes de la carga inicial no lo consultan, así que en ZA el barrido busca siete estructuras exclusivas de otros mercados en cada vuelta, y graba un registro para cada una — registros que la pestaña filtra fuera y que nada en la app puede borrar.
• O mercado é gravado no registro de sincronia e nunca lido. A busca do upsert casa só pelo tipo, então trocar de mercado sobrescreve a linha do anterior em vez de conviver com ela — e, até ser sobrescrita, uma linha de outro mercado é exibida como se fosse do atual. O campo é peso morto, e o seu valor pode ainda ser silenciosamente trocado por BR pelo fallback de leitura. The market is written on the sync record and never read. The upsert's lookup matches by type only, so switching market overwrites the previous one's row instead of coexisting with it — and, until it is overwritten, another market's row is displayed as if it were the current one's. The field is dead weight, and its value can still be silently swapped for BR by the read fallback. El mercado se graba en el registro de sincronización y nunca se lee. La búsqueda del upsert casa solo por el tipo, así que cambiar de mercado sobrescribe la fila del anterior en vez de convivir con ella — y, hasta ser sobrescrita, una fila de otro mercado se muestra como si fuera de la actual. El campo es peso muerto, y su valor puede aún ser silenciosamente cambiado por BR por el fallback de lectura.
• Nenhum dos três diários é podado. O de envios tem remoção nas quatro camadas e nenhum chamador; o de pagamentos tem nas três camadas de dados, sem UseCase e sem chamador; o de sincronia não tem remoção em camada alguma. Em nenhum dos três há retenção, limite ou expurgo. O de envios é o mais custoso: cresce sem limite, e toda leitura descomprime o conteúdo de todas as linhas — inclusive no recálculo de contagens, que roda depois de cada despacho. Os índices declarados em status e data não são usados, porque nenhuma leitura usa a API de consulta. O de pagamentos guarda as evidências em base64 para sempre. E uma única linha corrompida faz a leitura inteira falhar, esvaziando a aba. None of the three journals is pruned. The sent journal has removal in all four layers and no caller; the payments one has it in the three data layers, with no UseCase and no caller; the sync one has no removal in any layer. None of the three has retention, a cap or a purge. The sent one is the costliest: it grows without bound, and every read decompresses every row's content — including the counter recalculation, which runs after each dispatch. The indexes declared on status and date go unused, because no read uses the query API. The payments one keeps its evidence in base64 forever. And a single corrupt row makes the whole read fail, emptying the tab. Ninguno de los tres registros se poda. Los tres tienen método de eliminación declarado en las cuatro capas y ningún llamador; no hay retención, límite ni purga. El de envíos es el más costoso: crece sin límite, y toda lectura descomprime el contenido de todas las filas — incluido el recálculo de conteos, que corre después de cada despacho. Los índices declarados en estado y fecha no se usan, porque ninguna lectura usa la API de consulta. El de pagos guarda las evidencias en base64 para siempre. Y una única fila corrupta hace fallar la lectura entera, vaciando la pestaña.
• Renomear um valor de enum corrompe o histórico em silêncio. O tipo é persistido pelo nome Dart, e a leitura de volta cai em visit (envios) ou resource (recebimentos) quando não reconhece — sem log. Um rename de refatoração transformaria linhas antigas em "Visita" ou numa segunda linha de "Recurso" com dados alheios. Renaming an enum value silently corrupts history. The type is persisted by its Dart name, and reading back falls to visit (sent) or resource (received) when unrecognised — with no log. A refactoring rename would turn old rows into "Visit" or into a second "Resource" row holding someone else's data. Renombrar un valor de enum corrompe el historial en silencio. El tipo se persiste por el nombre Dart, y la lectura de vuelta cae en visit (envíos) o resource (recepción) cuando no reconoce — sin log. Un rename de refactorización convertiría filas antiguas en "Visita" o en una segunda fila de "Recurso" con datos ajenos.
• O botão "Sincronizar todos" pode avisar sucesso sem ter sincronizado nada. A rotina de sincronia completa retorna em silêncio se já houver uma sincronia rodando ou a inicial pendente, sem tocar o status — e o status nasce como "concluído". Quem chamou lê esse valor e mostra o aviso verde "Dados atualizados". O caso realista é tocar no botão logo depois do login, enquanto a carga inicial ainda corre. Há um segundo caminho, pior: o status olha só o lote de configuração — se ele passa e todas as 26 estruturas falham, o aviso verde aparece igual. The "Sync all" button can report success without having synced anything. The full-sync routine returns silently if a sync is already running or the initial one is pending, without touching the status — and the status starts out as "completed". The caller reads that value and shows the green "Data updated" notice. The realistic case is tapping the button right after login, while the initial load is still running. There is a second, worse path: the status looks only at the configuration batch — if it passes and all 26 structures fail, the green notice shows up just the same. El botón "Sincronizar todos" puede avisar éxito sin haber sincronizado nada. La rutina de sincronización completa retorna en silencio si ya hay una sincronización corriendo o la inicial pendiente, sin tocar el estado — y el estado nace como "completado". Quien llamó lee ese valor y muestra el aviso verde "Datos actualizados". El caso realista es tocar el botón justo después del login, mientras la carga inicial aún corre. Hay un segundo camino, peor: el estado mira solo el lote de configuración — si pasa y todas las 26 estructuras fallan, el aviso verde aparece igual.
• O cartão de pagamento repete o status no lugar do título, e não é clicável. O título da linha é a própria etiqueta de status, então cada cartão mostra o mesmo texto duas vezes e nunca o varejo, o valor ou o meio de pagamento — que existem no registro. Como o toque não navega para nenhum detalhe, não há superfície alguma na Central de dados para inspecionar esses campos (eles aparecem no detalhe do título em Gestão financeira). Efeitos colaterais: ordenar "por tipo" nessa aba ordena por status, e a busca — apesar de o cartão carregar a conta — não procura por nome nem por SAP, porque esse trecho é restrito à aba de Envios. The payment card repeats the status in place of the title, and isn't tappable. The row's title is the status label itself, so each card shows the same text twice and never the retail, the amount or the payment method — all of which exist on the register. Since tapping navigates to no detail, there is no surface at all in the Data center to inspect those fields (they show up on the item detail in Financial management). Side effects: sorting "by type" on that tab sorts by status, and the search — even though the card carries the account — does not look at name or SAP, because that block is restricted to the Sent tab. La tarjeta de pago repite el estado en lugar del título, y no es clicable. El título de la fila es la propia etiqueta de estado, así que cada tarjeta muestra el mismo texto dos veces y nunca el punto de venta, el monto o el medio de pago — que existen en el registro. Como el toque no navega a ningún detalle, no hay ninguna superficie en el Centro de datos para inspeccionar esos campos (aparecen en el detalle del título en Gestión financiera). Efectos colaterales: ordenar "por tipo" en esa pestaña ordena por estado, y la búsqueda — aunque la tarjeta lleve la cuenta — no busca por nombre ni por SAP, porque ese trecho está restringido a la pestaña de Envíos.
• Uma falha no relatório de caixa desaparece. Ao sincronizar um pagamento, a linha final preserva a mensagem de erro anterior quando o relatório de caixa falha — e ela normalmente está vazia. O registro é promovido a enviado de todo modo, perde o botão, e nada indica que uma das três transações não saiu. O mesmo vale para o comprovante: a falha dele marca um campo de estado de evidência que nenhuma tela exibe, e não há caminho para reenviar só a evidência. A cash-report failure disappears. When syncing a payment, the final row preserves the previous error message when the cash report fails — and that is normally empty. The register is promoted to sent anyway, loses its button, and nothing indicates that one of the three transactions didn't go out. The same holds for the proof of payment: its failure sets an evidence-status field no screen displays, and there is no path to resend the evidence alone. Un fallo en el reporte de caja desaparece. Al sincronizar un pago, la fila final preserva el mensaje de error anterior cuando el reporte de caja falla — y normalmente está vacío. El registro se promueve a enviado de todos modos, pierde el botón, y nada indica que una de las tres transacciones no salió. Lo mismo vale para el comprobante: su fallo marca un campo de estado de evidencia que ninguna pantalla muestra, y no hay camino para reenviar solo la evidencia.
• Um pagamento com status desconhecido se disfarça de sincronizado. O valor unknown reusa a etiqueta de sent, cai num grupo que a aba não declara caixa (logo não é contado em nenhuma) e não tem opção de filtro — então qualquer filtro o esconde. Pior: o encerramento da jornada o conta como pagamento pendente, enquanto esta tela o mostra como "Sincronizado". Duas telas, duas leituras opostas do mesmo registro. A payment with an unknown status disguises itself as synced. The unknown value reuses sent's label, lands in a group the tab declares no box for (so it is counted in none) and has no filter option — so any filter hides it. Worse: the journey wrap-up counts it as a pending payment, while this screen shows it as "Synced". Two screens, two opposite readings of the same register. Un pago con estado desconocido se disfraza de sincronizado. El valor unknown reutiliza la etiqueta de sent, cae en un grupo para el que la pestaña no declara caja (así que no se cuenta en ninguna) y no tiene opción de filtro — así que cualquier filtro lo esconde. Peor: el cierre de la jornada lo cuenta como pago pendiente, mientras esta pantalla lo muestra como "Sincronizado". Dos pantallas, dos lecturas opuestas del mismo registro.
• A aba de "serviços" existe inteira e é inalcançável. O tipo integration tem valor no enum, página própria (uma casca com "Em breve"), rota, método de navegação e chave de tradução — mas nenhum mercado o declara, e o único caminho para a página exige um cartão de uma aba que nunca é montada. É andaime de uma funcionalidade não entregue; ou se configura, ou se remove. The "services" tab exists in full and is unreachable. The integration type has an enum value, its own page (a shell with "Coming soon"), a route, a navigation method and a translation key — but no market declares it, and the only path to the page requires a card from a tab that is never built. It's scaffolding for an unshipped feature; either configure it or remove it. La pestaña de "servicios" existe entera y es inalcanzable. El tipo integration tiene valor en el enum, página propia (una cáscara con "Próximamente"), ruta, método de navegación y clave de traducción — pero ningún mercado lo declara, y el único camino a la página exige una tarjeta de una pestaña que nunca se arma. Es andamio de una funcionalidad no entregada; o se configura, o se quita.
• Configuração declarada e não obedecida. O ícone de cada caixa é lido da configuração, guardado na entity e nunca usado — o ícone real vem de uma tabela fixa no código (hoje os valores coincidem, então a divergência é invisível). Os códigos de filtro são configuráveis, mas só quatro têm efeito (status, type, attempts, period): um código novo renderiza os chips e não filtra nada. A ordenação não é configurável de forma alguma. E desligar hasFilter numa aba esconderia também a busca e a ordenação, não só o botão de filtro — nenhuma aba faz isso hoje, então esse caminho nunca foi exercitado. Configuration declared and not obeyed. Each box's icon is read from configuration, stored on the entity and never used — the real icon comes from a fixed table in code (today the values coincide, so the divergence is invisible). Filter codes are configurable, but only four have any effect (status, type, attempts, period): a new code renders the chips and filters nothing. Sorting isn't configurable at all. And switching hasFilter off on a tab would also hide the search and the sort, not just the filter button — no tab does that today, so that path has never been exercised. Configuración declarada y no obedecida. El ícono de cada caja se lee de la configuración, se guarda en la entity y nunca se usa — el ícono real viene de una tabla fija en el código (hoy los valores coinciden, así que la divergencia es invisible). Los códigos de filtro son configurables, pero solo cuatro tienen efecto (status, type, attempts, period): un código nuevo renderiza los chips y no filtra nada. El orden no es configurable en absoluto. Y apagar hasFilter en una pestaña esconderia también la búsqueda y el orden, no solo el botón de filtro — ninguna pestaña lo hace hoy, así que ese camino nunca se ejercitó.
• Uma falha de leitura de dados deixa a tela vazia em vez de avisar. O carregamento degrada as falhas dos dois primeiros diários para lista vazia, então um problema de cache aparece como "nenhum envio no momento". Só a resolução de pagamentos lança de verdade — e é a única capaz de levar a tela ao estado de erro, mesmo nos mercados sem aba de pagamentos, onde ela roda igual. A data-read failure leaves the screen empty instead of warning. The load degrades failures of the first two journals to an empty list, so a cache problem shows up as "no sends at the moment". Only the payment resolution actually throws — and it is the only one able to take the screen to the error state, even in markets with no payments tab, where it runs all the same. Un fallo de lectura de datos deja la pantalla vacía en vez de avisar. La carga degrada los fallos de los dos primeros registros a lista vacía, así que un problema de caché aparece como "sin envíos por el momento". Solo la resolución de pagos lanza de verdad — y es la única capaz de llevar la pantalla al estado de error, incluso en los mercados sin pestaña de pagos, donde corre igual.
• Diagnóstico que não chega ao suporte. O código estável e o identificador de rastreio são gravados em cada linha com erro e não aparecem em lugar algum — nem na tela de detalhe, nem no bloco de "copiar código de suporte", que leva o código de erro, o código de erro do app e a categoria, mas não esses dois. Esse bloco, aliás, é escrito com 27 rótulos fixos em inglês, o que é deliberado (é artefato de suporte, não texto de produto). O andamento da varredura em segundo plano também é registrado no estado e nunca mostrado — o rep não tem como saber que uma sincronia está correndo. Diagnostics that never reach support. The stable code and the trace identifier are written on every errored row and appear nowhere — not on the detail screen, not in the "copy support code" block, which carries the error code, the app error code and the category, but not those two. That block, incidentally, is written with 27 hardcoded English labels, which is deliberate (it's a support artifact, not product copy). The background sweep's progress is likewise recorded in state and never shown — the rep has no way to know a sync is running. Diagnóstico que no llega al soporte. El código estable y el identificador de rastreo se graban en cada fila con error y no aparecen en ningún lugar — ni en la pantalla de detalle, ni en el bloque de "copiar código de soporte", que lleva el código de error, el código de error de la app y la categoría, pero no esos dos. Ese bloque, por cierto, está escrito con 27 rótulos fijos en inglés, lo cual es deliberado (es artefacto de soporte, no texto de producto). El avance del barrido en segundo plano también se registra en el estado y nunca se muestra — el rep no tiene cómo saber que una sincronización está corriendo.
• Sem reconciliação com o servidor. O contrato só oferece o envio: não existe RPC para consultar o histórico. A única verdade que o app recebe é o retorno síncrono de cada envio, então uma linha que ficou pendente ou com erro nunca é confrontada com o estado real no backend. É o limite de desenho desta tela, e vale registrar para não se esperar dela o que ela não pode fazer. No reconciliation with the server. The contract only offers sending: there is no RPC to query history. The only truth the app receives is each send's synchronous response, so a row left pending or errored is never checked against the backend's real state. It's this screen's design boundary, and worth recording so nobody expects from it what it cannot do. Sin reconciliación con el servidor. El contrato solo ofrece el envío: no existe RPC para consultar el historial. La única verdad que la app recibe es la respuesta síncrona de cada envío, así que una fila que quedó pendiente o con error nunca se confronta con el estado real en el backend. Es el límite de diseño de esta pantalla, y vale registrarlo para no esperar de ella lo que no puede hacer.
• Pontas soltas menores. O limite de cinco tentativas do reenvio automático nunca é alcançado: uma linha pendente sempre tem zero tentativas, porque sair da fila é definitivo. A fila offline não deduplica — repetir a mesma ação offline cria uma linha por repetição, e todas são enviadas. O leque paralelo de envelopes do orquestrador não tem chamador (três UseCases o reescrevem à mão). O status 5 é aceito como sucesso, embora a varredura do backend tenha concluído que ele não existe. Dez chaves de tradução da feature não têm nenhum consumidor. E dois parsers de status caem em fallback sem log: um status de envio não reconhecido vira error — o que também habilita o botão Reenviar numa linha cujo estado real é desconhecido — e um de sincronia vira pending. Smaller loose ends. The automatic retry's five-attempt cap is never reached: a pending row always has zero attempts, because leaving the queue is final. The offline queue does not deduplicate — repeating the same offline action creates one row per repetition, and all of them are sent. The orchestrator's parallel envelope fan-out has no caller (three UseCases hand-rewrite it). Status 5 is accepted as success, although the backend sweep concluded it doesn't exist. Ten of the feature's translation keys have no consumer at all. And two status parsers fall back without logging: an unrecognised dispatch status becomes error — which also enables the Resend button on a row whose real state is unknown — and a sync one becomes pending. Puntas sueltas menores. El límite de cinco intentos del reenvío automático nunca se alcanza: una fila pendiente siempre tiene cero intentos, porque salir de la cola es definitivo. La cola offline no deduplica — repetir la misma acción offline crea una fila por repetición, y todas se envían. El abanico paralelo de envelopes del orquestador no tiene llamador (tres UseCases lo reescriben a mano). El estado 5 se acepta como éxito, aunque el barrido del backend concluyó que no existe. Diez claves de traducción de la feature no tienen ningún consumidor. Y dos parsers de estado caen en fallback sin log: un estado de envío no reconocido se vuelve error — lo que además habilita el botón Reenviar en una fila cuyo estado real es desconocido — y uno de sincronía se vuelve pending.
• A configuração anotada do EMC ignora esta feature. O arquivo comentado de referência do End Market Configuration não menciona dataCenterConfig uma única vez — nem o README da pasta —, embora documente fielmente o dataFreshnessConfig. Toda a configuração desta tela, inclusive a aba de pagamentos do Chile, existe apenas nos arquivos reais. The EMC's annotated configuration ignores this feature. The commented End Market Configuration reference file doesn't mention dataCenterConfig even once — nor does the folder's README — although it documents dataFreshnessConfig faithfully. All of this screen's configuration, including Chile's payments tab, exists only in the real files. La configuración anotada del EMC ignora esta feature. El archivo comentado de referencia del End Market Configuration no menciona dataCenterConfig ni una vez — ni el README de la carpeta —, aunque documenta fielmente el dataFreshnessConfig. Toda la configuración de esta pantalla, incluida la pestaña de pagos de Chile, existe solo en los archivos reales.