🏗️ Construção e Escala

O sistema TRIAD completo tem seis componentes principais interconectados: Hermes Agent (orquestrador central), soul.md (contexto pessoal), OpenRouter (hub de modelos), Pantheon (interface de personas), Gemini CLI (capacidade multimodal) e os três modelos do Triad (Opus/DeepSeek/GPT). O Hermes é o hub que conecta todos os outros — nenhum componente se comunica diretamente com outro sem passar pelo Hermes.

Ter o mapa completo antes de construir evita arquiteturas que funcionam em testes mas quebram em produção. Cada componente tem dependências claras de outros — entender o grafo de dependências é o primeiro passo.

Hermes como hub central · soul.md como fonte de contexto · OpenRouter como camada de abstração · Pantheon como interface · Gemini CLI como ferramenta externa · Três modelos por papel.

O Hermes controla: roteamento de tarefas para o modelo correto baseado no tipo de tarefa e persona ativa; carregamento e aplicação do soul.md como contexto; gerenciamento de memória entre sessões; invocação de ferramentas externas (CLIs, APIs, arquivos); agendamento de jobs para execução assíncrona; logging de todas as decisões e custos.

Entender o que o Hermes controla define o que você não precisa controlar manualmente. Cada função do Hermes que você configura corretamente é trabalho que você não precisa fazer a cada tarefa.

Roteamento de tarefas · Contexto via soul.md · Memória entre sessões · Invocação de ferramentas · Agendamento assíncrono · Logging centralizado.

O OpenRouter fica entre o Hermes e os provedores de modelos. O Hermes faz uma chamada ao OpenRouter com o nome do modelo e o payload — o OpenRouter lida com autenticação, roteamento para o provedor correto, fallbacks, rate limiting e billing. Para o Hermes, todos os modelos têm a mesma interface. Para o usuário, todos os custos aparecem em um único lugar.

A camada de abstração é o que torna o sistema extensível. Adicionar um novo modelo ao Triad é apenas configurar o nome do modelo no Hermes — o OpenRouter lida com todo o resto.

Abstração de provedor · Interface única · Fallback transparente · Billing centralizado · Extensibilidade sem mudança de código.

O soul.md é a fonte única de verdade sobre o usuário. O Hermes carrega o soul.md no início de cada sessão e injeta o contexto relevante em cada chamada de modelo. Não existe outra forma de contexto persistente fora do soul.md e do histórico de memória do Hermes — tudo que você quer que o agente saiba precisa estar em um desses dois lugares.

Entender que o soul.md é a fonte única de contexto evita a tentação de adicionar instruções ad-hoc em cada conversa. Se algo é importante, vai para o soul.md — não para o chat.

Single source of truth · Injeção automática de contexto · soul.md vs histórico de memória · Contexto ad-hoc vs persistente · Atualização do soul.md como manutenção.

O Pantheon é a camada de gerenciamento de personas — onde você cria, edita, versiona e invoca as personas do Hermes. Cada persona é um conjunto de: system prompt, modelo configurado, ferramentas disponíveis e metadados. O Pantheon persiste as personas em ~/.hermes/pantheon/ como arquivos YAML. A interface visual é opcional — o Hermes pode ler as personas diretamente dos arquivos.

Entender o Pantheon como interface de controle permite gerenciar as personas de forma sistemática — não como instruções soltas em conversas que se perdem.

Persona como arquivo YAML · ~/.hermes/pantheon/ · Interface visual vs arquivo · Versionamento de personas · Invocação por nome.

O Gemini CLI é a ferramenta especializada para tarefas que os outros modelos do Triad não fazem bem: análise de vídeo, análise de imagens em detalhe, leitura de PDFs longos com raciocínio visual, e análise de código visual (screenshots de UI). No ecossistema TRIAD, o Gemini CLI é uma ferramenta invocada pelo Hermes quando a tarefa tem componente visual que outros modelos não processam adequadamente.

Saber o papel específico do Gemini CLI no ecossistema evita usá-lo onde outros modelos são mais eficientes e garante que você o usa onde ele é insubstituível.

Especialização multimodal · Vídeo, imagem, PDF visual · Hermes como invocador · Quando Gemini vs quando OpenRouter · Insubstituível para análise visual.

O fluxo de uma tarefa estratégica no TRIAD: (1) usuário aciona Orpheus com objetivo; (2) Hermes carrega soul.md e contexto relevante; (3) Conductor (Opus via OpenRouter) interroga o usuário; (4) Hermes passa briefing ao Worker; (5) Worker (DeepSeek via OpenRouter com BYOK) executa de 3-5 ângulos; (6) loop Worker-Crítico (GPT-5.5 via OpenRouter) até SHIP; (7) Conductor valida e Hermes armazena resultado em memória; (8) Hermes notifica o usuário.

Ver o fluxo completo revela os pontos de configuração críticos — cada transição entre componentes precisa de uma configuração correta para funcionar.

Oito etapas do fluxo · Transição entre componentes · Pontos de configuração · Memória pós-tarefa · Notificação de conclusão.

Os pontos de extensão do sistema TRIAD: novos modelos (adicionar ao OpenRouter sem mudar o Hermes); novas personas (criar em ~/.hermes/pantheon/ e sincronizar); novas ferramentas de CLI (instalar e registrar no Hermes via hermes tools add); integrações externas (Webhook para N8N/Zapier/Telegram); soul.md expandido (novas seções conforme novos domínios de vida); novos loops de Triad (para casos de uso específicos com modelos distintos).

Conhecer os pontos de extensão permite planejar o crescimento do sistema sem precisar redesenhá-lo. O TRIAD foi projetado para crescer incrementalmente.

Extensão via OpenRouter · Novas personas como YAML · Ferramentas via CLI · Webhooks como integrações · soul.md como contêiner extensível · Loops Triad customizados.

O Pantheon é o painel de controle do Hermes para personas e skills. A interface visual — acessível via hermes pantheon — exibe todas as personas criadas, seus modelos configurados, o histórico de invocações e métricas de uso. Sem a interface visual, personas existem apenas como arquivos YAML em ~/.hermes/pantheon/ — funcionais mas difíceis de gerenciar quando você tem mais de 3.

A interface visual torna o gerenciamento de personas escalável. Com 5+ personas, você precisa ver a diferença entre elas rapidamente sem abrir arquivos individuais.

hermes pantheon · Arquivo YAML vs interface visual · Histórico de invocações · Escalabilidade com muitas personas · Visual como gerenciamento.

O dashboard do Pantheon tem quatro painéis: Personas ativas (lista com nome, modelo, data de criação e última invocação); Skills (configurações de comportamento reutilizáveis compartilhadas entre personas); Histórico (log das últimas invocações com duração, custo e resultado); Spend (custo acumulado por persona e por período). O painel de Spend é especialmente útil para identificar quais personas têm o melhor ROI.

Entender a estrutura do dashboard antes de acessá-lo permite navegar com propósito. Cada painel serve a uma função específica de gerenciamento.

Quatro painéis do dashboard · Personas vs Skills · Histórico de invocações · ROI por persona · Spend como feedback.

Para criar uma persona no Pantheon: abrir o dashboard com hermes pantheon; clicar em "Add Persona" ou pressionar n; preencher nome (único, sem espaços), descrição de uma linha, e quando invocar; selecionar o modelo orquestrador; colar ou escrever o system prompt no editor integrado; configurar ferramentas permitidas; salvar. O Pantheon valida a configuração e exibe a nova persona imediatamente.

O passo a passo completo evita configurações incompletas que resultam em personas que existem mas não funcionam corretamente.

Fluxo de criação · Validação automática · Nome único sem espaços · Editor integrado de system prompt · Ferramentas por persona.

Para editar uma persona existente: selecione-a no dashboard → clique em "Edit" → modifique o system prompt no editor integrado → salve. O Pantheon mantém versões anteriores automaticamente em ~/.hermes/pantheon/[nome]/versions/. Para reverter: hermes pantheon revert [nome] --version [número]. Boas práticas: commite a pasta ~/.hermes/pantheon/ em um repositório git privado.

Personas são documentos vivos — você vai querer ajustar o system prompt do Orpheus depois de cada uso real. Versionamento garante que você pode voltar a uma versão que funcionou bem.

Versionamento automático · ~/.hermes/pantheon/versions/ · hermes pantheon revert · Git para histórico · Evolução controlada de personas.

Após criar ou editar uma persona no Pantheon, sincronize com o Hermes: hermes pantheon sync. O Hermes carrega as personas atualizadas e confirma via resposta no chat. Alternativa via prompt: "Hermes, sincronize o Pantheon e confirme quais personas estão disponíveis". O Hermes lista as personas carregadas com seus system prompts resumidos.

A sincronização é necessária porque o Hermes pode estar rodando com uma versão desatualizada das personas se você editou os arquivos diretamente. Sincronizar garante que o Hermes usa a versão mais recente.

hermes pantheon sync · Versão em memória vs arquivo · Confirmação de carga · Prompt de sincronização · Versão desatualizada como bug silencioso.

O Pantheon pode exibir dados de uso do Claude Code (sessões, modelos usados, custo por projeto) quando integrado via hermes setup integrations --claude-code. Com essa integração ativa, o dashboard do Pantheon mostra uma visão unificada de todo uso de IA no computador — tanto via Hermes quanto via Claude Code.

Custo total de IA por projeto é impossível de calcular sem uma visão unificada. A integração Hermes-Claude Code é o que permite essa visão.

hermes setup integrations · Visão unificada de custo · Claude Code + Hermes · Custo por projeto · Dashboard de uso total.

O Pantheon suporta customizações de layout: reordenar painéis, configurar métricas exibidas por persona, definir personas "pinadas" que aparecem no topo, e criar atalhos de teclado para invocar personas frequentes. Para heavy users: configure alertas de custo por persona, configure refresh automático do histórico e exporte relatórios semanais de uso em CSV.

Um dashboard customizado para o seu fluxo reduz fricção de uso. As personas que você usa mais ficam acessíveis em um clique; as métricas que você acompanha aparecem sem precisar navegar.

Personas pinadas · Atalhos de teclado · Alertas por persona · Refresh automático · Export CSV para análise.

Tarefas ideais para automação overnight: análise de mercado com Orpheus (resultado pronto de manhã); pesquisa de concorrentes (50 empresas analisadas enquanto você dorme); geração de rascunhos de conteúdo (10 variações de post para você escolher); análise de métricas da semana com insights; revisão de código com lista de riscos técnicos priorizados; planejamento da semana com base no soul.md e nos projetos ativos.

Ver os casos de uso concretos que são viáveis overnight cria o hábito de pensar em automação antes de dormir. A pergunta certa toda noite é: "o que posso delegar para o Hermes fazer agora?"

Análise de mercado overnight · Pesquisa extensiva · Geração de variantes · Análise de métricas · Revisão de código · Planejamento contextual.

Para agendar um job recorrente: hermes schedule add --name "análise-semanal" --cron "0 23 * * 5" --persona Orpheus --task "Faça a análise semanal do meu negócio baseado no soul.md e métricas da semana". O Hermes confirma o agendamento e o job executa todo sábado às 23h. Para listar jobs: hermes schedule list. Para remover: hermes schedule remove --name "análise-semanal".

A sintaxe de agendamento é simples mas a configuração correta do prompt da tarefa é o que determina a qualidade do resultado. Entender o comando completo permite criar, listar e gerenciar jobs com confiança.

hermes schedule add · Cron syntax · --persona para definir o fluxo · Prompt da tarefa como input · hermes schedule list.

Para jobs overnight de qualidade, defina explicitamente: quais dados de entrada o job precisa (métricas do OpenRouter, dados do soul.md, arquivos específicos); o formato de saída esperado (relatório em Markdown, lista numerada, JSON); onde salvar o resultado (arquivo local, envio por email/Telegram, atualização do soul.md); o que fazer se a entrada não estiver disponível (abortar vs usar dados do dia anterior).

Jobs mal definidos produzem resultados genéricos ou falham silenciosamente. Entradas e saídas explícitas são o contrato que garante que o resultado do job é utilizável.

Entradas explícitas · Formato de saída · Destino do resultado · Fallback de entrada · Contrato de job.

Tarefas overnight longas precisam de checkpoints para sobreviver a interrupções. Configure o Worker do Triad para salvar checkpoints periodicamente em ~/.hermes/jobs/[nome]/checkpoint.md. O formato: CHECKPOINT: [progresso], [timestamp], [próxima etapa]. Se o job for interrompido, o Hermes detecta o checkpoint existente e oferece retomada em vez de reiniciar.

Sem checkpoints, uma interrupção às 3h da manhã (falha de rede, rate limit) joga fora 4 horas de trabalho. Com checkpoints, você perde no máximo a última etapa.

~/.hermes/jobs/ · Checkpoint periódico · Formato de checkpoint · Detecção automática · Retomada vs reinício.

Todo dia ao acordar, verifique os jobs noturnos: hermes jobs status --since yesterday. O Hermes mostra: jobs completados com resultado, jobs com erros com diagnóstico, e jobs parcialmente completos com checkpoint disponível. Configure o Hermes para enviar um resumo matinal automático por Telegram às 7h: hermes schedule add --name "morning-brief" --cron "0 7 * * *" --task "Resuma todos os jobs executados nas últimas 8 horas".

O protocolo de revisão matinal fecha o loop da automação overnight. Sem ele, você pode não perceber que um job importante falhou — ou não revisar os resultados de um job que funcionou perfeitamente.

hermes jobs status · Resumo automático matinal · Telegram às 7h · Loop fechado · Revisão como hábito.

O N8N é uma plataforma de automação de fluxos que pode acionar e receber dados do Hermes via Webhook. Exemplo de fluxo: N8N monitora métricas do YouTube a cada hora → quando um vídeo atinge 1.000 views, aciona um Webhook no Hermes → Hermes executa Orpheus com os dados do vídeo e gera uma análise → resultado enviado por Telegram. Configuração: hermes webhook add --name "youtube-milestone" --trigger-on POST.

N8N + Hermes transforma a automação de reativa (você pede) para proativa (o sistema age quando o evento acontece). Esse é o nível onde a automação começa a trabalhar verdadeiramente por você.

hermes webhook add · N8N como gatilho externo · Fluxo evento → análise → notificação · Proativo vs reativo · Dados externos como input do Triad.

O loop de melhoria contínua é um job recorrente que avalia o próprio sistema: toda segunda-feira, o Hermes analisa as últimas 20 tarefas do Orpheus, identifica os padrões de aprovação e reprovação do Crítico, e gera sugestões de melhoria para os system prompts do Triad. As sugestões são entregues como uma lista de ajustes específicos — você revisa e aplica os que fazem sentido.

Um sistema que não melhora envelhece. O loop de melhoria contínua é o mecanismo que mantém o TRIAD evoluindo junto com seus casos de uso — sem exigir que você faça esse trabalho analítico manualmente.

Job de análise de sistema · Padrão de aprovação/reprovação · Sugestões de system prompt · Revisão humana de ajustes · Sistema que evolui com uso.

O Hermes por si só requer que você abra o chat ou terminal para interagir. Integrações externas permitem que o Hermes chegue até você — via Telegram quando um job termina, via N8N quando um evento de negócio acontece, via email quando uma análise está pronta. Integrações transformam o Hermes de ferramenta passiva em sistema proativo que trabalha em segundo plano.

Entender o princípio de por que integrar — fazer o sistema chegar até você, não o contrário — define quais integrações valem a pena construir e quais são apenas complexidade sem benefício.

Hermes passivo vs proativo · Sistema que chega até você · Integrações como multiplicadores · Complexidade vs benefício · Escolha de integração por caso de uso.

O Hermes suporta integração nativa com Telegram via bot. Configuração: criar um bot no BotFather do Telegram (comando /newbot), copiar o token; hermes integrations add telegram --token [TOKEN] --chat-id [SEU_CHAT_ID]; testar com hermes integrations test telegram. Após configurado, o Hermes pode enviar mensagens pro seu Telegram com resultados, alertas e resumos. Você também pode enviar tarefas ao Hermes via Telegram.

Telegram é o canal mais imediato para receber atualizações do Hermes. Resultados de jobs overnight chegam como mensagem de Telegram — você vê ao acordar junto com outras mensagens.

BotFather e /newbot · Token do bot · hermes integrations add telegram · chat-id pessoal · Bidirecional: Hermes → você e você → Hermes.

Para que o Hermes receba tarefas via Telegram, configure o webhook de entrada: hermes telegram set-webhook --persona Orpheus --on-message. Após isso, qualquer mensagem enviada ao bot é processada pelo Hermes usando a persona configurada. Filtros de segurança: hermes telegram allow-users --chat-ids [SEU_ID] garante que apenas você pode enviar tarefas. Para uso em equipe, configure por grupo ou lista de IDs.

Receber tarefas via Telegram elimina a necessidade de abrir o terminal ou o dashboard. Você pensa em algo durante o dia, manda a mensagem — Hermes processa e responde.

Webhook de entrada · --on-message como gatilho · Filtro de usuários autorizados · Persona por canal · Uso em equipe com lista de IDs.

N8N é uma plataforma open-source de automação de fluxos (similar ao Zapier mas auto-hospedável). Um fluxo N8N é um grafo de nós conectados: gatilhos (webhook, schedule, evento de app) → ações (HTTP request, banco de dados, email). O Hermes pode ser um nó em qualquer fluxo N8N — recebendo dados como input e retornando análises como output via API Webhook.

N8N + Hermes é a combinação que permite automações de negócio sofisticadas sem código. O N8N cuida dos gatilhos e routing de dados; o Hermes cuida da análise e decisão.

N8N como orquestrador externo · Fluxo como grafo de nós · Hermes como nó de análise · Webhook como interface · Open-source vs Zapier.

Para integrar o Hermes como nó no N8N: criar um webhook endpoint no Hermes (hermes webhook add --name "n8n-análise" --persona Orpheus --output telegram); o Hermes retorna a URL do webhook; no N8N, adicionar um nó "HTTP Request" com método POST para essa URL; passar os dados como JSON no body; o Hermes processa e envia resultado ao Telegram. Teste com curl -X POST [URL] -d '{"task": "teste"}'.

A integração concreta passo a passo permite replicar o padrão para qualquer fluxo N8N. Uma vez que o primeiro webhook funciona, você pode criar quantos fluxos quiser usando o mesmo padrão.

hermes webhook add · URL do webhook · Nó HTTP Request no N8N · JSON como interface · curl para teste.

O Zapier é a alternativa ao N8N para quem prefere não auto-hospedar. Funciona via "Zaps" — automações de dois passos: trigger → action. Para integrar com o Hermes via Zapier, use o Webhook by Zapier como action: quando um evento ocorre (ex: novo lead no CRM), o Zapier faz um POST para o webhook do Hermes com os dados. O Hermes processa e retorna o resultado via Telegram ou outro canal.

Zapier é a opção mais acessível para equipes não-técnicas. Se seu time não tem alguém que configura N8N, o Zapier com webhook é a alternativa que funciona em minutos.

Zapier vs N8N · Webhook by Zapier · Trigger → Hermes → resultado · Sem auto-hospedagem · Opção para não-técnicos.

O pipeline completo: você envia uma tarefa estratégica pelo Telegram → o bot do Hermes recebe → Hermes identifica que é tarefa para Orpheus → Conductor interroga via Telegram (pode fazer perguntas de clarificação por lá) → após clarificação, Worker executa com DeepSeek → Crítico revisa → resultado enviado de volta por Telegram com resumo do processo. Esse pipeline pode completar tarefas de análise profunda enquanto você está no trânsito ou numa reunião.

Ver o pipeline completo de ponta a ponta elimina a abstração. Você consegue imaginar usando esse fluxo — e identificar onde ele vai falhar na sua realidade específica antes de construí-lo.

Pipeline completo · Telegram como interface de ponta · Clarificação assíncrona · Resultado por mensagem · Análise profunda sem abrir o computador.

Para publicar o curso TRIAD no GitHub Pages: inicializar git na raiz do projeto (git init && git add . && git commit -m "inicial: estrutura do curso TRIAD"); criar repositório no GitHub (ex: inematds/triad); adicionar remote (git remote add origin https://github.com/inematds/triad); fazer push (git push -u origin main). O repositório estará pronto para configurar Pages.

A sequência correta de preparação evita estados inconsistentes. Fazer push antes de configurar o remote ou commit antes de add são erros comuns que resultam em histórico bagunçado.

git init, add, commit · Repositório GitHub · git remote add · git push -u origin main · Sequência correta.

No repositório GitHub: Settings → Pages → Source: "Deploy from a branch" → Branch: main → Folder: / (root). O GitHub Pages publica tudo que está na raiz do repositório. Para o curso TRIAD, o index.html na raiz é a landing page e curso/ contém o conteúdo. Adicionar um arquivo .nojekyll na raiz desabilita o processamento Jekyll do GitHub (necessário para Tailwind funcionar corretamente via CDN).

Configuração incorreta do Pages resulta em site publicado mas com conteúdo errado ou estilos quebrados. O arquivo .nojekyll é frequentemente esquecido e causa problemas de renderização.

Settings → Pages · Branch main, Folder / · .nojekyll obrigatório · URL gerada automaticamente · Tempo de deploy ~1-2 minutos.

Para que o deploy funcione corretamente, a estrutura de arquivos deve ter: index.html na raiz (landing page); .nojekyll na raiz (arquivo vazio que desativa Jekyll); curso/ com subdiretórios trilha1/ a trilha4/; todos os links internos usando caminhos relativos (não absolutos com /). Links com /curso/trilha1/ quebram no GitHub Pages — use curso/trilha1/ (sem a barra inicial).

Links absolutos são o erro mais comum em deployments de GitHub Pages. Um link funcional localmente pode quebrar em produção se usar caminho absoluto.

Links relativos obrigatórios · Sem barra inicial · .nojekyll na raiz · Estrutura de diretórios · Diferença local vs produção.

Para automatizar o deploy a cada push: crie .github/workflows/pages.yml com: on: push: branches: [main]; jobs: deploy: runs-on: ubuntu-latest; steps: - uses: actions/checkout@v4 - name: Deploy to Pages uses: actions/upload-pages-artifact@v3 with path: . - uses: actions/deploy-pages@v4. Com essa configuração, cada git push para main atualiza automaticamente o site no GitHub Pages.

Deploy manual via interface do GitHub funciona mas é um passo extra a cada atualização. Automatizar elimina esse atrito — você faz push do código e o site atualiza.

.github/workflows/ · on push to main · upload-pages-artifact · deploy-pages · CD automático.

Para versionar o curso de forma semântica: use tags no formato v1.0.0 para releases estáveis (git tag v1.0.0 && git push origin v1.0.0); crie um GitHub Release para cada versão com release notes descrevendo o que foi adicionado ou corrigido; mantenha uma branch development para mudanças em progresso e faça merge para main apenas quando estável. Isso garante que o site ao vivo sempre mostra uma versão completa.

Versionamento semântico permite que usuários do curso saibam quando o conteúdo mudou significativamente. Para distribuidores que linkam o curso, uma URL de versão específica é mais confiável que a URL do main.

git tag · git push origin --tags · GitHub Release · Branch development · Versão estável vs em progresso.

Para distribuir o curso para uma equipe técnica: compartilhe a URL do GitHub Pages (formato: https://[org].github.io/[repo]); crie um documento CONTRIBUTING.md com instruções de como adicionar módulos ou corrigir conteúdo; configure branch protection em main para exigir review de PR antes de merge; crie um issue template para reportar erros de conteúdo. Para times maiores, configure GitHub Teams com permissões de write no repositório.

Distribuir bem é diferente de distribuir. Um time sem guia de contribuição vai criar PRs inconsistentes ou não contribuir. A estrutura de governança define a qualidade do conteúdo ao longo do tempo.

GitHub Pages URL · CONTRIBUTING.md · Branch protection · Issue template · GitHub Teams.

Para monitorar quem acessa o curso: adicionar Google Analytics ou Plausible ao index.html e às páginas de módulo; configurar eventos personalizados para cliques em "Ver Completo" e "Começar Trilha"; monitorar semanalmente via dashboard de analytics: páginas mais visitadas, tempo médio na página, taxa de rejeição por trilha; usar esses dados para priorizar melhorias de conteúdo.

Métricas de adoção são o feedback real sobre qual conteúdo está funcionando. Sem elas, você melhora baseado em suposição; com elas, baseado em comportamento real dos usuários.

Google Analytics vs Plausible · Eventos customizados · Páginas mais visitadas · Taxa de rejeição por trilha · Dados → priorização de melhorias.

O sistema TRIAD foi construído por e para pessoas confortáveis com terminal, APIs e configuração de JSON. A maioria dos potenciais usuários de alto valor — gestores, empreendedores, criadores de conteúdo — não tem esse background. Escalar para não-técnicos requer: simplificar a instalação, criar templates prontos para usar, escrever guias visuais e ter um ponto de suporte claro para quando algo der errado.

Não escalar para não-técnicos é uma decisão de negócio, não de tecnologia. Se o sistema só funciona para desenvolvedores, você está limitando o impacto a uma fração do mercado potencial.

Gap técnico como barreira · Templates como solução · Guias visuais · Ponto de suporte · Decisão de negócio vs técnica.

Para não-técnicos, o soul.md completo com todas as seções é intimidador. Crie uma versão simplificada com apenas as seções essenciais: nome, missão em uma frase, três objetivos, o que não sugerir, e o estilo de comunicação preferido. Formato: questionário de 10 perguntas com campos de preenchimento simples. O usuário responde, você (ou o próprio Hermes) converte para o formato soul.md correto.

Um soul.md simplificado que o não-técnico preenche é infinitamente mais valioso que um soul.md completo que fica vazio por ser complexo demais.

Versão simplificada vs completa · 10 perguntas essenciais · Conversão automática · Preenchimento guiado · Valor de um soul.md preenchido.

O guia de primeiro uso deve ser: visual (capturas de tela de cada etapa), sem jargão técnico (não "executar comando no terminal" — "abrir o aplicativo Terminal e colar este texto"), com resultado esperado após cada passo ("você deve ver uma mensagem verde dizendo..."), e com troubleshooting inline para os 3 erros mais comuns de cada etapa. Formato recomendado: documento com screenshots, versão em vídeo de 10 minutos como suporte.

Um guia de primeiro uso de qualidade é o investimento de conteúdo com maior retorno. Resolve o problema de suporte mais comum (como começar) de forma escalonável.

Visual com screenshots · Sem jargão · Resultado esperado · Troubleshooting inline · Guia escrito + vídeo.

Para não-técnicos, crie um repositório de personas prontas: Orpheus (deep work estratégico), Scribe (geração de conteúdo no tom de voz), Ágora (pesquisa de mercado), e PersonaPlanner (planejamento semanal). Cada persona é um arquivo YAML comentado com explicações em linguagem simples de cada campo. O usuário baixa o arquivo, substitui os campos marcados como [SEU NOME], [SEU OBJETIVO], e faz import no Pantheon.

Templates prontos eliminam a barreira de criar system prompts do zero — a parte mais técnica e mais difícil para não-técnicos. Com templates, o esforço é de personalização, não de criação.

Repositório de personas · YAML comentado · Campos substituíveis · Import no Pantheon · Personalização vs criação do zero.

As 10 dúvidas mais comuns em onboardings: (1) Quanto custa por mês? (2) O que o Hermes pode ver da minha vida? (3) Como eu paro o agente se algo der errado? (4) O que é o soul.md em termos simples? (5) Por que usar três modelos diferentes? (6) Quanto tempo leva uma tarefa do Orpheus? (7) O que fazer quando o Hermes dá uma resposta errada? (8) Posso usar sem preencher o soul.md? (9) Como sei que o job overnight foi feito? (10) Como eu compartilho o Hermes com meu time?

Documentar as dúvidas mais comuns antes de lançar para não-técnicos reduz o volume de suporte individual. Um FAQ bem feito resolve 80% das dúvidas sem intervenção humana.

FAQ preventivo · 10 dúvidas essenciais · 80% de cobertura · Redução de suporte individual · Documentação antes do lançamento.

Para usuários não-técnicos, defina claramente o protocolo de suporte: tentar os passos do guia de primeiro uso; consultar o FAQ; perguntar ao Hermes (ele frequentemente consegue diagnosticar o próprio problema); enviar uma mensagem para o canal de suporte com: o que você tentou fazer, o que apareceu na tela (screenshot), e o que você esperava que acontecesse. O escalada para técnico acontece apenas quando os passos 1-3 falharam.

Um protocolo de escalada claro evita que não-técnicos travem em problemas que poderiam resolver sozinhos, e garante que os técnicos recebem informação suficiente para resolver o que o usuário não consegue.

Autoatendimento antes de escalada · Hermes como primeiro suporte · Informação mínima para escalada · Screenshot + descrição · Técnico como último recurso.

Métricas de sucesso de onboarding para não-técnicos: percentual de usuários que completam o guia de primeiro uso; tempo médio até a primeira tarefa delegada ao Hermes; percentual que preenche o soul.md na primeira semana; taxa de uso ativo após 30 dias; volume de suporte por usuário por semana (deve cair após as primeiras 2 semanas). Um onboarding bem-sucedido tem >70% de conclusão e uso ativo após 30 dias >50%.

Sem métricas, você não sabe se o onboarding está funcionando. Com elas, você sabe exatamente onde os usuários travam e pode melhorar o guia especificamente nesses pontos.

Taxa de conclusão do guia · Tempo até primeira tarefa · soul.md filling rate · Retenção aos 30 dias · Ticket de suporte como proxy de dificuldade.