Título sugerido Dev full-stack / data (GCP) para implementar com Cursor a partir de arquitetura já definida Sobre o projeto Estou construindo um ecossistema de dados e uma aplicação interna de cotação (revenda de informática), em brownfield - ou seja, já existem repositórios, pipelines e documentação parcial; o trabalho continua a partir desse estado. A arquitetura e o escopo são definidos (ou em fechamento). A documentação atual é praticamente agent-executable: C4, ADRs (registros de decisão), planos de execução e contratos de verificação - com precisão suficiente para um agente de IA implementar sem 'adivinhar' a intenção. Se surgirem considerações sobre a arquitetura, sempre podemos conversar a respeito. No entanto, já está majoritariamente definida. O papel principal do dev é: - Ler e seguir os entregáveis aceitos (escopo, ADRs, C4, plano de execução, contratos de teste/assurance). - Coordenar o Cursor (agente de IA no IDE) para implementar, testar, abrir PRs e manter o git limpo. - Validar o resultado prático (código, deploys, testes, logs) e sinalizar quando a implementação exigir revisão de ADR - nunca divergir em silêncio. Se você já usa Cursor (ou ferramenta equivalente) no dia a dia e sabe quando o agente acertou vs. quando inventou, você é o perfil certo. Não precisa ser 'arquiteto sênior de papel'; precisa entender o suficiente dos conceitos abaixo para dirigir o agente com segurança. Principais repositórios envolvidos - Repo 1 (infra GCP centralizada) Documentação 'espelho' do que existe na GCP (não aplica IaC hoje). Fonte de verdade de topologia, IAM, padrões (região, WIF, etc.). - Repo 2 (ingestão de dados) Pipeline Python: FTP/SFTP - normalização - GCS - landing no BigQuery (raw_vault). Cloud Run Job, Pub/Sub, CI/CD. - Repo 3 (pipeline de dados) Transformação no BigQuery com Dataform: raw_vault - Data Vault - Business Vault - curated. - Repo 4 (front-end de catálogo) App interno de cotações (catálogo + cotação): monorepo Next.js. Há acoplamento claro entre eles (ex.: ingestion alimenta raw_vault; pipeline modela o warehouse; o app consome camadas curated). Trabalhar bem significa respeitar limites de repo e contratos entre camadas. O que você vai fazer no dia a dia - Implementar features / pipelines / configs conforme ADRs e plano de execução já aceitos. - Configurar e usar regras, skills e fluxo Git no Cursor (branches feature/* a partir de develop, commits atômicos, PRs, CI verde). - Executar e endurecer testes alinhados ao contrato de verification & continuous assurance (evidência por caminho crítico - não só 'unit tests passaram'). - Atualizar docs/runtime JSON quando a GCP mudar (especialmente no modelo slave doc vs. configs de runtime nos repos de app). - Comunicar bloqueios: decisão de negócio vs. detalhe técnico vs. possível supersessão de ADR. Tecnologias e conceitos (o que precisa conhecer) Must-have (bom desempenho sem isso fica difícil) - Cursor / AI-assisted coding (foco principal) Coordenar agente: prompts com escopo, validar diffs, rejeitar inventações, pedir testes/execução. Familiaridade com rules (.cursor/rules), skills, AGENTS.md, e fluxo de PR/CI com agente. Prático: você não precisa escrever tudo à mão; precisa saber o que pedir, o que revisar e quando parar o agente. - Git / GitHub (git-flow enxuto) Branch de integração: develop; produção: main. Trabalho em feature/* (ou fix/*, docs/*); PR -> develop; sem push direto em main/develop. Commits atômicos e mensagens claras (feat:, fix:, docs:, etc.). - Google Cloud (nível operacional, não 'arquiteto GCP') Projetos, regiões, Service Accounts, IAM básico. Cloud Run (Jobs e Services), GCS, Pub/Sub, BigQuery, Artifact Registry. Autenticação moderna: Workload Identity Federation (WIF) com GitHub Actions (sem chaves JSON de SA - política da org). gcloud / Console para verificar o que está live. Prático: deploy, smoke, ler logs, não 'inventar' buckets/SAs que não existem. - Python (data ingestion / serviços Cloud Run) Scripts de pipeline, configs JSON, packaging/container, testes. Prático: evoluir stages FTP->GCS->BQ e jobs de deploy sem quebrar contratos de arquivo/schema. - SQL / BigQuery + noção de Dataform SQL analítico, datasets/tabelas, cargas. Ideia de Dataform (SQLX, assertions, orquestração no BQ). Prático: materializar camadas modeladas a partir de raw_vault sem reimplementar ingestão no repo errado. - Noção de modelagem Data Vault (leve) Hubs / Links / Satellites, hash keys, histórico, business key. Prático: seguir specs YAML/docs; não precisa ser consultor DV - precisa não corromper o modelo. - TypeScript / Next.js (app catálogo front end) App Router, módulos por domínio, Server Actions / camada server. Stack típica: React, Prisma, Zod, Tailwind/shadcn, TanStack Query, Zustand; E2E com Playwright. Prático: features de catálogo/cotação dentro da estrutura de pastas já definida, sem reinventar o monorepo. A arquitetura do front-end ainda está pa