Ghost System v0.1
A Jornada

A dor de partida

GL7 tem 7 clientes ativos, mas a maquina propria de demanda anda no zero. Ferramentas existem, dinheiro gasto existe, lead chegando existe — o que falta e cola.

O diagnostico 5W2H

• O que: funil comercial GL7 fragmentado em 4 silos.
• Onde: Framer (captura) -> ??? -> SendPulse (email, subutilizado) -> ??? -> Reuniao Fathom -> planilha manual.
• Por que doeu: lead aberto/clicado nao escalava pra Jordan, Celso rodava trafego sem feedback de conversao por fonte, Thiago tinha insight virar tarefa no chat e sumir.
• Quanto: 85 referencias dispersas a SendPulse em docs e chats, 0 workflows core n8n vivos pra funil, Fathom 100% manual ate virar card CRM.
• Quando: diagnostico puxado no inicio da sessao 2026-04-14, apos semanas de discussao solta com Mateus sobre "maquina de lead".

Ferramentas isoladas, fio quebrado

A dor nao era "falta uma ferramenta nova". Era "existem 5 ferramentas e nenhuma sabe da outra". Escolher construir mais um SaaS seria vibe coding disfarcado de progresso. A resposta tinha que ser orquestrar.

O sonho: Ghost System

Uma camada fina. Um orquestrador, nao um construtor. O musculo operacional do Metodo GHOST.

A sacada-chave: separar doutrina de musculo. O Metodo GHOST (SEO-CTO7) ja existia como pensamento — KW research, clusters, pilares Consultoria -> Leads -> Vendas -> AUTO & AI. O que nao existia era um sistema que executasse essa doutrina dia a dia. Esse sistema virou o Ghost System.

Principios nao-negociaveis

• Camada fina: zero reescrita de Framer/SendPulse/n8n/Fathom. Ghost System e cola, nao motor.
• Brain-first: cada lead vive como markdown em brain-claude/08-memory/leads/. Git e versionamento ganha de CRM fechado.
• Free-tier first: tudo roda no que GL7 ja paga. Zero subscription novo ate bater limite real.
• AKITA7 GREEN: se nao tem test, nao e pronto. Evidence before assertions.

O plano: 4 decisoes criticas

Antes de escrever uma linha de codigo, Claude travou 4 perguntas bloqueadoras. Cada resposta mudou o escopo.

A arquitetura

4 etapas, 1 bus, 3 camadas de memoria. Fronteira rigida com traffic7 do Mateus: Ghost System consome sinais de trafego, nunca chama API de midia.

Tabela componente -> ferramenta -> papel

O contrato: lead canonico

Se cada etapa falar uma lingua diferente, a cola quebra. O lead canonico e a unica verdade — schema YAML versionado. Campo novo = ADR novo.

Schema YAML v0.1

lead_id: tdb-260414-a1b2c3   # <origem>-<YYMMDD>-<hash6>
created_at: 2026-04-14T09:00:00-03:00
origem: tdb              # tdb | olv | gl7 | sup | ...
source: framer_lp_master7
state: nurturing       # new|contacted|nurturing|sql|proposal|won|lost
score: 45                 # 0-100, threshold SQL = 60
owner: jordan            # thiago|mateus|jordan|celso
contact:
  name: "Joao Silva"
  email: joao@exemplo.com
  phone: "+5511999..."
journey:
  - {at: "2026-04-14T09:00", event: form_submit, delta: 0}
  - {at: "2026-04-14T10:15", event: email_open,  delta: +20}
tags: [b2b, automation]
notes: |
  markdown livre aqui

State machine

Scoring rules v0.1

• email_open +20
• email_click +30
• email_reply +50
• form_resubmit +15
• Threshold SQL = 60. Acima disso, workflow sell-handoff dispara Telegram pro owner.

A construcao: 43 arquivos em paralelo

Ultra Think multi-agente. 4 agents Claude rodando simultaneo, cada um com briefing denso isolado. Resultado: Fase 0 fechada em ~5 minutos de paralelo.

O pattern Ultra Think e uma das descobertas que ficou salvo em memoria (feedback_ultra_think_multi_agente): quando a tarefa pode ser particionada em escopos isolados, vale a pena spawar 3-4 agents numa so mensagem, cada um com briefing saturado. Ghost System foi o segundo caso validado, depois do Brain Sync GL7.

Wave 1 — Scaffolding (4 agents em paralelo)

Wave 2 — Codigo real + workflows + seeds

• Skill ghost-system-gl7 criada em ~/.claude/skills/ + espelho Antigravity + SKILLS-INDEX atualizado
• Scripts Python reais: lead-schema-validate.py, cockpit-render.py, traffic7-bridge.py, sendpulse-sync.py
• 4 workflows n8n em JSON: capture-normalize, nurture-scoring, sell-handoff, cockpit-cron
• 6 leads fixture: 3 TDB (dogfood Thiago) + 3 OLV (Mateus co-aprovou)
• Tests unittest stdlib-only: test_cockpit_render.py + test_schema_validate.py
• Cockpit.md, metrics.md, runbook.md, changelog.md, BACKLOG.md, visual-cheatsheet.html, README.md

O codigo: Python real AKITA7 GREEN

1174 linhas Python stdlib-only. Parser YAML proprio (sem PyYAML). 21/21 tests green. Red -> Green -> Refactor documentado com bug real.

Por que stdlib-only

MALWARE-GATE7 + PYTHON7 (stdlib-first) + Free-tier first. Cada pip install e uma superficie nova de supply chain. Pra um parser YAML que le 10 campos, escrever 60 linhas de parser proprio e mais seguro e mais rapido que instalar PyYAML. Build to Earn, nao Build to Learn.

Os scripts

Red -> Green -> Refactor (bug real)

Isso e Anti Vibe Coding na pratica: nao foi "ah, deve estar OK, segui o happy path e subi". Foi red -> green -> refactor com commit granular. Cada assertion de "funcionando" ancorada em output de teste real.

Os workflows: 4 pipelines n8n

28 nodes total. Cada workflow cobre 1 etapa do funil. Tudo importavel em n8n self-hosted via JSON na VPS Master7.

Total: 28 nodes. Os 4 JSONs vivem em scripts/ghost-system/workflows-n8n/ e estao prontos pra importar via UI n8n ou via API n8n import:workflow.

O piloto: TDB em dogfood

Por que TDB? Porque e a brand pessoal do Thiago. Zero risco cliente externo. Ja tem projeto Reportei ativo. Regra do Espelho: aplicar em GL7 primeiro, depois cliente.

3 fixtures TDB

Journey do Pedro Costa (SQL crossed)

Esse fluxo nao e mock. E o que o cockpit.md renderiza quando voce roda python3 cockpit-render.py contra os fixtures. Pedro aparece na coluna SQL com alerta "new handoff".

O segundo piloto: OLV (Mateus co-aprovou)

No meio da sessao, Mateus Busson entrou, leu o visual-cheatsheet.html, aprovou Ghost System e autorizou rollout paralelo em OLV. Virou o segundo piloto.

3 fixtures OLV

Owner dos 3 fixtures OLV: mateus. O mesmo cockpit.md que renderiza TDB renderiza OLV — basta filtrar por origem: olv. Prova arquitetural de que multi-cliente e so parametro, nao codigo novo.

O que falta: P0 Thiago (90min)

Codebase 100% pronta. 8 itens bloqueados aguardando desbloqueio manual do Thiago. Total estimado: 90 minutos. Nada depende de terceiros.

Total ~90 minutos. Quando Thiago desbloquear esses 8 itens, Fase 1 fecha oficialmente com certificacao AKITA7 GREEN. Ate la, o status honesto e: Fase 0 ✅ · Fase 1 codebase pronta · deploy pendente.

O que vem depois

Ghost System v0.1 e o minimo viavel pra desdefazer a defasagem. v0.2 e v0.3 ja estao mapeadas no BACKLOG — mas nada entra sem passar pelo CFO-first-gl7.

Fase 2 — Hardening (proximos ~30 dias)

• Event log append-only em 08-memory/ghost-system/events.jsonl (hoje e so git diff)
• HTML cockpit dinamico servido pela VPS Master7 (hoje e markdown estatico)
• Metrics reais: CAC por origem, LTV estimado, taxa new->sql, taxa sql->won
• OLV paralelo com TDB — primeiros leads reais via LP Oliver's
• Backup workflows n8n versionado em git (auto-export via API)

Fase 3 — Escala (backlog, gated por CFO-first)

• Chatwoot integrado pra chat multi-canal (WhatsApp + web)
• ML scoring dinamico (substituir regras estaticas por modelo)
• Portal cliente read-only (ver proprio pipeline)

Fase 2 Codebase — O ponto de equilibrio

Mateus aprovou, Thiago ficou com os 8 P0 parkados no PMO, e a sessao ganhou mais 2 horas de codigo. Resultado: Ghost System saiu de "codebase Fase 1 pronta" pra "codebase Fase 2 blindada" — sem tocar uma unica linha de back-end.