DEV Community: Marcin Firmuga

Your PC Monitor Shows Numbers. It Should Understand Your Machine - Marcin Firmuga

Marcin Firmuga — Tue, 16 Jun 2026 12:38:17 +0000

Your PC monitor shows numbers. It should understand your machine.

I wrote most of this article in the evening, after a day of welding plastics at a repair shop.

That's the honest setup. My savings ran out.
My IT applications stay silent. So three days ago I started a temporary job that has nothing to do with code, and I write this at night, the same rhythm this whole project was built in for 11 months.

But here's the part that keeps me going:
the thing I'm about to explain isn't a plan or a pitch.

It's working code in a free, open-source tool you can download right now and read line by line. Industrial-grade statistics, running on your PC, learning your specific machine.
Built by someone who codes between shifts.

Let me show you why every traditional PC monitor is fundamentally limited and what learning your specific hardware actually looks like in code.

The threshold is dumb by design

Open any popular system monitor and it does one thing:
draws 78°C on a graph. Red when it crosses 80. That's it.

It has no idea whether that 78°C is your idle on a hot July afternoon, or gaming on a cooler that's been collecting dust for six months. To the monitor, 78 is just 78.

The threshold is dumb by design.
That's not an insult but it's its nature.
Rule

"if temp > X, alert"

has no concept of what it's running on. It doesnt remember yesterday.
It doesn't know your RTX always holds 71°C in this game, and today it s*uddenly hits 77 at the same load in the same room*.
The threshold only sees a number against a constant somebody hardcoded for every machine in the world at once.

And here's the most important sentence in this article:
your machine isn't in any table.

How these tools actually work

Before anyone says "but I have Afterburner and it's great" — sure, it is.
Let's just look at what it actually does under the hood.
And what the others do, because each one is excellent at one thing and blind in another.

MSI Afterburner / RivaTuner:
a hand-drawn fan curve (lookup table) and a fixed clock/voltage offset.
Zero learning. The curve is a table.
"Set and forget" OC doesn't know about silicon aging or ambient temperature.

Fan Control / Argus Monitor:
highly configurable, but still rules and triggers that YOU define.
You are the intelligence. The program just executes.

HWiNFO / HWMonitor: the gold standard for raw sensor data.
Zero recommendations, zero memory. Pure readout.

CCleaner: deletes temp files and "cleans the registry".
Registry cleaning is a 2026 myth, Microsoft itself advises against it, performance gain is roughly zero.

GeForce Experience / Armoury Crate / iCUE:
cloud database of GPU+game, presets by hardware category.
A profile for "RTX 4070," not for your specific card or your temperatures. Phones home.

Notice the pattern.
Every one is a different way to do the same two things:
show data, or execute a rule somebody set in advance.

None of them builds a model of your computer.
At best, you are the intelligence, sitting there setting curves by hand.
At worst, the cloud is the intelligence, it knows you have an "RTX 4070" and has no clue your specific unit runs 6 degrees hotter than your neighbor's with the same SKU.

Four reasons "general" is weak

Silicon lottery.
Two identical RTX 4070s from the same production line aren't identical.
Different voltage-frequency curves, different leakage, different undervolt headroom. Gap can reach 50-100 mV.

That forum advice "for a 4070 do -100 mV, works for me" will crash half the units to a black screen, because half don't have that headroom.
A general profile physically cannot know your silicon.
It saw an averaged card you don't own.

Aging and drift.
Thermal paste pumps out over a year or three, and temperatures climb a few degrees. Fan bearings wear. PSU capacitors age and lose capacitance.
A fixed profile never adapts, because it was written once.
Your "stable" OC from last year throws silent soft-errors today.

Ambient and context.
The same load at 18°C in winter and 28°C in summer produces different core temperatures.

"if temp > X"

rule is blind to this. It doesn't know your room, the season, or that you opened a window.

Load composition.
"Game + Discord + browser + OBS" is a completely different thermal profile than the game alone.

A Blender render (sustained 100% for an hour) behaves differently than a game (bursty spikes) and differently than a crypto miner (pegged full).
General thresholds treat load as if it exists in isolation.
In real life it never does.

Voltages. This is where it all comes together.

If you remember one example from this article, remember this one.

The ATX spec for the 12V rail allows ±5%. So anything from 11.4V to 12.6V is formally "within norm".
Every classic monitor only alerts you once voltage leaves that band.

But a healthy PSU doesn't float across that whole range.
A healthy PSU holds your rail much, much tighter, around 11.95-12.05V. That's a real ±0.4%, not ±5%.

Now: your PSU starts aging.
Under load the rail drops to 11.7V.
Still "in spec"! The threshold says OK, you're fine.
But those are tired capacitors making themselves known, months, sometimes half a year before the system starts failing under heavier load.

This is where statistics computed on your history come in, not on a spec sheet.
PC Workman keeps the median and MAD (median absolute deviation) of your own samples and computes a modified Z-score per Iglewicz-Hoaglin:

M = 0.6745 × (x − median) / MAD
|M| > 3.5  → anomaly
|M| > 2.5  → warning

A drop to 11.7V, invisible to the ATX threshold, runs well past 3.5 against your own 11.95-12.05V norm. Anomaly.

An early warning no threshold on earth catches, because the threshold looks at the manufacturer's spec, not at how this specific PSU behaved over the last few weeks.

Why median, not mean? Because the mean is a coward.
One voltage spike drags the mean up, widens the band, and the next spike passes without an alarm, the tool anesthetizes itself.

The median doesn't move after one outlier.
MAD inherits that robustness.
Add four Nelson Rules (single spike, 2-of-3 cluster, nine points on one side, six-point monotonic trend), that's classic Statistical Process Control, the same kind factories have used to watch production lines for decades.
I'm not reinventing the wheel.
I moved proven process control onto your PC's power rail.

That's the whole thesis in one picture: an absolute spec threshold versus statistical control against your own history.

Wait, "AI," meaning what exactly?

I have to say this plainly, or the whole article goes in the trash with the marketing nonsense:

"AI" here does not mean a chatbot bolted onto an old tool.

There's no GPT stapled on that "intelligently analyzes your hardware" and in practice makes things up.

Underneath sits real statistics: **Welford's **algorithm for online mean and variance (one pass, no keeping the whole history in RAM), median and MAD for voltages, Nelson Rules, process control.

These are methods from the '60s and '90s, boring, predictable, and that's exactly why I trust them.
Statistics don't hallucinate.

When someone says "AI in a monitor," 95% of the time it means
"we pasted in an API and now it costs more".
Here it's the opposite, the model learns locally, on your data, with no account and nothing sent anywhere.

The six lines that start it all

The whole context-aware system begins with one tiny function. This is the actual code:

def classify(self, cpu_pct: float, gpu_pct: float) -> str:
    if gpu_pct >= 60:   return "gaming"
    if cpu_pct < 15:    return "idle"
    if cpu_pct < 35:    return "light"
    if cpu_pct < 65:    return "medium"
    return "heavy"

Five contexts: gaming, idle, light, medium, heavy.
That's the secret.

Once the system knows the context, it learns what "normal" means inside it.
Not normal in general.
Normal for your machine, doing what it's doing right now.
Each snapshot lands in one of five buckets, and each bucket keeps its own learned baseline using **Welford's **online algorithm over your last 14 days of history.

An 80°C threshold for everything is lazy.
72°C while gaming on a mid-tower is fine.
The same 72°C while idle on a thin laptop means something is wrong.

Where it actually beats the threshold

Predictive maintenance, the killer feature.
Voltage drift caught by MAD and Nelson Rules means tired capacitors.
A systematic +3-5°C climb over weeks means paste needs replacing, caught before the CPU throttles.
Falling RPM-to-temperature efficiency means dust in the heatsink.
Catching problems before they become problems.
A threshold can't do this by definition, it waits until things are already bad.

Root-cause throttling instead of "CPU hot".
A general tool says: 95°C, a lot.
The model says: 95°C, but only during game+render, and that's +6°C above your 30-day norm for this specific load, most likely dust or paste, here's the trend chart, see for yourself.
The second answer contains a cause.
The first is just a number with an exclamation mark.

Anomaly as security. A process pretending to be svchost.exe but launched from %TEMP%.
An unusual CPU pattern that looks like a quiet miner.
Pattern-against-your-norm catches things a signature list doesn't know, because you don't need to know the threat's name, you just need to know this machine never behaved like this before.

The analogy that closes it

Whoop and Garmin don't tell you
"your resting heart rate is 60, norm is 60-100, you're OK".
They learn your resting HR and HRV, and alert when you drift from your baseline, even if you're still within "population norm".
That's how they catch something happening a day before you feel it.

PC Workman is exactly that, for your computer.
"78°C" without your baseline is like a heart rate of 100 without knowing whether you're looking at a marathon runner after training or someone who just climbed to the second floor out of breath.
Same number, two completely different worlds.

The whole difference is context — and a threshold has none.

Honestly: where this has limits

I won't sell you this as magic, because it isn't, and a text pretending its product has no flaws disqualifies itself.

Cold-start. Fresh after install,
the model doesn't know your norm yet, it has to gather data for weeks, realistically 6-12 months, to pass through summer and winter, gaming and idle, different loads.

During that time it's closer to a regular monitor than an intelligent one. That's the price of later talking about your hardware instead of an averaged one.

It needs good sensors, and Windows can really make you suffer here.
psutil.sensors_temperatures() returns an empty field on Windows, no temperatures, the end, thank you.
Hence the dependency on LibreHardwareMonitor and WMI just to have something to learn from. I know this not from documentation but from tripping over it myself and losing an evening before I understood why the voltage chart was empty.

It must not bark without reason.
One false alarm now and then and you stop trusting the tool, you turn off notifications and that's that.
So 12V spikes during GPU load changes are deliberately suppressed
(they're physically expected, not a failure)
and a pattern that repeats five times stops being treated as an anomaly and becomes your hardware's new norm.
A*nomaly decay.*
A tool that learns must also know how to retract its own alarm.

And one more thing, to be clear:

this is not anti-HWiNFO or anti-Afterburner. Raw sensor data is still the foundation everything stands on. What changes isn't that you read the data, it's what happens to that data next.

Why I'm telling you this between welding shifts

Your computer has a history. Specific, physical, its own, that one piece of silicon in that one room with that one PSU.
It's time a program remembered it, instead of comparing you to an average you never owned.

I built this because I got tired of tools that show and never understand. I built it on a laptop that hit 94°C, between warehouse shifts in the Netherlands, then between convenience store shifts in Poland, and now between welding shifts at a repair shop.

Monday, an article about this project hit #1 Trending on HackerNoon.
My first thought wasn't "I made it".
It was "what if this is an accident?"

Fear after success is stranger than fear after failure, with failure you know what to fix, with success you suddenly have something to lose.

But the code doesn't know I'm scared. It doesn't check trending positions.
It classifies the context and keeps learning. Maybe that's the lesson.

We stopped needing a tool that shows. We need one that understands,
and does the work for us.
Locally. Quietly.

This isn't a roadmap, it's working code.
Thermal Baseline Learning and Voltage SPC described above run in
PC Workman v1.7.9 - free, open-source. You can check every line.

Download or read the code:
github.com/HuckleR2003/PC_Workman_HCK

Full article on the project domain site!: pcworkman.dev

Everything else and coffee! :) : linktr.ee/marcin_firmuga

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 who learns, after time, your natural PC behavior (spikes, voltage, temps, usages) built entirely from scratch on dying hardware during warehouse shifts in the Netherlands.

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.
1000+ hours of code. 4 complete UI rebuilds. 16,000 lines deleted.
3 AM all-nighters.Energy drinks and toast.

And my own hck_GPT AI, building for months to give a PC Workman a brain and heart.
And finally, an app I wouldn’t close in 5 seconds. That’s the difference between building and shipping.

Marcin Firmuga | 22 | Poland | HCK_Labs Building PC Workman publicly. Physical work by day, code by night.

Marcin Firmuga | 22 | Poland | HCK_Labs
Building PC Workman publicly. Physical work by day, code by night.

I Was Supposed to Fix Bugs. I Accidentally Built Two Features Instead. PC Workman 1.7.8 - Advanced Deep Learning AI, Supply Monitor and Health Keeper.

Marcin Firmuga — Fri, 05 Jun 2026 19:44:00 +0000

I Was Supposed to Fix Bugs. I Accidentally Built Two Features Instead.

Friday Shipped & Scarred #11, the one where "no new features" lasted about 4 hours.

The plan after v1.7.7 (which shipped 20+ patches over one week): maintenance only. Fix the tester list. Test things.
Don't build anything.

I opened Setup & Drivers to verify a fix. My own PC had two GPU entries.

RTX - the one currently in the machine.
And GT 1030 - removed over two years ago.
Driver entries still in the registry, taking up space, doing nothing. Windows keeps dead hardware on life support forever.

I thought: if MY machine has this, everyone's does.

Three hours later, Ghost Driver Detection was in the codebase.

Ghost Drivers: Why WMI Lies To You

The obvious approach for "which devices are actually connected" is WMI. It's wrong.

WMI Win32_PnPEntity returns phantom devices too, that's exactly the problem I was trying to detect. You can't ask the ghost if it's a ghost.

What actually works: pnputil /enum-devices --connected.
PnPUtil queries the kernel's live device tree, not the registry cache.

# core/startup_watcher.py — _get_pnp_connected_names()
result = subprocess.run(
    ["pnputil", "/enum-devices", "--connected", "/class", guid],
    capture_output=True, timeout=10,
    creationflags=subprocess.CREATE_NO_WINDOW,
)
# Parse "Instance ID: ..." blocks - only hardware that's physically here right now

The detection logic is a set diff:

Registry drivers -> all installed entries for a device class
Connected (pnputil) -> what's actually plugged in right now
Gap -> ghost Any driver entry older than 20 months not in the connected set gets flagged. Red badge. Age info. One-click removal via pnputil /remove-device.

The feature shipped fast because the registry-reading infrastructure for the Drivers tab already existed.
I just needed the diff logic and a new card in Optimization Center.

Background App Hibernation:

Two Modes, Different Tradeoffs
Feature #14 of 16 planned for Optimization Center. Started as a bug investigation into idle process detection, turned into a full feature.

Detecting "idle" without false positives

The naive version: flag any process with CPU < 1% for 15 minutes. Problem: that includes background services, compiler daemons, git processes — anything that legitimately idles. The user shouldn't see those.

The actual filter in app_activity_tracker.py:

# Only surface apps that were ever in the foreground this session.
# If it was never in the foreground, it's a service — skip it.
if pid not in known_fg_pids:
    continue

# CPU guard: need 3 consecutive samples all below CPU_IDLE_PCT = 3.0%
# "below threshold" ≠ "not doing background work"
if len(samples) < CPU_SAMPLES_NEED:  # CPU_SAMPLES_NEED = 3
    continue
cpu_avg = sum(samples[-CPU_SAMPLES_NEED:]) / CPU_SAMPLES_NEED
if cpu_avg >= CPU_IDLE_PCT:
    continue

The foreground window tracking uses
GetForegroundWindow and GetWindowThreadProcessId via ctypes, polled every 15 seconds. No external deps, just pure Windows API.

@staticmethod
def _foreground_pid() -> int:
    hwnd = ctypes.windll.user32.GetForegroundWindow()
    pid  = ctypes.c_ulong(0)
    ctypes.windll.user32.GetWindowThreadProcessId(hwnd, ctypes.byref(pid))
    return pid.value
The two sleep behaviors
LOW PRIORITY — SetPriorityClass(IDLE_PRIORITY_CLASS) via kernel32.

IDLE_PRIORITY_CLASS = 0x00000040

def _set_priority(pid: int, priority_class: int) -> bool:
    h = ctypes.windll.kernel32.OpenProcess(PROCESS_SET_INFORMATION, False, pid)
    if not h:
        return False
    try:
        return bool(ctypes.windll.kernel32.SetPriorityClass(h, priority_class))
    finally:
        ctypes.windll.kernel32.CloseHandle(h)
Process still runs. Gets CPU scheduling only when everything else is idle. Safe for apps you might need soon — Discord, Spotify.

FREEZE — psutil.Process.suspend(), which calls NtSuspendProcess internally.

if behavior == "freeze":
    proc.suspend()   # NtSuspendProcess under the hood
else:
    _set_priority(pid, IDLE_PRIORITY_CLASS)

Zero CPU usage. Stays in RAM. Instant proc.resume() on wake. Good for things like updater processes that sit there all day doing nothing.

Turbo integration
The behaviors persist to hibernation_prefs.json per exe name. When TURBO mode activates (the existing power plan + service stop system in v1.7.7), hibernation behaviors apply automatically:

# optimization_services.py — _tpp_run()
ok = _pp_set(_TPP["turbo_guid"])
if ok:
    _TPP["active"] = True
    hibm = COMPONENTS.get("core.hibernation_manager")
    if hibm:
        hibm.apply_turbo_behaviors()   # applies all configured per-exe behaviors

And reverses on Turbo deactivate:

def _tpp_restore():
    ok = _pp_set(original_guid)
    if ok:
        _TPP["active"] = False
        hibm = COMPONENTS.get("core.hibernation_manager")
        if hibm:
            hibm.restore_turbo_apps()   # wakes everything that was frozen

Protected list of 30+ system process names (svchost.exe, MsMpEng.exe, dwm.exe, etc.) that never appear as hibernation candidates regardless of CPU or idle time.

The Parser Bug That Corrupted Polish Words

parser.py had an accent normalization step — a mapping of incomplete Polish fragments to their full forms, for users who don't type diacritics:

_ACCENT_MAP = [
    ("temperatur",   "temperatura"),  # fix: "jak jest temperatur" → "temperatura"
    ("wydajnosc",    "wydajność"),
    ("pamieci",      "pamięci"),
    # ...
]

def _normalize_accents(self, text: str) -> str:
    for stripped, accented in self._ACCENT_MAP:
        text = text.replace(stripped, accented)  # ← THE BUG
    return text
"temperatur" is a substring of "temperatura". When a user typed "temperatura cpu" (the complete word), str.replace matched the fragment inside it:

"temperatura" → "temperaturaa"
The double-a broke every pattern match. "temperatura cpu" was routing to hw_cpu instead of temperature because the multi-word phrase "temperatura cpu" no longer matched anything in the vocabulary.

Fix: word-boundary matching.

def _normalize_accents(self, text: str) -> str:
    for stripped, accented in self._ACCENT_MAP:
        text = re.sub(r'\b' + re.escape(stripped) + r'\b', accented, text)
    return text

\b only matches "temperatur" as a** standalone word*. "temperatura" **passes through untouched.*

This was caught during the 20-question intent routing test I ran post-audit.
"temperatura cpu" was scoring hw_cpu with 33% confidence.
Traced it to "temperaturaa cpu" matching nothing.

The Cache That Was Rebuilding on Every Message
Same file. Different problem. The folded pattern cache (used for accent-insensitive matching) was being built inside parse():

# OLD — runs on every single message
def parse(self, text):
    folded_patterns_cache = {
        intent: [self._ascii_fold(p) for p in patterns]
        for intent, patterns in INTENT_PATTERNS.items()
    }
    # ... scoring ...

INTENT_PATTERNS has 82 intents, some with 30+ patterns each. Every user message rebuilt this entire dict from scratch. O(n×m) per call.

Fix: lazy class-level cache.

# NEW - built once, reused forever
class IntentParser:
    _folded_cache: Dict[str, List[str]] = {}

    def _get_folded_cache(self) -> Dict[str, List[str]]:
        if not self._folded_cache:
            IntentParser._folded_cache = {
                intent: [self._ascii_fold(p) for p in patterns]
                for intent, patterns in INTENT_PATTERNS.items()
            }
        return self._folded_cache
INTENT_PATTERNS is static at import time. There's no reason to rebuild it on message #47.

82/82 - What Full Intent Coverage Actually Means
The hck_GPT AI engine routes messages using a hybrid system:
keyword scoring and Naive Bayes blend TO confidence score
and rule engine if ≥ 0.65, Ollama LLM if below.

Each intent has two config entries in hybrid_engine.py:

_CONTEXT_WINDOWS — how far back the AI looks for that intent type:

_CONTEXT_WINDOWS = {
    "hw_cpu":          5,      # last 5 minutes — live snapshot
    "temperature":     10,     # last 10 minutes
    "temp_comparison": 10080,  # last 7 days — trend comparison
    "weekly_trends":   10080,
    "session_digest":  480,    # 8-hour session summary
    "fan_speed":       5,
    # ... 82 total
}
_INTENT_HINTS - what Ollama is told to focus on per intent type:

_INTENT_HINTS = {
    "temperature":  "User is asking about system temperatures - be specific: CPU, GPU, and threshold warnings.",
    "temp_comparison": "User asks if PC is running hotter than usual - compare current temps to 7-day and 30-day historical averages.",
    "fan_speed":    "User is asking about fan RPM - show all fan sensors, current RPM, and if any fans are stalled.",
    "ram_flush":    "User wants to free up RAM - explain what's safe to close, give current top RAM consumers with MB values.",
    # ... 82 total
}

Before this week: 34/82 had context windows. 54/82 had hints. Every unregistered intent fell through to a 30-minute default window and empty guidance.

Now all 82 have both. A query about "temperatur cpu" gets a 10-minute window (relevant recent data) and a hint telling the LLM exactly what to check.
A trend query like "is my cpu hot more than average" (temp_comparison) gets 7 days of data and the right comparison guidance.

The before/after on intent detection after fixing the parser
bug and filling the maps:

Query   Before  After   Context
temperatur cpu  hw_cpu (broken) temperature ✓ 10m
is my pc more warm than normal? hw_all RULE 5m  temp_comparison ✓ 10080m
make roast about my pc  unknown fun_roast ✓   30m
morning brief   unknown morning_brief ✓   10080m
is my cpu overclocked?  hw_cpu  overclock_check ✓ 5m
Test suite after all changes: 21/21.

The hck_GPT Panel Startup Bug
One-liner symptoms: panel appears at the very top of the window on fresh launch. Toggle Max View Mode once and it snaps to the correct bottom position.

Root cause:

parent.after(350, lambda: self._animate(0, self.collapsed_h, duration_ms=700))

The animation runs 350ms after panel creation. It reads parent.winfo_height() to compute y = parent_h - current_h.

But 350ms isn't enough on the first launch - the window hasn't been laid out yet, so winfo_height() returns 0.
Then y = 0 - 34 = -34, clamped to 0. Panel at the top.

Max View Mode triggered a geometry change, which forced a re-layout, which gave correct winfo_height().

Fix:

def _animate(self, start_h, end_h, duration_ms=200, on_end=None):
    parent_h = self.parent.winfo_height()
    if parent_h < 50:
        # Window not rendered yet — retry in 80ms
        self.frame.after(80, lambda: self._animate(start_h, end_h, duration_ms, on_end))
        return
    # ... normal animation
Polls until the parent has an actual height. No arbitrary sleeps, no one-shot 350ms guess.

The Numbers

2 unplanned features shipped (Ghost Drivers, Background App Hibernation)
15/16 Optimization Center features live
82/82 intents with context windows + LLM hints (was 34/54)
14 vocabulary patterns fixed or added
1 parser bug causing word corruption
1 startup positioning bug in hck_GPT panel
21/21 automated tests passing
I was supposed to fix bugs. I fixed the bugs. I also shipped two features. I have no explanation.

Stack & Links

PC Workman is a real-time Windows system monitor with embedded AI assistant (hck_GPT). Open source, Python 3.9+ / Tkinter, Windows 10+.

GitHub: github.com/HuckleR2003/PC_Workman_HCK
Medium (narrative version): link
Support: Coffee or Github :)
Marcin Firmuga - HCK_Labs - solo dev, Poland.
11 months. Still shipping.

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.
1000+ hours of code. 4 complete UI rebuilds. 16,000 lines deleted.
3 AM all-nighters.Energy drinks and toast.

And my own hck_GPT AI, building for months to give a PC Workman a brain and heart.
And finally, an app I wouldn’t close in 5 seconds. That’s the difference between building and shipping.

I Built an AI-Powered PC Monitor in Python. 28 Strangers Shaped Its Brain. PC Workman 1.7.6

Marcin Firmuga — Thu, 28 May 2026 20:47:16 +0000

I built an AI-powered PC monitor in Python. 28 strangers shaped its brain.
This article is about PC Workman 1.7.6.
But it's also about what indie dev actually looks like, between retail shifts, late night compiler sessions, and debugging Polish character encoding bugs at 4 AM.

Where it started

PC Workman has created, when I live and work in Nederlands by Agency.
Then 5 months later, I come back to Poland and trying to get a place for me.
For 3 weeks I working by International Trucker.
Then I got my little stop from coding, but after visits Slovakia and Czechy I have seen I carry a... 900% OVER MASS THAN LIMIT.
I don't get anything, I just see that before next trip to France.
Next
I was working as a cashier. Coming home after 8-hour shifts and sitting down to code.

Not because I had energy. Because I couldn't stop.

PC Workman started from one problem: my PC would slow down and I had no idea why. Task Manager said "CPU: 87%." But which process? Since when? How long? Nothing.

Every monitoring tool was either outdated, required installing 3 extra libraries, or looked like it was designed in 2009 and nobody touched the code since.

So I thought: I'll build my own.

Classic mistake. Best decision I ever made.

10 months, 96 files, 48,000 lines

Current state:

Python files:     96
Total lines:      48,081
Response builder: 255,065 chars (yes, one file)
Process library:  241 entries
AI intents:       82
Response handlers: 65

None of these numbers are what I'm most proud of.

Part 1: AI that understands "how much RAM is Chrome eating"

The most technically interesting part of PC Workman is hck_GPT — an AI assistant built directly into the app.

No external API. Doesn't send your data anywhere. Works locally through a hybrid engine: if the intent gets recognized by the 82-intent parser, it responds deterministically from real data. If not, it delegates to a local Ollama LLM.

user input
    → IntentParser (vocab match + ML classifier)
    → HybridEngine (rule dispatch vs LLM fallback)
    → ResponseBuilder (65 handlers, real sensor data)
    → bilingual response (PL/EN auto-detected)

82 intents cover everything from "why is CPU high" to "can I run Cyberpunk" to "what's eating my battery." Each intent has dozens of patterns — because users ask the same thing 15 different ways.

The bilingual helper looks almost embarrassingly simple:

def _t(lang: str, pl: str, en: str) -> str:
    return en if lang == "en" else pl

Behind that sits 854 lines of vocabulary patterns in two languages.

Part 2: The Polish ł that broke routing

This is one of my favorite bugs because it was so non-obvious.

The parser normalizes text before matching — strips diacritics so "dlaczego" (why) with or without accents hits the same intent:

def _ascii_fold(self, text: str) -> str:
    import unicodedata
    return "".join(
        c for c in unicodedata.normalize("NFD", text)
        if unicodedata.category(c) != "Mn"
    )

NFD normalization decomposes "ą" into "a" + combining ogonek, then the filter removes combining characters. Works great for ą, ę, ó, ź, ż, ń.

But not for ł.

ł (U+0142) isn't "l" with a combining stroke. It's a separate character that NFD doesn't decompose at all.

user types:    "jak dlugo wytrzyma bateria"   (plain l)
vocab pattern: "jak długo wytrzyma bateria"   (ł stays as ł after fold)

fold("długo") → "długo"   <- ł preserved
fold("dlugo") → "dlugo"   <- l preserved

"długo" ≠ "dlugo"  -> NO MATCH

The battery_estimate intent was returning conf=0.00 on a perfect question.

Fix: explicit ASCII fallback patterns for every intent containing ł:

# vocabulary.py - battery_estimate patterns
"jak dlugo wytrzyma bateria",     # ASCII fallback
"jak długo wytrzyma bateria",     # canonical Polish
"how long will battery last",     # English

This is the type of bug you only find when building an app in two languages simultaneously and one of them has characters that don't behave the way you think.

Part 3: 28 strangers designed 6 new features

Few weeks ago I posted a simple question on GitHub Discussions and LinkedIn:

"What would you ask an AI that lives inside your system monitor?"

28 answers. From GitHub, LinkedIn DMs, comments.

Every answer became a real function in the response builder.

Intent	What it does
game_can_run	Checks if your PC can handle a game (20-game DB with RAM/VRAM/disk requirements)
battery_estimate	psutil.sensors_battery() + drain rate based on activity type
upgrade_feasibility	WMI slot count + current sticks + free slots
top_resource_hog	TOP 5 processes by RSS memory + disk I/O
gaming_ram_usage	Live game process RAM + 7-day comparison
daily_ram_usage	7-day trend + verdict: very high / high / moderate / low

When you ask hck_GPT "can I run Cyberpunk" it checks your psutil RAM, WMI VRAM, free disk space and responds with specific numbers. No hallucination. No "usually..." No guessing.

The no-data fallback is deliberate:

def _no_data(self, intent, lang, what_missing=""):
    if lang == "en":
        return [
            f"{self.PREFIX} Not enough data for a reliable answer.",
            f"  I'd rather tell you honestly than guess.",
        ]

If I don't have data, I say so. AI that guesses is worse than AI that stays quiet.

Part 4: DeepMonitor - from ugly table to real tool

For a long time the hardware view in PC Workman was weak. Inline min/max values with no alignment, dark uneven colors, no structure.

Rewrote it from scratch on ttk.Treeview with 4 fixed columns:

Sensor                    | Value     | Min       | Max
----------------------------------------------------------
  CPU
    [Temperatures]
      Package             | 52.1°C    | 44.0°C    | 52.1°C
      Core #0             | 49.3°C    | 45.1°C    | 51.8°C
    [Utilization]
      Processor           | 13.7%     |  0.0%     | 23.6%
    [Clocks]
      Current             | 3.990 GHz |           | 4.011 GHz

Each category has its own background tint. Temperatures go from white to amber at 70°C to red at 83°C. Utilization hits red at 88%.

Action bar: Save Data (exports .txt/.csv), Pause (freezes the view, button turns amber), Reset (clears session min/max).

Same psutil and hardware_sensors feed hck_GPT. When DeepMonitor shows a red CPU temp line, the proactive monitor probably already sent an alert through hck_GPT a few minutes earlier. Two views, one data source.

Part 5: Proactive monitor - AI that doesn't wait for your question

One of my favorite modules. Runs in background and starts conversations on its own.

THROTTLE_RATIO   = 0.60   # below 60% of max freq = throttled
CPU_SPIKE_PCT    = 30.0   # single process >30% = spike alert
SESSION_BUDGET   = 3      # max 3 unsolicited alerts per 30 min
SESSION_WINDOW_S = 1800

SESSION_BUDGET isn't random — based on CHI 2025 research on proactive AI assistants and when proactivity becomes annoying.

Throttling alert:

hck_GPT: CPU power limit hit (58% of max). Heat is usually the cause. Type 'temperature'.

GPU temperature:

hck_GPT: GPU temperature spike to 89°C. Check cooling or lower graphics settings.

One alert. Specific reason. Specific next action. Not "your computer may be experiencing reduced performance."

Part 6: Language sync — one hour debugging for one line

For 10 months I built an app for Polish users entirely in English. That was a mistake I finally fixed.

But the Settings language toggle didn't sync with hck_GPT. Click "PL" — interface changes, hck_GPT keeps responding in English.

The fix was clean: utils/i18n.py has a callback system:

# panel.py __init__:
_i18n_register(self._on_i18n_lang_changed)

def _on_i18n_lang_changed(self):
    new_lang = _i18n_get_lang()
    self._ui_lang = new_lang
    proactive_monitor.set_language(new_lang)
    self.parent.after(0, self._refresh_welcome_for_lang)

After switching to PL:

hck_GPT: Witaj z powrotem — PC Workman gotowy do działania.

One callback registration. One hour understanding why the widget wasn't refreshing at the right moment.

Numbers that surprised me

28,000 LinkedIn views on the "building what 28 people asked for" post
27,500 views on "most developers never ship an .exe"
1,135 em-dashes found and replaced in one maintenance session across 58 files
241 processes in the knowledge base
82 intents in the parser, each with dozens of PL+EN patterns
0 external APIs — everything local Most surprising: the two most viral posts weren't about the most technically interesting things. They were about truths every developer recognizes but rarely says out loud.

What's next

Security module — offline, no signatures, no cloud. Pattern detection on data PC Workman already collects.

svch0st.exe pretending to be svchost.exe? Flagged.
Crypto miner with abnormal CPU pattern 24/7? Flagged.
New high-privilege process that wasn't there yesterday? Flagged.

Your antivirus knows about threats from around the world. PC Workman knows what's normal for YOUR specific machine.

And Microsoft Store submission. I've been saying this since v1.6.3. This time I mean it.

Current stats: 56 GitHub stars, 270+ downloads, 270+ commits, 82 AI intents, 48,081 lines, 10 months, one €1.50 coffee donation.

Repo: github.com/HuckleR2003/PC_Workman_HCK
All links: linktr.ee/marcin_firmuga

If you have a question you'd ask an AI inside your system monitor — drop it in the comments. Every one becomes a real feature.

Marcin Firmuga | 22 | Poland | HCK_Labs
Building PC Workman and GuideAI publicly. 10 months. 4 rebuilds. Still shipping.

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.
1000+ hours of code. 4 complete UI rebuilds. 16,000 lines deleted.
3 AM all-nighters.Energy drinks and toast.

And my own hck_GPT AI, building for months to give a PC Workman a brain and heart.
And finally, an app I wouldn’t close in 5 seconds. That’s the difference between building and shipping.

PC_Workman is the result.

How I Taught My Offline AI to Remember, Watch, and Warn, Without Any Cloud (Part 2)

Marcin Firmuga — Tue, 12 May 2026 15:17:33 +0000

Part 1 covered how hck_GPT routes messages through 9 layers and decides between rules and a local LLM. If you missed it:
Part 1 - Intent Scoring, Hybrid Routing, Temperature per Intent.

That was the brain. This is the memory and the instincts.

Part 1's AI was reactive. You ask, it answers. Close the app, everything is gone. No history. No learning. No initiative.

That's not how a PC companion should work. If I've been running PC Workman for two weeks, it should know that my CPU averages 28% and today's 67% is unusual. It should notice that Chrome has been eating 2GB RAM for an hour and mention it before I ask. It should remember my GPU model without me telling it twice.

So I built three systems that Part 1 didn't have: a persistent knowledge base that survives restarts, a metrics store that snapshots hardware data every 5 minutes into SQLite, and a proactive monitor that watches your system and pushes alerts without being asked.

All offline. All local. Your data never leaves your machine.

1. The Knowledge Base, AI That Remembers Across Restarts

Part 1 had session memory,
a Python dict that dies when the app closes. Useful for
"we talked about RAM 3 messages ago" but useless for
"your GPU is an RTX 3060 with 6GB VRAM"
which shouldn't need re-scanning every launch.

Four tables, each with a different job:

CREATE TABLE IF NOT EXISTS hardware_profile (
    key     TEXT PRIMARY KEY,
    value   TEXT NOT NULL,
    updated REAL NOT NULL
);

CREATE TABLE IF NOT EXISTS usage_patterns (
    metric  TEXT PRIMARY KEY,
    value   TEXT NOT NULL,
    updated REAL NOT NULL
);

CREATE TABLE IF NOT EXISTS user_facts (
    key        TEXT PRIMARY KEY,
    value      TEXT NOT NULL,
    source     TEXT NOT NULL DEFAULT 'detected',
    confidence REAL NOT NULL DEFAULT 1.0,
    created_at REAL NOT NULL
);

CREATE TABLE IF NOT EXISTS conversation_log (
    id         INTEGER PRIMARY KEY AUTOINCREMENT,
    session_id TEXT    NOT NULL,
    timestamp  REAL    NOT NULL,
    role       TEXT    NOT NULL,
    message    TEXT    NOT NULL
);

hardware_profile stores things that rarely change:
CPU model, GPU name, VRAM, motherboard, RAM speed, OS version.

Scanned once via psutil + WMI, then cached.
The hardware_is_fresh() method checks if the last scan was within 24 hours - if yes, skip the scan.
No wasted resources on startup.

usage_patterns stores things that change slowly:
average CPU load, peak hours, top apps, detected use-case
("gaming" vs "development" vs "office").
Updated periodically from the stats engine.

user_facts stores things the AI inferred or the user stated:
preferred language, PC usage type, whether they play games.
Each fact has a confidence score — detected facts start at 1.0, inferred facts can be lower.
This is how hck_GPT knows to greet you in Polish without asking every session.

conversation_log keeps the last 500 messages across sessions
(pruned monthly). Not for replaying conversations, for pattern detection. "User asks about temperature every Monday" is a signal.

The knowledge base builds a context summary for every AI response:

def build_knowledge_summary(self) -> str:
    hw    = self.get_all_hardware()
    facts = self.get_all_facts()
    lines = []

    if hw:
        lines.append("Hardware:")
        for key, label in _HW_LABELS:
            if key in hw and hw[key] is not None:
                lines.append(f"  {label}: {hw[key]}")

    if facts:
        lines.append("User facts:")
        for k, v in list(facts.items())[:8]:
            lines.append(f"  {k}: {v}")

    return "\n".join(lines) if lines else "(knowledge base empty)"

This gets injected into every Ollama prompt. The LLM doesn't ask "what GPU do you have?", it already knows.
From the first message of every session.

2. Metrics Store, 90 Days of Hardware History in SQLite

Session memory remembers what happened in the last 30 minutes.
The knowledge base remembers your hardware profile.
But what about "was my CPU hotter yesterday than today?"

The Metrics Store answers that. Every 5 minutes, a background thread snapshots 20+ sensor values into SQLite:

SNAPSHOT_INTERVAL = 300   # 5 minutes between snapshots
RETENTION_DAYS    = 90    # auto-prune after 90 days

CREATE TABLE IF NOT EXISTS deepmonitor_snapshots (
    id            INTEGER PRIMARY KEY AUTOINCREMENT,
    ts            REAL    NOT NULL,
    date_str      TEXT    NOT NULL,
    cpu_load      REAL,
    cpu_temp      REAL,
    cpu_mhz       REAL,
    cpu_power     REAL,
    gpu_temp      REAL,
    gpu_load      REAL,
    gpu_vram_pct  REAL,
    gpu_power     REAL,
    ram_pct       REAL,
    swap_pct      REAL,
    mb_temp_sys   REAL,
    mb_volt_12v   REAL,
    mb_volt_5v    REAL,
    mb_volt_33v   REAL,
    disk_json     TEXT
);

This table shares the same hck_stats.db file as the main stats engine — one database, WAL mode, concurrent reads and writes without locks.

The writer loop staggers its first write by 60 seconds so the UI finishes loading first:

def _writer_loop(self) -> None:
    self._stop.wait(60)  # let UI boot
    while not self._stop.is_set():
        try:
            self._save_snapshot()
            self._prune_old_rows()
        except Exception as e:
            log.debug("writer error: %s", e)
        self._stop.wait(SNAPSHOT_INTERVAL)

Auto-prune runs after every snapshot — rows older than 90 days get deleted. Database stays small (~5-10 MB per month).

The critical part is what happens on startup:

def _load_historical_baselines(self) -> None:
    since = time.time() - 7 * 86400
    row = conn.execute("""
        SELECT
          AVG(CASE WHEN cpu_load >= 0 THEN cpu_load END) AS cpu_av,
          AVG(CASE WHEN ram_pct  >= 0 THEN ram_pct  END) AS ram_av,
          MIN(CASE WHEN cpu_load >= 0 THEN cpu_load END) AS cpu_lo,
          MAX(CASE WHEN cpu_load >= 0 THEN cpu_load END) AS cpu_hi,
          COUNT(*) AS n
        FROM deepmonitor_snapshots WHERE ts >= ?
    """, (since,)).fetchone()

    live_sensors.update({
        "_hist_cpu_avg_7d": round(row["cpu_av"], 1),
        "_hist_ram_avg_7d": round(row["ram_av"], 1),
    })

On app boot, the store loads 7-day min/max/avg baselines into live memory. From the very first message, hck_GPT can say "your CPU is at 67% — but your 7-day average is 28%, something is off." Not because it guessed. Because it has 2,016 data points from the last week (288 snapshots/day × 7 days).

Without this, the AI would need to run for hours before it could make any comparison. With it, historical context is available from second one.

The public API is simple — two methods cover 90% of use cases:

rows = metrics_store.get_history(hours=24)     # raw snapshots
summary = metrics_store.daily_summary(days=7)  # per-day aggregates

3. The Proactive Monitor, AI That Speaks First

This is the part that makes people say "wait, it does WHAT?"

Most AI assistants wait for input. You type, they respond. Passive.

hck_GPT's Proactive Monitor is a daemon thread that runs every 45 seconds, checks system state, and pushes alerts to the chat panel without anyone asking.

CPU_HIGH_PCT     = 85.0
CPU_CRIT_PCT     = 95.0
RAM_HIGH_PCT     = 88.0
RAM_CRIT_PCT     = 93.0
DISK_LOW_GB      = 4.0
THROTTLE_RATIO   = 0.60
CHECK_INTERVAL_S = 45
MIN_GAP_SAME_S   = 300   # don't repeat same alert for 5 min

Seven conditions monitored:

CPU sustained high, not a spike, sustained.
Two consecutive checks above 85% before alerting.
One check could be a game loading.
Two means something is wrong.
CPU critical - above 95%. Immediate alert.
No waiting for second check.
RAM high - above 88%. Suggests checking what's eating memory.
RAM critical - above 93%. Pagefile is getting hit.
CPU throttling - current frequency divided by max frequency below 60%. Your CPU is being thermally limited.
Disk nearly full - any partition below 4 GB free.
Long session - PC running for many hours. Gentle reminder.

Every alert has a bilingual message pool, Polish and English versions with slight variations so the same alert doesn't read identically twice:

_MSGS = {
    "cpu_high": {
        "en": [
            "hck_GPT: ⚠ CPU sustained at {val}%. Type 'top processes' to see who's responsible.",
            "hck_GPT: CPU {val}% — something's eating it. Type 'top' to find out what.",
            "hck_GPT: Heads up — CPU at {val}%. Expected, or something sneaky in the background?",
        ],
        "pl": [
            "hck_GPT: ⚠ CPU na {val}% od dłuższego czasu. Wpisz 'top procesy' żeby zobaczyć winowajcę.",
            "hck_GPT: CPU {val}% — coś go zjada. Jeśli to nie Ty, to kto? Wpisz 'top'.",
        ],
    },
}

The anti-spam logic is critical. Without it, a sustained CPU spike would flood the chat with warnings every 45 seconds:

MIN_GAP_SAME_S = 300  # 5 minutes between same alert type

def _should_push(self, key: str) -> bool:
    now = time.time()
    last = self._last_push.get(key, 0)
    if now - last < MIN_GAP_SAME_S:
        return False
    self._last_push[key] = now
    return True

The push mechanism uses callbacks — the UI registers a function, the monitor calls it from the background thread:

proactive_monitor.register_push(
    lambda msg: root.after(0, lambda: panel.add_message(msg))
)

root.after(0, ...) schedules the message on tkinter's main thread. Background thread never touches the GUI directly. No race conditions. No crashes.

There's also a silent banner callback for non-intrusive status updates — "All quiet" vs "CPU 87% SPIKE | 2 alerts" in the hck_GPT status bar.

4. Bilingual Vocabulary — 854 Lines, Zero Translation API

Part 1 mentioned that Polish and English patterns are "defined separately." Here's what that actually looks like at scale.

vocabulary.py is 854 lines. 25+ intents. Each intent has a list of trigger patterns in both languages, mixed together:

INTENT_PATTERNS = {
    "hw_cpu": [
        # Polish tokens
        "procesor", "rdzeń", "rdzenie", "taktowanie",
        # English tokens
        "cpu", "processor", "cores", "boost",
        # Polish multi-word (high bonus)
        "jaki procesor", "jaki mam procesor", "ile rdzeni",
        "co mam za procesor", "powiedz mi o procesorze",
        # English multi-word
        "what cpu", "my cpu", "which processor",
        "tell me about my cpu", "cpu details",
    ],
}

No translation step.
No language detection preprocessing.
Both languages live in the same list.
The intent parser scores them all the same way — exact match, prefix match, typo tolerance. If someone types "jaki mam procesor" they get the same intent (hw_cpu) with the same confidence as "what cpu do I have."

The scoring comment at the top of the file explains the math:

# Pattern scoring (in parser.py):
#   - Multi-word phrases:  len(words) * 1.5  (biggest bonus)
#   - Exact single token:  1.0
#   - Partial prefix:      0.4
#   - Normalised:          min(1.0, score / 3.0)

Adding more multi-word phrases to an intent raises its confidence, making it more likely to hit the 0.60 threshold for the rule engine.
Ambiguous queries stay below threshold and go to Ollama.
The vocabulary file IS the tuning knob, no hyperparameters to optimize, just patterns to add.

This week I added 12 new intents based on questions from LinkedIn followers:

battery_drain - "Which process is draining my battery?"
session_compare - "Was it better yesterday?"
pc_changes - "What changed since yesterday?"
startup_safety - "Is it safe to disable this?"
browser_cache - "Is my browser slow because of caching?"
swap_analysis - "Which processes are using swap?"
network_usage - "Which process is using my network?" Each one: 10-20 patterns, Polish + English, with bilingual response handlers reading live data from psutil and the metrics store.

What Part 1 + Part 2 Give You Together

Layer	Part 1	Part 2
Input processing	Intent parser, confidence scoring	Bilingual vocabulary (854 lines)
Decision	9-layer routing, hybrid engine	—
Response	Rule engine + Ollama, temperature per intent	—
Short-term memory	Session dict, trend tracking	—
Long-term memory	—	User Knowledge Base (SQLite, AppData)
Historical data	—	Metrics Store (snapshots q5min, 90-day retention)
Proactive behavior	—	Daemon monitor (7 conditions, anti-spam, bilingual alerts)
Startup context	—	7-day baselines loaded on boot

Part 1 built a brain that responds. Part 2 gave it memory that persists, data that accumulates, and instincts that act without being asked.

What's Still Missing

Cross-session conversation context.
The knowledge base stores hardware profiles and usage patterns, but conversation topics don't persist. If you asked about RAM yesterday, today's session doesn't know.
The conversation_log table has the data — the response builder just doesn't query it yet.

Predictive alerts. The proactive monitor reacts to current state.
It doesn't predict. "Your RAM tends to spike around 9 PM on weekdays" is possible with the metrics store data - the SQL is straightforward, the pattern detection isn't built yet.

Automatic vocabulary expansion. Every unrecognized query requires manual pattern addition.

A feedback loop that logs low-confidence queries and suggests new patterns would cut maintenance time significantly.

The Offline-First Philosophy

Every feature in this article stores data locally. SQLite in AppData. Snapshots in the shared stats database.
Alerts computed from psutil readings. Nothing is sent anywhere.

**This isn't a limitation - it's a design choice.
**When your app monitors CPU temperatures, reads Windows registry, scans running processes, and tracks usage patterns over 90 days, the data is sensitive by definition.
Sending it to a cloud API for every interaction isn't just slow. It's a trust problem.

The optional Ollama integration (coming before v2.0) will give users a choice: stay fully offline with the Core AI, or enable a local LLM for smarter conversations.
The key word is "local." Even the LLM runs on your hardware.

Your data. Your machine. Your choice.

My Project

PC Workman is open source. MIT licensed.
The .exe doesn't require Python.

Download: GitHub Releases
Part 1: How I Built an Offline AI Assistant in Python

All my links: linktr.ee/marcin_firmuga

Currently doing Google's AI certification (Umiejętności Jutra 3.0 through SGH).
Curious how it'll change the way I think about this engine.

Marcin Firmuga | Python Developer | HCK_Labs
Building PC Workman publicly between retail shifts. 800+ hours, 28 GitHub stars, and an AI that now remembers what it told you last week.

Real guide from my 10 months of work PC Workman (Open Source, fully build in public (fails, tiny wins)

Marcin Firmuga — Mon, 04 May 2026 06:44:25 +0000

A 5-step decision chain for two languages

Marcin Firmuga

May 3

How I Built an Offline AI Assistant in Python - No OpenAI, No LangChain, No Dependencies

#python #ai #tutorial #opensource

9 min read

How I Built an Offline AI Assistant in Python - No OpenAI, No LangChain, No Dependencies

Marcin Firmuga — Sun, 03 May 2026 13:45:33 +0000

Every tutorial about building an AI assistant starts the same way:
pip install openai. Get an API key. Send everything to GPT. Done.

Now your assistant costs money per message, dies without internet, and you have zero control over what happens between the question and the answer.

I needed something different.

PC Workman is an open-source system monitor that runs on people's PCs. Some of those PCs are behind firewalls.
Some users don't want their system data leaving their machine.

So I built hck_GPT... a hybrid AI assistant that works fully offline,
handles Polish and English without a language model, routes messages through a 5-step decision chain, blends keyword scoring with
ML confidence, remembers what it said 3 messages ago, and optionally talks to a local LLM (Ollama) when it's available.

No cloud. No API key. No pip install magic.
Here's how it works. All of it.

1. Intent Scoring - One Algorithm for Two Languages, Zero NLP Libraries

The first problem: how do you figure out what someone is asking without shipping a 500MB NLP model?

Most intent parsers use spaCy, NLTK, or a transformer. I used string matching. But not the dumb kind.

def _score_intent(self, tokens: List[str], full_text: str,
                  patterns: List[str]) -> float:
    score = 0.0
    for pattern in patterns:
        if " " in pattern:
            # Multi-word phrase -> bonus proportional to word count
            if pattern in full_text:
                score += len(pattern.split()) * 1.5   # "why is ram so high" = 5 x 1.5
        else:
            if pattern in tokens:
                score += 1.0                          # exact match
            elif any(
                t.startswith(pattern) or pattern.startswith(t)
                for t in tokens if len(t) >= 3 and len(pattern) >= 3
            ):
                score += 0.4                          # prefix match ("perfor" -> "performance")
            elif len(pattern) >= 5 and any(
                self._edit_distance(t, pattern) <= 1
                for t in tokens if abs(len(t) - len(pattern)) <= 2 and len(t) >= 4
            ):
                score += 0.6                          # typo tolerance: 1-char edit distance
    return score

Three levels of matching in a single loop.

Exact match gives 1.0 - "cpu" in tokens, done.
Prefix match gives 0.4 - "perfor" matches "performance".
This is how the parser handles both languages without a language detector.
Polish and English vocabulary patterns are defined separately, but the scoring algorithm is identical.
Typo tolerance gives 0.6 - Levenshtein distance of 1 catches "temperture" → "temperature" without a spell checker.

Multi-word phrases get bonus scoring proportional to word count. "what changed in performance" (5 words x 1.5 = 7.5 pts) beats a standalone "performance" (1 pt).
More specific queries earn higher confidence.

The edit distance function has an early-exit: if the length difference between two strings is more than 2, skip the computation entirely.
This matters because this runs on every message in a GUI thread.
Blocking for 200ms on a distance calculation would feel like lag.

Zero dependencies. Works in both languages. Runs in under 1ms.

2. Hybrid Confidence - When to Trust ML, When to Trust Keywords

If you have a keyword scorer AND an ML classifier, you need to decide who wins. Most systems pick one. I blend them.

def _blend_with_ml(self, text: str, kw_intent: str, kw_conf: float):
    ml_intent, ml_conf = ml_classifier.predict(text)

    if ml_conf >= 0.70:
        # ML very confident — trust it outright
        return ml_intent, ml_conf

    if ml_conf >= 0.35:
        if ml_intent == kw_intent:
            # Agreement -> amplify the signal
            blended = 0.65 * ml_conf + 0.35 * kw_conf
            return ml_intent, min(1.0, blended)
        else:
            # Disagreement → pick the stronger weighted signal
            ml_score = 0.65 * ml_conf
            kw_score = 0.35 * kw_conf
            winner   = ml_intent if ml_score >= kw_score else kw_intent
            conf     = min(1.0, max(ml_score, kw_score) + 0.15 * min(ml_score, kw_score))
            return winner, conf

    # ML not confident enough - fall back to pure keyword scoring
    return kw_intent, kw_conf

Three trust zones instead of one threshold.

Above 0.70 - ML is confident. Trust it. Keywords don't get a vote.

Between 0.35 and 0.69, the interesting zone. If both models agree on the intent, the blended confidence goes up (agreement, amplified signal). If they disagree, the loser still gets 15% of the vote.
That 15% matters it prevents the winner from being overconfident on ambiguous inputs.

Below 0.35 - ML doesn't know. Pure keyword scoring takes over.

The 0.65/0.35 weight split is intentional.
ML gets more weight because when it's right, it understands full semantics. Keywords only match surface patterns.
But keywords are more reliable on short, domain-specific inputs like
"cpu" or "mb" where ML tends to underperform.

3. The Routing Decision - 5 Steps from Message to Answer

This is the core of the whole engine. Every message follows the same path:

RULE_THRESHOLD = 0.60   # above -> deterministic rule engine
LOW_THRESHOLD  = 0.20   # below -> not worth even trying

def process(self, msg: str, result: ParseResult, lang: str = "pl"):
    confidence = result.confidence
    intent     = result.intent

    # Step 1: Open-ended queries -> LLM first
    if intent in {"small_talk", "unknown"}:
        if self._check_available():
            return self._query_llm(msg, lang, result)
        return response_builder.build(result, lang)  # graceful degradation

    # Step 2: High confidence -> deterministic, instant answer
    if confidence >= RULE_THRESHOLD:
        resp = response_builder.build(result, lang)
        if resp:
            return resp

    # Step 3: Medium confidence -> try LLM for smarter answer
    if self._check_available():
        llm_resp = self._query_llm(msg, lang, result)
        if llm_resp:
            return llm_resp

    # Step 4: LLM unavailable → rule engine best-effort
    if confidence >= LOW_THRESHOLD:
        return response_builder.build(result, lang)

    # Step 5: Nothing works → caller handles it
    return None

No single point of failure. Every step has a fallback.

Type "cpu" → keyword confidence is 0.95 → Step 2 handles it instantly. Rule engine. Deterministic. No LLM involved.

Type "why is my computer acting weird today" → keyword confidence is 0.30 → Step 2 skips → Step 3 sends it to Ollama with full system context → if Ollama is down, Step 4 gives a best-effort rule response.

Type "how are you" → intent is "small_talk" → Step 1 sends it straight to LLM → if unavailable, rule engine returns a canned friendly response.

I didn't want Ollama for everything, it's slow (2-5 seconds).
I didn't want if/else for everything, it can't handle questions
I didn't anticipate.
So I gave every message a confidence score and
let the score decide which engine handles it.

4. Intent-Aware Temperature - The Surgeon vs The Friend

Every AI tutorial I've seen uses one temperature setting. Global. Static.
Same creativity level whether you're asking about CPU specs or saying hello.

I use 20 different temperatures.

_INTENT_TEMPERATURE: Dict[str, float] = {
    # Factual / diagnostic - precision over creativity
    "hw_cpu":         0.35,   # wrong MHz is bad advice
    "hw_gpu":         0.35,
    "temperature":    0.35,
    "throttle_check": 0.35,
    "stats":          0.35,
    "disk_health":    0.35,
    "ram_why_high":   0.40,
    "why_slow":       0.45,

    # Optimization - some creativity welcome
    "performance":    0.55,
    "optimization":   0.55,
    "speed_up_pc":    0.55,
    "health_check":   0.50,

    # Conversational - warmth and personality
    "small_talk":     0.80,   # "how are you" deserves a human answer
    "about_program":  0.65,
    "help":           0.60,
}

temperature = _INTENT_TEMPERATURE.get(intent, TEMPERATURE)  # default 0.72

"What CPU do I have?" -> 0.35. I want a surgeon.
The answer is a fact: Intel Core i7-12700H, 14 cores, 4.7 GHz boost.
There is exactly one correct answer.
Creativity here means wrong numbers.

"How are you?" -> 0.80. I want a friend.
Warmth, personality, maybe a joke.

"Why is my PC slow?" -> 0.45. Somewhere between.
The diagnostic needs to be accurate, but the explanation should be readable, not a data dump.

One line of code.
Massive difference in response quality.
Probably the highest value-per-line-of-code in the entire engine.

5. Fallback Chain with Availability Cache

Ollama runs locally but it's not always there.
Maybe **the user didn't install it.
**Maybe **the model is loading. Maybe it crashed.
**Your assistant can't hang for 30 seconds waiting to find out.

AVAILABILITY_TTL = 300   # re-check Ollama every 5 minutes

def _check_available(self) -> bool:
    now = time.time()

    # Respect the cool-down from previous failures
    if now < self._temp_unavail_until:
        return False

    # Cache: don't ping /api/tags on every message
    if self._available is None or (now - self._available_checked_at) > AVAILABILITY_TTL:
        self._available            = self._ollama.is_available()
        self._available_checked_at = now
        if self._available:
            self._pick_best_model()   # llama3.2 > mistral > phi3 > gemma > first available

    return bool(self._available)

def _query_llm(self, msg, lang, result):
    try:
        raw = self._ollama.generate(model=self.model, ...)
    except Exception:
        self._temp_unavail_until = time.time() + 60   # crash -> 60s cool-down
        return None

    if not raw:
        self._temp_unavail_until = time.time() + 30   # empty -> model loading, 30s
        return None

    return self._format_response(raw, lang)

Two levels of cool-down. Empty response (model loading) ->** 30 seconds*. Exception (crash, timeout) ->* 60 seconds*.
Full availability re-check -> **every 5 minutes*.

The user never waits for a ping. If Ollama was unavailable 10 seconds ago, the engine routes to rules immediately.
Answer in milliseconds instead of a spinner.

_pick_best_model() runs once on availability check:
llama3.2 > mistral > phi3 > gemma > whatever is installed.
If you have multiple models, hck_GPT picks the best one automatically.

6. Session Memory - AI That Remembers What It Said 3 Messages Ago

Most chatbot tutorials treat every message as independent.
User asks about RAM. Gets an answer.
User asks about system health. Gets a generic response that doesn't mention the RAM issue from 30 seconds ago.
hck_GPT remembers.

# When answering a RAM question - save the data:
session_memory.record_response_data("hw_ram", {
    "total_gb":    16,
    "speed":       3200,
    "current_pct": 78,
    "typical_avg": 51,
})

# Later, in a different handler (health_check) - reference it:
def _resp_health_check(self, r, lang):
    ram_sess = session_memory.get_response_data("hw_ram")

    if ram_sess.get("total_gb") and ram > 70:
        lines.append(
            f"  (Your {ram_sess['total_gb']} GB RAM we discussed earlier"
            f" - now at {ram:.0f}%, that's worth watching)"
        )

No SQLite. No JSON file. Just a dict:
{intent: {key: val, recorded_at: timestamp}}.
Lives in RAM for the session. When the app closes, it's gone.
That's intentional, session memory shouldn't outlive the session.

There's also trend tracking fed by snapshots every 30 seconds:

def get_trend(self, metric: str = "cpu") -> str:
    buf = self._cpu_trend if metric == "cpu" else self._ram_trend
    readings = list(buf)   # circular buffer of last 8 readings
    if len(readings) < 4:
        return "stable"
    mid        = len(readings) // 2
    first_avg  = sum(readings[:mid]) / mid
    second_avg = sum(readings[mid:]) / (len(readings) - mid)
    delta      = second_avg - first_avg
    if delta > 5:  return "rising"
    if delta < -5: return "falling"
    return "stable"

Split the buffer in half. Compare averages. Rising, falling, or stable. This lets hck_GPT say "your CPU has been climbing for the last few minutes" instead of just showing the current number.

7. System Prompt with Live PC Context — Facts, Not Vibes

When a message reaches Ollama, the LLM doesn't guess about your system.
It gets injected context built from real data:

== Live System State ==
CPU: 67%  @ 3840 MHz / max 4800 MHz
RAM: 71%  (11.4/16.0 GB used,  4.6 GB free)
Disk C: 48.3 GB free / 476.0 GB total

== Today's Averages ==
CPU avg: 34.2%  peak: 89.0%
RAM avg: 68.1%

== Top Processes (by CPU) ==
  chrome.exe       CPU 18.4%  RAM 892 MB
  code.exe         CPU 12.1%  RAM 441 MB
  python.exe       CPU  3.2%  RAM 156 MB

== Hardware Profile ==
CPU: Intel Core i7-12700H  (14 cores, boost 4.7 GHz)
GPU: NVIDIA GeForce RTX 3060  VRAM: 6 GB
RAM: 16.0 GB @ 3200 MHz

== Today vs Typical ==
CPU today 34% vs typical 28%  /\ (+6%)
RAM today 71% vs typical 51%  /\ (+20%)

== Learned Usage Patterns ==
Typical CPU avg (7-day baseline): 28%
Heaviest app this week: chrome.exe

Each section comes from a different module. psutil for live data.
SQLite for historical averages. WMI for hardware profile.
The Stats Engine for 7-day baselines.

The "Today vs Typical" section is the difference between an assistant that says "CPU 67%" and one that says "CPU 67% — but your normal is 28%, something is off." Context, not just data. That's the whole philosophy in two lines of a prompt.

What This Costs vs The OpenAI Approach

	hck_GPT (this approach)	pip install openai
Dependencies	zero (beyond psutil)	openai, tiktoken, etc.
Model size	zero (rule engine is pure Python)	N/A (cloud)
API costs	zero	$0.002-0.06 per message
Latency	<1ms rules, 2-5s Ollama	500-2000ms
Internet	not required	required
Privacy	data stays local	sent to OpenAI servers
RAM	~5MB	N/A

What I'd Do Differently

The intent vocabulary is hand-built.
~200 patterns across 25 intents.
Every time a user asks something I didn't anticipate,
I add patterns manually. This doesn't scale past maybe 50 intents.
A lightweight local classifier (even scikit-learn with TF-IDF) would handle the long tail better.

The confidence thresholds (0.60, 0.35, 0.20) were tuned by testing, not by math. They work for my use case but they're not optimal.
A proper evaluation dataset would help.

Session memory is per-session only. The user knowledge base (SQLite in AppData) stores hardware profiles and usage patterns, but conversation context doesn't persist across restarts yet.

Why I'm Writing This

Every "build an AI assistant" tutorial I found in 2026...
starts with pip install langchain or pip install openai.
Cloud API. Token costs. Internet required.
That's fine for some use cases.

But if you're building a desktop app that runs on someone else's machine, behind their firewall, on their data, you need a different approach.
This is that approach: a hybrid engine that's fast when it can be, smart when it needs to be, and never crashes because a server is down.

PC Workman is open source, MIT licensed.
The full AI engine is in hck_gpt/- intent parser, hybrid engine, response builder, session memory, context builder.
Read it, fork it, build something better.

Try It

Download the .exe (no Python needed): GitHub Releases

Read the source: github.com/HuckleR2003/PC_Workman_HCK

All my links: linktr.ee/marcin_firmuga

If you build something with a similar approach,
or if you'd do it completely differently.
I want to hear about it!

I'm Marcin Firmuga, solo developer and founder of HCK_Labs.
Building PC Workman publicly between retail shifts.
**800+ hours, 25 GitHub stars, and one offline AI engine that grew 9 layers when I wasn't looking.

Follow the build: GitHub · LinkedIn · X · Medium

Why I Sign Every .exe With Sigstore - PC Workman v1.7.2 Release, Security-First Open Source

Marcin Firmuga — Tue, 28 Apr 2026 21:43:04 +0000

Someone tried to scare me with a security audit. It backfired.

A few days ago, a stranger on the internet found PC Workman — my open-source system monitor — downloaded the .exe, and before running it, did what any sane person should do in 2026: they ran a full security audit.

Not a quick VirusTotal check. A proper audit. They used Claude to analyze the codebase, the build pipeline, the permissions model, the network behavior, everything.

Then they sent me the results. I think they expected me to panic.
Instead I replied: "Can I see the full report?"

They shared it. The audit confirmed what I already knew — clean code, no telemetry, no hidden network calls, no suspicious behavior. They ended up becoming a tester.

This is the story of PC Workman v1.7.2, the biggest release in the project's history, and why security isn't something I added after the fact. It's baked into how I build.

Why Nobody Trusts .exe Files Anymore (And Why They Shouldn't)

Let's be honest. Downloading a random .exe from GitHub in 2026 is a trust exercise most people fail. And they're right to fail it.

Open-source doesn't mean safe. It means auditable. The code being public is step one. But if you're shipping executables, you need to prove that the .exe you're distributing was actually built from that public code, wasn't tampered with, and doesn't phone home.

Most solo developers skip this entirely. They push a PyInstaller build to releases, write "trust me bro" in the README, and wonder why downloads stay low.

I decided early on that if PC Workman was going to ask for system-level access — reading CPU temperatures, monitoring processes, scanning Windows registry — then security couldn't be an afterthought.

What Security Actually Looks Like in PC Workman

Sigstore Digital Signatures

Every release gets signed with Sigstore. This is the same signing infrastructure used by Kubernetes, npm, and PyPI. It creates a cryptographic proof that ties the executable to my GitHub identity and logs it in a public transparency ledger.

Anyone can verify it:

sigstore verify github PC_Workman_HCK_1.7.2.exe --bundle sigstore.bundle

If the signature doesn't match, the file was tampered with. Don't run it.

VirusTotal — 70+ Engines, Every Release

Before any .exe goes public, it gets uploaded to VirusTotal and scanned against 70+ antivirus engines. Current result for v1.7.2: 0 detections.

You don't have to take my word for it. Go to virustotal.com, upload the file yourself, and check.

GitHub CodeQL — Automated on Every Commit

CodeQL runs on every push to main. It scans for common Python vulnerability patterns: injection attacks, path traversal, insecure deserialization, hardcoded secrets. If something triggers, it blocks the commit.

This isn't something I run occasionally. It runs on every single commit, automatically.

SECURITY.md — 445 Lines of Policy

Most GitHub repos either don't have a security policy, or they have a template that says "email me." PC Workman's SECURITY.md is 445 lines covering:

Supported versions and update timeline
How to report vulnerabilities (private GitHub reporting + email)
Response timeline (24h acknowledgment, 72h validation, 7 days for critical fixes)
CVSS severity classification
Dependency management process
Detailed verification instructions for every release
FAQ addressing trust questions directly

It exists because if you're asking users to run your code with admin privileges, you owe them a complete answer to "why should I trust this?"

What PC Workman Does NOT Do

No telemetry. Zero. Nothing phones home.
No analytics. No tracking. No user profiling.
No cloud dependency. Core monitoring is 100% offline.
No data leaves your machine unless you explicitly use the optional AI features.

The network section of the audit came back clean because there's nothing to find.

v1.7.2 — What Actually Changed

Now for the release itself. The last downloadable .exe was v1.6.8 from March. That was a monitoring tool that collected data and showed it to you.

v1.7.2 is a different animal. It acts on what it finds.

Hybrid AI Engine (Complete hck_GPT Rewrite)

The AI layer went from a single chat_handler.py file to a modular engine with 5 subpackages: engine/, intents/, memory/, context/, responses/.

The routing logic is simple: known intents (stats, alerts, temperature, processes) hit the rule engine first. Fast, predictable, zero external dependency. Open-ended questions ("why is my PC slow right now?") get forwarded to Ollama — a local LLM that runs on your machine. No cloud API. No API key. No tokens.

If Ollama isn't installed, the engine falls back gracefully. No crashes, no error messages about missing services. It just uses what it has.

Every response is bilingual. Polish or English, auto-detected per message. The parser uses ASCII-fold dual scoring to handle Polish diacritics without breaking intent matching.

There's also a proactive monitor running as a background daemon. It watches for sustained CPU pressure (>80% for 30 seconds), RAM warnings (>85%), throttling, low disk space, and long session uptime. When something triggers, it pushes an alert to the chat panel. You don't have to ask. It tells you.

Startup Manager

Full page that reads from three Windows registry hives (HKCU, HKLM, WOW6432Node). No admin rights needed for reading. Knowledge base of 30 common programs with impact ratings (High/Medium/Low). Three panels: programs to optimize, programs safe to disable, and the full list.

Disable means real winreg.DeleteValue() — but only after a confirmation dialog. Nothing gets removed silently. User choices persist to JSON between sessions.

Services Manager

Catalogue of 40+ Windows services sorted into four categories: Essential (locked, can't be touched), Recommended, Optional, and Likely Unnecessary. Each row shows current status, startup type, and action buttons (Stop/Start/Restart).

The interesting part is the TURBO Mode integration. You select which non-essential services should auto-stop when TURBO activates. When TURBO deactivates, they restore to their previous state. Selections persist between sessions. All changes get logged.

Admin detection is built in — if you're not elevated, the manager shows a warning banner instead of pretending the buttons work and failing silently.

Optimization Hub

The old single "Optimization & Services" button in My PC Central got replaced with a 3-zone interactive Canvas widget. Left zone: Optimization Center. Top-right: Startup Manager with live registry entry count. Bottom-right: Services Manager with running service count. Hover brightens the active zone. Metrics update from a background daemon thread.

Everything Else

First Setup & Drivers page with arc gauge health score computed from driver ages and startup count. Reads directly from Windows registry. No internet, no third-party API.
Dashboard nav buttons fully redesigned — dark gradients, bordeaux brackets, 7 vector icons drawn on Canvas (zero image files).
Inter font via GDI32 with Segoe UI fallback.
HCK_Labs and Guide pages redesigned as full blog layouts.
Efficiency tab fixes: correct physical core count, per-core session stats, side-by-side TOP CPU/RAM consumers.
4 new query_api methods: temperature history, temperature summary, top processes lifetime, weekly comparison with trend detection.
hck_GPT language bug fixed, temperature fallback fixed, unconditional TURBO tip removed.
Complete .exe packaging rewrite: 25+ hidden imports, settings directory bundled, proper output naming.

The Numbers

Version: 1.7.2
Commits since last .exe: ~60
New modules: 8
GitHub stars: 25
Downloads: ~100+
Hours logged: 800+
VirusTotal: 0/70 detections
Sigstore: Signed and verified
CodeQL: Active on every commit
SECURITY.md: 445 lines
Telemetry: None. Zero. Nothing.

Why I Ship .exe Files (And Why More Developers Should)

Most open-source projects live and die on GitHub. The README says "clone the repo, install dependencies, run startup.py." That's fine for developers. For everyone else, the project doesn't exist.

Shipping an executable is harder. You deal with PyInstaller nightmares (8 hours debugging hidden imports for v1.6.8), false positive antivirus detections, signing infrastructure, and the constant question of "how do I prove this is safe?"

But it's also where the real feedback comes from. Source code users are patient. They expect rough edges. .exe users click the button and expect it to work. That's the standard worth building toward.

v1.7.2 is the second .exe I've ever shipped. The first was v1.6.8 in March — a monitoring tool with placeholder buttons and a neon green Turbo Boost card. The app barely resembles that version now.

If you want to try it, the .exe is on GitHub Releases. If you want to audit it first, the source is right there. If you want to verify the signature, the instructions are in SECURITY.md. If you find something wrong, the reporting process is documented.

That's how it should work.

What's Next

v1.7.3 through v1.7.8 will build out the TURBO suite: suspending inactive background processes, auto power plan switching, CPU core unparking, and full integration testing.

v2.0 targets Microsoft Store publishing and Ollama as a first-class local AI option.

Next week I start Umiejętności Jutra 3.0 — Google's AI certification program through SGH. First structured learning since I finished technikum. Curious how it'll shape the roadmap.

PC Workman is open source, MIT licensed. 800+ hours of solo development between retail shifts. Still shipping. Still signing. Still scanning.

Star the repo: github.com/HuckleR2003/PC_Workman_HCK

All my links: linktr.ee/marcin_firmuga

I'm Marcin Firmuga, solo developer and founder of HCK_Labs. Building PC Workman publicly, honestly, between Żabka shifts. Follow the build: GitHub · LinkedIn · X/Twitter · Medium

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.