Pular para o conteúdo

Builder OS

&
Builder · OS
L06 · Encerramento
FIM DO MÓDULO
~9 MIN DE LEITURA

Lição 6 de 6: Encerramento

lição 6/6 do Módulo 5
AO FIM, VOCÊ VAI TER
  • Decisão clara sobre o que você vai fazer **nos próximos 30 dias** com o produto
  • Entry adicionada ao Ship Wall (ships.json) se ainda não fez no M4
  • Subscrição opcional ao Patch Notes RSS pra saber quando algo novo sair

Você terminou o Builder OS. 5 módulos, ~50 lições, fatia 1 do seu produto rodando em produção com analytics, MCP, feature flags, e um Personal Pack pra reusar nos próximos projetos.

Não tem Módulo 6.

O curso acabou. Os próximos 30 dias são contigo, com o produto, e com os usuários reais que vão usar (ou não).

Checklist do módulo 5

Antes de qualquer reflexão, confere os 6 itens. Mesma forma dos checklists anteriores (M1/L07, M2/L07, M3/L13, M4/L09): clica conforme confere; estado salva no navegador.

Auditoria do setup

0 / 6
  • como corrigir: Lição 1 — inventário do .claude/
  • como corrigir: Lição 2 — hooks como alavanca
  • como corrigir: Lição 3 — memória entre sessões
  • como corrigir: Lição 4 — atualizar seu Starter
  • como corrigir: Lição 5 — plugin & marketplace
  • como corrigir: Lição 6 — encerramento

Se você marcou 5 ou 6 de 6, segue. Se marcou 3-4, volta nas lições do que faltou: geralmente é hook (L02) ou personal pack (L05). Se marcou 2 ou menos, você passou rápido demais; volta no L01 e refaz.

O que você leva

Materialmente, do curso:

  1. Um produto vivo em produção: seuproduto.com.br ou *.vercel.app com fatia 1 ponta a ponta, deploy contínuo, analytics rodando.
  2. Um Personal Pack empacotado como plugin: suas skills/hooks num plugin do Claude Code (.claude-plugin/plugin.json), publicado num marketplace privado e instalável por comando no próximo projeto, distinto do canônico.
  3. Hábito de plan → work → resume: planejar (M2), executar passo a passo (M3) e retomar a memória entre sessões (L03).
  4. Inventário e sync com o Starter: você sabe puxar atualizações do upstream sem perder seu Pack.

Mentalmente:

  1. Regra da 3ª repetição: não escreve skill na 1ª; anota; espera; se a 3ª chegou, escreve. Aplicável fora de Claude também.
  2. Plano preciso vs plano vago: você consegue olhar pra plano genérico e dizer "isso não decidiu nada."
  3. LGPD por design: você não trata como overhead; trata como check de borda (M3/L02, M3/L04, M4/L04).
  4. Diferença entre dev e prod é modo, não URL: npm run build antes de qualquer deploy é reflexo.

Esses 8 itens são o que o curso entrega. Todo o resto é detalhe replicável.

O que vem agora — os próximos 30 dias

O exercício mais importante e mais difícil do curso é este:

Não acrescente nada nos próximos 30 dias. Não adicione feature, não inicie M6 imaginário, não procure novo curso. Você vai:

  1. Mostrar pra usuário real: não amigo, não você mesmo, não outro builder. Usuário do perfil do M2/L01. Quantos? 3-5. Manda no WhatsApp, marca call, pede pra usar enquanto você assiste.
  2. Anotar o que doeu: não o que o usuário disse ("seria legal ter X"); o que doeu na hora. Tela travada, mensagem confusa, fluxo abandonado.
  3. Esperar: pelo menos uma semana entre teste e próxima sessão de código. O contraste de "vontade de mexer" vs "necessidade real" só fica claro com pausa.
  4. Voltar a editar quando tiver dor concreta, não dor antecipada. Algo como "esse fluxo está perdendo 60% dos usuários no passo 2", não um vago "preciso refatorar".

Se isso parecer pouco, é exatamente o ponto. Sem disciplina de pausa, builder solo acaba refatorando em tempo integral um produto que ninguém usa. A pausa é o que separa as duas coisas.

Ship Wall — registre que você lançou

(Se você não fez no M4/L09, faz agora.) O Ship Wall é a página pública listando produtos lançados por leitores do Builder OS. É evidência de que pessoas reais terminam o curso e botam coisa na rua. Pro autor (eu), serve pra calibrar conteúdo futuro. Pra você, é placar.

prompt · text
Abre PR no repo `jpvss/builder-os` adicionando seu produto a `data/ships.json`:

{
"name": "<nome>",
"url": "<url-de-producao>",
"tagline": "<1 frase, idioma público>",
"shippedFromModule": 5, {/* voice-allow: R4 */}
"github": "<seu handle>",
"shippedAt": "<data ISO>" {/* voice-allow: R4 */}
}

Mostre o diff antes. Depois abre PR, não merge.

Aprove. O PR fica em curadoria leve (só pra filtrar spam) e é aceito ou rejeitado em alguns dias. Nos dois casos, você fez o gesto público.

Patch Notes RSS — feed de atualizações do Builder OS

O conteúdo do curso muda ao longo do tempo (correções, lições novas baseadas em feedback, edge cases brasileiros novos). Em vez de re-checar o site semanalmente, há um RSS:

https://builder-os.escoladados.com/patch-notes.xml

Plugar num leitor de RSS (NetNewsWire, Inoreader, Feedbin) faz você ficar sabendo sem precisar lembrar de checar. Se não usa RSS, ignora: é luxo, não infraestrutura.

Build Diary — o CEAP é projeto vivo há ~6 meses

Olhando o TRACKING.md do CEAP, dá pra ver a timeline:

2025-12: planejamento inicial, primeiro notebook de exploração 2026-01-05: v3.1 do mapping CNAE → fim do trabalho de análise principal 2026-01-11: deploy do dashboard em ceap.escoladados.com 2026-02: Phase 2 (Deputados), Phase 3 (Padrões) ativadas via feature flag ...

O produto está vivo há 6 meses, mas não recebe commit todo dia: fica pausado entre fases e só reativa com critério. Cada nova fase teve uma razão concreta (feedback de usuário, dado novo da Câmara, conexão com investigação real do TCU).

Essa temporalidade vale pro seu produto também. Produto vivo dura meses, não dias. O ritmo certo de iteração é determinado pelo uso (o analytics da L04 te diz, você não chuta), não por ansiedade de fazer mais.

Para onde ir depois

O curso te deu o loop de shippar produtos: planejar, trabalhar, retomar, lançar fatia 1, medir uso. Daqui, se você quiser, dá pra ir além. Dois caminhos avançados, fora do escopo do Builder OS; cada um é uma habilidade separada, que pede prática própria. Aqui só aponto onde começar.

  1. Orquestrar vários agentes. Quando uma tarefa é grande demais pra uma conversa só, dá pra delegar pedaços a subagentes especializados, cada um no próprio contexto, e rodar em fan-out. Útil pra dividir busca, revisão e implementação sem entupir o thread principal. Doc: Create custom subagents.
  2. Construir agentes programáticos com o Claude Agent SDK. Quando você quer um agente que roda fora do chat, no seu próprio código (num pipeline, num cron, dentro de um serviço), o Agent SDK expõe o mesmo loop e as mesmas ferramentas do Claude Code como biblioteca em Python e TypeScript. Doc: Agent SDK overview.

Nenhum dos dois é pré-requisito pra nada que você fez. Ficam de porta aberta pra quando bater a necessidade.

Takeaways

  • Não tem Módulo 6. O curso acabou; os próximos 30 dias são contigo, com o produto, e com usuários reais.
  • 4 ações dos próximos 30 dias: mostrar pra 3-5 usuários reais → anotar o que doeu (não o que disseram) → esperar 1 semana → voltar quando tiver dor concreta.
  • Produto vivo dura meses, não dias. Ritmo de iteração é determinado pelo uso (analytics da L04), não por ansiedade de fazer mais.
  • Ship Wall registra que você lançou. Tagline em 1 frase é o exercício mais útil pra fechar o curso.

Você terminou quando

Três coisas:

  1. Você decidiu o que vai fazer nos próximos 30 dias com o produto (e tem em mente que não é mexer no código)
  2. Ship Wall entry feita (ou explicitamente decidida não fazer)
  3. Você lê esta lição inteira e sente o encerramento, não como vazio, mas como "ok, sigo agora"