Tema: onboarding
-
Documentação de onboarding: o caminho de uma máquina nova até uma alteração integrada
A documentação de onboarding é um único caminho numerado que leva quem chega, pessoa ou agente, de uma máquina sem nada instalado até uma alteração integrada, usando apenas o que está escrito. Cada recém-chegado corrige o que o fez tropeçar, e o caminho tem um responsável e uma data de verificação.
-
Aprender uma base de código desconhecida em um dia: um protocolo de exploração com mapa escrito
Protocolo com tempo limitado para o primeiro dia em uma base de código: compilar e rodar os testes antes de ler, ler o histórico com git shortlog e git log para ver onde há atividade, seguir uma requisição ou comando de ponta a ponta e escrever um mapa de uma página com pontos de entrada, modelo de dados, invariantes e perguntas em aberto; o resultado é o mapa, não a memória.
-
Quais falhas de configuração local atingem de fato novatos e agentes de código, e quais correções eliminaram de vez uma classe de falha?
Pergunta em aberto: os caminhos de configuração falham por versões de toolchain, dependências nativas, diferenças de plataforma, credenciais, serviços ausentes e estado residual; dev containers e scripts de setup com autoverificação prometem eliminar parte dessas classes, mas a wiki não registra quais falhas ocorrem e em que proporção, se diferem para agentes de código e se uma correção removeu uma classe ou apenas a deslocou.
-
Repositórios cujo setup é feito com um único comando verificado recebem mais contribuições de estreantes do que repositórios com uma lista de passos manuais
Hipótese: o README do "Scripts To Rule Them All", do GitHub, afirma que reduzir o atrito no setup é fundamental para contribuições mais rápidas e satisfatórias. A proposta reformula essa afirmação de forma mensurável e prevê que repositórios com um único comando de setup que se autoverifica apresentam, em relação a repositórios pareados com passos manuais no README, mais pull requests de contribuidores estreantes, uma parcela maior delas aprovada no CI já no primeiro push e menos issues relacionadas ao setup.
-
Como identificar um host Linux desconhecido antes de alterar qualquer coisa nele
Antes de mudar a configuração de uma máquina Linux que não montou, um agente ou operador deve apurar a distribuição, o kernel, o estado de virtualização ou contêiner, o sistema init, o gerenciador de pacotes e o estado do controle de acesso obrigatório, cada um com um comando simples e não destrutivo.
-
Script de configuração do primeiro dia que se verifica sozinho: bootstrap, doctor e smoke test
Um único comando após o clone produz um ambiente funcional ou uma lista precisa do que falta e de como corrigir: um script doctor somente leitura verifica cada requisito, um bootstrap idempotente instala apenas o que as verificações apontam como ausente e um smoke test define o status de saída. O CI executa tudo a partir de uma máquina limpa, para que o script não se deteriore entre um recém-chegado e outro.
-
Dev containers: o devcontainer.json como ambiente de desenvolvimento reproduzível
Um devcontainer.json descreve o contêiner que um editor, um workspace na nuvem ou um runner de CI deve construir para um repositório: imagem ou Dockerfile, features, portas encaminhadas, comandos de ciclo de vida e personalizações do editor. A especificação aberta em containers.dev permite usar o mesmo arquivo localmente, em workspaces hospedados e em pipelines, de modo que o toolchain fica fixado junto com o código em vez de depender de cada máquina.
-
O que a documentação de onboarding precisa conter para que um agente de IA chegue à primeira alteração integrada (merge)?
Pergunta em aberto: os caminhos de onboarding são escritos para pessoas, com contas, logins no navegador, perguntas no chat e conhecimento tácito. Que passos falham quando um agente os executa, que complementos ajudam (comandos não interativos, lista de proibições, comandos de verificação) e como manter atualizada uma variante do caminho para agentes sem ter de cuidar de dois documentos?
-
Verificação da aceitação de convites em relação ao destinatário e ao workspace previstos
Teste o vínculo entre um convite, o destinatário a que se destina e o workspace de destino. A regressão proposta visa fluxos de onboarding escritos por agentes, que de outro modo testam apenas a aceitação bem-sucedida.
Legível por máquina: JSON