1 · o trabalho
Operar é manter um loop, não esperar a perfeição
O operador roda um sistema operacional semanal: motor confiável → aposta → demanda → evidência. Ciclos pequenos com riscos conhecidos vencem o congelamento.
01
Alembic Launch Academy · Módulo 6 · Visual Course
Playbook do operador
Ao fim desta lição você vai conduzir uma semana inteira de operação do Alembic como produto da Appfy — segunda mede a saúde do motor, terça revisa sinais, quarta decide as apostas de CEO, quinta executa engenharia e GTM, sexta faz o readout — e vai entender por que o trabalho do operador é rodar ciclos pequenos com riscos conhecidos, não congelar tudo até virar plataforma perfeita.
Leia primeiro (fonte primária)
Os painéis vivos do repositório: docs/weekly-status.html + docs/triage-board.html
Esta lição destila o módulo "Operator Playbook" da Launch Academy e o ancora em arquivos reais do checkout: o status documentado (docs/weekly-status.html), o board P0–P7 (docs/triage-board.html), os planos dry-run de infraestrutura (packages/infra/src/provision.ts) e o comando alembic status (apps/cli/src/commands.ts). Quando uma afirmação é hipótese de produto ou de mercado, ela aparece marcada como hipótese — para ser validada em discovery, nunca anunciada como fato.
01
A grande ideia
Um operador não escreve todo o código nem fecha toda a venda. Ele mantém um sistema operacional semanal rodando: garante que o motor é confiável, escolhe onde apostar, mede a demanda real e fecha o loop com evidência. O produto avança porque o ciclo gira, não porque alguém esperou a perfeição.
O que você vai conseguir fazer
- Conduzir uma reunião semanal do Alembic sem se perder em detalhes técnicos.
- Tomar decisões de CEO mantendo fato e hipótese separados, cada um com sua evidência.
- Priorizar engenharia por impacto em release, trust ou revenue — não por gosto.
- Definir um dashboard operacional onde toda métrica muda uma decisão.
- Manter os follow-ups P6/P7 visíveis sem deixá-los bloquear o GTM.
O que assumimos de você
- Você já entendeu, nos módulos anteriores, o que são
tier, gate,Resulte o funil — aqui a gente opera isso, não reexplica. - Você tem o checkout do Alembic na mão e consegue rodar comandos no terminal.
- Você não precisa saber tudo do produto: o playbook é justamente o roteiro para não precisar.
Pense num operador como o maestro de uma orquestra pequena. Ele não toca todos os instrumentos. Ele garante que o palco está montado (motor confiável), escolhe a peça da semana (as apostas), ouve a plateia (a demanda) e, no fim do show, anota o que funcionou e o que cortar (o readout). Se ele parar de reger esperando que cada músico fique perfeito, o concerto nunca acontece.
Analogia: o operador troca "esperar a perfeição" por "rodar um ciclo curto toda semana com riscos que ele conhece e aceita".
O sistema operacional, em uma frase
O operador roda um loop semanal com quatro responsáveis acoplados: engenharia mantém o motor confiável (gates verdes, invariantes, adapters), o CEO decide as apostas (ICP, oferta, preço, apetite a risco), o GTM mede a demanda (landing, conteúdo, ads, calls) e o produto fecha o loop transformando evidência em próxima aposta. Cada decisão é registrada como suposição com evidência, e cada métrica precisa mudar uma decisão — caso contrário é ruído.
02
A semana do operador
A semana tem uma forma fixa. Cada dia tem um foco e uma pergunta única. Isso é o que impede a reunião de virar uma lista infinita de assuntos.
A semana do operador como um anel: cinco estações, uma pergunta por dia, evidência fechando o loop na sexta.
Antes de revelar — pense
Se você só pudesse fazer uma coisa na segunda-feira, antes de qualquer decisão de produto, o que seria?
Confirmar que o motor é confiável. Rodar (ou agendar)
typecheck, build, test e o docs gate, e olhar o worktree sujo. Decisão de produto tomada sobre um motor quebrado é decisão sobre dados falsos — você não sabe se o que "funcionou" funcionou mesmo.Guarde istoUma pergunta por dia. Segunda: o motor é confiável? Terça: que sinal merece teste? Quarta: qual a aposta? Quinta: o que eu envio? Sexta: o que eu corto?
03
O loop semanal em SVG
A mesma semana, vista como um ciclo de cinco verbos: checar → revisar → decidir → enviar → medir, e então registrar o aprendizado. É um loop, não uma escada: ele recomeça toda segunda.
Toda semana você dá a mesma volta: confirma que a base está sólida, olha os sinais que chegaram, escolhe uma aposta, faz uma coisa de engenharia e uma de mercado, e mede o resultado. O que você aprendeu volta para o começo. Pequeno, repetível, honesto.
O loop mapeia para artefatos reais: checar = pnpm -r typecheck && pnpm -r build && pnpm -w test + docs gate; revisar = ler opportunity/learning stores via alembic status; decidir = registrar suposições; enviar = uma melhoria técnica estreita + um experimento de GTM estreito, mantendo P6/P7 visíveis; medir = comparar funil/manifestos contra o que foi prometido. O readout de sexta consolida e nomeia o que será cortado.
04
As três cadeiras de decisão
Um operador senta em três cadeiras diferentes na mesma semana. Confundi-las é a causa nº 1 de reunião travada: você discute preço (CEO) usando argumentos de cobertura de testes (engenharia). Saiba em qual cadeira você está.
As três cadeiras: cada uma decide coisas diferentes, com evidências diferentes — e o produto costura as três.
CEO
CEO — as apostas
Clique nas abas: a cadeira correspondente acende e o painel mostra o que ela decide e onde isso vive.
A regra que costura as três: registre toda decisão como uma suposição com evidência. "Vamos cobrar R$X" não é fato — é uma hipótese que tem que ser validada no funil. Separe sempre o que você sabe do que você aposta.
05
Arquivos, funções e comandos
O playbook não é abstrato: cada ritual tem um arquivo real para abrir e um comando para rodar. Esta é a tabela que você deixa aberta na reunião.
| Elemento | Onde olhar | Por que importa | Comando ou leitura |
|---|---|---|---|
| Status atual | docs/weekly-status.html | Snapshot documentado de status e métricas — o ponto de partida da segunda. | open docs/weekly-status.html |
| Triage | docs/triage-board.html | Board P0–P7 com os follow-ups ativos; é onde mora o roadmap. | open docs/triage-board.html |
| Stores do run | apps/cli/src/commands.ts | runStatus lê os stores de opportunity e learning e conta os registros. | alembic status --data-dir .alembic |
| Infra | packages/infra/src/provision.ts | Planos dry-run para terraform, docker-compose e launchd — sabe o que é host, droplet e CI. | sed -n '1,90p' packages/infra/src/provision.ts |
| Factory | .factory/run.ts | Workflow AFK de codificação em tempo de desenvolvimento (uso interno do operador). | sed -n '1,120p' .factory/run.ts |
O que o
provision.ts realmente faz hojeAs funções terraformPlan, composeUp e launchdLoad existem e são honestamente dry-run: elas montam o argv real (terraform -chdir=terraform plan, docker compose --profile prod up -d, carregar os agents launchd das 02:00/04:00) e registram um plano tipado, marcando a mutação real com // TODO(Pn):. Para o operador isso é ouro: você lê exatamente o que aconteceria antes de qualquer coisa mudar de verdade.
# segunda-feira, em sequência — a saúde do motor antes de qualquer decisão pnpm -r typecheck && pnpm -r build && pnpm -w test git status # worktree sujo? algo não foi commitado? # terça — contar o que os stores acumularam alembic status --data-dir .alembic # infra: ler o plano, sem mutar nada sed -n '1,90p' packages/infra/src/provision.ts
CuidadoNunca anuncie "green" pela memória. Compare o que
docs/weekly-status.html afirma com a execução local dos comandos. Documento e realidade divergem — a realidade ganha.06
Passo a passo da semana
Cinco rituais, um por dia útil. Faça-os na ordem: cada um depende da confiança que o anterior estabeleceu.
Os cinco rituais
1
Segunda — saúde do motor. Rode ou agende
typecheck, build, test e o docs gate; inspecione o worktree sujo. O operador precisa saber se a base é confiável antes de tudo.2
Terça — revisão de sinais. Olhe os stores de
opportunity e learning, os verifiedSignals e os manifestos de marketing. Decida quais sinais merecem um teste de GTM.3
Quarta — decisões de CEO. Escolha ICP, oferta, preço, teto do piloto, apetite a risco e o trade-off do roadmap. Registre cada decisão como suposição com evidência.
4
Quinta — execução eng + GTM. Envie uma melhoria técnica estreita e um experimento de mercado estreito. Mantenha os follow-ups P6/P7 visíveis.
5
Sexta — readout. Resuma a evidência: o que foi enviado, o que quebrou, o que converteu, o que foi aprendido, o que será cortado.
Agora você: pegue a sua semana atual e escreva os cinco rituais como cinco bullets, cada um com o arquivo que você abriria e o comando que você rodaria. Se algum ritual não tem arquivo nem comando, ele provavelmente é vago demais — aperte-o.
Recapitulando o ritmo: confiar no motor (seg) → escolher o sinal (ter) → decidir a aposta (qua) → executar estreito (qui) → cortar com evidência (sex).
07
Roadmap e registro de riscos
O roadmap do operador não é uma lista de desejos. Cada item P6/P7 precisa estar ligado a receita, trust, demo ou risco de release — senão é só vontade.
O registro de riscos vivo
Manter um risk register é parte do ritual. Os riscos atuais conhecidos do produto giram em torno de pontos que ainda dependem de mundo real:
risco · integração externa
O CLI real do Higgsfield e o gateway de modelos ao vivo dependem de credenciais e rede — falham fechado quando ausentes. Risco: anunciar capacidade antes do preflight passar.
risco · superfície de produto
tRPC/console e privacidade ainda em construção. Risco: prometer um painel multi-tenant antes de a superfície estar pronta.
risco · prova de venda
Falta prova de venda real (case-study fechado). Risco: confundir interesse com demanda — só o funil decide.
risco · confiabilidade do motor
Gates verdes localmente ≠ gates verdes no CI. Risco: um worktree sujo escondendo uma quebra. Mitigação: comparar sempre documento × execução.
Hipótese, não fato: os itens acima são leituras de risco de produto/mercado. Eles devem ser revalidados em discovery a cada ciclo — não tratados como verdades fixas.
08
Dashboards que decidem
A regra de ouro do dashboard: se uma métrica não muda uma decisão semanal, ela é ruído. Um bom painel operacional cobre quatro eixos — motor, produto, GTM e finanças.
decide
Gates verdes no CI (sim/não). Decide se a semana pode prometer "estável" ou precisa de um dia de correção primeiro.
decide
Calls de venda agendadas. Decide se o gargalo é demanda (topo) ou conversão (fundo) — muda onde o GTM investe.
decide
Custo por run. Decide se uma capacidade pode escalar ou precisa ficar founder-gated.
ruído
Total de commits na semana. Não muda nenhuma decisão — atividade não é progresso.
ruído
Estrelas no repositório. Vaidade: não diz nada sobre release, trust ou revenue.
4
eixos do dashboard (engine · product · GTM · finance)
12
métricas sugeridas, ~3 por eixo
5
rituais semanais (seg → sex)
P6/P7
faixas de roadmap ainda ativas
| Eixo | Pergunta que a métrica responde | Decisão que ela muda |
|---|---|---|
| Engine | O motor é confiável esta semana? | Prometer estável vs. parar para corrigir. |
| Product | O que foi enviado de fato chegou ao usuário? | Manter a aposta vs. recuar o escopo. |
| GTM | Há demanda real, medida no funil? | Onde investir: topo (demanda) ou fundo (conversão). |
| Finance | Quanto custa rodar e quanto entra? | Escalar uma capacidade vs. mantê-la gated. |
09
Confusões comuns
Três armadilhas derrubam operadores de primeira viagem. Reconheça-as antes de cair.
mito nº 1
"O roadmap é onde anoto tudo que seria legal ter."
clique para ver a correção
correção
Roadmap não é wishlist. Todo P6/P7 deve ligar a receita, trust, demo ou risco de release. Se não liga, fica fora — vira nota, não plano.
mito nº 2
"Só lanço quando estiver perfeito e completo."
clique para ver a correção
correção
O operador não espera perfeição. O papel é rodar ciclos pequenos com riscos conhecidos — não congelar até tudo virar plataforma.
mito nº 3
"Quanto mais métricas no dashboard, melhor."
clique para ver a correção
correção
Dashboards precisam de decisão. Se uma métrica não muda a decisão da semana, ela é ruído e deve sair do painel.
DicaQuando a reunião travar, pergunte: "em qual cadeira estamos sentados agora — CEO, Engineering ou GTM?". Quase toda discussão circular é duas cadeiras brigando no mesmo assunto.
10
Exemplo guiado: como eu verifico no código
Antes de anunciar qualquer coisa na sexta, o operador verifica. Aqui está o roteiro de verificação, ritual por ritual.
Verificação de sexta-feira
1
Ver status atual. Compare
docs/weekly-status.html com a execução local de pnpm -r typecheck && pnpm -r build && pnpm -w test antes de declarar green.2
Ver roadmap. Use
docs/triage-board.html e o HANDOFF para localizar os P6/P7 restantes e confirmar que cada um ainda liga a receita/trust/demo/release.3
Ver infra. Abra
packages/infra/src/topology.ts e provision.ts para saber o que é host, droplet e CI — e leia os planos dry-run sem mutar nada.4
Ver stores. Rode
alembic status contra o dataDir de um run real para contar os outputs (registros de opportunity e learning), em vez de estimar.Agora você: escolha um run real (ou crie um pequeno) e rode
alembic status --data-dir <seu-dir>. Quantos registros de opportunity e learning ele conta? Esse número é a sua evidência — não o seu palpite.A regra de evidência
Toda afirmação de status passa por um arquivo aberto ou um comando rodado.
"Acho que está verde" não é um status. "Rodei os três comandos e os três saíram com código 0, e alembic status contou 7 opportunity / 3 learning" é um status. O operador fala em evidência.
11
Recapitulando
Use as setas ← → (ou os botões) para percorrer os seis pontos que sustentam o playbook do operador.
2 · a semana
Uma pergunta por dia
Seg: o motor é confiável? Ter: que sinal merece teste? Qua: qual a aposta? Qui: o que envio? Sex: o que corto? A forma fixa impede a reunião de explodir.
02
3 · as cadeiras
CEO, Engineering, GTM — saiba onde você está sentado
Cada cadeira decide coisas diferentes com evidências diferentes. A maioria das reuniões travadas é duas cadeiras brigando no mesmo assunto.
03
4 · o roadmap
Roadmap não é wishlist
Um item só entra se liga a receita, trust, demo ou risco de release. O risk register é vivo: Higgsfield real, gateway ao vivo, tRPC/console, privacidade, prova de venda.
04
5 · os dashboards
Se não muda decisão, é ruído
Quatro eixos (engine · product · GTM · finance), ~12 métricas. Commits e estrelas são vaidade; gates verdes, calls agendadas e custo por run decidem.
05
6 · a disciplina
Fale em evidência, não em palpite
Compare documento × execução. Toda afirmação de status passa por um arquivo aberto ou um comando rodado: weekly-status.html, triage-board.html, provision.ts, alembic status.
06
12
Verifique
Três perguntas para confirmar que o playbook ficou de pé. Cada explicação manda você de volta à evidência.
Checagem de conhecimento
1. Por que a segunda-feira começa pela saúde do motor, antes de qualquer decisão de produto?
Se os gates não estão verdes, você não sabe se o que "funcionou" funcionou. Por isso a saúde do motor (
typecheck/build/test + worktree) vem antes — é a base de confiança da semana.2. Qual item PERTENCE ao roadmap do operador?
Roadmap não é wishlist. P6/P7 só entram quando ligam a receita, trust, demo ou risco de release. O resto é nota, não plano.
3. Uma métrica que não muda nenhuma decisão semanal é…
A regra de ouro: se a métrica não muda uma decisão, é ruído. Commits e estrelas são vaidade; gates verdes, calls agendadas e custo por run decidem.
As dez disciplinas do operador
- Confirme o motor (gates verdes) antes de decidir qualquer coisa.
- Uma pergunta por dia — não deixe a reunião virar lista infinita.
- Saiba em qual cadeira você está: CEO, Engineering ou GTM.
- Registre toda decisão como suposição com evidência.
- Separe sempre o que você sabe do que você aposta.
- Roadmap não é wishlist: ligue cada item a receita/trust/demo/release.
- Não espere a perfeição: rode ciclos pequenos com riscos conhecidos.
- Se a métrica não muda decisão, tire-a do dashboard.
- Mantenha um risk register vivo e revalide-o em discovery.
- Fale em evidência: documento × execução, sempre.