DEV Community: Aiman Fazal

The Midnight Game — The Game That Remembers

Aiman Fazal — Tue, 27 Oct 2026 06:03:26 +0000

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

What I Built

The Midnight Game — The Game That Remembers

I built a local, AI-powered folk-horror game inspired by the midnight games, playground rituals, campfire stories, and supernatural games that get passed from one person to another.

The premise is simple:

Play the game at midnight. Follow the rules. Don't break the ritual.

But there's a catch.

The game remembers.

Every player leaves behind traces of their session: the choices they made, the rules they followed, the things they discovered, and sometimes the things they weren't supposed to discover.

Future players can encounter fragments of those previous sessions.

A warning left by someone who played before them.

A rule that wasn't part of the original game.

A strange event that has happened several times.

Eventually, the game begins developing its own folklore.

The goal wasn't to build another chatbot that tells scary stories. I wanted to build a game where the AI actually feels like part of the world — something living inside the machine that remembers what happened before.

Demo

[Demo / Video coming soon]

The experience starts in a terminal-like interface:

╔════════════════════════════════════╗
║          THE MIDNIGHT GAME         ║
╚════════════════════════════════════╝

This game is best played alone.

The previous player lasted 17 minutes.

They left one message:

> DON'T ANSWER THE THIRD KNOCK.

The clock is approaching midnight.

From there, the player performs a series of actions and makes choices that influence what happens next.

The game engine controls the actual rules and state, while the local AI acts as the narrator and the voice of the entity.

Code

[GitHub Repository coming soon]

The project is designed around a simple separation:

              ┌─────────────────┐
              │     Player      │
              └────────┬────────┘
                       │
                       ▼
              ┌─────────────────┐
              │   Game Engine   │
              │                 │
              │ Rules           │
              │ Game State      │
              │ Events          │
              │ Randomness      │
              └────────┬────────┘
                       │
                       ▼
              ┌─────────────────┐
              │   Local LLM     │
              │                 │
              │ Narration       │
              │ Dialogue        │
              │ Atmosphere      │
              └────────┬────────┘
                       │
                       ▼
              ┌─────────────────┐
              │ Local Memory    │
              │                 │
              │ Past Sessions   │
              │ Player Choices  │
              │ Folklore        │
              └─────────────────┘

The model doesn't control the game rules. It interprets the game state and brings the world to life.

That means the AI can't simply hallucinate that a door is open when the game engine says it's closed.

At least, not without something going very, very wrong.

How I Built It

The core of the project is an open-weight model running locally.

The game engine is responsible for deterministic mechanics: the ritual, player choices, game state, events, and endings.

The local model is responsible for the parts that benefit from generative AI:

the voice of the entity
narration
contextual dialogue
interpreting previous player actions
generating atmospheric descriptions
reacting to discoveries
helping turn repeated player behavior into folklore

The game also maintains a local memory of previous sessions.

For example:

SESSION #019

Player lasted: 23m 41s

Actions:
• knocked 3 times
• opened the door
• refused to answer
• looked behind the chair

Final event:
THE GHOST SPOKE THE PLAYER'S NAME

Player's final message:

"Never open the door."

A future player might discover that message without knowing who left it.

Over time, repeated player behavior can become part of the game's evolving folklore:

LOCAL FOLKLORE

01. Never knock four times.
02. Never answer your own name.
03. Never extinguish the candle yourself.
04. If you hear breathing, don't turn around.

The idea is that the game doesn't just generate folklore.

It gradually accumulates it.

Why Does Open Innovation Matter?

The Midnight Game is designed to be played without the internet.

That's not just a technical choice. It's part of the experience.

A horror game about a mysterious presence becomes much more interesting when you can disconnect the machine from the internet and the presence is still there.

Running an open-weight model locally also means that the game's memories, conversations, and play history can remain on the player's machine.

No account.

No API key.

No cloud dependency.

No requirement to send someone's gameplay or personal information to a third-party AI provider.

Open models also make the project hackable.

Players can swap the model, change the personality of the entity, add new rules, create regional variations, or build entirely different versions of the game.

The same game engine could become:

a different folk-horror tradition
a campfire game
an urban legend
a supernatural puzzle
a completely new piece of fictional folklore

That's what open innovation made possible here: the AI isn't a service the game depends on. It's a component the player can own, inspect, modify, and replace.

My Agent Session

[DevRelay agent session coming soon]

The Spirit of It

There is something interesting about traditional folk games.

They don't need an app.

They don't need a server.

They don't even need an internet connection.

Someone just tells you the rules.

Then you play.

And if you play it with someone else, you might learn a slightly different version.

Maybe someone adds a new rule.

Maybe someone tells you that you're not supposed to say a certain word.

Maybe someone claims that something happened the last time they played.

And eventually, nobody remembers where the original rules came from.

The Midnight Game is an attempt to recreate that process with an AI.

The model isn't just telling a horror story.

It's participating in the creation of one.

Every player can leave something behind.

Every future player can discover it.

And eventually, the machine starts remembering things that its current player never taught it.

That's the ghost.

Prize Categories

Thanks for participating!

Sloth Organzier

Aiman Fazal — Fri, 23 Oct 2026 06:36:02 +0000

🦥 Sloth Organizer: Let AI Tidy Your Files While You Do Absolutely Nothing

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

What if organizing your files didn’t mean spending an afternoon dragging documents between folders, renaming cryptic filenames, and trying to remember where everything belongs?

You could do it yourself. Or, like a sloth, you could conserve your energy and let AI do the heavy lifting. 🦥

Meet Sloth Organizer — a local-first AI application that scans messy folders, proposes an organization plan, and safely moves or renames files after you review and approve the changes.

No cloud AI APIs. No uploading private documents. No letting an AI loose on your filesystem without supervision.

Just you, your files, and a local AI model doing the tedious work.

What I Built

Sloth Organizer turns folder chaos into an organized workspace, with AI doing the planning and you staying in control.

We all have that one folder: Downloads, Desktop, Documents, or perhaps an entire drive where files accumulate because organizing them feels like a chore.

Sloth Organizer helps tackle that problem.

Here's how it works:

Scan: Point the application at a folder. It scans files, calculates hashes, detects file types, and groups potential duplicates.
Organize: A locally running AI model analyzes the available file information and proposes sensible destinations and optional new filenames.
Prioritize: Review the generated tasks, grouped by priority so you can focus on what matters.
Review: Approve or reject each proposed file change individually.
Apply: Confirm the final summary and let Sloth Organizer execute the approved moves and renames.

The application also supports content previews for formats such as TXT, PDF, DOCX, and XLSX, helping the AI make more informed organization suggestions.

The important distinction? The AI proposes; you decide.

Files are never deleted, and the application includes safeguards against path traversal, unexpected overwrites, and invalid AI-generated responses.

The goal is simple: spend less time managing files and more time doing something you actually enjoy.

Demo

🖥️ Source repository: https://github.com/aimanfazal/sloth-organizer

Sloth Organizer runs locally in your browser, with the application served from your own machine.

To try it, install the prerequisites, set up LM Studio with a compatible chat model, build the frontend, and launch the application. The interface is available at http://localhost:8000.

I haven't included a separate hosted demo or video because the project is designed to run locally. A screen recording showing a messy folder, the generated organization plan, the review screen, and the final result would be a great way to demonstrate the complete workflow.

Code

🐙 GitHub repository: https://github.com/aimanfazal/sloth-organizer

The project is open source under the MIT license.

The main components include:

Backend: Python, FastAPI, SQLModel, and SQLite.
Frontend: React and Vite.
AI integration: LM Studio using its OpenAI-compatible local API.
File processing: Recursive scanning, SHA-256 hashing, MIME-type detection, and supported document-content extraction.
Execution safety: Validated AI output, restricted file paths, collision handling, and explicit user approval before changes are applied.

The codebase separates scanning, AI planning, review, and filesystem execution into distinct components, making the workflow easier to understand and maintain.

Check out the repository for installation instructions, configuration options, and implementation details.

How I Built It

I built Sloth Organizer around a simple principle: AI should take care of repetitive decisions without taking away the user's control.

The application combines a Python backend with a React frontend. FastAPI exposes the APIs used by the interface, while SQLite stores application data. WebSockets help communicate scan progress to the frontend.

For the AI layer, Sloth Organizer connects to a model running locally through LM Studio. The model receives file information and relevant content previews, then generates a structured organization plan containing proposed destinations and optional renames.

The backend validates and normalizes the model's response before it can become an executable task. This matters because AI-generated output should never be trusted blindly when it can change someone's filesystem.

The workflow deliberately separates planning from execution:

Scanning gathers information about the folder.
AI generates proposed changes.
The user reviews and approves individual tasks.
The execution layer checks the approved operations and applies them safely.

That final separation is important. A useful file organizer should not just be intelligent; it should also be predictable and cautious.

The Tech Stack

Component	Technology
Backend API	Python + FastAPI
Frontend	React + Vite
Database	SQLite + SQLModel
AI inference	LM Studio + locally running open-weight model
File analysis	SHA-256, MIME detection, document extraction
Communication	REST APIs + WebSockets

The application requires Python 3.11+, Node.js 18+, and LM Studio with a compatible chat model loaded and its local server running.

Why Does Open Innovation Matter?

For this project, open innovation isn't just about using a different AI model. It's about changing where AI runs, who controls the data, and how much freedom developers have to adapt the system.

1. Your files stay yours

Folders often contain sensitive information: personal documents, financial records, work files, and private notes.

By running inference locally through LM Studio, Sloth Organizer does not need to upload file contents to a hosted AI API. The application can perform its core AI workflow without a cloud inference provider, an AI account, or per-request cloud API charges.

Local inference does require suitable hardware and a compatible model, so the actual cost and speed depend on your setup.

2. You choose the model

The application uses LM Studio's OpenAI-compatible API rather than tying the workflow to a single proprietary cloud provider.

You can configure which locally loaded model is used and experiment with different compatible models as your needs change. This provides room to explore trade-offs between speed, quality, hardware requirements, and resource consumption.

3. You can inspect and adapt the software

The MIT-licensed codebase can be examined, modified, and extended. Developers can improve the organization prompts, add document extractors, adjust the safety checks, or build new features around the existing workflow.

4. No unnecessary dependence on a hosted AI service

Once the compatible model is available locally and the application is configured, its AI workflow can run without an external inference API.

That means fewer external dependencies, more predictable control over your data, and the possibility of avoiding recurring inference fees.

For me, that's the real promise of open innovation: making useful AI something people can run, understand, and adapt on their own terms.

My Agent Session

The code and its organization workflow are available in the GitHub repository.

I haven't included a DevRelay agent-session link in this submission. If you capture a session while developing the project, this section is a good place to embed it so readers can follow the implementation process and see how the application took shape.

The Lazy Payoff 🦥

Here's the kind of work Sloth Organizer is designed to eliminate:

Opening files one at a time to figure out what they are.
Repeatedly creating folders and moving documents by hand.
Renaming files to make their purpose easier to recognize.
Reorganizing a cluttered Downloads folder every few weeks.
Repeating the same tedious cleanup process whenever files pile up again.

Instead of manually handling every file, you can scan a folder, review the suggested plan, and approve the changes that make sense.

The payoff isn't just fewer clicks. It's lowering the mental friction that makes file organization so easy to postpone.

I don't have a measured time-savings figure to report yet, so I won't invent one. The actual benefit will depend on the number of files, the model's inference speed, and how much manual cleanup the folder would otherwise require.

But the idea is to turn a task people avoid into a workflow that requires much less effort and still leaves the final decisions in their hands.

Slow and steady wins the tidy folder.

Prize Categories

This project is intended for the main Hacktoberfest Open-Source AI Challenge: Week 3 — Slow and Steady.

I'm not claiming a partner category at this stage because the repository's use of LM Studio alone doesn't establish eligibility for any listed partner prize category. If the project uses a qualifying partner's technology and meets that category's requirements, the corresponding entry can be added here.

Final Thoughts

AI is often presented as something that needs to be bigger, faster, and more autonomous.

Sloth Organizer explores a quieter approach: let AI handle the repetitive planning, keep the processing local, and make the human approval step part of the design.

Not every AI agent needs to take over your day. Sometimes the most useful one is the one that quietly tidies up after you.

Build slowly. Organize smartly. Stay lazy. 🦥

Built for Hacktoberfest 2026 — Open-Source AI Challenge, Week 3: Slow and Steady.

Photo Proof 📸

Aiman Fazal — Tue, 13 Oct 2026 10:36:01 +0000

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

PhotoProof 📸 — Find the Photo You Remember, Not the Filename You Forgot

What I Built

Ever tried to find a photo buried somewhere in thousands of images? You might remember what was in it, but not its filename, folder, or the date you took it.

PhotoProof solves this with AI-powered semantic photo search.

Instead of manually browsing folders or tagging every picture, you can describe what you're looking for in plain English, such as:

"A dog running on the beach at sunset"
"A mountain landscape covered in snow"
"Photos similar to this one"

PhotoProof uses OpenCLIP to understand the visual content of images and text, turning photos into numerical embeddings that can be searched by meaning rather than filename alone.

What it can do

Natural-language search: Find photos by describing their content.
Search by image: Upload an image to find visually relevant photos in your library.
Similar-photo discovery: Find images that look similar to an existing indexed photo.
Incremental indexing: Skip unchanged photos instead of processing everything again.
Search filters and CSV export: Refine results and export them for further use.
Local AI inference: Generate image and text embeddings on your own machine, without paying a hosted model API for every query.

Who would pay for it?

PhotoProof could be useful for photographers, content creators, designers, researchers, and small businesses managing large image collections. It could eventually become a paid desktop tool or a specialized photo-management product.

The problem is simple: as photo libraries grow, finding the right image becomes increasingly difficult. PhotoProof makes those collections searchable by what the images actually contain.

Demo

GitHub repository: https://github.com/aimanfazal/photo-proof

Local demo: Run the application locally to explore the interface and search your own photo library.

git clone https://github.com/aimanfazal/photo-proof.git
cd photo-proof
make install

Configure your PostgreSQL connection in .env using .env.example as a guide, then start the application:

make run

The Streamlit interface opens at http://localhost:8501.

Video demo: https://youtu.be/pGL2lLp37FY

The project currently documents a local application workflow. A publicly deployed demo or recorded video can be added here when available.

Code

Explore the complete project on GitHub:

aimanfazal/photo-proof

The repository includes the AI embedding pipeline, image indexing, semantic search, vector storage, Streamlit interface, and automated tests.

Key implementation files:

photoproof/model.py — Loads OpenCLIP and generates embeddings.
photoproof/indexer.py — Scans image folders, computes embeddings, and indexes photos.
photoproof/search.py — Implements text-based and similar-image search.
photoproof/storage.py — Handles PostgreSQL and pgvector interactions.
photoproof/app.py — Provides the Streamlit interface.

How I Built It

PhotoProof is built around OpenCLIP, an open-source implementation of contrastive image–text learning, rather than a proprietary vision API.

The core stack includes:

Python for application logic.
OpenCLIP (ViT-B-32) for image and text embeddings.
PyTorch for model inference.
PostgreSQL + pgvector for storing and searching vector embeddings.
Streamlit for the browser-based interface.
Pillow and NumPy for image processing and numerical operations.

How the AI search works

Index the library: PhotoProof scans a folder of images and identifies supported files.
Understand each image: OpenCLIP converts each image into a 512-dimensional, L2-normalized embedding.
Store the representation: The embeddings and associated metadata are persisted in PostgreSQL using pgvector.
Understand the query: A natural-language description is encoded into the same vector space. An uploaded or indexed image can also serve as a visual query.
Retrieve relevant results: Vector similarity ranks the photos, and Streamlit displays them in a gallery.

The important idea is that the system compares semantic representations rather than relying only on filenames or manually assigned tags.

PhotoProof also supports incremental indexing, automatic cleanup of missing file paths during queries, similarity filtering, and CSV export.

Why Does Open Innovation Matter?

I wanted to build a useful AI application without making a proprietary API the foundation of the entire experience.

Open-source AI makes that possible.

With OpenCLIP and PyTorch, developers can inspect the implementation, experiment with models, run inference locally, and adapt the system to their own workflows. There is no need to send every search query to a closed vision API or pay a per-request model fee.

Open innovation also makes the architecture more flexible. Developers can explore alternative embedding models, experiment with retrieval quality, improve indexing performance, and build integrations around an understandable system.

Privacy is another important consideration. PhotoProof generates embeddings on the user's machine, and original photos remain in their local folders. Only embeddings and metadata are sent to the configured database.

This architecture offers a practical balance between AI capabilities, user control, and cost. The database can still be a managed service, but image inference does not depend on a hosted model API.

For me, open innovation means being able to build with AI while retaining the freedom to understand, modify, and improve the technology.

My Agent Session

[Add your saved DevRelay session link here, if available.]

If you used an AI coding agent to build the project, include a shareable session that demonstrates how it contributed to implementation, debugging, testing, or design decisions.

Prize Categories

Tiger Data — PhotoProof uses Tiger Data's PostgreSQL infrastructure with pgvector to persist image embeddings and power semantic vector search.

Closing Thoughts

PhotoProof explores a practical use of open-source AI: making personal and professional photo libraries searchable by meaning.

No manual tagging marathon. No need to remember cryptic filenames. Just describe the moment you're looking for.

The project is an experiment in making powerful AI retrieval more accessible, local, and adaptable. I'd love to see how the community builds on this idea, improves search quality, and finds new applications for semantic image search.

Find the moment, not the filename. 🔎

Hacktoberfest #OpenSourceAI #Python #OpenCLIP #ComputerVision #MachineLearning

Deen Trace

Aiman Fazal — Tue, 06 Oct 2026 18:37:49 +0000

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

What I Built

Deen Trace — an AI that knows when to get out of your way.

Deen Trace is a concept/prototype for a private, offline-first Muslim activity journal built around one simple principle:

Log → Reflect → Leave the screen.

The idea is to let people record everyday activities such as Salah, Qur'an, Dhikr, Sadaqah, Good Deeds, and Fasting, then review their history through a simple visual activity graph.

But the feature I designed specifically for Touch Grass is called Step Outside.

Instead of using AI to keep someone talking to an app, Deen Trace uses a local open-weight model to look at activity patterns and generate a small, non-judgmental suggestion for something the user can do away from the screen.

For example:

Step Outside

Put your phone down.

Take a short walk.

Notice something you normally overlook.

And then the app gets out of the way.

There are no outdoor streaks, XP, leaderboards, badges, or engagement loops.

The app doesn't even need to know whether the user followed the suggestion.

The goal is for the screen to be the shortest part of the experience.

Demo

This submission is currently a prototype/concept implementation plan rather than a deployed application.

The intended demo flow is:

Record daily activity.
View the activity graph.
Turn Wi-Fi/mobile data off.
Generate a reflection using the local AI model.
Receive a personalized "Step Outside" suggestion.
Put the phone down and actually go outside.

The most important moment of the demo would be generating the reflection while completely offline.

Code

The project is designed as an open-source application with the following architecture:

deentrace/
├── presentation/
├── domain/
├── data/
├── ai/
└── core/

The local database is the source of truth for the device.

The application is designed so that activity tracking does not depend on network access, while cloud services are limited to authentication and synchronization.

How I Built It

The proposed implementation uses:

Flutter for the cross-platform application
SQLite for local-first activity storage
llama.cpp for local model inference
Qwen3, an open-weight model, for local reflections
A small application/domain layer separating business logic from the UI

The AI pipeline is intentionally narrow:

Activity Data
      +
Optional Good Deed Notes
      │
      ▼
Context Builder
      │
      ▼
Local Open-Weight Model
      │
      ▼
Reflection Validator
      │
      ▼
Monthly Reflection
      │
      ▼
Step Outside

The model only receives the information required to generate the requested reflection.

Personal activity is not sent to a remote AI API.

The AI would have three modes:

Off
Reports only
Reports + personalized suggestions

The suggestion system is deliberately pattern-based and non-judgmental.

The AI is not a religious authority. It must not provide Islamic rulings, judge someone's faith, assign spiritual value, invent activity, or make unsupported claims about the user.

The underlying product architecture is also designed around offline-first behavior. Creating activities, editing them, viewing history, and viewing the activity graph should all work without an internet connection.

Why Does Open Innovation Matter?

This project deals with unusually personal information.

A person's worship activity and private Good Deed notes are not the kind of data I want to send to a remote AI provider simply because a cloud API is convenient.

Local open-weight inference changes that.

The intended architecture is:

                 DEVICE
┌─────────────────────────────────┐
│                                 │
│  Local Activity Database        │
│            │                    │
│            ▼                    │
│     Context Builder             │
│            │                    │
│            ▼                    │
│     Open-Weight Model           │
│            │                    │
│            ▼                    │
│  Reflection / Suggestion        │
│                                 │
└─────────────────────────────────┘

The user's personal activity can remain on the device.

Privacy

The AI doesn't require personal activity to be uploaded to a hosted AI service.

Offline capability

Once the model is installed, the reflection experience can work without an internet connection.

That is particularly relevant to the Touch Grass theme: the application should still be useful when someone is away from reliable connectivity.

Model freedom

The AI layer is intentionally replaceable.

The application should not be architecturally tied to a single proprietary API. Different open-weight models can be tested, optimized, or replaced without redesigning the entire product.

But the most important reason for using open AI is philosophical.

I don't want an AI assistant that tries to maximize the amount of time I spend talking to it.

I want an AI that can look at my activity, help me reflect, and then tell me:

Put the phone down.

That's what makes local open AI meaningful for this project.

My Agent Session

This prototype does not currently have a DevRelay agent session.

The intended development workflow would use an agent to help build and test the local-first architecture, while keeping the application's personal activity data separate from any remote AI service.

Prize Categories

Open-Source AI / Open-Weight AI

The project is designed specifically around an open-weight local model and local inference rather than a closed hosted AI API.

The idea behind Deen Trace

Deen Trace is built around a simple principle:

Real life comes before the app.

The activity graph isn't a spiritual score.

The AI isn't a religious authority.

The app doesn't need to know whether you actually followed its suggestion.

It just needs to help you reflect—and then get out of your way.

Log → Reflect → Leave the screen.

Dead Stock Dost

Aiman Fazal — Sun, 04 Oct 2026 15:18:05 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

I built Dead Stock Dost, a tiny local-first AI tool for a small neighborhood garment shop.

A small shop can have shirts, kurtas, jackets, and other products sitting on shelves for weeks or months. Even with an inventory CSV, it isn't always easy to quickly answer:

Which products need attention?
Why might they be stuck?
What could I try?

Dead Stock Dost takes a simple inventory CSV and turns it into:

CSV → Identify Dead Stock → Explain → Suggest an Action

The application deterministically identifies products that have been sitting unsold for too long, then lets the shopkeeper ask a local AI assistant for an explanation and possible actions.

The AI doesn't make the decision for them.

The code calculates the facts. The AI explains the facts. The shopkeeper decides.

Demo

🎥 Video Demo: https://youtu.be/U6-7b7IAlMg

The complete demo takes less than two minutes:

Open the app
   ↓
Try demo data / Upload CSV
   ↓
See products needing attention
   ↓
Select a product
   ↓
"Why is this stuck?"
   ↓
"What can I try?"
   ↓
Get a local AI response

Code

🔗 GitHub Repository: https://github.com/aimanfazal/dead-stock-dost

The repository contains the application, demo CSV, screenshots, architecture documentation, and project scope.

How I Built It

Dead Stock Dost is built with:

Next.js
React
TypeScript
CSV
LM Studio
Qwen 2.5 3B Instruct

The AI runs locally through LM Studio using an open-weight model.

The application itself handles the inventory logic deterministically:

90+ days: Dead Stock
45–89 days: At Risk
Less than 45 days: Normal
Stock ≤ 0: Ignored

The AI receives the calculated facts for a selected product and helps explain the situation or suggest possible actions.

It does not classify products, modify inventory, change prices, invent facts, or make decisions automatically.

I intentionally kept the architecture small: no database, authentication, cloud AI API, vector database, or multi-agent framework.

The CSV remains the source of truth.

Why Does Open Innovation Matter?

Open innovation made it possible to build this as a local-first AI tool instead of depending on a paid cloud AI API.

Using an open-weight model through local inference means the shopkeeper's inventory data can stay on their own machine while still getting a natural-language AI assistant.

It also makes the project easier to experiment with and adapt without tying the core application to a single hosted AI provider.

For this project, the important part isn't making AI autonomous. It's making a small, useful AI assistant available while keeping the shopkeeper in control.