DEV Community: kanwar singh

AccessFix AI: Exorcising the Invisible Ghosts Haunting the Web 👻

kanwar singh — Fri, 30 Oct 2026 11:59:13 +0000

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

What I Built

What if your website is haunted, but you can't see the ghosts? 👻

Imagine building a beautiful website. Everything looks polished. The buttons work, the layout feels perfect, and the design looks production-ready.

But something is hiding underneath.

A button has no accessible name. A form field has no associated label. Text blends into its background, making it difficult to read.

For developers, these problems can be nearly invisible. For people who rely on assistive technologies, they can become real barriers.

That's what inspired me to build AccessFix AI — an open-source, local-first AI agent that detects, explains, safely repairs, and verifies web accessibility issues.

For Hacktoberfest's Ghost in the Machine theme, I gave those invisible barriers an identity.

Meet Ghost Mode. 🎃

Instead of simply presenting a list of accessibility errors, AccessFix AI turns them into ghosts haunting your website.

Each ghost represents a genuine issue detected by an accessibility scanner.

The goal isn't just to discover these ghosts. It's to safely exorcise them and prove they're gone.

What AccessFix AI does

Scans a website: Uses Playwright and axe-core to discover accessibility violations.
Explains the problems: Displays affected elements, rule IDs, and relevant issue details.
Generates AI-powered fixes: Runs an open-weight coding model locally through Ollama.
Reviews proposed changes: Shows the original and AI-generated code side by side.
Enforces safety: Validates proposed modifications with a strict AST-based security gate.
Requires human approval: Never applies the generated fix without permission.
Applies and verifies: Uses real browser-based accessibility testing to check whether the fix worked.
Supports rollback and reset: Restores the original demo when needed.

Ghost Mode: Making invisible barriers visible

Ghost Mode introduces five meaningful states:

Ghost status	Meaning
👻 Ghost Detected	A real accessibility violation was discovered
🪄 Awaiting Permission	An AI-generated fix is ready for human review
✅ Ghost Removed	Verification confirms the rule was resolved
🔮 Still Haunting	The accessibility issue remains
⚠️ New Apparition	A new violation appeared after modification

These aren't fictional results added for Halloween.

Every status is derived from actual scanning or verification data.

The ghosts may be a metaphor, but the accessibility problems are real.

Demo

The most exciting part of this project was watching AccessFix AI successfully repair a real accessibility issue.

Rather than showing a hardcoded demonstration, I tested the complete workflow using my local AI model and an actual Chromium browser.

The experiment

My intentionally inaccessible demo initially contained:

button-name — A button without an accessible name.
color-contrast — Text with insufficient contrast.
label — A form field missing an associated label.

The baseline scan discovered 3 violated accessibility rules affecting 4 elements.

I then asked AccessFix AI to generate a repair using the locally running qwen2.5-coder:1.5b model.

The AI-generated fix

The model identified the helper-text color as a candidate for improvement and selected this change:

- color: '#a3a8b5'
+ color: '#000000'

But generating code wasn't enough.

Before applying the change, AccessFix AI checked it against the restricted AST safety policy.

The modification passed validation, I explicitly approved it, and the application applied the proposed fix.

Then Playwright and axe-core scanned the updated website.

The actual results

Metric	Before	After
Violated accessibility rules	3	2
Affected elements	4	3
`color-contrast`	Present	Resolved
`button-name`	Present	Remaining
`label`	Present	Remaining
Newly introduced rules	—	0

One real accessibility rule resolved. Zero new rules introduced.

That's a 33% reduction in violated rule types in this specific demonstration—not a claim that the entire website is now 33% more accessible.

The remaining issues were still reported honestly.

After verification, I reset the application and scanned again. The original 3 rules affecting 4 elements returned, confirming that the reset restored the original demo.

Both demo files also matched their starting contents after the workflow.

Watch the demo

🎥 Demo video: [https://youtu.be/tjIB_Y66GS0]

The approximately 110-second walkthrough covers:

Discovering accessibility ghosts
Generating a fix with local AI
Reviewing the proposed code
Explicitly approving the modification
Applying and verifying the fix
Viewing the updated Ghost Mode results
Resetting the demo

AccessFix AI currently runs as a local prototype, so the video and repository instructions demonstrate its functionality without requiring a public hosted AI service.

Code

🔗 GitHub repository: [https://github.com/kanwar05/AccessFix-AI.git]

The project includes the application source code, installation instructions, architecture documentation, tests, and verification evidence.

It is released under the MIT License, with separate notices for the model and third-party dependencies.

Run it locally

AccessFix AI uses Ollama for local model inference.

First, install Ollama and download the coding model:

ollama pull qwen2.5-coder:1.5b

Then clone the repository and follow the README to install dependencies and launch the application.

The repository also documents the Playwright browser requirements and the development configuration.

The AI model can run locally after its initial download, without sending source code to a proprietary hosted model API.

How I Built It

I wanted AccessFix AI to be more than another application that asks an LLM to generate code.

My main engineering question was:

How can we let AI fix code without blindly trusting everything it generates?

My answer was to separate AI reasoning from permission to modify source code.

Technology stack

Layer	Technology
Frontend	React, JavaScript, CSS
Backend	Node.js
Local AI inference	Ollama
Open-weight model	Qwen2.5-Coder 1.5B
Browser automation	Playwright
Accessibility auditing	axe-core
Code safety	AST-based validation
Testing	Automated backend and Ghost Mode tests

Architecture

        React Frontend
              |
              v
     Accessibility Scan
       Playwright + axe
              |
              v
     Accessibility Report
              |
              v
       Local Ollama AI
      Qwen2.5-Coder 1.5B
              |
              v
       Proposed Code Fix
              |
              v
      Code Comparison UI
              |
              v
      Explicit User Approval
              |
              v
       AST Safety Gate
          /       \
      Reject      Accept
                    |
                    v
              Apply Fix
                    |
                    v
         Playwright + axe
             Verification
                    |
                    v
          Before/After Report
                    |
                    v
           Reset or Rollback

The hardest challenge: Making AI-generated edits safe

Initially, my local model generated valid JSX that looked reasonable, but it also changed visible component content outside the application's approved modification policy.

The AST security gate rejected it with:

UNSUPPORTED_PROPOSED_CHANGE

That was an important moment.

The application had done exactly what its safety architecture was supposed to do: reject an AI-generated modification it could not safely authorize.

Rather than weakening the gate to make the demo pass, I improved the generation workflow so the model could produce more targeted, supported changes.

The successful experiment used the model-selected helper-text color modification while preserving the restricted AST policy.

The application also includes rollback handling, stale-proposal protection, duplicate-request protection, and explicit approval requirements.

The AI proposes.

The safety gate validates.

The developer approves.

The browser verifies.

No single component is blindly trusted.

Testing and validation

My final reported validation results were:

74 backend tests passing
2 Ghost Mode tests passing
76 tests passing in total
ESLint passing
Production build passing
Genuine Ollama generation verified
Real Playwright and axe verification completed
Reset behavior verified
Unsafe proposal rejection and rollback tested

The implementation and verification details are documented in the repository.

Why Does Open Innovation Matter?

For me, open innovation is not simply about publishing code.

It is about building software that developers can inspect, modify, and operate on their own terms.

AccessFix AI is designed around that principle.

1. Your source code stays under your control

Many AI-assisted development tools send source code to externally hosted inference services.

AccessFix AI uses a locally running open-weight model through Ollama.

Developers can perform AI inference on their own machines instead of submitting the relevant code to a third-party AI API.

For a tool that examines and proposes modifications to source code, that control matters.

2. No usage-based cloud AI charges

Once the required model and dependencies are available, local inference doesn't incur per-request charges from a hosted model provider.

There are still hardware, electricity, and maintenance costs, but developers are not forced into a metered AI API to run the core functionality.

3. The model isn't the source of truth

An LLM can produce syntactically valid but unsafe modifications.

AccessFix AI treats the model as a proposal generator—not an authority.

The AST safety gate restricts what can change, and Playwright plus axe-core provide independent evidence about the effect of a permitted modification.

This separation is especially important when working with generated code.

4. Developers can inspect and extend the system

Because the application uses open tooling and an open-weight model, developers can investigate the implementation, examine the safety rules, and adapt the workflow for their own needs.

They're not dependent on a single proprietary inference endpoint.

5. Accessibility should be approachable

Accessibility testing can feel overwhelming, especially when developers receive a long report without knowing what to fix first.

I wanted to combine the reliability of established accessibility tools with the explanatory and code-generation capabilities of local AI.

Open innovation made it possible to bring those pieces together.

Open-weight AI provides the intelligence. Open-source tools provide the evidence. The developer remains in control.

My Agent Session

AI coding assistance was part of my development workflow, alongside iterative implementation, testing, debugging, and manual review.

One of the most interesting engineering challenges was refining the AI proposal workflow without weakening the AST safety gate.

The development process included unsuccessful proposals, policy rejections, additional regression tests, and finally a verified repair.

That progression is an important part of the project: successful AI engineering involves validating the output, not merely accepting it.

The Spirit of It 👻

What started as a Halloween interpretation became a reminder of a real software engineering problem.

A website can appear perfectly functional to one person while containing serious barriers for someone else.

Those barriers are invisible until we know how to look for them.

The moment that made AccessFix AI feel real wasn't when the AI generated a piece of code.

It was when the browser verification confirmed:

Before: 3 violated rules
After:  2 violated rules

Resolved:   color-contrast
Remaining:  button-name, label
Introduced: none

Result: Verified improvement

And after resetting:

Original baseline restored
3 rules / 4 affected elements

The repair was real, measurable, and reversible.

That's the kind of AI-powered developer tooling I want to build: systems that don't simply produce impressive answers, but can demonstrate that their actions made something better.

Of course, automated testing cannot detect every accessibility problem, and one resolved rule doesn't make a website fully accessible. Human testing and broader accessibility review remain essential.

But even a small verified improvement matters.

This Halloween, I didn't build a chatbot to tell ghost stories.

I built an AI tool to discover the ghosts hiding inside our websites—and help developers safely remove them.

Happy Hacktoberfest! 🎃

Hacktoberfest #OpenSource #Accessibility #AI

🦥 RepoPilot AI — Let Local AI Handle the Boring Git Work

kanwar singh — Sun, 25 Oct 2026 14:00:55 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady.

What I Built

As developers, we enjoy building features, solving problems, and writing code.

But after finishing a feature, there are always a few repetitive tasks waiting for us:

Writing meaningful Git commit messages.
Preparing changelogs from commit history.
Updating README documentation whenever functionality changes.

These tasks are important, but they can interrupt our development flow.

So, for the Slow and Steady challenge, I built RepoPilot AI, an offline-first, AI-powered command-line tool that automates these repetitive Git workflows using locally running open-weight AI.

My goal was simple: Spend more time coding and less time documenting what I just coded.

🚀 Three Core Features

1. AI Commit Message Generator

RepoPilot analyzes staged Git changes and suggests meaningful Conventional Commit messages.

repopilot suggest-commit

Instead of manually examining a large diff and deciding how to describe it, developers receive an AI-generated suggestion based on their actual changes.

2. AI Changelog Generator

RepoPilot analyzes Git commit history and prepares categorized release notes.

repopilot generate-changelog --max-commits 10

It organizes relevant changes into categories such as Added, Changed, Fixed, and Removed.

3. AI README Assistant

RepoPilot examines staged changes alongside the existing README and identifies documentation that may need updating.

repopilot suggest-readme

What makes this feature interesting is its evidence validation. Every suggestion must be supported by actual repository content.

RepoPilot never automatically edits the README, commits code, or pushes anything. The developer always stays in control.

📦 Install RepoPilot AI

I also published RepoPilot AI on npm, making it easy for developers to try it in their own Git repositories.

Install the package:

npm install -g repopilot-ai

Install the local model:

ollama pull qwen2.5-coder:7b

With Ollama running, navigate to an existing Git repository and start using RepoPilot.

Available commands:

repopilot suggest-commit
repopilot generate-changelog
repopilot suggest-readme

No paid AI API key is required for the default local setup.

Demo

🎥 Watch RepoPilot AI in action:

[https://youtu.be/Q-jN-w4k9QM]

In the demonstration, I show how to install RepoPilot from npm, configure the local AI model, and run its commands inside a Git repository.

The demo covers generating commit suggestions, identifying missing README documentation, and turning Git history into readable changelogs.

Code

RepoPilot AI is open source and available under the MIT License.

GitHub repository:

[https://github.com/kanwar05/RepoPilot-AI]

Published npm package:

https://www.npmjs.com/package/repopilot-ai

Developers can inspect the implementation, run the tests, suggest improvements, and adapt the tool to their own workflows.

How I Built It

I wanted RepoPilot to be lightweight, easy to install, and genuinely useful without depending on cloud-based AI services.

🛠️ Tech Stack

Technology	Purpose
TypeScript + Node.js	Core CLI application
Commander.js	Command-line interface
Git CLI	Reading diffs and commit history
Ollama	Local LLM inference
Qwen2.5-Coder 7B	AI-powered code understanding
Node.js Test Runner	Automated testing
npm	Package distribution

Architecture

The workflow is straightforward:

Developer Command → Git Data Extraction → Input Validation → Local Ollama Model → Output Validation → Suggested Result

For commit generation, RepoPilot reads staged changes using Git and passes bounded diff content to the local model.

For changelog generation, it processes Git commit history and asks the model to create categorized release notes.

For README suggestions, it combines staged Git changes with the current README to identify missing documentation.

All generated output is validated before being displayed.

The Most Interesting Challenge: Making AI Trustworthy

One of the hardest parts of building RepoPilot wasn't connecting Ollama to Node.js.

It was making sure that AI-generated suggestions were actually supported by repository evidence.

During development, I encountered several problems:

Problem 1: The model invented evidence.

The README Assistant sometimes generated plausible documentation suggestions but cited example text that wasn't present in the actual Git diff.

Instead of accepting unsupported suggestions, I made the validator reject them.

Problem 2: Valid evidence was being rejected.

Git diffs mark added lines with a + prefix. Sometimes the model quoted a real added line without that prefix.

The original validator treated those quotes as invalid.

I improved the evidence verification logic to support harmless formatting differences while still checking that quoted content came from actual added lines.

Problem 3: The model returned empty suggestions.

Sometimes the model returned no documentation suggestions even when a newly added feature clearly needed documentation.

I refined the prompt to better distinguish user-facing changes from irrelevant modifications.

Testing and Validation

I didn't want RepoPilot to be a tool that only worked in a perfect demonstration.

The project passed 26 automated tests, covering areas such as:

Valid and malformed AI output.
Empty staged Git changes.
Large input handling.
Git history processing.
Evidence-backed README suggestions.
Hallucinated evidence rejection.
CLI command handling.

I also tested README suggestion generation using a real local Ollama model and a staged CSV export feature.

That test successfully produced an evidence-backed recommendation to update the README Usage section.

Before release, I verified the npm package contents and ensured the production CLI remained read-only.

Why Does Open Innovation Matter?

Open innovation is at the center of RepoPilot AI, not an optional feature.

🔒 1. Local-first privacy

Developers regularly work with private repositories and proprietary source code.

RepoPilot uses Ollama with a local endpoint by default, allowing source analysis to happen on the developer's own machine.

Repository content doesn't need to be sent to a third-party cloud AI provider in the default configuration.

Users can configure another model endpoint if they choose, so privacy also depends on how they configure the tool.

💰 2. No per-request AI API charges

RepoPilot doesn't require subscriptions or paid cloud AI API keys for its default inference workflow.

After downloading the model, developers can generate suggestions using their own computing resources.

🧩 3. Flexibility and customization

Because the inference layer uses Ollama, developers can experiment with compatible local models rather than depending on a single proprietary service.

They can also inspect and modify the open-source CLI itself.

🌍 4. Offline capability

Once the dependencies and model have been installed, the core Git analysis and local AI workflow can operate without an active internet connection.

This makes RepoPilot useful for developers who prefer local tools or work in environments with limited connectivity.

For me, the biggest advantage of open innovation is control over the entire AI workflow.

My Agent Session

I used AI-assisted development while building RepoPilot, particularly for implementation scaffolding, debugging, and testing.

One important part of the development process was improving the README Assistant after its first attempts produced unsupported evidence and overly conservative empty responses.

The Lazy Payoff 🦥

The entire purpose of RepoPilot is to automate repetitive developer chores.

Before RepoPilot

After writing code, a developer typically needs to:

Inspect staged changes to write a commit message.
Review multiple commits to prepare release notes.
Compare new functionality with existing documentation.
Manually decide which README sections need updates.

With RepoPilot

Developers can run:

repopilot suggest-commit

repopilot generate-changelog

repopilot suggest-readme

And receive AI-generated drafts based on repository evidence.

RepoPilot doesn't replace developer judgment. It reduces the repetitive work of preparing the first draft while keeping every final decision in the developer's hands.

I haven't established a reliable time-savings benchmark yet, but the working demonstrations show how the tool reduces manual drafting and review preparation.

What I Learned

This project taught me that integrating an AI model is only the beginning.

Building a useful AI-powered developer tool also requires proper input handling, trustworthy output validation, clear errors, privacy-conscious defaults, automated testing, and a smooth installation experience.

My biggest takeaway:

AI automation becomes much more useful when the output can be verified rather than blindly trusted.

RepoPilot AI is my contribution to the Slow and Steady theme: a small open-source tool that helps developers spend less time on repetitive Git chores and more time building something meaningful.

Write code. Let RepoPilot handle the boring Git work. 🚀🦥

Thanks for reading!

OpenSource #AI #Hacktoberfest

DukaanDost AI: A Local Gemma Assistant for Stock, Orders, and Udhaar

kanwar singh — Sat, 17 Oct 2026 08:09:11 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle.

What I Built

I built DukaanDost AI, a local business assistant for small Indian distributors supplying biscuits, namkeen, chips, and other packaged goods to shops.

Consider a simple transaction: a shop orders several cartons, pays part of the bill, and promises to pay the rest later. The distributor needs to update stock, record the sale, and carry the unpaid amount into the shop’s udhaar, or outstanding balance.

DukaanDost brings those tasks together:

Inventory tracking with purchases, adjustments, and low-stock alerts.
Multi-product orders with cash, UPI, and credit payments.
Shop ledgers and partial-payment tracking.
Sales reports, estimated gross profit, printable receipts, and CSV export.
An AI assistant for English and Hinglish business requests.

The intended customer is an owner-operated distributor. My proposed business model is paid setup, onboarding, and local support. Willingness to pay still needs validation; this is currently a working single-user MVP.

Demo

Watch the DukaanDost AI demo

The recording uses fictional shops and transactions.

One demonstrated workflow starts with this request:

Sell 2 Parle-G Biscuits cartons and 1 Bikaji Bhujia carton to Ramesh General Store. Received 500 rupees in cash.

With the sample catalog prices, the preview shows:

Order total: ₹1,720
Payment received: ₹500
Added to the shop’s outstanding balance: ₹1,220

The user reviews the preview and confirms it. Only then does the app save the sale, reduce inventory, and update the ledger.

The assistant also supports questions such as:

Aaj ki total sale kitni hui?

Ramesh General Store ka kitna balance pending hai?

Code

View the source code on GitHub

The application code is MIT licensed. The repository includes setup instructions, architecture documentation, automated tests, and recorded local-model evaluation results.

How I Built It

The frontend uses React and TypeScript, the backend uses FastAPI, and business records are stored in SQLite.

For AI, I used Gemma 3, specifically gemma3:1b, running locally through Ollama.

Gemma interprets a business request into a structured intent. The backend then validates that intent, resolves actual products and shops, and calculates prices, payments, and outstanding amounts from the database.

For business questions, answers are formatted from predefined database queries. For orders, the assistant creates a proposal requiring explicit confirmation.

An important implementation challenge was handling ambiguous product names. “Biscuit” could refer to several products, so the app can ask for clarification rather than silently choosing one.

The documented live Gemma evaluation passed 28 of 30 development checks. Two outstanding-balance queries returned clarification. This was a small development test set, and it showed that interpretation still has limitations. The results are documented in the AI evaluation report.

Ordinary inventory, order, and payment forms remain usable when Ollama is unavailable.

Why Does Open Innovation Matter?

Local inference makes a practical difference to this project’s business model. A distributor can use the assistant without a mandatory paid inference API or a per-request proprietary service dependency.

Gemma runs on the same computer as the application, while SQLite gives the operator a database they can back up themselves. The model is configurable, so the project can adapt as local hardware and available models improve.

After installing dependencies and downloading the model, the application is designed to operate using local services. Setup still requires internet, and inference performance depends on the machine.

Open-weight AI made this architecture possible. The next step is to test whether distributors find it useful enough to pay for setup and support.

Prize Categories

Best Use of Gemma

DukaanDost uses Gemma locally through Ollama to interpret English and Hinglish business questions and propose shop orders for human review.

AI disclosure: AI assistance was used during development and in preparing this write-up.

🌿 NatureLens: Turning Screen Time into Green Time

kanwar singh — Sun, 11 Oct 2026 06:14:27 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass.

What I Built

NatureLens is a nature companion designed to help people step away from their screens and reconnect with the world around them. 🌱

In a world where we spend hours scrolling, I wanted to build something that uses technology to encourage people to spend more time outdoors—not less.

NatureLens turns going outside into a simple, engaging experience through nature-focused activities and exploration.

The idea is simple: instead of spending more time consuming content on a screen, use the screen as a starting point for discovering something in the real world.

NatureLens is designed for students, nature lovers, and anyone who wants to build a healthier relationship with technology.

My goal is to make exploring nature feel accessible, interactive, and fun.

Demo

🌐 Live Demo: [https://naturelens-coral.vercel.app/]

Try the experience and see how technology can encourage real-world exploration!

Code

💻 GitHub Repository: https://github.com/kanwar05/Naturelens

The project is built with an emphasis on a modern web experience and making nature exploration accessible.

Contributions, suggestions, and feedback are welcome!

How I Built It

I built NatureLens using React and Vite, with a focus on creating a responsive, interactive web application.

The project explores how open-source AI can bring intelligence closer to the user, with browser-based inference as an approach to reduce dependence on remote AI services.

My intended direction is to use Hugging Face Transformers.js for running supported AI models directly in the browser, alongside a nature-exploration experience that remains useful when AI is unavailable.

One important engineering challenge was deployment: the AI dependency tree included a Node ONNX Runtime package whose installation attempted to download additional runtime files. This caused problems during cloud deployment. I worked on adjusting the dependency configuration so the browser-focused build could be deployed more cleanly.

This challenge reminded me that building an AI-powered application is not just about integrating a model. It also means understanding dependencies, runtime environments, deployment constraints, and graceful fallbacks.

Why Does Open Innovation Matter?

Open innovation makes it possible for developers to experiment, learn, and build on top of tools created by a global community.

Open-source AI frameworks give developers the opportunity to explore local and browser-based inference instead of automatically sending every task to a closed, paid API.

For a project like NatureLens, that direction matters because it can help reduce API costs, offer more control over the user experience, and create opportunities for privacy-conscious, offline-friendly features.

Open source also makes learning more practical. When something breaks, developers can investigate the dependency chain, understand the underlying problem, and share what they learn with others.

I believe technology should help us experience more of the real world—not keep us trapped inside a screen. That is the idea behind NatureLens.

My Agent Session

I used an AI coding agent during development to help explore the implementation, troubleshoot dependency issues, and refine the application.

Thanks for checking out NatureLens! 🌍

I’d love to hear your feedback: What feature would make you more likely to put your phone away and explore nature?