👻 WRAITH

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine

What I Built

Every developer knows the feeling.

Your website works perfectly during development. Every button responds, every form submits, and every page loads.

Then someone clicks something you never expected.

And suddenly, something breaks.

Traditional automated tests follow predefined instructions. But what about unexpected user journeys, unusual interface states, or bugs hiding between interactions?

That's the problem WRAITH aims to solve.

WRAITH is an AI-assisted website testing platform designed to investigate applications like a digital paranormal investigator.

Instead of relying exclusively on manually scripted tests, its proposed AI agent will plan browser interactions, explore authorized websites, observe unexpected behavior, and generate evidence-backed defect reports.

The Ghost-Hunting Toolkit

🦇 Command Center — Enter the Haunted Domain

A centralized dashboard for initiating investigations, reviewing activity, and monitoring testing progress.

🕯️ Investigations — Follow the Digital Footprints

An investigation history designed to organize testing sessions, target websites, and discovered issues.

⚰️ Bug Graveyard — Where Broken Code Goes to Rest

A centralized defect registry featuring severity-based filtering, issue tracking, and editable resolution status.

👻 Ghost Replay — Revisit the Scene

A planned mechanism for reproducing failures through recorded browser actions and supporting evidence.

📜 Reports — The Evidence Never Lies

Structured investigation summaries and downloadable findings.

🔥 Exorcism Mode — Make Sure the Ghost Is Gone

A planned regression-testing capability that will rerun relevant checks after developers implement fixes.

Why the Halloween Theme?

The challenge is called Ghost in the Machine, and I wanted to interpret that theme through something developers encounter every day.

Software bugs are digital ghosts.

They appear unexpectedly, disappear when someone tries to reproduce them, and return when everyone thinks the problem has been solved.

WRAITH turns that frustrating experience into a ghost-hunting workflow.

The Halloween-inspired black-and-orange interface isn't just decoration. It gives each testing capability a memorable identity while preserving the structure of a practical developer tool.

Code

How I Built It

I started with a question:

What would automated website testing look like if the testing tool could decide what to investigate next?

That question became the foundation of WRAITH.

Phase 1: Designing the Investigation Experience

I first mapped the complete testing workflow:

Target Website → Testing Objective → AI Planning → Browser Exploration → Anomaly Detection → Evidence Collection → Report → Replay

Instead of building a conventional testing dashboard, I designed an interface around the idea of a paranormal investigation.

Every screen represents a stage of discovering, documenting, and resolving software defects.

The result is Black Ember, a functional frontend prototype that demonstrates the intended user experience.

Phase 2: Planning the Open-Source AI Architecture

WRAITH's proposed architecture combines several open-source technologies.

🧠 Qwen + Ollama — The Reasoning Engine

The planned AI component uses open-weight Qwen models through Ollama for local inference.

The agent will interpret testing objectives, propose browser actions, and evaluate observations.

🎭 Playwright — The Browser Investigator

Playwright will execute browser interactions such as navigation, clicking buttons, completing forms, and inspecting application behavior.

It will also support evidence collection through screenshots and browser traces.

🔗 LangGraph — The Agent Workflow

LangGraph is planned to coordinate the investigation loop:

Plan → Act → Observe → Evaluate → Continue or Report

This structure is intended to let the agent adjust its next action based on what happens inside the browser.

⚡ FastAPI — The Backend

A Python/FastAPI backend will connect the frontend to browser automation, AI inference, and investigation management.

Phase 3: Building Toward Autonomous Testing

The next milestone is turning the simulated investigation workflow into real browser execution.

The planned implementation will prioritize authorized testing targets, controlled execution, reproducible evidence, and validation of AI-generated findings.

Why Does Open Innovation Matter?

For WRAITH, open innovation is more than a development preference.

It's fundamental to the kind of tool I want to build.

1. Developers Should Control Their Testing Tools

A website testing agent may encounter sensitive application workflows, internal interfaces, and development environments.

Local AI inference can help reduce the need to transmit application information to external AI services.

Using open-weight models through Ollama is intended to make that possible.

1. Intelligence Should Be Customizable

Different applications require different testing strategies.

An e-commerce application, student portal, and enterprise dashboard have completely different user journeys.

An open-source architecture allows developers to customize agent prompts, testing objectives, evaluation rules, and browser workflows.

1. Testing Should Be Reproducible

A useful bug report needs more than an AI-generated explanation.

Developers need evidence.

WRAITH's planned architecture emphasizes browser traces, screenshots, logs, and reproducible action sequences.

Open tooling makes those mechanisms inspectable and extensible.

1. Innovation Should Be Accessible

Not every developer or student can afford recurring commercial AI API costs.

By designing WRAITH around open-weight models and locally executable tooling, I want to make experimentation more accessible.

The goal isn't simply to build an AI that finds bugs. It's to build an AI testing workflow that developers can understand, inspect, modify, and improve together.

Prize Categories

Hacktoberfest Open-Source AI Challenge — Week 4: Ghost in the Machine

Partner-specific prize categories and eligibility will be finalized based on the implemented integrations and challenge requirements.