Desde a versão 2.14, o RadIA passou por uma evolução importante. O foco deixou de estar apenas na expansão do catálogo de ferramentas e avançou para algo mais ambicioso: permitir que o desenvolvedor Delphi compreenda, altere, valide, execute e investigue uma aplicação dentro de um fluxo integrado e verificável.
As versões 2.15.0 e 2.15.1 ampliaram a integração com o código Delphi, fortaleceram a automação de aplicações VCL em execução, melhoraram o processo de diagnóstico e adicionaram novas proteções às interfaces baseadas em WebView2.
Neste artigo, veremos o que mudou e como essas melhorias afetam o uso diário do RadIA.
Validação unificada de código Delphi
Uma das principais novidades é a validação unificada de código.
O RadIA agora consegue reunir diferentes fontes de análise em uma mesma experiência:
- regras internas específicas para Delphi;
- verificação pelo compilador;
- execução isolada do DelphiLint;
- integração com resultados do SonarQube;
- apresentação dos problemas encontrados de forma estruturada e navegável.
A proposta não é apenas informar que existe um problema. O RadIA procura explicar:
- onde o problema foi encontrado;
- qual regra foi violada;
- qual é a severidade;
- qual ferramenta originou o diagnóstico;
- se existe uma correção possível;
- quais pré-requisitos ainda precisam ser configurados.
Quando uma correção pode ser automatizada, ela não é aplicada diretamente. O RadIA prepara uma alteração revisável, apresenta o impacto e mantém o fluxo de consentimento e reversão.
Isso permite usar ferramentas externas de qualidade sem transformar o processo em uma coleção de comandos desconectados.
Painel unificado de problemas
Os diagnósticos também passaram a ser consolidados em uma superfície comum.
O painel de problemas pode reunir informações provenientes de:
- compilação;
- testes DUnitX;
- cobertura;
- análise de memória;
- consistência entre DFM e Pascal;
- problemas de concorrência;
- DelphiLint;
- SonarQube;
- revisões feitas pelo próprio RadIA.
Os resultados podem ser filtrados e usados para navegar até o arquivo ou trecho correspondente.
Essa centralização reduz o esforço de procurar o mesmo problema em diferentes janelas, arquivos de log ou ferramentas externas.
Refatorações semânticas mais completas
A versão 2.15 ampliou significativamente a capacidade do RadIA de compreender a estrutura de uma aplicação Delphi.
Antes de modificar o código, o RadIA pode analisar símbolos, declarações, implementações, referências, herança e dependências entre units.
Rename Symbol
A renomeação semântica identifica declarações e usos confirmados antes de preparar a alteração.
Ela pode alcançar:
- declarações;
- implementações;
- chamadas;
- arquivos fechados;
- referências em DFM;
- membros relacionados por herança.
Homônimos e referências ambíguas não são tratados como correspondências válidas automaticamente.
Change Signature
A alteração de assinatura consegue coordenar:
- declaração do método;
- implementação;
- parâmetros;
- chamadas confirmadas;
- métodos relacionados em uma hierarquia.
Antes da aplicação, o RadIA produz uma alteração multiarquivo revisável e bloqueia situações incompatíveis ou ambíguas.
Extract Method
O RadIA pode analisar uma seleção estruturalmente válida, identificar os valores usados pelo trecho e preparar a extração para um novo método.
O conteúdo original permanece inalterado até que a proposta seja aprovada.
Move Type
Também foi adicionada a movimentação transacional de tipos entre units.
O processo considera:
- declaração do tipo;
- implementações relacionadas;
- cláusulas
uses; - referências confirmadas;
- dependências privadas;
- risco de referência circular.
Se a mudança não puder ser feita com segurança, a operação é interrompida antes de alterar os arquivos.
Refatoração consciente de hierarquia
Renomear ou alterar um método virtual não é o mesmo que modificar um método isolado.
O RadIA passou a construir uma visão da hierarquia de tipos para encontrar relações entre:
- classe ancestral;
- classes descendentes;
- métodos virtuais;
- métodos abstratos;
- overrides;
- chamadas compatíveis.
Com isso, uma alteração pode ser preparada para toda a família de métodos relacionada.
Overloads, relações ambíguas e assinaturas incompatíveis são apresentados como bloqueios, evitando mudanças parciais que poderiam deixar a aplicação em um estado inconsistente.
Execução de testes baseada em impacto
A compreensão semântica também pode ser usada para selecionar testes relacionados às áreas modificadas.
O RadIA analisa as alterações e procura identificar quais testes DUnitX possuem relação com os símbolos, units ou comportamentos afetados.
Essa execução baseada em impacto não elimina a necessidade da suíte completa antes de uma release. Ela serve para reduzir o ciclo de feedback durante o desenvolvimento, permitindo testar primeiro o que possui maior probabilidade de ter sido afetado.
Breakpoints e diagnóstico avançado do debugger
A integração com o debugger também evoluiu.
Além das operações básicas de iniciar, pausar, continuar e encerrar a depuração, o RadIA possui ferramentas para trabalhar com:
- breakpoints;
- condições;
- contagem de ocorrências;
- logpoints;
- frames;
- filtros de thread;
- call stack;
- watches;
- avaliação segura de expressões;
- localização atual da execução.
As capacidades disponíveis são verificadas conforme a versão e a arquitetura da IDE.
Quando determinada operação não pode ser executada de forma confiável pela API pública do Delphi, o RadIA informa a limitação em vez de simular um suporte que não existe.
Automação de aplicações VCL em execução
Uma das mudanças mais relevantes da versão 2.15 foi a criação de uma infraestrutura para observar e interagir com aplicações VCL durante a execução.
Essa infraestrutura foi pensada para cenários como:
- reproduzir um erro que ocorre ao abrir ou fechar um formulário;
- acompanhar mudanças de estado na interface;
- inspecionar janelas e componentes autorizados;
- executar uma jornada visual limitada;
- capturar evidências antes e depois de uma ação;
- relacionar eventos da interface com o debugger.
O RadIA utiliza uma sessão autenticada e limitada à aplicação autorizada. Janelas e controles são representados por identificadores opacos, evitando que o modelo receba acesso irrestrito a handles, coordenadas globais ou outros processos.
As ações mutáveis continuam sujeitas a consentimento.
Essa fundação aproxima o RadIA de um fluxo no qual o usuário descreve um problema visual, a aplicação é executada, o comportamento é reproduzido e as evidências são usadas para orientar uma correção.
Ainda existem limites impostos pela própria aplicação, pela automação disponível e pelas APIs públicas do Delphi, mas a infraestrutura necessária para esse tipo de investigação agora faz parte do projeto.
Evidências de desempenho comparáveis
O RadIA também ganhou ferramentas para produzir evidências de desempenho mais estruturadas.
Em vez de apresentar apenas uma medição isolada, o fluxo pode comparar execuções e registrar informações suficientes para avaliar se uma alteração realmente trouxe ganho ou regressão.
A intenção é tornar investigações de desempenho mais reproduzíveis e menos dependentes de impressões subjetivas.
Diagnósticos do ecossistema Delphi
Foram adicionadas ferramentas para avaliar o ambiente necessário a diferentes tarefas.
O RadIA pode diagnosticar requisitos relacionados a:
- compilador;
- DelphiLint;
- SonarQube;
- DUnitX;
- FastMM5;
- configuração do projeto;
- plataformas suportadas;
- ferramentas externas;
- ambiente da IDE.
Quando algo está ausente, o objetivo é indicar o requisito, o motivo e a próxima ação possível, em vez de retornar apenas um erro técnico pouco compreensível.
Um pipeline de release mais determinístico
Boa parte do trabalho entre as versões 2.14 e 2.15 aconteceu no processo de validação.
O gate de release passou a executar como um fluxo indivisível:
- suítes DUnitX completas no Delphi 12 e 13;
- cenários registrados de integração;
- testes de ponta a ponta;
- criação da calculadora VCL;
- compilação da calculadora;
- testes funcionais da interface;
- testes DUnitX do projeto gerado;
- geração dos templates suportados;
- abertura e navegação de projetos;
- inicialização e encerramento das IDEs;
- matriz automatizada nos três alvos suportados.
Os alvos atuais são:
- Delphi 12 Win32;
- Delphi 13 Win32;
- Delphi 13 IDE64.
O processo instala explicitamente o build atual antes das jornadas de uso e impede que um pacote antigo presente na máquina seja confundido com a versão em validação.
Falhas transitórias de inicialização possuem tratamento limitado e registrado. Falhas funcionais, de build, testes, navegação ou encerramento continuam bloqueando imediatamente a publicação.
Segurança reforçada na versão 2.15.1
Depois da expansão funcional da versão 2.15.0, a versão 2.15.1 concentrou-se no reforço das fronteiras de segurança.
Validação da origem das mensagens WebView2
As interfaces do chat e da comparação de código recebem mensagens da WebView2.
Agora o host valida se a mensagem foi enviada pelo documento local esperado antes de processá-la. Mensagens originadas por outra página ou navegação inesperada são rejeitadas.
Renderização segura de conteúdo dinâmico
Nomes de provedores e comandos configuráveis passaram a ser inseridos como texto, sem interpretação de HTML.
O Markdown retornado pelos modelos também continua passando por uma política de renderização que impede a execução de conteúdo HTML arbitrário.
Remoção de uma ponte web obsoleta
Uma ponte antiga, destinada à integração com páginas remotas e que já não fazia parte do fluxo atual, foi removida do código e dos pacotes distribuídos.
A remoção reduz a superfície de ataque e elimina um caminho que não era necessário para o funcionamento atual do produto.
PrismJS atualizado
A dependência PrismJS foi atualizada para a versão 1.30.0.
As dependências web distribuídas passaram a possuir uma referência própria, facilitando futuras auditorias e atualizações.
Exportações e configurações externas
A revisão também reforçou:
- remoção de informações sensíveis em exportações;
- sanitização de configurações importadas;
- defaults mais restritivos para servidores MCP externos;
- aplicação centralizada das regras de consentimento;
- execução de login de CLI sem interpretador de shell.
Documentação e backlog revisados
A documentação também passou por uma revisão estrutural e semântica.
Não bastava verificar apenas se os arquivos existiam ou se os links estavam funcionando. O conteúdo precisava representar corretamente o estado atual do produto.
Entre as correções realizadas estão:
- sincronização das versões em português e inglês;
- remoção de referências desnecessárias a versões antigas em guias atuais;
- correção de caminhos documentais obsoletos;
- validação das 185 ferramentas internas registradas;
- revisão do catálogo de funcionalidades;
- atualização do roadmap;
- correção do backlog.
O backlog ainda apresentava a plataforma de testes de integração e ponta a ponta como trabalho pendente, embora essa plataforma já estivesse implementada e integrada ao gate obrigatório de release.
Esse item foi removido do trabalho aberto. Atualmente, o backlog público informa que não existe um goal aprovado em execução.
Os testes documentais também foram corrigidos para validar o estado real do backlog, sem exigir a permanência de textos obsoletos.
As 185 ferramentas internas
O catálogo atual possui 185 ferramentas internas registradas.
A documentação foi organizada em referências complementares:
- uma lista gerada diretamente do runtime;
- uma referência que explica o que cada ferramenta faz;
- orientações sobre quando cada ferramenta deve ser acionada;
- classificação de risco e consentimento;
- catálogo arquitetural para extensões e evolução interna.
Dentro do RadIA, o comando /tools apresenta as ferramentas disponíveis na instalação atual, incluindo ferramentas adicionadas por extensões.
Qualidade da versão
As validações das versões 2.15.0 e 2.15.1 incluíram:
- mais de 1.300 testes internos por versão do Delphi;
- cenários externos e testes de integração;
- templates de Console, DUnitX, FMX, Library, Package, Service e VCL;
- criação e teste funcional da calculadora;
- abertura e navegação imediata de projetos;
- validação do instalador;
- verificação de proveniência dos pacotes;
- análise pelo SonarQube.
O Quality Gate do SonarQube permaneceu aprovado, com cobertura global de 84% e zero bugs, vulnerabilidades, hotspots ou code smells registrados.
Conclusão
A evolução desde a versão 2.14 não se resume ao aumento da quantidade de ferramentas.
O RadIA passou a compreender melhor a estrutura do código Delphi, preparar refatorações multiarquivo, validar código por diferentes mecanismos, selecionar testes por impacto, interagir de maneira controlada com aplicações VCL em execução e produzir evidências mais confiáveis.
Ao mesmo tempo, o projeto reforçou suas fronteiras de segurança, tornou o pipeline de release mais determinístico e corrigiu a documentação para representar o que realmente está disponível.
O objetivo continua sendo oferecer uma experiência completa dentro do Delphi: partir de uma solicitação em linguagem natural, compreender o projeto, preparar alterações revisáveis, compilar, testar, executar, depurar e apresentar evidências claras do resultado.
O RadIA é um projeto de código aberto e pode ser compilado diretamente pelo usuário. Para quem prefere uma instalação simplificada, o instalador visual continua disponível nas releases oficiais do GitHub.
Descubra mais sobre Régys Borges da Silveira
Assine para receber nossas notícias mais recentes por e-mail.
Dê-nos sua opinião, seu comentário ajuda o site a crescer e melhorar a qualidade dos artigos.