DEV Community: Rodrigo Furlaneti

PointsTableAndExams — From a Coupled CRUD to a Clean Architecture & CQRS Evaluation System

Rodrigo Furlaneti — Thu, 04 Jun 2026 13:34:11 +0000

tags: devchallenge, githubchallenge, dotnet, react, architecture

GitHub “Finish-Up-A-Thon” Challenge Submission

PointsTableAndExams — From an Unfinished Prototype to a Robust, Multi-Tenant Evaluation Management System

This is a submission for the GitHub Finish-Up-A-Thon Challenge.

What I Built

PointsTableAndExams is a comprehensive evaluation management system designed to process complex exam scoring, apply dynamic weighting, and distribute points across scalable tables. What started as a quick, tightly-coupled prototype has been completely re-engineered into a production-ready application built on a modern stack: a .NET 9 Web API backend and a React + TypeScript + Vite frontend, styled with Tailwind CSS.

The philosophy behind this revival was simple: software design matters. I didn't just want to finish the UI; I wanted to build it using enterprise-grade standards.

What makes this iteration stand out:

Clean Architecture & DDD: The core business rules (scoring logic, weight distribution) are 100% isolated in the Domain layer, completely agnostic of databases or web frameworks.
CQRS Pattern: I implemented Command Query Responsibility Segregation to separate read and write operations. This drastically optimized performance for complex queries generating the points tables.
Behavior-Driven Development (BDD): Quality assurance is built-in. I wrote BDD specifications to guarantee the scoring algorithms behave exactly as expected under various edge cases.
O(1) Complexity Focus: Refactored critical evaluation loops that previously suffered from performance bottlenecks into highly efficient data structures.
Modern Frontend: Replaced the old UI with a blazing-fast React application, utilizing Vite for bundling and Tailwind CSS for a fully responsive, modern design.
Cloud-Ready: The system is containerized and optimized for deployment on Azure, ensuring scalability and cost-efficiency.

GitHub repository: https://github.com/rodrigofurlaneti/PointsTableAndExams

Demo

Clean Architecture Implementation (CQRS Handler):


csharp
// The application layer is now clean, handling commands with isolated logic
public class CalculateExamScoreCommandHandler : IRequestHandler<CalculateExamScoreCommand, ScoreResult>
{
    private readonly IExamRepository _examRepository;
    private readonly IScoreCalculatorService _scoreCalculator;

    public CalculateExamScoreCommandHandler(IExamRepository examRepository, IScoreCalculatorService scoreCalculator)
    {
        _examRepository = examRepository;
        _scoreCalculator = scoreCalculator;
    }

    public async Task<ScoreResult> Handle(CalculateExamScoreCommand request, CancellationToken cancellationToken)
    {
        var exam = await _examRepository.GetByIdAsync(request.ExamId, cancellationToken);
        // Domain logic execution, isolated from infrastructure
        var finalScore = _scoreCalculator.Calculate(exam, request.StudentAnswers);

        return finalScore;
    }
}


Feature: Exam Scoring Calculation
  As a system administrator
  I want the system to calculate points accurately based on question weights
  So that student evaluations are fair and transparent

  Scenario: Correct calculation with mixed weights
    Given an exam exists with 2 questions
    And Question 1 has a weight of 2.0
    And Question 2 has a weight of 1.5
    When the student answers Question 1 correctly and Question 2 incorrectly
    Then the final calculated score should be 2.0

(Author's note: Insert a screenshot of your React/Tailwind frontend dashboard here)

The Comeback Story
This project started from a frustrating reality: building a quick prototype often leads to technical debt that paralyzes future development.

The first version was a monolithic application. It got the job done for a single use case, but the UI logic, Entity Framework queries, and business rules were tangled together in massive controller methods. It sat unfinished for a long time because adding new features meant risking breaking the fragile scoring calculations. The Finish-Up-A-Thon was the exact push I needed to tear it down and rebuild it correctly.

Before — what the project looked like when I picked it back up:

A monolithic structure with massive controllers.

Hardcoded business rules mixed directly with SQL data access code.

No automated tests (making refactoring terrifying).

Basic, unresponsive UI built with outdated frontend practices.

Poor performance on large datasets due to nested loops and N+1 query issues.

What I finished to get to this final release:

Total Architectural Overhaul: Migrated the entire backend to .NET 9, implementing Clean Architecture. The domain is now pure.

CQRS Implementation: Segregated commands and queries, making the API endpoints clean, testable, and scalable.

Algorithm Optimization: Eliminated N+1 queries in Entity Framework and refactored the scoring loop to achieve O(1) time complexity where possible, drastically improving the calculation speed for large tables.

BDD & Unit Testing: I rigorously documented and fixed the BDD scenarios, ensuring that all specifications for the AccessAuthentication and scoring modules were correctly written and tested.

Frontend Rewrite: Threw away the old views and built a fresh, decoupled SPA using React, TypeScript, and Vite. The UI is now fully responsive thanks to Tailwind CSS.

The transformation from a "fragile script" to a scalable, beautifully architected software solution took late nights and deep focus. The Finish-Up-A-Thon was the deadline I needed to actually ship it.

My Experience with GitHub Copilot
GitHub Copilot was deeply involved in every phase of this rewrite—not as a tool that just wrote code for me, but as a brilliant pair programmer that accelerated my architectural decisions.

Transitioning a legacy codebase to Clean Architecture requires a lot of structural setup. Here is where Copilot changed the game:

Accelerating Boilerplate: When setting up MediatR for the CQRS pattern, Copilot perfectly anticipated the structure. I would define the Command record, and it instantly generated the corresponding CommandHandler, complete with the correct constructor injections for my repositories.

Refactoring to O(1) Complexity: I had an old, nested loop used for cross-referencing student answers with the answer key. I wrote a comment: // Refactor to use a Dictionary for O(1) lookups. Copilot immediately provided the optimized implementation, cutting down lines of code and improving performance.

Drafting BDD Tests: Writing Gherkin syntax and mapping it to step definitions can be tedious. Copilot understood the context of my PointsTable entities and suggested highly relevant edge cases for the scoring logic that I hadn't initially considered. It helped me ensure the BDD documentation was flawlessly written.

React & Tailwind Velocity: On the frontend, building the data tables to display the points was incredibly fast. I typed a comment describing a responsive grid for the exam results, and Copilot generated the full React component with all the necessary Tailwind utility classes for dark mode and mobile responsiveness.

What Copilot didn’t do: it didn’t design the domain boundaries or decide how to segregate the micro-services. Those architectural decisions were mine. But it removed the friction between "knowing what pattern to use" and "typing out the implementation."

Without Copilot, this level of structural refactoring would have taken weeks of tedious typing. With it, I shipped a tested, documented, and architecturally sound framework. That's the difference.

Code Property Graph: Visualizing Clean Architecture as an Interactive Knowledge Graph

Rodrigo Furlaneti — Tue, 26 May 2026 12:10:16 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built
Code Property Graph is a full-stack system designed to map any software project into a relational graph model. It allows you to visualize and navigate through your code's architecture—such as layers, projects, namespaces, and elements (classes, interfaces, records)—in a fully interactive way.

The project's biggest innovation is combining the Relational Paradigm (SQL Server + EF Core) with a Graph Vision (Knowledge Graph). There is no need to migrate to a native graph database; the backend models nodes and edges using classic tables and foreign keys, while the frontend translates all of this into a real-time mind map.

Beyond visually documenting the architecture, it features a Clean Architecture violation detection engine, immediately alerting you if a dependency rule is broken (for example, a Domain element depending on Infrastructure). All of this was built using the latest ecosystem versions: .NET 9.0 on the backend (using CQRS, MediatR, and Rich Entities) and React 18 + TypeScript + React Flow on the frontend.

Demo
The complete source code is available on my GitHub:

Code Property Graph Repository

Here is a glimpse of the interface mapping a system's dependencies:

The Comeback Story
The original idea for the Code Property Graph was born from a real pain point I've faced over years of dealing with complex systems. Designing solutions using Domain-Driven Design (DDD), patterns like CQRS, and Clean Architecture requires strict team discipline. I always felt the lack of a visual and pragmatic tool to validate these dependencies in real time, without the bureaucracy of parsing hundreds of .csproj files.

The project was sitting "in the drawer" as a conceptual proof of concept. For this Finish-Up-A-Thon, I finally decided to dust it off and finish the solution, elevating the technical level of the stack. The main changes to revive and complete the project included:

Backend Update: I refactored the core to use .NET 9.0, ensuring the entities were extremely rich (Rich Entities without Data Annotations) and implementing the Result Pattern to avoid exceptions in flow control.

React Flow Adoption: The old frontend didn't properly support rendering directional nodes. Integrating React Flow (@xyflow/react) with strict TypeScript typing completely changed the usability, allowing real-time filters and dependency highlighting (IMPLEMENTS and DEPENDS_ON).

Violation Engine: I completed the most important feature: the complex SQL queries via EF Core (AsSplitQuery) that automatically detect components bypassing Clean Architecture rules.

My Experience with GitHub Copilot
GitHub Copilot acted as a true senior pair programmer throughout the entire journey of finishing the project, accelerating the development cycle on essential fronts.

On the backend (.NET), it was brilliant at inferring the structure of my Fluent API in Entity Framework Core. When I needed to map composite keys for edges (like ElementImplementation and ElementDependency), Copilot auto-completed the relationship configurations and IEntityTypeConfiguration, respecting the AsNoTracking rule I had established. It also accelerated the creation of MediatR Handlers and validations via FluentValidation.

On the frontend, the biggest challenge was state management and the complex rendering of nodes. Copilot saved me hours of reading documentation by helping type custom React Flow nodes and writing Zustand selectors to manage filter options (layers, directories, and selected elements). Having this AI by my side eliminated repetitive boilerplate work and allowed me to focus entirely on the architecture and engineering of the data model.

Code Property Graph: Visualizando a Clean Architecture como um Knowledge Graph Interativo

Rodrigo Furlaneti — Tue, 26 May 2026 12:07:43 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built
O Code Property Graph é um sistema full-stack desenhado para mapear qualquer projeto de software em um modelo de grafo relacional. Ele permite que você visualize e navegue pela arquitetura do seu código — como camadas, projetos, namespaces e elementos (classes, interfaces, records) — de forma totalmente interativa.

A maior inovação do projeto é combinar o Paradigma Relacional (SQL Server + EF Core) com uma Visão de Grafo (Knowledge Graph). Não há necessidade de migrar para um banco de dados de grafos nativo; o backend modela nós e arestas usando tabelas e chaves estrangeiras clássicas, enquanto o frontend traduz tudo isso em um mapa mental em tempo real.

Além de documentar a arquitetura visualmente, ele possui uma engine de detecção de violações da Clean Architecture, alertando imediatamente caso uma regra de dependência seja quebrada (por exemplo, um elemento do Domain dependendo da Infrastructure). Tudo isso foi construído com as versões mais recentes do ecossistema: .NET 9.0 no backend (utilizando CQRS, MediatR e Rich Entities) e React 18 + TypeScript + React Flow no frontend.

Demo
O código-fonte completo está disponível no meu GitHub:
Repositório do Code Property Graph

Aqui está um vislumbre da interface mapeando as dependências de um sistema:

The Comeback Story
A ideia original do Code Property Graph nasceu de uma dor real que enfrentei ao longo de anos lidando com sistemas complexos. Projetar soluções utilizando Domain-Driven Design (DDD), padrões como CQRS e Clean Architecture exige disciplina rígida da equipe. Sempre senti falta de uma ferramenta visual e pragmática para validar essas dependências em tempo real, sem a burocracia de analisar centenas de arquivos .csproj.

O projeto estava "na gaveta" como uma prova de conceito conceitual. Para este Finish-Up-A-Thon, decidi finalmente tirar a poeira e finalizar a solução, elevando o nível técnico da stack. As principais mudanças para reviver e concluir o projeto incluíram:

Atualização do Backend: Refatorei o core para utilizar o .NET 9.0, garantindo que as entidades fossem extremamente ricas (Rich Entities sem Data Annotations) e implementando o Result Pattern para evitar exceções no controle de fluxo.

Adoção do React Flow: O frontend antigo não suportava bem a renderização de nós direcionais. Integrar o React Flow (@xyflow/react) com tipagem estrita em TypeScript mudou completamente a usabilidade, permitindo filtros em tempo real e destaque de dependências (IMPLEMENTS e DEPENDS_ON).

Engine de Violações: Concluí a feature mais importante: as queries SQL complexas via EF Core (AsSplitQuery) que detectam automaticamente componentes que furam o bloqueio da Clean Architecture.

My Experience with GitHub Copilot
O GitHub Copilot funcionou como um verdadeiro pair programmer sênior durante toda a jornada de finalização do projeto, acelerando o ciclo de desenvolvimento em frentes essenciais.

No backend (.NET), ele foi brilhante ao inferir a estrutura da minha Fluent API no Entity Framework Core. Quando eu precisava mapear as chaves compostas para as arestas (como ElementImplementation e ElementDependency), o Copilot autocompletava a configuração de relacionamentos e IEntityTypeConfiguration respeitando a regra de AsNoTracking que eu havia estabelecido. Ele também acelerou a criação dos Handlers do MediatR e as validações via FluentValidation.

No frontend, o maior desafio era o gerenciamento de estado e a renderização complexa de nós. O Copilot me poupou horas de documentação ajudando a tipar os nós customizados do React Flow e a escrever os seletores do Zustand para gerenciar as opções de filtros (camadas, diretórios e elementos selecionados). Ter essa IA do lado eliminou o trabalho repetitivo de boilerplate e me permitiu focar totalmente na arquitetura e na engenharia do modelo de dados.

Resolvendo a Alucinação da IA na Arquitetura de Software com Code Property Graphs e .NET 9

Rodrigo Furlaneti — Sat, 23 May 2026 10:31:50 +0000

A ascensão das ferramentas de Inteligência Artificial Generativa transformou radicalmente a produtividade na engenharia de software. Hoje, assistentes de código conseguem gerar classes inteiras, refatorar algoritmos complexos e propor padrões de projeto em segundos.

No entanto, como Engenheiro de Software trabalhando em ambientes corporativos de alta complexidade, esbarrei repetidamente no maior gargalo dessas ferramentas: a alucinação contextual e a quebra de fronteiras arquiteturais.

Quem nunca viu uma IA sugerir a criação de um arquivo no diretório errado? Ou pior, fazer a camada de Domain depender diretamente de um componente de Infrastructure, violando frontalmente os princípios da Clean Architecture?

Para resolver esse problema de forma determinística, decidi criar o Code Property Graph (CPG): um ecossistema que mapeia toda a estrutura estática do código (camadas, namespaces, classes e dependências) e atua como uma "guarda de fronteira" contra as alucinações da IA.

🏗️ O Conceito: Mapeando Código como Conhecimento
O projeto, que disponibilizei de forma open-source no meu GitHub (CodePropertyGraph), foi desenhado em três grandes módulos, abraçando uma abordagem que chamo de Paradigma Híbrido (Relacional + Grafo).

O Motor Híbrido: SQL com Alma de Grafo (1-Sql) Mapear dependências em bancos puramente relacionais costuma gerar tabelas associativas complexas. Por outro lado, forçar uma equipe a adotar um banco de grafos nativo (como Neo4j) apenas para essa análise pode gerar fricção operacional.

Minha solução foi criar um banco relacional otimizado para travessias. Uma tabela central CodeElement (o nó do grafo) armazena Classes, Interfaces e Records. Tabelas associativas como ElementDependency atuam como as arestas.

Com isso, antes de a IA gerar um código, o sistema pode rodar uma validação determinística:

SQL

-- Identificando violação clássica: Domain dependendo de Infrastructure
SELECT 
    SourceElem.Name AS ArquivoIncorreto,
    TargetElem.Name AS DependenciaProibida
FROM ElementDependency Dep
INNER JOIN CodeElement SourceElem ON Dep.SourceElementId = SourceElem.Id
INNER JOIN Layer SourceLayer ON SourceElem.LayerId = SourceLayer.Id
INNER JOIN CodeElement TargetElem ON Dep.TargetElementId = TargetElem.Id
INNER JOIN Layer TargetLayer ON TargetElem.LayerId = TargetLayer.Id
WHERE SourceLayer.Name = 'Domain' AND TargetLayer.Name = 'Infrastructure';

Se a query retornar dados, a IA é bloqueada de prosseguir com a sugestão. Simples e infalível.

O Cérebro: Backend em .NET 9.0 (2-BackEnd) Para orquestrar essa lógica, criei uma API robusta em .NET 9.0. Seguindo estritamente os princípios SOLID, implementei o padrão CQRS utilizando o MediatR.

Commands: Lidam com a ingestão pesada de metadados de código extraídos via analisadores estáticos (como o Roslyn).

Queries: Executam as validações arquiteturais em tempo real.

Tudo é abstraído pelo Repository Pattern, garantindo que as regras de negócio de validação arquitetural fiquem isoladas de como os dados estão persistidos.

A Visão: Interactive Knowledge Graph com React (3-FrontEnd) Dados puros não fornecem intuição arquitetural. O módulo front-end, construído em React, consome a API do .NET 9 e renderiza a arquitetura inteira como um Knowledge Graph interativo (semelhante a um mapa mental complexo).

O desenvolvedor pode clicar em um módulo específico e ver imediatamente a árvore de dependências. Mais importante: ele pode "desenhar" uma intenção de nova feature, e o front-end validará em tempo real se essa nova estrutura fere o design do sistema, antes mesmo de uma única linha de código ser escrita.

🚀 Conclusão
A IA Generativa é um co-piloto extraordinário, mas nós ainda somos os arquitetos. Ao criar um Code Property Graph, damos à IA os "olhos" necessários para entender os limites de domínio e infraestrutura de nossas aplicações. Projetos estruturados com .NET 9, bancos de dados otimizados e interfaces interativas em React são a ponte para um desenvolvimento assistido por IA verdadeiramente seguro.

Sinta-se à vontade para explorar o código, enviar PRs ou discutir ideias no repositório do projeto!

English Version 🇬🇧 / 🇺🇸
This is a submission for the Google I/O Writing Challenge

Solving AI Hallucination in Software Architecture with Code Property Graphs and .NET 9
The rise of Generative AI tools has radically transformed software engineering productivity. Today, coding assistants can generate entire classes, refactor complex algorithms, and propose design patterns in seconds.

However, as a Software Engineer working in highly complex enterprise environments, I repeatedly hit the biggest bottleneck of these tools: contextual hallucination and the breaking of architectural boundaries.

Who hasn't seen an AI suggest creating a file in completely the wrong directory? Or worse, make the Domain layer directly depend on an Infrastructure component, blatantly violating the principles of Clean Architecture?

To solve this problem deterministically, I decided to build the Code Property Graph (CPG): an ecosystem that maps the entire static structure of the code (layers, namespaces, classes, and dependencies) and acts as a "border guard" against AI hallucinations.

🏗️ The Concept: Mapping Code as Knowledge
The project, which I open-sourced on my GitHub (CodePropertyGraph), was designed in three major modules, embracing an approach I call the Hybrid Paradigm (Relational + Graph).

The Hybrid Engine: SQL with a Graph Soul (1-Sql) Mapping dependencies in purely relational databases usually generates complex associative tables. On the other hand, forcing a team to adopt a native graph database (like Neo4j) just for this analysis can cause operational friction.

My solution was to create a relational database optimized for traversals. A central CodeElement table (the graph node) stores Classes, Interfaces, and Records. Associative tables like ElementDependency act as the edges.

With this setup, before the AI generates code, the system can run a deterministic validation:

SQL

-- Identifying a classic violation: Domain depending on Infrastructure
SELECT 
    SourceElem.Name AS IncorrectFile,
    TargetElem.Name AS ForbiddenDependency
FROM ElementDependency Dep
INNER JOIN CodeElement SourceElem ON Dep.SourceElementId = SourceElem.Id
INNER JOIN Layer SourceLayer ON SourceElem.LayerId = SourceLayer.Id
INNER JOIN CodeElement TargetElem ON Dep.TargetElementId = TargetElem.Id
INNER JOIN Layer TargetLayer ON TargetElem.LayerId = TargetLayer.Id
WHERE SourceLayer.Name = 'Domain' AND TargetLayer.Name = 'Infrastructure';

If the query returns any data, the AI is blocked from proceeding with the suggestion. Simple and bulletproof.

The Brain: .NET 9.0 Backend (2-BackEnd) To orchestrate this logic, I built a robust API in .NET 9.0. Strictly following SOLID principles, I implemented the CQRS pattern using MediatR.

Commands: Handle the heavy ingestion of code metadata extracted via static analyzers (like Roslyn).

Queries: Execute real-time architectural validations.

Everything is abstracted by the Repository Pattern, ensuring that the architectural validation business rules remain isolated from how the data is persisted.

The Vision: Interactive Knowledge Graph with React (3-FrontEnd) Raw data doesn't provide architectural intuition. The front-end module, built in React, consumes the .NET 9 API and renders the entire architecture as an interactive Knowledge Graph (similar to a complex mind map).

Developers can click on a specific module and immediately see its dependency tree. More importantly, they can "draw" the intent for a new feature, and the front-end will validate in real-time if this new structure violates the system's design—before a single line of code is written.

🚀 Conclusion
Generative AI is an extraordinary co-pilot, but we are still the architects. By creating a Code Property Graph, we give AI the "eyes" it needs to understand the domain and infrastructure boundaries of our applications. Projects structured with .NET 9, optimized databases, and interactive React interfaces are the bridge to truly safe AI-assisted development.

Feel free to explore the code, submit PRs, or discuss ideas over at the project repository!

Solving AI Hallucination in Software Architecture with Code Property Graphs and .NET 9

Rodrigo Furlaneti — Sat, 23 May 2026 10:30:13 +0000

The rise of Generative AI tools has radically transformed software engineering productivity. Today, coding assistants can generate entire classes, refactor complex algorithms, and propose design patterns in seconds.

The Concept: Mapping Code as Knowledge
The project, which I open-sourced on my GitHub (CodePropertyGraph), was designed in three major modules, embracing an approach I call the Hybrid Paradigm (Relational + Graph).

The Hybrid Engine: SQL with a Graph Soul (1-Sql) Mapping dependencies in purely relational databases usually generates complex associative tables. On the other hand, forcing a team to adopt a native graph database (like Neo4j) just for this analysis can cause operational friction.

With this setup, before the AI generates code, the system can run a deterministic validation:

SQL
-- Identifying a classic violation: Domain depending on Infrastructure SELECT SourceElem.Name AS IncorrectFile, TargetElem.Name AS ForbiddenDependency FROM ElementDependency Dep INNER JOIN CodeElement SourceElem ON Dep.SourceElementId = SourceElem.Id INNER JOIN Layer SourceLayer ON SourceElem.LayerId = SourceLayer.Id INNER JOIN CodeElement TargetElem ON Dep.TargetElementId = TargetElem.Id INNER JOIN Layer TargetLayer ON TargetElem.LayerId = TargetLayer.Id WHERE SourceLayer.Name = 'Domain' AND TargetLayer.Name = 'Infrastructure';

If the query returns any data, the AI is blocked from proceeding with the suggestion. Simple and bulletproof.

The Brain: .NET 9.0 Backend (2-BackEnd) To orchestrate this logic, I built a robust API in .NET 9.0. Strictly following SOLID principles, I implemented the CQRS pattern using MediatR.

Commands: Handle the heavy ingestion of code metadata extracted via static analyzers (like Roslyn).

Queries: Execute real-time architectural validations.

Everything is abstracted by the Repository Pattern, ensuring that the architectural validation business rules remain isolated from how the data is persisted.

The Vision: Interactive Knowledge Graph with React (3-FrontEnd) Raw data doesn't provide architectural intuition. The front-end module, built in React, consumes the .NET 9 API and renders the entire architecture as an interactive Knowledge Graph (similar to a complex mind map).

Conclusion
Generative AI is an extraordinary co-pilot, but we are still the architects. By creating a Code Property Graph, we give AI the "eyes" it needs to understand the domain and infrastructure boundaries of our applications. Projects structured with .NET 9, optimized databases, and interactive React interfaces are the bridge to truly safe AI-assisted development.

Feel free to explore the code, submit PRs, or discuss ideas over at the project repository!

GhostScan v3.0 — From Scattered Scripts to an Elite Open-Source Pentest Framework

Rodrigo Furlaneti — Fri, 22 May 2026 11:43:38 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

GhostScan v3.0 is an elite, modular penetration testing framework for Kali Linux that brings together 53 security tools under a single, intelligent CLI — with correlation-aware scoring, WAF bypass profiles, adaptive workflows, and professional report generation.

The philosophy behind GhostScan is simple but powerful: signal over noise. Most security scanners dump 300+ raw findings and leave the tester to figure out what matters. GhostScan gives you 10 findings you can act on today, each ranked by a scoring formula that accounts for real-world impact, exploitability confidence, and business context:

score = (impact × 0.6) + (confidence × 0.4)

What makes it different from a typical scanner wrapper:

Correlation engine — automatically detects compound risks. A login panel + SQL injection isn't two MEDIUM findings. It's one CRITICAL: SQLi on Auth Endpoint = Auth Bypass + Full DB Dump, scored at 9.8.
Context multipliers — payment paths, exposed databases, and authenticated endpoints automatically elevate severity based on business impact.
WAF bypass profiles — auto-detects CloudFlare, Akamai, AWS WAF, F5, Imperva, ModSecurity, Wordfence, and Sucuri, then applies the right sqlmap tamper chain and timing delays.
Plugin system — drop a .py file into plugins/ and it loads automatically on the next scan. Plugins run sandboxed with timeout kill-switches so a broken plugin never stops the chain.
Adaptive workflow engine — after each scan, GhostScan generates exact next commands based on what was actually found, not a static checklist.
Scan profiles — stealth (passive only, 2s rate, no probing), standard (balanced), and aggressive (all modules, 50 threads, large wordlists, full injection suite).
Report generation — PDF, HTML, Markdown, and JSON out of the box.
CI/CD from day one — GitHub Actions runs syntax checks and unit tests across Python 3.10, 3.11, and 3.12 on every push.

⚠️ For authorized security testing only. Always obtain written permission before testing any system.

GitHub repository: https://github.com/rodrigofurlaneti/scanghost

Demo

Example scan output (correlation engine):

✓ Login panel at /wp-login.php (HTTP 200)
✓ SQL injection in ?search= (boolean-based)
✓ Content-Security-Policy missing
= 🔴 CRITICAL [9.8] SQLi on Auth Endpoint = Auth Bypass + DB Dump
  Attack: admin'-- → bypass auth → dump wp_users → crack hashes

✓ Redis on port 6379 (open to internet)
✓ No authentication (default config)
= 🔴 CRITICAL [9.6] Database Exposed Externally
  Attack: redis-cli → CONFIG SET → cron RCE

Full scan, PDF report:

ghostscan -t your-authorized-target.com --all --report pdf

Stealth recon only:

ghostscan -t target.com --mode stealth --recon

WAF bypass + browser DOM XSS:

ghostscan -t target.com --web --waf-bypass --browser --screenshots

The Comeback Story

This project started from a frustrating reality: penetration testing workflows are fragmented. You run nmap, then manually feed results into nikto, then into sqlmap, then into gobuster — each tool in its own terminal window, each output in its own format, and you're left manually correlating 300 raw findings to figure out what actually matters.

I started GhostScan as a personal tool to fix that for myself. The first version was a single Python script that called tools sequentially and printed output to the terminal. It worked, but barely — one missing tool would crash the whole run, there was no scoring, no scope enforcement, and the "report" was a text dump.

It sat unfinished for months. The core idea was solid, but it needed a lot more work before I'd share it with anyone. The Finish-Up-A-Thon was the push I needed.

Before — what the project looked like when I picked it back up:

A single Python script that called tools sequentially
No scoring or severity weighting — everything was "found" or "not found"
No scope enforcement — it could happily scan out-of-scope hosts
No WAF awareness — most active scans got blocked immediately
Reports were raw terminal output dumped to a text file
No plugin system, no extensibility
No CI, no tests

What I finished to get to v3:

Hard scope enforcement — ScopeEnforcer blocks out-of-scope requests and SSRF-prone IPs (169.254.x.x, 10.x.x.x by default) before any tool even runs. This was the most important safety addition.
Safe parallel executor — SafeExecutor runs tools concurrently with per-tool timeouts, retry logic, and failure isolation. One broken tool (e.g. a segfaulting nuclei template) never stops the scan.
Intelligence & correlation engine — IntelligenceEngine cross-references all findings from all modules to detect compound attack paths. This was the hardest module to finish. The raw data comes in from recon, web, and vuln modules in different shapes; the engine normalises it, deduplicates it, applies context multipliers, ranks attack surface targets, and surfaces correlations.
WAF bypass engine — WafBypass maps detected WAF vendors to specific sqlmap tamper scripts, encoding techniques, and rate delays. Previously the framework just got blocked and returned zero findings against WAF-protected targets.
Adaptive workflow engine — WorkflowEngine generates contextual next steps. If SQLi was found, it tells you exactly which sqlmap flags to run. If Redis is open, it gives you the specific redis-cli commands. Not generic advice — exact commands.
Headless browser module — HeadlessBrowser (Playwright) scans for DOM XSS, hidden endpoints, and client-side secrets. Catches things that static HTTP requests miss entirely.
Plugin system — completely new. plugins/base.py defines the GhostScanPlugin base class with sandboxed loading, per-plugin timeouts, confidence thresholds, and finding caps. Three built-in plugins ship with the framework: admin_finder.py, xss_custom.py, and sensitive_files.py.
Report generation — ReportingModule now produces proper PDF reports (via ReportLab), dark-theme HTML, structured JSON, and Markdown — all from the same normalised finding schema.
Web frontend + API — the framework was wrapped in an API layer and a web interface to make it accessible beyond the command line. The deployment config (staticwebapp.config.json) includes hardened security headers out of the box — it would be embarrassing for a security tool to ship without CSP, HSTS, and X-Frame-Options.
CI/CD — GitHub Actions runs syntax checks and integration tests across Python 3.10/3.11/3.12 on every push. The test suite validates scope enforcement (SSRF protection), WAF bypass profiles, and the intelligence correlation engine.

The transformation from "one guy's unfinished script" to a tested, documented, CI-backed open-source framework took months of evenings and weekends. The Finish-Up-A-Thon was the deadline I needed to actually ship it.

My Experience with GitHub Copilot

GitHub Copilot was deeply involved in every phase of this project — not as a code generator I blindly accepted, but as a fast, context-aware collaborator that dramatically reduced the time between "I know what this should do" and "this actually works."

Where Copilot helped the most:

Building the intelligence engine. The correlation logic is the most complex part of GhostScan. Given a Redis port open on the internet, a login panel, a missing CSP header, and a JS secret — how do you automatically detect which combinations create compound CRITICAL risks? I described the desired behaviour in a comment and Copilot drafted the scoring matrix and multiplier logic. It wasn't perfect on the first attempt, but it gave me a structure I could reason about and refine, instead of staring at a blank file.

The WAF bypass profiles. Mapping 8 different WAF vendors to their known sqlmap tamper chains, encoding specifics, and appropriate timing delays is tedious research work. Copilot accelerated this significantly — I'd write the CloudFlare profile, and Copilot would suggest accurate completions for Akamai, F5, and Imperva based on the pattern it saw. I still validated every tamper chain against actual test environments, but the scaffolding was generated in minutes.

Writing the plugin sandbox. Building a plugin loader that isolates crashes, enforces timeouts, caps findings, and suppresses low-confidence results requires a lot of boilerplate threading and error-handling code. Copilot handled most of that correctly on the first pass, which meant I could focus on the plugin API design rather than concurrent.futures plumbing.

The reporting module. Generating PDF reports with ReportLab is notoriously verbose. Copilot wrote most of the table formatting, colour mapping, and page layout code from a short description and the finding schema. I estimated that would have taken me two full evenings to write from scratch; with Copilot it took a few hours.

Test cases. The CI integration tests — scope enforcement, WAF bypass validation, intelligence engine assertions — were mostly Copilot-generated from the function signatures and docstrings. It understood what the functions were supposed to do and wrote meaningful assertions.

What Copilot didn't replace: architectural decisions, security correctness, and tool integration logic. Every suggestion got reviewed, and anything touching security behaviour (scope enforcement, SSRF protection, WAF detection) was written and tested manually.

The honest summary: without Copilot, GhostScan v3 would still be unfinished. With it, I shipped a tested, documented, CI-backed framework. That's the difference.

GhostScan v3.0 — From Closed-Source EXE to Open-Source Pentest Framework

Rodrigo Furlaneti — Fri, 22 May 2026 11:40:50 +0000

GhostScan v3.0 — From Scattered Scripts to an Elite Open-Source Pentest Framework

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

score = (impact × 0.6) + (confidence × 0.4)

What makes it different from a typical scanner wrapper:

Correlation engine — automatically detects compound risks. A login panel + SQL injection isn't two MEDIUM findings. It's one CRITICAL: SQLi on Auth Endpoint = Auth Bypass + Full DB Dump, scored at 9.8.
Context multipliers — payment paths, exposed databases, and authenticated endpoints automatically elevate severity based on business impact.
WAF bypass profiles — auto-detects CloudFlare, Akamai, AWS WAF, F5, Imperva, ModSecurity, Wordfence, and Sucuri, then applies the right sqlmap tamper chain and timing delays.
Plugin system — drop a .py file into plugins/ and it loads automatically on the next scan. Plugins run sandboxed with timeout kill-switches so a broken plugin never stops the chain.
Adaptive workflow engine — after each scan, GhostScan generates exact next commands based on what was actually found, not a static checklist.
Scan profiles — stealth (passive only, 2s rate, no probing), standard (balanced), and aggressive (all modules, 50 threads, large wordlists, full injection suite).
Report generation — PDF, HTML, Markdown, and JSON out of the box.
CI/CD from day one — GitHub Actions runs syntax checks and unit tests across Python 3.10, 3.11, and 3.12 on every push.

⚠️ For authorized security testing only. Always obtain written permission before testing any system.

GitHub repository: https://github.com/rodrigofurlaneti/scanghost

Demo

Example scan output (correlation engine):

✓ Login panel at /wp-login.php (HTTP 200)
✓ SQL injection in ?search= (boolean-based)
✓ Content-Security-Policy missing
= 🔴 CRITICAL [9.8] SQLi on Auth Endpoint = Auth Bypass + DB Dump
  Attack: admin'-- → bypass auth → dump wp_users → crack hashes

✓ Redis on port 6379 (open to internet)
✓ No authentication (default config)
= 🔴 CRITICAL [9.6] Database Exposed Externally
  Attack: redis-cli → CONFIG SET → cron RCE

Full scan, PDF report:

ghostscan -t your-authorized-target.com --all --report pdf

Stealth recon only:

ghostscan -t target.com --mode stealth --recon

WAF bypass + browser DOM XSS:

ghostscan -t target.com --web --waf-bypass --browser --screenshots

The Comeback Story

It sat unfinished for months. The core idea was solid, but it needed a lot more work before I'd share it with anyone. The Finish-Up-A-Thon was the push I needed.

Before — what the project looked like when I picked it back up:

A single Python script that called tools sequentially
No scoring or severity weighting — everything was "found" or "not found"
No scope enforcement — it could happily scan out-of-scope hosts
No WAF awareness — most active scans got blocked immediately
Reports were raw terminal output dumped to a text file
No plugin system, no extensibility
No CI, no tests

What I finished to get to v3:

Hard scope enforcement — ScopeEnforcer blocks out-of-scope requests and SSRF-prone IPs (169.254.x.x, 10.x.x.x by default) before any tool even runs. This was the most important safety addition.
Safe parallel executor — SafeExecutor runs tools concurrently with per-tool timeouts, retry logic, and failure isolation. One broken tool (e.g. a segfaulting nuclei template) never stops the scan.
Intelligence & correlation engine — IntelligenceEngine cross-references all findings from all modules to detect compound attack paths. This was the hardest module to finish. The raw data comes in from recon, web, and vuln modules in different shapes; the engine normalises it, deduplicates it, applies context multipliers, ranks attack surface targets, and surfaces correlations.
WAF bypass engine — WafBypass maps detected WAF vendors to specific sqlmap tamper scripts, encoding techniques, and rate delays. Previously the framework just got blocked and returned zero findings against WAF-protected targets.
Adaptive workflow engine — WorkflowEngine generates contextual next steps. If SQLi was found, it tells you exactly which sqlmap flags to run. If Redis is open, it gives you the specific redis-cli commands. Not generic advice — exact commands.
Headless browser module — HeadlessBrowser (Playwright) scans for DOM XSS, hidden endpoints, and client-side secrets. Catches things that static HTTP requests miss entirely.
Plugin system — completely new. plugins/base.py defines the GhostScanPlugin base class with sandboxed loading, per-plugin timeouts, confidence thresholds, and finding caps. Three built-in plugins ship with the framework: admin_finder.py, xss_custom.py, and sensitive_files.py.
Report generation — ReportingModule now produces proper PDF reports (via ReportLab), dark-theme HTML, structured JSON, and Markdown — all from the same normalised finding schema.
Web frontend + API — the framework was wrapped in an API layer and a web interface to make it accessible beyond the command line. The deployment config (staticwebapp.config.json) includes hardened security headers out of the box — it would be embarrassing for a security tool to ship without CSP, HSTS, and X-Frame-Options.
CI/CD — GitHub Actions runs syntax checks and integration tests across Python 3.10/3.11/3.12 on every push. The test suite validates scope enforcement (SSRF protection), WAF bypass profiles, and the intelligence correlation engine.

My Experience with GitHub Copilot

Where Copilot helped the most:

The honest summary: without Copilot, GhostScan v3 would still be unfinished. With it, I shipped a tested, documented, CI-backed framework. That's the difference.