Pular para conteúdo

Agente "Sobe Obras"

Objetivo: um agente conversacional que vive no Open WebUI (padrão Betão), usado por qualquer pessoa da equipe Bepex para publicar uma obra no site (CPT projetos) a partir de: links do Dropbox com as fotos, imagem principal separada, respostas a um roteiro de perguntas, e a categorização por produto. O agente gera a descrição no modelo padrão, pega cidade/estado e publica no WordPress já categorizado.

Status: v0 — plano inicial (2026-07-07). Nenhuma sessão de build executada. Aguardando inputs A+B do Rafael e a Sessão 0 (descoberta WP). Este README consolida o PLANO.md (fonte da verdade da arquitetura) e o progress_control.md (estado) da pasta-fonte.

1. Fundação técnica já descoberta

1.1 Como o Open WebUI conecta no n8n (padrão Betão — reaproveitar)

  • Open WebUI (https://n8n-openwebui.fetrtm.easypanel.host/, self-hosted EasyPanel, v0.10.1) é só a casca de chat. Toda a inteligência mora no n8n. Pipes em /admin/functions.
  • A ponte é uma função tipo Pipe ("N8N Pipe" da comunidade, customizada pela Bepex). Cada pipe vira um "modelo" no seletor do Open WebUI.
  • Pipes existentes → webhook n8n (host n8n-hook.bepex.com.br):
  • n8n_betao → /webhook/3dc7d59a-… (Betão Coach de Vendas)
  • n8n_betao_v2 → /webhook/betao2 (Betão Análise de Negócio, timeout 360s)
  • n8n_para_tudo → /webhook/v2/kowalski (Kowalski)
  • Contrato do pipe ↔ n8n: envia body.chatInput + body.sessionId; recebe o campo output (via Respond to Webhook). Bearer token compartilhado nas valves: ${OPENWEBUI_N8N_BEARER}.
  • Workflow n8n típico do Betão: chatTrigger + Webhook (auth cred openwebUI) → AI Agent (OpenRouter, ex. google/gemini-2.5-pro, cred Betão Openrouter Agente SESgn3rDg6E6qtJG) → memória Postgres (Postgres n8n v2 / 7F3gxDoPsQGjAbOW) → Respond to Webhook. Um Switch desvia mensagens Query: (geração de título do Open WebUI) pra não gastar o agente.

1.2 Como o site trata "obras" (WordPress)

  • Stack: JetEngine (Crocoblock) + Elementor + JetFormBuilder. Não é WooCommerce pra obras.
  • "Obra" = CPT projetos (rest_base: projetos). Ex.: obra id 13734 "Forum de Ipanema", URL https://bepex.com.br/projetos/<slug>/.
  • Categorização por produto = taxonomia aplicacoes-do-projeto (uma obra pode ter várias). Termos:
id nome slug nº obras
93 Fachada Metálica fachada-metalica 26
92 Brise Metálico brise-metalico 14
403 Revestimento Interno revestimento-interno 5
94 Forro Metálico forro-metalico 2
406 Guarda Corpos guarda-corpos 1
405 Brise Móvel brise-movel 0
404 Divisórias e Biombos divisorias-e-biombos 0
  • A página de obra exibe Cidade - Estado (ex. "Rio de Janeiro - RJ") acima do título, uma galeria e uma imagem principal. Esses são campos meta do JetEngine e NÃO aparecem no REST público (meta e acf vêm vazios; content.rendered também vem vazio — a página é montada por template Elementor/JetEngine puxando os campos meta).
  • Outros CPTs de contexto: tabela-de-materiais (taxonomias aplicacoes, modelo-disponivel), tabelas-de-design, downloads. Páginas de produto são page com taxonomias material e aplicacao.

1.3 O que ainda falta descobrir (só com login no wp-admin) — vira Sessão 0

  1. Slugs exatos dos campos meta JetEngine do CPT projetos: galeria, imagem principal/destaque, cidade, estado (ou campo único "localização"), campo de descrição.
  2. Formato de armazenamento das imagens (array de IDs de mídia? de URLs? string separada por vírgula? — JetEngine varia).
  3. Se a ligação obra↔produto é só a taxonomia aplicacoes-do-projeto ou também uma relação JetEngine com tabela-de-materiais/páginas de produto.
  4. Método de escrita da meta: JetEngine por padrão NÃO expõe meta com show_in_rest. Caminhos a validar: (a) registrar campos com show_in_rest + POST /wp-json/wp/v2/projetos; (b) REST próprio do JetEngine; (c) endpoint custom (mu-plugin); (d) reaproveitar um JetFormBuilder existente de cadastro de obra.
  5. Se já existe uma JetForm de "subir obra" — seria o caminho mais limpo (validação/curadoria já prontas) e o agente só alimentaria essa form.
  6. Como autenticar o n8n no WP: criar uma Application Password para um usuário editor/admin dedicado e testar POST /wp-json/wp/v2/media + criar projetos rascunho.

2. Arquitetura alvo

[Equipe Bepex]
     │  (chat)
     ▼
[Open WebUI]  modelo "Betão — Sobe Obras"
     │  pipe n8n (chatInput/sessionId → output)
     ▼
[n8n · WF-Sobe-Obra]  (novo workflow)
     │
     ├─ AI Agent (OpenRouter) — intake conversacional guiado:
     │     1. coleta link(s) Dropbox da galeria
     │     2. coleta imagem principal (separada)
     │     3. roteiro de perguntas sobre a obra  ← [PROMPT do Rafael, adaptado]
     │     4. cidade + estado
     │     5. produto(s) usado(s) → mapeia p/ termos `aplicacoes-do-projeto`
     │     6. gera descrição no modelo padrão      ← [MODELO do Rafael]
     │     7. mostra resumo e pede confirmação
     │
     └─ (na confirmação) → Sub-flow determinístico de publicação:
           a. Dropbox → baixa imagens (galeria + principal)
           b. upload cada imagem → WP media  (POST /wp-json/wp/v2/media, App Password)
           c. cria post `projetos` (título, descrição, status, featured_media, taxonomia)
           d. grava meta JetEngine (galeria, cidade, estado) — método definido na Sessão 0
           e. devolve a URL da obra → agente responde "publicado ✅ <link>"

Decisões de design (confirmadas com Rafael 2026-07-07):

  • Imagens são COPIADAS para a biblioteca de mídia do WP (não hotlink do Dropbox) — confiabilidade
  • SEO. Dropbox é só transporte.
  • Obra publicada DIRETO NO AR (status: publish). Como não há revisão humana pós, a etapa de confirmação no chat é obrigatória e reforçada: o agente mostra resumo completo (título, cidade/estado, produto(s), descrição, nº de fotos + qual é a principal) e só publica após "confirmo".
  • Imagens do Dropbox via LINK DE PASTA: a pessoa cola 1 link de pasta e o agente lista/baixa todas as fotos. A imagem principal é indicada à parte.
  • Escrita no WP via REST API + Application Password (Rafael loga o wp-admin; Claude gera as chaves na Sessão 0).
  • Reaproveitar o padrão dos pipes Betão (nova pipe + novo webhook), não mexer nos existentes.

3. Inputs pendentes do Rafael

# Input Bloqueia Status
A Prompt/roteiro de perguntas sobre a obra (pra adaptar) Sessão 3 ⏳ Rafael vai mandar
B Modelo/template da descrição da obra Sessão 3 ⏳ Rafael vai montar
C Acesso de escrita ao WP Sessões 0,1,2 ✅ Rafael loga wp-admin; Claude gera App Password
D Publicar rascunho ou direto? Sessão 2 ✅ Direto no ar (status: publish)
E Fonte das imagens Sessão 1 ✅ Link de pasta Dropbox

4. Quebra em sessões (orquestração)

Sessão 0 — Descoberta WP + recibo de escrita (BLOQUEADOR). Loga no wp-admin; extrai slugs/tipos dos campos meta JetEngine do CPT projetos; confere se produto é taxonomia e/ou relação; procura JetForm de obra existente; cria uma App Password; valida na prática um POST de rascunho de projetos via REST com imagem de teste + meta + taxonomia; apaga o rascunho. Entrega: referencia-tecnica.md (mapa de campos + receita REST validada) + App Password. Skills: wordpress-chrome-mcp + chrome-file-upload.

Sessão 1 — Pipeline Dropbox → WP Media. Sub-workflow n8n que recebe link(s) Dropbox, baixa as imagens (link público ?dl=1 ou Dropbox API) e sobe cada uma em POST /wp-json/wp/v2/media; retorna IDs + qual é a principal. Skills: n8n + n8n-bepex.

Sessão 2 — Sub-flow de publicação da obra. Caminho determinístico: cria projetos (título, descrição, status, featured media, taxonomia) e grava a meta JetEngine pelo método da Sessão 0. Devolve a URL. Skills: n8n + n8n-bepex.

Sessão 3 — Workflow do agente (conversa + intake) (precisa inputs A e B). Cria WF-Sobe-Obra (chatTrigger + Webhook openwebUI + OpenRouter agent + memória Postgres + Switch Query:); escreve o system prompt adaptando o roteiro (A); embute o modelo de descrição (B); dá ao agente a lista de termos aplicacoes-do-projeto; conecta a tool do sub-flow de publicação; define o fluxo de confirmação. Skills: n8n + n8n-bepex + n8n-bepex-teste-pipeline-e2e.

Sessão 4 — Pipe + modelo no Open WebUI. Clona a pipe n8n_betao → nova pipe apontando pro webhook de WF-Sobe-Obra; cria o modelo "Betão — Sobe Obras"; define permissão para o grupo da equipe. Skills: operação Open WebUI via Chrome + API (/api/v1/functions, /api/v1/models).

Sessão 5 — Teste E2E + handoff da equipe. Roda o fluxo completo com uma pasta Dropbox real, publica, valida no site (cidade/estado, galeria, principal, categoria, descrição), corrige o que faltar. Escreve doc operacional e registra o projeto. Skills: n8n-bepex-teste-pipeline-e2e + documentacao-projetos.

Grafo de dependências

S0 (WP discovery + App Password)  ── bloqueia ──▶ S1, S2
S1 (Dropbox→Media) ─┐
S2 (Publica obra)  ─┴─ (S2 usa S1) ── vira tool ──▶ S3
A (prompt) + B (modelo) ─────────────────────────▶ S3
S3 (Agente) ──▶ S4 (Pipe/Modelo Open WebUI) ──▶ S5 (E2E + handoff)

Caminho crítico: S0 → S1 → S2 → S3 → S4 → S5. S3 também espera A+B. S0 pode começar assim que houver acesso WP; A+B podem ser preparados em paralelo por Rafael.

5. Riscos e mitigação

  • JetEngine meta não escrevível via REST padrão → S0 testa e escolhe entre registrar show_in_rest, endpoint custom, ou reaproveitar JetForm. Não avançar S2 sem recibo verde.
  • Imagens grandes / muitas fotos → limitar tamanho, processar em lote, timeout do pipe alto (como betao2 usa 360s).
  • Qualquer um da equipe publicando → confirmação no chat obrigatória antes de publicar.
  • Sessão do n8n / Betão OpenRouter key emprestada → usar cred própria; não bater em auth do n8n.
  • Nunca subir arquivo via base64/DataTransfer no browser — no n8n é server-side (ok); em UI WP, seguir chrome-file-upload.

6. Lições acumuladas (a não repetir)

  • REST público do WP NÃO revela meta JetEngine — precisa wp-admin logado (Sessão 0).
  • Não mexer nos pipes/webhooks Betão existentes — criar novos.
  • list_workflows/get_workflow do n8n estouram token → parsear via arquivo salvo + jq/python.

7. Log de decisões

  • 2026-07-07 — Plano v0 criado. Descoberto: obra=CPT projetos, produto=taxonomia aplicacoes-do-projeto, campos são meta JetEngine (fora do REST público). Arquitetura = pipe Open WebUI → WF-Sobe-Obra (agente) → sub-flow de publicação. Pendências A–E abertas.
  • 2026-07-07 — Decisões Rafael: C = REST API + App Password; D = publicar direto no ar; E = link de pasta Dropbox. Reforçada a etapa de confirmação no chat (sem revisão pós-publicação). Faltam só A (prompt) e B (modelo descrição).

Segredo: o bearer compartilhado das valves Open WebUI ↔ n8n aparece como ${OPENWEBUI_N8N_BEARER} (Tier 1 → rotacionar; valor real no arquivo restrito de segredos).