@luanpdd/kit-mcp 1.21.0 → 1.26.0

package/kit/agents/crm-pipeline-implementer.md

@@ -140,8 +140,114 @@ CRM-PIPELINE-IMPLEMENTER · output
 - Histogram `crm.lead.time_to_close_days{org_id, won_or_lost}`
 - Alarme se `crm.lead.stage_change.count{to_stage='lost'} > baseline` → review pipeline
 
+## SELECT FOR UPDATE em Stage Transition (v1.22+ — default agora)
+
+A trigger `validate_lead_stage_transition` agora gera `SELECT ... FOR UPDATE` por default em rows lidas para prevenir lost update quando 2 reps movem o mesmo lead simultaneamente. Padrão completo em skill [`postgres-isolamento-concorrencia`](../skills/postgres-isolamento-concorrencia/SKILL.md) (v1.22 — DDIA Ch 7).
+
+Exemplo gerado:
+
+```sql
+CREATE OR REPLACE FUNCTION validate_lead_stage_transition()
+RETURNS TRIGGER AS $$
+BEGIN
+  -- v1.22+ DEFAULT: lock row para prevenir lost update
+  PERFORM 1 FROM leads WHERE id = NEW.id FOR UPDATE;
+  -- ... validação de transição ...
+END;
+$$ LANGUAGE plpgsql;
+```
+
+## Cooperative handoff to supabase-rls-hardener (v1.23)
+
+Após gerar CREATE TABLE leads (6 stages canônicos) + tabela lead_stage_transitions + trigger BEFORE UPDATE validate_lead_stage_transition + trigger AFTER UPDATE audit_lead_ownership_change, faça handoff cooperativo:
+
+```python
+Task(subagent_type="supabase-rls-hardener", prompt=f"""
+<upstream_intent>
+Source agent: crm-pipeline-implementer
+Original goal: implementar CRM lead pipeline com 6 stages canônicos para {org_context}
+Constraints: lead dedup (unique org_id,phone) + (unique org_id,email); state machine via trigger BEFORE UPDATE (não só CHECK constraint); ownership transfer com notification; integration WhatsApp lookup contact_phone
+</upstream_intent>
+
+<draft_sql>{generated_leads_sql}</draft_sql>
+
+<user_facing_caller>true</user_facing_caller>
+""")
+```
+
+Hardener valida policies por org_id, GRANTs corretos, trigger SECURITY DEFINER em schema private (se aplicável). **NUNCA descarte intent upstream silenciosamente**.
+
+## Cooperative handoff Postgres Roles (v1.26 — CROSS-21)
+
+Crie role `lead_manager` para acesso PII columns dos leads (phone, email, notes). Role dedicado complementa column-level GRANTs (v1.24 CROSS-13). Auditabilidade superior + governance.
+
+```python
+Task(subagent_type="supabase-roles-implementer", prompt=f"""
+<upstream_intent>
+Source agent: crm-pipeline-implementer
+Original goal: criar role lead_manager para acesso PII columns dos leads (cross-ref v1.24 column-level)
+Constraints: NÃO BYPASSRLS (deve respeitar org boundary via RLS hierárquica multi-tenant v1.21); column-level GRANT em phone/email/notes; login opcional (pode ser group usado por managers via SET ROLE)
+</upstream_intent>
+
+<roles_to_create>
+- name: lead_manager
+  type: group
+  login: false
+  bypassrls: false  # respeita org boundary
+  inherit: false
+  description: "Acesso PII columns dos leads (phone, email, notes). Usado por sales managers via SET ROLE."
+  owner: "sales-team@company.com"
+</roles_to_create>
+
+<grants>
+lead_manager:
+  - schema: public, usage: true
+  - table: public.leads, ops: [SELECT]  # column-level já aplicado via v1.24 CROSS-13
+</grants>
+
+<use_case>system_access</use_case>
+<user_facing_caller>true</user_facing_caller>
+""")
+```
+
+**Caveat:** este role complementa RLS row-level (org boundary) + column-level (PII). NÃO substitui auth.users + custom claims (v1.25) — lead_manager é Postgres role para DBA/sales-ops, não para end-user via app.
+
+## Cooperative handoff column-level (v1.24 — CROSS-13)
+
+Lead PII columns (phone, email) podem precisar de column-level restriction para LGPD compliance — apenas owner do lead ou lead_manager role vê os dados de contato completos. Aplique handoff cooperativo:
+
+```python
+Task(subagent_type="supabase-column-privileges-writer", prompt=f"""
+<upstream_intent>
+Source agent: crm-pipeline-implementer
+Original goal: lead PII columns (phone, email) com REVOKE select cross-user para LGPD compliance
+Constraints: lead.phone e lead.email são PII; visível apenas para owner (RLS) + lead_manager role (column-level); company_name e job_title públicos para membros da org
+</upstream_intent>
+
+<table>schema: public, name: leads</table>
+
+<sensitive_columns>
+- phone
+- email
+- notes (jsonb — pode ter PII em call notes)
+</sensitive_columns>
+
+<allowed_roles>
+- service_role: SELECT all
+- lead_manager: SELECT all (admin do CRM)
+- authenticated: SELECT (id, org_id, owner_id, company_name, job_title, stage, lead_value, created_at) — sem PII
+</allowed_roles>
+
+<user_facing_caller>true</user_facing_caller>
+""")
+```
+
+**Importante:** combinar com RLS row-level (owner vê próprio lead inteiro) — RLS filtra qual lead; column-level filtra quais colunas DENTRO do lead. Owner pode precisar SELECT phone do PRÓPRIO lead — considere policy `for select to authenticated using (owner_id = (select auth.uid()))` granted em todas colunas, e usar column-level apenas para cross-user (outro member da org tentando ver lead alheio).
+
 ## Ver também
 
+- [supabase-rls-hardener](./supabase-rls-hardener.md) — canonical handoff target v1.23
+- [supabase-column-privileges-writer](./supabase-column-privileges-writer.md) — canonical handoff target v1.24 (column-level lead PII)
 - [crm-lead-pipeline-patterns](../skills/crm-lead-pipeline-patterns/SKILL.md) — base de conhecimento
 - [evolution-go-integrator](./evolution-go-integrator.md) — Phase 112 (cross-phase handoff)
 - [supabase-migration-writer](./supabase-migration-writer.md) — invoked via Task() para SQL