Pular para o conteúdo
Challenge 18
Live
DIÁRIODIÁRIO DE BORDO

23 set 2026

Equipe BlendOps
Cauê Carneiro, Fabrício Tosta, João Paulo, Júlia Clovandi, Matheus Silva
Data
Contexto
FrilaChallenge 18 (Apple Developer Academy)

O que foi feito

  • Cenários de desenvolvimento do Frila: 12 profissionais, 4 contratantes, 3 estabelecimentos do DF, 7 vagas em todos os estados, 7 turnos, 6 avaliações, 1 bloqueio e 2 ocorrências (6858610).
  • Teste que mede o próprio cenário: 36 asserções. A suíte vai de 196 para 232, com 71 de 71 regras cobertas por mutação e o ciclo HTTP verde.
  • Elegibilidade da RN05 medida com PostGIS, não estimada: Lago Sul 8,6 km, Águas Claras 16,9 e 17,4 km até a vaga de referência.
  • Portão do advisor de segurança corrigido para reprovar quando não consegue medir (9167fca).
  • Contrato 0.2.2 publicado, com as 4 operações que faltavam e a troca de alvo_usuario_id por alvo_tipo + alvo_id (BlendOps/Frila#2).
  • Conferência de 83 cartões do Sprint 1 e 2 contra as 43 operações do contrato: 4 faltavam, 6 divergiam de nome, 11 existem sem cartão, 26 conferem.
  • Portão contrato-acompanha-o-codigo.sh: reprova PR que mexe em função de public sem levar o contrato (6422e98).
  • CI nova no repositório do Frila: redocly lint, versão que sobe e seção Estado que descreve a versão.
  • Ponte bancada-sync.sh entre o backend e esta Bancada (fef5fe7, b483a7b), e a forma externo no registrar-fato.sh.
  • Hooks desta Bancada voltaram a funcionar no monorepo.
  • Filtro de texto ofensivo (diretriz 1.2 da App Store): privado.termo_bloqueado, normalizar e texto_aceitavel, com criar_conta recusando nome com termo bloqueado (422 campo_invalido).
  • Contrato 0.2.3 por causa dele: criar_conta passa a poder devolver um código que antes não devolvia.
  • Verificador de mutação passa a varrer o schema privado: de 71 para 74 alvos.
  • 223 asserções pgTAP na branch do filtro, 74 de 74 na mutação, 422 campo_invalido conferido por HTTP.
  • Três RPCs do perfil profissional (US02): criar, ler e atualizar, com a grade semanal que aceita janela atravessando a meia-noite.
  • Contrato 0.2.4: perfil_ja_existe e o 404 que faltava em atualizar_perfil_profissional.
  • 256 asserções pgTAP, 74 de 74 na mutação, sete passos novos no ciclo HTTP.
  • A organização mudou de nome: BlendOps virou FrilaApp, e Frila virou frila-docs. Trinta referências corrigidas em oito arquivos.
  • Oito PRs abertos: frila-backend#4, #5, #7, #8, #9, #10 e frila-docs#2, #3, #4.

Decisões

  • Cenário não entra no seed.sql, ao contrário do que o cartão pede — e pelo motivo que o próprio critério de aceite dele dá. aplicar-remoto.sh aplica o seed.sql no frila-dev, porque lá ele é o catálogo de funções, que é dado de produto. Cenário nesse arquivo vira estabelecimento fantasma no ambiente remoto.
  • O contrato vira 0.2.2, não 0.2.1. A 0.2.1 saiu em 22/09 e nenhuma das dez operações que o cartão lista estava nela. Adições compatíveis sobem o patch.
  • bloquear e denunciar trocam de parâmetro sem virar _v2. O campo antigo era impreenchível: nenhuma resposta devolve o id de conta da outra parte. Sem cliente capaz de chamar, a troca não deixa ninguém para trás.
  • criar_conta não recebe a data do aceite. A versão vem do cliente, o instante é do servidor. Data enviada pelo app é forjável, e consentimento que a parte interessada escreve não vale como registro.
  • Grade semanal vazia é aceita no cadastro. Recusar obrigaria a pessoa a inventar uma grade para terminar, e grade inventada é pior que grade vazia: ela produz despacho para quem não vai atender.
  • Criar perfil duas vezes é conflito, não sobrescrita. Sobrescrever apagaria a grade de quem tocasse duas vezes no botão.
  • O filtro compara palavra inteira, e não substring. cu está dentro de Cunha, Cuiabá, curso e cuidado. Um filtro por substring recusaria "Ana Cunha" no cadastro.
  • Quatro termos ficaram fora da lista de propósito: pinto, pau, rola e boceta — sobrenome, topônimo, verbo de uso diário e grafia regional. O teste fixa Rodrigo Pinto para que a exclusão não se perca.
  • O filtro não persegue variação de grafia. m3rda passa, e passar é o desenho: um filtro que persegue grafia vira um filtro que recusa nome de gente.
  • A ponte não escreve a narrativa do dia. Fato e narrativa são camadas separadas; um script que virasse assunto de commit em prosa inventaria a camada de cima a partir da de baixo.

Bloqueios

  • SUPABASE_ACCESS_TOKEN responde 401. O advisor de segurança do frila-dev não é verificado desde que o token venceu, e não aparecia porque o portão lia o corpo de erro como "nenhum achado". Depende de supabase login presencial.
  • FRILA_DOCS_TOKEN não existe. contrato-em-dia.sh nunca chegou a comparar o espelho com o original — confere só a integridade local.
  • Requisitos 6.4 cita versão antiga do contrato e está no .docx, binário. Precisa de quem edita o original.
  • A lista de termos bloqueados precisa da revisão da Júlia. É decisão de produto e de jurídico, não de quem escreve o SQL. Sem ela, o cartão do filtro não fecha.
  • A CI do backend não rodou um teste sequer hoje. Cinco execuções em três branches caíram em toomanyrequests do ghcr.io antes de subir o ambiente. O docker/login-action entrou e não resolveu: o passo autenticou e o pull continuou falhando, o que aponta incidente do registro, não cota.

Aprendizados

  • Os hooks desta Bancada estavam desligados no monorepo. O bootstrap.sh fixava core.hooksPath em scripts/git-hooks, caminho que não existe na raiz do monorepo — e o git não reclama de hooksPath inexistente, simplesmente não roda hook. Zero fatos entre 10/09 e 23/09, sem uma linha de aviso.
  • A primeira versão da ponte datou 22/09 como se fosse hoje. Uma jornada inteira aterrissou no log de um dia em que ela não aconteceu.
  • git log --all inclui refs/stash. Dois git stash viraram quatro fatos com assunto "index on <branch>". Guardar trabalho não é trabalho.
  • curl -sS sai com 0 num 401. O portão do advisor lia o corpo de erro como resposta válida. Mesma falha de 22/09, num portão que a correção daquele dia não alcançou.
  • Banco povoado quebra teste escrito para banco vazio. Três asserções consultavam public.turno e public.vaga sem filtro, o que só significava "o que este teste criou" enquanto o reset deixava o banco vazio.
  • Fixture sem teste apodrece em silêncio. Quem descobre é a próxima pessoa que for demonstrar o produto.
  • A CI pode reprovar pelo motivo errado. O PR de prova do portão do contrato falhou na primeira execução por rate limit do ghcr.io, não pelo portão. Reprovação não é prova; prova é reprovar no passo certo. O portão saiu de trás do supabase start e virou job próprio: portão barato não fica atrás de portão caro.
  • Portão com alcance curto mente com convicção. O verificador de mutação só varria public. A primeira tabela de privado com restrição entrou e o total de alvos não subiu: ele continuou dizendo 71 de 71. Alargar o alcance achou, de brinde, uma regra sem cobertura nenhuma — o check (id) que faz de privado.ambiente uma tabela de uma linha só.
  • Rótulo de volatilidade mentiroso, de novo. privado.ponto_do_json nasceu IMMUTABLE levantando exceção. Terceira vez que o lint pega o mesmo defeito neste projeto — o planejador acredita no rótulo, não no corpo.
  • Redirect do GitHub esconde nome morto. A org BlendOps não existe mais e nada quebrou: trinta referências continuavam funcionando por redirect, inclusive a URL da Management API no portão que compara o espelho do contrato com o original.
  • Metade de um teste de filtro tem de medir o que ele aceita. Falso negativo tem denúncia e bloqueio atrás; falso positivo não tem nada — a pessoa é recusada por um motivo que não entende e vai embora, sem ninguém no time ficar sabendo.

Próximos passos

  • cadastrar_estabelecimento, que é o que falta para publicar_vaga ter onde publicar.
  • Depois publicar_vaga e candidatar — candidatar é onde o produto quebra se errar, e precisa de teste de corrida com pgbench.
  • Avisar o time da renomeação da org: todo link BlendOps/... nos cartões do Trello está vivo só por redirect.
  • Revisão da Júlia na lista de termos bloqueados.
  • Reexecutar a CI quando o ghcr.io estabilizar: nenhum dos seis PRs teve teste rodado lá.
  • Renovar o token de conta do Supabase e voltar a medir o advisor do frila-dev.
  • Decidir as 11 operações que existem no contrato e não têm cartão: contrato a mais ou cartão faltando.