Os seis módulos anteriores te deram o mapa. Este te dá a bancada. Aqui você sai do entendimento passivo e entra na fluência: cinco laboratórios sequenciais — modelo mental, prova offline, design de eval, artefato de GTM e memo do operador — cada um exigindo que você toque evidência real do repositório e produza um artefato verificável. A regra é uma só: nada é "pronto" sem prova.
Esta lição é a única do curso onde você faz em vez de só ler. Todo lab é ancorado em docs/alembic-launch-academy/EVIDENCE-INVENTORY.md e nos arquivos reais de /Users/acf/Documents/Projects/appfy/alembic. Quando uma afirmação for hipótese de produto ou de mercado, ela aparece marcada como hipótese — e você a valida em discovery, não no editor.
1
A virada do módulo final
Existe uma diferença enorme entre reconhecer uma resposta e conseguir produzi-la com as mãos. Um curso que só explica te deixa no primeiro estado. Este módulo te empurra para o segundo.
O que assumimos de você (muito pouco)
Você tem o repositório alembic clonado e consegue abrir um terminal.
Você leu — ou pelo menos folheou — os Módulos 1 a 6 desta academia.
Você sabe rodar pnpm install e não tem medo de ler um arquivo .ts.
Você aceita a regra de ouro: uma afirmação sem prova é só um palpite.
Lembre-seLaboratório não é sinônimo de "commitar código". A maioria destes labs treina leitura, design e operação. Você só altera código quando o lab pedir explicitamente — e mesmo aí, o artefato avaliado costuma ser o teste, não a feature.
Os cinco laboratórios formam um circuito: cada estação exige tocar evidência real e devolver um artefato. O anel externo é o loop LEARN → EXECUTE → VERIFY que governa todos eles.
O Alembic, em uma frase do próprio README.md, é o motor agêntico de destilação da Appfy: contratos Zod-first, ETL L0/L-1 e ingestão, adapters de modelo L1, debate L2, funil T0–T3, swarm L3 e harness L4. Você já conhece essas camadas. Agora vai operá-las.
O loop LEARN → EXECUTE → VERIFY que governa cada lab. Sem prova no boundary real, você não fecha o ciclo — você o repete.
2
Objetivos de aprendizagem
Ao terminar este módulo, você será capaz de
Construir um modelo mental do monorepo lendo README, package.json e @alembic/contracts em ~20 minutos.
Rodar a prova offline (distill hermético, $0) sobre um corpus-fixture e comparar a saída com o FunnelReport esperado.
Projetar um eval ausente — escrever o .test.ts que deveria existir para um modo de falha de parser ou de modelo.
Produzir um artefato de GTM a partir de um BusinessSignal hipotético, separando fato do repo de hipótese de mercado.
Escrever um memo de operador que cruza engenharia, produto, GTM e riscos — com prova anexada a cada afirmação.
Avaliar a própria resposta com uma rubrica objetiva de quatro níveis, de claim a prova reproduzível.
Senioridade no Alembic se mede por leitura, design e prova — não por volume de diff. A barra de código de produção é zero.
3
O circuito dos 5 labs
Os labs não são avulsos: eles atravessam o sistema na ordem em que o valor flui — do código bruto à decisão de operador. Leia o circuito antes de começar qualquer um.
Os cinco labs em ordem de fluxo de valor. Cada um produz um artefato distinto; o memo final volta a alimentar o ciclo.
Preveja antes de revelar
Dos cinco labs, quantos exigem editar e commitar código de produção para serem concluídos com nota máxima?
Zero, se você for rigoroso — no máximo um arquivo novo. O Lab 1 é leitura; o Lab 2 roda um comando existente; o Lab 3 escreve um teste (arquivo novo, não muda a feature); o Lab 4 e o Lab 5 produzem artefatos de produto/operação. Nenhum exige tocar o código de produção. Isso é proposital: senioridade no Alembic se mede mais por leitura, design e prova do que por volume de diff.
4
A bancada: arquivos e comandos
Antes de abrir os labs, conheça as ferramentas que ficam na bancada. Tudo aqui é observado no checkout atual — são os comandos e arquivos que você vai tocar repetidamente.
Elemento
Onde olhar
Por que importa
Comando / leitura
Baseline verde
package.json · turbo.json
Todo lab começa com o monorepo buildando.
pnpm install && pnpm typecheck && pnpm build
Suíte de testes
raiz do repo · CI
A prova final de qualquer mudança.
pnpm -w test
Funil offline
packages/etl/src/pipeline.ts
T0 hermético, $0 — o coração do Lab 2.
alembic distill <corpus> --offline
Contratos
packages/contracts/src/
O vocabulário Zod-first; a cintura de modelo.
model.ts · domain.ts · registry.ts
Adapters
packages/adapters/src/*.test.ts
Guards, roteamento e custo — alvo do Lab 3.
pnpm -F @alembic/adapters test
Council / verifier
packages/council/src/*.test.ts
Scoring, consenso, contrarian e verifier.
pnpm -F @alembic/council test
Harness
packages/harness/src/*.test.ts
Funil, bridge, HTTP/SSE e MCP read-only.
pnpm -F @alembic/harness test
Swarm
packages/swarm/src/*.test.ts
Resume, queue, worker, park e monitor.
pnpm -F @alembic/swarm test
Marketing factory
packages/marketing-factory/src/
Signal → positioning → manifests; base do Lab 4.
alembic marketing <signal.json>
Inventário de evidência
docs/alembic-launch-academy/
A fonte de verdade desta academia.
EVIDENCE-INVENTORY.md
CuidadoModo offline é a opção segura. Se você vir fetch failed, o gateway cliproxyapi (127.0.0.1:8317) está inalcançável ou falta o ALEMBIC_CLIPROXY_TOKEN. Para todos os labs, prefira --offline / ALEMBIC_OFFLINE=1: é determinístico, hermético e custa $0.
A chave que você liga em todo lab. Offline é a rota padrão: hermética, determinística e $0. Online só quando o lab exigir um backend real.
5
Lab 1 · Construir o modelo mental
Objetivo: em ~20 minutos, desenhar o mapa do monorepo sem rodar nada. É o lab de leitura orientada — o músculo mais subestimado de um engenheiro sênior.
Exemplo resolvido — o roteiro de leitura
1
Abra README.md e pnpm-workspace.yaml. Liste os workspaces: apps/cli mais os pacotes contracts, adapters, etl, ingestion, council, swarm, harness, marketing-factory, infra e factory.
2
Abra packages/contracts/src/. Esse é o centro de gravidade: model.ts (a cintura de modelo), domain.ts e registry.ts. Tudo que cruza fronteira passa por um schema Zod daqui.
3
Siga uma dependência: adapters importa contracts; etl importa contracts; harness orquestra os outros. Desenhe as setas — quem depende de quem.
4
Anote três invariantes que você consegue provar lendo o código (ex.: "ModelAdapter.run nunca lança", "roteamento é explícito e devolve err sem fallback silencioso", "stores são append-only e content-addressed").
5
Agora você: entregue um diagrama de uma página (caixas + setas) e a lista de três invariantes, cada invariante com o arquivo onde você a leu. Sem arquivo, não é invariante — é palpite.
O esqueleto que você deveria conseguir reconstruir de memória após o Lab 1: contracts no centro, todos importando dele.
Critério de prova do Lab 1: seu diagrama coincide com a tabela de workspaces do EVIDENCE-INVENTORY.md, e cada invariante aponta um arquivo. Se você não consegue dizer onde leu, volte e leia.
6
Lab 2 · Rodar a prova offline
Objetivo: depois de buildar, rodar a destilação offline sobre um corpus de teste e comparar a saída com o FunnelReport esperado. É o lab que transforma "eu acho que entendi o funil" em "eu vi o funil rodar".
Em linguagem de gente: você liga o moedor no modo "sem internet e sem custo", joga um saquinho de café de teste dentro e confere se o que sai pelo outro lado é exatamente o pó que a receita prometia. Se bater, você sabe que o moedor funciona — sem gastar um grão de café de verdade nem um centavo.
Com os termos reais: o pipeline T0 (packages/etl/src/pipeline.ts) caminha pelos .jsonl, exclui Repos/Models e Repos/Prompts, valida cada wiki package, pontua deterministicamente, deduplica por SHA-256 e emite resíduo. Em --offline nenhuma chamada paga acontece (o BudgetGuard nem é exercitado) e a saída é byte-estável. Você compara o FunnelReport emitido com o esperado.
Exemplo resolvido — a sequência hermética
1
Garanta o baseline verde: pnpm typecheck && pnpm build. Sem build, o CLI compilado não enxerga os .d.ts dependentes.
2
Aponte para um corpus-fixture do próprio repo (ex.: o fixture de corpus usado pelos testes de ETL) e rode em modo hermético: alembic distill <corpus> --offline.
3
Leia o FunnelReport: quantos itens entraram, quantos foram dedupados por SHA-256, quantos viraram resíduo, quais stores append-only foram tocados.
4
Rode alembic status e confira o estado do funil. Depois rode os testes de ETL: pnpm -F @alembic/etl test — eles cobrem o mesmo caminho que você acabou de exercitar à mão.
5
Agora você: entregue o FunnelReport colado + uma frase por número ("X itens dedupados porque compartilham o mesmo hash de conteúdo"). Se um número te surpreende, ache no pipeline.ts a regra que o produziu.
# Lab 2 — destilação hermética, $0, determinísticapnpm typecheck &&pnpm build
# roda o funil T0 sem rede e sem custoalembic distill <corpus>--offline# confere o estado do funil e cruza com os testesalembic status
pnpm -F @alembic/etl test
O caminho que o Lab 2 exercita à mão. Cada caixa corresponde a uma etapa de pipeline.ts; o relatório é a prova.
7
Lab 3 · Projetar o eval que falta
Objetivo: sem alterar a feature, escrever o teste que deveria existir para um modo de falha — de um parser, de um adapter ou de um caminho de scoring. Pensar como quem quebra o sistema é uma habilidade de design, não de codificação.
Dica
Um bom eval mira a fronteira, não o caminho feliz. Pergunte: o que acontece com JSON malformado? Com um tier sem modelo? Com um adapter ausente no registry? Com um erro retryable versus um permanente? Cada pergunta dessas é um teste candidato.
Exemplo resolvido — do modo de falha ao teste
1
Escolha um alvo com fronteira clara. Bom candidato: o roteamento de adapter, que devolve err quando um tier não tem modelo ou o adapter do registry está ausente — e não faz fallback silencioso.
2
Formule a asserção como um contrato: "dado um tier vazio, pickAdapter retorna um Result de falha com código tipado — nunca um modelo aleatório, nunca uma exceção".
3
Esboce o .test.ts ao lado dos testes reais (packages/adapters/src/*.test.ts): arranje o registry sem o tier, aja chamando o roteador, verifique result.ok === false e o error.code.
4
Rode pnpm -F @alembic/adapters test. Verde quer dizer que o invariante já é garantido; vermelho quer dizer que você achou um gap real de cobertura — anote-o.
5
Agora você: entregue um teste (ou três) com nome descritivo + a frase do contrato que ele protege. Bônus sênior: diga qual regressão esse teste pegaria se alguém "consertasse" o erro com um fallback.
// Lab 3 — o eval que falta para o roteamento fail-closeddescribe('pickAdapter — fronteira', () => {
it('devolve err quando o tier não tem modelo (sem fallback)', () => {
const r = pickAdapter(emptyRegistry, 'T2');
expect(r.ok).toBe(false); // nunca um modelo aleatórioif (!r.ok) expect(r.error.code).toBeDefined();
});
});
Arrange–Act–Assert aplicado à fronteira fail-closed. O eval protege o invariante "roteamento explícito, sem fallback silencioso".
O contrato que o seu teste protege: a falha é um valor de primeira classe (ok: false), com código e flag retryable — jamais uma exceção.
8
Lab 4 · Produzir o artefato de GTM
Objetivo: a partir de um BusinessSignal hipotético, produzir um conjunto de artefatos de go-to-market — positioning, uma seção de landing e um brief de vídeo — separando rigorosamente fato do repo de hipótese de mercado.
Fronteira fato × hipótese
O que a marketing factory faz (transformar signals verificados em positioning, copy, requests de geração e manifests versionados) é fato do repo. Quem é o cliente, qual a dor e qual canal converte são hipóteses — derivadas do código e do objetivo da Appfy, não de pesquisa de mercado externa. Marque cada uma.
Exemplo resolvido — do signal ao manifest
1
Pegue um BusinessSignal mínimo (um JSON fino: um problema e um público hipotéticos). O Lab não inventa um cliente real — ele exercita o pipeline.
2
Rode em modo offline: alembic marketing <signal.json> ($0, Higgsfield fake + templates determinísticos). Leia o AssetsManifest versionado que sai.
3
Acima do manifest, escreva o positioning: para quem, contra qual alternativa, com qual prova. Toda prova precisa apontar um diferenciador observado (contratos tipados, modo offline, guardrails de PII, stores append-only, governança council/verifier).
4
Esboce uma seção de landing e um brief de vídeo curtos. Mantenha o filtro de virality em mente: o pipeline filtra creatives por um ViralityScorer — seu artefato deveria sobreviver a esse filtro.
5
Agora você: entregue positioning + landing + brief, com uma coluna marcando cada linha como [fato] ou [hipótese]. Um artefato sem essa marcação reprova — é como o curso evita vender o que ainda é follow-up.
O pipeline que o Lab 4 exercita. O ViralityScorer é o gate: seu artefato precisa sobreviver a ele.
A marcação que o Lab 4 exige em toda linha: fato do repo (com prova) versus hipótese de mercado (para validar em discovery). Sem essa coluna, o artefato reprova.
9
Lab 5 · Escrever o memo do operador
Objetivo: produzir uma nota semanal de operador que cruza as quatro lentes — engenharia, produto, GTM e riscos — e termina com uma recomendação GO / PIVOT / NO_GO. É o lab capstone: ele exige tudo que os anteriores treinaram.
Exemplo resolvido — a anatomia do memo
1
Engenharia: estado do baseline (typecheck/build/test verdes?), o que mudou, e um risco técnico que você não aceitaria em produção — com o arquivo que o sustenta.
2
Produto: qual capacidade está pronta (fato do repo) versus qual é follow-up documentado (ex.: Higgsfield CLI/OAuth real, consumo FounderOS). Não confunda os dois.
3
GTM: uma oferta concreta (ex.: um piloto de 14 dias), o ICP testável, a métrica que diria se funcionou, e a objeção mais provável.
4
Riscos: os dois ou três riscos P6/P7 que mais te preocupam, cada um com impacto, arquivo-prova e mitigação.
5
Agora você: feche com GO, PIVOT ou NO_GO e uma frase de justificativa por lente. Um memo que recomenda sem citar prova não é memo de operador — é torcida.
O memo capstone funde as quatro lentes numa única decisão verificável. A justificativa por lente é o que separa decisão de torcida.
10
Desafios por papel
Os mesmos cinco labs, vistos por seis chapéus diferentes. Escolha o papel que mais te assusta — é onde você mais aprende. Cada card entrega um artefato distinto.
Engenheiro sênior
Trace o distill
Siga a destilação offline do CLI até as stores. Entregue o call graph e três invariantes provados.
artefato → call graph + 3 invariantes citadas
Arquiteto
Mapa de risco P6/P7
Liste os riscos das fases ativas com impacto, arquivo-prova e mitigação para cada um.
artefato → risk map com mitigações
Engenheiro de IA
Proponha evals
Desenhe evals para parsing de JSON tolerante, schema de extração, scoring do council e claims do verifier.
artefato → suíte de evals candidatos
Engenheiro de harness
Console swimlane
Projete um renderer de console que consome o snapshot do bus sem duplicar a lógica do core.
artefato → design de observabilidade
CEO
Decisão de piloto
Escreva um GO / PIVOT / NO_GO para uma oferta-piloto de 14 dias, com métrica e prova.
artefato → decisão fundamentada
Líder de GTM
Kit de lançamento
Produza outline de landing, post de LinkedIn, thread de X.com, teste de Facebook e brief de vídeo Higgsfield.
artefato → kit multicanal
Os seis papéis não são pessoas diferentes — são lentes que você veste. O chapéu mais desconfortável é o que mais te ensina.
Escolha um lab e rode o roteiro
Os cinco labs, lado a lado, com tier de risco e o artefato esperado. Clique nas abas para alternar.
Lab 1 · Construir o modelo mental
leitura~20 minsem código
Abra README.md, package.json, pnpm-workspace.yaml e @alembic/contracts. Desenhe o mapa de dependências e anote três invariantes, cada um com o arquivo onde você o leu.
Prova → diagrama bate com a tabela de workspaces do EVIDENCE-INVENTORY.md.
Lab 2 · Rodar a prova offline
execução$0 herméticodeterminístico
Depois de pnpm build, rode alembic distill <corpus> --offline sobre um fixture e leia o FunnelReport. Cruze com pnpm -F @alembic/etl test.
Prova → FunnelReport colado + uma frase por número.
Lab 3 · Projetar o eval que falta
design1 arquivo novofronteira
Escreva um .test.ts para um modo de falha (ex.: pickAdapter com tier vazio devolve err, sem fallback). Rode pnpm -F @alembic/adapters test.
Prova → teste com nome descritivo + o contrato que ele protege.
Lab 4 · Produzir o artefato de GTM
produtooffline $0fato vs hipótese
De um BusinessSignal hipotético, rode alembic marketing <signal.json> e escreva positioning + landing + brief, marcando cada linha como [fato] ou [hipótese].
Prova → artefatos com a coluna fato/hipótese preenchida.
Lab 5 · Escrever o memo do operador
operaçãocapstone4 lentes
Cruze engenharia, produto, GTM e riscos numa nota semanal e termine com GO / PIVOT / NO_GO mais uma frase de justificativa por lente, cada uma com prova.
Prova → decisão + uma justificativa citada por lente.
11
A rubrica da prova
Toda entrega de lab é avaliada na mesma escada. A pergunta nunca é "ficou bonito?" — é "qual o nível de prova?". Suba até onde der.
A escada da rubrica: uma resposta sênior nunca para no degrau 1. Ela sobe de claim para citação, de citação para comando, e de comando para prova reproduzível.
Nível
O que parece
Exemplo no Alembic
1 · Claim
Afirmação sem evidência.
"o funil deduplica" — sem dizer como nem onde
2 · Citação
Aponta o arquivo da verdade.
"dedupe por SHA-256, ver packages/etl/src/pipeline.ts"
3 · Comando
Cola a saída de um comando real.
pnpm -w test → 0; alembic status mostra o estado
4 · Prova reproduzível
Qualquer pessoa repete e obtém o mesmo.
distill --offline + diff vs FunnelReport esperado
A mesma escada da tabela, como degraus. Toda entrega de lab deve subir o mais alto que conseguir — idealmente até o degrau 4.
A regra única: uma resposta sênior nunca para no Nível 1. Se você só sabe afirmar, volte ao código até conseguir citar; depois rodar; depois reproduzir.
12
Confusões comuns
Quatro tropeços que aparecem toda vez. Reconhecê-los já é meio caminho para não cair neles.
"Lab = commitar código"
Não. A maioria treina leitura, design e operação. Você só altera código quando o lab pede — e quase sempre o artefato é o teste, não a feature.
"Pulei a verificação"
Toda resposta sênior aponta arquivo, comando ou teste que a sustenta. Sem prova anexada, a entrega volta para o Nível 1 da rubrica.
"Marketing não tem rubrica"
Tem. Boa copy para o Alembic precisa de prova, ICP, dor, CTA e métrica — e cada linha marcada como fato ou hipótese.
"Vendi o follow-up como pronto"
O erro mais caro. Higgsfield CLI/OAuth real, consumo FounderOS e o caminho de query vetorial são follow-up documentado, não capacidade entregue. Não os apresente como prontos.
A armadilha do claim: afirmar sem provar parece avanço, mas a rubrica te devolve ao Nível 1. O antídoto é sempre anexar a evidência.
Detalhe técnico
Um exemplo concreto da fronteira pronto/follow-up: o Alembic constrói índices de embeddings, mas o caminho de query (cosine / topK / rerank) é roadmap; e o MCP HTTP expõe só ferramentas read-only (harness_status, harness_events, harness_lane) — não há ferramenta de start/fanout. Cite a fronteira como ela é.
13
Recapitulando em 6 slides
A virada do módulo
Do mapa à bancada
Os módulos 1–6 te deram o mapa. O módulo 7 te dá a bancada: cinco labs que exigem tocar evidência real e devolver um artefato.
1
O circuito
Cinco labs em fila
modelo mental → prova offline → design de eval → artefato de GTM → memo do operador. Cada um entrega um artefato; o memo realimenta o ciclo.
2
A escada
De claim a prova
Quatro níveis: claim → citação (arquivo) → comando (saída) → prova reproduzível. Resposta sênior nunca para no nível 1.
3
A bancada
Offline é o padrão seguro
--offline / ALEMBIC_OFFLINE=1: hermético, determinístico, $0. Se vir fetch failed, é o gateway — caia para offline.
4
A fronteira
Fato vs follow-up
O que o repo faz é fato; quem é o cliente é hipótese; Higgsfield real e query vetorial são follow-up. Marque cada um — nunca venda o follow-up como pronto.
5
O fecho
Você agora opera
Se você completa os cinco labs com prova de Nível 4, você não entende o Alembic — você opera o Alembic. Esse era o objetivo da academia inteira.
6
1 / 6setas ←→
Cartões de memória
Vire cada cartão (clique, ou Enter/Espaço) e tente responder antes de ver o verso. É prática de recuperação — vale mais que reler.
Lab 2
Qual flag torna a destilação hermética e $0?
clique para virar
--offline (ou ALEMBIC_OFFLINE=1). Sem rede, determinística, byte-estável — e o BudgetGuard nem é exercitado.
Lab 3
Por que um eval deve mirar a fronteira, não o caminho feliz?
clique para virar
Porque é na fronteira que os invariantes quebram: JSON malformado, tier sem modelo, adapter ausente, erro retryable vs permanente. O caminho feliz raramente regride.
Rubrica
Quais são os quatro níveis de prova?
clique para virar
Claim → citação (arquivo) → comando (saída colada) → prova reproduzível (qualquer um repete). Nunca pare no nível 1.
Lab 4
No Lab de GTM, o que é fato e o que é hipótese?
clique para virar
Fato: o que a marketing factory faz (signal → positioning → manifests). Hipótese: quem é o cliente, qual a dor, qual canal converte. Marque cada linha.
Lab 5
Quais quatro lentes o memo do operador cruza?
clique para virar
Engenharia, produto, GTM e riscos — convergindo numa decisão GO / PIVOT / NO_GO com uma justificativa citada por lente.
Baseline
Qual o comando que prova qualquer mudança no monorepo?
clique para virar
pnpm typecheck && pnpm build && pnpm -w test. Verde é a porta de entrada de todo lab; sem build, o CLI nem enxerga os .d.ts.
As Dez ideias para levar deste módulo
Reconhecer uma resposta é fácil; produzi-la com as mãos é o que este módulo treina.
Os cinco labs atravessam o fluxo de valor: modelo → prova → eval → GTM → memo.
Lab não é commitar código. A maioria treina leitura, design e operação.
O modo --offline é hermético, determinístico e $0 — sempre o padrão seguro.
Um bom eval mira a fronteira: é lá que os invariantes quebram.
A rubrica tem quatro níveis: claim → citação → comando → prova reproduzível.
Resposta sênior nunca para no Nível 1; sobe até a prova reproduzível.
Em GTM, separe fato do repo de hipótese de mercado — marque cada linha.
Nunca venda o follow-up (Higgsfield real, query vetorial) como pronto.
Cinco labs com prova de Nível 4 = você opera o Alembic, não só o entende.
14
Verifique seu entendimento
Três perguntas. Escolha e leia o porquê de cada opção — o feedback ensina tanto quanto a pergunta.
Checagem cumulativa
Acerte as três para fechar a academia. A pontuação aparece abaixo.
1. Qual combinação melhor descreve o que o Alembic é, de fato, hoje?
(b). O fato observado no repo é o pipeline corpus → signal → council/verifier → marketing manifest, com stores append-only, guardrails de PII e budget. (a) e (c) confundem uma peça com o todo — e (a) inclui um "painel em tempo real" que não é capacidade entregue.
2. No Lab 3, você roda o eval e ele fica vermelho. O que isso significa?
(c). Verde significa que o invariante já é garantido; vermelho significa que o comportamento esperado não está coberto — um gap real, que é exatamente o que o Lab 3 pede para você descobrir. Não é o repo quebrado (a) nem redundância (b).
3. Sua entrega de lab afirma "o funil deduplica itens". Em que nível da rubrica ela está?
(a). É só uma afirmação. Para subir: cite packages/etl/src/pipeline.ts (nível 2), cole a saída de distill --offline (nível 3) e mostre o diff contra o FunnelReport esperado (nível 4). (b) salta níveis sem evidência e (c) viola a regra de ouro do módulo.
Acertos: 0/3
Em uma frase, para você mesmo: "Eu consigo rodar o lab ____, e a prova que eu anexaria está no nível ____ da rubrica." Se você consegue nomear o lab e o nível, você está pronto para operar.
15
Conclusão da academia & próximos passos
Você chegou ao fim da Launch Academy. Vale parar um instante e ver o caminho inteiro — porque cada módulo era um degrau para chegar aqui, à bancada.
o arco completo da Launch Academy
O que você leva da academia inteira
Você lê o repo como um mapa: contracts no centro, todos importando dele, e sabe nomear três invariantes com o arquivo de cada.
Você prova em vez de afirmar: roda o funil offline, compara com o relatório esperado e anexa a saída a cada claim.
Você pensa em fronteiras: projeta o eval que falta e distingue um gap de cobertura de um falso positivo.
Você vende com honestidade: produz GTM marcando fato versus hipótese e nunca apresenta follow-up como pronto.
Checklist de domínio
Marque cada item que você consegue fazer sem depender de explicação externa. O progresso fica salvo neste navegador — é o seu termômetro de fluência.
Próximos passos
Saindo da academia para a operação
1
Hoje: rode o Lab 2 de verdade no seu checkout. Cole o FunnelReport em algum lugar — é a sua primeira prova de Nível 4.
2
Esta semana: escolha o papel que mais te assusta na seção "Desafios por papel" e entregue o artefato dele, avaliado pela rubrica.
3
Recorrente: adote o memo do operador (Lab 5) como um ritual. Uma nota por semana cruzando as quatro lentes mantém engenharia, produto e GTM honestos entre si.
4
Sempre: antes de dizer "pronto", suba a escada da rubrica. Se você não consegue reproduzir, ainda não está pronto.
Você foi o aluno em sete módulos; agora seja o operador. Volte ao índice da academia sempre que precisar reabrir um módulo — e use esta página como sua bancada toda vez que for transformar um entendimento novo em capacidade provada. A academia termina; a prática começa.