Now connecting it all together
Hacktoberfest was essentially all about using AI to make projects, and I broke down how I used it
This Hacktoberfest, I contributed to a series of open-source projects that I developed, focusing on solving real-world problems with a local-first, hands-on approach. It was an incredible experience in building practical, user-centric tools. Here’s a breakdown of my journey.
This Hacktoberfest, I worked on several projects, with the two flagship projects being SlothMode and lux.
SlothMode is a local-first AI productivity companion designed to enforce breaks. In a world obsessed with productivity, it acts as a "sloth" that takes the wheel when you’ve worked too long, saving your work and locking you out until your scheduled break is over. It’s built on the principle of open innovation: your data, session logs, and break schedules never leave your machine. It uses open-weight models and a local .ics calendar file, proving you don’t need a server or a subscription to build a useful, privacy-respecting tool. The typical user is a developer or writer who struggles to take regular breaks; SlothMode tracks their focus and enforces a healthy .
lux is an open-source puzzle and learning platform that combines Linux, programming, cybersecurity, and AI-assisted problem-solving into an interactive adventure. Players progress through hands-on challenges, receiving contextual hints powered by local AI models. It’s designed for learners who want to gain practical technical skills through experimentation rather than memorization. For example, a beginner can solve a Linux command-line puzzle, and if they get stuck, the local AI agent provides a hint without revealing the answer, encouraging them to figure it out. This project is important because it makes technical education more engaging, accessible, and interactive.
The other projects in my Hacktoberfest cohort include:
The primary technical challenge I addressed was in SlothMode: reliably preventing a user from dismissing a scheduled break. A simple notification is too easy to ignore. The issue was to create a "hard lockout" mechanism that could not be bypassed without breaking the system’s state.
This was solved by building a LockoutAbstraction (using the Bridge pattern) that could toggle between a gentle toast notification and a fullscreen mode. The fullscreen mode creates a JavaFX overlay that captures all user input and prevents dismissing the window, effectively enforcing the break.
In lux, the key challenge was safely executing untrusted, script-based puzzle submissions. The solution involved running code inside a Docker container with network disabled, dropped capabilities, and limited CPU/memory, ensuring the platform remains secure while allowing users to experiment freely.
The tech stack for SlothMode is designed for local, cross-platform use:
.ics File
The full workflow is centered on the SlothModeApp facade. When a user starts a focus session, the SessionHub (Mediator) coordinates the state. The ConfigManager (Singleton) provides the user's settings, such as lockout mode. When a session ends, the LockoutAbstraction (Bridge) triggers either a gentle notification or a full-screen lockout. The app then uses a Memento pattern to snapshot the .ics file before writing any new manual breaks, ensuring no data is lost if an error occurs. Finally, the Observer pattern notifies all UI components (like the reward system) to update.
For lux, the stack includes:
The workflow starts with a user selecting a level via the CLI agent or web UI. The agent fetches the puzzle description from the Flask server and accepts an attempt. If the attempt is incorrect, the agent queries Ollama for a contextual hint. When solved, the server validates the answer (via string comparison or sandboxed Docker execution) and the agent persists progress to a local JSON state file. The server exposes versioned API routes (/api/v1/...) for puzzle discovery, progress, and achievements, making it easy to build future clients.
A significant technical challenge in SlothMode was implementing the fullscreen lockout in a way that was robust and secure but also not overly intrusive or resource-heavy. My initial attempts involved trying to block all input at the OS level, which was complex and platform-dependent. I then tried using a JavaFX WebView with an embedded HTML/JS overlay, which proved to be too heavy. The solution was to create a dedicated LockoutStage using JavaFX's Stage with StageStyle.UNDECORATED and setFullScreen(true). The key was to handle the setOnCloseRequest and setOnKeyPressed events directly on this stage, consuming the events and effectively making the lockout un-dismissable.
In lux, the challenge was ensuring the Docker sandbox was truly secure. I had to carefully configure the container to disable networking, drop all capabilities, and limit resources, while still allowing the puzzle scripts to run correctly. This required extensive testing and iteration on the sandbox.py module.
The final solution for SlothMode was to use the Bridge design pattern to separate the "abstraction" of a lockout from its "implementation." The LockoutAbstraction defines the interface (engage() and disengage()), while FullscreenLockout and GentleLockout are the concrete implementations. This architecture allowed me to have a configurable lockout.mode in the config.toml file. The LockoutAbstraction is instantiated with the correct implementation at runtime via the Abstract Factory pattern. The full-screen implementation was then built as a JavaFX Stage that consumes all input events. Testing was done by running the app and starting a focus session, verifying that the overlay appeared and couldn't be dismissed until the timer expired.
For lux, the solution was a multi-layered approach: a Flask server for puzzle management, a CLI agent for interaction, and a Docker-based sandbox for secure code execution. The AI hints are generated by Ollama, with a system prompt that instructs the model not to reveal flags. Progress is persisted locally in a JSON state file, making the platform fully self-contained. Testing involved running the server and agent, solving levels, and verifying that progress and achievements were correctly saved and restored. What I'd Do Differently: Using agents to automate testing and deployment would have saved time, rather than relying on chatbots, which I needed support on. However, I sparingly used it due to recognizing design patterns I learned in class. Attending more livestreams would have given me better insight into trending tools. Next year, I plan to host an event showcasing these projects and how others can contribute, bringing more people into the open-source fold.
Links to all projects below:
[https://github.com/johnny603/SlothMode](https://github.com/johnny603/SlothMode)
[https://github.com/johnny603/museum_of_the_dead](https://github.com/johnny603/museum_of_the_dead)
[https://github.com/johnny603/CreatorDesk](https://github.com/johnny603/CreatorDesk)
[https://github.com/johnny603/MudMap](https://github.com/johnny603/MudMap)
[https://github.com/johnny603/CscGrader](https://github.com/johnny603/CscGrader)
[https://github.com/johnny603/generateRubrics](https://github.com/johnny603/generateRubrics)
[https://github.com/johnny603/lux](https://github.com/johnny603/lux)