Portfolio — Tyrien Jones

Featured work

PC_HEALTH gets the full write-up below. ECO and L.I.LY are big enough to get their own pages — the cards below take you straight there. Then one more I’m running right now. Every one’s split the same way, so the lines are clear and you can scan it:

The job — what it is, in plain terms.
What’s mine — the part I built.
What I wired in — other people’s tools I integrated. Not my code. I pick them, read the docs, pin a version that works, and write the glue.
How I ran it — the agents and the checkpoints.
Why it counts — what it proves I can do for you.

One thing that pattern makes obvious: the projects aren’t all the same kind of work. PC_HEALTH is mostly wiring good tools together. ECO is mostly original, bespoke work. L.I.LY is both. That’s the range.

PC_HEALTH leads because it’s finished and I use it every day.

PC_HEALTH — a longevity monitor for Windows PCs

Finished. v0.1.0. In daily use on my own machine. MIT licensed.

This one’s smaller and looser than L.I.LY, and that’s on purpose — a focused tool for one clean problem, not a months-long build. Different jobs need different shapes.

The job. Watch the health of a Windows PC over time — drive wear, temperatures, GPU, and system errors — and keep a timestamped record so you can see trouble coming before a drive dies on you. Read-only by design, and I mean it literally: there’s exactly one network call in the whole tool, to a sensor service on my own machine. Nothing’s written to firmware, nothing phones home, nothing leaves the box.

What’s mine. The layer that sits on top of the sensors: the part that polls four separate sources on a sensible schedule, decides what counts as healthy versus worrying, writes clean timestamped JSON snapshots, and — the key piece — hands all of it to an AI through an MCP server with five typed, read-only tools (get_current_health, get_recent_live, get_smart_history, get_recent_events, list_drives). I also wrote the packaging and the docs that ship with it — a README that walks setup, AI integration, architecture, and dependency versions, plus a documented thresholds file for CPU and drive cutoffs with examples for per-model overrides. Docs built along the way, not bolted on.

What I wired in. The actual readings come from other people’s open-source tools, not mine: LibreHardwareMonitor reads the CPU, GPU, and board sensors; smartmontools (smartctl) reads drive SMART data; nvidia-smi reads the GPU; the Windows Event Log handles system errors; and the whole thing speaks the Model Context Protocol (MCP). I didn’t build a hardware monitor. I built the thing that turns four separate hardware tools into one clean stream an AI can read.

How I ran it. A solo build — my design, operator-directed, built by AI under the rules I run by — read-only chosen on purpose, defensively coded against malformed sensor and CLI output, every dependency and version written down before I called it shipped.

Why it counts. I can ship working software end-to-end on a real stack, with clean separation between the readers, the aggregator, and the server. An honest README that lists every dependency. The right boundaries picked on purpose. Real software a client can run today.

Python 3.11+, on top of LibreHardwareMonitor, smartmontools, nvidia-smi, the Windows Event Log, and MCP. GitHub: github.com/tyrienjones-tech/PC_HEALTH_MCP

ECO — a control plane for governing AI-assisted builds

v0.2 (Milestone 1 complete). My biggest project, and the one I’m proudest of. In active development since March 2026 — 267 commits deep, 677 Rust tests passing.

Read the full write-up →

L.I.LY — a personal AI stack with a real safety crew

v0.15. About three weeks of intense daily work — 300-plus commits. 430 tests.

Read the full write-up →

Also running right now

ETS2LA — fixing a four-year-old self-driving mod from the ground up, and keeping it in Python. ETS2LA is a self-driving mod for Euro Truck Simulator 2 — four years old, almost all Python. The upstream team is dropping that Python and rewriting the whole thing in C#, citing performance, maintainability, and code quality. Fair enough — but I checked. Fifty analysis passes through the codebase, reason by reason, and those reasons don’t hold up. The bugs people actually hit are discipline-and-pattern bugs — the kind that come back one-for-one in C# unless you fix the pattern first. The language isn’t what’s broken. So this is my own campaign: take it apart, fix it from the ground up, keep it in Python, and prove the rewrite was never the only way to make it run right.

This is my own campaign, not a pull-request job — nothing here goes back to their GitHub. The fixes live on my machine, where the point is to prove it can be done, one bug at a time. The mod itself is theirs — GPL v3, every line of it. What’s mine is the campaign and the argument it makes. And I’ll call it what it is: a skill-test and a learning project at the same time.

The report opens with the rule I wrote for it: “write like you’re explaining the fix to a foreman, not pitching to a board.”

Four bugs closed so far — two of them are arbitrary-code-execution holes:

Arbitrary code execution through the settings file (ETS-021/022). The loader was running pickle.loads(eval(value)) on text it read straight out of a SQLite file — so anyone who could write to that file could run Python on the next launch. I replaced it with json.loads and took both eval and pickle out of that path. Verified with a hostile-input round-trip test and a real in-game window-drag. The same hole comes back in C# through Roslyn scripting or BinaryFormatter — Microsoft has explicitly warned against BinaryFormatter for this exact reason. The language doesn’t save you; fixing the pattern does.
A second code-execution hole, in the model-file loader (ETS-024). Same shape, different door: the loader ran eval() on the contents of a model file. I swapped it for ast.literal_eval, which parses data instead of running it. This one’s supply-chain reachable — a poisoned model file from a compromised source would have run on the next update check.
Window position that never saved (ETS-023). A function called check_if_window_still_open was polling the OS for the window position and writing it down — but nothing in the codebase ever called it. Dead since at least August 2025. A two-line fix wired it back into the existing 10Hz tick. Verified in-game. No compiler flags this one — catching it in the C# port means a human walking the call graph by hand, which is exactly the kind of thing a rewrite skips.
Map page froze on the second open (ETS-005). First open worked; every reopen sat dead until a restart. Traced to stale websocket subscription state that never reset when the map closed — so the next open got silently dropped. Three-line fix, verified in-game.

How I run it: four roles, not two — and except for me, they’re AI running under role prompts I wrote. A Director (Talos) sets strategy and scope, reached only through me. An Auto Drive Agent does the building — it reads the code, proposes the fix, and lands the change in the working copy under my checkpoints; it never commits and never opens a PR. An Auto Drive Strategist (a separate session) gives a second opinion each cycle. And I’m the operator: I route between them, make the calls, and run the in-game verification myself — nothing closes until I’ve driven it. The paper trail is the same jobsite kit I use everywhere — a Kanban board (INBOX → ACTIVE → AWAITING_OPERATOR → VERIFY → COMPLETED, plus HALTED and DEFERRED lanes), an append-only JSONL ledger that logs every state change, session logs, handover and context-pack files, and a rolling current-state file.

Why it counts: reading someone else’s code at scale and explaining why it’s wrong, not just what’s wrong. Holding a real technical argument — the C# point — against a four-year codebase, and backing it bug by bug instead of just asserting it. And running the whole thing the way I run every project: agents I name and scope, my checkpoints catching what they get wrong, and me driving every fix in-game before it counts as done. Four bugs closed so far, two of them code-execution holes. It’s focused work, not a cathedral — and that’s exactly what it needs to be.

The arc — three months, dated

I’m showing the early stuff on purpose. These are first attempts, not shipped products, and I’m not going to pretend otherwise. The story is the climb.

Feb 17, 2026 — Earliest dated file on my machine: an audio archive from before I started coding. (I made music first.)
Feb 19 — First Python I wrote: an early audio engine and an LLM bridge script. These survive only as zip snapshots now, not a live project — so I’m calling them what they are: where it started.
Feb 22–28 — First real week. Audio tools (a music player with a beat-reactive visualiser, a visual playlist tool, an audio-video mesh), a job-hunting web app — the first version of what I’d iterate through into HuntOS v2, then v3 and v4 in the weeks after — and a couple of skeletons I started and didn’t finish. Even these first ones shipped with READMEs, troubleshooting docs, and a plug-in structure. The documentation habit was there from day one.
March — Prototypes get serious. Stability Forge — first started in late February alongside the audio tools, but in early March it got my first written-down agent crew: Alex on the engine, Sarah on the wrapper, and a read-only auditor I called TALLAS. That role-separation method has shown up in every project since. Alongside it: HuntOS v3 → v4 (the job-hunting platform from week one, now with named agents David and Heather), Founder Brain (a small, clean service with a local database), a deterministic combat simulator with replay and seeded randomness, plus a behavioural-intelligence framework, an author-enrichment pipeline, a beat generator, and a couple of music tools.
Mar 27 — First commit on ECO. The folder was opened a week earlier on Mar 19 — I didn’t start tracking it in git until Mar 27.
Apr 30 — Set up the two-role agent rotation (Talos and Effy) on top of ECO.
May 17 — Shipped PC_HEALTH. In daily use ever since.
May 26 — L.I.LY hit v0.9, 139 tests passing after a safety-hardening sweep.
May 25–31 — ETS2LA campaign: four bugs closed (two are code-execution holes); report active, last updated May 31.

The March prototypes mostly didn’t ship to production, and I won’t say they did. What they show is the climb — and that the way I run AI agents now didn’t appear from nowhere. The role-separation method has a March prototype behind it. You can watch the same idea get sharper across every project.

The stack — what I write, and what I wire together

Languages I write and read in

I’m not claiming to be an expert in eight languages after three months. What I’m claiming is that I can move between stacks fast enough to ship in them and to audit them.

Language	Where I’ve used it
Python	L.I.LY, PC_HEALTH, the ETS2LA campaign, most of the March work
Rust	ECO’s backend
TypeScript	ECO
Svelte	ECO
JavaScript / HTML / CSS	Web interfaces across L.I.LY and ECO, and this site
PowerShell	Backup scripts, the PC_HEALTH event-log piece
SQL	Databases in ECO, Founder Brain, and others
C# (read, not written)	Reading a game’s runtime to plan mod work

What I integrate — other people’s tools, wired together right

A lot of what I ship sits on top of open-source software other people wrote. I’m straight about that, because picking the right tool, reading its docs, pinning a version that works, writing the glue, and documenting how to put it back when it breaks — that’s a real skill, and it’s one a lot of “I built it all myself” portfolios quietly skip. Plenty of clients have been burned by someone who rebuilt a worse version of a solved problem instead of using the tool that already works.

These are tools I integrate. They’re not my code. I wire them in and I keep them running:

AI / LLM: Anthropic’s API and the Model Context Protocol (MCP)
Networking: Tailscale (private network access, so things never leave your own machines)
Backup: Restic (encrypted snapshots, with a retention and restore routine I wrote)
Hardware sensing: LibreHardwareMonitor, smartmontools, nvidia-smi, the Windows Event Log
Voice / audio ML: XTTS-v2, faster-whisper, silero-vad
Compute: PyTorch with CUDA
Web frameworks: FastAPI, SvelteKit, Tauri
Storage: SQLite with full-text search, Supabase
Hosting: Cloudflare Pages, and self-hosted (this site)
Quality and security: Playwright, Vitest, ESLint, secret-scanning

The discipline that isn’t code

Some of how I work doesn’t show up as code at all, but it’s where the blue-collar side earns its keep:

Two backup systems, both running. Daily automated snapshots of ECO since 2026-04-28 (31 dated snapshot folders on the backup drive, set-and-forget). Separately, an encrypted Restic system for L.I.LY plus my private vault — a wrapper script I wrote in PowerShell, ACL-locked passphrase, retention policy (14 daily / 8 weekly / 12 monthly), and a documented disaster-recovery flow. Two different jobs, two different shapes, both real.
Verification logs and decision logs as real documents, not afterthoughts. The last verified entry is the ground truth. Every decision has a record.
Method statements, sign-offs, RFIs, inspections — jobsite paperwork applied to software. When the work’s blocked I raise it; when it’s done I prove it.

Got a job that looks like one of these? Let’s talk about it →