Quando o sync parece funcionar, mas o estado ainda não merece confiança

O nome original desse projeto era todo_flutter.

Mas faz tempo que ele deixou de ser só "um app de tarefas em Flutter".

Hoje ele é o SaaS Reliability Lab: um playground público para mostrar, de forma visível, o que acontece quando sincronização, sessão e conflito saem do caminho ideal.

Repositório público:

github.com/eliasfeijo/saas-reliability-lab

Playground em produção:

eliasfeijo.github.io/saas-reliability-lab

Esse reposicionamento importa porque o problema central nunca foi só "sincronizar tarefas".

O problema era outro: entender como um produto pode parecer estável no happy path e, ainda assim, deixar de ser confiável quando a realidade começa a sair do roteiro.

Hidratação virou problema de verdade quando o estado precisou continuar honesto

Um dos sinais mais úteis no histórico foi o commit fix(flutter-app): persist remote sync hydration.

Esse tipo de ajuste parece pequeno, mas aponta para uma fragilidade comum: a interface pode restaurar dados locais e parecer pronta, enquanto a leitura real do estado ainda está incompleta.

No laboratório, isso se mistura com outro ajuste importante do mesmo bloco: fix(flutter-app): serialize workspace auth setup.

Juntos, eles reforçam uma leitura simples: "hidratar" não é só restaurar dados salvos. É recolocar cada coisa no lugar certo antes de fingir continuidade.

Se isso fica implícito, o produto transmite confiança antes da hora.

E continuidade falsa gera um tipo ruim de confiança: aquela que parece existir até o dia em que alguém precisa explicar o que aconteceu.

Delayed replay deixou de ser truque de demo e virou ferramenta de leitura

Outro grupo de commits recentes foi ainda mais didático.

Primeiro vieram feat(flutter-app): add staged delayed sync controls e feat(flutter-app): add outbox diagnostics and reset controls.

Depois apareceu fix(flutter-app): preserve delayed replay follow-up updates.

Aqui vale traduzir os termos.

Quando eu falo em delayed replay, estou falando de uma sincronização que o próprio lab segura de propósito por alguns instantes para ficar mais fácil observar o comportamento do sistema.

Em vez de deixar tudo acontecer rápido demais e esconder os detalhes, o app cria um atraso controlado e mostra o que acontece enquanto aquela mudança ainda está "a caminho".

Isso se conecta com outro conceito importante do lab: fault injection.

Em linguagem simples, fault injection é a prática de provocar cenários de falha ou atraso de forma controlada para ver se o produto continua compreensível e confiável fora do happy path.

No SaaS Reliability Lab, isso não aparece como teoria solta. Já existe, na interface do operador, a possibilidade de simular perda de conectividade e também delayed sync com algumas opções bem concretas:

• atrasos de 500 ms, 2 s, 5 s e 10 s
• atraso no estágio local, transport ou backend
• comportamento persistente ou one-shot

O ponto importante não é o nome da técnica. É o que ela revela.

Não bastava atrasar o replay para fins de demonstração. O sistema precisava continuar íntegro quando novas mudanças aconteciam enquanto aquela sincronização atrasada ainda estava em curso.

É aí que o delayed sync deixa de ser truque visual e vira experimento de produto.

As perguntas mudam de nível:

• a mudança nova entra como continuação coerente do estado local?
• ela é perdida, duplicada ou escondida enquanto o sync anterior ainda está em espera?
• o operador consegue ver onde o atraso está acontecendo: no local, no transporte ou na confirmação final?
• a timeline ajuda a explicar o comportamento ou só confirma que "alguma coisa sincronizou"?

Quando o produto consegue responder isso visualmente, o sync deixa de ser caixa-preta.

O nome mudou, mas a lição principal ficou mais nítida

Hoje faz muito mais sentido falar em SaaS Reliability Lab do que em todo_flutter.

O domínio de tarefas continua pequeno de propósito, mas o produto real já é outro: um playground público para tornar visível o tipo de ambiguidade operacional que muita aplicação esconde até tarde demais.

O ponto principal, para mim, ficou este:

em produto com sincronização, confiança não vem de "ter sync". Ela vem de conseguir explicar o que está pendente, o que foi confirmado, o que ficou bloqueado e o que ainda precisa de decisão.

Quando até um laboratório pequeno precisa iterar em fila local explícita, delayed replay com continuidade íntegra, hidratação remota persistida, coordenação de auth e revisão de conflito no workspace, fica mais fácil perceber o que sistemas maiores costumam chamar de "sincronizado" sem realmente tornar o estado confiável.

Se quiser explorar o playground público, ele está aqui:

eliasfeijo.github.io/saas-reliability-lab

E, se esse ângulo conversa com o teu contexto, o ponto de entrada principal continua aqui:

Se fizer mais sentido começar por uma leitura prática do seu fluxo: