Lançar

O que Lançar faz?

Lançar é a corrida de entrega do estaleiro: do briefing da missão à mudança verificada e implantada. Ela se apoia na fronteira da verificabilidade — agentes executam continuamente tudo que é repetível e aceitável por evidência; humanos decidem o que não pode ser julgado pelo sistema ou o que falha de forma custosa. O objetivo não é a automação máxima — é a delegação máxima do trabalho verificável, para que o tempo humano seja gasto apenas nas decisões que somente um humano pode tomar.

O teste de verificabilidade, aplicado a cada etapa: se isso for feito errado, o sistema consegue detectar? Consegue refazer ou reverter automaticamente? Sim para ambos → agente. Sem resposta única, sistema não consegue julgar, ou caro para errar → humano.

Lançar assume que o estaleiro existe — e se recusa a executar se não existir. O portão do estaleiro é a primeira ação de toda invocação, antes da resolução do idioma do documento e antes de ler qualquer especificação fornecida:

• Execute a auditoria completa --check do drydock — superfícies faltantes, um documentLanguage no frontmatter do CONTEXT.md ausente ou inválido, caminhos mortos, termos do glossário não usados no código, padrões nunca referenciados. Este é o único critério: Lançar não realiza inventário próprio de instalações.
• Descobertas acionáveis / de alta confiança bloqueiam a execução: liste cada descoberta literalmente, aponte para /oh-my-claudecode:drydock, declare que a execução nunca começou e nenhum artefato foi produzido, e pare. Sem uma substituição explícita, trate qualquer descoberta como bloqueio.
• Substituição restrita (intenção explícita apenas): descobertas de baixa confiança, descobertas explicitamente classificadas como falsos positivos no relatório do drydock, ou um repositório de rascunho/descartável explicitamente declarado pelo usuário podem ser substituídas apenas com intenção deliberada e por invocação do usuário — a substituição deve nomear a(s) descoberta(s) ou o escopo descartável e nunca deve engolir silenciosamente uma descoberta acionável de alta confiança. Nenhuma flag de bypass geral.
• Limitação atual da auditoria: hoje --check é uma lista de verificação de instruções da skill sem um contrato legível por máquina de descoberta/gravidade ou executável — a classificação de gravidade depende da redação do relatório do drydock até que um contrato estruturado exista. Um contrato de saída de descoberta/gravidade legível por máquina é o acompanhamento pretendido; a redação do portão permanece honesta sobre o que pode e não pode depender mecanicamente.
• Uma auditoria limpa (ou um escopo de baixa confiança/falso positivo/descartável explicitamente substituído) admite a execução. Cada slot de rastro documental (CONTEXT.md, docs/adr/, docs/business/) e superfície da instalação já existe nesse ponto; Lançar preenche o rastro documental conforme as decisões se estabelecem, mas nunca cria os slots.
• A regra de entrada é CLAUDE.md — o mapa do estaleiro não reconhece substituto.

A fronteira

Pontos de verificação humanos (os 20% críticos)	Execução contínua do agente (os 80% mecânicos)
C1 redigir o briefing da missão (objetivo + escopo)	levantamento de fatos e exploração do repositório, autoatendido
C2 aprovar critérios de aceitação + lista de costuras de teste	preparação da entrevista: perguntas de fronteira em lote com respostas recomendadas
C3 aprovar decomposição de tarefas (granularidade, arestas de bloqueio)	redação de especificação e tarefas, validação mecânica (independência, demonstrável, cabe em um contexto)
C4 responder decisões irreversíveis que surgem durante a execução (em lote, assíncrono)	implementação tdd nas costuras acordadas, builds, testes, regressões
C5 aceitar o relatório de conclusão; vetar via Suposições Abertas e a lista de sedimento por linha	revisão de código, verificação em toda a mudança, agendamento da fronteira da equipe, todo o rastro documental

Entre os pontos de verificação, o pipeline nunca fica ocioso: agentes continuam trabalhando em todas as tarefas de fronteira que não dependem de uma resposta humana pendente.

Postura de ciclo de vida

Lançar é uma composição sem estado sobre o ciclo de vida existente do OMC — não possui máquina de estado de tempo de execução própria:

• A equipe é dona dos status de tarefas, transições, cancelamento e limpeza de tempo de execução; Lançar nunca os altera fora do contrato da Equipe.
• Os canônicos plan → execute → review → verify superficies próprias possuem seu comportamento de ciclo de vida existente. Os artefatos criados pelo Lançar são limitados a .omc/specs/<feature-slug>/, CONTEXT.md, docs/adr/, e docs/business/ — mais, apenas após aprovação C5, os slots de sedimento nomeados na tabela da Fase 5.
• Lançar não tem retomada automática. Após interrupção, releia os artefatos e o status atual da Equipe, mas continue apenas através de uma nova invocação explícita do Lançar após o ciclo de vida da Equipe proprietária ter alcançado um limite terminal/limpeza suportado. Nunca infira uma aprovação humana ou reproduza uma tarefa in_progress.
• Esforços nebulosos são jurisdição do navegador: quando o portão de névoa roteia para /oh-my-claudecode:ask-navigator, a execução nunca começa — sem artefatos, sem estado parcial. O mapa do navegador é o único portador entre sessões; o Lançar retoma apenas do briefing da missão que ele devolve.
• Lançar não adiciona recibo de aprovação, contador de revisão, log de reprodução, caminho de cancelamento, mecanismo de reversão ou ciclo de vida de limpeza próprios.

Qualquer alegação de durabilidade nesta skill é uma alegação sobre os arquivos no disco, não sobre um tempo de execução oculto.

Fase 0 — Entrada

Uma execução chega a esta fase apenas através de um portão do estaleiro limpo. Antes de ler uma especificação fornecida ou entrar na Fase 1, resolva o idioma do documento. Uma escolha humana explícita na invocação atual vence; caso contrário, leia uma tag BCP-47 válida do frontmatter do CONTEXT.md na chave exata e estável documentLanguage; caso contrário, exija inferência unânime e de alta confiança do CLAUDE.md e depois do README.md. Uma tag chinesa persistida, simples ou apenas de região, é ambígua em relação ao script e deve ser perguntada uma vez nesse nível de autoridade, nunca ignorada por inferência. Evidência chinesa ausente, mista, conflitante, de baixa confiança, explícita inválida ou ambígua em relação ao script requer uma pergunta de idioma em lote; não adivinhe. O chinês deve ser resolvido para uma tag de script explícita zh-Hans ou zh-Hant. zh-Hans-* seleciona o companheiro Simplificado e zh-Hant-* seleciona o companheiro Tradicional enquanto a tag normalizada completa é persistida. Persista a tag normalizada resolvida de volta para CONTEXT.md antes de qualquer artefato criado pelo Lançar, para que uma invocação explícita nova possa lê-la sem estado de conversa oculto. O humano lê e mantém esses artefatos; agentes são agnósticos a idioma.

Localize apenas prosa e rótulos voltados para humanos / valores escalares localizáveis. Caminhos, comandos de barra, flags, cercas de código, placeholders, chaves de frontmatter e valores semânticos de máquina, chaves YAML/JSON, tokens de ciclo de vida (plan, execute, review, verify), enums de status (pending, in_progress, completed, failed, ready-for-agent), IDs, blockedBy de tarefas, blocked_by público da Equipe e todos os tokens de análise/controle permanecem estáveis byte por byte. Os companheiros de idioma de referência são mutuamente exclusivos: emita exatamente uma renderização selecionada, nunca cabeçalhos ou rótulos bilíngues duplicados.

• Auto-verificação rápida antes de qualquer outra coisa: o briefing nomeia um objetivo, um limite de escopo e não-objetivos? Se dois ou mais estiverem faltando, diga isso e peça uma rodada de refinamento — executar o pipeline em um briefing vago converte ambiguidade em saída de aparência confiante.
• Portão de névoa: após a rodada de refinamento, aplique o teste de névoa do navegador — P1: o destino pode ser declarado em uma frase (a especificação, decisão ou mudança para a qual este esforço está encontrando seu caminho)? P2: as primeiras três decisões podem ser declaradas com precisão agora, mesmo que nenhuma possa ser respondida ainda? Qualquer resposta não → a execução nunca começa: declare isso claramente, observe que nenhum artefato foi produzido, recomende /oh-my-claudecode:ask-navigator (o navegador do estaleiro mapeia névoa como um mapa de tarefas de decisão e devolve um briefing da missão), e pare. Entregue as perguntas residuais e qualquer vocabulário já estabelecido, para que o W1 do navegador não as repita.
• Verificação de mapa: antes de ler uma especificação fornecida ou entrar na Fase 1, procure por um navigator:map aberto (rótulo do rastreador, ou sob .omc/wayfinder/). Um existe e esta invocação não fornece novo briefing → recomende /oh-my-claudecode:ask-navigator para trabalhar a próxima decisão naquele mapa, e pare. Um existe e um novo briefing é fornecido → faça uma pergunta — continuar o mapa aberto, ou iniciar um novo esforço — antes de prosseguir.
• Caminho da especificação fornecido → leia, pule para a Fase 2.
• Briefing da missão → Fase 1.
• Correção de ponto único → entregue para executar, saia.

Fase 1 — Convergir (humano decide, agente prepara)

Execute a entrevista com o protocolo da árvore de design: mapeie decisões e suas dependências, depois trabalhe em rodadas de fronteira — agrupe cada pergunta atualmente perguntável em uma rodada, numerada, cada uma com uma resposta recomendada. O humano responde; a árvore se remodela; recalcule a fronteira. Fatos são sempre autoatendidos por subagentes a partir de evidências do repositório — o humano é perguntado apenas sobre o que nenhuma quantidade de exploração pode resolver.

Rastro documental, escrito no momento em que cada item se estabelece:

• vocabulário de domínio → CONTEXT.md na raiz do repositório (uma entrada por termo)
• decisões que passam no teste ADR (difícil de reverter, surpreendente sem contexto, tradeoff real) → docs/adr/NNNN-<slug>.md
• regras de negócio e descobertas de contexto durante a convergência → docs/business/ (um artigo por pergunta de negócio, parágrafo de abertura declara por que é importante)

Não convergir aqui é trabalho normal, não uma falha: se a fronteira não esvaziar, apresente as perguntas residuais classificadas — esta é a entrada para C2, não um erro. Se as próprias perguntas residuais não puderem ser declaradas com precisão (o teste de névoa P2 falha), o próprio destino é incerto e isso está além da autoridade do C2: pare, anote o que já foi estabelecido (vocabulário em CONTEXT.md, perguntas respondidas), recomende /oh-my-claudecode:ask-navigator, e saia — o pipeline nunca inventa um destino.

Desvio de Loft. Uma pergunta residual que é precisa mas não pode ser resolvida em prosa — precisa ser vista ou clicada, não descrita (como a UI deve parecer, se um modelo de estado parece certo) — é respondida com um artefato, não com mais perguntas: chame a ferramenta Skill com "loft", deixe o capitão reagir, e incorpore essa reação de volta na entrevista. O artefato elevado é a entrada para C2; o capitão assina o que viu, não o que lhe foi dito.

Briefs de Porto. Um briefing de missão entregue por /oh-my-claudecode:harbor carrega decisões assinadas com links e condições aplicáveis: consuma-os como já feitos — não repita perguntas sobre metas de negócio inalteradas. Se o código mudou desde que as evidências foram coletadas (novo head, base alterada), reverifique a evidência técnica afetada; novo escopo de implementação além do brief assinado ainda obtém sua própria aprovação.

Fase 2 — Síntese de especificação (agente redige → C2 aprova)

Sintetize .omc/specs/<feature-slug>/spec.md:

# Especificação <Feature>
## Problema
## Solução
## Histórias de Usuário        (numeradas, cada uma com critérios de aceitação testáveis)
## Decisões de Implementação
## Decisões de Teste   (comportamento externo apenas)
## Fora de Escopo

Redija tudo, depois pare em C2: apresente os critérios de aceitação e a lista de costuras de teste para aprovação humana. Costuras são selecionadas por evidência do repositório e pela disciplina de módulo profundo (interfaces públicas, costuras de teste existentes, análise de profundidade); o humano confirma ou corrige a lista — uma costura que o humano não aprovou não recebe testes.

Portão de durabilidade (imposto pelo agente, sem necessidade de aprovação): especificação e tarefas carregam contratos, nunca coordenadas — sem caminhos de arquivo, sem números de linha. Fragmentos que codificam uma decisão melhor que prosa (máquinas de estado, redutores, esquemas) são a exceção e declaram sua origem (geralmente um loft).

Fase 3 — Decomposição de tarefas (agente redige → C3 aprova)

Divida em fatias verticais sob .omc/specs/<feature-slug>/tickets/:

• NN-slug.md, um arquivo por tarefa, ordenado por dependência, cada um declarando blockedBy: [ids]
• cada tarefa cruza todas as camadas, é independentemente demonstrável e cabe em um contexto fresco
• refatorações amplas vão expandir-contratar: adicione a nova forma, migre em lotes, remova a antiga — cada lote uma tarefa

A validação mecânica do lado do agente é executada primeiro (independência, demonstrável, ajuste de contexto). Depois C3: apresente granularidade, arestas de bloqueio e mesclagens/divisões propostas para aprovação humana. Itere até aprovar. Marque cada tarefa ready-for-agent.

Regra de fiação de integração: toda fatia vertical inclui sua própria fiação e uma asserção de fumaça — uma fatia cuja saída nada monta, serve ou importa não está concluída. Costuras entre fatias que nenhuma fatia individual possui (montagem de rota, serviço estático, fiação de ponto de entrada) recebem uma tarefa de integração explícita como o último item da fronteira.

Fase 4 — Executar a fronteira

A fronteira é toda tarefa cujos bloqueadores estão todos concluídos.

Paralelo (padrão, 2+ tarefas). Entregue tarefas para a equipe: cada tarefa se torna uma tarefa da equipe, arestas blockedBy são transferidas — os mecanismos de reivindicação da equipe selecionam apenas tarefas de fronteira. Gere N trabalhadores. Cada trabalhador implementa com a disciplina tdd nas costuras aprovadas no C2, aplicando /oh-my-claudecode:minimal-code-discipline como a disciplina de tempo de escrita (ela permanece opt-in); uma tarefa fecha apenas após a revisão de código passar no diff, declarada pelo revisor — o implementador nunca se auto-aprova.

Serial (tarefa única, ou --serial). Delegue uma tarefa de cada vez a um subagente executor; mesma verificação de revisão.

Verificação de revisão de dois eixos. A revisão de fechamento é executada ao longo de dois eixos, em paralelo, relatada separadamente — nunca mesclada ou classificada em cruz, porque uma mudança pode passar em um eixo e falhar no outro (conforme os padrões mas com comportamento errado; fiel mas quebrando convenções). O revisor falha a tarefa quando qualquer eixo falha:

• Eixo de Padrões — o diff contra o volume correspondente de docs/standards/, mais uma linha de base de cheiros apenas de julgamento (um padrão de repositório documentado substitui a linha de base; qualquer coisa que as ferramentas já impõem é ignorada). Este é o consumidor permanente que mantém as superfícies de padrões referenciadas.
• Eixo de Especificação — o diff contra os critérios de aceitação desta tarefa (a especificação é o livro-razão total do qual as tarefas foram decompostas; é consultada apenas para rastrear de onde veio um critério e para julgar escopo contrabandeado — comportamento que nenhuma tarefa cobre).

Fase 5 — Relatório (agente apresenta → C5 aceita)

Após o fechamento da fronteira, produza um resumo de conclusão em .omc/specs/<feature-slug>/summary.md:

# Relatório de Conclusão: <Feature>
## O que foi feito
## O que não foi feito
## Suposições Abertas
## Sedimento (por linha)
## Mudanças na Superfície de Padrões

Suposições Abertas nomeia todo suposto fundo factual que a implementação assumiu como verdadeiro mas nunca explicitamente verificou. A proposta de revisão de código é um diff contra uma linha de base informada por suposições abertas; cada diffs que sinaliza uma violação de suposição reabre o item anterior.

Sedimento (por linha) é uma lista numerada de cada detecção marginal, surpresa, correção de bug fora do escopo ou descoberta adiada encontrada durante a implementação. Nomeie coisas que não têm lugar na especificação mas que um revisor futuro ou proprietário do sistema deveria saber. Não corte sedimento. Uma implementação que produziu zero sedimento é suspeita como o único resultado possível de negligência — sedimentos são o subproduto natural de um trabalho honesto.

Mudanças na Superfície de Padrões captura novo conhecimento que pertence a docs/standards/ — ou confirma que nenhuma mudança de padrão foi necessária.

A apresentação do relatório de conclusão fecha com uma sessão de verificação: produza um diff contra a especificação, anotado com proveniência (especificação → tarefa → commit → teste → diff). Isso prova que todo critério de aceitação na especificação é rastreável até um teste de passagem.

C5 aceita ou veta. Apenas na aceitação final: escreva os slots de sedimento nomeados na tabela abaixo. Antes, eles são mantidos apenas no relatório.

Slot	Localização	Conteúdo
Mudanças na Superfície de Padrões	docs/standards/ (atualizações ou novos arquivos)	novo conhecimento de padrões
Suposições Abertas	.omc/specs/<feature-slug>/open-assumptions.md	suposições não verificadas
Sedimento (por linha)	.omc/specs/<feature-slug>/sediment.md	lista numerada de sedimentos

Após a aceitação, Lançar está completo. Nenhum ciclo de vida posterior é de propriedade do Lançar.

Resumo de comandos

Comando	Efeito
lançar <briefing da missão>	Iniciar da Fase 1 (convergir)
lançar <caminho da especificação>	Pular para Fase 2 (síntese de especificação)
lançar --serial	Executar fronteira em série em vez de paralelo
lançar <correção de ponto único>	Entregar diretamente para execução, sair
/oh-my-claudecode:drydock	Auditoria do portão do estaleiro
/oh-my-claudecode:ask-navigator	Roteamento de névoa para o navegador

Notas de implementação

• A implementação da skill deve ser puramente determinística (sem estado oculto, sem aleatoriedade) — Lançar não possui estado de tempo de execução.
• A auditoria de portão é a única verificação de infraestrutura; Lançar não executa instalação, configuração ou verificação de dependência.
• A resolução de idioma é um pré-requisito para todos os artefatos localizáveis; sem uma tag resolvida, nenhum artefato é gravado.
• A implementação da skill deve tratar arquivos .omc/specs/<feature-slug>/ como o único diretório de saída, a menos que explicitamente coberto por outro mecanismo (CONTEXT.md, ADRs, docs de negócio).
• A revisão de dois eixos é obrigatória — nunca mescle os eixos em uma única classificação.
• O relatório de sedimentos deve sempre ser produzido; relatórios vazios de sedimentos são a maneira da equipe sinalizar que nenhum sedimento foi encontrado.