CLAUDE
CODE

O Claude Code detecta quando uma continuação adicionou menos de 500 tokens em relação à anterior, e para após 3 ocorrências seguidas. Em qualquer app que use stream com continuações (relatórios, análises longas), implemente a mesma lógica: meça o delta de tokens entre chunks, e se o delta cair abaixo de um limiar por N turnos, encerre antes de consumir cota. Isso pode cortar 40-60% do custo de API em prompts que entram em loop sem perceber.

O padrão Withheld Messages guarda erros em quarentena antes de exibi-los ao usuário. Se a API retornar 503, você não mostra o erro — você tenta fallback, retry, modelo alternativo. Só se tudo falhar o erro aparece. Em SaaS de IA: crie uma fila pendingErrors com timeout de 3s. Durante esse tempo, tente recuperar silenciosamente. O usuário nunca vê o erro que você já resolveu, e percebe confiabilidade superior mesmo com a mesma taxa de falhas.

Quando uma mensagem fica órfã (tool call sem result), o Claude Code não deleta — marca como tombstone e filtra na renderização. Em automações com múltiplos agentes: nunca delete uma mensagem de log com falha. Adicione um campo voided: true e filtre no query. Isso mantém rastreabilidade completa para debug, permite reprocessamento idempotente, e impede bugs de "deleção que corrompeu a sequência" — problema clássico em webhooks assíncronos.

A camada 1 do Context Management remove resultados de tools antigos quando o gap entre mensagens supera 1h. A lógica: cache frio já expirou de qualquer forma, então reescrever o contexto não tem custo marginal. Em apps de chat de longa duração, implemente um middleware que, ao retomar sessão depois de 1h+, limpa automaticamente tool results, imagens e blocos de código grandes do histórico — mantendo apenas mensagens text e um resumo. Reduz contexto em 60-70% sem perda perceptível de qualidade.

O autocompact do Claude Code tem Circuit Breaker com MAX=3 falhas consecutivas. Sem isso: 1279 sessões geraram 250K chamadas de API desperdiçadas em um dia. Em qualquer feature que chama API em background (compactação, resumo, análise), implemente circuit breaker: após N falhas, para por um período (ex: 30min), registra o evento, e retoma. O padrão mais simples: um contador em memória com timestamp do último failure — sem biblioteca, sem infra extra.

Stage 1 usa max_tokens=64 com stop_sequences para aprovar/bloquear ações triviais em milissegundos. Apenas ações ambíguas vão para Stage 2 (4096 tokens, chain-of-thought). Em qualquer SaaS de IA com classificação de intenção (spam, segurança, routing), implemente a mesma divisão: Haiku/Flash para filtro inicial, Sonnet/Opus só para casos duvidosos. A redução de custo é de 85-90% na classificação, com qualidade igual ou superior — porque o modelo grande foca só onde importa.

O Claude Code nunca permite edição de .bashrc, .gitconfig e similares, mesmo em modo bypassPermissions. Essa imunidade é hardcoded, não configurável. Em produtos multi-tenant com modo admin, implemente o mesmo conceito: crie uma lista explícita de ações que nenhum role pode executar — nem o super admin. Isso protege contra bugs de escalada de privilégio, engenharia social, e o clássico "mas eu sei o que estou fazendo" que precede acidentes de produção.

O Claude Code tem uma função que analisa as regras de permissão em busca de conflitos, regras que nunca disparam, e shadow rules (uma regra que cobre completamente outra). Para produtos com lógica de regras complexa (planos de acesso, roles, feature flags), implemente uma versão simples: rode uma análise periódica que lista todas as combinações rule+path e detecta duplicatas ou contradições. Bugs de permissão são os mais difíceis de encontrar em produção — e os mais críticos.

O Claude Code analisa os últimos 1024 bytes do output de um processo para detectar se está aguardando input (prompt interativo). Se detectado, cancela ou escalona. Em apps que executam subprocessos ou agentes long-running: implemente um watchdog que verifica periodicamente (a cada 10s) se o output mudou. Se parou mas não finalizou, e o último output contém padrões de "aguardando input" (ex: ? no final, Enter to continue), cancele e retorne erro explicativo. Isso resolve 80% dos timeouts misteriosos.

O sistema considera uma task terminada só depois de 5 verificações consecutivas sem mudança de estado. Isso evita falso positivo quando um processo tem burst de inatividade mas ainda está processando. Em workflows assíncronos (polling de job queue, webhook de processamento), use o mesmo conceito: não marque como complete na primeira checagem positiva — aguarde N confirmações. O N depende da variância do seu sistema, mas 3-5 é um bom padrão inicial que elimina race conditions.

Se Bash falha em um grupo de tools paralelas, o executor cancela imediatamente os siblings ainda em andamento. Em apps que executam múltiplas chamadas de API em paralelo (ex: buscar dados de 3 fontes para gerar um relatório): implemente um AbortController compartilhado. Quando qualquer fetch falha com erro não-retriable, chame controller.abort(). O usuário vê o erro em 200ms em vez de aguardar todos os timeouts — e você para de pagar por chamadas que não vão contribuir para o resultado.

O executor entrega resultados na ordem em que chegam, não na ordem em que foram iniciados. Isso evita que uma tool lenta bloqueie a exibição das que já terminaram. Em UIs de painel ou dashboard que carregam múltiplos widgets: implemente o mesmo padrão — renderize cada widget assim que seu dado chega, não espere todos completarem. Use Promise.race() ou um stream de resultados. O impacto em UX percebida é enorme: o usuário vê progresso imediato em vez de tela branca até tudo carregar.

O buildForkedMessages() garante que todos os agentes paralelos recebem o mesmo payload até o ponto de divergência (o sufixo task-specific). A API usa o prefixo como chave de cache — se é byte-idêntico, um único hit serve todos. Em apps que processam lotes com o mesmo contexto (ex: analisar 50 produtos com as mesmas instruções), estruture os prompts como: [system + contexto geral + instruções] + [task específica]. Nunca embaralhe metadados por task no começo do prompt — isso destrói o cache e multiplica o custo por N.

O padrão é: monte o payload base completo (system, histórico, instruções, contexto), então adicione APENAS a variação no final. Em processamento paralelo de documentos com Claude: crie uma função buildPayload(baseMessages, taskSpecific) que garante que baseMessages nunca muda entre chamadas do mesmo lote. Teste: log os primeiros 1000 bytes de cada payload paralelo — devem ser idênticos. Se não forem, você está pagando N vezes pelo mesmo cache.

O DreamTask roda em background entre sessões, consolidando fragmentos de memória em chunks coerentes via pipeline Orient→Gather→Consolidate→Prune. Em apps de IA com histórico longo (assistente pessoal, CRM inteligente), implemente uma versão simplificada: um job que roda a cada 24h e pede ao modelo para revisar as últimas 50 memórias, identificar duplicatas, resolver contradições, e descartar itens obsoletos. O prompt é simples; o impacto em qualidade de resposta é imediato e cumulativo.

O DreamTask usa o mtime de um arquivo como timestamp E mutex simultaneamente: se o arquivo existe e seu mtime é recente, outro processo está rodando. Se o processo falha, rollbackConsolidationLock() usa utimes() para retroagir o mtime e liberar o lock sem banco, sem Redis, sem infra extra. Em workers serverless que precisam de idempotência (ex: Cloudflare Workers), esse padrão de lock-via-filesystem-ou-KV é uma alternativa simples a Durable Objects para coordenação de curta duração.

Bones nunca persistem em disco — eles são recalculados deterministicamente do userId toda vez. Isso significa que nenhum usuário pode manipular sua raridade salvando/restaurando arquivos. Se você vai adicionar qualquer elemento de coleção ou conquista no seu produto: desenhe o mecanismo anti-exploit antes de pensar na UI. Identifique todos os pontos de savestate (disco, localStorage, banco) e defina quais são imutáveis. A percepção de fairness do sistema determina se os usuários vão querer exibi-lo ou escondê-lo.

O PRNG mulberry32 garante que o mesmo userId sempre gera o mesmo companheiro — único, mas estável. Isso é diferente de random puro (muda a cada reload) e de dado salvo (pode ser manipulado). Em features de personalização ou onboarding: use seed baseada em userId para elementos "uniquely yours" que não podem ser rerolados. Exemplo: avatares gerados por hash, paleta de cores da conta, tagline personalizada. O usuário sente que o produto foi feito pra ele sem você ter feito nada por usuário.

Writes vão para overlayPath; reads consultam overlay primeiro, filesystem real depois. Se o usuário aceita: promoteOverlay(). Se rejeita: descarta o overlay sem rastro. Em features de AI-suggested edits (como suggest mode no Notion ou suggestions no Google Docs), implemente o mesmo: crie uma "branch virtual" da entidade (documento, config, código), aplique as mudanças da IA nela, mostre diff, aguarde aprovação. O estado real nunca muda antes da confirmação — isso elimina uma classe inteira de bugs de "IA que fez coisa errada e não tem undo".

A execução especulativa é controlada por tengu_speculation, uma flag server-side. Isso significa que a Anthropic pode ativar, desativar ou ajustar o comportamento para % do tráfego sem nenhum deploy. Em features experimentais de IA (que são basicamente todas): separe o código de feature do código de rollout. Feature flags não são só para A/B test — são o mecanismo de segurança principal em sistemas onde o comportamento da IA em produção é diferente do comportamento em staging.

O Modo Undercover ativa-se ao detectar que o repositório é público/open-source — sem nenhuma intervenção humana. O prompt resultante proíbe qualquer referência a informações internas da Anthropic. Em assistentes de IA para empresas: implemente detecção automática de contexto sensível. Se o usuário está em uma sessão de suporte com cliente, injete automaticamente restrições sobre compartilhamento de roadmap interno. Se está em apresentação (detectável por horário + participantes), restrinja dados financeiros. Segurança contextual > segurança opt-in.

Não existe forma de desativar o Modo Undercover — nem mesmo via configuração de admin. Isso é uma decisão de produto deliberada: certos comportamentos de proteção não devem ser overridable por nenhum usuário, incluindo o próprio time da Anthropic. Em produtos com compliance (HIPAA, GDPR, SOC2), identifique os 3-5 comportamentos que nunca podem ser desligados e os isole do sistema de permissões normal. A regra prática: se a consequência de override for auditoria ou vazamento de dados, o toggle não deve existir.

O padrão # MAGIC DOC: [título] é detectado passivamente pelo FileReadTool — qualquer arquivo que o Claude lê e que tem esse header é automaticamente monitorado para atualizações por um subagente dedicado. Em assistentes de código: implemente convenções semelhantes. Um arquivo com // @ai-generated pode ser automaticamente sugerido para refatoração. Um CLAUDE.md com seção ## Auto-update pode disparar documentação automática após cada commit. Convenções são features que os usuários descobrem e ficam impressionados — sem você ter que anunciar nada.

O Magic Docs não faz polling periódico de arquivos — ele escuta o FileReadTool. Quando o Claude lê um arquivo como parte de qualquer outra tarefa, o listener verifica se é um Magic Doc. Em sistemas de cache ou sync: prefira listeners em pontos de acesso naturais (hooks em read/write operations) a polling periódico. O polling cria carga constante de CPU/rede e sempre tem latência. Um hook no momento do acesso é simultâneo ao evento e tem custo zero quando não há acesso — o modelo correto para a maioria dos casos de uso.

Uma linha de FFI (prctl(PR_SET_DUMPABLE, 0)) bloqueia qualquer processo do mesmo UID de fazer ptrace e injetar no heap onde os tokens de API ficam em memória. Em apps que lidam com API keys ou tokens em processo long-running (daemons, workers): considere adicionar esse call no início do processo em Linux. É uma linha de código que elimina um vetor de ataque que nenhum framework de segurança costuma cobrir. Em Node.js com bun ou com FFI nativa, o custo de implementação é trivial.

O Claude Code serializa uma única mensagem Protobuf com 10 linhas de encoding varint manual — sem protobufjs, sem geração de código, sem deps. Para uma única mensagem de um único tipo, isso é correto. Em microserviços que precisam serializar poucos tipos de mensagem para uma interface interna: avalie o custo de implementar o encoding manual dos seus N campos versus adicionar toda a toolchain Protobuf/Avro/Thrift. Se N < 5 campos, encoding manual é mais rápido de entender, mais fácil de debugar, e elimina uma categoria de vulnerabilidade de supply chain.

O host config do react-reconciler define como criar, atualizar e destruir "elementos" — que podem ser células de terminal, shapes de canvas, ou nós de PDF. O Claude Code implementou o config completo para terminal, incluindo profiling de commits lentos e debug via fiber walking. Em apps que precisam de UI em contextos não-DOM (geração de email HTML, PDF report, canvas interativo): considere uma thin layer baseada em react-reconciler ou Ink. A alternativa — código imperativo de manipulação direta — fica impossível de manter em semanas quando o design muda.

O reconciler do Claude Code inclui profiling de commits lentos — ele detecta quando um ciclo de render demorou mais do que um threshold e registra quais fibras foram responsáveis. Em apps React com problemas de performance difíceis de reproduzir: implemente um hook de profiling na camada do reconciler (ou via React Profiler API) que salva os top-3 componentes lentos de cada commit. Logs estruturados com tempo de commit + componente culpado identificam 90% dos problemas de performance em produção sem nenhuma sessão de profiling manual.

Ao portar o Yoga para TypeScript, o Claude Code garantiu que o mesmo algoritmo de layout roda no terminal, em Node.js, em qualquer ambiente que execute JS — sem nenhuma dependência do browser ou de bindings nativos. Em apps que precisam calcular layouts fora do browser (geração de PDF, email HTML, canvas server-side): usar uma implementação TypeScript pura do algoritmo de layout garante comportamento idêntico entre client e server, debug mais simples, e portabilidade total. O custo é performance ligeiramente menor; o benefício é eliminação de uma classe inteira de bugs de "funciona aqui mas não lá".

Cada dependência nativa (sqlite3, canvas, sharp, etc.) adiciona: compilação na instalação (que falha em ARM vs x64), bindings específicos por versão de Node, impossibilidade de rodar em algumas plataformas serverless, e surface de ataque de supply chain. O Yoga em TypeScript puro elimina todos esses problemas. Antes de adicionar uma dep nativa: avalie se existe uma implementação TypeScript pura do mesmo algoritmo. Para casos de uso de alta performance (video processing, crypto de alta frequência), a dep nativa é necessária. Para layout, parsing, serialização — quase sempre há uma alternativa pura.

Cada tick de wheel no terminal dispara um evento. Sem quantização, cada tick → setState → React render. Com SCROLL_QUANTUM=40, o scroll acumula até 40px antes de atualizar o estado. O resultado: 40x menos renders por scroll, UI fluida, sem perda visual perceptível. Em qualquer app React com scroll, resize, ou drag: implemente um buffer de quantização antes do setState. Para scroll: use Math.round(delta / 40) * 40. Para resize: debounce com 16ms. Para drag: threshold de 4px antes de atualizar posição. Essas três otimizações eliminam 90% dos problemas de performance de UI de alta frequência.

O dispatch de eventos do Claude Code replica o getEventPriority() do react-dom, que trata cliques com prioridade alta, scrolls com prioridade normal, e foco/blur com prioridade baixa. Em apps React com muitos eventos concorrentes: use startTransition() para envolver atualizações de baixa prioridade (filtros de busca, paginação, refresh de dados) e deixe eventos diretos do usuário (cliques, inputs) com prioridade normal. Isso sozinho resolve o bug clássico de "a UI trava enquanto o filtro está processando" sem nenhuma mudança de arquitetura.

Em vez de comparar strings de estilo entre frames ("color: #D97757; font-size: 13px" == "color: #D97757; font-size: 13px"), o Claude Code atribui IDs inteiros únicos a cada string distinta via Pool, e a comparação vira 3 === 3. Em apps React que renderizam listas longas com atributos repetitivos (status de pedido, tipo de usuário, categoria de produto): implemente um Map de string → integer para os valores mais frequentes e compare os IDs no shouldComponentUpdate ou useMemo deps. Para 10.000 rows, a diferença em tempo de diff pode ser 50-100ms por render.

O clock de animação do Claude Code só roda quando há pelo menos um subscriber (um componente animando algo visível). Sem subscribers, o clock para completamente — zero CPU, zero bateria. Em apps mobile ou com animações em background: implemente um clock global com contagem de subscribers. Use o IntersectionObserver para decrementar o contador quando componentes saem da viewport. Uma animação de loading spinner que você esqueceu em uma tab inativa consumindo CPU constante é o tipo de bug que aparece nos reviews da App Store como "drena bateria".>

O motor Vim define 11 estados como type VimState = 'normal' | 'insert' | 'visual' | .... A função transition(state, event) retorna { next?: VimState, execute?: () => void }. Nunca existem combinações inválidas porque TypeScript garante em compile-time que todos os estados são tratados. Em qualquer lógica com estados complexos (onboarding multi-step, wizard de checkout, editor com modos): abandone booleanos (isEditing, isPreviewing, isSaving) e use um union type. TypeScript vai te forçar a cobrir todos os casos e vai tornar estados impossíveis literalmente não-representáveis no tipo.

O motor Vim opera sobre graphemes via Intl.Segmenter — "👨‍👩‍👧‍👦" é um único grapheme, não 7 code points. Em qualquer app que processa texto de usuário (contagem de caracteres para Twitter/SMS, seleção de texto, highlight): use new Intl.Segmenter().segment(text) em vez de text.length ou text.split(''). Emoji compostos quebrando no meio é um bug de UX que aparece nos reviews de usuários internacionais como "app quebrado" — e é trivialmente evitável com uma linha de código.

Para cada arquivo indexado, o Claude Code mantém um bitmap de 26 bits (um por letra a-z). Se o query tem a letra 'z' mas o bitmap do arquivo não tem o bit 'z' setado, o arquivo é imediatamente descartado — sem nenhuma comparação de string. Isso elimina 80-90% dos candidatos antes de qualquer fuzzy matching caro. Em apps de busca com catálogo grande (produtos, usuários, documentos): implemente um pre-filter baseado em bitmap de caracteres para os campos mais buscados. Para 100.000 itens, isso pode reduzir os candidatos que chegam ao algoritmo de ranking de 100.000 para 2.000.

A busca fuzzy do Claude Code começa a retornar resultados antes de o índice estar completo — o build é incremental e assíncrono, e a busca consulta o índice parcial. Em apps com datasets grandes que precisam de busca em tempo real (file picker, command palette): não bloqueie a UI esperando o índice completo. Construa o índice em chunks de 100ms, sinalize o progresso (ex: "Indexando 3.421 de 15.000 arquivos"), e permita busca no índice parcial. O usuário percebe responsividade imediata e o índice completo fica disponível em background.

Um Set puro cresce indefinidamente com o histórico. Um ring buffer sozinho perde dedup para IDs antigos que retornam. O BoundedUUIDSet combina os dois: ring buffer com tamanho fixo (ex: 1000 IDs), um Set para lookup O(1), e quando o ring transborda, o ID mais antigo é removido do Set. Em qualquer sistema de WebSocket ou SSE onde mensagens podem chegar duplicadas (reconexão, retry de produtor): implemente esse padrão. Uma Map simples com timestamp + limpeza periódica funciona igualmente bem para a maioria dos casos e cabe em menos de 20 linhas.

O FlushGate é uma state machine de 3 estados: flushing (entregando mensagens acumuladas), switching (transição), live (apenas mensagens em tempo real). Isso garante que quando o cliente reconecta, ele recebe primeiro todas as mensagens que perdeu, na ordem correta, antes de começar a receber o stream live. Em chats, dashboards de métricas, ou feeds com reconexão: se você pular essa garantia, o usuário vê mensagens out-of-order — o que é pior do que não ver nenhuma. A state machine de 3 estados é a implementação mínima que garante o ordering correto.

O SendMessage usa diretórios de mailbox no filesystem para comunicação entre agentes — cada agente tem um diretório, mensagens são arquivos JSON. Não há Redis, não há broker, não há infra extra. Para multi-agent systems em produção com N < 100 agentes: um mailbox filesystem é mais debugável (você pode ler as mensagens com cat), mais resiliente (persiste através de crashes), e mais simples de implementar do que qualquer sistema de queue. A limitação é latência (file I/O > memory), mas para coordenação de agentes com granularidade de segundos, isso nunca é o gargalo.

O protocolo inclui shutdown_request com approve/reject e auto-resume de agentes inativos. Isso significa que um agente pode ser parado, reiniciado, e retomar de onde parou — o estado está no mailbox, não em memória volátil. Em qualquer job queue ou workflow de longa duração: design o estado como externamente persistível desde o início. Se o worker pode ser parado e retomado a qualquer momento com zero perda de progresso, você elimina a categoria de bugs mais cara em sistemas distribuídos — o processo que morreu no meio e deixou dados inconsistentes.

O transport em-processo do MCP usa queueMicrotask() para simular comunicação assíncrona bidirecional sem nenhuma socket, nenhuma serialização, nenhuma rede — tudo em memória no mesmo processo. Em testes de integração de MCP ou qualquer sistema baseado em mensagens: use o mesmo padrão para criar um transport fake. Ao invés de mockar a camada HTTP com jest.mock(), implemente um transport em-memória que entrega as mensagens via microtask queue. Seus testes ficam 10x mais rápidos e você testa o protocolo real — não um mock que diverge do comportamento de produção.

O MCP gating tem 6 níveis de acesso que controlam quais tools um contexto pode chamar. Isso permite que um agente de leitura nunca acesse tools de escrita, mesmo que esteja no mesmo sistema. Em produtos multi-tenant com tools de IA: implemente gating de tools baseado no plano do cliente, não apenas no papel do usuário. Tools de análise avançada ficam atrás de enterprise gate; tools básicas ficam disponíveis para todos. O gating no nível de tool é mais granular e mais seguro do que verificar permissão no início da ação.

Ao invés de tentar o fluxo automático, esperar timeout, e só então mostrar o botão manual, o Claude Code inicia os dois simultaneamente. Se o automático completar em 200ms, o manual é cancelado silenciosamente — o usuário nem percebeu. Se o automático falhar, o manual já está pronto. Em qualquer auth flow com fallback manual: implemente o race pattern. Promise.race([automaticAuth(), showManualAuthButton()]). O usuário nunca espera pelo timeout de uma tentativa para ver a opção alternativa — a latência percebida cai para o mínimo possível.

O API Service Layer tem um watchdog que monitora chunks do stream — se 90s passam sem nenhum chunk (mas a conexão ainda está "aberta"), o watchdog fecha e reabre. Streams TCP podem ficar em estado "open sem dados" indefinidamente por problemas de NAT, proxy ou load balancer sem enviar FIN. Em apps que consomem streaming de LLM: implemente um watchdog simples com setTimeout que reseta a cada chunk e reabre a conexão se disparar. Sem isso, 1-5% dos usuários experimentam sessões que parecem travadas mas estão tecnicamente abertas — e você nunca vê isso nos logs.

O BashTool detecta 15 patterns de comandos destrutivos (rm -rf, DROP TABLE, format, etc.) e requer confirmação explícita antes de executar. Em qualquer agente de IA com acesso a shell ou banco de dados: mantenha uma lista explícita de patterns que precisam de confirmação extra. Não confie apenas no modelo para saber o que é destrutivo — a lista hardcoded é o safety net que funciona mesmo quando o model reasoning falha em edge cases. Comece com os 10 mais óbvios e adicione quando algum incidente acontecer.

O WebFetchTool mantém um cache LRU de 50MB com TTL de 15min. Se o agente consulta a mesma URL múltiplas vezes na mesma sessão (documentação, API reference, pricing page), paga o custo de rede apenas uma vez. Em agentes que fazem research com múltiplas consultas: implemente cache em memória para chamadas externas com TTL razoável (10-30min). Isso reduz latência, custo de bandwidth, e o risco de rate limiting em APIs externas que não têm generosidade nos limites para agentes de IA.

Em vez de salvar "usuário X está no grupo A" em banco, o Claude Code deriva o bucket com SHA-256(userId + experimentId) % 100. O resultado: o mesmo usuário sempre cai no mesmo grupo, sem estado adicional, sem sincronização entre servidores, e sem PII armazenada. Em apps com feature flags ou A/B tests: implemente bucketing por hash. Uma função de 3 linhas substitui uma tabela de banco e toda a infraestrutura de sync. A única limitação: você não pode mover um usuário entre grupos manualmente — mas para a maioria dos A/B tests, isso é o comportamento correto.

O Plugin System usa três camadas onde cada mais específica sobrescreve a mais geral. User (global, todos os projetos) → Project (repositório específico) → Local (máquina específica). Em qualquer SaaS multi-tenant com config de comportamento: implemente exatamente esse modelo. Admin da plataforma define defaults, admin da organização sobrescreve, usuário individual sobrescreve sua instância. O custo de add essa estrutura depois de ter configurações em produção é alto — migrations complexas, dados inconsistentes, expectativas de usuário quebradas. Faça certo na v1.

O /thinkback usa alternate screen (sequência ANSI \x1b[?1049h) para renderizar a retrospectiva animada em um buffer separado — quando termina, o terminal volta ao estado exato anterior, sem rastro. Em CLIs com output longo ou interfaces temporárias (progress bar animada, preview de arquivo, diff visual): use alternate screen para conteúdo que não deve ficar no histórico do terminal. O usuário vê uma experiência rica; quando termina, o terminal está limpo. É a diferença entre "UI de produto" e "output de shell descartável".

O thinkback gera dois outputs em paralelo: a animação no terminal (live experience) e um HTML equivalente que pode ser convertido em vídeo para download. Isso transforma uma experiência efêmera em artefato compartilhável. Em qualquer feature de relatório ou retrospectiva: ofereça sempre uma forma de exportar como imagem/PDF/HTML além do display em tempo real. O usuário que consegue compartilhar o resultado é o seu melhor canal de aquisição — cada share é um anúncio orgânico para a audiência mais relevante possível.

Um prompt genérico "revise este código" produz revisão genérica. Agentes especializados — um para segurança, um para performance, um para test coverage, um para documentação — produzem análise profunda em cada dimensão. Em análise de documento, auditoria de contrato, ou due diligence com IA: divida a tarefa por dimensão especializada, não por seção do documento. Um agente que só procura cláusulas de indemnização encontra muito mais do que um agente genérico que lê o contrato inteiro. O custo de N agentes em paralelo é menor que N×tempo sequencial e maior em qualidade do que 1 agente tentando fazer tudo.

O /ultrareview "teleporta" o repositório para um ambiente remoto de computação (CCR), onde os agentes rodam em infra da Anthropic com acesso a resources que um laptop não tem. O terminal local fica completamente livre. Para produtos de análise de código ou dados com IA: ofereça uma opção "run in cloud" para análises longas. O usuário não precisa esperar com o laptop aberto — envia, recebe notificação, acessa resultado. Separar a UX de submit da UX de resultado multiplica o volume de análises pesadas que seus usuários vão fazer.

O /ultraplan envia a sessão para um remote runner com Opus e retorna o controle ao terminal imediatamente. O resultado chega via SendMessage quando o Opus termina. Em qualquer feature de IA com processamento >30s: separe a UX em dois momentos distintos — submit (instantâneo, confirma que foi recebido) e resultado (notificação quando pronto, com link para acessar). Isso é especialmente crítico em apps mobile onde o sistema pode matar processos em background. Um webhook + notificação push é mais confiável do que um stream longo aberto.

O /ultraplan usa explicitamente Opus — o modelo mais capaz e mais caro — para planejamento estratégico complexo. Outras tasks usam Haiku ou Sonnet. Em produtos de IA com múltiplos casos de uso: não use o mesmo modelo para tudo. Mapeie cada type de task para o tier de modelo mais adequado. Haiku para classificação, extração, formatação. Sonnet para geração, reasoning médio. Opus apenas para tarefas onde a diferença de qualidade justifica o custo (3-10x maior). Esse mapeamento geralmente reduz custo total em 40-60% com impacto mínimo em qualidade percebida.

O /rewind abre um seletor de checkpoints — pontos nomeados no tempo, não apenas o estado anterior. A diferença entre checkpoint nomeado ("antes de refatorar o auth") e undo linear ("10 passos atrás") é que o usuário consegue navegar de forma significativa. Em apps com estado complexo que muda ao longo do tempo (editores, configuradores, planos): ofereça checkpoints explícitos em momentos-chave em vez de apenas ctrl+z. Auto-salve checkpoints antes de operações destrutivas grandes. O usuário precisa de âncoras contextuais para navegar no tempo — não apenas um slider de "quanto tempo atrás".

Restaurar o código para ontem não deve forçar a restaurar a conversa para ontem — e vice-versa. Em assistentes de IA com estado persistente: separe o versionamento do contexto do versionamento do output/artefato. Um usuário pode querer continuar a conversa atual mas desfazer as mudanças de código das últimas 2 horas. Outro pode querer retomar uma conversa de semana passada mas manter o código atual. Implemente os dois como cursores independentes em seus respectivos stores, não como um único snapshot de estado global.

O /btw cria um fork com prefixo byte-idêntico à sessão principal, então adiciona apenas a pergunta específica. O cache da sessão principal já está quente — o fork não paga para reprocessar o mesmo contexto. Em plataformas de IA onde o usuário faz perguntas tangenciais durante uma tarefa maior: implemente fork/branch de contexto. O branch herda o contexto pai via cache, adiciona apenas o delta, retorna a resposta, e é descartado. O usuário paga apenas pelo tokens do delta, não pelo contexto inteiro repetido. Isso reduz custo de "perguntas rápidas" de O(contexto + pergunta) para O(pergunta).

O /btw retorna a resposta sem modificar a sessão principal — o contexto principal continua exatamente onde estava, como se a pergunta não tivesse acontecido. Em assistentes de IA com tarefas longas: implemente um "modo pergunta" que consulta o modelo em paralelo sem adicionar a troca ao histórico principal. Um usuário trabalhando em um refactor de 20 arquivos pode perguntar "como funciona o sistema de auth?" sem esse contexto aparecer no histórico do refactor. A sessão de trabalho fica limpa; a pergunta pontual é respondida. Separação de concerns no nível de contexto.

O /voice verifica: (1) auth válida, (2) kill-switch não ativo, (3) SoX instalado, (4) permissão de microfone — nessa ordem, falhando imediatamente com mensagem específica em cada etapa. Em features que dependem de hardware ou permissões (microfone, câmera, notificações, localização): implemente um preflight sequencial. Não tente usar o recurso e tratar o erro depois — verifique a condição antes. O custo de "verificar e falhar com mensagem clara" é infinitamente menor do que "tentar, falhar genericamente, e debugar com o usuário no suporte".

O preflight do /voice inclui verificação de um kill-switch server-side. Se a Anthropic precisar desativar o voice input por qualquer razão (bug de segurança, sobrecarga, problema legal), isso acontece instantaneamente para todos os usuários sem nenhum deploy. Em features de IA com acesso a recursos sensíveis (microfone, câmera, dados do sistema): implemente kill-switch antes de lançar. A capacidade de desativar uma feature em segundos é a diferença entre um incidente controlado e um incidente que escala. O custo de implementação é uma chamada de API a cada início de feature; o valor é controle total em emergências.

O companheiro é derivado de hash(userId) — sempre o mesmo para o mesmo usuário, único entre usuários, sem estado adicional. Em onboarding de produtos: use hash do email para gerar elementos de identidade únicos — avatar inicial, paleta de cores da conta, tagline personalizada, nome de instância. O usuário percebe personalização sem você ter armazenado preferências. Mais importante: essa personalização não pode ser "resetada" por acidente porque é derivada deterministicamente a cada vez. Não há estado adicional para sincronizar, para migrar, ou para corromper.

O sistema Buddy tem probabilidades reais e publicadas (1% legendary, 1% shiny) — não são percepções manipuladas. Quando o usuário consegue um legendary, o valor percebido é real porque a raridade é real. Em qualquer sistema de coleção ou conquista: publique as probabilidades. Usuários que entendem o mecanismo confiam mais no sistema e valorizam mais as conquistas raras do que usuários que suspeitam de manipulação. Transparência em gamificação não diminui o engajamento — aumenta, porque transforma sorte em um evento significativo compartilhável.

O Chrome como MCP server significa que o Claude Code pode navegar, ler DOM, preencher formulários e tirar screenshots usando exatamente o mesmo protocolo que usa para qualquer outra tool. Em times que constroem produtos: considere expor um MCP server para seus próprios produtos internos. Seu painel de analytics, seu CRM interno, seu sistema de tickets — cada um pode se tornar uma tool que seus agentes de IA usam diretamente, sem custom integration. O custo de implementar um MCP server básico é de horas; o benefício é conectividade com o ecossistema crescente de AI assistants.

Playwright abstrai sobre o Chrome DevTools Protocol; MCP permite ao Claude se conectar diretamente ao CDP via extensão. Remover a camada de abstração elimina a versão de Playwright, o gerenciamento de browser binaries, e a superfície de bugs que cresce com cada intermediário. Para automação de browser: avalie o CDP diretamente antes de adicionar Playwright. Para casos simples (navegar, clicar, ler texto), o CDP com WebSocket é direto e trivialmente implementável. Playwright faz sentido quando você precisa de cross-browser, page.waitForSelector abstraction, e o ecossistema de plugins. Para AI agents que só precisam de Chrome, o CDP diretamente via MCP é mais limpo.

Ninguém esperava encontrar uma loja de stickers em um CLI de programação. Por isso funciona — é o tipo de surpresa deliciosa que as pessoas compartilham. Em produtos para devs: plante pelo menos uma feature que claramente não é séria mas demonstra que a equipe tem personalidade. Uma loja de merch acessível via CLI, um spinner com piadas, um help text com haiku — essas features custam horas de implementação e geram meses de posts orgânicos. A pergunta não é "isso é útil?" — é "isso é o tipo de coisa que vai aparecer no HN ou Twitter por conta própria?".

Quando um usuário compra um sticker de um produto de software, ele está fazendo um gesto de identidade — está declarando publicamente que usa e gosta do produto. Esse gesto aumenta o custo psicológico de churnar. Em produtos com base de usuários engajada: ofereça qualquer forma de expressão de afiliação (sticker, camiseta, badge de Discord, frame de LinkedIn). A mecânica é simples: usuário que se identifica com o produto permanece mais tempo, refere mais pessoas, e perdoa mais falhas. O custo de um programa de merch é trivial comparado ao impacto em LTV dos usuários que participam.

O usuário está mais vulnerável à ansiedade exatamente quando o spinner está rodando. Um "Processando..." genérico confirma a ansiedade. Um "Flibbertigibbeting" transforma o momento em sorriso. Em qualquer app com operações assíncronas: crie uma lista de 20-50 mensagens de loading que reflitam a personalidade do produto. Categorize por contexto (análise, geração, busca, conexão) e sorteie. O custo é mínimo; o impacto em percepção de qualidade é desproporcionalmente alto — usuários avaliam a "sensação" do produto tanto quanto as features, e o loading state é um momento high-stakes de sensação.

"Clauding" é um verbo que não existe no dicionário. É perfeito exatamente por isso — é proprietário, inimitável, e cria uma referência cultural exclusiva do produto. Quando um usuário diz "o Claude está Clauding" para um colega, ele está usando linguagem do produto na vida real — o indicador mais forte de brand embedment que existe. Em produtos de IA: crie pelo menos um verbo proprietário para o que seu produto faz. Não "Processando" — "[NomeDoProduto]ing" ou um verbo inventado que só faz sentido no seu contexto. Propriedade linguística é um moat que nenhuma feature copia.

Tengu (analytics prefix), Plover (autoDream gate), Bagel (WebBrowser tool) — nenhum desses nomes revela o que a feature faz a alguém que não está no time interno. Em times que desenvolvem features competitivas em repositórios semi-públicos ou com contractors externos: adote codinomes para features em desenvolvimento antes do anúncio. O processo é simples: escolha um animal ou conceito aleatório (não relacionado à feature), use consistentemente em commits, issues, e código. Quando lançar, o anúncio pode usar o nome real — a menção nos logs históricos é irrelevante depois do lançamento.

XAA não é um codinome genérico — é um acrônimo técnico que descreve um padrão de auth enterprise (Cross-App Access, Layer-3). A distinção é importante: codinomes são para features cujo propósito você quer esconder; acrônimos são para conceitos técnicos que precisam de identidade própria para ser referenciados de forma consistente. Em times técnicos: crie acrônimos para os padrões arquiteturais que você usa repetidamente (BUC para BoundedUUIDSet, FG para FlushGate). Isso permite discussão precisa em code review, issue tracker, e onboarding sem repetir a descrição completa toda vez.

Medir quantos usuários rodam dois Claudes simultaneamente é uma métrica de profundidade de uso que DAU não captura. Em produtos de produtividade: identifique o comportamento que distingue power users de usuários casuais e meça explicitamente. Para um editor: quantos arquivos abertos ao mesmo tempo. Para uma ferramenta de análise: quantas queries em paralelo. Para um assistente: quantas tasks simultâneas. Essa métrica vai guiar features de forma muito mais eficaz do que "mais usuários" — porque usuários power são o segmento que fica, paga mais, e indica para outros power users.

Em vez de lançar tudo em UTC midnight (que cria um spike no TechCrunch mas é 11pm em São Paulo e 8am em Tóquio ao mesmo tempo), o Rolling Wave lança progressivamente por timezone — primeiro UTC-8 (Pacific), depois UTC+0 (Europa), depois UTC+9 (Ásia). Cada "onda" gera seu próprio ciclo de posts, tweets e discussões na hora de pico local de cada mercado. Para lançamentos de produto globais: planeje o rolling wave desde o início. Não é só sobre timezone — é sobre ter 3 oportunidades de coverage em vez de 1, e garantir que cada mercado recebe atenção no momento certo.

CompanionBones é recalculado de hash(userId) toda vez que necessário — nunca salvo em disco. Se o banco de dados vazar, não há registro de qual Bones pertence a qual usuário. Em apps com dados de preferência ou comportamento do usuário: separe o que precisa ser persistido do que pode ser derivado. Preferência de tema pode ser derivada de hash + timezone (hora local → light/dark). Sugestões de onboarding podem ser derivadas de dados já existentes. Dados derivados = zero risco de vazamento, zero custo de storage, zero sincronização entre dispositivos. Não persista o que você pode calcular.

O nome do companheiro é gerado pelo modelo na primeira interação — único, personalizado, e persistido apenas esse resultado (não o processo). O modelo recebe as características do companheiro (espécie, stats, raridade) e gera um nome que faz sentido para aquela combinação. Em onboarding com IA: use o modelo para gerar elementos de identidade personalizada na primeira sessão (nome de instância, tagline, welcome message) e persista apenas o resultado. O usuário percebe uma experiência única e personalizada; você tem o custo de uma chamada de API no onboarding. O ROI em percepção de qualidade é imediato.