Hi guys, quick update! Since the last devlog I’ve been fixing the “what’s missing” list and getting the portfolio ready to deploy:

• Filtering & Sorting (done!): The Projects page now actually filters and sorts. You can filter by category and sort by newest, oldest or any project field. Everything goes through URL search params, so a filtered view can be shared as a link.
• Real GitHub Data on the Contributions Page: The contribution graph now merges my own project milestones with my real GitHub contribution calendar. It’s fetched on the server through GitHub’s GraphQL API, private contributions included, so the token never reaches the browser.
• Data Backfill: The showcase went from 18 to 42 projects, now covering everything from July 2021 to December 2025. That includes the whole OmniSys plugin family (Vanish, LaunchPads, StaffHomes, RanksPro and more), bots, APIs and older web projects, each with its own thumbnail and gallery.
• Ready for Vercel: Serverless filesystems are read-only, so I wrote a storage layer that saves CMS edits to Vercel Blob when deployed and falls back to the local JSON files when self-hosted. It’s the same admin panel on both.
• Admin Security: Admin auth is now properly hardened. Sessions are HMAC-signed cookies that expire after 8 hours, and passwords are checked with timing-safe comparison. If the secrets are missing in production, every login is refused. Admins can also see hidden projects on the public pages.
• Config-driven Landing: The work experience timeline and the tech logo loop used to be hardcoded. They now come from config files, so updating them doesn’t mean editing JSX.Tests: I added a Vitest suite covering auth, storage, project data and the admin actions.Polish: A proper 404 page for unknown projects, plus a README with setup instructions and a write-up of how everything works.
  What’s missing:
• Mobile optimization
• Hero screenshots/GIFs for the README
• Deploying it live at sgattix.online

Hi guys. Have you ever felt that feeling, at the end of the summer, when you just can’t move on to fall. But as Richard Feynman reminds us, “What is a memory? It is a memory of a past moment, a remembered feeling, an echo of a time. But a memory is also a feeling that can be remade. It is a new moment, a new feeling, a new memory, when you choose to recall the past.”.

So this is my way to keep the memories of this past summer: an headless Next.js application that acts as an extension to the physical diary I wrote to handle media, knowledge and experience sharing.

How it works

On the physical diary, I printed one QRCode per page. So the “user” flow is:

1. Open the physical diaryScan the QRCode
2. Play any media available on the page
3. In the meanwhile read the daily reflection
4. Have fun while reading.

What’s done

• I built the main infrastructure, while focusing more on flexibility rather then scalability
• Wrote some of the pages (20)

What’s missing

• Add some twists
• Finish writing all the pages (80)
  Wish me luck!

NOTE: The diary and the pages are all written in italian because this was part of a school project, hope it doesn’t bother anyone. I suggest you to use google translate to translate the entire page

Hi everyone!
I’ve been making good progress on Defied lately. Here’s an update on what I’ve been working on:

Backend

• Magic-link auth is working, and I’ve added Zitadel as auth provider for a more ecosystem-like architecture. The auth handler now supports both email magic-links and Zitadel OIDC.
• Health endpoints: /health, /health/db, /health/auth, and /health/mail endpoints for monitoring
• Email verification: SMTP integration with verifyEmailConnection() for magic-link email verification

Frontend

• Blog management: Integrated BlockNote and Nextra to build a fully-functional blog
• Landing page: Designed and built, showcasing Defied’s services and values
• Login page: Updated with modern design and auth flow

I will soon implement syntax highlighting and LaTeX in the blog editor. Stay tuned

Hi guys, I decided to spend these 4 hours doing something that almost no one does these days: reviewing code by hand, zero-AI. I noticed some contradictions, something that didn’t quite reflect Defied’s values and status. So here’s the final, working, bulletproof, but most importantly meaningful version of Defied’s landing page.

I will soon ship it, so wish me luck!

Hi guys, I’ve been quite busy lately with my life outside Stardance. However I still managed to put some effort on a new project: Defied.
Defied is a software company that builds advanced digital products, combining software engineering, AI and design to create reliable, elegant and accessible tools.
Here’s what I did so far:

Backend

• Built basic magic-link auth that will be later moved to a Zitadel-based auth for a more ecosystem-like architecture

Frontend

• Designed and built landing page
• Designed and built login page

Just as a quick note, this is Defied’s landing page and service wrapper, not a service. For Defied services, check out Defied Prism (Which I will later post here, as a multi-framework, css modules and tailwindcss component library).

If you ever created a web application with React using some component library, you know how it goes. You start with a simple page, maybe a header and a button. Then you add some more components, maybe a form or a dropdown. Before you know it, you have a full-blown application with dozens of components and complex state management. This is why I invented Paradox UI, an opinionated, highly-reusable React component library engineered to eliminate dependency fragmentation and bridge the gap between basic primitives and complex, data-dense UI. Built by and for the frontend community.

What I Built (The First 8 Hours)

• Set up the development environment with pnpm and turbo
• Created the basic project structure with multiple apps (web, server, docs)
• Implemented UI primitives and components in @paradox-ui/primitives (WCAG AA accessibility) and @paradox-ui/ui (divided in client and server components)
• Created the “preset submission flow”

Next Up

• Build out the main application components and pages for the web app
• Create additional UI components such as modals, tooltips, and tables
• Implement responsive design improvements

It is finally done. After 3 hours and 40 minutes, WinSentry is complete, fully optimized, and running flawlessly. The final block of development focused entirely on the user-controlled workspace clearing engine and rigorous resource profiling.

The Final Piece: The Safe Developer Staging Queue

The automated system janitor is great for temp folders, but developer bloat like node_modules or pycache requires absolute user safety.

• How it works: I implemented a high-speed, sequential directory traversal engine. When triggered on-demand via the CLI (winsentry –scan), the tool walks through user-specified workspace paths looking for target directory names defined in the config.
• The Guardrail: Instead of deleting anything, the tool calculates the total directory size and flushes the data to a local state file inside %APPDATA%/WinSentry/queue.json.
• The Interactive Review: The user is notified via the terminal that bloat has been discovered. Running winsentry –purge loads the JSON queue and gives the user an interactive, explicit review prompt to check boxes or type all to confirm deletion. Absolute control, zero risk of accidental data loss.

Production Performance Benchmarks

Since this tool was built to fight Windows sluggishness, it could not afford to be heavy. Running a fast compiled systems language like Rust paid off massively. Here are the real-world metrics monitored via Windows Task Manager:

• Idle Footprint: 0% CPU and 0.9MB of RAM. It sits completely dormant in the background, listening for the global hotkey message loop and waiting for the 30-minute system interval.
• Peak Scan & Discovery Footprint: Maximum 10% CPU usage and a peak of 5MB of RAM while actively traversing thousands of subdirectories and calculating file sizes during a deep disk scan.

On an NVMe and DDR5 setup, the scan completes in seconds, meaning the system never hitches and the user never has to wait for the utility.

READY TO SHIP!

Two more hours in, and WinSentry now has a fully functioning debloating engine and a robust multi-threaded architecture.

What’s new

• I ripped out the real-time event watcher and replaced it with a task that executes once every 30 minutes. It sleeps completely in between cycles. Performance dropped immediately back to 0% CPU on idle, achieving the exact “invisible” footprint a performance tool needs.
• Reworked Threading: Thread safety is locked down. The core engine now cleanly separates the global UI hotkey listener thread from the background debloating loop, ensuring a heavy system cleanup never hitches or delays the 300ms “Panic Button” response.
• System Debloater: The 30-minute janitor thread now actively sweeps system-generated trash paths (configured via %APPDATA%/WinSentry/config.toml). It safely bypasses active, locked files while cleanly executing deep purges on dead telemetry and crash dumps.
• Robust Logging & Documentation: Implemented a lightweight, structured local logging system to track exactly how many megabytes of ghost space are reclaimed over time. I also laid down the full README.md.

Next Up
Implementing the User-Specified Safe Queue (queue.json). I’ll be writing the directory traversal logic to detect massive developer black holes (node_modules, pycache) and scaffolding the manual CLI review step so users can safely approve massive space reclamation.

Windows has a bad habit of treating the user like a guest on their own machine. Despite running an i7-12700K, 32GB of DDR5, and a fast NVMe, I still run into locked UI threads, disappearing taskbar icons, and a persistent “waiting for the OS” feeling.

Instead of dealing with it, I’m building WinSentry—a lightweight, native Windows daemon written in Rust designed to force the OS to be responsive and clean.

What I Built (The First 2 Hours)

Instead of cutting corners, I spent the first block of development setting up a bulletproof core architecture:

• The 300ms Panic Button: Implemented a low-level global keyboard hook using the Win32 API (RegisterHotKey). Pressing Ctrl + Alt + W forcefully kills explorer.exe, wipes the easily-corrupted local %localappdata%\IconCache.db file while the thread is dead, clears the icons registry at HKEY_CURRENT_USER\Software\Classes\.png and instantly spawns a clean shell instance.
• Configuration System: Designed a centralized configuration system that initializes inside a specified directory. Users can customize their hotkeys and define exact target paths.
• Aggressive Binary Optimization: The background daemon sits completely idle at 0% CPU and takes up less than 1MB of RAM, making it practically invisible to the system.

Next Up

Moving on to the storage engine:

• Implementing ReadDirectoryChangesW for zero-overhead, real-time event tracking on high-bloat system folders (%TEMP%, crash dumps).
• Building the staging queue pipeline (queue.json) to safely scaffold and manually review massive developer black holes like node_modules and pycache before purging them.

Hi guys, I started building this project right between Flavortown and Stardance, so here’s what I did so far:

• The Content Engine: local JSON-based CMS.
• The Project CMS (Admin Panel)
• The “Contribution” Chronology: I’ve implemented a custom Contribution Graph and Timeline. Unlike a standard GitHub embed, this logic parses my own project milestones and releases (dating back to the founding of OmniCraft in 2020) to visualize activity across various platforms (Java, Discord, Web).
• WebGL Integration (“Faulty Terminal” background)
• Kibo-UI & Custom Components: I’m using a mix of custom components like PixelCard (Canvas-based shimmering effects) and kibo-ui for complex elements like date pickers and dropzones in the admin panel.

What’s missing:

• Filtering Logic
• Mobile Optimization
• Data Integrity: Some sections of the “Contributions” page are still being backfilled with historical data from the 2020–2023 era.