Frila · Escopo do MVP

Versão 1.0 · 22 de setembro de 2026

O que entra em cada versão do Frila, o que fica fora e por quê, e como o trabalho se divide em sprints até a loja. Este documento é a fonte do quadro do Trello (https://trello.com/b/0eyqvbRJ/frila) e tem uma cópia editável em https://claude.ai/code/artifact/7c7cc595-0666-4687-a586-316e542f7d70.

---

Resumo

O MVP do Frila é um app iOS, só no Distrito Federal, que fecha o ciclo de um turno avulso de ponta a ponta: o contratante publica a vaga com poucos campos, os profissionais perto recebem a notificação e se candidatam sem formulário, o primeiro aceito é confirmado, faz check-in no local e os dois se avaliam com Sim ou Não.

Ele vai para a App Store em 13/11/2026 (v1.0). Antes disso, o protótipo clicável é apresentado na Apple Review de 28/09 (v0.1) e um TestFlight interno fecha o ciclo em 27/10 (v0.5). Entram as 19 histórias MUST do Backlog v1.2.0, menos a parte web do Painel do gestor. Ficam para a v1.1 (dezembro) o modo seleção, a equipe de confiança e o suporte por e-mail, e para a v1.2 (1º trimestre de 2027) o Android, a web com o Painel e a escala de evento em lote.

O time tem três desenvolvedores (Cauê, João Paulo e Matheus), uma PO (Júlia) e um designer (Fabrício), e sete semanas até a loja.

Critério de corte

Entra na v1.0 o que é preciso para um turno acontecer de ponta a ponta no iOS, no DF, e o que a App Store exige para aprovar o app. Cada história do Backlog passou por quatro perguntas, nesta ordem:

1. Sem isso o ciclo não fecha? Publicar, notificar, candidatar, confirmar, liberar contato, fazer check-in e avaliar entram.
2. A App Store exige? Excluir a conta de dentro do app (diretriz 5.1.1(v)), denunciar e bloquear (diretriz 1.2) e a política de privacidade entram.
3. É a tese do produto? Despacho por proximidade sem levas, reputação binária com denominador e valor integral para o profissional entram, porque são o que diferencia o Frila do grupo de WhatsApp.
4. Só faz sentido com volume ou com outra plataforma? Escala em lote, Painel web, Android, relatório consolidado e múltiplos membros ficam para depois.

A base é a prioridade MoSCoW do Backlog v1.2.0: MUST vai para a v1.0, SHOULD para a v1.1 e COULD para a v1.2. A única exceção é a US21: o alerta de vaga vazia e a confirmação de check-in manual entram na v1.0, no app, e o Painel web vai para a v1.2, junto com a versão web. Fora do produto continuam pagamento no app, CLT, chat, nota de 1 a 5, aval externo e operação fora do DF.

O que entra na v1.0 (MVP)

A v1.0 é um app iOS (iOS 17 ou superior), com dois perfis e um perfil por conta, para o Distrito Federal, com o backend no Supabase. São 19 histórias e 90 pontos, todas MUST no Backlog v1.2.0.

Também fazem parte da v1.0, sem história própria: a política de privacidade e os termos de uso publicados, o texto "Por que recebo vagas" no perfil (a explicação, sem o botão Contestar), leitura offline dos turnos confirmados (RNF06), acessibilidade com VoiceOver e Dynamic Type (RNF10) e a telemetria mínima para medir o piloto.

O que fica fora do MVP

Oito histórias do Backlog e três plataformas ficam para depois da loja. Nenhuma delas impede um turno de acontecer no DF pelo iPhone.

Fora do produto, sem data: pagamento dentro do app (RN09), contratação CLT e processo seletivo, chat interno, nota de 1 a 5, aval de fora da plataforma, rede social e operação fora do DF antes da consolidação.

Versões e iterações

A v1.1 só começa depois da loja: até 13/11 toda a capacidade do time vai para a v1.0. O que o piloto mostrar entre 13/11 e 04/12 reordena a v1.1; a lista acima é o ponto de partida, não um compromisso.

Fluxos de uso da v1.0

Dois fluxos, um por perfil, que se encontram na vaga. Cada caixa é uma tela do protótipo clicável.

flowchart LR
  A[Entrar com código no e-mail] --> B[Perfil de contratante]
  B --> C[Cadastrar estabelecimento]
  C --> D[Publicar vaga]
  D --> E{Vaga preenchida?}
  E -- não, a 3 h do início --> F[Alerta de vaga vazia]
  F --> D
  E -- sim --> G[Confirmado e contato]
  G --> H[Confirmar check-in manual]
  H --> I[Avaliar: chamaria de novo?]

O contratante publica e espera: o Frila notifica quem está perto e o avisa se a vaga seguir vazia. Ele só volta a agir para confirmar um check-in manual e para avaliar.

flowchart LR
  A[Entrar com código no e-mail] --> B[Perfil de profissional]
  B --> C[Funções, ponto base e grade]
  C --> D[Notificação de vaga]
  D --> E[Ver vaga e reputação do local]
  E --> F[Candidatar-me]
  F --> G{Primeiro a aceitar?}
  G -- sim --> H[Confirmado: contato liberado]
  G -- não --> I[Vaga já preenchida]
  I --> E
  H --> J[Check-in até 200 m]
  J --> K[Check-out e avaliar]

O profissional recebe, decide e vai. Perder a corrida no modo urgência é normal e a tela diz isso sem culpa; ele volta à lista de vagas do DF.

As 26 histórias completas, com narrativa e cenários BDD, estão na coluna "Histórias de usuário" do quadro do Trello e no Backlog v1.2.0.

Sprints até a loja

Quatro sprints de 22/09 a 13/11. O Sprint 0 é de fundação e termina no marco que o FigJam já marcava (05/10); os outros têm duas semanas, e o último é mais curto porque termina na loja. Cada sprint tem uma pergunta que responde e o backend anda uma etapa à frente do iOS.

Depois da loja, a coluna Backlog v1.1 tem 10 cartões e a v1.2 tem 7. Se o Sprint 2 atrasar, o corte segue esta ordem, sem tocar no ciclo nem no que a App Store exige: republicar vaga (US05), aviso de hora excedida, lembrete de 24 h (fica só o de 3 h) e exportar dados (excluir conta fica). Nunca saem: candidatura e confirmação, check-in, avaliação, denúncia e bloqueio, exclusão de conta.

Carga e cortes dos Sprints 1 e 2 (revisão de 19/10/2026)

O que é: estimativa em dias por cartão, carga de cada dev e cortes decididos, feitos em 19/10/2026 pelo Nick Fury por delegação do Cauê (líder do projeto). São estimativas, não medição: cada dono corrige o seu número na quarta-feira, 21/10, e a tabela é atualizada.

Premissas

• Sprint 1: 06/10 a 19/10, com 9 dias úteis (12/10 é feriado). Sprint 2: 20/10 a 02/11, com 9 dias úteis (02/11 é feriado). Sprint 3 começa em 03/11.
• Três devs: Cauê, João Paulo e Matheus. Capacidade de cada um: 9 dias por sprint (100%), já contando 1 dia de rituais e revisão de PR.
• "Dia" é o tempo de atenção do dev (decisão, revisão, teste e correção), com o apoio dos Vingadores. O "restante" vem do estágio do cartão (Revisão, mais ou menos 0,5 dia; Em andamento, 1 a 3 dias) e dos critérios ainda abertos.
• Critério sem marcar não prova que o trabalho não foi feito; por isso o restante dos cartões de design e pesquisa fica "a confirmar pelo dono".

Estimativa por cartão: Sprint 1 (cartões que eram do Sprint 1)

Estimativa por cartão: Sprint 2

Carga de cada dev

Sprint 1 (retrospectivo, capacidade 9 dias)

Leitura: o Sprint 1 fechou com o Cauê acima de 100% e com os cartões de infra dele (SMTP, entrega contínua, build 0.4) sem terminar, porque o tempo foi para o backend do Sprint 2. Os outros dois tiveram folga.

Sprint 2 (planejado, capacidade 9 dias, já com 1 dia de rituais e revisão)

Soma do time: 27 de 27 dias. Não há folga. Por isso há gatilho de corte abaixo.

Cortes decididos

1. Mudança de rota, sem perda de escopo: El0rlp6K (develop para main e produção, 2 dias) sai do Sprint 2 e vai para o início do Sprint 3 (03/11 a 05/11), mantendo o prazo do próprio cartão (05/11, antes da submissão de 06/11). Risco: sobram 3 dias úteis para 2 dias de trabalho; se algum cartão do backend atrasar, a produção atrasa junto. Cartão movido para a coluna do Sprint 3.
2. Troca de dono, sem perda de escopo: dke9K3yV (entrega contínua) e prRWMvWj (prazo_resposta) passam para o Matheus; 0,5 dia do Jg8qMYKj passa do Cauê para o João; 1 dia do TestFlight 0.5 passa do Cauê para o João; wosMgVsF (RNF04, medição no aparelho com iOS 17) passa para o João, que é quem tem o aparelho e o Xcode. O motivo é tirar o Cauê de 139% para 100%.
3. Nada do que nunca sai foi cortado: candidatura e confirmação, check-in, avaliação, denúncia e bloqueio, e exclusão de conta seguem inteiros.
4. Gatilho para cortes de escopo (não acionado hoje): em 27/10, se o restante dos cartões do Sprint 2 passar de 100% da capacidade restante, cortar nesta ordem: republicar vaga (US05), aviso de hora excedida, lembrete de 24 h, exportar dados. É a mesma ordem da seção "Ordem de corte" deste documento; nenhum item corta sozinho sem registro aqui.
5. Fora desta rodada: a carga de Júlia e Fabrício. Os cartões deles têm estimativa registrada, mas o restante depende do que cada um já fez, e os cartões não mostram (critérios sem marcar). Os dois confirmam na quarta-feira, 21/10, e o balanço deles entra na próxima revisão.

Registro: 19/10/2026 · Nick Fury, por delegação do Cauê Carneiro Kilanovic (cartão UwqBldBW). Próxima revisão: 21/10 (confirmação dos donos) e 27/10 (gatilho de corte).

Riscos e dependências

Dependências externas fora do controle do time: aprovação da Apple, entrega do FCM e da APNs, disponibilidade do Supabase no horário de pico (RNF12) e a agenda dos estabelecimentos do piloto.

O quadro do Trello

O quadro tem 2 cartões de leitura, 26 histórias de usuário e 101 tarefas (84 até a loja, 17 depois). Cada tarefa tem etiquetas, responsável sugerido, história ou requisito, contexto, o que fazer, critérios de aceite e referências.

O nome de cada cartão carrega o sprint e a área (S1 · Backend · …). As etiquetas estão na primeira linha da descrição (#backend #must #epico-4), porque a integração usada para montar o quadro não cria etiquetas coloridas; para tê-las, basta criar no menu do quadro as de área (Backend, iOS, Design, Produto, Pesquisa, Jurídico, Infra, QA) e as de prioridade (MUST, SHOULD, COULD). O prazo de cada cartão é o fim do sprint, salvo os marcos fixos: 28/09, 27/10, 06/11, 10/11 e 13/11.

Responsáveis são sugestão, não atribuição: Cauê no backend e na infra, João Paulo e Matheus no iOS e no backend, Fabrício no design, Júlia em produto, pesquisa e jurídico.

---

Fontes: Documento de Requisitos v1.3.0, Documento de Visão v1.2.0, Histórias de Usuário e Backlog v1.2.0, contrato da API 0.2.0, notas de arquitetura do vault (Arquitetura, Classe, Banco, Casos de Uso, Pendências Técnicas), quadro 03 do FigJam e as tarefas T-0010 a T-0024. As datas dos marcos vêm do calendário do CBL C18.