Decisões — produto-cadencia-memory¶

ARQUIVO HISTÓRICO / LEGADO. Preservado para memória, auditoria e contexto de decisões. Não usar como documentação operacional atual.

Decisões — Squad Cadência¶

(append-only — decisões relevantes, mais recente em cima)

2026-07-03 — Ideia futura: Brave Search API como grounding externo para "Tenho uma ideia"¶

Contexto: conversa sobre browser de trabalho, Brave Browser, brave-search-mcp-server e Brave Search API. Felipe percebeu que a API e paga, mas apontou valor futuro para o Cadencia, especialmente na feature "Tenho uma ideia" e em outras funcoes que precisam de pesquisa/contexto externo.

Aprendizado registrado: - O MCP da Brave e gratuito/open-source como adaptador, mas depende da Brave Search API paga/creditada. - A API nao controla o navegador Brave; ela fornece busca estruturada para agentes. - Para agentes/chatbots, a doc oficial recomenda LLM Context em vez de Web Search quando o consumidor e o modelo. - llm_context traz conteudo pre-extraido com controle de tokens, URLs, freshness e threshold de relevancia. - web_search e news_search ficam melhores como descoberta/listagem de fontes. - answers fica fora de prioridade por custo e menor controle.

Decisao: registrar como ideia futura, sem integrar agora no core nem no produto. Se virar experimento, comecar pequeno e feature-flagged na feature "Tenho uma ideia" ou em pesquisa de pauta, com whitelist inicial brave_llm_context, brave_web_search, brave_news_search, quota/custo controlado e fontes auditaveis.

Guardrail de produto: nao expor "Brave", "MCP", "API" ou "grounding" na UI. Linguagem do usuario: buscar contexto/referencias para melhorar a ideia, mantendo a voz do tenant via SOUL.md.

Nota operacional: Felipe baixou o Brave para uso pessoal. Isso e separado da eventual integracao de produto.

Detalhe: nota completa em context/ideia-brave-search-api-tenho-uma-ideia-2026-07-03.md.

Quem decidiu: Felipe.

2026-07-02 — Google Fonts é enhancement, não dependência; dado legado se resolve no read-path; merge só rebase (G009)¶

Contexto: Sentry 7586124316 (slide 1 timeout) expôs cadeia de 3 bugs: @import de Google Fonts bloqueava o render Playwright (DEV-1021); TenantTheme(**dict) quebrava com chaves extras e derrubava TODO render pro template default silenciosamente (DEV-1096); 2 rows legadas de tenant_themes com nome de sub-preset no campo name anulavam PRESET_OVERRIDES e o carregamento de fontes (DEV-1098).

Decisão: 1. Render nunca depende do CDN do Google Fonts. Sucesso → woff2 inlinado em base64 (cache só de sucesso). Falha → o @import é REMOVIDO e o font-family fallback do template assume. Cache nunca guarda estado de falha. 2. Dado legado de tenant_themes se corrige na leitura, não no banco (resolve_preset_name) — a doc do theme-engine proíbe editar a tabela diretamente; recalcular via theme_agent mudaria o visual dos tenants sem pedido. 3. Merge no cadencia-app é exclusivamente "Rebase and merge" (G009 no CLAUDE.md do repo) — squash/merge-commit reautora o commit pro criador do PR e a Vercel Hobby bloqueia o deploy de produção.

Alternativas consideradas: manter @import em falha com timeout maior (rejeitado — só adia o timeout); recalcular themes legados via theme_agent (rejeitado — muda visual sem demanda); corrigir rows no banco (rejeitado — doc proíbe).

Impacto: pipeline de carrossel imune a instabilidade do CDN; 2 tenants legados voltam a ter preset base + tipografia corretos; validação em produção registrada nas issues (log Google Fonts inlined pela primeira vez em prod).

Quem decidiu: Felipe.

2026-07-01 — Provisionamento de tenant: fonte única cadencia-cli + provision_tenant.py; regra "ler doc antes de codar" institucionalizada¶

Contexto: Epic DEV-998. Prospects criados por caminhos paralelos (skill /criar-tenant-agencia com INSERT auth manual bugado; cadencia-cli esqueleto) nasciam quebrados (não logavam, presos no onboarding, sem canais/infra).

Decisão: 1. Criação de tenant tem fonte única: cadencia-cli tenants provision (auth via GoTrue Admin API, não INSERT manual) cria a base + current_phase='complete' + growth_channels, e ao final dispara provision_tenant.py na VPS (blog Vercel + email domain Resend + DNS). As skills (/cadencia-provisionar-tenant, /ativar-cliente) delegam a ele — nunca reimplementam. 2. Email pós-GHL: seinfeld/newsletter via Resend per-tenant (já existia, CAD-675/676); gate ghlDependent no trigger-generation passou a olhar email_provider. LinkedIn gera sem GHL (publicação nativa fica na épica DEV-844/Composio). 3. Regra dura "ler a doc do componente ANTES de codar/debugar" institucionalizada em 7 lugares (CLAUDE global, AGENTS.md, DEV-WORKFLOW §3, code-principles §0, manual A21, hook userprompt-read-docs-first.py, CLAUDE.md do Luiz).

Alternativas consideradas: reimplementar blog/email/visual no cadencia-cli (descartado — já existe em provision_tenant.py); publicar LinkedIn via caminho próprio agora (descartado — é a épica Composio DEV-844).

Impacto: todo tenant novo nasce 100% (login + dashboard + carrossel + blog + email domain), sem data fix manual. Skills de provisionamento viram orquestradoras finas. Anti-padrão de ignorar doc agora tem enforcement mecânico (hook).

Quem decidiu: Felipe (+ execução Vitor/Amélia via cascata).

2026-06-24 (noite) — Épica DEV-844: Integração Social via Composio (V1 = IG + LinkedIn, TikTok adiado)¶

Contexto: Cadencia precisa de auto-publish e botão "Postar agora" em redes sociais. Auto-publish do Instagram existia via GHL (motor legado em sunset). LinkedIn/TikTok/Facebook nunca tiveram publish. Decisão de produto: substituir tudo por Composio nativo.

Decisão: criar épica DEV-844 com 10 sub-issues organizadas em 3 fases (A fundação, B superfície, C hardening) + 2 V2 (webhook, histórico). V1 entrega só Instagram + LinkedIn. TikTok (DEV-848) cancelada.

Subdecisões: - TikTok adiado: sem audit aprovada do app TikTok (processo de 2-4 semanas — privacy policy + demo), Direct Post vira privacy=SELF_ONLY (privado). Reabrir DEV-848 quando audit submetida. - LinkedIn só perfil pessoal cadastrado: scope w_member_social, sem Company Page V1. - LinkedIn OAuth = Composio managed default: aceito risco de 429 com volume alto; migrar pra OAuth app própria do Cadencia (LinkedIn Developer) só sob demanda. - Instagram exige conta Business OU Creator — restrição da plataforma, contas pessoais rejeitadas no OAuth. UI deve avisar. - Stack Composio: Native Tools SDK (@composio/core) + Direct Execution. Sem MCP, sem provider framework. ADR-CRM-006 (= ADR-0013 no cadencia-app/docs/adr/). - Schema: uma tabela social_integrations cobre as 3 redes via UNIQUE(tenant_id, provider). user_id Composio = tenant_id. composio_connected_account_id é a chave operacional. - Gate isGrowth REMOVIDO na tab Integrações do perfil — Cadencia é credit-only, sem separação por plano.

Alternativas consideradas: - (a) Manter OAuth por rede direto (Meta/LinkedIn/TikTok SDK) — descartado pela complexidade de manter 3 fluxos de refresh + secrets + quirks. Composio abstrai. - (b) TikTok via Inbox/Drafts — descartado por Felipe ("se a pessoa escolheu postar, tem que postar") + impossibilidade de mudar UX depois sem quebrar contrato. - (c) MCP em vez de Direct Execution — descartado por overhead de tokens (55k+) e latência sem ganho, já que não há LLM no loop de publish. - (d) Toolkit separado pra LinkedIn pessoal vs Company — falso problema: Composio expõe um único toolkit LINKEDIN, distinção via URN.

Impacto: - 9 branches feature/dev-XXX no cadencia-app aguardando código (A1 já tem commit, resto vazias). - Wrapper src/lib/composio.ts é fundação pra todas as publicações; refator pra Sessions só se Cadencia adicionar agente conversacional sobre publish depois. - Rate limit por rede vira tarefa concreta (DEV-858): IG 25/24h, LinkedIn 50/dia/perfil, TikTok 5/dia (quando voltar). - channels_published (DEV-853) deixa de ter flags inconsistentes (fix do bug histórico DEV-476).

Quem decidiu: Felipe. Detalhe: docs reais Composio lidas via WebFetch (docs.composio.dev/toolkits/{instagram,linkedin,tiktok}); foundation em times/dev/foundation/composio-api.md; planos persistidos em times/produto/cadencia/context/plano-DEV-{845-858}.md.

2026-06-24 — DEV-582 cancelada: HMAC/token de serviço é desnecessário pro uso interno da CLI¶

Contexto: a cadencia-cli bloqueava ações com lógica de negócio (enrich, dispatch, carrossel) à espera da DEV-582 (endpoint público /api/v1/automations/move-card com HMAC + idempotency + rate-limit + token de serviço).

Decisão: cancelar a DEV-582. No cenário interno, segurança/acesso já vem do controle de acesso ao ambiente (a CLI herda o PAT Supabase + chave SSH do 1Password); Bearer/HMAC não adicionam segurança — só agregam com terceiros externos (MCP/API REST, sem prioridade). O único valor real — proteger a regra financeira do enrich (débito de crédito + API paga DataStone) — será uma Postgres RPC enrich_contact no Supabase, não um endpoint HMAC.

Alternativas consideradas: (a) implementar na VPS Master em vez de Vercel — válido (Vercel é só front), mas ainda assim o aparato HMAC é desnecessário pro interno; (b) Bearer token simples — descartado por ser redundante (mesmo cofre); (c) manter a issue como está — descartado (over-engineering para consumidor externo inexistente).

Impacto: camada MUTATION da CLI re-escopada (RPC Postgres futura, não token de serviço); build_dispatch_request HMAC é legado (DISPATCH real é SSH desde DEV-747). DEV-782 (enrich) e DEV-805 (dispatch) re-escopadas. Pendência: mapear se triggers de stage são Postgres trigger ou código, e onde vive o débito de crédito hoje.

Quem decidiu: Felipe. Detalhe: comentário na DEV-582 (Linear) + nota Obsidian Dev/Autenticacao de API - Bearer vs HMAC.

2026-06-23 — Tenant default = o tenant da empresa (CRM), não dogfooding¶

Contexto: A cadencia-cli e operações de CRM/conteúdo precisavam de um tenant default inequívoco. Havia confusão entre o tenant da empresa (CRM com leads) e tenants pessoais do Felipe.

Decisão: O tenant default de toda operação de CRM/conteúdo sem tenant explícito é o tenant da empresa 6bb2c1ba-7fb3-416a-b523-7c9561ea8db3 (slug felipe-salgueiro, ~7,6k contatos, owner felipe@cadencia.ia.br, gmail super_admin). Conteúdo pessoal do Felipe = 832cf6fe (felipeluissalgueiro). Registrado em _core/CADENCIA-CLI.md, times/produto/cadencia/CLAUDE.md, cadencia-cli/config/settings.py, memória do framework.

Alternativas consideradas: usar o tenant pessoal 832cf6fe como default — descartado (0 contatos, não é o CRM operado).

Impacto: qualquer agente/skill que opera CRM/conteúdo usa 6bb2c1ba por padrão (override via CADENCIA_TENANT_ID).

Quem decidiu: Felipe.

2026-06-23 — Unificação de perfil entre tenants pessoais (6bb2 → 832c)¶

Contexto: Felipe tinha dois tenants pessoais bagunçados — 6bb2c1ba (perfil rico/atual, 7,6k contatos) e 832cf6fe (perfil antigo/genérico, 42 posts, 0 contatos). Quis usar o 832cf6fe (login gmail) com o perfil bom do 6bb2c1ba.

Decisão: Copiar o perfil de identidade de conteúdo (config identidade + dossiê + 3 editorias + big5 + identidade visual) do 6bb2c1ba por cima do 832cf6fe, preservando integrações próprias do destino (blog/stripe/ghl/plano/whatsapp/logo) e mantendo os 42 posts/53 ideias. Editorias atualizadas in-place (preserva FKs das ideias). soul_md antigo removido. gmail virou owner do 832c (+ super_admin do 6bb2). Backup em C:\temp\backup_unify_832c_2026-06-23.json.

Alternativas consideradas: copiar config inteiro (descartado — schemas diferentes quebrariam integrações); delete+insert das editorias (descartado — FK das ideias).

Impacto: tenant 832cf6fe agora gera conteúdo com a identidade real do Felipe. CRM da empresa segue no 6bb2c1ba.

Quem decidiu: Felipe.

2026-06-23 — Seinfeld dispatch: <= hoje ao invés de = hoje (DEV-763)¶

Contexto: Tenant Alexandre Manhães onboardou com conteúdo gerado mas sem emails nos contatos (importação GHL/Linkia sem email). O --dispatch só buscava seinfeld_scheduled_at::date = hoje, então posts com datas passadas nunca eram despachados mesmo após emails chegarem.

Decisão: Query de dispatch passa a buscar <= hoje, com ORDER BY seinfeld_scheduled_at ASC e LIMIT 1. Retoma do post mais antigo pendente — 1 por dia — até zerar backlog. Não inunda a base.

Alternativas descartadas: (a) backfill manual a cada onboarding — não escala; (b) reagendar via --generate — só funciona para posts sem data, não para os já agendados no passado.

Impacto: Qualquer tenant que criou conteúdo antes de ter emails vai receber os posts em fila sequencial automaticamente. Fix em produção: cadencia-growth commit acb5d57, VPS Master /cadencia/pipeline/seinfeld_generate.py.

Quem decidiu: Felipe.

2026-06-23 — seed_tenant_crm nunca rodou para tenants antigos (DEV-762)¶

Contexto: Migration 20260619150000_pipelines_v2_seed.sql incluiu backfill mas com WHERE slug='nutricao' — só aplicou para o tenant do Felipe. Os outros 29 tenants ficaram sem os 4 pipelines obrigatórios do CRM (Geração de Demanda, Geração de Negócios, Nutrição, Ciclo de Vida do Cliente).

Decisão: Rodou seed_tenant_crm(p_tenant_id) manualmente para todos os 29 tenants via Management API. Provision novo já chama a função (não é bug de produção ativa — só afetou tenants criados antes da migration).

Impacto: Todos os tenants agora têm os 4 pipelines. Novos tenants provisionados a partir de CAD-676 já recebem corretamente.

Quem decidiu: Felipe.

2026-06-20 (parte 2) — Superfície de controle de email + timeline de eventos + decisões de produto¶

Decisões: - Master on/off de email por tenant (CAD-677): flag config.email_sending_enabled (default ligado). Quando off, a cadência pausa o step de email (não envia, não avança — retoma ao religar), em vez de pular. UI na aba Email de Configurações. - Configurações vira a casa do controle por-tenant: aba Email (domínio + toggle) é o padrão; metas do HUD (CAD-668) também vão pra Configurações (não na aba Oportunidades), em tenant_config.config.crm_goals (default 50/20/3/1). - Botão de email do card: mailto descartado (não faz nada sem cliente de email padrão). Fix definitivo = compositor no app via Resend (CAD-617) — cadencia-app não tem infra Resend hoje, é feature (key Vercel + rota + UI). Fica pra bloco focado. - Timeline do contato registra eventos de oportunidade: created/stage.changed/won/lost/discarded/deleted gravam em timeline_activities (não-crítico). Atribuição via actor_metadata.actor_type. "Agendamento de reunião" como evento próprio só com o calendário (CAD-585). - Touchpoints = esforço MANUAL: só os toques pelos botões do card (email/wa/call/ig/li → *.sent) contam no HUD; envios automáticos (cadence.step.sent) não. Mantido assim (placar de prospecção pessoal). Métricas precisas + metas editáveis = CAD-668. - CAD-588 (rollback GHL) cancelada por obsolescência: pós go-live não dá pra voltar dados pro GHL; rollback real = flags existentes + reativar subconta.

Convenção de deploy (reforço): deploy de prod só com autorização inline do Felipe (DEV-WORKFLOW §12.0b). PR dispensado no cadencia-growth/app. No cadencia-app (clone OneDrive compartilhado): stashar WIP de outro agente → branch off origin/master → merge → restaurar a branch dele.

Quem decidiu: Felipe.

2026-06-20 — Fix do go-live de email (403), subdomínio por tenant automatizado (CAD-676), GHL desligado no provision (CAD-683)¶

Contexto: sessão pra confirmar a entrega do cutover de email (do dia 19). Descoberto que o go-live do PD estava QUEBRADO: 0 emails entregues — todos 403 email.cadencia.app.br domain is not verified. O config.email_sender_address do PD apontava pra subdomínio nunca verificado no Resend (só cadencia.app.br raiz estava). O "validado end-to-end" do dia 19 não cobriu o caminho real do dispatch.

Decisões: - Modelo de domínio = subdomínio dedicado por tenant (não from-address no domínio compartilhado). Naming (Felipe): nome da empresa; se for nome de pessoa, as 2 primeiras palavras, stopwords PT dropadas, flat (<empresa>.cadencia.app.br). Colisão → sufixo -<tid6>. - Host de email ≠ apex do blog. O blog ocupa <slug>.cadencia.app.br (CNAME→Vercel); o email NÃO pode compartilhar o apex (CNAME captura TXT/MX → quebra SPF/DKIM). Por isso label próprio. - Provisão manual imediata de 6 subdomínios verificados (PD email, Grupo WGL wgl, Horus horus, Lab. Crescimento labcrescimento, Ariane arianefarrapo, Gustavo petinati) — destravou o PD. Os 5 (fora PD) têm 0 contatos → provisionados/prontos, enviam quando tiverem lista. Achado: só PD (7.661) e Nathalia (43) têm contatos; "14 tenants ativos com Seinfeld" do handoff era impreciso (Orsolon estava com 0). - RESEND_API_KEY da VPS gerencia domínios (não é send-only — GET/POST /domains = 200). O 403 era só sobre enviar de domínio não verificado. - CAD-676 fase 1 automatizada: provision_resend_email_domain() no provision_tenant.py faz tudo (Resend POST + DNS Cloudflare + verify + grava config). Gate anti-403: email_provider só flipa pra resend quando verified; pending → partial → retry recupera. Idempotente. Fase 2 (UI self-service) = CAD-681. - GHL desligado no provision (CAD-683): flag GHL_PROVISION_ENABLED (env, default OFF) gateia criação de sub-conta/usuário/pipeline GHL. Tenant novo nasce sem GHL. Fix correlato: should_retry_provisioning e o skip-guard respeitam o flag (senão re-provisionava tenant sem location_id até o cap de 3). Reversível. GHL em sync/scoring/dispatch fica como remoção separada (skipa sozinho sem location_id).

Impacto: PD destravado (cron 11h BRT envia de email.cadencia.app.br verificado). Todo tenant novo nasce GHL-free com email Resend próprio. Em produção: cadencia-growth main (deploy 48baed5→59cf4db→06570cb), cadencia-trigger.service reiniciado. Docs: cadencia-growth/docs/email-domain-provisioning.md. Review: GLM 5.2 (2 P1 reais pegos: gate de flip + retry loop).

Quem decidiu: Felipe.

2026-06-19 (noite) — Cutover de email pro Resend, WhatsApp oficial Meta, convenção de review GLM¶

Contexto: thread "desligar o GHL". Construído o motor de cadências e migrado o envio de email (Seinfeld+newsletter) do GHL pro Resend.

Decisão: - Email migra GHL→Resend por tenant, com warm-up. Flag config.email_provider (resend/ghl) sobrepõe o env global; config.email_warmup.stages editável (default 50→100→250→500→1000→∞). Priorização por score desc + toggle por lead contacts.auto_email_enabled. Go-live PD+Orsolon. - Arquitetura do motor = padrão do Luiz (cadencia-growth /cadencia/, script standalone + lib_api), NÃO cadencia-workers/APScheduler. "Falar a mesma língua." - WhatsApp: Stevo descartado (cobra por instância → custo escala com tenants + não-oficial). Direção: Meta Cloud API oficial (cliente paga Meta), broker possível Composio. CAD-579 repensada/bloqueada. - Convenção de review: GLM 5.2 primário + qwen3.7-max fallback (quando GLM não pega nada/dúvida). codex(gpt-4o) e claude-review REMOVIDOS — GLM 5.2 achou um P1 (cadência presa) que qwen+codex perderam. - Domínio: modelo final = subdomínio Cadência auto-provisionado por tenant (<slug>.cadencia.app.br, DNS via Cloudflare API + Resend Domains API) = reputação isolada. Compartilhado cadencia.app.br é interim (CAD-676).

Alternativas consideradas: flip global do default pra resend (descartado — domínio frio queima reputação); APScheduler in-process (descartado — 2 paradigmas + lock); Stevo (descartado — custo por instância).

Impacto: GHL aposentado no email do PD+Orsolon; rollout dos legados exige migrar GHL→CRM antes (14 ativos sem contatos no CRM). Reviews de todo o trabalho de produto passam a usar GLM 5.2.

Quem decidiu: Felipe.

2026-06-17 (tarde/noite) — Redesign CRM estilo Linear + schema de produtos/lifecycle/perda/campos personalizados¶

Contexto: após validar a pill Contatos e o épico Empresa na preview, Felipe pediu redesign completo do CRM (contatos/empresas) e várias features novas, validando item a item e acumulando ajustes.

Decisão: - Estética = estilo Linear (aprovada após benchmark): linhas de propriedade compactas ícone·label→valor 13px, abas texto+sublinhado roxo, cards flat sem sombra, badges sutis, seções colapsáveis. Spec canônica context/redesign-crm-ux-sofia.md (UX "Sofia"); componentes base cadencia-app/.../growth/_components/crm-ui.tsx. - Hierarquia: dados do cliente à ESQUERDA (principal), atividade à DIREITA. Linear inspira estética, não posição. - Campos enxugados (só genéricos): removidos ECuro/press_/Stripe/atividade-email-interna/cluster/score_ia/fit_icp + duplicatas de empresa no contato (~73→~18). - Entidades novas: Produtos (adquirido/interesse), contacts.lifecycle, motivo de perda (5 presets), custom_field_defs, papel socio. Migration 20260617130000 em prod. - Backfill: 658 empresas via CNPJ dos contatos + associações + Cliente p/ quem tem opp ganha. - Pipelines = funis reais do GHL* (22 stages) + re-sync das 1.440 opps. Setor/Porte = select.

Impacto: UI do CRM repaginada na branch cad-563 (preview); migrations+dados em prod. Falta: sócios-associação, criar campos personalizados, ajustes finos, merge p/ produção (após validação).

Quem decidiu: Felipe (validação iterativa) + Sofia (UX).

Refs: context/redesign-crm-ux-sofia.md · branch cad-563 commits acc939e→264151e · migrations 20260617100000/110000/120000/130000.

2026-06-17 (tarde) — Call H&Co/Itinco → catálogo de features padrão de mercado (19 issues)¶

Contexto: transcrição da call de vendas com Vanessa (H&Co/Itinco, ~1214 linhas) processada por agente de produto.

Decisão: foco em features padrão de mercado, não dores específicas. Tema central = motor de Campanhas Segmentadas por tipo de lead (CAD-618/619 P1). HubSpot bidirecional e multi-idioma = sob medida, fora do roadmap. 19 issues criadas (CAD-618→636) no Roadmap, cada uma com aviso /linear-planejar-issue.

Achado — overpromises na call (afirmados prontos, não existem): auto-tag por nicho · switcher multi-conta · auto-publish LinkedIn/TikTok/FB (só IG publica).

Quem decidiu: Felipe + agente de produto.

Refs: context/catalogo-features-call-hco-20260617.md · issues CAD-618→636.

2026-06-17 — Execução E1 CRM próprio: 5 stories em prod + ampliação migração + processo¶

Contexto: Felipe exigiu seguir o DEV-WORKFLOW à risca após eu atropelar (codei sem gate/review). Modo A + gate Vitor + /codex-review + /claude-review + validação no banco (BEGIN/ROLLBACK) + OK antes de aplicar + merge story→feature/crm-proprio→main.

Decisões/aprendizados: - Migrations aplicadas via Management API SQL direto (BEGIN/COMMIT), NÃO supabase db push — supabase_migrations.schema_migrations remoto congelou em 20260409; o time aplica direto. Validação pré-apply: BEGIN; <migration>; ROLLBACK; no banco real (testa FK/sintaxe/RLS sem persistir). - RPC SECURITY DEFINER no Supabase: REVOKE FROM PUBLIC NÃO basta — anon/authenticated têm grant default; revogar explicitamente os 3 + GRANT TO service_role. (Pego em prod no CAD-565.) - gen_random_bytes não existe (pgcrypto não habilitado) — usar gen_random_uuid() (nativo) concatenado p/ secrets. - Guard cross-tenant em trigger DEFINER: só dispara se v_jwt_tenant IS NOT NULL (service_role não tem JWT → não bloquear o INSERT legítimo). service_role coberto pelo guardrail de código (CAD-599). - FK composta (tenant,id) rejeitada (Vitor): 561 já em prod com FK simples; FK composta não pega "errar tenant_id em tudo" → guardrail de código (CAD-599). - email nullable (CAD-566 ampliado): 3 chaves de dedupe parciais por origem — email (índice parcial WHERE email IS NOT NULL) · ghl_contact_id (import GHL) · cnpj (enriquecimento sem email, futuro). Enriquecimento mantém skip no_email até existir coluna cnpj. - Stevo descartado → WhatsApp provedor agnóstico (Cloud API/Evolution), instância por tenant. - APScheduler (não cron-job.org) p/ scheduler de cadências.

Refs: PRs cadencia-app #36/#38 mergeados; migrations 20260617000000→060000; branch feature/crm-proprio; issues CAD-561/562/565/567/598 Done, 566 em andamento, 599/600/601 novas.

2026-06-16/17 — Projeto CRM próprio (substituir GHL): planejamento + decisões de arquitetura¶

Contexto: Decisão estratégica de matar o GHL (ADR-CRM-001/0007) e construir CRM próprio multi-tenant nativo Supabase dentro do cadencia-app. PRD V2 aprovado. Sessão planejou 42 issues, 8 épicos, planos técnicos ancorados no código, e iniciou execução (CAD-561 em produção).

Decisões tomadas (Felipe): 1. Estrutura = 8 épicos (Project Milestones E0–E7), não 6. Roundtable Catarina(PM)+Vitor(Arch)+Paloma(PO) quebrou o "balde": Sprint 0 (557-560) é gate de abertura (E0); toast (590) é infra transversal cedo (E0, bloqueia 573/589); Engine Cadências dividido em E4 (dados/catálogo) + E5 (runtime/disparo); Calendar/Composio isolado (E6, P2, pode escorregar sem travar go-live). 2. Scheduler = APScheduler (PRD original), não cron-job.org. O repo usa cron HTTP hoje, mas Felipe optou por APScheduler como worker persistente (CAD-577). Afeta 577/586/593. 3. Colunas phone + custom_fields jsonb adicionadas a contacts — PR #36 criou a tabela sem elas; CAD-561 fez o ALTER. Migração/seed/FieldTypes/enriquecimento dependem. 4. WhatsApp = provedor agnóstico, instância por tenant. Stevo DESCARTADO — usar API oficial (WhatsApp Business/Cloud API) ou Evolution API (Evo); escolha na execução do CAD-579 (interface WhatsAppSender). Não bloqueia. 5. Enriquecimento passa a gravar em public.contacts (CAD-598, nova story E1) com source='enrichment', substituindo upsertTenantContact() GHL. Achado da investigação: hoje o enriquecimento grava no GHL + lead_enrichments, a tabela contacts fica vazia. Sem CAD-598 o CRM não recebe dados. 6. Trigger CAD-562 dispara AFTER INSERT ON contacts WHERE source='enrichment' (não em lead_enrichments, não entry_source — bug do PRD §4.2). Bloqueado por CAD-598. 7. Projeto é do Felipe — Luiz fica nas issues dele. 42 issues reatribuídas ao Felipe. 8. Plano técnico completo espelhado em cada issue do Linear (não só no doc).

Como migrations são aplicadas (descoberto): supabase_migrations.schema_migrations remoto para em 20260409; migrations recentes (contacts, lead_enrichments) existem no banco mas não registradas → o time aplica via SQL direto (Management API), não supabase db push. CAD-561 seguiu o mesmo método (BEGIN/COMMIT).

Impacto: E1 fundado em produção (7 tabelas + RLS). Caminho crítico destravado. Risco residual: gates Composio (E6) e provedor WhatsApp ficam pra execução das stories respectivas.

Quem decidiu: Felipe (+ roundtable Catarina/Vitor/Paloma via agentes).

Refs: context/prd-crm-proprio.md · context/planos-tecnicos-crm.md · foundation/ux-patterns-crm.md · cadencia-app docs/adr/0007–0011 · PRs cadencia-app #36 (contacts) e #38 (schema base) mergeados · projeto Linear 69a31a72-8ac6-4420-a3b2-1093792ed73f.

2026-06-11 — OpenAI gpt-image-1 vira provider primário de capas; Gemini fallback (PDL-504)¶

Contexto: Tenants COM fotos saíam sem capa: Mode B (person) só usava Gemini e por design não tinha fallback ("no generic fallback for real_face"). Quota Gemini esgotada desde 09/06 → falha silenciosa (caso real: 3 carrosséis da Mel sem cover.png). Decisão: OpenAI gpt-image-1 primário nas 3 funções de cover_generation.py — person via images/edits com fotos de referência (input_fidelity=high mantém identidade), thematic via generations, physical_description via gpt-4o-mini vision. Gemini fallback. Alternativas consideradas: (a) só resolver quota/billing Gemini — descartado como única ação (qualidade GPT melhor e dependência única persiste); (b) manter sem fallback — inaceitável, quebra silenciosa. Impacto: tenants com foto voltam a ter capa com rosto real mesmo sem Gemini. Validado em produção (regen Mel, doc 014c8258). PDL-475 (Pexels fallback) reduz de escopo. Quem decidiu: Felipe.

2026-06-11 — Modelo de negócio: créditos puros, fim dos planos/assinatura (PDL-505)¶

Contexto: Cadência vendia 4 planos subscription + addons de créditos. Felipe decidiu simplificar: usuário compra créditos e usa como quiser. Decisão: Só pacotes one-time (+10 R$49,90 · +30 R$129,90 · +60 R$219,90, mesmos price IDs Stripe). Créditos não expiram. Novo cadastro ganha 20 créditos (plan_name="creditos", era trial de 3). Gating por plano removido (todos os canais liberados). Compra SOMA na carteira ativa — o webhook não insere mais row nova em tenant_plans (app lê só a mais recente; insert zerava o saldo anterior). Alternativas consideradas: manter assinatura paralela — descartado (sem assinantes ativos, complexidade sem retorno). Impacto: /app/plans vira "Comprar créditos"; checkout payment-only; workers dão prioridade só a pacote pago. Handlers de subscription no webhook ficam inertes. Pendente validação real de signup + compra. Quem decidiu: Felipe.

2026-06-11 — Impersonation real de tenant via cookie httpOnly (PDL-503)¶

Contexto: Página /app/admin/impersonate era read-only fake (decisão antiga "no session faking") — clicar não dava visão do app como cliente. Decisão: Cookie impersonate_tenant_id httpOnly (2h) setado por POST /api/app/admin/impersonate, honrado server-side por resolveTenant() SOMENTE para super_admin. Helper central substituiu a query inline user_tenant_roles em 27 call sites client-facing. Banner fixo + audit_logs em start/stop. ProfileQuestionModal suprimido durante impersonation. Alternativas consideradas: magic link do user (funciona como workaround mas é sessão real do cliente, queima token e não audita); session faking via Supabase (rejeitado historicamente). Impacto: suporte/demo sem pedir login do cliente. Admin segue admin nas rotas /admin durante impersonation. Quem decidiu: Felipe.

2026-06-09 — Separar OPENAI_IMAGES_KEY de OPENAI_API_KEY no cadencia-workers (Railway)¶

Contexto: Carrosséis Instagram de todos os 12+ tenants atuais (sem foto cadastrada) saíam com capa quebrada — fundo creme + texto branco ilegível, sem imagem real. Causa raiz identificada via Railway logs (debug-polya CRÍTICO): Gemini 429 quota free esgotada + OpenAI fallback gpt-image-1 retornando 401 porque OPENAI_API_KEY no Railway era sk-or-v1-... (OpenRouter), e o endpoint https://api.openai.com/v1/images/generations só aceita keys OpenAI nativas (sk-proj-...).

Decisão: Introduzir field dedicado settings.openai_images_key lendo OPENAI_IMAGES_KEY do env, com fallback transparente pra openai_api_key (compat). cover_generation.py:301 agora prefere o field novo. Env var setada no Railway production = mesma key OpenAI nativa que funciona na VPS Master pro blog_generate.py.

Alternativas consideradas: - (A) Substituir OPENAI_API_KEY no Railway direto pela key OpenAI nativa: rejeitado porque quebraria CHAT_MODEL OpenRouter (openai/gpt-4o-mini) e outras chamadas que dependem do gateway. - (B) Renomear OPENAI_API_KEY (gateway) → OPENROUTER_API_KEY: cosmético, requer mudar mais código. Pode virar débito futuro de naming clarity, mas não bloqueia agora. - (C) Implementar Pexels fallback de uma vez: escopo maior, fica em PDL-480 (Luiz).

Impacto: Capa thematic agora gera via Gemini OU OpenAI fallback (qualquer um que estiver up). Validado end-to-end no doc 74e30a48 do tenant Alexandre — Cover image loaded: cover.png (2490 KB) + foto editorial real renderizada. Backwards compat 100% — tenants sem OPENAI_IMAGES_KEY setada usam comportamento idêntico ao anterior.

Quem decidiu: Felipe (modo debug-polya CRÍTICO, autorizando "pode seguir com o necessário" + "faça tudo").

Refs: Commit 9ec7d60 master cadencia-app · PDL-475 (Done) · PDL-480 (Luiz, Pexels fallback) · Incidente incidents/2026-06-09_capa-instagram-vazia-openai-key-openrouter-railway.md.

2026-06-09 — Refinamento manual pós-workers como etapa obrigatória do /criar-tenant-agencia¶

Contexto: Dossier v1 do tenant Alexandre Manhães gerado automaticamente pelos workers veio raso/genérico ("treinamento corporativo de liderança e vendas"), sem mention de neurociência aplicada, andragogia 3 fases, autoresponsabilidade ou da tese assinada "vender é liderar". Resultado: 8 ideias geradas com cara de "trainer corporativo qualquer" + soul_md truncado no meio de parágrafos + editorias com vocabulário genérico de blog B2B.

Decisão: Adicionar FASE 0 (pesquisar transcrição/ata de call de briefing no Obsidian antes da coleta blocada) + Passo 12 — REFINAMENTO PÓS-WORKERS na skill /criar-tenant-agencia. Cobre 7 sub-passos: reescrever tenant_dossier.data denso (~3500 palavras, 8 blocos com 300-500 palavras cada), reconstruir soul_md sem truncar, reescrever editorias com vocabulário-âncora do cliente, expandir audiencia_descricao, limpar content_ideas/published_posts antigos genéricos, reconfirmar dossier_validated.

Alternativas consideradas: - (A) Fixar prompt do worker pra gerar dossier denso direto: maior esforço de eng, requer iterar prompt, e ainda assim risco de regressão pra tenants legados. - (B) Refinamento manual SEMPRE obrigatório (escolhido): rápido, alta densidade, captura material da call de briefing que o worker nunca acessa.

Impacto: Tenant white-glove premium agora nasce com dossier denso + soul não truncado + editorias com vocabulário-âncora — geração de conteúdo a partir disso já sai com cara do cliente. Tempo extra: 30-60min por tenant na primeira vez. Compensado pela qualidade do output.

Quem decidiu: Felipe + Catarina (PM persona). Skill atualizada em ~/.claude/skills/criar-tenant-agencia/SKILL.md com 6 edições cirúrgicas (FASE 0, avisos passos 7 e 8, novo Passo 12 com 7 sub-passos, mapa de tabelas tenant-scoped, 14 gotchas catalogados).

Refs: Tenant referência 91694c2d-7fa8-4aa2-82c8-16fe3a1cdfd5 Alexandre Manhães · Script versionado em times/produto/cadencia/context/diagnostico-tenant-alexandre-20260609.py.

2026-06-03/05 — Smoke test HTTP obrigatório pós-provisioning de blog¶

Contexto: Onboarding Marinella (Grupo WGL) e Mel Quevedo (Horus) marcou provisioning_status=ready mesmo com blogs retornando HTTP 525 (SSL handshake failed). DNS estava ok, Vercel project ok, mas Cloudflare proxied=True impedia Let's Encrypt emitir cert. Bug silencioso — só descobrimos por inspeção manual ao revisar tenants pós-onboarding.

Decisão: provision_tenant.py agora chama curl GET no domínio público após criar DNS+blog. Faz 1 tentativa imediata + 3 retries com sleep de 12s. Se HTTP != (200|301|302|307|308) ao final, adiciona erro estruturado em provisioning_errors e marca provisioning_status=partial. Default tuple OK_CODES evita duplicação.

Alternativas consideradas: - Não testar e confiar em verify=true da Vercel API (rejeitada — Vercel marca verified mesmo com cert pending indefinido) - curl -I HEAD (rejeitada — Vercel rejeita HEAD em algumas configs) - Sleep fixo 45s sem retry (rejeitada — pior caso real ~78s + 0s economia no caso feliz)

Impacto: Provisioning pode levar +5-30s no caso feliz, até ~52s no pior caso. Em troca, regressão de SSL/DNS é detectada na hora e visível em tenant_config.config.ghl.provisioning_errors. Commits 1df97c6 → 5bed398 → ea736df no cadencia-growth.

Quem decidiu: Felipe + Catarina (após auditoria pós-onboarding Marinella).

2026-06-03 — os.environ[k] = v substitui setdefault em todo script Python que lê .env¶

Contexto: trigger_server.py daemon rodou 4 dias com GHL_COMPANY_ID antigo em memória mesmo após fix de .env em 02/06. Scripts filhos (provision_tenant.py e cia) eram invocados via subprocess.run(cmd) sem env= — herdavam env do parent. O loader interno os.environ.setdefault(k, v) não sobrescrevia o valor herdado. Resultado: 403 silencioso em create_location para TODO tenant provisionado entre 02/06 23:40 e 03/06 19:30 (Marinella + Horus afetados).

Decisão: Patch em 11 scripts do cadencia-growth/pipeline/ + crons/ trocando os.environ.setdefault(k.strip(), v.strip()) por os.environ[k.strip()] = v.strip(). Comentário inline explicando o porquê.

Alternativas consideradas: - Passar env= em todo subprocess.run do trigger_server (rejeitada — propaga obrigação pra cada call, frágil) - Restartar trigger_server toda vez que .env muda (mantida como hábito, mas não substitui o patch)

Impacto: Scripts agora sempre usam valores frescos do .env. Combinado com systemd unit (decisão abaixo) garante que .env modificado em disco sempre chega no processo. Commit f7b1682 no cadencia-growth.

Quem decidiu: Felipe + Catarina (após debug-polya completo).

2026-06-03 — Systemd unit cadencia-trigger.service substitui nohup manual¶

Contexto: Mesmo incident do daemon env stale (acima). trigger_server.py foi iniciado em 30/05 via nohup python3 trigger_server.py >> log & e nunca foi restartado quando .env mudou. Sem EnvironmentFile, qualquer mudança em disco é invisível ao processo.

Decisão: Criar systemd unit em /etc/systemd/system/cadencia-trigger.service com: - Type=simple - User=root - EnvironmentFile=/cadencia/.env (recarrega .env em cada restart) - Restart=always + RestartSec=5 - StandardOutput=append:/cadencia/logs/trigger_server.log - Habilitado via systemctl enable.

Convenção nova: após mudar /cadencia/.env, OBRIGATÓRIO sudo systemctl restart cadencia-trigger.service. Adicionar como step 6 da skill /validar-deploy-vps.

Alternativas consideradas: - Continuar com nohup + lembrar de restartar manualmente (rejeitada — não é confiável, foi a causa do incident) - Cron job pra recarregar .env (rejeitada — gambiarra, não resolve o root)

Impacto: trigger_server agora restarta automático se cair, sempre lê .env fresh, e tem log unificado. PID muda a cada restart mas isso é OK.

Quem decidiu: Felipe + Diego (Infra).

2026-06-03 — Cloudflare proxied: False em todo subdomínio Vercel¶

Contexto: DNS records criados pelo provision_tenant.py com proxied: True (Cloudflare orange cloud ON). Vercel não conseguia validar HTTP-01 challenge do Let's Encrypt através do proxy → SSL nunca emitia na origem → HTTP 525 silencioso ao acessar blog. Confirmado em 3 tenants (Marinella, Horus, Alejandro).

Decisão: Default no script é proxied: False (DNS only, gray cloud). Vercel gerencia SSL direto via Let's Encrypt. Para domains já quebrados, sequência de remediação: PATCH Cloudflare DNS record proxied=false → Vercel API DELETE /domains/<x> → POST /domains → re-verify → aguardar 5-30 min pro cert emitir.

Alternativas consideradas: - Configurar Cloudflare em modo "Full (strict)" + cert origin Cloudflare (rejeitada — requer setup manual por tenant) - Usar Vercel nameservers em vez de Cloudflare (rejeitada — Cloudflare é DNS principal do domínio, mover quebraria outros serviços)

Impacto: SSL Vercel sempre emite. Cloudflare segue como DNS authoritative (sem proxy). Commit f7b1682 no cadencia-growth.

Quem decidiu: Felipe + Diego.

2026-06-03 — Email sender por tenant + warm-up domínio próprio (email.cadencia.app.br)¶

Contexto: dispatch seinfeld saía como noreply@mail.cadencia.app.br mas esse subdomain nunca foi autenticado — GHL caía no fallback agency, compartilhando reputação/quota. Limite 1000/dia atingido todo dia sem distribuir entre tenants.

Decisão: sender address por tenant via tenant_config.config.email_sender_address. Tenant 6bb2c1ba (Felipe) usa felipe@email.cadencia.app.br (subdomínio dedicado autenticado no GHL com SPF/DKIM/DMARC/MX via Mailgun). Display name separado via email_sender_name pro envelope (Felipe Luis Salgueiro | Cadencia), brand_name segue no template HTML (Cadencia).

Alternativas consideradas: Mailgun externo (descartado — GHL tem LC Email nativo), SES (descartado por complexidade de sandbox→prod), reutilizar inbox.cadencia.app.br (descartado — semanticamente confuso, fica disponível pra Mailgun inbound).

Impacto: warm-up de reputação começa amanhã (04/06 cron 14h UTC). Limite inicial ~1000/dia, escala em 3-4 semanas pra volume total (~230k/mês). Outros tenants continuam usando fallback default (zero regressão).

Quem decidiu: Felipe.

2026-06-03 — Webhook scoring: locationId via query string + event_type via path¶

Contexto: GHL Agency PIT bloqueado pra /contacts/* (testado 401 em 4 variantes). Sem reverse-lookup, handler não consegue inferir tenant a partir do contactId. GHL Workflow Custom Data tampouco preenche {{location.id}} no body POST.

Decisão: URL do webhook por tenant carrega ?location=<location_id> na query string. Handler infere event_type do path (/email-aberto → email_aberto, /email-clicado → email_clicado). Aceita payload em PT-BR (evento, email_aberto, email_clicado) além das variantes EN (type, event_type, email_opened, email_clicked).

Alternativas consideradas: Reverse lookup contactId→tenant via Agency PIT (impossível por bloqueio scope), iteração nos Location PITs com cache (caro O(N) por evento novo), provisioning automation via Workflow API (PDL-389 aberto, sem validação técnica ainda).

Impacto: scoring funciona end-to-end no tenant Felipe (validado SCORED 0→2). Cada tenant futuro precisa config manual (1× ~30s no GHL) até PDL-389 ser implementado. Documentado em cadencia-growth/docs/provisioning-ghl.md.

Quem decidiu: Felipe.

2026-06-03 — Newsletter limite NEWSLETTER_MAX_POSTS (default 7)¶

Contexto: newsletter_generate.py buscava TODOS os posts com newsletter_included=false sem limite. Tenant Felipe acumulou 15 posts em 5 semanas → uma newsletter gigante sairia na próxima sexta.

Decisão: limita query a NEWSLETTER_MAX_POSTS (default 7 = 1 por dia da semana, configurável via env). Ordem asc garante FIFO. Excedentes ficam pra próxima edição automaticamente.

Alternativas consideradas: segmentar por data (descartado — frágil quando cron atrasa), limite hardcode (descartado — perde flexibilidade), limpar backlog manualmente (descartado — perde histórico).

Impacto: pool de 15 do Felipe vai sair em 3 sextas (06/06, 13/06, 20/06). Duplicata b89ccb31 marcada newsletter_included=true pra não duplicar Opus 4.8.

Quem decidiu: Felipe.

2026-06-03 — Remover provision_tenant.py duplicado da raiz¶

Contexto: repo cadencia-growth tinha duas cópias: /provision_tenant.py (raiz, desatualizada de 27/05) e /pipeline/provision_tenant.py (versão ativa). Documentação dizia "canonical" raiz mas auditoria mostrou nenhum script ativo apontava pra ela.

Decisão: raiz removida do repo. test_provision.py corrigido pra pipeline/. docs/provisioning-ghl.md atualizado com nota histórica. VPS Master também renomeou versão antiga /cadencia/provision_tenant.py → .bak-dead-code-removed-2026-06-03.

Alternativas consideradas: manter ambas sincronizadas via symlink (descartado — drift inevitável).

Impacto: uma única cópia oficial em pipeline/. Reduz risco de drift e bug onde script raiz seria executado por engano.

Quem decidiu: Felipe.

2026-06-02 — Modelo de cobrança crédito-only · removida lógica de tier no pipeline¶

Contexto: growth_pipeline.py mantinha filtros if plan_name in ('trial','essencial','starter'): pula seinfeld + roda blog 2x/sem. Modelo do produto mudou pra crédito-only: "planos" são apenas convenções comerciais (lotes com desconto). Felipe explicou na sessão. Todo cliente paga tem que ter todos os canais habilitados.

Decisão: removido o branch de plan_name em growth_pipeline.py. Só tenant_plans.credits_total - credits_used > 0 decide se gera. Backfill tenant_config.growth_channels = ["blog","seinfeld","linkedin","instagram"] em 20 tenants com NULL (22/22 agora completos). Provision-tenant frontend (cadencia-app) também cria tenant_config com defaults sempre (antes só criava se attribution).

Alternativas consideradas: manter filtro como degradação visual (descartado — modelo mudou de verdade, código tem que refletir).

Impacto: tenants em "trial"/"essencial"/"starter" param de receber 5 dias de skip por semana — passam a gerar diário enquanto creditos > 0. Risco: planos antigos com poucos créditos podem queimar mais rápido — alinhar com CS antes de comunicar.

Quem decidiu: Felipe.

2026-06-02 — PDL-171 resolvido · generation_queue.channels text[] adicionado¶

Contexto: frontend gravava INSERT { channels: [...] } em generation_queue há semanas. Mas a coluna channels (plural) nunca existiu na tabela — só channel (singular, default 'blog'). Supabase silenciosamente descartava a coluna inexistente e inseria com channel='blog' por default. Toda informação multi-canal do user era perdida na borda do banco. PDL-171 estava aberto descrevendo o sintoma há tempo.

Decisão: ALTER TABLE generation_queue ADD COLUMN channels text[] NOT NULL DEFAULT '{}' + backfill channels = ARRAY[channel] WHERE channel IS NOT NULL. Aplicado em prod via Management API. 269/269 rows com channels populado. Coluna channel singular mantida pra compat (pode dropar depois). Migration commitada em cadencia-app/supabase/migrations/20260602230000_generation_queue_channels_array.sql.

Alternativas consideradas: manter só channel e frontend usar singular (descartado — multi-canal é requisito do produto, não dá pra perder).

Impacto: linkedin/instagram/seinfeld que dependiam de saber "quais canais o user aprovou" agora têm informação correta. Combinado com fix do VPS_TRIGGER_URL e do tier filter, fecha o ciclo "aprovou e não gerou".

Quem decidiu: Felipe (aprovou plano), agente executou.

2026-06-02 — 1 blog = 1 repo Git dedicado por tenant · supera limite Vercel 10/repo¶

Contexto: antiga implementação ligava todos os Vercel projects ao mesmo cadencia-blog-template. Vercel Hobby limita 10 projects per Git Repository. No 11º tenant vercel project create falhava silenciosamente. Felipe não quer upgrade pra Pro agora.

Decisão: provision_tenant.create_vercel_blog() agora chama GitHub Template API (POST /repos/{template}/generate) pra criar {owner}/blog-{slug} dedicado, depois cria Vercel project ligado a esse repo isolado. Template (cadencia-blog-template) nunca acumula projects.

Owner = felipeluissalgueiro (conta pessoal) porque Vercel Hobby rejeita repo privado de organização. Migração pra org Cadencia (slug atual Posicionamento-Digital) postergada — esperar upgrade Vercel Pro pra mover tudo de vez (renomear slug org + transfer repos felipeluissalgueiro/blog-* → Cadencia/blog-* + update constante GITHUB_BLOG_REPOS_OWNER).

Alternativas consideradas: - Migrar blogs pra VPS Master (Caddy + static): rejeitado — Felipe quer manter Git como fonte da verdade e pipeline de deploy. - Repos públicos na org Posicionamento-Digital: tecnicamente seguro (segredos em Vercel env), mas expõe template publicamente. - Vercel Pro $20/mês: postergado por decisão de custo. - Deploy sem Git via Vercel API direta: rejeitado — Felipe quer Git.

Impacto: PR cadencia-growth#1 mergeado. Validado em Alejandro Pano (1bb0723e) que tinha falhado no limite Vercel; agora felipeluissalgueiro/blog-alejandro-pano criado + Vercel project deploy READY em ~3s.

Quem decidiu: Felipe.

2026-06-02 — Padrão de branches nos repos do produto: commit direto em main¶

Contexto: durante sessão, agente abriu branches feat/pdl-XXX + PRs em cadencia-app e cadencia-growth pra Felipe "revisar". Felipe explicitou: "não estou entendendo isso que vc está fazendo de colocar as branchs para eu revisar. nunca usei isso. não existe isso no framework". Padrão real é commit direto em main nos repos do produto.

Decisão: a partir desta data, em repos como cadencia-app, cadencia-growth, pd-portal, etc — commit direto em main/master sem branch + PR pra Felipe revisar. Branches + PR só quando: (a) Felipe pedir explicitamente, (b) for issue Linear sendo trabalhada formalmente com plano técnico, (c) o repo tiver branch protection que bloqueie push direto.

Alternativas consideradas: manter branches + PR como hábito defensivo (descartado — Felipe não revisa PRs assim, atrasa entrega).

Impacto: ciclos mais curtos, sem espera. Risco: erro vai pra main direto. Mitigação: agente continua compile check + dry-run + valida antes de push.

Quem decidiu: Felipe.

2026-06-01 — Workaround blog Vercel para limite de 10 projetos com git integration¶

Contexto: template cadencia-blog-template atingiu limite de 10 projetos conectados via git integration no Vercel. vercel project add via API com gitRepository retorna erro.

Decisão: criar projeto Vercel via API sem campo gitRepository, clonar template localmente (gh repo clone), vercel link --project <nome> + vercel deploy --prod --yes. Bypass do limite git sem criar repo novo no GitHub.

Alternativas consideradas: criar novo fork do template (descartado — proliferação de repos); mudar para Vercel Team plan (custo desnecessário); deploy via ZIP API (mais complexo, mesmo resultado).

Impacto: para cada novo blog de tenant, o flow é: API cria projeto → clone local em C:\temp\cadencia-blog-<slug>\ → link → deploy. Primeira vez leva ~3 min; deploys subsequentes via vercel deploy no mesmo clone.

Quem decidiu: Felipe (implícito — constraint de infra).

2026-06-01 — Fix sub-preset-choice worker (bug crítico 500)¶

Contexto: endpoint POST /api/v1/onboarding/sub-preset-choice retornava 500 para qualquer payload. Dois bugs independentes.

Decisão: (1) Pydantic SubPresetChoiceBody sem handling de ValidationError → wrap em try-except retornando 422 com mensagem explícita. (2) select("theme") em tenant_visual_identity — coluna inexistente, tabela usa coluna data — corrigido para select("data").

Impacto: onboarding white-glove agora pode definir sub-preset via worker sem erro. Commit 24c2ba44 em felipeluissalgueiro/cadencia-app master, auto-deploy Railway.

Quem decidiu: Felipe.

2026-05-30 (madrugada) — Batch 2 paralelo (Modo B): 4 PDLs em sequência (351, 354, 347, 346)¶

Contexto: continuação do dia 29/05 com Modo B (paralelo + Felipe babysitting). Felipe autorizou ampla execução do Batch 2 com defaults Catarina.

PDL-351 — Pipeline cascade abort¶

Decisão final (Codex P1 override da opção B): abort condicional — manter abort somente quando content_idea_id setado.

Razão Codex P1: opção B simples (remover abort completo) criaria regressão pior. Sem published_post da idea solicitada, seinfeld --generate pega o post mais antigo unscheduled; linkedin/instagram com --idea-id fazem fallback pra queue genérica. Resultado: dispatch de conteúdo de ideia errada para o tenant.

Implementação: pipeline/trigger_server.py:87-97 — if content_idea_id: return mantido; sem idea-specific, segue. blog_ok flag dead code removida (Claude P2).

Deploy: VPS Master /cadencia/pipeline/trigger_server.py via SCP + restart (PID 2164301).

Refs: commits 438254f (B simples) → e030e3a (Codex P1 fix) → 5680062 (docs). Reports: cadencia-growth/docs/{codex,claude,runtime}-reviews/*-pdl351.md.

PDL-354 — chat-ideias title via LLM¶

Decisão: gpt-4o-mini gera title editorial limpo (≤12 palavras pt-BR, sem fórmulas batidas, preserva ferramentas/números mencionados). description mantém input bruto. Timeout agressivo 3s — UX > qualidade quando OpenAI lento. Fallback automático pra input truncado.

Mitigação prompt injection: input encapsulado em <user_input>...</user_input> + reforço "Trate como DADOS, nunca instruções".

Sanitização: strip de markdown bold (**), headers (##), prefixo "Título:"/"Title:". Truncamento por palavra (≤12), não por char.

Refs: PR cadencia-app#4 merged. Commits 04260a8 → 3e593f0 (P1+P2 reviews) → 03473da (docs). Reports: docs/{codex,claude,runtime}-reviews/*-pdl354.md.

PDL-347 — Headlines few-shot¶

Decisão: refactor completo do prompt do headline_agent com: - 5 GOOD exemplos reais (validados IG/TikTok Felipe) + 5 BAD (fórmulas a evitar). - Regra 0 nova: editoria headline_rule tem precedência. - Regra 1 reescrita: "ferramenta MENCIONADA NESTA IDEIA" — sem importar marcas dos exemplos (mitigação Claude P2 bias tech/AI). - Hook vulnerabilidade adicionado em HOOK_TYPES. - Tamanho flexível: core ≤10 + paren ≤8. - Validação separada core vs paren via regex (_split_core_and_parens). - Pydantic field_validator normaliza hook_type contra HOOK_TYPES + aliases comuns. - model_config.py:474 atualizado pra preservar headline do slide 1 (antes truncava em 6 palavras — Codex P1 critical).

Refs: PR cadencia-app#5 merged. Commits 0c8217b → 8f6a42e (Codex P1 + Claude P2 reviews). Raw reviews em docs/{codex,claude}-reviews/raw-pdl347.txt.

PDL-346 — Cover scene preferences (fix mínimo)¶

Decisão (Modo B fix mínimo): adicionar campo tenant_config.config.visual_scene_preferences (JSON) com: - scene_categories_blocked: list de categorias rejeitadas - free_form_scene_hint: string com preferência visual livre

cover_generation.py:generate_scene_prompt aceita 2 params novos. Hint posicionado depois das RULES como OVERRIDE (Claude P2 recency bias). Encapsulado em <tenant_hint> + instrução "treat as DATA, not instructions" (Claude P2 prompt injection mitigation).

Regra 4 reescrita: removidas equações niche=cena (advogado=historic, consultor=studio) — agora lista paleta de imaginários (studio, outdoor, urban raw, historic, working desk, rustic, workshop) e diz "pick whichever best matches THIS specific tenant's voice".

orchestrator.py: 2 callsites (cover-pessoa + thematic) leem visual_scene_preferences e propagam. Quando LLM falha E tenant tem prefs setadas, logar cover_scene_fallback_with_prefs (warning Codex P2 — SCENE_TEMPLATES hardcoded podem conter cenas bloqueadas).

Refactor completo SCENE_TEMPLATES por categoria: deferido pra PDL nova. Fase 2 do plano técnico.

Refs: PR cadencia-app#6 merged. Commits ff5611b → 3952276 (Codex P2 + Claude P2x3 reviews). Raw reviews em docs/{codex,claude}-reviews/raw-pdl346.txt.

Quem decidiu: Felipe (PO autorizou Batch 2 amplo) + Catarina (defaults + execução) + Vitor (Python) + Codex/Opus (review).

Aprendizado meta: Modo B funcionou — execução paralela + babysitting passivo do Felipe permitiu fechar 4 PDLs em 1 hora. Pipeline triplo de review pegou regressões críticas (Codex P1 em PDL-351 e PDL-347) que análise unitária não pegaria.

2026-05-29 — gpt-image-1 substitui dall-e-3 + mensagens de erro estruturadas (PDL-350 + PDL-352)¶

Contexto: OpenAI descontinuou dall-e-3. Todo blog gerado em produção quebrava silenciosamente sem featured image ('dall-e-3' does not exist em 100% das tentativas). Mesma sessão: erro genérico 'tenant is not on growth plan' mascarava bugs como plan_tier='growth_pro' inválido.

Decisão técnica: - Migrar blog_generate.py + backfill_images.py para gpt-image-1 com payload novo: size='1536x1024' (3:2 widescreen), quality='high', response em b64_json (sem etapa de download via URL intermediária). - Padronizar mensagens de erro de validação: tier atual + esperado + source (campo/tabela) + SQL fix pronto pra copiar. Aplicar pra plan_tier e blog.vercel_url. - tenant_id SEMPRE validado via uuid.UUID() antes de embebido em SQL exibido. - SQL fix pra path nested em JSONB: usar config || jsonb_build_object(...) ao invés de jsonb_set('{a,b}',...) — funciona com ou sem parent key.

Pipeline triplo aplicado (Modo B paralelo): - Codex (GPT-5.4) → 1 P1 (backfill sem base_url override) + 1 P2 (jsonb_set no-op) - Claude (Opus 4.7) → 2 P2 (b64decode silencioso em moderação + tenant_id SQL injection) + 6 P3 - Runtime-fix-review → 8 PASS / 0 FAIL, incluindo teste runtime real em VPS com mensagem PDL-352 saindo formatada

Custo: quality='high' em gpt-image-1 (~$0.19/img 1536x1024) é ~5x mais caro que DALL-E standard (~$0.04). Consistente com cover_generation.py. Limit/quota em backfill batch fica como P2 backlog.

Refs: - Repo: Posicionamento-Digital/cadencia-growth (push main direto, sem PR) - Commits: 5e66abf (fix base) · 1f8f951 (P1+P2 reviews) · 12e6f71 (docs) - Deploy VPS Master: SCP /cadencia/pipeline/blog_generate.py + backfill_images.py + sudo chown root + pyc invalidado. Backups em *.bak-pdl350-352 e *.bak-pdl350. - Reports: docs/{codex,claude,runtime}-reviews/*-pdl350-352.md - Pattern reference: cadencia-app/cadencia-workers/src/workers/cover_generation.py:250-294

Quem decidiu: Vitor (executou + decidiu padrão de payload e mensagens) + Codex/Opus (review) + runtime validation em VPS prod.

2026-05-29 — Newsletter removida dos canais on-demand (PDL-353)¶

Contexto: newsletter aparecia como canal selecionável on-demand em /app/ideas (drawer aprovação) e em /app/perfil > Integrações. Backend (trigger_server.py) ignora silenciosamente desde fix do incidente 06/05/2026 (newsletter = digest semanal cron Sex 15h BRT). Resultado: usuário pagava crédito por canal que nunca executava + lixo na generation_queue.

Decisão produto (opção A — cirúrgica): - Remover newsletter da lista de canais on-demand no frontend. - Manter copy "Toda sexta uma newsletter" no modal info do drawer (transparência sobre digest automático). - NÃO implementar newsletter on-demand real (opção C) — reintroduziria risco do incidente 06/05. - NÃO implementar checkbox disabled com tooltip (opção B) — overkill.

Mudanças: - src/app/(app)/app/ideas/page.tsx: remover newsletter de ALL_GROWTH_CHANNELS, 5 entries de PLAN_CHANNELS, item do array do drawer JSX. - src/components/brand/BrandProfile.tsx: remover newsletter de GROWTH_CHANNEL_OPTIONS. - src/app/api/app/toggle-config/route.ts: remover newsletter de VALID_CHANNELS (rejeita re-persist). - Migration data Supabase: UPDATE tenant_config SET config = jsonb_set(..., (config->'growth_channels') - 'newsletter') WHERE ... → 5 rows updated (legacy data).

Pipeline triplo aplicado novamente (Modo A protocol): - Codex (GPT-5.4) → 1 P1: BrandProfile.tsx ainda expunha newsletter + legacy data - Claude (Opus 4.7) → 2 P2 (sobrepostos com Codex P1) + 2 P3 (não bloqueantes) - Runtime-fix-review → 8 PASS / 0 FAIL (build + migration + post-state validation)

Refs: - PR felipeluissalgueiro/cadencia-app#3 - Commits: b476f88 (fix base) · 6f31719 (review fixes) · 74be945 (docs) - Reports: docs/{codex,claude,runtime}-reviews/*-pdl353.md no repo cadencia-app - Incidente origem: pd-framework/incidents/2026-05-29_cadencia-16-bugs-provisioning-tenant-felipe.md - Incidente background newsletter: pd-framework/incidents/2026-05-06_trigger-server-zerava-pool-newsletter.md

Quem decidiu: Felipe (PO escolheu opção A) + Catarina (PM executou) + Codex/Opus (review).

2026-05-29 — Dedup atômico Seinfeld via Supabase + pipeline triplo de review (PDL-355/356)¶

Contexto: dispatch Seinfeld marcava apenas seinfeld_sent=true no post sem rastrear quais contatos receberam. Retry/crash/reset duplicava emails (G019 novo). Felipe pediu reviews retroativos depois que pulei o protocolo do squad dev na primeira passada.

Decisão técnica: - Dedup primário: tabela seinfeld_daily_sent com UNIQUE (tenant_id, contact_id, sent_date). INSERT atômico → conflict 409 = skip, 2xx = enviar, 4xx/5xx = pular sem enviar. - Audit log secundário: seinfeld_dispatch_log (post-level, sem UNIQUE). - Rollback em falha de envio via sb_delete REAL — NÃO UPDATE sent_date='1970-01-01' (corrompia UNIQUE e poluía auditoria). - sb_insert retorna 3 estados distintos: list (OK), [] (conflict 409), None (erro real). Caller diferencia.

Decisão de processo: pipeline triplo de review obrigatório pra mudanças em código de dispatch.

Coverage não-overlapping comprovada nesta sprint: - Codex (GPT-5.4) → 1 P1: sb_insert undefined (patch via regex falhou silenciosamente) - Claude (Opus 4.7) → 2 P1 mais profundos (mascaramento 4xx/5xx como sucesso + UPDATE corrompendo UNIQUE) + 3 P2 + 4 P3 - Runtime-fix-review (real Supabase) → 6 PASS / 0 FAIL

Sem o pipeline o dispatch quebraria com NameError no 1º contato (Codex) ou mascararia falhas auth como sucesso (Claude).

Anti-padrão registrado: patch via regex em código Python não pode reportar "OK" sem verificar com grep -c que o helper foi de fato inserido. Smoke test SQL não basta — precisa exercitar o caminho non-dry-run real.

Refs: - cadencia-growth/docs/codex-reviews/codex-review-29-05-2026.md - cadencia-growth/docs/claude-reviews/claude-review-29-05-2026.md - cadencia-growth/docs/runtime-reviews/runtime-review-29-05-2026.md - Commits main: efc1394 PDL-355 · 6da6b9d PDL-356 · 5ade215 sb_insert fix · 77e70d9 P1+P2 reviews fix

Quem decidiu: Felipe (insistiu retroativo) + Catarina (executou) + Codex/Opus (review).

2026-05-28 — Onboarding dialogado do tenant pessoal Felipe (PDL-332)¶

Contexto: Felipe optou por fazer o onboarding do tenant pessoal felipe@cadencia.ia.br dialogado com Catarina em vez da UI padrão, porque produz resultado mais profundo (PME que responde Big5 com 1 clique vs Felipe que dialoga com nuance).

Decisão: Catarina conduziu briefing em fases (1, 1.5, 2, 3) replicando o que os workers oficiais (dossier.py, visual_identity.py, editorials.py) perguntariam. Resultados injetados via SQL direto nas 6 tabelas: tenant_config, tenant_profile, tenant_dossier, tenant_visual_identity, tenant_themes, tenant_editorials + tenant_onboarding.current_phase='complete'. Pulamos provision_tenant.py (que criaria nova subconta GHL) — Felipe usou location PD existente PrAh9rKjmpUkElCu5KBI (dual-use).

Anti-padrão registrado: primeira tentativa pulei tenant_profile/dossier/visual_identity/themes (só populei tenant_config.config). Felipe pegou: "no onboarding se criam as fontes, eu mando fotos, me fala como ficou o perfil, paleta de cores... vc pulou tudo isso, não tem como o sistema criar". Aprendizado pra qualquer provisioning futuro manual: as 6 tabelas são obrigatórias, pular qualquer uma quebra geração.

Impacto: - Tenant Felipe pessoal funcional (validar em sessão seguinte: 1ª geração de ideia + Identity Lock cover) - Material da mentoria Alexandre Manhães usado como insumo interno (NÃO em conteúdo público — ver decisão separada abaixo) - Editorias com pesos custom (0.40 educativa / 0.35 confrontadora / 0.25 demonstrativa) — sobrescreve canônico do produto - Upload de fotos rosto em background pendente conclusão na próxima sessão

Quem decidiu: Felipe + Catarina (sessão dialogada 28/05 noite)

Refs: EXPERTISE.md § Tenant pessoal Felipe · scripts em C:\tmp\ (fase1_v7_inject.py, fase15_inject.py, fase2_inject.py, fase3_inject.py, populate_tables.py, vps_resize_upload.py)

2026-05-28 — Mirror docs/ sincronizado com GitHub (PDL-342)¶

Contexto: Auditoria 2026-05-28 descobriu que mirror times/produto/cadencia/docs/ estava defasado em 21 arquivos (5 pastas inteiras + 4 arquivos soltos só existiam no GitHub cadencia-app/master/docs/).

Decisão: Sync manual via C:\tmp\sync_cadencia_docs.py trouxe os 21 arquivos faltantes. Cada um recebeu header padrão 📄 Cópia local — fonte de verdade no GitHub apontando pra origem. Mirror agora 1:1 com GitHub master (62 docs total).

Impacto: - EXPERTISE.md §8 atualizado (sem "mirror defasado") - CLAUDE.md do squad atualizado (regra absoluta diz "sincronizado") - Próximo sync via /documentar precisa cobrir TODAS as pastas (não só estruturadas) — follow-up registrado na PDL-342

Quem decidiu: Felipe (depois que Catarina propôs "mandar agente ler GitHub se mirror defasar" — Felipe: "se está defasado para quem mandar ele ler outra coisa, melhor corrigir")

2026-05-28 — EXPERTISE.md criada como leitura obrigatória do squad¶

Contexto: Felipe cobrou — "como líder do cadencia vc teria obrigação de saber tudo de cabo a rabo". Agente novo carregando contexto via ~50 docs separados é lento e propenso a perder detalhes críticos (gotchas, tokens GHL distintos, schema tenant_config, dependências cross-pipeline).

Decisão: Criado times/produto/cadencia/EXPERTISE.md — doc denso (~280 linhas) consolidando: arquitetura em 1 página, 16 gotchas catalogados (G001-G016), mapa de 4 tipos de token GHL distintos, schema tenant_config.config, ADRs em 1 linha cada, dependências cross-pipeline, débitos críticos do produto, convenções 1P, checklist obrigatório antes de trabalho técnico.

CLAUDE.md do squad atualizado com regra absoluta: ANTES de qualquer trabalho técnico no Cadência, leia (1) EXPERTISE.md, (2) context/how-it-works.md, (3) doc específico da área.

Quem decidiu: Felipe

2026-05-28 — Mentoria Alexandre Manhães = insumo interno (não público)¶

Contexto: Material da mentoria com Alexandre Manhães (Laboratório de Crescimento) foi usado pra enriquecer dossier/Sobre do tenant pessoal Felipe. Mas relação Mentor↔Mentorado se sobrepõe com Cliente↔Fornecedor (Felipe entrega Cadência white-glove pro Alexandre, Alexandre cobra mentoria) — negociação de parceria comercial Cadência↔Recomendo em curso.

Decisão: Material da mentoria fica como insumo INTERNO (decisions, briefing, memory, foundation, EXPERTISE.md). NÃO entra em conteúdo público do Felipe (Sobre, SOUL.md, posts, marketing externo, ata pública).

Como aplicar: redações públicas usam termo genérico ("disciplina externa de execução", "ritmo semanal") sem nomear Alexandre/Laboratório/MetaCortex/Recomendo.

Quem decidiu: Felipe (cortou direto: "como eu já disse não falar sobre minha mentoria")

Refs: memory feedback feedback_mentoria_alexandre_privada.md no stamper

2026-05-27 — Documentação técnica completa via /documentar + 5 ADRs novas¶

Contexto: Squad Cadência tinha CLAUDE.md por componente (28 arquivos com template simplificado da fase anterior) mas sem ADRs formais (só ADR-0001 Stripe) nem mapa global de "por que cada coisa é assim". Agentes novos chegando no squad precisavam ler código pra inferir decisões — risco de regressão.

Decisão: Rodar /documentar modo projeto-inteiro a partir do handoff context/handoff-documentar-cadencia.md (fases 6-10). Resultado: 1. Fase 7 (globais): CONTEXT.md (linguagem ubíqua) + docs/architecture.md (C4 mermaid) + 5 ADRs novas (0002 chat agent design, 0003 GHL motor invisível, 0004 carrossel Railway resto VPS, 0005 location_pit_token por tenant, 0006 multi-tenant RLS) + CHANGELOG.md 2. Fase 6: 26 CLAUDE.md de componente enriquecidos com seções Quando usar/NÃO usar, Por que (link ADR), Don'ts, Já tentamos (referenciando incidents do hub), Troubleshooting, Refs cruzadas 3. Fase 8: Wiki HTML em docs/wiki/ no repo cadencia-app — 39 arquivos (index + 26 componentes + 2 overview + 6 ADRs + changelog + style/script/search-index) com sidebar dinâmica 4. Fase 9: 26 notas Obsidian em Time PD/Projetos/Cadencia/Docs/ com frontmatter + wikilinks 5. Fase 10: docs/.documentar-meta.json atualizado pra modo "projeto-inteiro" com mapa completo 6. Mirror no framework: times/produto/cadencia/docs/ com 42 arquivos organizados por área (architecture, adr, workers, growth, frontend, lib) + READMEs de navegação em cada nível + atualização do CLAUDE.md do squad com mapa de intenções

Alternativas consideradas: - Doc só nos repos: descartado — agentes do framework precisam ler tudo via gh api cada vez. Mirror local custa pouco e dá leitura direta + grep. - README único master no framework sem sub-READMEs: descartado — Felipe pediu navegação fractal (sub-index por subpasta). - Duplicar estrutura docs/<area>/ nos repos também: descartado — no repo a doc convive com o código (cada CLAUDE.md no diretório do componente). Só READMEs leves em docs/ e docs/adr/ foram criados nos repos. - Sobrescrever ADR-0001: descartado — ADRs são imutáveis. ADR-0002 a 0006 são novas, numeração sequencial.

Impacto: - Agente novo entrando no squad lê CLAUDE.md → docs/README.md → componente específico em ~5min, sem precisar inferir decisões do código. - 6 ADRs viraram fonte da verdade pras decisões "por que GHL é invisível?", "por que carrossel Railway e blog VPS?", "por que location_pit_token por tenant?", "por que RLS Supabase?". - Fonte da verdade dos docs continua o GitHub — cópia local em docs/ é read-mostly com header indicando origem. - Atualização futura: rodar /documentar ou sync_to_framework.py ressincroniza tudo. - Esses ~80 commits no cadencia-app master dispararam builds Vercel (deploy frontend) — não afeta runtime mas gera ruído.

Quem decidiu: Felipe

Refs: - docs/README.md (master + 6 sub-READMEs) - docs/adr/ (6 ADRs) - Wiki: docs/wiki/index.html no cadencia-app - Obsidian: Time PD/Projetos/Cadencia/Docs/

2026-05-25 — Bootstrap Squad Cadência (PDL-232)¶

Contexto: Cadência precisava entrar no PD Framework como Squad pai PRODUTO com identidade própria (SOUL.md), distinto dos Times operacionais. 4 níveis hierárquicos por complexidade (frontend/growth/workers internamente).

Decisão: Squad pai times/produto/cadencia/ criado em sessão guiada com Felipe. 3 sub-squads (frontend/growth/workers) + 1 feature (blog rebaixada de sub-squad). Persona Catarina como PM/Owner. Foundation com 5 docs constitutivos. SOUL.md populado real (não placeholder) com base em Notion "Avatar de Marca — Quem é a Cadencia" (01/05/2026) + POSICIONAMENTO-AL-RIES.md + CADENCIA-VISAO-PRODUTO.md.

Alternativas consideradas: - 4 sub-squads incluindo blog (descartado — blog não tem ritmo/workers próprios, virou feature) - Persona Luana (descartado — Felipe escolheu Catarina) - Skills duplicadas repo + framework (descartado — A1 só no framework, deleta do repo) - n8n stack VPS como sub-squad (descartado — n8n só compartilha nome, não relacionado) - assessoria-imprensa-cadencia como sub-squad (descartado — pertence a Marketing/Comunicação)

Impacto: - 3 projetos Linear ligados (Roadmap, Bugs, Growth Migração) já mapeados em linear-squad-map.json - Skills locais migram do repo Cadência para skills/ (A1) - Time Dev cobre suporte técnico cross-Time (Vitor/Amélia/Camila/Paula/João) - Catarina invocável /catarina cross-Time para decisões de produto

Quem decidiu: Felipe

2026-05-25 — D02: Skills do Cadência migram pro framework (A1)¶

Contexto: Skills locais (cadencia-review-deploy, capi-test, gerenciar-plano, analytics-report) viviam em cadencia-app/.claude/skills/. Felipe pode estar codando de qualquer cwd e precisa invocar skills do Cadência.

Decisão: Migrar (mover) skills do repo cadencia-app para times/produto/cadencia/skills/ no PD Framework. Adicionar CADENCIA_REPO="<path>" + cd "$CADENCIA_REPO" no início de cada skill que opera no código. Deletar do repo Cadência (sem drift bidirecional).

Pendência pós-bootstrap: sandbox da sessão bloqueou deleção de pastas fora de pd-framework. Felipe precisa executar manualmente no repo Cadência:

cd "Projetos BMAD/Cadencia/.claude/skills" && rm -rf cadencia-review-deploy capi-test gerenciar-plano analytics-report

Alternativas consideradas: - Manter no repo Cadência só (perde acesso de cwds diferentes — rejeitado) - Bidirecional/duplicar (drift garantido — rejeitado)

Impacto: - Skills disponíveis de qualquer cwd - Padrão path absoluto fixo: se repo mudar de pasta, atualiza um lugar - Skills vazias (/deletar-user, /visual-test) viram issue Linear de backlog (repopular)

Quem decidiu: Felipe

2026-05-25 — D03: Blog rebaixado de sub-squad para feature¶

Contexto: Briefing inicial previa 4 sub-squads (frontend/growth/workers/blog). Análise mostrou que blog não tem ritmo próprio: geração vive em workers/ (orchestrator 7-step), auto-deploy via Vercel template estático (cadencia-blog-template), template raramente muda, sem cron próprio, sem equipe distinta.

Decisão: Blog vira features/blog/ (sem CLAUDE.md, sem memory, só README documentando o template). PDL-240 (planejada como sub-squad blog) é fechada com Closes mantendo o escopo ajustado — cria features/blog/README.md.

Alternativas consideradas: - Manter blog como sub-squad (não passa critério HIERARCHY — sem workers/STATE/ritmo próprio — rejeitado) - Eliminar blog completamente (rejeitado — repo cadencia-blog-template existe e é parte do produto)

Impacto: Estrutura final: 3 sub-squads + 1 feature. Squad pai documenta blog em features/blog/README.md.

Quem decidiu: Felipe

2026-06-18 — D04: CRM E2 + filtros/colunas/views (CAD-613/614/615/570/571/572/642)¶

Contexto: continuação do redesign CRM próprio. E2 fechado + sprint S2 (filtros, colunas, search, saved views).

Decisões: - Tags: catálogo ÚNICO por tenant (tags + contact_tags + company_tags), tags livres criadas on-the-fly no contato/empresa; gestão (cor/rename/excluir) em Configurações. Aplicáveis a contato E empresa. (CAD-614) - Campos personalizados: criação/gestão SÓ em /app/growth/configuracoes (não no detalhe do registro — removido). Entidades: contact/company/opportunity (custom_field_defs + custom_fields jsonb). Preenchimento de valor virá por edição inline nas views. - Filtros e search: 100% CLIENT-side sobre o lote carregado (PRD §3.2 — sem endpoint por filtro). Endpoint server-side /query foi descartado por divergir do PRD. - Saved views (CAD-642): extensão além do PRD; tabela crm_views, views COMPARTILHADAS no tenant, guardam filtros+colunas(visível/ordem)+ordenação. Benchmark estético: Linear. - Colunas: avançadas (GHL/custom/lifecycle/source/tags) ocultas por default (progressive disclosure); visibilidade+ordem em localStorage.

Desvios do PRD declarados: presets de filtro que dependem de opportunity/activity/cadência (CAD-571) e os 12 editores inline avançados (CAD-570) e tsvector cross-object server (CAD-572) ficaram fora — declarados, não silenciados.

Migrations em prod (Management API): 20260618000000_tags_schema, 20260618010000_custom_fields_opportunity, 20260618020000_crm_views.

Quem decidiu: Felipe