FastInBox | Manual consolidado
Documentacao Geral da Plataforma
Versao: 2.0 | Documento guarda-chuva de produto e engenharia
Este manual consolida visao de produto, jornada por perfil, arquitetura funcional, modelo de entrega e diretrizes de continuidade da plataforma FastInBox.
1. Resumo executivo
FastInBox e uma plataforma white label para operacao de marmitas personalizadas. O produto conecta os atores do processo em fluxo transacional unico, minimizando dependencias de ferramentas paralelas e melhorando governanca de status.
O recorte atual prioriza demonstrabilidade academica sem comprometer evolucao tecnica futura.
2. Arquitetura funcional por modulo
2.1 Modulo nutricionista
- Cadastro e atualizacao de pacientes.
- Criacao de pedidos com multiplos itens.
- Acompanhamento de status de cada pedido.
2.2 Modulo paciente
- Acesso por codigo unico do pedido.
- Revisao de itens e confirmacao.
- Pagamento e visao de progresso da producao.
2.3 Modulo fabrica
- Painel kanban para fluxo operacional.
- Atualizacao de transicoes de status.
- Consolidacao de itens por janela de entrega.
2.4 Modulo administrativo
- Governanca de operacao e indicadores.
- Visao consolidada de usuarios e pedidos.
- Acompanhamento de saude da plataforma.
3. Stack e repositorios
| Camada | Tecnologia | Repositorio |
|---|---|---|
| Aplicacao web | Next.js 15, React 19, TypeScript | front |
| API e dominio | NestJS 11, TypeScript | back |
| Documentacao | HTML/CSS/JS + GitHub Pages | docs |
| Governanca GitHub | Perfil publico e padroes | .github |
4. Fluxo operacional detalhado
- Nutricionista registra paciente ou seleciona existente.
- Pedido e montado com itens, observacoes e data de entrega.
- Codigo unico e gerado para jornada do paciente.
- Paciente revisa, confirma e paga.
- Sistema libera pedido para fabrica apos autorizacao financeira.
- Fabrica executa producao e movimenta status ate entregue.
- Todos os perfis acompanham a mesma linha de status.
5. Niveis de qualidade esperados
- Consistencia de navegacao: sem rotas quebradas entre jornadas.
- Confiabilidade visual: layout responsivo e legivel.
- Integridade de estado: transicoes coerentes de pedido.
- Rastreabilidade: historico operacional disponivel para analise.
- Reprodutibilidade: build e deploy com procedimento documentado.
6. Limites da versao atual
A Sprint 1 adota persistencia local para reduzir complexidade e garantir um unico deploy funcional para demonstracao. Esta decisao e intencional e controlada, com plano de migracao para persistencia real na sequencia do roadmap.
Nao e um limite de arquitetura final; e uma estrategia de entrega incremental para validar valor de negocio com baixo risco operacional.
7. Diretrizes de evolucao
- Integrar API com persistencia em banco relacional.
- Introduzir testes automatizados por jornada critica.
- Adicionar telemetria de uso e funil de conversao.
- Expandir camada administrativa com relatorios comparativos.
- Formalizar politicas de dados para conformidade ampliada.
8. Ambientes e publicacao
| Ambiente | Finalidade | Artefato de validacao |
|---|---|---|
| Local de desenvolvimento | Implementacao e teste rapido | Build/lint sem erro |
| Producao aplicacao | Demonstracao funcional publica | URL HTTP 200 e fluxo E2E valido |
| Producao documentacao | Biblioteca tecnica da banca | Pages atualizado e links navegaveis |
9. Runbook resumido de operacao
- Confirmar estado do repositorio alvo e branch principal.
- Executar build do modulo alterado.
- Validar fluxo funcional impactado por checklist.
- Publicar alteracoes e registrar evidencias de release.
- Atualizar documento correspondente quando houver mudanca estrutural.
O runbook reduz dependencia de memoria individual e padroniza qualidade minima de publicacao.
10. Matriz de conformidade documental
| Artefato | Pergunta de conformidade | Status esperado |
|---|---|---|
| ERS | Requisitos estao atualizados com as entregas? | Sim, por release |
| Arquitetura | Modelo reflete componentes implementados? | Sim, por sprint |
| Plano de projeto | Riscos e marcos foram revisados? | Sim, em fechamento de sprint |
| Sprint review | Evidencias tecnicas estao anexadas? | Sim, em encerramento |
| Termos legais | Regras de dados e acesso permanecem coerentes? | Sim, em mudanca de processo |
11. Personas e drivers de decisao
| Persona | Contexto principal | Driver de decisao | Implicacao no sistema |
|---|---|---|---|
| Nutricionista parceira | Uso entre consultas e tarefas administrativas | Velocidade com seguranca | Formulario guiado e status claros |
| Paciente final | Acesso rapido via celular | Clareza e confianca | Leitura objetiva e checkout sem ruido |
| Operadora de cozinha | Ambiente sob pressao e alto volume | Escaneabilidade operacional | Fila por etapa e detalhes sem excesso |
| Gestora administrativa | Monitoramento e excecoes | Visao consolidada | Dashboard com filtros e rastreabilidade |
12. Regras de negocio consolidadas
- A marca da clinica e a identidade dominante na experiencia do paciente.
- Somente pedidos confirmados e pagos podem seguir para producao.
- Cada pedido precisa ter codigo unico e historico de mudanca recuperavel.
- Status operacionais precisam respeitar ordem logica de execucao.
- Dados visiveis devem ser proporcionais ao papel do usuario autenticado.
13. Matriz de evidencia por repositorio
| Repositorio | Evidencia principal | Uso na avaliacao |
|---|---|---|
| front | Jornadas publicas e modulos por perfil | Demonstracao funcional ao vivo |
| back | Base de API e evolucao de dominio | Comprovacao de prontidao arquitetural |
| docs | Artefatos tecnicos, legais e de projeto | Auditoria academica e rastreabilidade |
| org-profile | Contexto institucional do produto | Apoio de posicionamento e governanca |
14. Prioridades do proximo ciclo
- Migrar persistencia local para arquitetura com API e banco relacional.
- Formalizar criterios de permissao e sessao por perfil.
- Adicionar suite minima de testes de regressao por jornada critica.
- Consolidar relatorios administrativos com visao financeira e operacional.