Modificar um kit de UI para console seguindo a documentação atual e conferir a tela real

## Seguir a documentação atual do repositório, não padrões de versões antigas - Quando um projeto declara uma reescrita significativa, pressuponha que padrões aprendidos anteriormente podem ser incompatíveis, mesmo que os nomes pareçam familiares. - Leia a introdução atual à migração do repositório antes de projetar, editar ou revisar código. - Use o padrão mínimo de aplicação, a terminologia, o ciclo de vida e as observações de compatibilidade atuais da documentação versionada do código-fonte. - Dê preferência à constituição do projeto, ao guia de contribuição, ao contexto legível por máquina e às regras aninhadas, em vez de recorrer à memória ou a exemplos de versões anteriores. - Se a documentação atual divergir do conhecimento prévio, siga o repositório atual e registre a divergência, em vez de combinar os dois projetos. ## Antes de começar, distinguir se a tarefa é criar um app ou mudar o próprio kit - Primeiro, classifique a solicitação como criação de aplicações, contribuição para o kit de ferramentas, correção de erro ou gravação e verificação visual. - Use o guia específico de aplicações e o catálogo de padrões para aplicações consumidoras. - Use o fluxo de contribuição para recursos e defeitos da biblioteca. - Use o fluxo de gravação para mudanças visíveis na UI e evidências de interação. - Leia a documentação dos conceitos principais sobre ciclo de vida, hierarquia de visualizações, leiaute, eventos canceláveis e terminologia do domínio antes de alterar essas áreas. - Não aplique componentes internos exclusivos de contribuidores a exemplos de aplicações nem atalhos de aplicações ao trabalho na biblioteca principal. ## Passar pelas checklists antes de cada edição e depois de escrever código - Antes de cada edição de arquivo, percorra a lista de atualização do repositório para identificar erros comuns e restrições locais. - Depois de escrever ou modificar código, aplique toda a lista de validação posterior à geração. - Leia a regra detalhada de cada tópico afetado, incluindo formatação, declarações de tipo, sintaxe de construção, padrões de eventos, texto Unicode, organização do código, documentação, testes, diagnósticos e áreas frágeis. - No modo de planejamento, crie um plano em Markdown no diretório de planos designado, com etapas de implementação, arquivos afetados, oportunidades de reutilização e verificação. - Mantenha o plano alinhado ao escopo real e atualize-o quando as evidências alterarem o caminho da implementação. ## Colocar os testes novos na suíte paralela por padrão - Restaure as dependências, compile uma vez e execute testes focados sem recompilar enquanto a compilação ainda estiver atual. - Coloque novos testes no conjunto paralelizável por padrão. - Use o conjunto não paralelo somente quando um estado estático de todo o processo for inevitável e explique essa dependência. - Nunca acrescente nova cobertura a um conjunto legado que esteja programado para reescrita ou remoção. - Selecione um único método ou uma única classe durante a iteração e depois amplie para o projeto relevante quando o resultado focado for aprovado. - Consulte o inventário de testes antes de escolher cobertura de integração, estresse, desempenho, paralela ou não paralela. ## Gravar o terminal em execução para conferir as mudanças de UI - Não entregue uma mudança visual sem observar a interface em execução. - Execute a aplicação em um pseudoterminal, injete pressionamentos de teclas representativos e capture a sessão renderizada. - Leia a gravação legível por máquina quadro a quadro para verificar o que realmente apareceu, em vez de confiar apenas em uma visualização humana. - Anexe um artefato visual quando os revisores precisarem avaliar a aparência ou a interação. - Para asserções determinísticas, use injeção de entrada no processo, tempo virtual e captura de tela no nível do driver. - Verifique o leiaute, o foco, o tratamento de entrada, os grafemas Unicode, o cancelamento e o comportamento de redesenho no nível afetado pela mudança. ## Seguir as regras exatas de espaçamento e tipos do repositório - Preserve os espaços exigidos pelo repositório ao redor de chamadas e indexação, a colocação de chaves e as regras de linhas em branco. - Use tipos explícitos, exceto para o pequeno conjunto de tipos primitivos incorporados permitido pelo guia local. - Dê preferência à construção com tipo de destino e à sintaxe de expressões de coleção quando exigido. - Use apenas um tipo public ou internal por arquivo. - Ordene os membros e os campos de apoio de acordo com a regra de organização do código. - Para parâmetros de retorno de chamada não utilizados, use a convenção de descarte do repositório. - Execute o formatador e as verificações posteriores à geração do repositório; não descarte diferenças de estilo como se fossem meramente estéticas. ## Usar saídas antecipadas e os termos próprios do projeto - Dê preferência a cláusulas de guarda e saídas antecipadas; inverta as condições em vez de envolver o caminho bem-sucedido em aninhamentos profundos. - Aplique a mesma regra de saída antecipada a métodos, retornos de chamada e laços. - Use os termos de contenção do projeto de modo consistente e reserve termos genéricos de relacionamento para referências sem contenção. - Escreva código que se explique por nomes, tipos e estrutura antes de adicionar comentários. - Na documentação de referência, instruções e API, indique o objetivo e depois forneça uma ação imperativa direta. - Documente contratos públicos, o comportamento de fluxos canceláveis, o tratamento de grafemas Unicode e invariantes não óbvias com o formato de documentação exigido pelo repositório. ## Adicionar testes de regressão sem reduzir a cobertura - Marque os testes gerados por agentes com a anotação de agente e modelo aceita pelo repositório. - Nunca reduza a cobertura para fazer uma mudança ser aprovada. - Evite a inicialização global da aplicação nos testes, a menos que o comportamento exija especificamente um estado de todo o processo. - Dê preferência a uma preparação isolada, entradas determinísticas, tempo virtual e asserções observáveis. - Coloque cada teste no conjunto correspondente ao seu modelo de estado, e não apenas naquele com o nome de arquivo mais próximo. - Acrescente cobertura de regressão para o defeito ou comportamento visível ao usuário, incluindo casos de leiaute e ordem de eventos quando forem pertinentes. ## Usar o logging do repositório e não mexer em código frágil ou sem relação - Use os recursos de registro, registro de testes e rastreamento do repositório; não escreva diretamente no console a partir do código da biblioteca ou dos testes. - Não refatore como limpeza incidental um subsistema documentado como frágil. - Não modifique código sem relação com o trabalho ao implementar um recurso ou uma correção focada. - Não introduza novos avisos do compilador, analisador, documentação ou testes. - Releia as diferenças para conferir formatação, terminologia, localização dos testes e qualquer ampliação acidental do escopo antes de informar a conclusão. - Se uma área frágil precisar ser alterada, isole a menor edição necessária e verifique seu comportamento específico antes de executar testes mais amplos.