docs(conectores): o cartão da política de dados pessoais dos conectores

docs/approvals.md

@@ -943,6 +943,12 @@ Decisões do fundador no meio da etapa (L6), antes da aprovação da página. Em
 
 Decisão do fundador no meio da etapa (L6), depois da aprovação do cartão, em 2026-11-11, sobre a gravação da U2 (as quatro respostas reais do Mercado Livre só podem ser lidas pelo Hub no ar, e o Hub no ar ainda recusa as entradas `order.date_last_updated.from`, `search_type=scan` e `scroll_id`): à pergunta da divisão (A: a U1 entra sozinha, a U2a leva só as declarações das leituras novas, sem dublê nem resposta inventada, e a U2b grava as quatro respostas pelo Hub depois que a U2a estiver no ar e faz o dublê, a conformidade e a skill; B: gravar com uma execução avulsa; C: esperar): "A". O cartão não muda, e a U2 entra em dois pull requests: a U2a, empilhada na U1, e a U2b, depois.
 
+## A política de dados pessoais dos conectores
+
+Cartão curto de A política de dados pessoais dos conectores (`docs/steps/a-politica-de-dados-pessoais.md`) aprovado em 2026-11-11 (commit 9656e2addf8984e5e6d9cfa9c884965411c26645), depois de ler o fluxo do cartão em quatro cenas (a dona pede o app ao Builder; outras pessoas abrem o app pela F1; um cargo sem tipos pede o mesmo app e o Builder explica e o Publicar para; o Assistente responde com nomes e sem CPF): "Gostei aprovado"
+
+Decisões do fundador antes da aprovação da página (L6). Em 2026-11-11, às perguntas do estudo da política de dados pessoais (A, quem vê dados pessoais de clientes; B, o que vai ao modelo; C, a cópia; D, os sensíveis; E, o advogado): "A1, mas seria uma capabilidade para criar e selecionar POR EXEMPLO PARA DAR PARA OUTRO cargo"; "B1, okay, mas como vamos tratar isso Fácil a gente selecionar um conhecimento específico, tipo CPF, mas eu sempre quero pensar na lógica, porque a gente vai trabalhar com a criação de vários conectores, de uma plataforma muito robusta. Qual que seria a lógica para a gente conseguir fazer isso, entende? Vale a pena? É uma gambiarra? Referências fazem? Entende meu ponto?"; "`C1` porém mesma coisa de B"; "D1"; "E Só vai vir depois". No mesmo dia, às decisões F (num app, de quem é o "pode ver"), G (a porta genérica do Sankhya) e H (o lugar no roteiro) da página do cartão (`docs/steps/a-politica-de-dados-pessoais.md`) no commit 30e2b034ca27eebb0f9559e3052b942d1eb06fcd: "F1, PORÉM QUERO entender a parte tencia de código arquitetura que vamos implementar isso de forma funcional / G Não vou limitar nada disso / H1". A página as escreve como decididas: F1, com a seção "Como funciona no código"; G, a porta genérica do Sankhya fora da política, sem trava nova, e o RH só pela frase da skill, como hoje; H1, logo depois do Sync e antes da Capacidade 4.
+
 ## Mudança de método: um pull request por grupo de unidades
 
 Em 2026-11-09, como mudança de método (L20), o fundador disse: "eu queria fazer é mudar a nossa regra de toda o 1C1PR, 1CI, né? Eu acho que seria no mínimo um conjunto de 3 etapas, tipo 1, o 2, o 3. Aí sim poderia subir um PR e aí rodar CI e tudo. Lógico que o nosso teste, né? A gente faz testes, né? Tipo, do 1, a gente teria fazer e testar e validar. Mas eu falo realmente subir e utilizar o CI, sabe? Para ser mais rápido, mais efetivo." E, aprovando o formato que o firstmate propôs (o cartão segue como pull request só de documentos, aprovado antes de qualquer código; o build vai num pull request por etapa, ou por grupo de unidades quando a etapa é grande; um commit por unidade, cada uma construída, testada e validada antes do seu commit; o revisor Opus lê commit a commit; o CI roda uma vez, no fim; o merge guarda os commits): "Sim, por exemplo U1, U2 e U3 seriam um PR por exemplo". Muda a L9, a L13 e as skills `conexus-build`, `conexus-review` e o cartão leve do padrão.