DEV Community: Marcin Firmuga

[Boost]

Marcin Firmuga — Sat, 25 Jul 2026 07:00:16 +0000

Marcin Firmuga

Jul 24

I Had a 6,533-Line Python Response Builder. It Still Worked. That Was the Problem.

#python #architecture #opensource #refactoring

10 min read

I Had a 6,533-Line Python Response Builder. It Still Worked. That Was the Problem.

Marcin Firmuga — Fri, 24 Jul 2026 23:52:39 +0000

PC Workman has a small offline assistant called hck_GPT.

It reads local sensor data, workload history, process information and hardware details. It answers in Polish or English. No account, no cloud, no machine data leaving the PC.

By v1.8.5, it had 96 intents, also had one file called builder.py.
That file was 6,533 lines long.

And it still worked.
That was the problem.

The file did not become ridiculous overnight

There was no single bad decision that created the monolith.
It grew ten lines at a time.

One new intent, one new response.

A Polish version beside the English one, a helper added near the bottom because I was already in the file.

A tester asks:

“Can it explain why my laptop is warm?”

So I add _resp_temperature().

Someone else asks:

“Can it tell me if I can run this game?”

So I add _resp_game_can_run().

Then startup questions.
Then RAM questions.
Then thermal history.
Then upgrade compatibility.
...

Every commit looked reasonable on its own.

That is how technical debt usually gets in.

Not through one obviously stupid decision.

Through a hundred small decisions that each save ten minutes.

Eventually ResponseBuilder had 96 handlers in one class:

class ResponseBuilder:
    def _resp_temperature(self, result, lang):
        ...

    def _resp_why_slow(self, result, lang):
        ...

    def _resp_game_can_run(self, result, lang):
        ...

    def _resp_full_specs(self, result, lang):
        ...

    # 92 more

File opened slowly enough that my editor paused for a beat.
More importantly, I had stopped wandering through it.
I opened it only when I already knew exactly what I needed.

I avoided shared helpers because I could not remember what else they touched.

I postponed cleanup because even a small change meant scrolling past thousands of unrelated lines.

File was not impossible to understand.

It was just unpleasant enough that I stopped improving the parts around the task.

That was worse.

A file you are afraid to open is a file you have already stopped improving.

Why I finally touched it

I build PC Workman at night after working in a plastic-repair shop in Radom, Poland.

For a long time, that made the project feel private.

Messy code was my problem.
A slow page was my problem.

A version string copied into eight files was ugly, but nobody depended on it except me.

Then PC Workman reached the Microsoft Store.

Nothing changed in the repository that day.

Same files. Same functions.
Same 6,533-line builder.

But strangers could now click Install and run it on machines I would never see.

That changed what I was willing to ignore, project had users.

A tester offered a Ryzen 9 and RTX 4090 system as a test bench because I did not own hardware like that.

People started sending screenshots of PC Workman learning their machines.
Someone sent the first meaningful 50 PLN support payment.
These are small numbers by company standards.

For a solo project built after physical shifts, they changed the weight of the work.

Code no longer felt like a private mess I could clean “someday.”

So I opened builder.py and started cutting.

The one rule: do not break the public seam

Rest of the application talked to the response layer through one call:

response_builder.build(result, lang)

The chat panel used it, proactive monitor used it.
Test suite used it.

I could have redesigned the whole response API while splitting the file.
I did not.

I wanted one side of the refactor to stay completely still.
My rule was:

Move the implementation. Do not move the door.

That meant keeping:

ResponseBuilder;
build(result, lang);
_resp_<intent> handler names;
alias resolution;
bilingual output;
unsupported-intent behavior;
every existing caller import.

A refactor that changes every caller at the same time is difficult to trust.

If something breaks, you no longer know whether the problem came from moving code or changing the contract.

So the contract stayed.

The facade stayed. The body moved out.

ResponseBuilder became a facade composed from domain mixins:

class ResponseBuilder(
    HardwareResponses,
    UpgradeResponses,
    ThermalResponses,
    GamingResponses,
    SystemResponses,
    PerformanceResponses,
    InsightsResponses,
    AssistantResponses,
):
    """Build bilingual responses for every parsed intent."""

The word “facade” sounds fancier than the idea, rest of the application still knocks on the same door.
Rooms behind it are just no longer one giant hall.

Each mixin contains one group of handlers:

class ThermalResponses:
    def _resp_temperature(self, result, lang):
        ...

    def _resp_fan_speed(self, result, lang):
        ...

    def _resp_thermal_history(self, result, lang):
        ...

Mixins are not separate services.
They do not have their own lifecycle,they are slices of one object, separated because the methods change for different reasons.

That distinction mattered.

I was not trying to build an architecture diagram impressive enough for LinkedIn.

I was trying to stop one file from becoming the place where every future feature went to die.

The dispatcher did not move

The existing dispatch logic was already useful:

intent = self._INTENT_ALIASES.get(
    result.intent,
    result.intent,
)

handler = getattr(
    self,
    f"_resp_{intent}",
    None,
)

if handler is None:
    return None

return handler(result, lang)

For an intent such as:

temperature

the builder looks for:

_resp_temperature

getattr() performs that lookup on the final ResponseBuilder instance.

Python’s method resolution order walks through the mixins and finds the method.

It does not care whether _resp_temperature() lives inside the old builder.py or the new r_thermal.py.

The dispatch path stayed:

parsed intent
    -> alias resolution
    -> "_resp_<intent>"
    -> method lookup
    -> response

Filename was never part of the contract.

That made the extraction almost invisible from outside the package.

I split by subject, not by size

I did not create eight equal files.
Two equally large files can still be two badly organised files.
I grouped handlers by what they answer.

Module	Handlers	Responsibility
`r_hardware.py`	25	CPU, GPU, RAM, disks, motherboard, full specs
`r_insights.py`	15	trends, comparisons, session digests, what changed
`r_performance.py`	13	load, throttling, why the PC is slow
`r_system.py`	13	health, processes, startup, security
`r_thermal.py`	11	temperatures, fans, voltage baselines
`r_assistant.py`	11	greetings, help, context recall
`r_gaming.py`	6	game compatibility and gaming history
`r_upgrade.py`	2	offline hardware compatibility

Two more files carry shared work:

common.py
flows.py

common.py holds things such as:

bilingual text selection;
number formatting;
follow-up hints;
labels such as +23% above your norm.

flows.py holds guided conversations that take more than one message.
The old builder.py dropped from 6,533 lines to under 600.

Its job is now boring:

compose the mixins;
resolve the intent;
call the handler;
return the answer.

That is exactly what I wanted.

The smallest module showed the biggest change

r_upgrade.py started with only two handlers.

It could easily have been pasted into an existing file.

A year earlier, that is what I would have done.
New feature would have landed wherever the cursor already was.

This time it received its own module from the first line.
Two handlers, lots of empty room.

That may sound trivial, but it is the cleanest proof that the refactor changed more than file sizes.

Next feature had somewhere sensible to live.

Mixins solved one problem and introduced another

Mixins were useful here, but they have a sharp edge.
Two mixins can define the same method:

class ThermalResponses:
    def _resp_health_check(self, result, lang):
        ...

class SystemResponses:
    def _resp_health_check(self, result, lang):
        ...

Python does not complain.

One method wins according to inheritance order.

The other remains in the repository, looks correct during review and never runs.

That is exactly the kind of bug I do not want in a response system.

Nothing crashes.

The answer simply comes from the wrong handler.

So I added a test that scans every response module and rejects duplicate _resp_* names:

all_defs = []

for path in glob.glob(_RESPONSES_GLOB):
    source = _read(path)

    all_defs += re.findall(
        r"def (_resp_[a-z0-9_]+)\(",
        source,
    )

duplicates = {
    name
    for name in all_defs
    if all_defs.count(name) > 1
}

self.assertEqual(duplicates, set())

It is not clever, it does not need to be.
Handler naming convention is strict, so a simple structural test is enough.

Important part is that silent MRO shadowing now turns the build red.

I also added a test against my future laziness

Splitting the monolith once was not enough.
Pressure that created it still exists.

At 11 PM, adding a handler to an existing module will always feel faster than deciding whether the module should split.
A README note would not stop me.

So every response module now has a line limit:

def test_monolith_guard(self):
    for path in glob.glob(_RESPONSES_GLOB):
        line_count = _read(path).count("\n") + 1

        self.assertLess(
            line_count,
            1600,
            (
                f"{os.path.basename(path)} has "
                f"{line_count} lines - split it "
                "instead of growing another monolith"
            ),
        )

The number 1600 is not a universal clean-code law.
A 1,601-line file is not automatically terrible.

A 300-line file can still be nonsense.
This is a project-specific ratchet.

It says:

No response domain is allowed to become the next 6,533-line dumping ground.

The failure message is deliberately plain.

Not:

Architecture policy violation

But:

split it instead of growing another monolith

That message is for me six months from now.

A refactor without a ratchet is just a delay.

Before and after

Before

hck_gpt/
└── responses/
    └── builder.py       # 6,533 lines

After

hck_gpt/
└── responses/
    ├── builder.py       # facade + dispatch, under 600 lines
    ├── common.py
    ├── flows.py
    ├── r_assistant.py
    ├── r_gaming.py
    ├── r_hardware.py
    ├── r_insights.py
    ├── r_performance.py
    ├── r_system.py
    ├── r_thermal.py
    └── r_upgrade.py

Public call stayed the same:

response_builder.build(result, lang)

Maintenance experience did not.

Now:

thermal responses live with thermal responses;
hardware work does not require scrolling past greetings;
duplicate handlers fail CI;
oversized modules fail CI;
new domains have an obvious starting point;
callers remain untouched.

The same release fixed a two-second UI delay

The builder was the biggest refactor in v1.8.5, but not the only one.

The My PC page used to take about two seconds to reopen.

I blamed the charts first.

Then the amount of hardware data.

The actual reason was much less glamorous:

two wmic calls on the UI thread

One fetched the CPU name and one fetched the disk model. Each could wait up to three seconds.
On current Windows systems, wmic can be painfully slow.

The page was paying that cost during an interactive action.
Fix was simple once the cause was visible:

Collect stable hardware identity once during startup.
Reuse the cached identity.
Build the page once.
Keep it alive instead of destroying and rebuilding it.

The page now reopens in roughly 1–17 ms.
Lesson was not “never use wmic.”

It was:

Stable hardware identity does not belong on the path that must feel instant.

The version number lived in eight places

The app version had another quiet failure, it existed in eight files they had already drifted.

Title bar could report one version while the single-instance logic searched for a different window title.

A second launch would then fail to focus the copy already running.

Nothing dramatic happened.
The app just behaved slightly wrong.
Version now has one source of truth.

A test scans for hardcoded duplicates and fails if the number starts spreading again.

This pattern became common across the release:

bug
    -> root cause
    -> fix
    -> regression test
    -> build guard

Fixing the current problem is useful.

Making the same class of problem harder to reintroduce is better.

Test suite went from 21 to 194

In June, PC Workman had 21 tests.

By v1.8.5, it had 194.
Number is not the interesting part, what matters is where the tests came from.

Many were written after failures:

intent patterns with no response handler;
Store installs writing into a read-only path;
protected Windows processes being treated like normal apps;
anti-cheat processes missing from safety rules;
background daemons starting twice;
learning engines receiving no usable sensor data;
version strings drifting;
response modules growing without a boundary;
duplicate handlers hiding behind mixin order.

That is the closest a solo project gets to institutional memory.

There is no team meeting where somebody says:

"Remember the bug from three months ago?"

Test says it every time the code changes.

What I deliberately did not do

I did not rename everything

Moving and renaming at the same time makes failures harder to trace.
I moved first. Names can improve later.

I did not replace the public API

A new registry or explicit service composition might be cleaner eventually.

That was not job of this refactor.
Job was to reduce maintenance risk without creating a second project.

I did not chase equal file sizes

Line count is a guard, not a design method.
Real boundary is responsibility.

I did not pretend mixins are perfect

They preserve shared state and the current public object.
They also make inheritance order matter, that is why the collision test exists.

I did not try to remove every piece of technical debt

That would have turned one safe extraction into an endless rewrite.
Codebase only needed to become safer for the next change and that was enough.

When this pattern makes sense

A facade plus domain mixins can be a reasonable bridge when:

callers already depend on one stable object;
many handlers share the same state;
methods follow a strict naming convention;
preserving the public surface matters;
the immediate problem is ownership and navigation;
tests can guard name collisions and module growth.

It is a poor fit when:

each domain needs separate mutable state;
components have independent lifecycles;
dependency boundaries must be explicit;
method names overlap naturally;
inheritance order becomes business logic;
separate services can be introduced without breaking callers.

This is not "the correct Python architecture.", but smallest safe move from one bad state to a better one.

What actually changed

From the user’s point of view, almost nothing.
They still ask a question.
Parser still produces an intent, builder still calls:

_resp_<intent>

The same public method still returns the answer.
From my point of view, codebase changed completely.
File I avoided is gone.

The new upgrade feature has its own home, UI no longer waits on slow hardware calls, version number stopped disagreeing with itself.

And the build now refuses several mistakes that used to survive quietly.

That is the part of refactoring people rarely screenshot, Not smaller file. The fear disappearing from the next change.

PC Workman is free, open-source and offline by design.

The response-builder split, the architectural guards, the My PC speed-up and the expanded test suite ship in v1.8.5.

❤️ If you want to support me, click here :) ❤️

I am Marcin “HCK” Firmuga from Radom, Poland. I repair and weld plastic during the day, then build PC Workman at night. I write about the code that shipped, the assumptions that failed, and the fixes that now have tests behind them.

From a Warehouse Floor to the Microsoft Store - PC Workman Marcin Firmuga

Marcin Firmuga — Sun, 19 Jul 2026 13:39:57 +0000

Originally published on pcworkman.dev.
Hire me! - LinkedIn :)

There is a temperature a cheap laptop reaches right before it gives up. Mine hits it at 94°C. Fans scream.

For most of last year, that scream was the soundtrack to my nights.

I did not code through those nights out of passion.
I coded because I was scared that if I stopped moving I would vanish,
same quiet way twelve dead projects before this one vanished, and the same quiet way I almost did at twenty-two.

This morning that fear got the strangest answer I can imagine.

PC Workman, the Windows monitor I built on that screaming laptop, alone, broke, between shifts, is live on the Microsoft Store.
It is not a ZIP on some forum and it is not a repo you have to clone.
It is a real listing, in the same store as the software I grew up thinking only companies could make.

Let me tell you how a barcode scanner got there. I will show you the good parts and the desperate parts, and I will show you the actual code, because the code is where both of them ended up.

PC Workman 1.8.0. Live everything, plus an AI that actually explains it.

The number you never see cross a line

My father died when I was seventeen.
I did not break that week. I broke slowly, over two or three years, and that is the part nobody warns you about. There is no moment. There is no line you catch yourself crossing.

It works like a power rail sagging. Twelve volts becomes 11.9, then 11.8, and every single reading is still "within spec", so nothing alarms. Then one day you look at the number and it is simply wrong, and you cannot say when that happened. Somewhere around twenty-two, that was me. I gave up on myself quietly, the way almost everyone does it.

Remember that rail. It comes back later, in code, and I mean that literally.

The warehouse

Nine months in a warehouse in the Netherlands. Fifteen kilometres a day on foot, scanning barcodes, for nineteen złoty an hour that turned into about fifteen after deductions.
Call it three and a half euros.
I did the math on a break once:
a full nine-hour shift bought roughly one month of the cheapest server hosting I was dreaming about, and I never rented it, because rent for myself came first.

The rhythm was fixed. Shift from morning to evening, dinner from a pan, then six hours at night on a 2014 laptop that thermally throttled if I compiled anything twice in a row.
People ask how long the project took and the honest unit is not months.
It is nights.

Then, three days before Christmas, the same people who had smiled at me for weeks smiled again and said:

"You didn't pass the trial. Tomorrow, goodbye. And out of the apartment."

The 22nd of December. Suitcases stood by the door before I finished understanding the sentence. Two dogs were waiting for me in another country and I had maybe a month of money left.

22 December. I stood in a corridor and shouted that I wasn't a terrorist, three days before Christmas, in a language that wasn't mine. Long story. Different post.

I did not open a job board that night and I did not write my hundredth identical CV. I opened my editor and started rebuild number four of the monitor. Three weeks later I shipped the first .exe.
Twelve projects had died before it.
I did not know yet that this was the one that would refuse to.

The truest sentence I own from that year: build something, commit something, watch a progress bar move, and feel like you exist. Nobody frames that on a wall. That year it was survival.

What I actually built

PC Workman answers the question every other monitor dodges:
not whether your PC is slow, you already know that, but why.

You ask it in plain language, through hck_GPT, an assistant that runs entirely on your machine. Under the hood it is a hybrid:
a rule engine with 90 intents and a multi-layer router, plus an optional local model for open questions.
There is no cloud, no API key, and nothing you type ever leaves your computer.

The routing is unglamorous and that is deliberate.
A message gets tokenized, accent-folded (Polish users type both "wentylatory" and "wentylatory" without diacritics), scored against every intent's phrase list, blended with a small naive-Bayes classifier, and dispatched by name:

result  = parser.parse("why is my pc slow")
# ParseResult(intent="why_slow", confidence=0.92, ...)

handler = getattr(builder, f"_resp_{result.intent}", None)
if handler:
    lines = handler(result, lang)   # bilingual, built from live data

Every handler is a plain method that reads live sensors and real history.
When the data is missing, the assistant says so instead of inventing a number. I wrote that rule into the code review checklist on day one:

an assistant that guesses about your hardware is worse than no assistant.

I could have shipped pip install openai in an afternoon.
I decided not to, and it was a product decision, not a technical one.
A monitor that reads your machine and then phones a stranger's server to explain it is a contradiction. So the whole intelligence layer runs in the same process that draws the charts, and the privacy page needs one sentence instead of a lawyer.

hck_GPT. No internet, no key, nothing sent anywhere. It reads your live machine and answers in plain language.

A monitor with a memory

Part I actually lose sleep over is memory.

Every monitor on earth forgets you the second you close it. HWiNFO, Afterburner: open them tomorrow and they will draw your 78°C against the exact same line they draw for every machine that has ever existed.

The most useful number a monitor can give you is not the temperature.
It is whether this temperature is normal for you, on your machine, doing what you are doing right now.

So every reading lands in one of five workload buckets:
idle, light, medium, heavy, gaming.
Each bucket keeps its own learned normal, folded forward with a Welford accumulator. Three numbers per bucket, updated in constant time, never recomputed from scratch:

def _welford_add(acc, x):
    """Fold one sample into a running accumulator (Welford, 1962)."""
    n     = acc["n"] + 1
    delta = x - acc["mean"]
    mean  = acc["mean"] + delta / n
    acc["n"]    = n
    acc["mean"] = mean
    acc["M2"]   = acc["M2"] + delta * (x - mean)

The payoff is a verdict instead of a reading. The same 82°C is fine in the middle of a gaming session and alarming on an idle desktop.
Same number, opposite meaning, and the difference lives entirely in the learned history.
After twelve days on my own machine the idle bucket is calibrated on 613 samples and the gaming bucket is trained on 115, so when something is 14% above my normal, the app can say exactly that.

The oldest math in the project

Voltages get statistics older than my parents. For each rail the analyzer learns a median and a MAD (median absolute deviation), then judges every new sample with a modified z-score.
This is real code from voltage_analyzer.py, not a sketch:

def modified_z(self, value: float) -> float:
    """Modified z-score: M = 0.6745 * (x - median) / MAD.
    Returns 0.0 if MAD is effectively zero (constant signal)."""
    if self.mad < 1e-6:
        return 0.0
    return 0.6745 * (value - self.median) / self.mad

@property
def normal_band(self) -> tuple[float, float]:
    """The tight 'expected' operating band for this rail."""
    w = Z_WATCH * _K * self.mad      # _K = 1.4826, consistency factor
    return (self.median - w, self.median + w)

On top of that sit Nelson rules from 1984: nine points on the same side of the median, six points trending one direction.
Those rules exist to catch exactly one thing a threshold never will:
the slow sag. A rail that drifts from 12.05 V to 11.88 V over weeks trips no limit, because every individual reading is legal. The pattern is the alarm.

Now, the rail from earlier. I am the one that sagged for three years inside spec while everyone, me included, swore nothing was wrong.

I built the alarm I never had. It is statistics from the sixties babysitting a power supply, boring and predictable, and that is exactly why I trust it. Statistics never hallucinate. People do.

People looked me in the eye at 3.5€ an hour and said the rate would improve. It never improved. The math, at least, never lied to me.

A year, measured in releases

You never see the grind. You see the version number.

Here is the receipt. It started as a prototype that could barely draw a graph. Then a first stable .exe.
Then a SQLite stats engine with minute-to-month aggregation.
Then the hybrid AI, a Startup manager, a Services manager.
Its biggest quality jump the project ever had, and then Smart Learning, the release where the monitor finally got its memory.

Eleven releases, over eight hundred commits, four complete rebuilds of the interface. Every one of them written after a shift, on the same warm laptop.

These days it is a welding gun by day. Hot air, melting plastic back together. The welding taught me the one thing the learning engine needed: you don't get an eye for hot metal from a manual. Cherry red, straw, blue that means you've gone too far. It accumulates. You earn it.

Microsoft said no. Then Microsoft said yes.

Two weeks ago I published a post called "Microsoft said no."

My first .msix got rejected, and not for the code.
The blockers were a blurry tile icon and a privacy-policy link that pointed at my security policy instead.

A year of voltage-anomaly math and offline AI, and what stopped me at the gate was a fuzzy PNG. The reviewer was right. It stung anyway.

So I fixed both. I drew a crisp icon, wrote a real privacy policy that lives where a privacy policy should, and folded in thirteen more fixes my testers had found while I waited.
Then I resubmitted and went back to work, because waiting with the app open in another window does not make certification faster.

This morning the status changed to approved.
A rejection that says "fix these two things and resubmit" was never a no.
It was the Store telling me how close I was.

The Store also fixes something on your side of the screen.
You no longer have to trust a stranger's ZIP.

Every build is Sigstore-signed, clean on VirusTotal, and checked by CodeQL on every commit. That paranoia was in the project from the first release. The listing just makes it visible.

What the first weeks on the Store taught me

A listing is a promise, and promises get tested fast.

Within days a tester hit the worst bug of the project's life: under long, heavy sessions the app could freeze the entire computer.

White screen, dead desktop, restart to recover.
A monitor that can freeze the machine it monitors is not a monitor, so everything else stopped until this was dead.

The root cause was one missing guard.
My optimizer had a single primitive that suspends idle processes to save resources, and it checked for anti-cheat software but nothing else. Nothing stopped it from suspending dwm.exe, the process that literally draws the Windows desktop, or from suspending PC Workman itself.

Fix went in at the lowest level, so every optimization path got safe at once:

def sleep_app(self, pid, name, exe, behavior):
    # ONE central guard for every process primitive: anti-cheat engines,
    # ~30 OS-critical processes (dwm, explorer, csrss, lsass...),
    # and PC Workman's own pid. No caller can forget to check.
    if is_protected(name, exe) or is_self(pid):
        return False
    ...

The second lesson was cheaper but it changed how I work:

the test suite went from 21 tests to 46 within two weeks of the listing, > and the most valuable ones are the tests that guard against my own > future mistakes.

A store listing means strangers update on your word.
The suite is what makes that word worth something.

And one more thing nobody tells you:
the first support message from a person you have never met, about a machine you will never see, feels bigger than the approval email did.

The kid who was afraid of disappearing

For the first months I shipped into an empty room. Thirty views on a post.
Zero stars on the repo.
You write into that silence long enough and you start to wonder whether you are really there at all.

Then one of my articles reached forty-four thousand people, and I wrote the most honest thing I have ever put online:

that I keep building because I am terrified of disappearing, and that I > ship code to prove I still exist.

I do not have a clean ending for that fear, and anyone who sells you one is lying.

But I have this. A permanent listing in the Microsoft Store is about the most concrete "I exist" a solo developer can get.
The kid who quietly quit at twenty-two did not stay quit. The rail that sagged inside spec finally got its alarm.

Twelve projects had to die so this one could stand in a store next to software made by companies with a thousand engineers and a real salary each.

I built a program that learns for the entire life of the install.
I learn for the life of mine. This grind is a year old, it has not ended, and it is not going to.

I have finally understood that this is not the tragedy of the story.
It is the proof of it. A finished man has nothing left to recover.
I get to keep going. That is a pulse.

Kacia (11) and Lusia (2). Best teammates for the breaks. Kacia has slept through every release since 1.0. Still here, all three of us.

Thank you. To every tester who spent hours breaking things I would never have found alone. To the strangers whose questions turned into real features. To everyone who starred the repo, read a post, or just said "keep going". This one is yours too.

PC Workman is free and open source (MIT). No accounts, no cloud AI, nothing leaves your machine. Physical work by day, code by night, the same rhythm that built every line of it. The next chapter is already loading.

Still here. Still shipping.

PC Workman is free, runs entirely on your machine, and after a year it's on the Microsoft Store.
1,100+ downloads · 64 GitHub stars · Sigstore-signed · VirusTotal-clean · open source (MIT).

Install it from the Microsoft Store: one click, no account, no cloud.
Not on Windows yet? Star the repo or follow the build. I ship in public, every week.

And I read every single comment: if an AI lived inside your PC, what is the first thing you would ask it? The best questions become real features. Twenty-eight of them already have.

The Man Who Got Himself Back - Marcin HCK Firmuga

Marcin Firmuga — Mon, 29 Jun 2026 07:25:48 +0000

The Man Who Got Himself back
PC Workman 1.8.0 is the release where my system monitor finally learned to remember your machine. It's also the story of the year I spent getting mine back.
I've stopped being able to tell those two apart.

I had to shout at a man that I'm not a terrorist.

SNF (Stichting Normering Flexwonen)
was the only thing that stopped him from putting me on the street that night, out of the apartment the work agency had housed me in for four months. Building was certified. I knew my rights.
He was gambling that I didn't.

So I stood in a corridor somewhere in the Netherlands and screamed the single most absurd sentence of my life, three days before Christmas.
In a foreign language.

For weeks the people at that job had smiled at me.
Then, wearing the same smile:

"You didn't pass the trial. Tomorrow, goodbye and out of the apartment."

The 22nd of December.
My suitcases were by the door before I'd finished understanding the sentence. Two dogs waiting for me in another country. A laptop that climbs to 94°C if I ask it to think too hard. Maybe a month of money left.

I'm telling you this first because that corridor is where this project was made, and four nights ago, at three in the morning, it's still where it's being made.
PC Workman, the thing I shipped this week, was written in conditions like that, and it is still being written in conditions like that.

So yes, this is a release note. 1.8.0 is out:
the version where my monitor finally remembers your machine instead of meeting it like a stranger every time you open it.
But I'd be lying if I sold it to you as software and stopped there.

Because the twelve months I spent teaching a program to remember are the same twelve months I spent getting myself back.
And here's about I didn't expect to be able to write down:
somewhere in that year, I found the guy who went missing.

He'd been in the code the whole time.

The number you never see cross a line

My father died when I was seventeen.
I didn't break that week.
I broke slowly, over the next two or three years, and that's something no one warns you about:
there's no moment. No threshold you catch yourself crossing.

It's a power rail sagging: 12 volts becomes 11.9, becomes 11.8, and every reading is still "within spec" so nothing alarms, and then one day you look at the number and it's just wrong, and you have no idea when that happened.

I went through technical school on fumes. INF.02 on the paper, nothing behind it. And somewhere around 2022, after school handed me the entire weight of being an adult all at once, I gave up on myself. Quietly. The way almost everyone does it.

The part people will either love or refuse to print:

it was AI that helped me find the exact day I quit.
Bounced between agencies whose names I never learned,
I started talking to a machine the way you'd talk to the one person who never gets tired of you, and it helped me locate the moment, the decision, the sag.

And the second I could see it, I could refuse it. That's the whole thesis, honestly. You cannot fix a number you never learned to measure.

So I made a decision that looks stupid typed out and felt like survival at 3 a.m.: I will not let this grind me into one more used-up man it spits out the far end. I'll work while I have strength. I'll learn one thing a day. I'll build out loud, in public, so I can't quietly vanish. And I will not, at thirty, look in a mirror and hate the kid who stopped trying at twenty-two.

Then I opened my editor.

A monitor that remembers you
PC Workman tells you why your PC is slow, not just that it is. It learns your machine — your temperatures by workload, your voltage patterns, the games you actually play — and it talks to you through an offline AI assistant I wrote called hck_GPT. 84 intents, no cloud, no API key, all of it running on your own metal.

There's one-click optimization, ghost-driver detection for hardware you ripped out years ago, an in-game overlay that starts empty and shows only what you choose, and a small antivirus that checks who really signed a process instead of trusting the name.

The 1.8.0 receipts: 84 intents, 373 known processes, 40+ games it greets by name, 21/21 tests green, ~790 downloads across SourceForge and GitHub, 61 stars — and twelve dead projects buried behind it.

But the headline of 1.8.0 is the only part I actually lose sleep over. Memory.

Every monitor on earth forgets you the second you close it.
HWiNFO, Afterburner, open them tomorrow and they'll draw your 78°C against the exact same line they draw for every machine that has ever existed.
I couldn't live with that.
The most useful number a monitor can give you isn't the temperature.
It's whether this temperature is normal for you, and to answer that, the thing has to remember.

So every reading falls into one of five workload buckets, and each keeps its own learned normal:
def classify(self, cpu_load, gpu_load=0.0): """Return the workload bucket for the given CPU / GPU utilisation.""" if (gpu_load or 0.0) >= 60.0: return "gaming" cl = cpu_load or 0.0 if cl < 15.0: return "idle" if cl < 40.0: return "light" if cl < 70.0: return "medium" return "heavy"

82°C while you game: fine.
82°C sitting idle: something's wrong.
Same number, opposite verdict, judged against your own past instead of a spec line.

And it does not forget. I tore out the old 14-day window and rebuilt it as a Welford accumulator: three numbers per workload, a running count,
a mean, and a thing called M2 — folded forward, never recomputed.

def _welford_add(acc, x): """Fold one sample into a running accumulator (Welford, 1962).""" n = acc["n"] + 1 delta = x - acc["mean"] mean = acc["mean"] + delta / n acc["n"] = n acc["mean"] = mean acc["M2"] = acc["M2"] + delta * (x - mean)

It keeps learning for the entire life of the install, and the learned shape survives even after the raw data gets pruned at ninety days.
Detail rolls off.
Shape of your machine stays.
That's the whole memory.

Statistics from the 1960s, babysitting your power supply

Voltages got the oldest math in the project.

Spec says your 12V rail is fine anywhere between 11.4 and 12.6. Technically true, practically uselessm a healthy supply doesn't roam that whole band, but holds tight, around 11.95 to 12.05.

So instead of the spec, PC Workman learns the median and spread of your rail and runs Nelson rules from 1984 on top of it, hunting the slow sag the threshold will never catch.

It scores every reading against your own history with a modified z-score, median and MAD, not mean and σ, because one spike drags an average up and lets the next one sail through:
M = 0.6745 × (x − median) / MAD

A drift to 11.7V is invisible to the spec and screams against your own history. Early warning, months before anything actually dies.

You already know why I had to build that. I am the rail that sagged for three years inside spec while everyone, me included swore nothing was wrong. I built the alarm I never had.

Sixty-year-old statistics babysitting a power supply.
Boring, predictable, and that is exactly why I trust them.
Statistics don't hallucinate. People do. People looked me in the eye at 19 PLN an hour and said, "just try harder, the rate will get better."
It never got better. Math, at least, never lied to me.

Written after the shift

I need you to see where this actually gets made, because it changes how you read everything above.

PC Workman does not get built in a clean bedroom with a mechanical keyboard and a ring light. It gets built after I weld.
Hot air, a gun, melting plastic grates back together in a workshop, and then I go home, open a laptop from 2014, and write a Welford accumulator on it.

That contrast used to embarrass me.
It doesn't anymore, because the welding taught me the one thing the memory engine needed. You don't get an eye for hot metal from a manual.
It accumulates, cherry red, straw, blue that means you already gone too far.
Nobody hands it to you. You earn it by burning enough of it until the knowledge in your hands is yours and not the chart's.
That's the entire philosophy of the learning engine, and I learned it with a heat gun before I ever wrote it in Python.

Fear changed shape

Here's what I only understood this week, and have never written before.

For a year the fear was simple:

I'm scared of disappearing, so I build. Commit something, watch a progress bar move, prove I still exist. That fear is loud but clean.
When you've got nothing, you've got nothing to lose, and that turns out to be its own brutal kind of freedom.

Then something I made hit #1 trending on HackerNoon and held it there for two days.
I have a small, real community now, people who spend eight hours stress-testing my releases and then come back.
And the fear quietly mutated into something heavier:

now I have something I can lose.

It took me off the board for a week.
I cried for three days. Not from joy.
From a flavor of dread I didn't have a word for. It was a fluke.
I'll lose it all. Maybe it only works once. Impostor syndrome, except impostor syndrome while you're broke and welding plastic to eat is a different animal entirely.
It rides shotgun with every single small win, every day.

But under the dread was the truest sentence I own, and I'm almost proud of it: I went from trying to gain to having something to protect.
The second one is a step higher up the stairs even when he's the one sitting on them, crying.

Three in the morning

Monday I shipped 1.8.0.
It was supposed to go out four days earlier.
I kept pushing it back because I kept finding more, more bugs to kill, more to test, more of the machine to teach, more reasons not to put my name on something half-true.
In four days I did close to two weeks of work.

I clicked publish at three in the morning.
Then I lay down to sleep, and from three until twenty past four I stared at the ceiling and asked the only question that ever really comes for me at that hour: does any of this mean anything.

I get that question every two to four days. Always at night.
And here's the thing I've learned to trust like a law of physics:

it lasts about an hour. Sometimes two, sometimes three. And then I beat it, all the way, not halfway. And the motivation comes back whole, like nothing happened.

You don't argue with weather. You survive the hour, and you wait for the part where time and stubbornness pay you back.

At 4:20 I stopped asking. By nine I was writing this.

The man who got himself back

I wanted to title this The Man Who Got Himself Back. In Polish, my language — "Człowiek odzyskał siebie." It's a beautiful title. It's also a lie, and I'd rather hand you the truth, because it's the one thing on this entire page I'm actually sure of.

You don't get yourself back once. There's no ceremony,
though one did land in my hands the same Monday I shipped this, a Google one:
Skills of Tomorrow 3.0 AI, five weeks that felt exactly like the accumulator, not knowledge downloaded, knowledge folded in, slowly, never recomputed.

But certificate isn't the moment. Moment is smaller, and it repeats.
You get yourself back at twenty past four in the morning, when the question comes and you outlast it one more time.
You get yourself back the next night the laptop boots warm and you write one more function instead of closing the lid.

My monitor learns for the life of the install.
I learn for the life of mine. This grind is twelve months old, it has not ended, and it is not going to, and I've finally understood that this is not the tragedy of the story. It's the proof of it.
A finished man has nothing left to recover.
I get to keep recovering. That's a pulse.

I get myself back. Every morning.
Not yet not today. I'm still here.

Find me (and maybe the first coffee?)

PC Workman 1.8.0 is free and open source (MIT), one ZIP, no installer, no account, runs locally on your machine.

⭐ Star / download: github.com/HuckleR2003/PC_Workman_HCK
Site: pcworkman.dev
Coffee: buycoffee.to/hcklabs
Everything (LinkedIn - X - Dev.to):
linktr.ee/marcin_firmuga

Polish version: pcworkman.dev/blog/the-man-who-got-himself-back_pl

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 that learns your PC's natural behavior over time, spikes, voltages, temperatures, usage 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. Twelve months of code. Four complete UI rebuilds. 26,000 lines deleted, ~50,000 total. 3 a.m. all-nighters. Energy drinks and toast. And my own hck_GPT AI, built over months to give PC Workman a brain and a heart.

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

Built solo and in public by Marcin "HCK" Firmuga - 22, Radom, Poland. After the welding shift, on a 2014 laptop, in the hour between the night breakdowns. GitHub: HuckleR2003 · pcworkman.dev. Still shipping.

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