# James M — Projects (full text)

> A living portfolio of 19 active projects — game engines, a media toolkit, an AI-agent sandbox, cloud infrastructure, and more — each shipped continuously by an autonomous Claude Code burndown fleet.

This is the full-text LLM index (llms-full.txt, see llmstxt.org): every project's complete details — tagline, deep-link, source repo, language, topics, description, and highlights — inlined here so a language model has the whole portfolio in a single fetch without following links. The concise one-line-per-project index is at https://jm-portfolio-5afqr6ijoq-uc.a.run.app/llms.txt.

## LRGQ

2D game engine in C++ with a built-in editor, on SFML or raylib

- Page: https://jm-portfolio-5afqr6ijoq-uc.a.run.app/#/project/lrge
- Source: https://github.com/virtualhealthcitizen/lrge
- Language: C++
- Topics: game-engine, c++17, sfml, raylib, editor, cmake

A from-scratch 2D game engine and editor in C++17. Ships with zero external assets — the sprite sheet and jump sound are generated in code — so a fresh clone builds and runs with nothing to download. Includes a launcher, a tile-map editor with pan/zoom, a UE5-style Pawn blueprint with a visual Event Graph, and a fixed-timestep play mode. Its drawing runs through a backend-neutral facade with two implementations behind it, SFML 3 and raylib, and a second seam now abstracts the other half a graphics library owns — the window, the event pump, input and the Dear ImGui host — so a single LRGE\_BACKEND build option selects which pair ships. As of v0.3.0 both options build a running editor — the resource seam beneath the facade closed, so fonts and textures no longer cross it as SFML-typed handles — and CI configures and builds both backends plus a raylib-only probe on every push. SFML remains the reference for text fidelity; where raylib differs (italic shear, stamped outlines, a single-size atlas, collapsed mouse-wheel notches) the difference is documented rather than hidden. The project kept that distinction out loud the whole way — compiles was not links, and links was not runs.

Highlights:

- Fixed-timestep engine loop with scene transitions
- Two seams, not one — a draw facade (gfx::IRenderer) and a window/event/input/ImGui boundary, each with an SFML 3 and a raylib implementation, selected together by one LRGE\_BACKEND build option
- A raylib-only probe target compiles the facade with SFML nowhere in scope, so the seam can't quietly rot — and it doubles as the gate that checks the key mapping is total and injective
- Tile-map editor: pan, zoom, content browser, Pawn blueprints with an Event Graph
- Synthesized audio + procedurally generated sprites (no asset files)
- Multi-session autonomous burndown with a 1-in-3 bug-hunt cadence, gated by 217 headless test cases then a human editor pass — 31 features validated hands-on, 1 pending

## ffmpeg-util

A media toolkit whose dependency-free core builds the exact ffmpeg command — library, CLI & desktop app

- Page: https://jm-portfolio-5afqr6ijoq-uc.a.run.app/#/project/ffmpeg-util
- Source: https://github.com/virtualhealthcitizen/ffmpeg-util
- Language: Python
- Topics: ffmpeg, python, cli, electron, fastapi, media

A media toolkit built on one idea: the core doesn't run ffmpeg, it builds the exact invocation. ffmpeg\_util is a dependency-free Python 3.11+ stdlib library of ~98 argv builders — one pure function per chore that assembles the precise ffmpeg/ffprobe command, which a thin runner then executes (or, with --dry-run, just prints). Two properties fall out of that: it needs no third-party dependencies (building an argument list is stdlib work), and it's testable without ffmpeg installed (a test just asserts the built string). Around that core sit three ways to drive it — import the library, type the CLI (ffmpeg-util convert …, with a config file), or click the Electron desktop app, whose renderer talks to a Python FastAPI sidecar (~60 endpoints, a per-launch bearer token on loopback) that re-exposes the very same library, so no surface re-implements ffmpeg logic. The operation catalog is broad — roughly 50 operations: convert / trim / concat / thumbnail / contact-sheet / probe, compression by CRF, target-size (two-pass) or hardware (NVENC / QSV) with a real-sample size estimate, video FX (watermark, burn-in subtitles, blur regions, crossfade, rotate/flip/crop/pad, PiP & side-by-side), colour (grayscale / invert / eq / sharpen / denoise / deinterlace), audio (volume, EBU-R128 loudness, replace / mute / mono, trim-silence), speed / fps / reverse / boomerang, and GIF (palette two-pass with dithering). The desktop app adds drag-and-drop, source preview, batch mode, cancel, presets/profiles, light/dark, keyboard shortcuts, and a live progress bar + ETA streamed from ffmpeg's -progress over SSE. Packaged with a PyInstaller-frozen sidecar (zero Python needed at runtime) and gated by a three-layer test suite — root pytest + sidecar pytest against real ffmpeg + node:test renderer helpers + a headless Electron E2E smoke — shipped continuously by an autonomous burn loop with a 1-in-3 bug-hunt cadence.

Highlights:

- The command is the artifact — a dependency-free stdlib core of ~98 argv builders assembles the exact ffmpeg call, so it's testable without ffmpeg installed and --dry-run just prints it
- One core, three surfaces — a library, a CLI (with a config file), and an Electron desktop app whose renderer drives a Python FastAPI sidecar (~60 endpoints) re-exposing the same library
- ~50 operations — convert/trim/concat/thumbnail/probe, CRF/target-size/hardware compression, video FX, colour, audio, speed & GIF
- Desktop app: drag-and-drop, source preview, batch mode, cancel, presets/profiles, light/dark, shortcuts, and a live progress bar + ETA from ffmpeg's -progress over SSE
- PyInstaller-frozen sidecar (zero Python at runtime), gated by 3 test layers (root pytest + sidecar pytest vs real ffmpeg + node:test + a headless Electron E2E)
- Shipped continuously by an autonomous burn loop with a 1-in-3 bug-hunt cadence

## Forge Engine

A UE5-like game engine built entirely on HTML5

- Page: https://jm-portfolio-5afqr6ijoq-uc.a.run.app/#/project/smol
- Source: https://github.com/virtualhealthcitizen/smol
- Language: TypeScript
- Topics: webgpu, typescript, electron, game-engine, vite

A UE5-style game engine shipped as a desktop editor: WebGPU rendering, an Electron dockable UI, TypeScript + Vite throughout. Key systems target Blueprints, a material graph, physics, and animation. Strictly typed, test-gated, and shipped one validated milestone at a time.

Highlights:

- WebGPU forward renderer with tiled light binning
- Blueprints: data-graph → JS expression codegen
- Material graph, physics narrowphase, animation root motion
- UE5-style dockable editor panels and play-mode toolbar
- Autonomous burn fleet with a 1-in-3 bug-hunt cadence

## adk-sandbox

A sandbox of runnable Google ADK agents that pick a tool and answer from the result

- Page: https://jm-portfolio-5afqr6ijoq-uc.a.run.app/#/project/adk-sandbox
- Source: https://github.com/virtualhealthcitizen/adk-sandbox
- Language: Python
- Topics: google-adk, python, agents, tool-calling, gemini, gcs, sphinx

A sandbox of runnable example agents built on Google's Agent Development Kit (ADK). Each agent is a directory whose agent.py exposes a single module-level root\_agent, which the runtime discovers by name (adk run <dir> / adk web) — no extra registration. What makes each an agent rather than a prompt is the tool-call loop: the model (gemini-2.5-flash) reads the signature and docstring of each declared Python function, decides which to call, calls it, and answers from what comes back. Four agents sit side by side so the pattern reads at a glance: multi\_tool\_agent (time & weather for 76 cities, tools get\_weather / get\_current\_time), project\_builder\_agent (scaffolds runnable Flask / FastAPI / Express templates and runs them under a time-bounded runner), jm\_test\_agent (the smallest possible root\_agent, backed by a mock tool so the smoke suite runs offline and deterministically), and youtube\_shorts\_assistant (Shorts planning, script templates, speaking-time estimates and niche-aware hashtags). Shared lookup data lives in one importable module (adk\_sandbox/city\_data.py), a Sphinx docs site renders each agent's tools straight from the AST — so the reference can't drift from the code — and auto-deploys to Google Cloud Storage on every merged PR. Python 3.12, uv-managed with pinned dependency lower bounds and drift-guard tests; CI runs pytest before it builds and publishes, so a red test blocks the docs. An autonomous burn loop keeps the whole thing green, one validated item per run.

Highlights:

- Four runnable ADK agents, each a directory the runtime discovers by its module-level root\_agent
- The tool-call loop up front — gemini-2.5-flash reads a function's signature, picks it, calls it, answers from the result
- A mock-tool agent (jm\_test) runs the identical loop offline so the smoke suite needs no live key
- Docs generated from the AST — a Sphinx directive renders each agent's tools from source, so they can't drift
- Sphinx site auto-deployed to GCS on every merge, gated behind the pytest suite
- Kept green by an autonomous burn loop — one validated item per run, 1-in-3 bug-hunt cadence

## go-labs

A hands-on Go playground you learn by running — one module, a live browser sandbox

- Page: https://jm-portfolio-5afqr6ijoq-uc.a.run.app/#/project/go-labs
- Source: https://github.com/virtualhealthcitizen/go-labs
- Language: Go
- Topics: go, learning, playground, concurrency, go-embed, stdlib

A single Go module of small, runnable examples that walk the language from first principles — variables and control flow through concurrency, the standard library, and testing. The convention that holds it together is the architecture: every runnable example is its own directory, a \`package main\` with a single \`func main\`, so two mains can never collide and \`go build ./...\` compiles the whole repo and stays green no matter how many examples land. Reusable code (the \`util\` package) lives in its own named package and ships with table-driven tests. Because reading code you can't run is half a lesson, the repo also ships a self-contained web sandbox: one Go binary with \`go:embed\`ded assets and no third-party dependencies that auto-discovers the numbered topic directories, renders each note, and compiles + runs any example (or your own scratch code) live in the browser via an in-place editor — each run a sandboxed child process bounded by a hard timeout that kills the whole process tree, so a runaway \`for {}\` can't hang the server. The whole module stays gofmt-clean, vet-clean, and green as a single command: \`make check\` (gofmt + vet + build + test) runs locally and in GitHub Actions on every push.

Highlights:

- Learn by running — one \`package main\` per directory keeps \`go build ./...\` green no matter how many examples land
- A dependency-free \`go:embed\` web sandbox that compiles & runs any example (or scratch code) live in the browser
- Runs are sandboxed child processes with a hard timeout that kills the whole process tree — a runaway loop can't hang the server
- Topics 01–13 + stdlib + testing: basics, functions, structs, maps, pointers, concurrency, error handling — each a runnable note
- Importable, tested util package; whole module stays gofmt/vet/build/test green via \`make check\` + CI
- A two-track roadmap: round out the language, then isolated ecosystem tours (net/http, chi/Gin/Echo, cobra, slog, database/sql)

## Token Validator

A stateless Flask token-validation service and the Electron desktop app that fronts it

- Page: https://jm-portfolio-5afqr6ijoq-uc.a.run.app/#/project/token-validator-service
- Source: https://github.com/virtualhealthcitizen/token-validator-service
- Language: Python
- Topics: python, flask, oauth2, electron, react, cloud-run

A stateless microservice that verifies Google OAuth access tokens — and a cross-platform Electron desktop app that puts a friendly face on it. The load-bearing idea is delegated trust: rather than owning keys, rotation and revocation state itself, the service hands the token to Google's oauth2/v3/tokeninfo endpoint and, if Google says it's live, returns the claims Google decoded. POST a token to /api/validate-token and it returns { valid, token\_info } (200) or a clean 400 — Flask, CORS-enabled, no database and no secret of its own, containerized (Docker) for Google Cloud Run, with a Postman/Newman collection as the integration suite in CI/CD. The companion desktop client (Electron + Vite + React + TypeScript, under desktop/) lets you paste a token, pick Direct mode (call Google's tokeninfo straight from the app, no backend) or Remote mode (POST to the deployed service so CORS and creds stay server-side), and read the result: an ordered claims table with scope chips, a humanized expiry (absolute + 'expires in …'), and copy-as-JSON, in a light/dark theme with keyboard shortcuts. A narrow, context-isolated preload IPC bridge keeps Node and the network out of the renderer, the same renderer also runs as a plain web page via a browser fallback, and the token is treated as a secret throughout — never written to disk, never logged, scrubbed from memory after a check (only the mode/URL/theme preferences are persisted). The pure claim-formatting and expiry helpers are covered by vitest.

Highlights:

- Delegated trust — POST /api/validate-token proxies Google's tokeninfo; the service stays stateless, database-free and holds no secret of its own
- A companion Electron + React + TS desktop app: paste a token, validate, and read the decoded claims — no curl, no Postman
- Two validation modes — Direct (client → Google) or Remote (client → the Flask service → Google)
- The token is never stored or logged — in-memory only, scrubbed on clear; only UI preferences persist
- Readable claims: scope chips, humanized expiry (absolute + 'expires in …'), an ordered table, copy-as-JSON, light/dark theme
- Containerized for Cloud Run with a Postman/Newman integration suite; the desktop's pure helpers are vitest-covered

## cloud-portfolio

A React/TypeScript personal portfolio that ships itself to Cloud Run on every pull request

- Page: https://jm-portfolio-5afqr6ijoq-uc.a.run.app/#/project/cloud-portfolio
- Source: https://github.com/virtualhealthcitizen/professional-portfolio
- Language: TypeScript
- Topics: react, typescript, vite, mui, cloud-run, docker

A personal portfolio single-page app built on a modern stack and delivered by a pipeline where opening a pull request deploys it live. Three routes — Home, About, Projects — on React 19 + Vite 6 + TypeScript, styled with MUI 7 (Emotion) over a hand-built design-token theme: a teal→sky accent gradient, translucent glass surfaces, a focus ring and an ambient background, in both light and dark modes. Home is a react-spring animated hero plus skills and certifications sections; Projects pairs personal project cards with a timeline-anchored accordion of enterprise experience and a GitHub stats/contributions panel. Delivery is containerized and automatic: a multi-stage Dockerfile runs npm run build in a node:20 stage then copies just the static build/ into an nginx:stable-alpine runtime (SPA fallback routing + CORS; Cloud Run injects $PORT), and .github/workflows/cicd.yml builds, pushes the image to Google Artifact Registry, and deploys to Cloud Run on pull\_request → main — so a proposed change is reviewable at a live URL before it merges. Recently migrated off Create React App to Vite 6 + Vitest 4, dropping a defunct polyfill.io script and pruning the dependency surface from ~1,500 to 466 packages down to zero audit vulnerabilities.

Highlights:

- Open a pull request → it's live: cicd.yml deploys the build to Cloud Run on pull\_request (not merge), so a change is reviewable at a real URL
- Multi-stage Docker build — a node:20 stage builds the bundle, an nginx:stable-alpine stage serves just the static build/ (the toolchain never ships)
- React 19 + Vite 6 + TypeScript, MUI 7 on a design-token theme — teal→sky accent gradient, glass surfaces, light & dark modes
- Home (react-spring hero + skills + certifications), About, and a Projects page (personal cards + enterprise timeline + GitHub stats)
- Migrated off Create React App to Vite 6 + Vitest 4 — dropped a defunct polyfill.io script, pruned deps ~1,500 → 466, zero audit vulns

## Workflow Dispatcher

A client-side React panel that fans GitHub Actions runs out across many repos

- Page: https://jm-portfolio-5afqr6ijoq-uc.a.run.app/#/project/cicd-frontend-react-ts
- Source: https://github.com/virtualhealthcitizen/cicd-frontend-react-ts
- Language: TypeScript
- Topics: react, typescript, vite, zustand, github-actions, cicd

A fully client-side React + TypeScript + Vite control panel for GitHub Actions workflow\_dispatch. GitHub's UI hides on-demand runs one repo and one workflow at a time, and pushing an empty commit to nudge a run is a hack — the Dispatcher inverts that: connect any number of owner/repo targets (each validated live against the GitHub API on connect), browse and select workflows across all of them, target a branch, tag, or exact commit SHA, attach arbitrary key/value inputs, then fire every selected run in one action — sequentially (for … await) or in parallel (Promise.all) — and watch them land in a run-history panel with status, conclusion, the triggering actor, and a link back to GitHub. There's no backend of its own: every call goes straight from the browser to api.github.com with a Bearer header, and your Personal Access Token lives in memory in the store, never written to disk or logged. State is two small Zustand stores (repos/workflows/selection/dispatch, and run-history), the domain is fully typed, and the app was ported from a plain HTML/CSS/JS prototype to the typed Vite/React stack with ESLint and GitHub Actions CI.

Highlights:

- Fan workflow\_dispatch runs out across many repos in one action — sequentially (for…await) or in parallel (Promise.all)
- Multi-repo connect with live GitHub-API validation; browse & select workflows across all connected repos
- Flexible ref targeting (branch / tag / exact SHA) + arbitrary key/value inputs passed straight into the dispatch payload
- A run-history panel — status, conclusion, actor & a link back to GitHub — without leaving the app or pushing a commit
- No backend of its own: browser → api.github.com with a Bearer PAT held in memory only, never persisted or logged
- Typed Vite + React + Zustand (two small stores), ported from a plain HTML/CSS/JS prototype, with ESLint + CI

## Recall

A zero-dependency flashcards app that reviews each card right before you forget it

- Page: https://jm-portfolio-5afqr6ijoq-uc.a.run.app/#/project/recall
- Source: https://github.com/virtualhealthcitizen/recall
- Language: JavaScript
- Topics: flashcards, spaced-repetition, sm-2, vanilla-js, indexeddb, offline-first

A fast, offline-first flashcards web app shipped as a single self-contained index.html — the whole app (markup, styles, and ~2,300 lines of vanilla JS) is one file with no build step and nothing to npm install. Cards live in decks grouped under colour-coded subjects, in two types: basic (front/back) and fill-in-the-blank with accepted-answer alternates; both render rich, sanitised HTML including inline images. The core mechanic is an SM-2-style spaced-repetition scheduler: every card carries { due, interval, ease (starting at 2.5), reps, lapses }, a good grade multiplies its interval so reviews spread further apart as the memory sticks, and a lapse snaps it back to the front of the queue — the home screen's 'Study due' queue surfaces exactly the cards whose due date has passed. Persistence is browser-native and automatic: IndexedDB is the primary store (room for images) while a synchronous localStorage cache gives an instant first-paint restore, and the two reconcile to whichever snapshot is freshest, with debounced saves so nothing is lost on reload; a private-mode fallback keeps working when storage is blocked. Because the data is tied to one browser, JSON Export/Import provides backups and device-to-device moves — sample libraries ship in exports/. Dark theme by default (plus light and a compact density mode), and a ~90-line zero-dependency Node-stdlib static server (serve.js) runs it locally with a CI smoke test on every push.

Highlights:

- The entire app is one self-contained index.html — no build step, no framework, nothing to install
- SM-2-style spaced repetition — each card's interval stretches with its ease as the memory sticks; a 'Study due' queue surfaces only what's due
- Basic and fill-in-the-blank cards (with answer alternates) in decks grouped by colour-coded subject; rich sanitised HTML + inline images
- Browser-native persistence: IndexedDB primary + a synchronous localStorage cache for instant restore, reconciled by freshest snapshot
- Your data stays yours — no account, no server, no network call; JSON export/import for backups and moving decks between devices
- A ~90-line zero-dependency Node-stdlib static server + a CI smoke test; dark-default with light & compact density modes

## GCP Terraform Labs

jm's Google Cloud footprint as Terraform — the live portfolio infra, plus a library of self-destroying API experiments

- Page: https://jm-portfolio-5afqr6ijoq-uc.a.run.app/#/project/gcp-terraform-labs
- Source: https://github.com/virtualhealthcitizen/gcp-terraform-labs
- Language: HCL
- Topics: terraform, gcp, infrastructure-as-code, iam, cloud-run

jm's Google Cloud footprint as Terraform, in two complementary halves under one repo and one GCS remote-state backend (lofty-root-tf-state, on the google/google-beta ~>6.0 providers). (1) The LIVE portfolio infrastructure: gcp/dev provisions the service accounts and Workload-Identity / IAM bindings that let GitHub Actions deploy the portfolio's Cloud Run services, plus KMS/CMEK-encrypted and public Cloud Storage buckets, Secret Manager (with accessor bindings), Pub/Sub, and a Cloud SQL instance — and the portfolio's live application backends themselves: the jm-likes ♥ service (a Cloud Run + Firestore counter behind the site's like buttons) and murmur-chat, which has grown from a message write-path into a full moderated chat API (a ~560-LOC Cloud Run service exposing nine endpoints — post, edit, soft-delete, transactional reaction toggles, pins, moderation reports and presence — writing into a jm-chat Firestore database with IP-hash abuse hardening, realtime reads coming straight from Firestore client-side; enough distinct reporters escalates a message to a shadow-ban the API never acknowledges, and presence carries online/away status, a truncated typing preview and a readAt receipt), alongside the token-gated desktop auto-update proxy. (2) A growing library of EPHEMERAL experiments: each gcp/<name>-demo stands up a throwaway no-billing GCP project, provisions exactly one API or resource pattern, proves it (curl-testable right after apply), captures anything the showcase needs, then tears itself down — state-prefixed per experiment, so nothing lingers and nothing is billed. A dozen have shipped so far — gemini (generativelanguage + apikeys; it captured a live adk-sandbox agent run for the jm showcase), translate (Cloud Translation), pub/sub, firestore, vision, bigquery, cloud-scheduler, artifact-registry, cloud-functions, cloud-run, secret-manager, and an enrichment-pipeline. A Terraform CI workflow validates every environment, and the repo builds Sphinx documentation.

Highlights:

- Two halves under one repo + GCS state backend: the LIVE portfolio infra (gcp/dev) and a library of ephemeral, self-destroying API experiments (gcp/<name>-demo)
- gcp/dev provisions the real infrastructure — SAs + Workload-Identity/IAM for GitHub-Actions Cloud Run deploys, KMS/CMEK + public buckets, Secret Manager, Pub/Sub, Cloud SQL — and the live app backends (jm-likes ♥ + murmur-chat) + the desktop auto-update proxy
- murmur-chat — a full moderated chat API on Cloud Run (9 endpoints, ~560 LOC): post/edit/soft-delete, transactional reaction toggles, pins, and a reports→moderation-queue path where enough DISTINCT reporters escalates to a shadow-ban the response never reveals
- Presence as its own write: online/away status the client's own tab visibility sets, a truncated typing preview, and a readAt high-water mark for "seen" receipts — all rate-limited, because unbounded presence POSTs were a free-tier cost DoS
- The ephemeral pattern: each demo spins up a throwaway NO-BILLING GCP project, proves one API, captures what the showcase needs, then destroys itself — zero cost, nothing left behind
- A dozen self-destroying experiments shipped: gemini, translate, pub/sub, firestore, vision, bigquery, cloud-scheduler, artifact-registry, cloud-functions, cloud-run, secret-manager & an enrichment-pipeline
- All in Terraform on google/google-beta ~>6.0 with a GCS remote state backend (lofty-root-tf-state) + a Terraform CI workflow + Sphinx docs

## AWS Terraform Infra

Reusable AWS Terraform modules & examples — provisioning cloud architectures, validated without credentials

- Page: https://jm-portfolio-5afqr6ijoq-uc.a.run.app/#/project/terraform-aws
- Source: https://github.com/virtualhealthcitizen/terraform-aws
- Language: HCL
- Topics: terraform, aws, infrastructure-as-code, modules, ecs, vpc

A modular AWS Terraform playground and reference: reusable, independently-exampled modules — network, messaging, compute, iam, and monitoring — for provisioning common cloud architectures, each with its own runnable examples/ root and validated with no AWS credentials required (terraform fmt + per-root validate + tflint, gated in CI and pre-commit; plan/apply is deferred until creds exist). The modules compose into thin per-environment roots (dev / staging / prod) that own isolated S3 state — the flagship worked example being SentryStream, a telemetry-ingest platform wired end to end — while a global/bootstrap root lays the foundation on local state: a versioned, encrypted S3 state bucket (with its own access-logs bucket), KMS CMKs, a multi-region CloudTrail audit trail, a DynamoDB lock table (a pre-1.10 fallback), and a least-privilege TerraformDeploy IAM role. The building blocks: a network module (a two-AZ VPC with public/private subnets, NAT egress, an internal Network Load Balancer, KMS-encrypted flow logs, and VPC interface + S3 gateway endpoints); a messaging module (versioned, CMK-encrypted S3 storage and an SNS topic fanning out to per-consumer SQS queues, each with a DLQ); a compute module (ECS Fargate with CPU target-tracking autoscaling, a read-only root filesystem, and break-glass ECS Exec); an iam module (least-privilege roles with permissions boundaries); and a monitoring module (a CloudWatch operator dashboard). Authenticates via IAM Identity Center (SSO) with an assume-role / OIDC path for cross-account and CI on the hashicorp/aws ~>6.0 provider — a growing catalog of production-shaped AWS patterns you can lift module by module.

Highlights:

- Reusable, independently-exampled modules — network, messaging, compute, iam, monitoring — each with its own runnable examples/ root you can lift into any project
- Validated with NO AWS credentials — terraform fmt + per-root validate + tflint, gated in CI and pre-commit (plan/apply deferred until creds exist)
- Composes into thin dev / staging / prod roots with isolated S3 state — the flagship worked example: SentryStream, a telemetry-ingest platform wired end to end
- The building blocks: a two-AZ VPC (NAT, internal NLB, flow logs, VPC endpoints), SNS → SQS fan-out with per-consumer DLQs, ECS Fargate autoscaling, least-privilege IAM, a CloudWatch dashboard
- global/bootstrap foundation (encrypted/versioned S3 state, KMS, multi-region CloudTrail, DynamoDB lock, TerraformDeploy IAM) + IAM Identity Center SSO / OIDC on hashicorp/aws ~>6.0

## Ashenreach

A first-person RPG built entirely in C++ on UE 5.3 — the Field Guide's reference project

- Page: https://jm-portfolio-5afqr6ijoq-uc.a.run.app/#/project/ashenreach
- Source: https://github.com/virtualhealthcitizen/Ashenreach
- Language: C++
- Topics: unreal-engine, ue5, c++, rpg, animation, procedural-generation

A Morrowind-like first-person RPG whose every system is written from first principles in plain C++ on Unreal Engine 5.3 — no Blueprint gameplay, no Gameplay Ability System, nothing hidden behind a node graph. It is the reference project for the Field Guide handbook's UE5 C++ track: each chapter builds a system here and ships the complete .h/.cpp files, so the book and the game advance together. Shipped and compile-verified today: a first-person character with Enhanced Input; attribute pools with regen and delegates, damage/resistances/death; a data-driven item model with inventory, equipment and world pickups; a cost/cooldown ability system with projectile, area and heal spells; an interface-driven focus-trace interaction system with doors, containers, levers and locks; and a seeded procedural dungeon generator that extrudes rooms, caves and mazes into walkable procedural-mesh geometry, then populates them solvably. The deepest seam is animation: a third-person mannequin body runs a from-scratch locomotion stack — a directional strafe blend space, walk/jog gaits, rotation modes, per-armament linked anim layers, crouch, airborne states, a spine-split so upper-body montages layer over a live stride, plus melee attacks with a phase-driven time warp and a held shield guard with live pose-trim knobs. A UE-Python toolkit (AshAnimPolish) bakes Souls-style polish — per-phase time warps, authored contact holds, spring follow-through — into duplicated animation assets behind a headless test gate.

Highlights:

- Every system in plain C++ (module Ashenreach, AAsh…/UAsh…/FAsh…/EAsh… naming) — no Blueprint gameplay, no GAS, so a reader can follow the whole call path
- A from-scratch animation stack: directional strafe blend space, gaits, rotation modes, per-armament linked anim layers, crouch, airborne states, and a spine split that layers upper-body montages over a live stride
- Combat feel as engineering: a phase-driven montage time warp that makes a controlled mocap swing commit, and a held shield guard whose raise→loop seam is crossfaded guard-to-guard so no frame of locomotion flashes through
- Live pose-trim knobs — per-stance rotator pairs composed in C++ and applied by component-space Transform-Modify-Bone nodes, tunable in the editor with no recompile and zero-default no-op
- AshAnimPolish: a UE 5.3 editor-Python toolkit that bakes per-phase time warps, contact holds and spring follow-through into duplicated AnimSequences, gated by a headless commandlet test
- A seeded procedural dungeon generator (rooms · caves · mazes) extruded into walkable UProceduralMeshComponent geometry, with locks, keys and solvable population
- Every chapter is compile-verified headlessly (UBT exit 0) and PIE-validated before it ships — the book never documents an unbuilt system

## ue5-experiments

Unreal Engine 5 C++ gameplay experiments for a 2D side-scroller

- Page: https://jm-portfolio-5afqr6ijoq-uc.a.run.app/#/project/ue5-experiments
- Source: https://github.com/virtualhealthcitizen/SideScrollerProto
- Language: C++
- Topics: unreal-engine, ue5, c++, procedural-animation, paperzd

A grab-bag of Unreal Engine 5.3 C++ gameplay systems prototyped around a PaperZD 2D side-scroller. Each piece is a self-contained, Blueprint-exposed component or function library: a variable-height platformer jump (physics only, animation left to the caller), oscillate/toggle directional movers for floating platforms, doors, and lifts, a Niagara debuff/buff particle helper that attaches effects to a character, a self-contained 3D analog clock built from engine primitive meshes, and an in-world retro terminal with a cartridge system — keystroke capture, scrollback, cursor editing, and text wrapping rendered through a UMG widget delegate. A growing suite of procedural-animation scene components animates engine-primitive meshes entirely in code (no animation assets) — a boids SwarmComponent, an interfering-wave WaveFieldComponent, and a golden-angle SpiralBloomComponent — each defaulting to an engine primitive but accepting an editor-settable mesh override. Shipped continuously by an autonomous burn loop whose gate is a real headless UBT compile.

Highlights:

- Procedural-animation scene components from engine primitives: boids swarm, interfering wave field, golden-angle phyllotaxis bloom — code-driven, no animation assets, editor-overridable mesh
- DirectionalMovementComponent: sinusoidal-oscillate and open/close-toggle movers (with phase offset + Reset) for platforms, doors, and lifts
- Variable-height platformer jump as a Blueprint function library — physics only, animation left to the caller
- Niagara debuff/buff particle library that attaches effects to a character and follows them
- In-world retro terminal + cartridge system: keystroke capture, scrollback, cursor editing, wrapping, rendered via a UMG delegate
- Self-contained 3D analog clock built from engine primitive meshes, hands tracking real machine time

## NetSentry

A defensive-security sentry for one household's LAN, PC, and Cloud Run apps

- Page: https://jm-portfolio-5afqr6ijoq-uc.a.run.app/#/project/netsentry
- Source: https://github.com/virtualhealthcitizen/netsentry
- Language: PowerShell
- Topics: security, powershell, network-scanning, cloud-run, windows

A small, repeatable defensive-security toolkit for a single household — Windows-native PowerShell, no nmap. It deep-scans the home LAN (host discovery + service scan + local-listener audit) and diffs the result against a known-good baseline, toasting on any new device or open port — with a fast between-sweeps ARP/neighbor watch that catches a new device the moment it joins. It audits this PC's Windows hardening (SMB/LLMNR/print-spooler surface, Defender/AV state, SMBv1, BitLocker) into a score; turns a Cloud Run service's request logs into visitor classes with deduced intent and scanner detection, and flags any PUBLIC (allUsers) invoke on a service's IAM policy for review; and runs a gitleaks-style secrets sweep over the operator's own repos, reporting redacted findings. An orchestrator, a WPF dashboard, toast alerting, and a daily scheduled sweep make it continuous monitoring that flags unusual things. Authorized own-assets only — secrets, device MACs, and raw logs stay gitignored; the repo ships redacted examples.

Highlights:

- Home-LAN discovery + service scan diffed against a known-good baseline → toast on any new device or open port (no nmap), plus a fast between-sweeps ARP watch
- Windows hardening audit scored against a baseline: SMB/LLMNR/print-spooler surface, Defender/AV state, SMBv1, BitLocker
- Cloud Run defense: request logs → visitor classes + deduced intent + scanner detection, and an IAM audit flagging any PUBLIC (allUsers) invoke for review
- Secrets hygiene: a gitleaks-style sweep of the operator's OWN repos → a redacted findings report; an orchestrator + WPF dashboard + toast + a daily scheduled sweep
- Authorized own-assets only — secrets, device MACs, and raw logs gitignored, with redacted examples committed

## Spinnaker Sandbox

Master Spinnaker through small runnable labs — pipelines-as-code with a local Lab Console

- Page: https://jm-portfolio-5afqr6ijoq-uc.a.run.app/#/project/spinnaker-sandbox
- Source: https://github.com/virtualhealthcitizen/spinnaker-sandbox
- Language: JavaScript
- Topics: spinnaker, continuous-delivery, pipelines-as-code, kubernetes, devops

A dependency-free playground for learning Spinnaker continuous delivery without a live cluster. Each lab lives under labs/<NN-slug>/ as a real pipeline definition (pipeline.json — the JSON shape Orca consumes), any manifests it needs, and a README teaching one concept, spanning a curriculum from linear deploys through deployment strategies (highlander, red/black, rolling, canary), triggers & artifacts, SpEL and notifications, and automated canary analysis (Kayenta) config, sources, and modes. A pragmatic JSON Schema plus a structural gate — an authoritative Windows PowerShell validator with a parity Bash/jq port — checks every pipeline for unique stage refIds, an acyclic requisiteStageRefIds DAG, no dangling edges, and required fields, and a self-test asserts each failure mode is still caught so the gate can't regress to a no-op. A static local Lab Console (the ui/) reads a generated catalog to render each pipeline's stage DAG and stream simulated per-stage console output, so you can watch a pipeline 'execute' with no Gate/Orca; a later adapter swaps the simulator for a real backend to tail live runs. Shipped continuously by an autonomous burn loop whose gate is the validator plus PowerShell and Node engine self-tests.

Highlights:

- 30+ self-contained labs: a Spinnaker curriculum from linear deploy → strategies → triggers/artifacts → SpEL → Kayenta canary, each a real pipeline.json + README
- Dependency-free structural gate: an authoritative PowerShell validator (unique refIds, acyclic DAG, no dangling edges, required fields) with a parity Bash/jq port
- Local Lab Console (static ui/) renders each pipeline's stage DAG and streams simulated per-stage console output — no live cluster required
- Self-test catches every failure mode (cycle, dangling edge, duplicate refId, missing field) so the gate can't silently become a no-op
- Everything validates locally with no live Spinnaker; a later adapter swaps the simulator for a real Gate/Orca to tail live runs

## PH1

A procedural space sandbox, built in Phaser 3

- Page: https://jm-portfolio-5afqr6ijoq-uc.a.run.app/#/project/nebula-drift
- Source: https://github.com/virtualhealthcitizen/nebula-drift
- Language: TypeScript
- Topics: phaser, typescript, vite, procedural-generation, webgl

PH1 is a procedural space sandbox: one persistent career across a seeded universe, its economy, and the planets you land on and walk. Built on Phaser 3 + TypeScript + Vite over a Phaser-free pure core, so the rules are testable on their own and the scenes only present them.

Highlights:

- A seeded universe — sectors, planets and asteroid fields generated from one per-account seed
- An economy you work — mine, refine, manufacture, market and fit, each a pure tested system
- Ship combat flown in its own scene, over a layered tank
- Planetary surfaces you land on and never leave — walk them, dig them, build on them
- A discipline and job career you level by doing
- Generated, not drawn — the art is made in code
- Pure model first, scene glue after — the rules run headlessly, under test

## Pipeworks

A Factorio-inspired management sim for Spinnaker CI/CD pipelines — build the delivery factory

- Page: https://jm-portfolio-5afqr6ijoq-uc.a.run.app/#/project/pipeworks
- Source: https://github.com/virtualhealthcitizen/pipeworks
- Language: TypeScript
- Topics: pixijs, react, typescript, vite, spinnaker, ci-cd, simulation, webgl

A management sim about operating a Spinnaker-style continuous-delivery pipeline, in the spirit of Factorio — ten releases in: v0.1.0 'Groundwork' laid the pure core and the live board, v0.2.0 'Depth' turned it into a game, v0.3.0 'Scale & Progression' added a ship-to-unlock technology tree and finite regional compute, v0.4.0 'Consequence' gave the systems local consequence (per-region capacity, artifact promotion), v0.5.0 'Promotion' scaled delivery across environments, v0.6.0 'Optimization' added the modules/beacons/quality layer, v0.7.0 'Legibility & Playability' built the game around the simulation, v0.8.0 'Dependencies' wired services into a delivery graph, v0.9.0 'Onboarding & Teach' made it teachable, v0.10.0 'AAA UI & Juice' lifted the board and HUD to a AAA finish, and v0.11.0 'Mastery' is in flight. Commits arrive like raw ore; you draw the delivery graph yourself — bake → test → deploy wired into a DAG — in a drag-to-build editor where cycles and dangling edges are illegal moves that stall execution until you fix them, and a growing stage catalog adds Manual Judgment gates, Check Preconditions soaks, external Run Jobs and recurring deploy-freeze windows; your DORA performance (deployment frequency, lead time, change-failure rate) is the score, with a per-key breakdown. A CI/CD organisation modelled as a factory under layered pressure: compute capacity browns out when over-subscribed, shared bake/deploy resource pools add finite infra contention, a buffered queue's contents spoil past a freshness TTL, and a monotonic system-fragility ratchet (Factorio's evolution factor) raises prod risk as the org grows — while a mounting demand-pressure antagonist means standing still loses ground. Deployment scales across environments: proven artifacts promote dev → staging → prod as linked pipelines (bake once, deploy many), each pre-prod stage a regression gate, rendered as contiguous board zones; and services can depend on one another — while a dependency is unhealthy (an open incident, or it hasn't shipped a version yet) the dependent's runs hold as visible backpressure until it recovers, with a cycle guard that rejects a dependency loop that would deadlock the whole chain. A ship-to-unlock technology tree gates the advanced catalog behind engineering capability you earn by deploying (progress and production are the same act); finite regional compute depletes and forces expansion, with per-region fuel, per-region agent pools you must staff, and a relocate-service lever; a slot-budgeted operator capability loadout carries your passive powers (the equipment grid, without the avatar); and fog-of-war observability means you instrument a service to watch it live or fly blind on a decaying last-known snapshot. Deployment strategy is a live risk/cost/speed dial — Highlander / Red-Black / Rolling / Canary, the last with opt-in Kayenta-style canary scoring — and each prod deploy mints a versioned server group, keeping the previous one as a hot standby (or destroying it) per the strategy; a reckless ship breeds a budget-draining incident you recover by rolling back to that standby, and MTTR feeds DORA. An optimization layer lets you invest for speed and reliability — modules/beacons-style speed upgrades (faster but power-hungrier), a compute-specialised agent class, and Factorio-quality build-reliability tiers — each a genuine, non-dominant tradeoff locked by a headless balance sweep. A diagnosis layer — per-stage bottleneck highlight, throughput sparklines, an agent-utilisation readout, a 'one thing to fix now' alert strip — plus a directives milestone ladder, an in-game Player's Manual, and juiced audio/visual feedback make it legible from the first minute; 1×/2×/4× speed control fast-forwards calm stretches. And it teaches itself: the opening is inverted so you hand-deploy the first build gate by gate until demand out-runs your clicking and the game hands you the automatic trigger (the demand antagonist is the teacher); a Runbooks menu of nine CI/CD lessons ticks itself as you perform each concept; a just-in-time coach surfaces the one tip that has just become relevant; the HUD progressively discloses advanced panels as their lesson unlocks; a self-play pilot runs the whole factory as an attract demo you can take over mid-run; and a three-axis mastery scorecard — throughput vs stability vs efficiency, with personal bests — makes the non-dominated ceiling visible, while Steady / Calm / Chaos difficulty storytellers shape how hard the demand ramp pushes. The domain model and the structural rules kernel — unique refIds, resolvable dependency edges, an acyclic DAG (Kahn), required fields — are ported from the sibling spinnaker-sandbox pipelines-as-code project, so it teaches the real tool rather than a cartoon of it. Built with PixiJS + React + TypeScript + Vite over a pure, deterministic, Pixi/React-free simulation core unit-tested with node:test (508 tests) and exercised end-to-end by a headless 240-second smoke simulation asserting invariants every frame. A live WebGL board renders each pipeline as a lane — stage nodes lit queued → running → succeeded / failed with artifacts flowing along the edges, tinting by freshness — beside a minimal, Murmur-descended control-room HUD.

Highlights:

- A CI/CD org modelled as a Factorio factory — commits arrive like ore, flow bake → test → deploy down a DAG; DORA (deploy frequency, lead time, change-failure) is the score, with a per-key breakdown
- A drag-to-build pipeline editor + a growing stage catalog — Manual Judgment, Check Preconditions, Run Job, recurring deploy-freeze windows; cycles are illegal moves that gate execution
- Multi-environment promotion — proven artifacts promote dev → staging → prod as linked pipelines (bake once, deploy many), each pre-prod stage a regression gate, rendered as contiguous board zones
- Cross-service dependencies — a service can wait on another; while the dependency is unhealthy the dependent's runs hold as visible backpressure, and a cycle guard rejects a dependency loop that would deadlock the chain
- A ship-to-unlock technology tree — the advanced catalog (stage types, canary, ops modules) gates behind engineering capability earned by deploying; progress and production are the same act
- Deployment strategy as a risk/cost/speed dial (Highlander / Red-Black / Rolling / Canary + opt-in Kayenta canary scoring) → versioned server groups with rollback to a standby
- Layered pressure — capacity brownout, finite bake/deploy resource pools, perishable artifacts (TTL), budget-draining incidents, an evolution-factor fragility ratchet, and a mounting demand-pressure antagonist so standing still loses
- Finite regional compute that depletes and forces expansion — per-region fuel, per-region agent pools you must staff, and a relocate-service lever — plus a slot-budgeted operator capability loadout and fog-of-war observability (the equipment grid without the avatar)
- An optimization layer — modules/beacons-style speed upgrades, a compute-specialised agent class, and Factorio-quality reliability tiers — each a non-dominant tradeoff locked by a headless balance sweep
- Playable from the first minute — first-run onboarding, an in-game Player's Manual, a directives milestone ladder, a 'one thing to fix now' alert strip, juiced audio/visual feedback, and a diagnosis layer (bottleneck highlight, throughput sparklines, agent-utilisation) + 1×/2×/4× speed control
- It teaches itself — an inverted opening (hand-deploy until demand out-runs you, then you're handed the machine), a self-ticking Runbooks menu of 9 CI/CD lessons, a just-in-time coach, progressive HUD disclosure, and a self-play attract demo you can take over mid-run
- A mastery ceiling you can see — a three-axis scorecard (throughput vs stability vs efficiency) on structurally-opposed axes the balance sweep proves non-dominated, plus Steady / Calm / Chaos difficulty storytellers. A personal best has to be earned (a run must be two minutes in and ten deploys deep before it banks one — two axes used to hand out a perfect 100 in the opening seconds, when nothing shipped means nothing failed), and each axis reports where the run sits as a percentile against a distribution swept from the simulation itself
- A AAA presentation layer over the sim — design tokens and a named type scale, a density setting, glass surfaces over the live board, a selective glow/bloom layer, a homegrown tweener driving success pops, failure impacts and event-driven screen shake, MSDF board labels crisp under zoom, and sound cues for both the world and your own clicks
- Two of the polish items were really reachability — a pan/zoom camera, because past roughly nine services the board grew taller than the canvas and those lanes were gone rather than merely off-screen (still running, still consuming capacity, with no way to look at them), and per-lane dirty-tracking, because redrawing every lane every frame was the frame budget at scale
- Nine releases shipped (v0.1.0 Groundwork → v0.9.0 Onboarding & Teach) with v0.10.0 AAA UI & Juice in flight — a pure, deterministic sim core: the spinnaker-sandbox rules kernel, 438 node:test cases + a headless 240s smoke sim

## sketchbook

A p5.js sketchbook where algorithms render as live generative art

- Page: https://jm-portfolio-5afqr6ijoq-uc.a.run.app/#/project/processing-sandbox
- Source: https://github.com/virtualhealthcitizen/processing-sandbox
- Language: JavaScript
- Topics: p5js, creative-coding, webgl, algorithms, generative-art

A p5.js sketchbook (repo slug: processing-sandbox) of 111 standalone sketches across 22 topics — algorithm visualizers (sorting, trees, graphs, bitwise, dynamic programming, backtracking, n-queens, tower of hanoi, consistent hashing) and generative art (GLSL shader spheres, harmonic particle text, trig meshes) — 105 of them rendered in WebGL, each its own HTML file that runs with no build step. Two tracks drive it. FIDELITY: a research-backed Graphics & Animation Quality roadmap (ROADMAP.md, 58 items across 7 phases) on a one-minor-release-per-phase cadence, lifting every sketch from 'runs' to top-tier visual quality. Its founding constraint has since been retired: a verified deep-research pass found the pinned p5 1.6.0 predated nearly every high-value technique, so v0.3.0 moved the whole collection to 1.11.13 behind a smoke harness — which unlocked most of the pipeline on the 1.x line (framebuffer bloom, image-based lighting and WebGL2 have all since shipped), leaving only shader hooks and instancing waiting on a 2.0 jump. Nine releases in, the antialiasing sweep is complete, bloom and IBL are live on the reel, and spring physics plus prefers-reduced-motion landed across it. INFRA: 'The Bench' (see the Design dossier) — a shared, opt-in runtime built to a strict non-breaking contract: loading it has zero side effects, a sketch opts in with one script tag, and ignoring it leaves today's behaviour exactly as it was. It now ships eight modules — a DPR/antialias canvas opener, a pausable clock, an easing library with damped springs, a transport bar, an orbit camera with mouse and touch parity, auto-hiding chrome, a fullscreen toggle and seed round-tripping through the URL — behind 80 dependency-free Node unit tests and an 11-assertion real-p5 browser harness, with 15 sketches adopted so far. A generated, manifest-driven gallery catalogs the collection with topic chips, text search, shareable deep-link routes, per-card embed snippets, and live iframe thumbnails capped at ten at once so 105 WebGL contexts never spin up together. The playable reel is preview-gated (each candidate reviewed and approved before it ships) on vendored p5 1.11.13, alongside the original hand-listed launcher.

Highlights:

- Research-backed graphics & animation quality roadmap — 58 items across 7 phases (ROADMAP.md), one minor release per phase
- The p5 upgrade already paid off — v0.3.0 moved the collection 1.6.0 -> 1.11.13 behind a smoke harness, unlocking framebuffers, image-based lighting & WebGL2 on the 1.x line; only shader hooks & instancing still need a 2.0 jump
- 111 standalone p5.js sketches across 22 topics — algorithm visualizers + generative shaders, 105 of them in WebGL
- Preview-gated playable reel of the real sketches on vendored p5 1.11.13, alongside the original hand-listed launcher
- 'The Bench' — an opt-in shared runtime under a zero-side-effect contract: 8 modules (AA/DPR canvas, pausable clock, springs & easing, transport bar, touch-capable orbit camera, auto-hide chrome, fullscreen, seed<->URL), 80 Node unit tests + an 11/11 real-p5 browser harness, 15 sketches adopted
- A generated, manifest-driven gallery — topic chips, text search, shareable deep-link routes, per-card copy-embed, and live thumbnails capped at ten so 105 WebGL contexts never spin up at once
- Grounded in a measured audit + verified deep research: the antialiasing sweep is complete (all 105 WebGL sketches antialiased, up from 6 after the first G1 pass), so the remaining headroom is colour management, the p5 2.0 jump & Bench adoption

## Orrery

A native control panel for the whole portfolio — it runs the commands itself, with no agent in the loop

- Page: https://jm-portfolio-5afqr6ijoq-uc.a.run.app/#/project/orrery
- Source: https://github.com/virtualhealthcitizen/orrery
- Language: TypeScript
- Topics: electron, typescript, react, vite, devtools, automation, gcp, control-panel

A desktop control panel for this portfolio, the sibling-repo fleet, and the GCP platform underneath them — built to do the things that were previously typed into a terminal, natively and without an assistant in the loop at runtime. It spawns the real processes (git, gh, npm, gcloud, gsutil, terraform, PowerShell) and streams their output; there is no service in the middle and nothing to be offline from. Fifty-nine operations live in a data catalog rather than in code paths, and the security model falls out of that shape: the renderer asks for an operation BY ID and cannot ask for a command, so parameters substitute per-argv-element and a branch named \`a&whoami\` is data rather than a shell injection — verified by a test that would execute it under a shell. Nothing runs until you have seen it: every operation resolves to a dry run first, showing the fully-substituted argv, the working directory, and whether it will spawn directly or route through cmd.exe, which is the terraform-plan discipline applied to shell commands. Friction then scales with blast radius — read and local operations run immediately, remote ones take a confirmation, and destructive ones require typing the target's own name — while a Safe Mode borrowed from k9s does not merely block dangerous operations but declines to register them, so there is nothing to mis-click. Jobs are owned by the main process (a renderer is closable, reloadable and crashable, and takes any spawn handle down with it), with a concurrency queue, sticky terminal states, a bounded ring buffer that reports what it evicted rather than silently dropping it, and log deltas batched at 32ms then coalesced onto a frame — because at ~0.6ms per IPC message a suite emitting 2,000 lines a second would otherwise spend more than a second of IPC per second of wall clock. The Windows process layer is the part that took the research: Node ignores PATHEXT when resolving a bare name and refuses to spawn .cmd shims at all since CVE-2024-27980, so the app walks PATH itself and routes batch shims through cmd.exe with ArgvQuote-quoted arguments; cancellation is \`taskkill /T /F\` because killing one process leaves grandchildren holding the file locks that fail the next run; and UTF-8 is forced into every child, since at a CP437 console the multi-byte characters are destroyed before any decoder sees them. The auto-updater was rebuilt from a four-cause post-mortem of the sibling app it replaces — progress synthesised from the feed's own file size so it survives a server that omits Content-Length, differential range requests disabled because a single-range server silently doubles every download, a strict-newer guard at both the available and downloaded events to close a self-reinstall loop, and eight distinguishable error classes in place of one ambiguous message. Its signature view is literal: the burn fleet's loops fire on a delay-compensated grid, and drawn as concentric rings with the fire minutes marked, that schedule is an orrery. Electron 43 + Vite 7 + React 19, one runtime dependency, zero native modules, hand-written CSS in OKLCH.

Highlights:

- Runs the real commands — git, gh, npm, gcloud, terraform, PowerShell — spawned directly and streamed live; no agent in the loop at runtime and no service in the middle
- 59 operations as DATA, not code paths — the renderer asks by operation id and cannot ask for a command, so a parameter is always an argv element (a branch named \`a&whoami\` is a name, not an injection)
- Dry run before anything spawns — the fully-resolved argv, the working directory, and whether it goes direct or via cmd.exe; terraform-plan discipline applied to shell commands
- Friction scales with blast radius — read/local run straight through, remote takes a confirmation, destructive makes you type the target's name; Safe Mode un-registers dangerous operations rather than blocking them, so there is nothing to mis-click
- The Windows process layer is the hard part — own PATH+PATHEXT walk (Node ignores PATHEXT), ArgvQuote-quoted cmd.exe routing for .cmd shims (Node won't spawn them since CVE-2024-27980), taskkill /T /F so orphans can't hold locks, and UTF-8 forced into every child
- Jobs live in the main process with a concurrency queue, sticky terminal states, and a ring buffer that reports what it evicted — log deltas batched at 32ms because one IPC message per line costs more than a second of IPC per second of output
- An auto-updater rebuilt from a four-cause post-mortem — progress synthesised from the feed's file size (survives a missing Content-Length), differential ranges off (a single-range server doubles every download), a strict-newer guard at both events, and eight distinguishable error classes instead of one
- The fleet dial is the name made literal — burn loops fire on a delay-compensated grid, and drawn as concentric rings with the fire minutes marked, that schedule is an orrery

## Resources

- [Concise index](https://jm-portfolio-5afqr6ijoq-uc.a.run.app/llms.txt): the one-line-per-project llms.txt
- [Release notes](https://jm-portfolio-5afqr6ijoq-uc.a.run.app/#/releases): cross-project changelog and semantic releases
- [RSS feed](https://jm-portfolio-5afqr6ijoq-uc.a.run.app/feed.xml): machine-readable release feed (RSS 2.0)
- [Sitemap](https://jm-portfolio-5afqr6ijoq-uc.a.run.app/sitemap.xml): every route and project page
- [humans.txt](https://jm-portfolio-5afqr6ijoq-uc.a.run.app/humans.txt): the site colophon (authors, stack, credits)