Forem: Marcin Firmuga

Wednesday Code Autopsy #4: The Canvas Arc Nobody Uses - PC Workman

Marcin Firmuga — Thu, 16 Apr 2026 17:50:16 +0000

Needed circular progress gauge. Googled "Python circular progress bar." Every answer: pip install [library].

Drew mine with pure tkinter Canvas:

Zero dependencies
Two parameters: style="arc", extent=-270
Professional look
20 lines of code

secret: tkinter has THREE arc styles. 99% of devs only use one.

The Problem

I needed a circular progress gauge for PC Workman's "First Setup & Drivers" page.

Something clean. Professional. The kind you see in system health dashboards.

First instinct: Google.

Search: "Python circular progress bar"

Results:

matplotlib circular progress tutorial
PIL + pillow gauge example
PyQt QProgressBar subclass
Custom tkinter widget library

Every answer started the same: pip install [library].

PC Workman is already PyQt6 + tkinter + psutil + SQLite. Adding matplotlib for one gauge? Overkill.

There had to be a better way.

The Discovery

Opened the tkinter Canvas docs.

Not Stack Overflow. Not a tutorial. The actual documentation.

Found create_arc():

style: One of 'pieslice' (default), 'chord', or 'arc'.

style="arc" — draws just the arc itself. No fill. No center lines.

This was it.

The Solution

def _draw_arc(canvas, score):
    # Background arc (full 270° track)
    canvas.create_arc(10, 10, 110, 110,
                      start=225, extent=-270,
                      style="arc", outline="#1f2937", width=7)

    # Progress arc (proportional to score)
    if score is not None:
        color = _score_color(score)
        extent = -int(270 * score / 100)
        canvas.create_arc(10, 10, 110, 110,
                          start=225, extent=extent,
                          style="arc", outline=color, width=7)

Result:

[10-second PC Health gauge animation]

Clean. Professional. Zero dependencies.

How It Works

The Geometry

create_arc() takes a bounding box, not center + radius:

canvas.create_arc(x1, y1, x2, y2, ...)
#                 └─────┬─────┘
#                 rectangle containing circle

For a perfect circle at (60, 60) with radius 50:

canvas.create_arc(10, 10, 110, 110, ...)
#                 60-50, 60-50, 60+50, 60+50

The Angles

tkinter measures angles from East (3 o'clock) = 0°, counterclockwise:

Direction	Degrees
East	0°
North	90°
West	180°
South	270°

Trick: Negative extent goes clockwise.

For a speedometer (7:30 to 4:30 position):

start=225,   # 225° = bottom-left (7:30)
extent=-270  # -270° clockwise = wraps to bottom-right (4:30)

Perfect 270° gauge.

The Secret Third Style

Most devs know two Canvas arc styles:

Style	What It Draws
`"pieslice"`	Filled wedge from center (default)
`"chord"`	Arc + straight line connecting ends
`"arc"`	Just the arc curve

Almost nobody uses style="arc".

That's your circular progress bar.

style="arc", outline="#10b981", width=7

7-pixel green arc. No fill. No custom drawing.
style="arc" has been in tkinter since Python 1.x. 99% of developers have never touched it.

The Production Implementation

The two-line example is simplified. Here's what ships in PC Workman:

def _draw_arc(canvas, score):
    canvas.delete("all")
    W, H = 108, 92
    cx, cy, r = W // 2, H // 2 + 4, 35

    # Layer 1: Outer glow (wider, darker)
    canvas.create_arc(cx-r-4, cy-r-4, cx+r+4, cy+r+4,
                      start=225, extent=-270, style="arc",
                      outline="#1a2035", width=10)

    # Layer 2: Track (gray path)
    canvas.create_arc(cx-r, cy-r, cx+r, cy+r,
                      start=225, extent=-270,
                      style="arc", outline="#1f2937", width=7)

    # Layer 3: Progress (colored, proportional)
    if score is not None:
        col = _score_color(score)
        extent = -int(270 * score / 100)
        canvas.create_arc(cx-r, cy-r, cx+r, cy+r,
                          start=225, extent=extent,
                          style="arc", outline=col, width=7)

        # Score text
        canvas.create_text(cx, cy - 3, text=str(score),
                          fill=col, font=("Consolas", 22, "bold"))
        canvas.create_text(cx, cy + 17, text="/100",
                          fill="#6b7280", font=("Consolas", 9))

Three layers on same Canvas:

Outer glow — 10px dark, 4px larger radius (depth)
Track — 7px gray, full 270° (background)
Progress — 7px colored, proportional (gauge)

No masking. No blending. Just stacking arcs.

The Math

extent = -int(270 * score / 100)

Score	Calculation	Result
100	-int(270 * 1.0)	-270 (full)
75	-int(270 * 0.75)	-202 (¾)
50	-int(270 * 0.5)	-135 (½)
0	-int(270 * 0.0)	0 (empty)

The int() is critical. tkinter won't accept float extents — it'll silently fail and draw nothing.

Color Grading

def _score_color(score):
    if score >= 80:
        return "#10b981"  # Green
    if score >= 55:
        return "#fbbf24"  # Amber
    return "#ef4444"      # Red

def _score_grade(score):
    if score >= 85: return "EXCELLENT"
    if score >= 70: return "GOOD"
    if score >= 50: return "FAIR"
    return "POOR"

Three thresholds. Same color in arc, number, and label.

No color library. Just hex values.

The Scanning State

Gauge drawn twice:

On load — gray track only (score=None)
After scan — colored progress (score=0-100)

# Initial
_draw_arc(health_canvas, None)

# After scan thread
_draw_arc(health_canvas, calculated_score)

if score is not None prevents empty arc or crash.

While scanning (registry check, driver status, updates), gauge waits as clean gray circle.

Copyable Minimal Example

Want this in your project? Here's the stripped version:

import tkinter as tk

root = tk.Tk()
canvas = tk.Canvas(root, width=120, height=120, bg="#0a0e14")
canvas.pack()

def draw_gauge(score):
    canvas.delete("all")

    # Gray track
    canvas.create_arc(10, 10, 110, 110,
                      start=225, extent=-270,
                      style="arc", outline="#1f2937", width=8)

    # Colored progress
    if score:
        extent = -int(270 * score / 100)
        canvas.create_arc(10, 10, 110, 110,
                          start=225, extent=extent,
                          style="arc", outline="#10b981", width=8)

        # Text
        canvas.create_text(60, 60, text=str(score),
                          fill="white", font=("Consolas", 18, "bold"))

draw_gauge(73)
root.mainloop()

20 lines. Zero dependencies. Production-ready.

Why This Matters

This gauge powers health check in PC Workman (110+ downloads, 23 GitHub stars).
First thing users see in "First Setup & Drivers."

Makes the section feel premium — smooth, clean, not default tkinter.
All because I read Canvas docs instead of installing matplotlib.

The Bigger Lesson

Most developers solve problems by adding dependencies.
Need progress bar? Install library.

Need chart? Install library.

Need widget? Install library.

Nothing wrong with libraries. Good ones save time.
But sometimes the best solution is in stdlib docs.
In a parameter you've never used.
On a page you've never read.
style="arc" has existed since Python 1.x.
99% of developers never touched it.
I found it in 5 minutes of reading docs instead of Googling "how to."

What's Next

PC Workman v1.7.x builds toward TURBO Mode. Windows optimization tools:

CPU unparking
RAM flushing
Service management
Power plan switching

"First Setup & Drivers" scans system, gives health score before TURBO touches anything.

This gauge is part of that foundation.

v1.7.2 ships next week.

Your Turn

What's your "I can't believe this is possible with just X" moment?
Time you almost installed library, then realized solution was in docs?
Drop it below

PC Workman v1.7.2: I Built a Driver Booster Competitor From Scratch, Fixes. Monday Grind Blueprint #3

Marcin Firmuga — Mon, 13 Apr 2026 12:40:56 +0000

6 AM. Monday. Couldn't sleep.

Not the inspirational "I'm so motivated" kind of can't sleep. More like my brain decided to start compiling the entire weekly sprint at 5:47 AM and wouldn't shut up until I opened VS Code.

By 11 AM I had shipped four things that weren't even on this week's list. By Friday, the actual plan got done too. Some of it. Enough of it. This is the story of both.

PC Workman is at v1.7.2 now. If you're new here: it's an open-source AI-powered system monitor I've been building solo for 800+ hours. Python, PyQt5, WMI, a custom AI diagnostic engine called hck_GPT, and a lot of late nights after Żabka shifts. This week was one of the heaviest since I started.

Let's cut it open.

1. hck_GPT Time Badges — The Small Feature That Took Months to Actually Do

This one has been haunting me since Monday Grind Blueprint #1.

The problem was simple: hck_GPT would tell you things like "Chrome ate 6GB RAM recently." When recently? An hour ago? Yesterday? During that Windows update at 3 AM?

No timestamp. No context. Just "recently."

I kept pushing it back. "Next sprint." "After the UI redesign." "When I have time." Classic.

Monday morning, 6:23 AM, I just... did it.

The Interesting Part

hck_GPT's chat panel is a tk.Text widget. Most people use Text widgets for plain text. Type stuff in, maybe color some words, done.

But tkinter has this thing called window_create() that lets you embed any widget inside the text flow. Not on top of it. Not floating above it. Inside it, like it's just another character.

So instead of prepending "[08:52]" as plain text (boring, hard to style, breaks if the message wraps weird), I built a tiny canvas badge:

# panel.py
def _make_time_badge(self):
    badge = tk.Canvas(
        self.log,
        width=62, height=14,
        bg=THEME["bg_panel"],
        highlightthickness=0,
    )
    badge.create_rectangle(0, 0, 62, 14, fill="#0d0f14", outline="")
    badge.create_rectangle(0, 0, 3, 14, fill="#dc2626", outline="")   # left red bar
    badge.create_rectangle(59, 0, 62, 14, fill="#dc2626", outline="") # right red bar
    badge.create_line(3, 0, 3, 14, fill="#374151")
    badge.create_text(31, 7, text=time.strftime("%H:%M"),
                      fill="#94a3b8", font=("Consolas", 7, "bold"))
    return badge

Dark background, red accent bars on each side, Consolas font, 7pt bold. It looks like a tiny terminal badge sitting in the chat.

Then in add_message():

def add_message(self, msg):
    self.log.config(state="normal")
    if msg.startswith("hck_GPT:"):
        badge = self._make_time_badge()
        self.log.window_create("end", window=badge, padx=2, pady=1)
        self.log.insert("end", " ")
    self.log.insert("end", msg + "\n")
    self.log.config(state="disabled")

That window_create("end", window=badge) is the whole trick. The canvas lives inside the text flow, scrolls with everything else, and costs almost nothing performance-wise.

Small feature. One morning. Months overdue. Now every hck_GPT message says when it happened. 08:52, not "a while ago."

2. Process Library — From "Unknown" to "Oh, That's What You Are"

This one started in Blueprint #1 too. The idea was simple: when PC Workman mentions a process, you should know what it is without opening Google.

process_library.json already had ~60 entries. But real usage kept surfacing gaps. hck_GPT would say "WmiPrvSE.exe is using 34% CPU" and the tooltip showed... nothing. Unknown process.

This week I added 8 more entries, specifically the ones that kept showing up as unknowns during actual sessions:

wmiprvse.exe — WMI Provider Host. Every monitoring tool talks to this. Including PC Workman itself.
msmpeng.exe — Windows Defender's scan engine. The one that randomly spikes CPU at 2 AM.
registry — NT kernel process, no .exe extension. Easy to miss entirely.
claude.exe — Yes, the Claude desktop app. I use it enough that it shows up in Top 5.
hitman.exe, hitman2.exe, hitman3.exe — HITMAN trilogy. Each one with different VRAM profiles.
datatransfer.exe — Connected Devices Platform sync. Nobody knows what this is until it's eating RAM.

Each entry follows the same schema:

{
  "msmpeng.exe": {
    "name": "Windows Defender Antimalware Service",
    "vendor": "Microsoft",
    "category": "Security",
    "description": "Core scan engine for Windows Defender. Periodic CPU spikes are normal during scheduled scans.",
    "power_usage": "medium-high during scans",
    "safety": "safe — do not kill",
    "typical_cpu": "0-5% idle, 15-40% during scan",
    "typical_ram": "150-300 MB"
  }
}

Clean, queryable, and every field actually means something.

Tooltips Everywhere, Not Just in Chat

Before this week, the hover tooltip only worked inside hck_GPT's chat panel. If a process showed up in the main dashboard Top 5 panels, you were on your own.

Fixed that. But it wasn't as simple as "just add a tooltip."

The Top 5 panels update every render tick. Process names change constantly. If you capture the process name at widget creation time, the tooltip will show stale data within seconds.

Solution: store the process name in a mutable dict that gets updated every tick:

# main_window_expanded.py
widget_data = {
    "row": row, "name": name_lbl,
    "cpu_bar": cpu_bar, "cpu_val": cpu_val,
    "ram_bar": ram_bar, "ram_val": ram_val,
    "proc_name": "",   # updated every render tick
}

if self._process_tooltip:
    def _enter(e, wd=widget_data):
        pn = wd["proc_name"]
        if pn:
            tt = _proc_lib.format_tooltip_text(pn)
            if tt:
                self._process_tooltip.show(e, pn, tt)
    def _leave(e):
        self._process_tooltip.hide()
    name_lbl.bind("<Enter>", _enter)
    row.bind("<Enter>", _enter)    # whole row = bigger hit area

Then in the render loop, one line:

widget_data["proc_name"] = display_name

The wd=widget_data in the lambda captures by reference, not by value. So when the render loop updates proc_name, the tooltip reads the fresh name. No timer, no polling, no auto-hide. Mouse in = tooltip. Mouse out = gone. User reads at their own pace.

3. First Setup & Drivers — Building a Driver Booster From Scratch

This was the big one. Not planned for Monday. Not planned for this week at all. Just... happened.

I opened Driver Booster, IObit's tool, the one everyone installs when they get a new PC. And I thought: what does it actually do?

It reads your installed drivers. Checks versions. Shows you what's outdated. That's it. The "boost" part is just a download link.

I can do that. Without internet. Without admin rights. Without a third-party API.

Reading Drivers From the Windows Registry

Windows stores driver metadata in the registry under SYSTEM\CurrentControlSet\Control\Class\{GUID}. Each device class (GPU, Audio, Network, USB) has its own GUID. You open the key, enumerate subkeys, and read three values: DriverDesc, DriverVersion, DriverDate.

def _read_class_driver(guid):
    key_path = fr"SYSTEM\CurrentControlSet\Control\Class\{guid}"
    with winreg.OpenKey(winreg.HKEY_LOCAL_MACHINE, key_path) as cls:
        for i in range(min(winreg.QueryInfoKey(cls)[0], 24)):
            sn = winreg.EnumKey(cls, i)
            if not sn[:4].isdigit():
                continue
            with winreg.OpenKey(cls, sn) as dev:
                desc = winreg.QueryValueEx(dev, "DriverDesc")[0]
                if any(kw in desc.lower() for kw in _SKIP):
                    continue
                ver      = winreg.QueryValueEx(dev, "DriverVersion")[0]
                drv_date = winreg.QueryValueEx(dev, "DriverDate")[0]
                return {"name": desc, "version": ver, "date": drv_date}

No internet call. No admin popup. Just winreg.OpenKey on HKEY_LOCAL_MACHINE. Windows lets you read this without elevation. You just can't write to it.

The _SKIP list filters out virtual network adapters (Hyper-V, VPN clients, Docker). Without it, the page fills up with phantom devices nobody cares about.

The Date Format Problem

Driver dates come from the registry as strings. Sounds simple. Except Windows uses at least three different formats depending on... I honestly don't know what. Device class? Driver manufacturer? Phase of the moon?

MM-DD-YYYY
YYYY-MM-DD
YYYYMMDD

The _driver_age_days() function tries all three. If none work, it returns None and the health score takes a small penalty for "unknown age" instead of crashing.

Health Score — Computed, Not Faked

Driver Booster shows you a big number. "Your system health: 73%." Where does that number come from? Nobody knows.

Mine is transparent:

def _compute_score(drivers, startup_count):
    score = 100
    for d in drivers:
        days = _driver_age_days(d.get("date", ""))
        if days is None:   score -= 6
        elif days >= 365:  score -= 20
        elif days >= 180:  score -= 9
    if startup_count > 12: score -= 15
    elif startup_count > 8: score -= 8
    return max(10, min(100, score))

Driver older than a year? Minus 20. Unknown date? Minus 6. Too many startup programs? Penalty. The formula is right there. You can read it, disagree with it, and fork it.

The score renders as an arc gauge drawn with canvas.create_arc(). 270° sweep, green→amber→red based on value. Nothing fancy. Nothing hidden.

Quick Actions

The page also has a Quick Actions panel. One-click access to Device Manager, Services, System Info, and MSConfig. These are just subprocess.Popen calls to devmgmt.msc, services.msc, msinfo32.exe, and msconfig.exe.

Sounds trivial. But I deep-researched what other tools in this space offer for first-time PC setup, and most of them... don't offer this. They focus on the driver scan and ignore the fact that someone setting up a new machine probably also wants quick access to system tools.

The Architecture Bit

The page itself is ~370 lines (ui/pages/first_setup_drivers.py). UI builds immediately — instant render, no loading screen. The driver scan runs in a threading.Thread and posts results back to the main thread via sf.after(0, lambda: _apply(...)).

Startup programs come from two registry hives:

paths = [
    (winreg.HKEY_CURRENT_USER,
     r"SOFTWARE\Microsoft\Windows\CurrentVersion\Run", "User"),
    (winreg.HKEY_LOCAL_MACHINE,
     r"SOFTWARE\Microsoft\Windows\CurrentVersion\Run", "System"),
]

User-level and system-level. Both matter.

There's also a setup checklist that persists to data/cache/setup_checklist.json. Toggle items on click, progress bar updates live. Small thing, but it makes the page feel like a tool you come back to, not a one-time scan.

4. The Bug Nobody Noticed

The "First Setup & Drivers" button in yourpc_page.py was routing to the wrong page.

Click "First Setup & Drivers" → opens the optimization wizard. Not the setup page. The optimization wizard worked fine, so nobody reported it. Including me. I was clicking through the sidebar, not through the yourpc page buttons.

# Before (wrong):
btn.config(command=lambda: self._nav_to("optimization_wizard"))

# After (correct):
btn.config(command=lambda: self._nav_to("first_setup"))

One line. Probably been wrong since the button was created. The sidebar badge now also shows the live checklist state (e.g., "3/6 done"), loaded from JSON on every render.

5. The Scars

Every week has them. Here are this week's:

The scroll_frame width trap. When you embed a tk.Frame inside a tk.Canvas via create_window, the frame doesn't automatically fill the canvas width. Your entire page content renders in a narrow strip on the left. All your fill="x" packs are filling a 1px-wide frame and you don't know why.

Fix:

win_id = wrap.create_window((0, 0), window=sf, anchor="nw")
wrap.bind("<Configure>",
          lambda e: wrap.itemconfig(win_id, width=e.width - 2))

One binding. Took me 10 minutes of staring at the screen to figure out. If you're doing scrollable frames in tkinter — bookmark this.

The dead-code ghost. Earlier in the project, I deleted a _build_yourpc_page_OLD_REMOVED function. But a nested function inside it (_build_sensors_page_placeholder) survived the edit because the first attempt only replaced the function header, leaving the body orphaned. 40 lines of dead code sitting there, not breaking anything, not doing anything. Just vibing. Had to go back and kill it properly.

The write tool rejection. After writing ~370 lines for the new Setup & Drivers page, the file write failed because a linter touched the file between read and write. Had to re-read and re-issue the entire write. Not a code problem. Workflow problem. Lesson: on large files, write in one shot without anything touching the file in between.

What's Coming — The Week Plan (v1.7.2 → v1.7.4)

This was the Monday Grind Blueprint #3 plan. Here's what's on the board:

Dashboard Button Redesign

The buttons work. They look like 2015. PIL-generated gradients, canvas caching for button states, CSS-like hover system with state tracking. Zero FPS impact — gradients are pre-rendered once on init, then reused. The purple color scheme stays.

System Cleanup Utilities

Temp files cleaner (%temp%, Windows\Temp, Prefetch, browser caches). Log file manager with archive-before-delete. Startup optimizer with enable/disable toggles and impact ratings (High/Medium/Low).

One rule that won't change: nothing gets deleted without explicit user confirmation. No "we cleaned 2.3 GB!" surprises. You see the size, you confirm, then it happens. Detailed log of everything that was removed.

Complete "My PC" Health Tab

Right now: pretty placeholder. This week: real hardware detection via WMI queries (Win32_Processor, Win32_VideoController), temperature warnings (>85°C yellow, >90°C red), uptime stats, and JSON export for the health report.

TURBO — Auto RAM Flush

The one I'm most curious about. Advanced SystemCare and CCleaner claim 300-800 MB freed. What are they actually doing?

Researching three approaches:

EmptyStandbyList.exe (Sysinternals) — clears standby list
Native Python via ctypes (SetSystemFileCacheSize) — direct kernel call
Gentle per-process working set flush — least aggressive

Trigger: RAM >75% for >30 seconds. Measure before/after. Show the user exactly how much was freed. Toggle on/off, threshold adjustable.

If it works reliably without causing instability, it becomes the first real TURBO feature in PC Workman.

The Numbers

Version: 1.7.2
Hours logged: 800+
GitHub stars: 23
Downloads: ~100
Roadmap issues: 17 tracked, 4 done, 7 in review
Retail shifts between coding sessions: 5 per week
Microsoft Store: Q4 2026
Sleep this week: not enough

The Bigger Picture

I started PC Workman on a laptop hitting 94°C during compilation. Got fired three days before Christmas. Moved back to Poland. Started working at Żabka to pay bills while I keep building.

This isn't a weekend project. It's 800+ hours of "I refuse to let another project die at 70%."

v1.7.2 is the most feature-complete version yet. The First Setup & Drivers page alone competes with tools people pay for. The process library makes hck_GPT actually useful instead of just impressive. The timestamps make diagnostics real instead of vague.

And we're not even at v2.0 yet.

If you're building something solo, between shifts, between life — I see you. Keep shipping. Even the messy weeks count.

Star the repo if you want to follow along: github.com/HuckleR2003/PC_Workman_HCK

All my links: linktr.ee/marcin_firmuga

Monday Grind Blueprint sets the bar.
Wednesday Code Autopsy cuts it open.
Friday Shipped & Scarred shows what actually happened.

See you Wednesday.

About the Author

I'm Marcin Firmuga. Solo developer and founder of HCK_Labs. Building PC Workman — an open-source AI-powered system monitor — from scratch, publicly, honestly. Before this: game translations, IT technician internships, warehouse shifts in the Netherlands, and twelve failed projects I never finished. This one stuck.

Follow the build: GitHub · X/Twitter · LinkedIn · Medium

Friday Shipped & Scarred #3: PC Workman 1.7.1, The Foundation Great Release

Marcin Firmuga — Fri, 10 Apr 2026 08:32:02 +0000

PC Workman v1.7.1 shipped this morning:
18 test cases rewritten (previously broken)

~130 lines dead code removed
UI component refactor (AnimatedBar class)

3 chart bugs fixed (startup blank screen, filter lag, color inconsistency)

Process display redesign (readability improvements)

No new monitoring features. That's the point. This is infrastructure for TURBO Mode (system optimization tools coming in 1.7.x series).

Stack: Python, PyQt6, tkinter, psutil, SQLite

Dev time: Single morning (flow state after 9h retail shift)

Community impact: Closed testing issue from @Mary-devz

The Plan vs The Reality

Monday's roadmap:

3 issues from 1.7.8 milestone
UI button redesign
Code optimization in hck_gpt/

What actually happened:

Tuesday-Wednesday: Schema.org validator debugging
Thursday: 9h Żabka shift → 00:30 home → 5.5h sleep
Friday 6 AM: Flow state activated → full release shipped

Not what I planned. Better than what I planned.

Dead Code Archaeology

Fast-moving projects accumulate technical debt. PC Workman went from simple psutil wrapper to multi-module platform in ~12 months. That speed left artifacts.

Example: main_window_expanded.py

def _build_yourpc_page_OLD_REMOVED(self):
    """
    Old implementation of Your PC page.
    Extracted to ui/components/yourpc_page.py in v1.5.2
    ~130 lines of dead UI code
    """
    # ... 130 lines that haven't been called in 4 months

The problem: Not connected to anything. Never called. Just cognitive overhead.

The fix: Delete. Entire function removed.

Example: core/monitor.py

import platform  # Used: never
import psutil    # Used: everywhere

The fix: Remove unused import.

Example: requirements.txt

tkinter
tk>=0.1.0

The problem: Both are stdlib. Neither is pip-installable. Silent failures on pip install -r requirements.txt.

The fix: Remove both. Document stdlib dependencies in README instead.

Test Suite Rewrite: From Broken to Verified

Before (test_monitor.py):

def test_monitor_has_read():
    s = monitor.read()       # ❌ Method doesn't exist
    assert 'cpu_percent' in s

Actual method: monitor.read_snapshot()

This test has never passed. It was never run.

After (test_monitor.py):

@patch('core.monitor.psutil.cpu_percent', return_value=45.2)
@patch('core.monitor.psutil.virtual_memory')
@patch('core.monitor.psutil.disk_usage')
@patch('core.monitor.psutil.net_io_counters')
def test_read_snapshot_keys(self, mock_net, mock_disk, mock_mem, mock_cpu):
    """Snapshot contains all required keys with correct types"""
    mock_mem.return_value = MagicMock(percent=62.5)
    mock_disk.return_value = MagicMock(percent=78.0)
    mock_net.return_value = MagicMock(bytes_sent=1000, bytes_recv=2000)

    snapshot = monitor.read_snapshot()

    assert 'cpu_percent' in snapshot
    assert isinstance(snapshot['cpu_percent'], (int, float))
    assert 'ram_percent' in snapshot
    assert 'timestamp' in snapshot

Changes:

psutil fully mocked (no live system dependency)
Actual method name used
Type validation added
Runs in CI without hardware

Test Coverage Summary

test_monitor.py (7 cases)

Snapshot key presence & types
Process list parsing correctness
Sort order (CPU, RAM)
top_processes(n) limit enforcement
Cache hit behavior
Background thread population timing

test_analyzer.py (7 cases)

Zero-buffer edge case (should return zeroes)
CPU average calculation accuracy
averages_now_1h_4h() structure validation
Timestamp-based sample filtering
Spike detection (clear jump vs stable values)
Threshold sensitivity

test_avg_calculator.py (4 cases)

Missing file handling (empty list return)
Single-day aggregation with known values
Multi-day split (separate avg per date)
Result dict key validation

Total: 18 test cases, all using unittest.mock, zero live system dependencies.

Impact: TURBO Mode features (coming soon) will mutate system state. Verified data pipeline baseline is essential.

UI Component: AnimatedBar

Problem

Bars updated instantly:

# Before - instant jump
self.cpu_bar.place(relwidth=new_value)

Visually jarring when values change significantly (e.g., 20% → 75%).

Solution: Ease-out Animation Component

# ui/components/led_bars.py
class AnimatedBar:
    def __init__(self, parent, color, height=8):
        self.bg_frame = tk.Frame(parent, bg="#1e293b", height=height)
        self._fill = tk.Frame(self.bg_frame, bg=color, height=height)
        self._fill.place(relx=0, rely=0, relwidth=0, relheight=1)

        self._current = 0.0
        self._target = 0.0
        self._animating = False

    def set_target(self, pct: float):
        """Set target percentage (0.0 to 1.0)"""
        self._target = max(0.0, min(1.0, pct))
        if not self._animating:
            self._animating = True
            self._step()

    def _step(self):
        """Animation frame (ease-out)"""
        diff = self._target - self._current

        # Snap threshold: 0.4%
        if abs(diff) < 0.004:
            self._current = self._target
            self._fill.place(relwidth=self._current)
            self._animating = False
            return

        # Ease factor: 18% of gap per frame
        self._current += diff * 0.18
        self._fill.place(relwidth=self._current)

        # ~60fps
        self._fill.after(16, self._step)

Design Choices

Choice	Reasoning
Ease-out vs fixed-step	Always converges, no oscillation
Snap threshold (0.4%)	Prevents infinite micro-adjustments
18% ease factor	Fast initial movement, smooth slow-down
16ms frame time	~60fps
Layout-agnostic	`bg_frame` packs/grids anywhere

Usage

# Session Averages (3 bars)
self.cpu_bar = AnimatedBar(parent, color="#3b82f6")
self.cpu_bar.bg_frame.pack(fill="x", pady=2)
self.cpu_bar.set_target(0.63)  # 63%

# TOP 5 Processes (10 bars × 2 panels = 20 instances)
for i in range(5):
    cpu_bar = AnimatedBar(row_frame, color="#3b82f6")
    ram_bar = AnimatedBar(row_frame, color="#fbbf24")
    # ... layout logic

Result: All bars in app use same component. Future bars = 2 lines of code.

Process Display Redesign

Before (22px tall):

1. chrome.exe    [C ████░░ 12%] [R ██░░░░ 8%]

Issues:

Single-char labels (C, R) unclear
Name truncated at 14 chars (EpicGamesLau...)
Cramped layout

After (36px tall):

1. chrome.exe
   CPU ████████░░ 12%   |   RAM ████░░░░ 35%

Changes:

Two-line layout
Full labels (CPU, RAM) in accent colors
Name limit: 20 chars (covers most processes)
Equal-width bars with visual divider
Better hierarchy (name bold, metrics secondary)

Implementation

# Row container
row = tk.Frame(panel, bg=THEME["bg_panel"], height=36)
row.pack(fill="x", pady=1)

# Line 1: Process name
name_label = tk.Label(
    row,
    text=f"{i+1}. {proc_name[:20]}",
    bg=THEME["bg_panel"],
    fg=THEME["text"],
    font=("Consolas", 9, "bold"),
    anchor="w"
)
name_label.pack(fill="x", padx=8, pady=(4,0))

# Line 2: Metrics container
metrics = tk.Frame(row, bg=THEME["bg_panel"])
metrics.pack(fill="x", padx=8, pady=(0,4))

# CPU half
cpu_frame = tk.Frame(metrics, bg=THEME["bg_panel"])
cpu_frame.pack(side="left", fill="both", expand=True)

cpu_label = tk.Label(cpu_frame, text="CPU", 
                     fg="#3b82f6", font=("Consolas", 8))
cpu_label.pack(side="left")

cpu_bar = AnimatedBar(cpu_frame, color="#3b82f6", height=6)
cpu_bar.bg_frame.pack(side="left", fill="x", expand=True, padx=4)

cpu_pct = tk.Label(cpu_frame, text=f"{proc['cpu']:.0f}%",
                   fg=THEME["muted"], font=("Consolas", 8))
cpu_pct.pack(side="right")

# Divider
divider = tk.Frame(metrics, bg=THEME["muted"], width=1)
divider.pack(side="left", fill="y", padx=4)

# RAM half (same pattern)

Impact: Processes now identifiable at a glance. No guessing what C and R mean.

Chart Fixes: Three Bugs, One Session

Bug 1: Blank on Startup

Problem: canvas.winfo_width() returns 1 before tkinter paints widget. Retry logic was fragile.

Fix:

# Canonical tkinter pattern for "wait for real dimensions"
self.realtime_canvas.bind('<Configure>', self._on_chart_configure)

def _on_chart_configure(self, event=None):
    """Fires when canvas gets real dimensions (or resizes)"""
    self._chart_items = []  # Reset item pool
    self._schedule_chart_update(50)  # Immediate redraw

Result: Chart renders on first paint, every time.

Bug 2: Filter Lag

Problem: Clicking 1H or 4H loaded data but chart didn't update until next 2-second tick.

Fix:

def _on_filter_click(self, filter_name):
    """User clicked 1H, 4H, or Live"""
    self._current_filter = filter_name
    self._load_chart_data()
    self._schedule_chart_update(50)  # ← Added this line

Result: Instant visual feedback on filter change.

Bug 3: Color Inconsistency

Problem: Chart used #1e3a8a, #92400e, #064e3b (dark navy, brown, dark green) — remnants from intermediate implementation.

Fix:

# Consistent palette used everywhere else in app
CHART_COLORS = {
    'cpu': '#3b82f6',   # Blue
    'ram': '#fbbf24',   # Amber
    'gpu': '#10b981'    # Green
}

Result: Visual consistency across entire interface.

What's Coming: TURBO Mode

The 1.7.x series builds toward TURBO Mode — Windows system optimization tools triggered from dashboard.

Planned Features

1. Stop Non-Essential Services

# Pseudocode
essential = ['Dhcp', 'Dnscache', 'EventLog', ...]
running = get_running_services()
stoppable = [s for s in running if s not in essential]

for service in stoppable:
    if service.cpu_avg_7d < 0.5 and service.ram_avg_mb < 50:
        service.stop()

Impact: Free CPU/RAM from background services user doesn't need.

2. Unpark CPU Cores

# Windows parks cores under light load
# TURBO unpaks all physical cores
for core in range(cpu_count(logical=False)):
    set_core_parked_state(core, parked=False)

Impact: All cores available for compute-heavy tasks.

3. Auto Power Plan Switch

# Switch based on load threshold
if cpu_avg_5min > 60 or gpu_avg_5min > 70:
    set_power_plan('High Performance')
else:
    set_power_plan('Balanced')

Impact: Performance when needed, power saving when idle.

4. RAM Flush (>75% usage)

# Clear Windows standby list
if ram_percent > 75:
    flush_standby_list()  # ctypes call to kernel32

Impact: Reclaim cached RAM under memory pressure.

5. Suspend Inactive Processes

# Identify processes idle >10min
for proc in running_processes():
    if proc.cpu_time_last_10min == 0:
        proc.suspend()  # psutil.Process.suspend()

Impact: Free resources from backgrounded apps.

Why This Matters

TURBO Mode touches Windows internals. Incorrect implementation = system instability.

Requirements:

Verified data pipeline (tests)
Clean codebase (no dead code confusion)
Stable UI components (AnimatedBar reusable)
Bug-free monitoring (chart fixes)

v1.7.1 provides all of these.

When TURBO features land (1.7.2-1.7.8), they'll be built on solid foundation.

Scarred: Lessons Learned

1. Sleep debt is real

Flow state at 6 AM on 5.5h sleep? Lucky. Not sustainable.

2. Foundation work is invisible

No screenshots. No new features. But when TURBO Mode doesn't crash Windows? This is why.

3. Community feedback → credibility

Mary-devz raised testing issue. I shipped tests. Issue closed. Trust built.

4. Flow state doesn't wait

Best coding happens when it happens. 9h retail shift → 5.5h sleep → flow state → full release.

Plan around energy, not calendar.

What's Next

1.7.2 scope (next week):

UI button redesign (original roadmap item)
Possibly auto-update check (#14 - quick win)

1.7.x series:

TURBO Mode implementation (features listed above)
Complete "My PC" health tab
Microsoft Store preparation

Long-term:

v1.7.8 feature-complete
Store submission Q3 2026
v2.0 with full TURBO suite

Tech Stack

Component	Technology
Core	Python 3.8+
UI Framework	PyQt6
Legacy UI	tkinter
Monitoring	psutil
Storage	SQLite
Testing	unittest + unittest.mock
Build	PyInstaller
Signing	Sigstore

Monday Grind Blueprint #2: 80 Processes Explained, 3 Issues Targeted, 1 Week to Ship

Marcin Firmuga — Mon, 06 Apr 2026 22:05:17 +0000

Nobody needs another AI feature.

They need to know if svchost.exe is safe or a virus.
I spent Easter weekend building something embarrassingly simple: a JSON file that explains what 80+ Windows processes actually do.
Not machine learning. Not blockchain integration. Not "AI-powered insights."
Just context.
And it works better than I expected.

The Problem: Task Manager Shows Data, Not Understanding
Open Task Manager right now. You'll see:

svchost.exe — 6 instances, 800MB RAM
dwm.exe — 40% CPU spike
RuntimeBroker.exe — Random activity
System — Always at the top

What do you do?
Google "is svchost.exe a virus?"
Read 10 forum threads.
Still not sure.
Maybe kill the process.
Break something.
PC_Workman now solves this in 0.5 seconds:
Hover on svchost.exe in the chat →
Service Host Process
Microsoft Corporation
Hosts Windows services. Multiple instances are normal.
Power: Low-Medium
Safety: Safe (part of Windows)
CPU: 1-15% per instance
RAM: 50-200MB per instance
Done.
No Google. No paranoia. Just facts.

Easter Weekend: From "Too Tired" to "Shipped"
Context:
Week 1 at Żabka retail: 5:30 AM starts, solo store shifts by day 5, 20 zł/h (~$5/hour).
Monday plan: Process library + timestamps + 2 articles
Tuesday-Friday reality: Too exhausted to code after 9-hour shifts
Saturday-Sunday: Redemption arc
What shipped:

process_library.json — 80+ process definitions
process_library.py — Loader with lookups
tooltip.py — Hover UI widget
Integration in panel.py — Regex binding for chat

Time: ~4 hours total
Difficulty: Medium (Tkinter events + regex)
Impact: HIGH (users finally understand what processes are)

What I Built: The Process Library System
File 1: process_library.json (The Data)
Location: PC_Workman_HCK/data/process_library.json
Size: 80+ definitions (will grow to 150+)
Categories:

System: explorer.exe, svchost.exe, dwm.exe, csrss.exe
Browsers: chrome.exe, firefox.exe, edge.exe, opera.exe, brave.exe
Gaming: steam.exe, valorant.exe, leagueoflegends.exe, fortnite.exe, minecraft.exe
Development: python.exe, node.exe, code.exe, docker.exe, git.exe
Communication: discord.exe, teams.exe, zoom.exe, slack.exe
Media: spotify.exe, vlc.exe, obs64.exe, photoshop.exe
Productivity: excel.exe, word.exe, notion.exe, outlook.exe
Utilities: 7zfm.exe, winrar.exe, everything.exe
Virtualization: vmware.exe, virtualbox.exe

Structure:
json{ "chrome.exe": { "name": "Google Chrome", "vendor": "Google LLC", "category": "browser", "description": "Web browser. RAM usage increases with open tabs.", "power_usage": "high", "safety": "safe", "typical_cpu": "5-25%", "typical_ram": "200-800MB per window" }, "svchost.exe": { "name": "Service Host Process", "vendor": "Microsoft Corporation", "category": "system", "description": "Hosts Windows services. Multiple instances are normal.", "power_usage": "low_medium", "safety": "safe", "typical_cpu": "1-15% per instance", "typical_ram": "50-200MB per instance" } }
No AI-generated descriptions. All written in plain English, human-verified.

File 2: process_library.py (The Loader)
Location: PC_Workman_HCK/hck_gpt/process_library.py
What it does:

Loads JSON on startup
Provides case-insensitive lookups
Formats tooltip text for display

Implementation:
pythonclass ProcessLibrary:
` """Loads process definitions from JSON and provides lookups"""

def __init__(self):
    self.processes = {}
    self._load_library()

def _load_library(self):
    """Load process_library.json"""
    lib_path = os.path.join(
        os.path.dirname(__file__), 
        '..', 
        'data', 
        'process_library.json'
    )

    if os.path.exists(lib_path):
        with open(lib_path, 'r', encoding='utf-8') as f:
            self.processes = json.load(f)
        print(f"[ProcessLibrary] Loaded {len(self.processes)} process definitions")

def get_process_info(self, process_name):
    """Case-insensitive lookup"""
    return self.processes.get(process_name.lower().strip())

def format_tooltip_text(self, process_name):
    """Format for display"""
    info = self.get_process_info(process_name)
    if not info:
        return None

    return f"""📦 {info['name']}

{info['vendor']}

{info['description']}

Power: {info['power_usage']}
Safety: {info['safety']}
CPU: {info['typical_cpu']}
RAM: {info['typical_ram']}"""

Singleton instance

process_library = ProcessLibrary()`
Why singleton? One load at startup, shared across all components.

File 3: tooltip.py (The UI Widget)
Location: PC_Workman_HCK/hck_gpt/tooltip.py
What it does:

Creates borderless tooltip window
Positions near mouse cursor
Displays formatted process information
Auto-hides on mouse leave

Implementation:
pythonclass ProcessTooltip:
` """Shows tooltip on hover over process names"""

def __init__(self, parent):
    self.parent = parent
    self.tooltip_window = None

def show(self, event, process_name, tooltip_text):
    """Show tooltip at mouse position"""
    if not tooltip_text:
        return

    self.hide()  # Destroy old tooltip

    # Create borderless window
    self.tooltip_window = tk.Toplevel(self.parent)
    self.tooltip_window.wm_overrideredirect(True)
    self.tooltip_window.wm_attributes("-topmost", True)

    # Position near mouse
    x = event.x_root + 20
    y = event.y_root + 10
    self.tooltip_window.wm_geometry(f"+{x}+{y}")

    # Styled frame + label
    frame = tk.Frame(
        self.tooltip_window,
        bg=THEME["bg_panel"],
        highlightbackground=THEME["accent2"],
        highlightthickness=2,
        padx=12,
        pady=8
    )
    frame.pack()

    label = tk.Label(
        frame,
        text=tooltip_text,
        bg=THEME["bg_panel"],
        fg=THEME["text"],
        font=("Consolas", 9),
        justify="left"
    )
    label.pack()

def hide(self):
    """Destroy tooltip"""
    if self.tooltip_window:
        self.tooltip_window.destroy()
        self.tooltip_window = None`

Positioning logic: +20px right, +10px down from cursor to avoid blocking text.

File 4: panel.py (The Integration)
Location: PC_Workman_HCK/hck_gpt/panel.py
What changed:

Import process library:
`
pythonimport re

try:
from hck_gpt.process_library import process_library
from hck_gpt.tooltip import ProcessTooltip
HAS_PROCESS_LIBRARY = True
except ImportError:
HAS_PROCESS_LIBRARY = False
print("[hck_GPT] Process library not available")

Initialize tooltip in init:

python# Tooltip system
self.tooltip = ProcessTooltip(parent) if HAS_PROCESS_LIBRARY else None

Bind tooltips method:

pythondef _bind_process_tooltips(self):
"""Scan chat text for process names and bind hover events"""
if not HAS_PROCESS_LIBRARY or not self.tooltip:
return

# Get all text
content = self.log.get("1.0", "end-1c")

# Search for .exe patterns
exe_pattern = r'\b\w+\.exe\b'

for match in re.finditer(exe_pattern, content, re.IGNORECASE):
    process_name = match.group(0)

    # Check if process exists in library
    info = process_library.get_process_info(process_name)

    if info:
        # Create unique tag
        tag_name = f"process_{process_name}_{match.start()}"

        # Add tag to text
        # (Tkinter text index conversion logic here)
        self.log.tag_add(tag_name, start_pos, end_pos)

        # Style the tag (underline, color)
        self.log.tag_config(
            tag_name,
            foreground=THEME["accent2"],
            underline=True
        )

        # Bind hover events
        tooltip_text = process_library.format_tooltip_text(process_name)

        self.log.tag_bind(
            tag_name,
            "<Enter>",
            lambda e, pn=process_name, tt=tooltip_text: 
                self.tooltip.show(e, pn, tt)
        )

        self.log.tag_bind(
            tag_name,
            "<Leave>",
            lambda e: self.tooltip.hide()
        )

Call after adding messages:

pythondef add_message(self, msg):
# ... add text to chat
self._bind_process_tooltips() # Scan and bind`
Regex pattern: r'\b\w+.exe\b' matches word boundaries + .exe extension (case-insensitive)
Why unique tags? Same process can appear multiple times in chat — each occurrence needs separate hover binding.

Why This Matters
Before process library:
User: "epicgames.exe is using 40% CPU — is that normal?"
Action: Google → Reddit → forum threads → paranoia → maybe kill process
After process library:
User hovers on epicgames.exe

Epic Games Launcher
Epic Games, Inc.
Game distribution platform. Updates games in background.
Power: Medium-High
Safety: Safe
CPU: 10-40% (during updates)
RAM: 300-800MB

User: "Oh, it's updating games. That's fine."
Result: Informed decision instead of guessing.

This Week's Plan: 3 Issues from Roadmap 1.7.8
Full roadmap: https://github.com/users/HuckleR2003/projects/3/views/2?pane=issue&itemId=166508113&issue=HuckleR2003%7CPC_Workman_HCK%7C17
Total issues to v1.7.8: 17
Selected for this week: 3

Issue #1: Missing tests, discussions, packaging

Source: GitHub issue from Mary-devz (community feedback)
Problem:

No automated tests yet
Need discussion about update mechanisms
Packaging strategy unclear

Plan:

Set up pytest framework
Create test suite for core modules
Discuss auto-update vs manual download strategy
Define packaging requirements for Microsoft Store

Why this matters: Community feedback = roadmap priorities

Issue #2: [UI] Main dashboard button graphics redesign

Source: Own issue
Problem:

Current buttons functional but inconsistent
Need final visual style before Store submission
Button states (normal/hover/active) need polish

Plan:

Finalize button style guide
Redesign primary controls (Start Monitoring, Settings, Reports)
Implement hover animations
Ensure accessibility (contrast ratios, click targets)

Why this matters: UI = first impression for new users

Issue #3: [Code] Optimize hck_gpt/ modules

Source: Own issue
Problem:

Multiple small files in hck_gpt/ folder
Some code duplication
Performance could be better

Plan:

Analyze module dependencies
Consolidate related functionality
Remove duplicate code
Profile performance bottlenecks
Document optimization decisions

Why this matters: Clean code = easier maintenance = faster feature development

Build-in-Public Philosophy
Why share the struggle?
Because "I planned X, did Y" is more valuable than "look at my perfect progress."
Week 1 reality:

Monday: Ambitious plan
Tuesday-Friday: Too tired after Żabka
Saturday-Sunday: Catch-up sprint
Monday: Selective focus on 3 issues

Not shipping everything. Shipping what matters.
The gap between plan and execution = the actual content.

Current State & Goals
Today:

Day job: Żabka retail (20 zł/h, 1-2 months bridge)
Dev time: Weekends + evenings when possible
PC_Workman: v1.7.0 (process library shipped)

This week:

Close 3 issues from roadmap
Build momentum toward v1.7.8

April target:

v1.7.8 feature-complete
All critical issues resolved

Q3 2026:

Microsoft Store submission
Public release v2.0

June-July 2026:

Exit Żabka → Junior dev role

What's Next
Process library expansion:

Target: 150+ definitions by v1.7.8
Community contributions (submit PRs with process definitions)
Auto-categorization for unknown processes (future)

This week deliverables:

Test framework setup + initial tests
UI button redesign completed
hck_gpt/ optimization documented

Long-term vision:

Microsoft Store release
Cross-platform support (Linux, macOS)
Process behavior learning (detect unusual patterns)

Try It Yourself
PC_Workman v1.7.0:

GitHub: https://github.com/HuckleR2003/PC_Workman_HCK
Free, open source, portable .exe
Windows 10/11

Process library:

JSON format (easy to extend)
MIT license
Contributions welcome

GitHub, here :)
All my links here :)

About the Author
I’m Marcin Firmuga. Solo developer and founder of HCK_Labs.

I created PC Workman , an open-source, AI-powered
PC resource monitor
built entirely from scratch on dying hardware during warehouse
shifts in the Netherlands.
This is the first time I’ve given one of my projects a real, dedicated home.

Before this: game translations, PC technician internships, warehouse operations in multiple countries, and countless failed projects I never finished.

But this one? This one stuck.
800+ hours of code. 4 complete UI rebuilds. 16,000 lines deleted.
3 AM all-nighters. Energy drinks and toast.

And finally, an app I wouldn’t close in 5 seconds.
That’s the difference between building and shipping.

PC_Workman is the result.

Friday Shipped & Scarred #1: The Day git --force Deleted 130 PC Workman Commits (I Got 90 Back)

Marcin Firmuga — Fri, 27 Mar 2026 13:03:34 +0000

Friday Shipped & Scarred #1: The Day git --force Deleted 130 Commits (And How I Got 90 Back)

First in a weekly series tracking PC_Workman development. The good, the broken, the lessons learned.

Monday: My Heart Stopped

I ran git push --force on PC_Workman.
130 commits became 1 commit.

Eight months of development history disappeared.
Not the code. The code was fine. But the story was gone.

Every "Fixed memory leak" commit. Every "Rebuilt UI (again)" message. Every timestamp proving this project wasn't slapped together over a weekend.
Gone.

The Panic

First reaction: freeze.
Second reaction: check GitHub.

One commit. Master branch. That's it.
Reflog? Empty.

Old branches? None with the history.

GitHub API endpoints? Nothing recoverable.

I'd read about this happening to others. "Always backup before git surgery" they said.
I didn't backup this time...

The Recovery: An Accidental Save

Then I remembered something.

Three weeks ago, I created an archive branch.

Not for backup. Just to keep old files around for reference. Old UI screenshots. Deprecated features. That kind of thing.

I checked it.

90 commits.

Not the full 130. But 90 commits with complete history dating back months.

The archive had saved me.

What I Lost (And What I Kept)

Lost:

40 commits (most recent work)
Detailed messages about recent bugfixes
Exact timeline of last month's changes

Kept:

90 commits showing project evolution
Proof of 8 months of development
Complete rebuild history (I did 4 complete UI rebuilds - that's documented)

Could have lost:

Everything.

90 out of 130 = 69% recovery rate.

Not perfect. But infinitely better than 1 out of 130.

This Week: Cleaning Up What The Disaster Exposed

The git crisis had a silver lining: it forced me to look closely at the repository.

And I found... problems.

Problem 1: Missing CONTRIBUTING.md

Someone opened an issue: "CONTRIBUTING.md link is broken"
I checked. The file was gone.
Lost in the git chaos. Never recovered from the archive.

Solution: Rewrote it from scratch. Better this time. Clearer guidelines. Actual examples.
Result: Contributor can now actually contribute.

Problem 2: AI-Generated Patterns in README

Last week I posted on Reddit asking why my project looked "AI-generated."
Got brutal, honest feedback:

Empty bullet points (- with no text)
Emoji bullets (everywhere)
AI-style phrasing ("Why it's different" with arrow format)

Solution:

Removed all empty bullets
Removed emoji formatting
Rewrote descriptions in plain English
Added actual technical depth from CHANGELOG

Before:

Monitors your PC
Shows graphs

After:
Real-time CPU, GPU, RAM tracking with historical analysis.
Dashboard loads optimized from 800ms to 200ms through widget reuse pattern.

Specific. Technical. No fluff.

Problem 3: Polish UI Text (In An English Project)

I thought I'd translated everything.
I was wrong.

Found Polish text in:

Status messages ("Ładowanie..." = "Loading...")
Dashboard labels ("Użycie CPU" = "CPU Usage")
Error messages
Placeholder tooltips

Files changed:

ui/windows/main_window.py
ui/windows/main_window_expanded.py
ui/components/fan_dashboard.py
ui/components/sidebar_nav.py
ui/pages/fan_control/usage_stats.py
ui/pages/fan_control/hardware_info.py
6 more files

Time spent: 6 hours
Times I thought I was done: 3
Times I actually was done: 1

Problem 4: Marketing Docstrings

Early code had docstrings like:

def update_dashboard():
    """
    Revolutionary real-time dashboard update system.
    Leverages advanced widget reuse patterns for optimal performance.
    Seamlessly integrates with monitoring engine.
    """
    # ... actual code

Nobody talks like this in real code.

After cleanup:

def update_dashboard():
    """Update dashboard widgets. Reuses existing widgets instead of recreating."""
    # ... actual code

Boring. Accurate. Better.

Removed from:

Main window files
Fan dashboard
All page components

Result: Code reads like code, not a sales pitch.

Problem 5: Guide-AI Repository (Side Project)

While cleaning PC_Workman, noticed Guide-AI repo was stale:

No screenshots (people can't see what it does)
No tags
Outdated description

Fixed:

Added QR code demo screenshots
Added proper GitHub topics (react, supabase, ai, qr-codes)
Rewrote description with actual value prop Not perfect. But visible now.

What Shipped This Week

Repository cleanup:

CONTRIBUTING.md rewritten
README cleanup
12 files Polish -> English translation
Marketing docstrings -> technical docstrings
Guide-AI repo updated

Stats:

90+ commits recovered and visible
0 empty bullet points remaining
0 Polish UI strings remaining
0 "leverages advanced" phrases remaining

What Broke

Git recovery wasn't perfect:

Lost 40 commits
Lost detailed timeline of February changes
Had to manually recreate some documentation

Translation took 3x longer than expected:

Found Polish text in 12 files (thought it was 4)
Each pass found more hidden strings
Final check: found 3 more files

Time management:

Planned: 2 hours for cleanup
Actual: 8 hours across 3 days

Lessons Learned

1. Before ANY risky git operation:

git branch backup-$(date +%Y%m%d)

5 seconds. Could save months.

2. "Clean" code has layers

First pass: obvious issues

Second pass: hidden patterns

Third pass: still finding things

Clean once isn't enough.

3. Accidental backups count as backups

That archive branch saved me.
Wasn't intentional. Still worked.
Lesson: Keep old branches longer than you think necessary.

4. Reddit feedback hurts but helps

Being told your project "looks AI-generated" stings.
But it pushed me to actually clean up the issues.
Feedback <3.

Next Week:

-Monday Blueprint Grind #1
-Wednesday Code Autopsy #2

Topic: Process aggregation - how PC_Workman tracks per-process CPU/RAM usage without destroying performance.

Format: Technical deep-dive into hck_stats_engine/process_aggregator.py

Also coming:

First YouTube Short (Code Autopsy video format)
v1.7.0 planning (TURBO mode research)

The Numbers

PC_Workman current state:

Version: 1.6.8
Commits visible: 90+ (recovered)
Development time: 800+ hours
Next milestone: v2.0 → Microsoft Store (Q3 2026)

This week's time investment:

Git recovery: 2 hours
README cleanup: 1 hour
Code translation: 6 hours
Documentation: 1 hour

Total: 10 hours (planned 4, actual 10)

Try It / Break It / Fix It

PC_Workman is open source. MIT licensed.

GitHub: github.com/HuckleR2003/PC_Workman_HCK

Download: Latest release

Follow the journey:

Building in public. Shipped & Scarred every Friday.

Questions, comments, roasts? Hit me up.

About the Author

I’m Marcin Firmuga. Solo developer and founder of HCK_Labs.

Before this: game translations, PC technician internships, warehouse operations in multiple countries, and countless failed projects I never finished.

But this one? This one stuck.
800+ hours of code. 4 complete UI rebuilds. 16,000 lines deleted.
3 AM all-nighters. Energy drinks and toast.

And finally, an app I wouldn’t close in 5 seconds.
That’s the difference between building and shipping.

PC_Workman is the result.

My first series of Wednesday Code Autopsy! Every wednesday :)

Marcin Firmuga — Wed, 25 Mar 2026 20:23:34 +0000

Marcin Firmuga

Mar 25

Code Autopsy #1: How ~90 Lines Turned System Monitoring Into A Conversation

#python #opensource #buildinpublic #ai

Comments

5 min read

Code Autopsy #1: How ~90 Lines Turned System Monitoring Into A Conversation

Marcin Firmuga — Wed, 25 Mar 2026 16:08:57 +0000

Code Autopsy #1: How 30 Lines Turned System Monitoring Into A Conversation

Part of the PC_Workman build-in-public series. Code Autopsy drops every Wednesday.

The Problem: Numbers Without Answers

You open Task Manager.

"CPU: 87%"

Cool.

But WHY 87%?

Is that normal? Should you worry? What process caused it? When did it start?

Task Manager doesn't answer. HWMonitor doesn't answer. MSI Afterburner doesn't answer.

They show you WHAT is happening. Never WHY.

That's the gap PC_Workman fills.

PC Workman 1.6.8 - hck_GPT in action. Service Setup - quick access to disable useless services, or services what you don't will use (Bluetooth, Print, fax). Today Report - Info about correctly collecting data by sessions. Daily usage averages. And Alerts from suspected spikes/moments by temperatures or voltage.

The Solution: EventDetector

After 800 hours building PC_Workman (most of it on a laptop that peaks at 94°C), I realized: users don't need more data. They need context.

So I built EventDetector.

30 lines of Python that turn monitoring into a conversation.

Here's how it works.

Step 1: Track YOUR Baseline (Not Generic Averages)

Most tools compare against hardcoded thresholds:

"50% CPU is normal"
"60% RAM is high"
"80°C is warm"

Problem: Your normal isn't my normal.

A gaming PC idling at 30% CPU? Normal.

A lightweight laptop idling at 30% CPU? Something's wrong.

EventDetector tracks YOUR baseline from the last 10 minutes:

def _get_baseline(self, now):
    """Get recent baseline averages from minute_stats.
    Cached for 60 seconds to avoid excessive queries.
    """
    cutoff = now - SPIKE_BASELINE_WINDOW  # 10 minutes

    rows = conn.execute("""
        SELECT AVG(cpu_avg) as cpu_avg, 
               AVG(ram_avg) as ram_avg,
               AVG(gpu_avg) as gpu_avg,
               AVG(cpu_temp) as cpu_temp, 
               AVG(gpu_temp) as gpu_temp
        FROM minute_stats
        WHERE timestamp >= ?
    """, (cutoff,)).fetchone()

    return baseline_cache

Key insight: The baseline is YOU. Not everyone. Just you.

PC Workman 1.6.8 - Events detector for hck_GPT insights. Based on long-term monitoring: CPU, GPU, RAM. EventDetector code with highlights on baseline, delta, rate limiting, severity

Step 2: Calculate Delta (Current vs YOUR Normal)

Once we have YOUR baseline, detecting spikes is simple math:

def _check_metric(self, now, metric_name, current_val, 
                  baseline_val, threshold, description):
    """Check if a metric exceeds its threshold above baseline"""

    delta = current_val - baseline_val

    if delta < threshold:
        return  # No spike - you're within YOUR normal range

Example:

Your CPU baseline (last 10 min): 42%
Current CPU: 87%
Delta: +45%
Threshold: 20%

Result: Spike detected. But we're not done yet.

Step 3: Rate Limiting (No Alert Spam)

Early versions of EventDetector had a problem: alert spam.

Chrome spikes CPU every 30 seconds? You'd get 120 alerts per hour.

Useless.

Solution: Rate limiting.

# Rate limiting: {metric_name: last_event_timestamp}
self._last_event_time = {}

def _check_metric(self, ...):
    # ... delta calculation ...

    # Rate limiting
    last_time = self._last_event_time.get(metric_name, 0)
    if now - last_time < SPIKE_COOLDOWN:  # 5 minutes
        return  # Too soon since last alert

    # Log the event
    self._last_event_time[metric_name] = now

Result: Max 1 alert per metric per 5 minutes. No spam.

Step 4: Severity Levels (Critical vs Warning vs Info)

Not all spikes are equal.

CPU spiking 21% above baseline? Worth noting.

CPU spiking 60% above baseline? Drop everything.

EventDetector categorizes:

# Determine severity
if delta >= threshold * 2:
    severity = 'critical'  # 🔴
elif delta >= threshold * 1.5:
    severity = 'warning'   # ⚠️
else:
    severity = 'info'      # ℹ️

Example thresholds:

CPU threshold: 20%
Delta 40%+: Critical
Delta 30%+: Warning
Delta 20-29%: Info

Result: Alerts match urgency.

The Final Output: Context, Not Just Numbers

Here's what you see in PC_Workman when a spike happens:

Before (Task Manager):

CPU: 87%

After (PC_Workman):

⚠️ CPU spike: 87% (baseline: 42%, delta: +45%)
Chrome.exe - started 3 hours ago

Same data. Different story.

One gives you anxiety. The other gives you action.

PC Workman 1.6.8 - My PC - Center of Actions.
STATS & ALERTS - Long term monitoring your components usage, process usage. And mainly time-travel TEMP and Voltages alerts about spikes, or suspected moments. Optimization & Services - For optimize and improve your PC performance. First Setup & Drivers - All for setup your new device/new os. Stability Tests - For check about correctly working of PC Workman and Database check. Your Account-Details - Soon :)

Implementation Notes

Handles 5 Metrics With Same Logic

The beauty of this design: reusable.

Same _check_metric function handles:

CPU usage
RAM usage
GPU usage
CPU temperature
GPU temperature

def check_and_log_spike(self, cpu_avg, ram_avg, gpu_avg,
                        cpu_temp=None, gpu_temp=None):
    baseline = self._get_baseline(now)

    # Check each metric with same logic
    self._check_metric(now, 'cpu', cpu_avg, 
                      baseline['cpu_avg'], 
                      SPIKE_THRESHOLD_CPU, 'CPU usage')

    self._check_metric(now, 'ram', ram_avg, 
                      baseline['ram_avg'],
                      SPIKE_THRESHOLD_RAM, 'RAM usage')

    # ... and so on

Clean. Maintainable. Scalable.

Performance: Cached Baselines

Baseline queries hit SQLite. Could be slow.

Solution: 60-second cache.

if now - self._baseline_cache_time < 60 and self._baseline_cache:
    return self._baseline_cache  # Use cached data

Result: Query once per minute, not once per second.

Storage: SQLite Events Table

All events logged to database:

INSERT INTO events
(timestamp, event_type, severity, metric, value, 
 baseline, process_name, description)
VALUES (?, ?, ?, ?, ?, ?, ?, ?)

Benefits:

Historical tracking (what spiked last week?)
Pattern detection (Chrome spikes every Tuesday?)
Exportable data

What I Learned Building This

1. Users Don't Need More Data

Early versions of PC_Workman showed 20+ metrics.

Users ignored them all.

Lesson: Context, no quantity.

2. Rate Limiting Is User Experience

First version: no rate limiting.

Result: 500 alerts per hour. Unusable.

Lesson: Silence is a feature.

3. Personalization.

"50% CPU is high" works for nobody.

YOUR 50% vs MY 50% = different stories.

Lesson: Baselines must be personal.

PC Workman 1.6.8 - hck_GPT Insights

The Numbers

EventDetector stats:

~30 lines core logic
Handles 5 metrics
Max 1 alert per metric per 5 min
Baseline cached 60 sec
3 severity levels

PC_Workman stats:

800+ hours development
Built on 94°C laptop
v1.6.8 current (v2.0 -> Microsoft Store, Q3 2026)
60+ downloads
17 stars
Open source, MIT licensed

Try It Yourself

PC_Workman is open source.

EventDetector is in hck_stats_engine/events.py.

Download, run, break it, improve it.

GitHub: github.com/HuckleR2003/PC_Workman_HCK
File what I show you: PC_Workman_HCK/hck_stats_engine/events.py

Building in public. Code Autopsy every Wednesday.

Follow the journey:

Twitter: @hck_lab
LinkedIn: Marcin Firmuga
Everything: linktr.ee/marcin_firmuga

Next Week: Wednesday Code Autopsy #2

Topic: ProcessAggregator - how PC_Workman tracks which apps eat your CPU without destroying performance.
See you Wednesday.

Questions? Comments? Roasts? I'm building in public. Feedback welcome.

About the Author

I’m Marcin Firmuga. Solo developer and founder of HCK_Labs.

I created PC Workman , an open-source, AI-powered
PC resource monitor
built entirely from scratch on dying hardware during warehouse
shifts in the Netherlands.

This is the first time I’ve given one of my projects a real, dedicated home.

Before this: game translations, PC technician internships, warehouse operations in multiple countries, and countless failed projects I never finished.

But this one? This one stuck.
800+ hours of code. 4 complete UI rebuilds. 16,000 lines deleted.
3 AM all-nighters. Energy drinks and toast.

And finally, an app I wouldn’t close in 5 seconds.
That’s the difference between building and shipping.

PC_Workman is the result.

PC_Workman: Building a System Monitor for Microsoft Store

Marcin Firmuga — Wed, 18 Mar 2026 00:44:13 +0000

PC_Workman: Building a System Monitor for Microsoft Store

Eight months. 680 hours. 80 downloads.

Now: preparing for Microsoft Store.
Here's what's changing, what's staying, and why the Store matters.

Current State

PC_Workman v1.6.8 shipped February 2026.

Features:

Real-time CPU/GPU/RAM monitoring
AI diagnostics (hck_GPT)
SQLite-backed stats engine
Historical data tracking
Fan curve control

Tech:

Python 3.9+
PyQt5 (UI)
psutil/GPUtil (telemetry)
OpenAI API (AI assistant)

Distribution:

GitHub releases (.exe installer)
Sourceforge listing
80 downloads since January

Problem: Limited discovery.

Most users don't browse GitHub for system monitors.
They search Microsoft Store.

Why Microsoft Store

Discovery:

1+ billion Windows users
Built-in trust (Microsoft verification)
Automatic updates
One-click install

Legitimacy:

No SmartScreen warnings
Code signing included
Privacy policy required (forces transparency)
Age ratings (shows it's vetted)

Competition:
MSI Afterburner, HWMonitor, Core Temp - none on Store.
There's a gap.

v1.7.9 Roadmap (Before Store)

16 features planned March-June 2026.

Core Updates

Auto-update checker

Check GitHub releases on startup
Show banner if newer version exists
User choice: update now or later
No forced updates, no telemetry

Dashboard graphics refresh

New icon set
Purple → blue gradients
Hover animations
Better visual hierarchy

Code optimization pass #2

10-15% line reduction
Better performance (built on 94°C laptop, optimization isn't optional)
Type hints + docstrings
Remove dead code

TURBO BOOST Mode (The Big One)

Research from ASC, Razer Cortex, CCleaner, Wise optimizers.
16 optimization features tested:

Auto RAM flush - Clear standby memory when >75%
Process sleeper - Suspend inactive apps
Service killer - Stop non-essential Windows services
CPU unparking - Unlock parked cores
Power plan switch - Auto "High Performance" mode
Game mode - Windows Game Mode auto-enable
Network optimizer - TCP tweaks, DNS flush
Temp cleaner - Auto cleanup every X hours
SSD trim - Automatic TRIM, defrag only HDD
Startup optimizer - Disable non-essential startup
Real-time tune-up - AI decides what to boost when
Browser cache - Clear without closing browser
Priority manager - Boost game process priority
Auto detection - Detect fullscreen game → trigger boost
Thermal prevention - Kill processes at >85°C
Battery mode - Economy mode on battery

Status: Research phase.
Testing each on dying laptop.
Only features that actually work ship.

Target: v1.7.5 (first 5), v1.7.9 (all 16)

Tab Completions

Finishing placeholder pages:

My PC → Health Report (component diagnostics)
My PC → Cleanup (temp files, logs, cache)
Stability Tests (file integrity, engine status)

v2.0: Microsoft Store Preparation

Technical requirements:

MSIX packaging
- Convert .exe → .appx/msix
- Handle app sandboxing
- Limited file access (Store apps are restricted)
Code signing
- Requires certificate (~$200-400/year)
- Signs app as verified developer
- Removes SmartScreen warnings
Privacy policy
- Required by Store
- PC_Workman doesn't collect data
- Policy explains what's monitored (local only)
Store listing
- 500 char description
- 4-5 screenshots
- High-res icon (1024x1024)
- Category: Utilities & Tools

Challenges:

Cost: Code signing isn't free
Sandboxing: Might break some features (needs testing)
Review time: Can take weeks
Microsoft cut: Store takes % of sales (PC_Workman is free, so irrelevant)

Alternative:

Sideload MSIX (users install without Store)
GitHub releases remain primary
Store as secondary discovery channel

What Changes (And What Doesn't)

Changing:

Distribution (GitHub + Store)
Package format (.exe → MSIX)
Update mechanism (Store handles it)
Code signing (required)

NOT changing:

Free and open source (MIT license stays)
No data collection (privacy-first)
Core features (monitoring, AI, TURBO)
GitHub development (Store is just distribution)

Timeline

March 2026: v1.7.0-1.7.3
- Auto-update
- Dashboard refresh
- Code optimization

April-May: v1.7.4-1.7.6
- TURBO features (wave 1)
- Tab completions

June: v1.7.7-1.7.9
- TURBO complete (all 16 features)
- Final optimization
- Code freeze

Q3 2026: v2.0
- MSIX packaging
- Microsoft Store submission
- Local AI integration (Ollama/LM Studio)

Not promises. Goals.
Things break. Laptops die. Life happens.

Why I'm Building This

Nine months in Netherlands warehouse.
15km daily. Scanning barcodes.
Lost job December 22.

Started rebuild #4 that night.
Shipped first .exe three weeks later.

Not talent. Stubbornness.

PC_Workman exists because:

MSI Afterburner shows "CPU: 87%" - doesn't explain WHY
HWMonitor logs data - doesn't help you optimize
Task Manager is reactive - not proactive

Needed tool that EXPLAINS, not just SHOWS.
Built on 94°C laptop.
Optimized for real-world constraints.

Microsoft Store = next step in making it accessible.

Follow Development

GitHub: click!
Roadmap: click
Twitter: hck_lab
LinkedIn: here

KO-FI ❤ — Coffe?

Let's build.

Marcin Firmuga | Warehouse worker -> Indie developer | Building in public

Just an great steps :) 8 months of unstoppable working. Full build in public. Income? 0$ but don't care

Marcin Firmuga — Mon, 23 Feb 2026 11:30:26 +0000

PC_Workman 1.6.8: When "Quick Fix" Took 3 Weeks (Data Engine + AI Context + 70% Performance)

Marcin Firmuga ・ Feb 22

#python #opensource #buildinpublic #showdev

PC_Workman 1.6.8: When "Quick Fix" Took 3 Weeks (Data Engine + AI Context + 70% Performance)

Marcin Firmuga — Sun, 22 Feb 2026 23:00:36 +0000

PC_Workman 1.6.8: When "Quick Fix" Became the Biggest Update Since Alpha

How I rebuilt the data engine, added AI context awareness, gained 70% performance, and learned that scope creep isn't always bad

// Marcin Firmuga | Solo Developer | HCK_Labs

Version 1.6.8 wasn't supposed to be this big.

The plan was simple: fix the temporary chart system that couldn't show historical data. Maybe two days of work. Update the changelog. Push to testers. Done.

Three weeks later, I'd rebuilt the entire data aggregation engine, added context-aware AI that learns your patterns, optimized performance by 70%, fixed two critical bugs, polished the UI, and deleted 500+ lines of dead code.

This is that story. Technical deep-dive, honest struggles, lessons learned. The works.

The Problem That Started Everything

PC_Workman alpha shipped in January. Seven testers across different hardware. Bug reports coming in. Most were small - UI glitches, missing labels, the usual polish stuff.

Then one tester asked: "Can I see what happened yesterday? Like, what was eating CPU at 3 PM?"

No. The app couldn't do that.

Why? Because I'd built the chart system using temporary in-memory data structures. Great for showing "right now." Terrible for "what about three hours ago."

The charts were literally fake. Placeholder data that looked good in screenshots but had no historical persistence. Classic MVP shortcut that became a blocker.

I could've dismissed it. "Alpha feature, coming later." But the request made sense. A system monitor that can't look back in time isn't really monitoring - it's just displaying the present.

So I decided to fix it. "Two days," I told myself. "Build proper data persistence, hook it to the charts, done."

I was wrong about the timeline. But right about needing to fix it.

Building HCK_STATS_ENGINE: The Data Foundation

The core problem: how do you store months of system telemetry without killing the database?

PC_Workman collects data every second. CPU usage, RAM, GPU, temperatures, processes, everything. That's 86,400 data points per day per metric. Multiply by 10-20 metrics. That's nearly 2 million rows per day if you're naive about it.

SQLite can handle that, but querying becomes slow. And I was building this on a 2014 laptop that hits 94°C under load. Can't afford bloat.

The Aggregation Pipeline

The solution: in-memory accumulation + tiered aggregation.

Here's how it works:

Level 1: In-Memory Accumulator

# Structure: {(hour_timestamp, process_name): {metrics}}
accumulator = {
    (1738368000, "chrome.exe"): {
        "cpu_sum": 245.3,      # Total CPU seconds
        "cpu_max": 45.2,       # Peak usage
        "ram_sum": 1024000,    # Total RAM bytes
        "count": 3600,         # Sample count
        "active_secs": 3543    # Seconds active
    }
}

Every second, accumulate_second() updates the dict. Lightweight. Just dict operations. No I/O.

Level 2: Hourly Flush

def flush_hourly_processes():
    # At hour boundary (00:00, 01:00, etc.)
    # Write accumulator → process_hourly_stats table
    # Clear accumulator
    # If crash mid-write → transaction rollback, data safe

Level 3: Daily Aggregation

def aggregate_daily_processes():
    # At day boundary (midnight)
    # Sum hourly stats → process_daily_stats
    # Keep hourly data for 7 days
    # Keep daily data forever (or until disk full)

Result: Real historical data. Queryable. Fast. Safe.

Stability First

The engine runs on the scheduler thread. Separate from UI. Every operation wrapped in try/except. If SQLite fails (disk full, permission issue, cosmic ray), the app doesn't crash. It falls back to CSV logging like before.

try:
    db.execute(query, params)
    db.commit()
except sqlite3.Error as e:
    logger.error(f"Stats engine failed: {e}")
    fallback_to_csv(data)  # App still works

Why this matters: System monitoring tools can't afford to crash. If your monitoring crashes, you're blind. So we built defense in depth:

WAL mode (write-ahead logging) - concurrent reads/writes
Atomic transactions (crash-safe)
Graceful degradation (SQLite fail → CSV works)
No new dependencies (sqlite3 is Python stdlib)

Files added:

hck_stats_engine/constants.py - config, table schemas
hck_stats_engine/db_manager.py - connection pooling, migrations
hck_stats_engine/aggregator.py - core aggregation logic
hck_stats_engine/process_aggregator.py - process-specific stats
hck_stats_engine/query_api.py - read interface for UI
hck_stats_engine/events.py - anomaly detection hooks

Six new files. ~1,200 lines of code. But now the charts show real data going back weeks.

Making AI Actually Intelligent

While building the data engine, I kept opening hck_GPT (the AI assistant panel) for testing. Every time, it greeted me the same way:

"Hello! I'm hck_GPT, your PC companion. How can I help?"

Static. Boring. Useless.

I'd just implemented a system that knows everything about the computer's behavior. CPU spikes. Heavy apps. Gaming sessions. Work patterns. And the AI assistant was ignoring all of it.

That felt wrong. So I fixed it.

Context Awareness: InsightsEngine

The breakthrough was realizing: timing matters more than data.

It's not enough to know Chrome used 40% CPU. You need to know:

When? (During work hours? Gaming time?)
Context? (Is this normal for this time of day?)
Pattern? (Does this happen every Tuesday at 3 PM?)
Action? (Should I suggest closing tabs? Or is this expected?)

Enter InsightsEngine - 300 lines of pattern recognition and contextual intelligence.

What it does:

1. Time-aware greetings:

def get_greeting(self):
    hour = datetime.now().hour

    if hour < 12:
        return "Morning. Coffee loaded? CPU looking good at 8%."
    elif hour < 17:
        return "Afternoon. RAM at 52%, up from morning. Chrome again?"
    else:
        # Evening - check for gaming patterns
        if self._detect_game_pattern():
            return "Evening. Ready for another round of Battlefield? GPU warmed up."
        return "Evening. System's quiet. 12% CPU, 45% RAM."

2. Real-time spike detection:

def detect_spike(self, metric, current_value):
    # Get 7-day baseline
    baseline = self._get_baseline(metric)
    threshold = baseline * 1.5  # 50% above normal

    if current_value > threshold:
        # Find cause
        heavy_process = self._get_top_process(metric)
        return f"{metric.upper()} SPIKE: {current_value}% (normal: {baseline}%). {heavy_process} is the cause."

3. Process categorization:

CATEGORIES = {
    "gaming": ["battlefield", "cod", "cyberpunk", "steam"],
    "browser": ["chrome", "firefox", "edge"],
    "dev_tools": ["vscode", "pycharm", "docker", "node"]
}

def categorize_process(name):
    for category, keywords in CATEGORIES.items():
        if any(kw in name.lower() for kw in keywords):
            return category
    return "system"

4. Pattern learning (7-day habit tracking):

def get_teaser(self):
    # Evening gaming pattern detected
    if self._is_evening() and self._played_game_last_3_days("battlefield"):
        return "Ready for another round of Battlefield? GPU's warmed up."

    # Morning work pattern
    if self._is_morning() and self._opened_vscode_last_5_days():
        return "VS Code from yesterday still open. Pick up where you left off?"

UI Integration

The panel now:

Opens with context:

Morning: mentions coffee, shows overnight stats
Afternoon: references morning activity
Evening: suggests gaming if pattern detected

Dynamic banner:

Normal: "CPU 12% | RAM 45% | All quiet"
Spike: "CPU 87% SPIKE | Chrome (3.2GB RAM)"
Gaming: "Battlefield running | GPU 78%"

New commands:

stats - 7-day habit summary
alerts - anomaly report (24h)
insights - what's notable right now
teaser - proactive suggestion based on patterns

Color-coded reports (directly in chat, no separate window):

CPU values: red
GPU values: blue
RAM values: yellow
Category badges: [Gaming] red, [Browser] blue, [Development] green
Alert status: yellow banner

The Difference

Before:

User: "What's using CPU?"

hck_GPT: "Chrome is using 42% CPU."

After:

[Auto-greeting at 7 PM]

hck_GPT: "Evening. Battlefield pattern detected - last 3 nights, 7-10 PM. GPU ready at 45°C. RAM at 54%, up from afternoon (Chrome still open with 15 tabs)."

That's intelligence. Not just answering questions. Anticipating needs based on learned patterns.

The Performance Crisis Nobody Saw

While testing the new data engine and AI context, I noticed something embarrassing:

PC_Workman was using 15-20% CPU.

A system monitoring tool. That monitors CPU usage. Was itself eating 15-20% CPU.

The irony wasn't lost on me.

Finding the Bottlenecks

I profiled the app. The culprits:

1. Main loop cadence: 300ms

UI updated every 0.3 seconds
200 updates/minute
Unnecessary for human perception

Solution: 1000ms (1 second)

Still smooth
70% less overhead
Nobody notices the difference

2. Widget destruction hell:

# Old way (every 2 seconds):
for widget in top5_panel.winfo_children():
    widget.destroy()  # Expensive!

for process in top_processes:
    create_new_widget(process)  # More expensive!

Destroying and recreating 5 widgets every 2 seconds = memory fragmentation + CPU waste.

Solution: Widget pooling

# New way:
if not self.process_widgets:
    # First time: create 5 reusable widgets
    self.process_widgets = [create_widget() for _ in range(5)]

# Every update: just update text
for widget, process in zip(self.process_widgets, top_processes):
    widget.config(text=process.name, cpu=process.cpu)

Reuse > recreate. Performance improved by orders of magnitude.

3. Redundant syscalls:

# Old way (every update):
cpu_count = psutil.cpu_count()  # Why call this every second?
total_ram = psutil.virtual_memory().total  # This never changes!

Hardware doesn't change at runtime. Cache it once at startup.

# New way:
class HardwareConstants:
    CPU_COUNT = psutil.cpu_count()  # Once
    TOTAL_RAM = psutil.virtual_memory().total  # Once

    @classmethod
    def get_cpu_percent_per_core(cls):
        return 100 / cls.CPU_COUNT

4. Chart rendering nightmare:

The old chart system used PhotoImage pixel manipulation:

# Old: ~70,000 iterations per frame
for x in range(width):
    for y in range(height):
        if should_draw_pixel(x, y):
            img.put(color, (x, y))  # Slowwww

Solution: Canvas object reuse

# New: Create objects once
self.chart_lines = [
    canvas.create_line(0, 0, 0, 0, fill="red", width=2)
    for _ in range(num_datapoints)
]

# Update: Just move coordinates
for i, (line, point) in enumerate(zip(self.chart_lines, datapoints)):
    canvas.coords(line, x1, y1, x2, y2)  # Fast!

Orders of magnitude faster. Literally.

5. UI thread blocking:

Heavy telemetry collection (iterating 200+ processes) was blocking the UI thread.

Solution: Background daemon

# Startup: Launch background thread
telemetry_thread = threading.Thread(
    target=collect_telemetry_loop,
    daemon=True  # Dies with main app
)
telemetry_thread.start()

# UI thread: Just read snapshot (non-blocking)
def update_ui():
    snapshot = telemetry.read_snapshot()  # Instant
    render_data(snapshot)

No more drag lag. No more freezes.

Results

Before:

Main loop: 300ms
CPU usage: 15-20%
Chart updates: laggy
Widget updates: memory spikes

After:

Main loop: 1000ms (70% reduction)
CPU usage: 3-5% (75% improvement)
Chart updates: smooth
Widget updates: stable memory

The lesson: Building on a dying 94°C laptop forced optimization thinking. Constraints = innovation.

Bug Fixes Nobody Sees (But Everyone Benefits From)

Two critical bugs fixed in 1.6.8. Not sexy. But important.

Bug A: Data Aggregation Overlap

Problem: get_summary_stats() was double-counting data.

When computing "lifetime uptime," it would:

Sum daily stats (past days)
Sum hourly stats (today)
Sum minute stats (current hour)

But hourly stats include minute stats. And daily stats include hourly stats. Double-counting everywhere.

Result: Lifetime uptime showed 847 hours when real time was 423 hours.

Fix: Multi-tier fallback with overlap prevention:

def get_summary_stats():
    # Layer 1: Daily (complete days only)
    daily_sum = sum(daily_stats[:-1])  # Exclude today

    # Layer 2: Hourly (today, complete hours only)
    hourly_sum = sum(hourly_stats[:-1])  # Exclude current hour

    # Layer 3: Minute (current hour, real-time)
    minute_sum = sum(minute_stats)

    # No overlap: daily + hourly + minute = accurate
    return daily_sum + hourly_sum + minute_sum

Now lifetime uptime is accurate from the first session.

Bug B: System Noise Pollution

Problem: System processes triggering false alerts.

"System Idle Process" would show 800% CPU (8 cores * 100% idle). "Memory Compression" would spike to 90% RAM during compaction. "Interrupts" would randomly hit 1000% (kernel threads).

These aren't problems. They're normal system behavior. But InsightsEngine was treating them as anomalies.

Fix: Strict filtering at multiple layers:

Layer 1: Telemetry (process_aggregator.py)

SYSTEM_NOISE = [
    "system idle process",
    "system interrupts", 
    "memory compression",
    "registry",
    "dwm.exe"  # Desktop Window Manager
]

def is_system_noise(process_name):
    return any(noise in process_name.lower() 
               for noise in SYSTEM_NOISE)

Layer 2: Insights (InsightsEngine)

def _is_system_noise(self, process_name):
    # Additional filter for user-facing alerts
    if is_system_noise(process_name):
        return True

    # Cap at 100% per process (prevent overflow display)
    if process_cpu > 100:
        process_cpu = min(process_cpu, 100)

    return False

Result: Clean telemetry. No false alerts. Accurate health checks.

Polish: The Details That Matter

Big features get headlines. Polish gets ignored. But polish is what makes software feel professional vs amateur.

UI Refinements

Info Section redesign:

Height: 50px (compact, not cramped)
Accent color: #a78bfa (purple, not blue)
Font: Consolas (mono, technical readability)
Typewriter animation: 70ms typing, 3-char burst deletion, longer hold time

Why Consolas? Monospaced fonts make numbers align. "CPU: 8%" lines up with "RAM: 64%" visually. Small detail. Huge readability improvement.

Dashboard-only updates:

def _update_hardware_cards(self):
    if self.current_view != "dashboard":
        return  # Don't update if not visible

Eliminates errors from updating widgets that don't exist. Defensive coding.

winfo_exists() guards everywhere:

def _update_widget(self, widget):
    if not widget.winfo_exists():
        return  # Widget destroyed, skip update

Prevents crashes when closing panels mid-update.

Cleanup: Less Is More

Deleted:

60 LOC: _animate_button_shimmer() (CPU overhead, nobody noticed)
3 modules: file_utils, net_utils, system_info (unused)
1 component: ExpandableProcessList (replaced by widget pooling)
settings/ directory (obsolete configs)
System artifacts: _nul, nul (Windows junk)

Why cleanup matters:

Faster builds (less to compile)
Less cognitive overhead (fewer files to track)
Maintainability (obvious what's actually used)

The philosophy: Every line of code is a liability. If it's not pulling weight, delete it.

Lessons Learned (The Real Value)

1.6.8 taught me more than any previous update. Here's what stuck:

1. Scope Creep Can Be Good

Started with: Fix chart data persistence.

Ended with: New data engine + AI context + 70% performance + bug fixes + polish.

Lesson: Sometimes the "quick fix" reveals deeper problems. Don't fight the scope creep if it's making the product better. Just communicate the timeline honestly.

2. Constraints Force Innovation

Building on a 94°C laptop isn't ideal. But it forced me to optimize obsessively. Widget pooling, background threading, canvas reuse - these weren't optional. They were necessary.

Lesson: Constraints aren't obstacles. They're forcing functions for creativity. Unlimited resources = lazy solutions.

3. Context > Features

hck_GPT gained intelligence not from more features, but from using existing data contextually. Time-of-day + process patterns + user habits = proactive assistant.

Lesson: Before adding features, ask: "Am I using existing data optimally?" Context multiplies value without adding complexity.

4. Measure, Then Optimize

I guessed the main loop was slow. Profiling showed widget destruction was the real bottleneck. Guessing = wasted effort. Measuring = targeted fixes.

Lesson: Profile first. Optimize second. Never guess.

5. Stability Is a Feature

Try/except everywhere. Graceful degradation. Defensive coding. These aren't "nice to haves." They're the difference between a tool people trust vs one they uninstall after the first crash.

Lesson: System monitoring tools can't afford to crash. Build defense in depth.

6. Real Users = Real Priorities

The "show me yesterday's data" request came from a tester. Not from my roadmap. But it was the right priority.

Lesson: Ship early. Listen closely. Real feedback > imagined use cases.

7. Technical Debt Compounds

Temporary charts were a 2-hour shortcut to ship alpha. Fixing them properly took 3 weeks. The 2-hour shortcut cost 21 days later.

Lesson: Pay tech debt early. It only gets more expensive.

What's Next

1.6.8 is live for testers now. Two-week stability testing window. Collecting feedback. Handling bug reports (same-day turnaround).

Coming in future updates:

InsightsEngine v2:

Deeper pattern learning (monthly trends, not just weekly)
Predictive suggestions ("Battlefield usually crashes after 2h, save your game")
Anomaly alerts (SMS/email when system spikes while you're away)

Cross-platform:

macOS support (different syscalls, same architecture)
Linux support (easier than macOS, tbh)

Plugin system:

Community extensions
Custom metrics (track your own apps)
Share configs (gaming profile, work profile, etc.)

Mobile companion:

View stats remotely
Get alerts on phone
Start/stop monitoring

But first: Stability. Performance. Polish. The boring work that makes software reliable.

Try It Yourself

PC_Workman is open source. Free forever. MIT license.

GitHub: github.com/HuckleR2003/PC_Workman_HCK
It would be perfect, when you send me star!

Download: Alpha available on GitHub Releases + SourceForge

System requirements:

Windows 10/11 (macOS/Linux coming)
Python 3.9+ (if running from source)
.exe available (no Python needed)

Verified security:

VirusTotal scanned (70 engines, clean)
Sigstore signed (cryptographic proof of authenticity)
CodeQL analyzed (GitHub security scanning)

Want to contribute?

Bug reports: GitHub Issues
Feature requests: GitHub Discussions
Code: Pull requests welcome

Follow the build-in-public journey:

Twitter/X: Updates, screenshots, lessons
Medium: Long-form technical articles
Dev.to: Tutorials, deep-dives
Hashnode: Build-in-public series

The Real Story

1.6.8 wasn't planned. It emerged from fixing one thing, discovering another, and following the thread.

Started: "Fix charts in 2 days"

Ended: "Rebuilt data engine, added AI intelligence, gained 70% performance in 3 weeks"

Was it scope creep? Yes.
Was it worth it? Absolutely.

This is what building in public looks like. Not the polished "I had a vision" narrative. The messy "I found a bug, then another, then realized the whole system needed rethinking" reality.

PC_Workman is better because I didn't stick to the plan. I followed the problems to their root and fixed them properly.

Next update might be small. Might be huge. Don't know yet. That's the fun part.

Stack: Python 3.9, PyQt5, SQLite (WAL mode), psutil, Threading, Canvas rendering

Development time: 3 weeks (estimated 2 days, lol)
Lines added: ~1,500
Lines deleted: ~500
Laptop temperature during build: Still 94°C, still alive
Coffee consumed: Too much
Lessons learned: Infinite

Building PC_Workman on a dying laptop between warehouse shifts. Documenting everything. Shipping weekly. This is update 1.6.8.

About the Author
Marcin Firmuga | Solo Developer | HCK_Labs Founder

I built PC_Workman from scratch on dying hardware during warehouse shifts in the Netherlands.

Before this:

Game translations for Polish communities
IT technician internships (2 months, 2022)
Warehouse operations (Poland, Netherlands, multiple contracts)
Twelve failed projects (all quit at 70–85%)
But this one stuck.

680+ hours of code. 4 complete UI rebuilds. 16,000 lines deleted. 3 AM sessions. Energy drinks and toast #7.

And finally: an app I wouldn’t close in 5 seconds.
That’s the difference between building and shipping.

PC_Workman is the result.
Currently: Searching for first tech role while building in public.

Warehouse to Developer | Building Despite Everything | HCK_Labs

If you want to be first person, who support me:
IM HERE <3 - CLICK

How to Sign Your Python .exe With Sigstore (No Certificate Required)

Marcin Firmuga — Sun, 15 Feb 2026 19:48:32 +0000

How to Sign Your Python .exe With Sigstore (No Certificate Required)

The problem: You built an open-source app. Users download your .exe. How do they know it's actually from you and hasn't been tampered with?

Traditional solution: Buy a code signing certificate. Cost: $200-400/year.

Better solution: Sigstore. Free, open source, cryptographically secure.

This is how I sign every PC_Workman release. Takes 8 minutes to set up, 30 seconds per release.

Why This Matters

Someone could:

Clone your GitHub repo
Add malware to your code
Compile a fake .exe
Distribute it claiming it's yours

Users have no way to verify authenticity without code signing.

Sigstore solves this:

✅ Proves the file came from your GitHub account
✅ Proves it hasn't been modified since signing
✅ Provides cryptographic proof anyone can verify
✅ Completely free

Want to Star? <3

What You'll Need

Python project compiled to .exe (PyInstaller, Nuitka, etc.)
GitHub account
8 minutes

That's it. No credit card, no certificate purchase, no annual fees.

Step 1: Install Sigstore

pip install sigstore

That's the entire installation. Sigstore is a Python package.

Verify installation:

sigstore --version

Expected output: sigstore, version X.X.X

Step 2: Generate GitHub Token

Sigstore authenticates via GitHub OAuth, but you need a token first.

GitHub → Settings → Developer settings → Personal access tokens → Tokens (classic)

Click "Generate new token (classic)"

Required scopes:

✅ read:user
✅ user:email

Token expiration: Set to "No expiration" (for ongoing releases)

Copy the token. You'll only see it once.

Store it securely:

Linux/Mac

export GITHUB_TOKEN="your_token_here"

Windows (PowerShell)

$env:GITHUB_TOKEN="your_token_here"

Or save in password manager and paste when needed.

Step 3: Sign Your .exe

Navigate to your release directory:

cd /path/to/your/releases

Sign the file:

sigstore sign \
--bundle sigstore-bundle.json \
PC_Workman_HCK.exe

Replace PC_Workman_HCK.exe with your filename.

What happens:

Sigstore opens browser for GitHub OAuth
You authorize the app
Sigstore generates cryptographic signature
Creates sigstore-bundle.json (the signature file)

Time: ~30 seconds

Output files:

PC_Workman_HCK.exe (unchanged)
sigstore-bundle.json (signature proof)

Step 4: Upload Both Files to GitHub Release

When creating a GitHub release:

Files to include:

PC_Workman_HCK.exe (your executable)
sigstore-bundle.json (signature)
VERIFICATION.md (instructions for users - see below)

Example release structure:
PC_Workman_v1.6.4/
├── PC_Workman_HCK.exe
├── sigstore-bundle.json
├── VERIFICATION.md
└── README.md

Step 5: Create Verification Instructions for Users

Create VERIFICATION.md in your release:

Verifying This Release

Install Sigstore

pip install sigstore

Verify Signature

sigstore verify github PC_Workman_HCK.exe \
--bundle sigstore-bundle.json \
--cert-identity https://github.com/YourUsername

Expected Output

Signature verified successfully

What This Proves

✅ File came from @YourUsername GitHub account
✅ File hasn't been modified since signing
✅ Signing happened on [date]

Replace YourUsername with your actual GitHub username.

How Verification Works (User Side)

Your users run:
sigstore verify github your-app.exe \
--bundle sigstore-bundle.json \
--cert-identity https://github.com/YourUsername

Sigstore checks:

Certificate identity: Does the signature match the claimed GitHub account?
Integrity: Has the file been modified since signing?
Timestamp: When was this signed?

Success output:
Verified OK: PC_Workman_HCK.exe

Failure output:
Verification failed: signature invalid

No trust required. Pure cryptography.

Real-World Example: PC_Workman

Every PC_Workman release includes:

The executable (PC_Workman_HCK.exe)
Sigstore bundle (sigstore-bundle.json)
Security report (VirusTotal scan results)
Verification guide (how to verify)

My release checklist:

1. Build executable

pyinstaller main.py

2. Sign with Sigstore

sigstore sign --bundle sigstore-bundle.json dist/PC_Workman_HCK.exe

3. Scan on VirusTotal

(manual upload to virustotal.com)

4. Create GitHub release

Upload: .exe + bundle + security report

5. Update documentation

Link to verification guide

Time per release: 5-10 minutes total.

Beyond Basic Signing

Automated Signing in CI/CD

You can integrate Sigstore into GitHub Actions:
name: Release

on:
release:
types: [created]

jobs:
sign-release:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3

  - name: Install Sigstore
    run: pip install sigstore

  - name: Sign executable
    run: |
      sigstore sign \
        --bundle sigstore-bundle.json \
        dist/your-app.exe
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

  - name: Upload signed files
    uses: actions/upload-artifact@v3
    with:
      name: signed-release
      path: |
        dist/your-app.exe
        sigstore-bundle.json

Result: Every release = automatically signed.

Adding More Trust Signals

Sigstore proves the file came from your GitHub. But how do users know YOU'RE legitimate?

1. ORCID iD (Persistent Identity)

Persistent digital identity for researchers/developers
Link to GitHub profile
Proves you're a real person

2. GitHub Developer Program

Apply at github.com/developer

Shows commitment to open source
Requires public profile + active projects
Free membership

3. OpenSSF Best Practices Badge

Apply at bestpractices.coreinfrastructure.org

60+ security criteria
Comprehensive security audit
Industry-recognized badge

Together: These create a web of trust.

Common Issues & Fixes

"GitHub OAuth failed"

Solution: Check your GitHub token has read:user and user:email scopes.

"Bundle file not found"

Solution: Make sure --bundle filename matches what you upload to releases.

"Verification failed: certificate identity mismatch"

Solution: --cert-identity must match exact GitHub URL. Use https://github.com/YourUsername, not github.com/YourUsername.

"Command not found: sigstore"

Solution: Activate the Python environment where you installed Sigstore, or install globally.

Why I Actually Did This

I was tired of people asking "how do I know this is safe?"

Not because they're paranoid. Because they're smart. Running .exe files from unknown people IS risky.

Sigstore gives users the option to verify. No blind trust required. Just math.

Setup time: 8 minutes

Per-release time: 30 seconds

Cost: $0

User confidence: Significantly improved

Worth it.

The Complete Security Stack

For PC_Workman, I combine:

VirusTotal scanning (70 antivirus engines) - Part 1 article
Sigstore signing (this article)
CodeQL analysis (GitHub security scanning)
OpenSSF Best Practices (working toward badge) - Part 3 coming soon

None of this prevents bugs. None of it proves bug-free code.

But it proves I'm serious about security and transparency.

Users can verify for themselves. That's what matters.

Try It Yourself

5-minute challenge:

Install Sigstore: pip install sigstore
Create a test file: echo "test" > test.txt
Sign it: sigstore sign --bundle test-bundle.json test.txt
Verify it: sigstore verify github test.txt --bundle test-bundle.json --cert-identity https://github.com/YourUsername

You just cryptographically signed your first file.

Now apply this to your actual releases.

Resources

Official Sigstore docs: docs.sigstore.dev

GitHub integration guide: GitHub + Sigstore

PC_Workman releases (examples): GitHub Releases

Questions? Drop them below. I'll answer every one.

About This Series

This is Part 2 of 3 in the PC_Workman Security Series:

Part 1: VirusTotal Scanning & CodeQL Analysis (link when published on Dev.to)
Part 2: Sigstore Signing (this article)
Part 3: OpenSSF Best Practices Badge (coming soon)

About Me

I'm Marcin, solo developer building PC_Workman — an open-source system monitoring tool.

Built on a dying 2014 laptop during warehouse shifts in the Netherlands. 700+ hours, 4 complete rebuilds, finally shipped.

Follow my build-in-public journey:

GitHub: @HuckleR2003
Twitter: https://x.com/hck_lab
Everything about me: https://linktr.ee/marcin_firmuga

Building in public. Documenting everything. Shipping weekly.

sigstore #python #security #opensource #buildinpublic

How I built an AI Manual Assistant between warehouse shifts (and why it hallucinated about charcoal)

Marcin Firmuga — Thu, 05 Feb 2026 12:50:03 +0000

Marcin Firmuga - 22 years (Poland)

The physical world is still stuck in the 90s.

I spend my days picking orders in a warehouse, surrounded by machinery and heavy boxes. But my nights belong to my laptop.
For the past few months, I’ve been obsessed with one question:

Why are we still using 100-page paper manuals in 2026?

I decided to fix this by building GuideAI :)

The Concept

The idea is simple:

Upload a PDF manual.
AI parses the data into a knowledge base.
Generate a QR code for the physical device. *Scan and chat with the machine in plain English or Polish. *

The "Charcoal" Incident (Hallucinations are real)

While stress-testing the logic with Llama 3 (via Groq),
I asked the assistant how to fix a modern Beko washing machine.

The AI confidently told me to "refill the charcoal tray" and check for soot buildup. Apparently, my LLM thought I was living in the 19th century.

This taught me a huge lesson:
Garbage in, garbage out. Fine-tuning the RAG (Retrieval-Augmented Generation) and switching to more precise models like GPT-4o-mini became my top priority to ensure users don't start putting BBQ briquettes in their laundry rooms.

The Stack

As a solo dev, I had to choose a stack that lets me move fast:
Frontend: React + Tailwind CSS.
Backend/Auth: Supabase **
(Recently finished a deep dive into Google OAuth and RLS).
**AI Pipeline: Groq (for speed) and OpenAI (for precision).
Deployment: Vercel.

I've spent over 700 hours on my projects, deleted >20,000 lines of code. It was brutal, but for the first time,
I have a product that actually ships.
(payment is still not configured :) )

Where it stands now

The MVP is live at
https://guide-ai-gold.vercel.app/#

Full Dashboard: Manage your "fleet" of devices.

Scan Analytics: See how many times people actually scanned your QR.

GDPR Ready: Just finished the Terms and Privacy pages to make it "official."

I need your "Dev" eyes

I’m looking for fellow builders to:
Try to break the AI: Upload a weird manual and see if it still talks about coal.
UX Review: Does the QR-to-Mobile flow feel smooth?

Roast my stack: Is there a better way to handle the PDF-to-Knowledge-Base pipeline?

I’m building this in public as HCK_Labs. From the warehouse floor to the cloud—it’s been a wild ride.

Check it out: GuideAI

And... If you want to be my first $1 after months of work :)
I'm and my socials is here. THANKS YOU MATE :)
https://linktr.ee/marcin_firmuga

About the Author

I’m Marcin Firmuga. Solo developer and founder of HCK_Labs.

My journey started with PC Workman, an open-source, AI-powered PC resource monitor built entirely from scratch on dying hardware during warehouse shifts in the Netherlands.
It was the first time I gave my code a real home.

Before this: game translations, PC technician internships, warehouse operations in multiple countries, and countless failed projects. But something changed. I stopped just building; I started shipping.

After 700+ hours of code on my previous tools, GuideAI is my next big step. It’s the result of the same 3 AM all-nighters, energy drinks, and the refusal to let “good enough” be the end. I’m still the guy from the warehouse, but now I’m making the physical world talk.

BuildInPublic #IndieDev #SaaS #AI #HCK_Labs #GuideAI

Forem: Marcin Firmuga

Wednesday Code Autopsy #4: The Canvas Arc Nobody Uses - PC Workman

The Problem

The Discovery

The Solution

How It Works

The Geometry

The Angles

The Secret Third Style

The Production Implementation

The Math

Color Grading

The Scanning State

Copyable Minimal Example

Why This Matters

The Bigger Lesson

What's Next

Your Turn

Links

PC Workman v1.7.2: I Built a Driver Booster Competitor From Scratch, Fixes. Monday Grind Blueprint #3

1. hck_GPT Time Badges — The Small Feature That Took Months to Actually Do

The Interesting Part

2. Process Library — From "Unknown" to "Oh, That's What You Are"

Tooltips Everywhere, Not Just in Chat

3. First Setup & Drivers — Building a Driver Booster From Scratch

Reading Drivers From the Windows Registry

The Date Format Problem

Health Score — Computed, Not Faked

Quick Actions

The Architecture Bit

4. The Bug Nobody Noticed

5. The Scars

What's Coming — The Week Plan (v1.7.2 → v1.7.4)

Dashboard Button Redesign

System Cleanup Utilities

Complete "My PC" Health Tab

TURBO — Auto RAM Flush

The Numbers

The Bigger Picture

Friday Shipped & Scarred #3: PC Workman 1.7.1, The Foundation Great Release

The Plan vs The Reality

Dead Code Archaeology

Example: main_window_expanded.py

Example: core/monitor.py

Example: requirements.txt

Test Suite Rewrite: From Broken to Verified

Before (test_monitor.py):

After (test_monitor.py):

Test Coverage Summary

test_monitor.py (7 cases)

test_analyzer.py (7 cases)

test_avg_calculator.py (4 cases)

UI Component: AnimatedBar

Problem

Solution: Ease-out Animation Component

Design Choices

Usage

Process Display Redesign

Before (22px tall):

After (36px tall):

Implementation

Chart Fixes: Three Bugs, One Session

Bug 1: Blank on Startup

Bug 2: Filter Lag

Bug 3: Color Inconsistency

What's Coming: TURBO Mode

Planned Features

1. Stop Non-Essential Services

2. Unpark CPU Cores

3. Auto Power Plan Switch

4. RAM Flush (>75% usage)

5. Suspend Inactive Processes

Why This Matters

Requirements:

Scarred: Lessons Learned

1. Sleep debt is real

2. Foundation work is invisible

3. Community feedback → credibility

4. Flow state doesn't wait

What's Next