Wiki · Gustavo + Hermes

proposta-conteudo-v0

Leitura de 19 min

Sistema de conteúdo · proposta v0

22/10/2026 · autor: Hermes (subagente de pesquisa) · estado: 🟡 proposta, nada construído. Mapa: N1, nova sub-fábrica proposta “Conteúdo” (ver §3). Nada aqui publica, posta, assina serviço ou instala coisa.

Resumo em 10 linhas

  1. Ideia: um wiki em markdown (git) é a fonte única; cada post é uma “peça” gerada a partir de afirmações do wiki, nunca do zero.
  2. Camadas: fontes (imutáveis) → claims (1 afirmação + evidência + confiança C0 a C3) → peças por canal → verificar → gate Gustavo → publicar → medir → laço.
  3. Base: o padrão LLM Wiki do Karpathy (já é skill nossa) + COPE da NPR (conteúdo limpo, separado da apresentação) + notas atômicas do Matuschak.
  4. 5 tipos só: Fonte, Claim, Peça, Canal, Resultado (+ Playbook como saída do laço). Tudo markdown com frontmatter em ~/projects/conteudo.
  5. Notion é espelho: uma base “Peças” onde o Gustavo aprova pelo celular. Git manda; Notion só devolve status e edição.
  6. Verificar @codigo novo: todo número de uma peça tem que existir num claim ligado a ela (fact-check barato e rígido), além do lint atual do checar_textos.py.
  7. LinkedIn pessoal: postar por API existe, mas os termos da API proíbem “automate posting” e o User Agreement proíbe bot criando post. Fica copia e cola do Gustavo.
  8. X: postar pela API é permitido na própria conta (US0,015 por post, US0,20 com link), mas exige conta de dev e crédito. v1 também manual.
  9. Lugar no mapa: sub-fábrica compartilhada (como Marca), usada primeiro pela Carreira e depois por cada negócio da Incubadora. Não é fábrica nova.
  10. v1 em ~1 dia de Hermes: repo + SCHEMA + migrar os 10 rascunhos do CALENDARIO + checador novo + espelho no Notion. Sem site, sem API de post, sem pt-BR ainda.

3 decisões para o Gustavo

  1. Lugar no mapa: aprovar “Conteúdo” como sub-fábrica compartilhada (Carreira agora, Incubadora depois), e não como 4ª fábrica? (recomendo sim)
  2. Quando construir: Hermes faz o v1 agora, em paralelo, sem mudar as datas do calendário (1º post 27/10) e sem pedir horas suas além das aprovações? Ou espera a recontagem de 02/11? (recomendo agora, limitado a 1 dia, porque a migração dos 10 rascunhos já é o trabalho do calendário)
  3. Como publicar: v1 100% copia e cola (recomendo), ou liberar depois um agendador oficial (Typefully: Hermes cria rascunho, você clica “agendar”) e/ou crédito da API do X? E qual conta do X (pendência 1 do CALENDARIO)?

1. O que já existe lá fora (prior art)

Todos os links foram abertos ou confirmados por busca em 22/10/2026. Uma linha cada sobre o que copiar.

Wiki e notas

Criar uma vez, publicar em todo lugar

Atomizar: pilar → micro-conteúdo

Conteúdo estruturado (docs as code, headless CMS)

Publicar o wiki como site

  • Quartz · https://quartz.jzhao.xyz/ · copiar mais tarde: gera site estático a partir de markdown compatível com Obsidian (wikilinks, backlinks, grafo). Seria o “jardim digital” público com os claims C2+. Adiado para depois do v1.

Ferramentas que levam o texto até a rede

1b. Realidade de API e termos: o que dá para automatizar

LinkedIn, perfil pessoal

Conclusão LinkedIn:

  • Hermes pode: gerar, checar, formatar, mandar o texto final pronto para copiar (Telegram/Notion), lembrar o horário, registrar a URL.
  • Fica humano: colar e publicar (ou agendar no próprio LinkedIn), responder comentários, ler as métricas (print ou 3 números digitados no D+7).
  • Não fazer: postar pelo navegador logado com automação, nem ler analytics por script no navegador (é exatamente o que a página de “software proibido” descreve).

X

Conclusão X:

  • Pode automatizar (depois do gate): publicar o post ou thread aprovado na conta dele, sem link no corpo (US0,015 por post; uma thread de 3 custa ~US0,045). Exige criar conta de dev e comprar crédito, então é decisão dele.
  • Fica humano: respostas, likes, follows, DMs. Sempre.
  • v1: copia e cola, igual ao LinkedIn. O ganho de automatizar 2 posts por semana é ~2 minutos.

Canais nossos (depois, pt-BR)

  • Newsletter (Resend), blog estático: 100% automatizável depois do gate, porque a conta e a lista são nossas (critério “nosso vs alugado” da canais-distribuicao-v2.md).
  • Instagram: API de publicação só para conta profissional ligada a app Meta (já documentado na canais-distribuicao-v2.md).

2. Arquitetura recomendada

2.1 O cano, na notação do mapa

Dois canos e um laço. Vertical, para ler no celular.

ingerir : Fonte -> [Claim]
  fonte (experimento, dado GringaOK, nota de voz, link, página do Cérebro)
  | mapear @codigo (guardar em raw/, hash)     # Fonte imutável
  | expandir @llm (extrair afirmações)         # [Claim] C0
  | verificar @codigo (cada número existe na fonte? caminho + chave)
  | filtrar @llm (1 ideia só? vale para alguém além de mim?)
  | mapear @codigo (ligar a claims parecidos, marcar contradição)  # [Claim] C1

produzir : [Claim] -> [Peça]
  fila de temas (claims C1+ ainda não usados, ordem do playbook)
  | escolher @llm + @codigo (2 por semana, 1 por pilar)   # [Claim]
  | mapear @llm (por canal: template do canal + voice-dna)  # [Peça] C0
  | verificar @codigo (lint do canal: tamanho, travessão, link, hashtag, emoji, palavras proibidas, 1 pergunta no fim)
  | verificar @codigo (fact-check: todo número da peça está num claim ligado; claim dentro da validade)
  | verificar @llm (crítica com nota 1 a 5: gancho, voz, clareza; defeito com camada culpada)
  | gate Gustavo (Notion no celular)           # Peça aprovada + hash do texto
  | mapear @humano (publicar: copia e cola)    # Peça publicada + URL
  | mapear @humano (ler métricas no D+7)       # Resultado

aprender : [Resultado] -> Playbook   ↺
  resultados (a cada 8 peças ou mensal)
  | reduzir @llm + @codigo (o que funcionou por pilar, gancho, formato, horário)  # Playbook C1/C2
  | gate Gustavo (aceita a mudança)
  ↺ ajusta: templates dos canais · ordem da fila de temas · lista de palavras do lint

Regras herdadas da LINGUA:

  • Tudo que sai de @llm nasce C0 e passa por verificar antes do gate.
  • Defeito marcado com a camada culpada: peça (só este texto), template (do canal), claim (afirmação errada ou fraca), voz (voice-dna). O mesmo defeito em 3+ peças sobe de camada.
  • “Publicar” e “medir” não são verbos novos: são mapear @humano.

2.2 Os 5 tipos (campos mínimos)

Cada arquivo é markdown com frontmatter YAML. O corpo é texto livre.

Fonte (raw/, imutável, o agente nunca edita)

  • id, tipo (experimento · dado · nota-de-voz · link · conversa · cerebro)
  • origem (caminho no disco ou URL), sha256 (do arquivo original), capturada_em
  • custo (se houve, ex. US$0,08), privada (sim/não: nota de voz e setup pessoal nascem privadas)
  • Corpo: resumo de 3 a 5 linhas. Arquivo grande (ex. sample.json) não é copiado: a Fonte aponta para ele e guarda o hash.

Claim (wiki/claims/, uma afirmação por arquivo)

  • id, afirmacao (1 frase, sem tom de canal)
  • numeros (lista: valor, unidade, de onde sai, ex. 688 · fonte: f-teste-a-sample-1018 · chave funnel.latam_engenharia; derivados com a conta, ex. 94% = 646/688)
  • fontes (ids), confianca (C0 a C3), vale_ate (data em que o dado envelhece; ex. janela de 14 dias)
  • pilar (dado · experimento-ia · agentes · …), dominio (carreira · incubadora · negócio X), publico (EM/founder US · dev BR · clínicas)
  • relacionadas, contesta (id de claim que contradiz), usada_em (ids de peças, preenchido por código)
  • Corpo: o raciocínio e as ressalvas (“n pequeno”, “uma janela só”).

Peça (pecas/AAAA-MM/, uma por canal)

  • id, canal, formato (post · thread · carrossel · e-mail · artigo), claims (ids), gancho
  • estado: rascunho → verificada → aprovada → publicada → medida (ou vetada)
  • data_planejada, imagem (caminho), template_versao, voz_versao
  • aprovado_hash (sha do texto que o Gustavo aprovou; texto mudou = volta ao gate, igual ao Outbound)
  • url, publicada_em, defeitos (lista com camada culpada)
  • Corpo: o texto final, exatamente como vai para a rede.

Canal (canais/<id>/CANAL.md + template.md)

  • id (ex. linkedin-gustavo, x-gustavo, depois newsletter-gringaok), plataforma, conta, idioma
  • publico, objetivo e metrica_principal (ex. contatos de EM/founder T1/T2 por post)
  • regras (lidas pelo lint: máx. caracteres, link no corpo sim/não, hashtags máx., thread máx., pergunta no fim)
  • cadencia (ex. ter e qui, 08:00 a 09:00 BRT), modo_publicacao (manual · api-depois-do-gate), dono, estado (✅ 🟡 ❌ 💤)

Resultado (resultados/resultados.jsonl, uma linha por medição; append-only)

  • peca, medido_em (D+1, D+7, D+28), impressoes, reacoes, comentarios, seguidores_novos
  • contatos_qualificados (EM/founder/T1/T2 que chegaram pelo post), como_medi (print · digitado · API), confianca

Saída do laço: Playbook (playbook.md, versionado no git): regras com confiança, ex. “gancho com número na 1ª linha > pergunta na 1ª linha (C2, 6 peças)“.

2.3 Onde os arquivos vivem

Repo git novo em ~/projects/conteudo (fonte da verdade):

conteudo/
  README.md            # 1 página, linguagem simples: como funciona
  SCHEMA.md            # tipos, campos, regras (o "SCHEMA" do LLM Wiki)
  index.md             # catálogo de claims por pilar (gerado)
  log.md               # o que entrou e mudou (append-only)
  raw/                 # Fontes (cartões + arquivos pequenos copiados)
  wiki/claims/         # um claim por arquivo
  wiki/temas/          # páginas-hub por pilar (links para claims)
  canais/linkedin-gustavo/  CANAL.md + template.md
  canais/x-gustavo/         CANAL.md + template.md
  pecas/2026-10/ ...   # uma peça por canal
  assets/img/          # imagens das peças (com hash)
  resultados/resultados.jsonl
  playbook.md
  tools/checar.py      # lint por canal + fact-check (evolui o checar_textos.py)
  tools/calendario.py  # gera views/CALENDARIO.md a partir das peças
  tools/notion_sync.py # espelho no Notion
  views/CALENDARIO.md  # gerado, nunca editado à mão
  • A voz não é copiada: SCHEMA.md aponta para ~/projects/career/voice-dna.md (uma fonte só). Mais tarde, negócios pt-BR ganham voz/<negocio>.md.
  • O Cérebro do Notion continua sendo o lugar dos aprendizados de fora (livros, links). Quando uma página do Cérebro vira matéria-prima de post, ela entra aqui como Fonte tipo: cerebro com o link. Sem duplicar os dois sistemas.

2.4 Como o Notion espelha (aprovação pelo celular)

  • Uma base nova ”📣 Peças” na raiz do Hermes. Campos: Gancho (título), Canal, Data, Estado, Pilar, Claims (texto com o resumo de cada claim e a confiança), Link no git. Corpo da página = o texto final + a imagem.
  • Ida (git → Notion): notion_sync.py cria ou atualiza a página quando a peça fica “verificada” e avisa no Telegram/Discord: “3 peças para aprovar”.
  • Volta (Notion → git), só 2 coisas:
    • Estado: Gustavo troca para “Aprovada” ou “Vetada” (com comentário). Hermes grava aprovado_hash no git.
    • Edição: se ele editar o texto no Notion, Hermes puxa para o git, roda o verificar de novo e avisa se o lint falhou. Edição dele conta como aprovação daquele texto.
  • Na hora de publicar: Hermes manda o texto final no Telegram em bloco fácil de copiar + a imagem. Ele cola, publica e responde com a URL (ou Hermes pergunta no dia seguinte).
  • Conflito: git manda. O Notion nunca é editado por dois lados ao mesmo tempo porque só o estado e o corpo voltam.

2.5 Migração do que já existe (sem mexer nos originais)

Os arquivos de hoje ficam intactos; o v1 lê e copia.

  • CALENDARIO.md (10 seções) → 20 Peças (10 LinkedIn + 10 X) em pecas/2026-10/ e pecas/2026-11/, estado “verificada” (não “aprovada”: o Gustavo ainda não aprovou nenhuma).
    • A tabela do topo vira views/CALENDARIO.md, gerado.
    • A linha “Fonte:” de cada seção vira Fontes + Claims (ex. post 1 vira os claims “688 vagas, 42 reais” e “94% some antes de aplicar”, com os números e a conta 646/688).
    • “Mudanças vs v2” e “Nota” viram histórico no corpo da Peça.
    • “Pendências para o Gustavo” vira itens de decisão no README (e continuam no CALENDARIO original).
    • Post 7 (precisa refresh n=19): o claim ganha vale_ate, e o fact-check bloqueia a peça até o dado novo entrar.
  • experimentos/*-resultados.md (nondet, json, judge, colapso de ideias e de listas) → 5 Fontes tipo: experimento, apontando para os scripts e o _raw.json; cada uma rende 2 a 4 claims. cost_log.jsonl fica onde está; a Fonte guarda o custo total.
  • ../../teste-a/data/sample.json e dado_semana.json → Fontes tipo: dado (só ponteiro + hash, sem copiar).
  • img/*.png e ../linkedin-v2/img/* → assets/img/ com hash; a Peça aponta para a cópia.
  • linkedin-v2-baseline.md → primeira linha de resultados.jsonl (baseline do canal: 605 seguidores, 0 impressões em 28 dias).
  • checar_textos.py → tools/checar.py: mesma lógica, mas lê uma peça por arquivo e pega as regras do CANAL.md (hoje elas estão fixas no código). Antes de trocar, rodar os dois nos 10 rascunhos e conferir que dão o mesmo resultado.
  • gerar_imagens_4sem.py → fica fora do v1; a Peça só referencia a imagem.

3. Lugar no mapa

Opções:

  • Fábrica nova no N1 (4ª, ao lado de Incubadora, Automações, Carreira): exagero. Conteúdo não tem meta própria; ele serve à Carreira (C6, 10% das horas, “amplificador, não fonte”) e aos negócios.
  • Dentro da Carreira: resolve hoje, mas quando um negócio da Incubadora precisar de newsletter ou Instagram, teríamos um segundo sistema igual.
  • Sub-fábrica compartilhada (recomendo), como a Marca: “Conteúdo : Canal (briefing) -> cano de produção daquele canal”. É fábrica porque a saída é outra caixa: cada canal novo (LinkedIn do Gustavo, newsletter do GringaOK, Instagram de um negócio) é uma instância com template, voz, cadência e métrica, rodando no mesmo wiki e no mesmo verificar.

Como desenhar no N1:

  • Sub-fábrica “Conteúdo” listada uma vez, com duas setas de uso: Carreira → (canais de atrair, C6) e Incubadora → (negócio passou do dia 14 → ganha canais). Igual à regra da Marca: negócio em teste não ganha sistema de conteúdo completo.
  • Liga com a Marca: a Marca entrega tokens e voz verbal do negócio; o Conteúdo usa como voz/<negocio>.md e template visual.
  • Liga com a Base: roda na VM do Hermes; Notion é só superfície de leitura e aprovação.
  • Δ mapa (se aprovado): N1 ganha a sub-fábrica Conteúdo; a caixa “Conteúdo” da Carreira passa a apontar para ela; registrar em DELTA.md.

4. v1 mínimo, o que adiar e riscos

v1 (~1 dia de Hermes, zero hora do Gustavo além de aprovar)

  1. Criar o repo ~/projects/conteudo com README, SCHEMA, index, log (git init).
  2. Canais: linkedin-gustavo e x-gustavo (regras tiradas do checar_textos.py e do topo do CALENDARIO).
  3. Migrar: 10 rascunhos → 20 Peças; fontes dos 10 → ~8 Fontes e ~15 a 20 Claims.
  4. tools/checar.py: lint por canal + fact-check de números + validade do claim. Critério de pronto: dá o mesmo resultado do checar_textos.py nos 10 rascunhos e pega pelo menos 1 número plantado errado num teste.
  5. tools/calendario.py: gera views/CALENDARIO.md.
  6. tools/notion_sync.py: base ”📣 Peças”, ida + volta do estado. Se o dia acabar antes, este passo fica para o dia 2 e as aprovações seguem como hoje.
  7. Uma skill curta (“content-system”) com o passo a passo, para o Hermes não reinventar.

Não muda nada no calendário: o post de 27/10 sai igual, só que lido da Peça.

Adiar (e o gatilho para trazer)

  • Canais pt-BR dos negócios (newsletter, Instagram, blog): quando um negócio passar do dia 14.
  • Postar por API (X) ou via Typefully: só se a decisão 3 liberar e copiar e colar virar gargalo de verdade.
  • Site público com Quartz: quando houver 30+ claims C2 que valham como “página de provas” viva.
  • Ingestão automática de notas de voz e do pipeline GringaOK: quando o ritmo passar de 2 peças por semana.
  • Laço automático do playbook: depois de 8 peças medidas (antes disso é ruído).
  • Geração de imagem por template, vídeo curto, YouTube.
  • Métricas por API do LinkedIn: não existe para nós (exige aprovação de empresa); fica manual.

Riscos e como travar

  • Buraco de coelho (TDAH) contra a busca de emprego. Construir sistema é mais gostoso que mandar candidatura. Trava: o Gustavo não constrói nada; o v1 tem limite de 1 dia de Hermes; Conteúdo continua com 10% das horas da estratégia; a recontagem de 02/11 e a decisão de 09/11 decidem se o canal continua. Se o C6 morrer (0 contato de EM/founder), o sistema congela no estado em que estiver.
  • Engenharia demais. 5 tipos, arquivos, um script de checagem, uma base no Notion. Nada de banco, CMS, site ou agendador no v1. Regra: tipo ou campo novo só entra se 3 peças precisarem dele.
  • Ban ou restrição de conta. LinkedIn: nada de automação no navegador para postar ou ler métricas (User Agreement e API Terms). X: nada de like, follow, resposta ou DM automática; não postar texto idêntico em várias contas quando os negócios tiverem perfis próprios (adaptar por canal, não copiar).
  • Erro factual em público. O fact-check por código bloqueia número sem claim; claim vencido bloqueia a peça; crítica @llm aponta afirmação forte demais para a confiança do claim (C1 não vira “sempre”).
  • Cara de texto de IA. Lint de palavras proibidas + voice-dna + o olho do Gustavo no gate. Defeito de voz repetido 3 vezes sobe para o template ou para a voice-dna.
  • Privacidade. Fonte nasce privada quando é nota de voz ou setup pessoal; peça que usa claim privado avisa no gate (ex. post 4, que expõe impostos, banco e backup).
  • Notion e git divergindo. Só estado e corpo voltam do Notion; git é a verdade; sync roda antes de cada aviso de aprovação.

Fontes conferidas nesta proposta

  • Links do §1 e §1b, abertos ou confirmados por busca em 22/10/2026. Os 2 trechos mais importantes foram lidos no navegador: preços do X (docs.x.com) e a cláusula “automate posting” (LinkedIn API Terms).
  • Não consegui abrir a página oficial de regras de automação do X (verificação anti-bot do Cloudflare); usei transcrição de terceiro datada de 08/10/2026 e marquei como fonte secundária.
  • Arquivos locais lidos (não alterados): mapa/LINGUA.md, mapa/N1.md, incubadora/testes/conteudo-4sem/CALENDARIO.md e checar_textos.py, career/voice-dna.md, incubadora/canais-distribuicao-v2.md, career/estrategia-canais-v1.md, skills llm-wiki e second-brain-notion.

Visão de gráfico