Achei Meu Pet

Plataforma web comunitária para reunir animais perdidos com seus donos, usando a própria vizinhança como rede de busca — pensada para o Mato Grosso do Sul e desenhada mobile-first, para quem cadastra na rua, com uma mão e pressa.

Projeto full-stack completo (backend geoespacial, SPA, infra, CI e testes), construído do zero em sprints. A visão, o modelo de dados e o detalhamento de cada sprint estão em PLANO_ACHEI_MEU_PET.md.

---

O problema e o objetivo

Quando um animal some, o tempo é tudo — e a informação está fragmentada em dezenas de grupos de WhatsApp. O Achei Meu Pet centraliza isso num feed regional e tenta fechar o ciclo perdido → encontrado com o mínimo de fricção.

A métrica-norte (North Star) do produto é o tempo médio até o primeiro contato qualificado: quanto tempo, depois de um pet ser publicado, até alguém abrir uma conversa sobre ele. O sistema instrumenta essa métrica de ponta a ponta.

Princípios de produto (inegociáveis)

1. Ver antes de cadastrar — o visitante anônimo vê o feed na hora, sem login.
2. Login só onde há razão técnica — exigido para publicar (filtro regional, throttling, responsabilização), nunca como pedágio.
3. Privacidade por padrão — o endereço do usuário nunca é exposto; localização de pets é sempre aproximada.
4. Clareza acima de completude — cada tela tem um trabalho só.

---

Principais funcionalidades

• Feed público regional — qualquer pessoa vê animais encontrados perto de si, sem login, filtrando por raio real (km) e por tipo (perdidos / encontrados / todos).
• Publicação de perdidos e encontrados — 1–6 fotos, espécie, porte, cores, sexo, data, situação e localização aproximada, com upload resiliente.
• Match automático geoespacial — publicar um perdido dispara, em background, a comparação com os encontrados compatíveis na região e notifica o dono.
• “Reconheci este animal” → contato intermediado — abre uma conversa sem expor telefone/e-mail de nenhuma das partes.
• Cartaz com QR Code — gera um cartaz (PDF/PNG) do pet perdido para impressão e compartilhamento, com QR apontando para a página pública (sem contato pessoal).
• Compartilhamento para WhatsApp com card rico (Open Graph).
• Alertas regionais — o usuário define um raio e é avisado de novos animais na sua área (com opt-out).
• Ciclo de vida do post — status (ativo/resolvido/expirado), expiração automática em 30 dias com avisos em D-3/D-1 e renovação em 1 clique.
• Perfil completo + LGPD — meus posts, notificações, preferências, exportação e exclusão de dados.

---

Destaques de engenharia

O que torna o projeto interessante além da lista de telas:

🔒 Privacidade por design (não como recurso, como arquitetura)

• A coordenada real de um pet e o endereço do usuário ficam em campos que a API pública nunca serializa — só o rótulo aproximado (bairro) sai.
• EXIF removido de toda foto no upload (a imagem é re-encodada), então o GPS embutido na câmera nunca vaza.
• Contato sempre intermediado — mensageria interna, mitigando o golpe clássico do “achei seu pet”. E-mail/telefone são redigidos automaticamente nas mensagens.
• Testes de segurança dedicados garantem essas invariantes (IDOR, vazamento de PII, upload malicioso) e rodam no CI a cada push.

🗺️ Geoespacial de verdade (PostGIS, não cálculo no app)

• Filtro por raio com ST_DWithin sobre coluna geography indexada (GIST) — comparação em metros, sem trazer a tabela inteira para a aplicação.
• Heurística de matching com score (espécie + porte + janela de datas + sobreposição de cores + distância), persistida e idempotente (não re-notifica o mesmo par), rodando assíncrona no Celery.

🎨 Identidade com intenção

• O contador “X dias procurando”, em âmbar, é o elemento de assinatura: ele transforma um dado frio (data do sumiço) em tensão que move a comunidade.
• Decisão de cor justificada: urgência em âmbar/terracota, nunca vermelho (vermelho amplifica pânico); verde reservado só para resolução.

🛡️ Decisões de stack defensáveis

• Auth por sessão (cookie httpOnly + SameSite + CSRF) em vez de JWT no localStorage — imune a roubo de token por XSS.
• Sem SSR/Next.js: o único caso que exigiria SSR (cards Open Graph do WhatsApp) é resolvido por um endpoint dedicado que server-renderiza só as meta tags.
• Cloudflare R2 para imagens (sem egress fee), via interface S3-compatível.

📈 Observabilidade e operação

• Métrica North Star instrumentada (persistida por pet + endpoint agregado + log).
• Healthcheck (banco + Redis), logs estruturados em JSON opcionais, integração com Sentry, backup do Postgres com runbook de restauração testado.

✅ Qualidade levada a sério

• ~95 testes de backend (regras de negócio, autorização, segurança) + testes de frontend (componentes, acessibilidade com axe).
• E2E (Playwright) dos fluxos críticos e teste de carga (k6) do feed e da publicação, com thresholds de latência/erro.
• CI (GitHub Actions) com lint, format, testes e build obrigatórios.

---

Stack e arquitetura

Camada	Tecnologia
Backend	Django 5 + DRF + GeoDjango/PostGIS (Python 3.12)
Banco	PostgreSQL 16 + PostGIS
Frontend	React 19 + Vite + TypeScript, Tailwind v4, shadcn/ui
Assíncrono	Celery + Redis (matching, e-mails, expiração)
Storage	Cloudflare R2 (S3-compatível)
Edge	Caddy (TLS automático, reverse proxy, headers de segurança/CSP)
Infra	Docker Compose (single-host)
CI / Erros	GitHub Actions · Sentry

                 Internet
                    │
                 ┌──┴──┐
                 │Caddy│  TLS automático, reverse proxy, CSP
                 └──┬──┘
        ┌───────────┼───────────────┐
   app (SPA estático)        api (Django/gunicorn)
                                   │
                  ┌────────────────┼─────────────────┐
            PostgreSQL+PostGIS   Redis        Celery worker + beat
                                   │
                          Cloudflare R2 (imagens)

Modelo de dados (resumo)

User (com localizacao/endereco privados) · Pet + PetFoto (UUID, coordenada real indexada vs. rótulo exibível) · Match (auditável) · Conversa + Mensagem (contato intermediado) · Notificacao · PrimeiroContato (North Star). Detalhes no plano.

---

Estrutura do repositório

backend/    Django + DRF (API, settings base/dev/prod, Celery, ~95 testes)
frontend/   React 19 + Vite SPA (Tailwind v4, tokens de design, Playwright e2e)
infra/      Caddy (edge), backup/restore do Postgres, testes de carga k6
.github/    GitHub Actions (CI + E2E manual)

---

Rodando localmente

Pré-requisitos

Docker + Docker Compose, ou Python 3.12 + Node 24 para rodar fora de container.

Demonstração rápida (recomendado)

Sobe a stack completa em modo de desenvolvimento (HTTP puro, hot-reload, sem TLS) já populada com dados de exemplo — nenhum .env necessário:

docker compose -f docker-compose.local.yml up --build

• App: http://localhost:5173
• API health: http://localhost:8000/api/health · Admin: http://localhost:8000/admin

Na subida, o comando manage.py seed_demo cria usuários, posts de perdidos e encontrados (com fotos geradas), matches, notificações e uma conversa intermediada. Login sugerido para explorar tudo:

e-mail	senha
ana@demo.acheimeu.pet	demoAcheiPet1

O seed é idempotente: rode docker compose -f docker-compose.local.yml exec api python manage.py seed_demo quando quiser recriar os dados. E-mails (ex.: verificação, match) saem no console do container api.

Produção (Docker + Caddy/TLS)

cp backend/.env.example backend/.env   # ajuste SECRET_KEY etc.
cp .env.example .env
docker compose --env-file backend/.env up --build

• App: http://localhost
• API health: http://localhost:8080/api/health

Backend sem Docker

cd backend
python -m venv .venv && . .venv/Scripts/activate   # Windows
pip install -r requirements-dev.txt
cp .env.example .env
python manage.py migrate
python manage.py runserver        # http://localhost:8000/api/health

GeoDjango exige as libs GDAL/GEOS/PROJ instaladas no sistema.

Frontend sem Docker

cd frontend
npm install
npm run dev        # http://localhost:5173 (proxy /api -> :8000)

---

Testes e qualidade

# Backend
cd backend && pytest && ruff check . && black --check .

# Frontend (unit + componentes + acessibilidade)
cd frontend && npm test && npm run lint && npm run build

• E2E (Playwright) — fluxos críticos ponta a ponta: veja frontend/e2e/README.md.
• Carga (k6) — feed e publicação com thresholds: veja infra/load/README.md.

.github/workflows/ci.yml roda em cada push/PR (lint, testes, build). Os testes E2E rodam sob demanda em .github/workflows/e2e.yml. Nenhum merge sem CI verde.

---

Observabilidade e LGPD

• Healthcheck: GET /api/health (banco + cache/Redis).
• North Star (tempo até o primeiro contato qualificado): GET /api/metrics/north-star (staff) + log estruturado. Logs em JSON via LOG_FORMAT=json.
• Exportação de dados: GET /api/auth/me/exportar. Exclusão: DELETE /api/auth/me.
• Política de privacidade na rota /privacidade, linkada do cadastro.

---

Roadmap (pós-MVP)

Camada de IA, sempre como assistente e nunca como autoridade em casos sensíveis: moderação de imagens/texto com revisão humana, similaridade visual por embeddings, coleira QR preventiva, parceiros verificados (clínicas/ONGs) e mapa interativo com pontos ofuscados por jitter. Detalhes na §10 do plano.

---

Backup, restore e segredos

Scripts em infra/backup/; o procedimento de restauração — que deve ser testado, não só configurado — está em RESTORE_RUNBOOK.md. Nunca commitar .env; veja *.env.example para a lista de variáveis.

Buraco Zero

Plataforma colaborativa para mapear e gerir o conserto de buracos em vias públicas — do relato anônimo do cidadão à confirmação do conserto pela prefeitura, com transparência pública. Caso de uso: Campo Grande/MS.

Stack: Django 5 · DRF · GeoDjango/PostGIS · React 18 · Vite · MapLibre · Docker Qualidade: 141 testes automatizados (96 backend / 45 frontend) · revisão de segurança §9/OWASP · CI-ready Status: MVP completo (Sprints 0–7) · pronto para deploy

---

🖼️ Interface

Identidade visual “asfalto” — grafite escuro + âmbar de marca (Tailwind v4 + shadcn/ui). O app do cidadão é mobile-first: mapa em tela cheia, pins por forma + cor segundo o status, e relato de baixo atrito — posicionar o pino e confirmar.

  

_{Cidadão — mapa com clusters por status · arraste o pino até o buraco e confirme.}

Painel da prefeitura (desktop), com a visão certa por papel:

Gestão — mapa, filtros e lista priorizada por urgência.

Conserto com staging — polígono, rua ou clusters → revisão.

_{Login da prefeitura — acesso restrito por papel (JWT).}

_{Capturas da stack de demonstração (compose.local.yml) com dados de exemplo em Campo Grande/MS.}

---

🎯 O problema

Buracos em vias públicas são reportados de forma dispersa (redes sociais, telefone, ouvidoria), sem geolocalização agregada. A prefeitura não tem um canal único para visualizar, priorizar e acompanhar consertos. O Buraco Zero centraliza esse ciclo de vida em uma plataforma só, com três públicos:

Público	O que faz
👤 Cidadão (anônimo)	Registra um buraco em < 15s, sem cadastro (UX referência: alerta do Waze). Foto opcional.
📊 Analista (prefeitura)	Prioriza por urgência, filtra, avança status, exporta dados.
🛠️ Funcionário de campo	Marca consertos (polígono/rua/clusters), revisa e confirma em lote.
🌐 População	Painel público de transparência (consertos, tempo médio, por bairro).

---

🚀 Demo local em um comando

Pré-requisito: Docker + Docker Compose. Na raiz do repositório:

docker compose -f compose.local.yml up --build

Sobe a stack inteira (PostGIS + Django + PWA atrás do nginx), migra o banco e popula dados de demonstração automaticamente. Depois abra:

👉 http://localhost:8080

Rota	O que ver
/	App do cidadão: mapa com clusters coloridos por status, botão “Relatar buraco”.
/painel	Transparência: métricas e recorte por bairro.
/admin	Painel da prefeitura (login abaixo).

Credenciais de demonstração (papéis distintos mudam a experiência):

Papel	Login	Senha	Vê
Admin	admin@cg.ms.gov.br	demo12345	gestão + conserto + arquivar
Analista	analista@cg.ms.gov.br	demo12345	mapa, lista, filtros, status, exportar
Campo	campo@cg.ms.gov.br	demo12345	conserto com staging (3 métodos)

Encerrar: docker compose -f compose.local.yml down -v.

Diferente do backend/docker-compose.yml (só backend, para desenvolvimento), o compose.local.yml entrega o sistema completo em uma URL, como em produção, mas sem TLS e com dados de exemplo.

---

✨ Funcionalidades

• Registro de baixa fricção — o relato é persistido no instante da confirmação; a foto é um enriquecimento assíncrono que nunca bloqueia o fluxo crítico.
• Deduplicação geoespacial — relatos do mesmo buraco (dentro de um raio) viram um único cluster, a unidade de gestão da prefeitura. Query PostGIS com índice espacial, não cálculo em Python.
• Clustering visual — Supercluster agrupa pins por zoom, mantendo o mapa legível.
• Máquina de status com transições validadas no servidor e histórico imutável (base das métricas de SLA).
• Conserto com staging — o funcionário acumula consertos como rascunho, revisa (clusters em verde) e confirma; só então fecham, em uma transação atômica e idempotente. Três métodos: desenho de polígono, rua e seleção de clusters.
• Transparência pública — total de consertos, tempo médio de resolução, consertos nos últimos 30 dias e recorte por bairro.
• Exportação CSV/GeoJSON e arquivamento em lote de relatos expirados.
• PWA instalável, com cache do último estado do mapa para visualização offline.

---

🧠 Destaques de engenharia

O que este projeto demonstra além de CRUD:

• Geoespacial de verdade: GeoDjango + PostGIS com distance_lte/intersects sobre campos geography, índice GIST, e testes rodando contra PostGIS real (não SQLite — queries espaciais não têm equivalente e dariam falso verde).
• Modelagem orientada ao domínio: o cluster (não o relato) é a entidade central; StatusHistory é append-only; MaintenanceZone nasce como rascunho.
• Integridade transacional: o commit de consertos é tudo-ou-nada e idempotente (cluster já fechado entre o rascunho e o commit é ignorado sem erro) — coberto por teste que simula falha no meio e verifica o rollback.
• Segurança desde o primeiro commit: rate limiting no endpoint anônimo, hash salgado de IP (LGPD), strip de EXIF nas fotos, JWT por papel com lockout no login, headers seguros e uma revisão §9/OWASP. Cada feature tem teste de permissão (401/403) e de caminho de abuso.
• Testes como contrato: 141 testes cobrindo dedup, transições, staging, auth, filtros e os caminhos de risco — não cobertura cega.
• Acessibilidade: status indicado por forma + cor (não só cor), alvos de toque de 44px, contraste WCAG AA, prefers-reduced-motion.

Um bug real encontrado e corrigido durante o desenvolvimento: o ?format= do endpoint de exportação colidia com a negociação de conteúdo do DRF, devolvendo 404 antes da view rodar — resolvido com URL_FORMAT_OVERRIDE=None. Documentado no código.

---

🏗️ Arquitetura

                    ┌─────────────────────────── nginx ───────────────────────────┐
   Cidadão ─────────│  /            → PWA (React/Vite, estático)                    │
   Prefeitura ──────│  /api, /admin → proxy → gunicorn + Django/DRF                 │
                    │  /static,/media → volumes                                    │
                    └───────────────────────────────┬──────────────────────────────┘
                                                     │
                                       ┌─────────────▼─────────────┐
                                       │   Django + GeoDjango       │
                                       │   (dedup, staging, auth,   │
                                       │    stats, jobs de cron)    │
                                       └─────────────┬─────────────┘
                                                     │
                                       ┌─────────────▼─────────────┐
                                       │   PostgreSQL 16 + PostGIS  │
                                       └───────────────────────────┘

Decisões registradas em DOCUMENTACAO_SISTEMA.md (a fonte de verdade do produto): por que cluster é a entidade central, dedup em duas camadas, staging no servidor, expiração como flag visual, e mais.

---

🧩 Stack e estrutura

Camada	Tecnologias
Backend	Django 5, DRF, GeoDjango, simplejwt, django-ratelimit, Pillow
Banco	PostgreSQL 16 + PostGIS 3.4
Frontend	React 18, Vite, TypeScript, Tailwind v4, shadcn/ui, MapLibre GL, Supercluster, TanStack Query
Infra	Docker Compose, nginx, gunicorn, Let’s Encrypt, Sentry (opcional)
Testes	pytest + pytest-django (PostGIS real), Vitest + Testing Library, Locust

tapa-buraco/
├── backend/         Django + DRF + GeoDjango (API, painel, staging, jobs)
├── frontend/        PWA React (cidadão, analista, campo, painel público)
├── deploy/          produção: nginx+TLS, gunicorn, backups, Let's Encrypt
├── loadtest/        teste de carga (Locust) da superfície pública
├── compose.local.yml          demo da stack completa (este README)
├── DEPLOY.md                  guia de deploy e operação
├── SECURITY_REVIEW.md         revisão §9 + OWASP Top 10
└── DOCUMENTACAO_SISTEMA.md    especificação do produto (fonte de verdade)

---

🛠️ Desenvolvimento

# Backend (roda via Docker por causa do GeoDjango/GDAL)
cd backend && cp .env.example .env && docker compose up -d --build
docker compose run --rm web pytest            # 96 testes (PostGIS real)

# Frontend
cd frontend && npm install && npm run dev      # http://localhost:5173
npm test                                       # 45 testes

Detalhes em backend/README.md e frontend/README.md.

---

🚢 Produção

Deploy num VPS único via Docker Compose (nginx + TLS + gunicorn + PostGIS + backups + Sentry) — passo a passo em DEPLOY.md. Segurança em SECURITY_REVIEW.md. Teste de carga em loadtest/.

---

🗺️ Roadmap (entregue por sprints)

Sprint	Entrega	Status
0–1	Fundação + API pública de relatos (dedup geoespacial, EXIF strip)	✅
2	Frontend do cidadão (mapa + relato) PWA	✅
3	Auth JWT + API admin (filtros, paginação, transições)	✅
4	Painel do analista (mapa + lista + filtros + detalhe + status)	✅
5	Conserto com staging (polígono/rua/clusters → revisão → commit)	✅
6	Exportação, painel público e expiração (jobs via cron)	✅
7	Endurecimento e deploy (TLS, backups, Sentry, carga, docs)	✅
5.5	Importação CSV de consertos (opcional; depende de OSM + pg_trgm)	⏳

---

_{Projeto desenvolvido como estudo de uma plataforma cívica real, priorizando domínio geoespacial, integridade transacional, segurança e testes. Construído por sprints, cada uma entregando algo verificável e testado.}

Portal de Clientes - Agência de Marketing

Plataforma SaaS white-label para agências de marketing digital gerenciarem clientes, entregas, finanças e resultados, em um único lugar.

---

📌 Sobre o projeto

O Portal de Clientes é um sistema web desenvolvido em Laravel 11 para centralizar a gestão de clientes de uma agência de marketing digital. Ele oferece dois ambientes distintos: um painel administrativo para a equipe da agência e um portal exclusivo para os clientes.

A plataforma conecta-se à conta Google da agência para sincronizar automaticamente eventos de reuniões e entregas, permite o envio de relatórios mensais de performance com dados reais de campanhas e redes sociais, e oferece uma área financeira completa com geração de cobranças, QR Code PIX e controle de inadimplência.

---

✨ Funcionalidades

🔐 Acesso e Permissões

• Sistema de autenticação com múltiplos perfis: super_admin, admin e client
• Controle de permissões granular via Spatie Laravel Permission
• Suporte a múltiplos usuários por empresa-cliente, cada um com acesso controlado à sua conta
• Proteção anti-IDOR com UUIDs em todas as rotas de recursos sensíveis
• Soft delete em usuários, clientes e registros financeiros

🗓️ Integração com Google Agenda

• OAuth 2.0 com a conta Google da agência
• Sincronização automática a cada 5 minutos via Laravel Scheduler + Cron Job
• Eventos baixados e armazenados localmente para exibição no portal do cliente
• Filtro inteligente de eventos por nome da empresa (case-insensitive)
• Cada cliente vê apenas os eventos relevantes à sua conta

📊 Relatórios de Performance

• Relatórios mensais com dados de tráfego pago, Instagram e metas
• Campos disponíveis: investimento, faturamento, CPC, conversas, alcance, publicações, novos seguidores, views, visitas ao perfil
• Cálculo automático de ROI (coluna gerada no banco)
• Controle de versões do relatório com histórico de alterações
• Fluxo de publicação em etapas: rascunho → publicado → arquivado
• Exportação em PDF via DomPDF
• Navegação por mês de referência diretamente no portal

💰 Gestão Financeira

• Cadastro de notas fiscais (Invoice) e cobranças individuais (Payment)
• Pagamentos com suporte a QR Code PIX gerado dinamicamente
• Status de pagamento: pending, under_review, paid, overdue
• Botão “Já paguei” no portal do cliente para notificar a agência sem precisar contato
• Marcação automática de pagamentos vencidos diariamente (via Scheduler)
• Painel administrativo com visão consolidada de inadimplência

📁 Biblioteca de Mídia (Google Drive)

• Links de entregáveis organizados por cliente, mês e ano
• Suporte a tipos de conteúdo: video, image, document, link
• Controle de visibilidade pública/privada por item
• Integrado ao portal do cliente para visualização de entregas

⚙️ Painel Administrativo

• CRUD completo de clientes com dados: razão social, CNPJ, e-mail, telefone, endereço, vigência de contrato e mensalidade
• Gerenciamento de usuários e permissões por cliente
• Dashboard com visão geral de clientes ativos, pagamentos e relatórios
• Configurações globais do sistema (aparência, textos, comportamentos)
• Logs de auditoria de ações críticas

---

💻 Telas do Sistema (algumas para exemplo)

Dashboard do Cliente	Calendário de Eventos
Gestão de Pagamentos	Configurações (Painel Admin)

---

🏗️ Arquitetura

O projeto segue uma arquitetura organizada em domains, separando as responsabilidades por contexto de negócio:

app/
├── Console/
│   └── Commands/
│       └── SyncCalendarCommand.php   # Comando artisan: calendar:sync
├── Domain/
│   ├── Calendar/     # Integração com Google Agenda
│   ├── Client/       # Gestão de clientes
│   ├── Financial/    # Pagamentos e faturas
│   ├── Media/        # Links de entregáveis
│   ├── Report/       # Relatórios de performance
│   └── Setting/      # Configurações do sistema
├── Http/
│   ├── Controllers/
│   │   ├── Admin/    # Controllers do painel da agência
│   │   └── Client/   # Controllers do portal do cliente
│   └── Middleware/
└── Models/           # User, GoogleOAuthToken, AuditLog

---

🛠️ Stack Tecnológica

Camada	Tecnologia
Backend	Laravel 11, PHP 8.2
Banco de dados	PostgreSQL
Frontend	Blade + Tailwind CSS
Permissões	Spatie Laravel Permission
Google APIs	google/apiclient (Calendar + Drive)
PDF	barryvdh/laravel-dompdf
QR Code PIX	chillerlan/php-qrcode
Ícones (UI)	Heroicons, Solar Icons, Remix Icons
Logs de atividade	Spatie Laravel Activitylog
Deploy	Hostinger (shared hosting)

---

🚀 Instalação local

Pré-requisitos

• PHP 8.2+
• Composer
• PostgreSQL
• Node.js + NPM

Passos

# Clone o repositório
git clone https://github.com/enzoterra/portal-agencia.git
cd portal-agencia

# Instale as dependências PHP
composer install

# Instale as dependências JS
npm install

# Configure o ambiente
cp .env.example .env
php artisan key:generate

# Rode as migrations
php artisan migrate --seed

# Inicie o servidor de desenvolvimento
composer run dev

Variáveis de ambiente necessárias

Configure as seguintes entradas no .env:

# Banco de dados
DB_CONNECTION=pgsql
DB_HOST=127.0.0.1
DB_PORT=5432
DB_DATABASE=portal_agencia
DB_USERNAME=seu_usuario
DB_PASSWORD=sua_senha

# Google OAuth
GOOGLE_CLIENT_ID=
GOOGLE_CLIENT_SECRET=
GOOGLE_REDIRECT_URI=
GOOGLE_CALENDAR_ID=

---

⏰ Tarefas Agendadas

O sistema depende de um Cron Job configurado no servidor para funcionar corretamente. Adicione a seguinte linha ao cron do servidor:

* * * * * /usr/bin/php /caminho/para/artisan schedule:run >> /dev/null 2>&1

O Laravel gerencia internamente os intervalos de cada tarefa:

Tarefa	Frequência	Descrição
calendar:sync	A cada 5 minutos	Sincroniza eventos do Google Agenda
Marcar vencidos	Diário às 00:05	Atualiza status de pagamentos vencidos

---

📄 Licença

Este projeto foi desenvolvido para uso interno e fins de portfólio.