Altere um monorepo TypeScript full-stack e teste as funcionalidades de LLM pelo significado

## Rode só os comandos e verificações por pacote que a CI usa Descubra os comandos documentados de desenvolvimento, build, lint, formatação, testes, testes de integração e avaliação do repositório antes de executar qualquer coisa. Use o comando específico do pacote para o espaço de trabalho afetado, em vez de substituí-lo por uma ferramenta aplicada à raiz inteira. - Execute um único teste por meio do caminho ou filtro de nome compatível. - Execute as avaliações de IA pelo comando de avaliação dedicado do pacote de IA, a partir da raiz do repositório. - Use o build ou a verificação de tipos do aplicativo alinhado à CI; não execute na raiz uma verificação de tipos sem suporte que revele dívidas não relacionadas do monorepositório. - Instale as dependências antes dos testes ou builds somente quando o espaço de trabalho ainda não estiver instalado. - Não inicie servidores de desenvolvimento nem builds completos, a menos que a tarefa os solicite explicitamente. A validação deve corresponder ao pacote alterado e às verificações usadas pela CI. ## Teste o que o código faz, não como ele foi escrito Consulte o guia de testes do repositório antes de criar ou alterar testes. Para correções de falhas no núcleo, use a sequência vermelho-verde-refatorar quando for prático: primeiro reproduza a falha, depois faça a menor correção e, por fim, melhore a estrutura sem alterar o comportamento. Mantenha os testes unitários junto aos arquivos de código-fonte. Coloque testes de integração, de ponta a ponta e de avaliação de IA nas árvores de testes designadas. Use a implementação real de logs, a menos que o teste trate especificamente do limite do logger. Prefira testes que detectem uma regressão de comportamento relevante. Evite asserções de pouco valor que apenas repitam detalhes privados da implementação. Alterações em prompts e no comportamento do modelo devem incluir avaliações semânticas ou testes de contrato estruturado, além dos testes comuns de código. ## Instale as dependências no espaço de trabalho que as usa Instale uma dependência no espaço de trabalho que a utiliza, não na raiz do monorepositório. Ao adicionar um novo pacote de espaço de trabalho, atualize todos os manifestos de build de contêineres de produção e locais que copiam metadados de pacotes antes da instalação das dependências. Mantenha as variáveis de ambiente sincronizadas entre o arquivo de ambiente de exemplo, o módulo de validação em tempo de execução e a configuração de build do monorepositório. Use o prefixo de variável pública do repositório nas variáveis expostas ao código do navegador. Quando o comportamento do framework for sensível à versão ou pouco claro, leia a documentação fornecida com a dependência instalada antes de alterar o código. Não se baseie na memória nem na documentação de outra versão instalada. ## Importe direto do arquivo que define cada item e derive os tipos dos esquemas Use verificação estrita de valores nulos e infira os tipos TypeScript a partir dos esquemas de validação, em vez de duplicar interfaces. Não exporte um tipo usado somente no arquivo em que foi definido. - Mantenha todos os imports no início do arquivo; não adicione imports dinâmicos no meio dele. - Importe do código-fonte original, em vez de criar cadeias de reexportação ou arquivos agregadores. - Importe funções utilitárias individuais, em vez de toda uma biblioteca de utilitários. - Use o alias configurado da raiz do projeto para imports internos do aplicativo. - Coloque funções auxiliares no final do arquivo. - Mantenha um recurso por arquivo de rota de API. A propriedade direta facilita a compreensão das dependências, da eliminação de código não utilizado e do impacto das alterações. ## Extraia funções auxiliares só quando deixarem o código mais claro Por padrão, mantenha a lógica embutida e junto ao local de uso. Pequenas expressões duplicadas costumam ser mais claras do que um auxiliar criado cedo demais. Não extraia uma função que apenas renomeie e encaminhe parâmetros. Faça a extração quando um auxiliar nomear um conceito relevante do domínio, facilitar a leitura do fluxo de controle ao redor ou manter consistente um comportamento sensível à correção em vários fluxos. Centralize cedo uma lógica duplicada substancial quando as cópias precisarem permanecer sincronizadas para evitar falhas. Evite expressões ternárias grandes ou aninhadas. Prefira um fluxo de controle simples, um auxiliar focado ou uma tabela de consulta. Adicione comentários para explicar por que uma decisão existe, não para descrever o que um código autoexplicativo faz. Prefira a alteração legível mais simples. Preserve a compatibilidade retroativa somente quando o requisito a exigir; caso contrário, atualize diretamente os pontos de chamada coordenados, em vez de adicionar um caminho de migração sem uso. ## Não deixe dados pessoais em níveis de log amplos Não repita campos de contexto do logger que já foram anexados em um ponto anterior da cadeia de chamadas. Coloque campos que identifiquem pessoas, como remetente, destinatário ou assunto da mensagem, somente no nível de rastreamento mais restrito do repositório. Uma exceção documentada explicitamente pode permitir o identificador do próprio usuário autenticado em níveis mais amplos, mas não estenda essa exceção a dados de terceiros. Mantenha os testes no logger real para que filtros de privacidade, propagação de contexto e formatação continuem sendo exercitados. Antes de adicionar um log, identifique seu público, retenção, sensibilidade e se o contexto existente já fornece o valor. ## Derive o estado da interface dos dados e use os componentes compartilhados Não copie propriedades obtidas nem dados do servidor para o estado local por meio de um efeito. Prefira valores derivados para visualizações somente de leitura e um estado de edição explícito para rascunhos controlados pelo usuário. Use a biblioteca de componentes aprovada pelo repositório antes de criar um elemento básico personalizado. Renderize conteúdo assíncrono por meio do wrapper compartilhado de carregamento e erro para manter consistentes os estados de carregamento, falha e sucesso. Mantenha componentes de página específicos de uma rota ao lado do arquivo de entrada dessa rota, sem adicionar diretórios de componentes aninhados. Coloque os componentes compartilhados entre páginas no diretório de componentes compartilhados do aplicativo. ## Faça mudanças de dados com server actions e esquemas de validação compartilhados Escolha o middleware de rota conforme o nível de acesso: tratamento público de erros, acesso de usuário autenticado ou acesso limitado à conta. Exporte tipos de resposta derivando-os da função de dados, em vez de duplicar interfaces de resposta. Use ações de servidor por meio da camada de ações seguras do repositório para mutações na web. Reserve rotas de API POST para integrações que exijam um contrato HTTP externo estável, como clientes nativos. Defina os esquemas de validação de mutações nos módulos de validação designados e infira os tipos de entrada a partir desses esquemas. Use o cache de cliente estabelecido para leituras e invalide a chave afetada depois da mutação. Crie formulários com a biblioteca de formulários aprovada e o hook de ação, e encaminhe falhas pelo formatador compartilhado de erros de ação. Use abstrações de provedores na lógica normal do aplicativo. Verifique um tipo concreto de provedor somente em um limite real de integração. Evite transações dinâmicas de banco de dados baseadas em callback quando o repositório as proibir. ## Teste as funcionalidades de LLM pelo significado, não por listas de palavras-chave Corrija modos gerais de falha do modelo, não a redação de um único caso de avaliação. Não adicione listas de palavras-chave ou expressões proibidas a prompts, avaliações ou testes apenas para capturar a formulação atual do modelo; verificações textuais são especialmente frágeis entre idiomas. Valide resultados semânticos com um critério avaliador ou contrato estruturado, como verificar se o modelo evita esclarecimentos desnecessários ou declarações de estado sem suporte. Nunca condicione a injeção de contexto nem o comportamento de ferramentas a correspondências improvisadas com o texto do usuário. Use estado estruturado, metadados ou eventos explícitos. Faça com que cada descrição de ferramenta seja autossuficiente: finalidade, significado dos parâmetros, orientação de seleção, pré-requisitos e restrições de segurança específicas da ferramenta. Mantenha no prompt do sistema somente as políticas transversais de identidade, confirmação, segurança e formatação; coloque as orientações de cada ferramenta na descrição correspondente. ## Revise o diff e informe quais verificações rodaram Antes de informar a conclusão, inspecione o diff alterado e execute o menor conjunto alinhado à CI que comprove o comportamento afetado. Amplie para testes de integração ou de avaliação quando o contrato atravessar esses limites. Confirme que: - o espaço de trabalho correto seja responsável por todas as dependências e variáveis de ambiente; - os testes cubram o comportamento e novos arquivos de teste possam ser descobertos; - imports, tipos derivados de esquemas, auxiliares e abstrações sigam as convenções do repositório; - os logs não ampliem a exposição de dados pessoais; - o estado da interface, as mutações, a validação, a invalidação de cache e os estados de carregamento usem os padrões estabelecidos; - o comportamento do LLM seja testado semanticamente, não por redações frágeis; - nenhuma verificação sem suporte na raiz inteira, nenhum servidor de desenvolvimento e nenhum build completo tenham sido executados sem autorização. Informe quais verificações foram executadas e quais verificações mais amplas foram mantidas intencionalmente fora do escopo.