Infrastructure and Automation: One Day, Two Worlds
Morning: The Homelab Dashboard
Started the day with the /admin/homelab page. This thing had been half-baked for weeks—hardcoded service names, no live status, a bunch of placeholder buttons that didn't do anything.
The previous sessions had already done the groundwork: fixed Tailscale routing after Titan went down, discovered the rt-control tunnel was missing from Cloudflare, got the API inventory documented. So I had a solid foundation.
Spent about an hour and a half implementing a 7-phase plan that I'd drafted beforehand. The idea was straightforward: make the page actually poll the infrastructure and show real-time health dots.
What Got Built
- Container name mapping — 16 MasaiMara Docker services, 4 Proxmox VMs/LXCs. Each one gets a health dot that updates every 30 seconds.
- Live status badges — Shows whether the Unraid array is healthy, whether each host is reachable, which services are running.
- Control buttons — Play/restart/stop icons on each container. Clicking them triggers an action through the API with a spinner to show something's happening.
- Discovered services section — Shows containers we know about but aren't explicitly registered in the sidebar, so you can see what else is running.
The implementation was straightforward because I had battle-tested reference patterns from the servers page. Used Promise.allSettled() instead of Promise.all() so that if one API call fails, the others still go through. 30-second polling interval as a balance between responsiveness and load.
The Sticky Part
The rt-control proxy route was broken. The system was trying to hit rt-control.argobox.com directly, but that tunnel entry didn't exist in Cloudflare. The real rt-control instance lives on the Unraid as a local HTTP endpoint, but you can't reach it from the browser without a proxy.
Created a passthrough endpoint in mm-argobox that forwards requests to the internal rt-control API. Updated the ArgoBox route to hit mm-argobox instead. Straightforward proxy pattern, but getting the URL rewriting right took a few tries.
Build verified. Pushed to Gitea + GitHub. Everything was ready to deploy once mm-argobox got redeployed on MasaiMara.
Afternoon/Evening: Job Automation from Scratch
Then I switched gears entirely.
The job market is broken. Not philosophically—mechanically. Every job board has different forms, different submission flows, different expectations about resume formatting. Manual tailoring gets 3-4x response rates, but tailoring 50 applications takes 8-10 hours. Nobody has that time.
I'd been running a small internal system for this for a while. Built it for myself, tested it, it works. But it's tightly coupled to ArgoBox infrastructure—database on the Unraid, task scheduling through the agent system, resume storage in vaults. Not portable.
Spent 10 hours across three context windows building it out into a proper system.
The Architecture
Python core — 10 modules, about 2,800 lines:
models.py— Data structures for jobs, applications, resume dataresume_parser.py— Reads a .docx resume and extracts name, email, phone, skills, work history, educationbrowser.py— Playwright + stealth plugin so LinkedIn doesn't immediately flag the botai_helper.py— Claude Haiku for cover letters and screening question answers (cheaper than Sonnet, fast enough)tracker.py— SQLite database for tracking application pipeline. Status progression from pending → submitted → screening → interview/offer/rejected/ghostedlinkedin.py— The complicated one. Forms are dynamically generated, fields can appear in any order, some are required, some optional, some have prefilled defaults. 580 lines of logic to find all the form elements, match them to the resume data, fill them intelligently, detect when you're stuck in a loop (15-iteration counter), handle autocomplete fields, all of it.engine.py— Orchestrator. Loads the job CSV, parses the resume, launches the browser, logs in, iterates through jobs, tracks results.api.py— FastAPI REST API on port 8585 with 21 routes
ArgoBox integration — Dashboard page that talks to the Python API, shows stats, job queue, history, pipeline funnel, logs, and a Start Session modal where you pick which CSV to run and set parameters.
The Research Phase
Before writing linkedin.py, I spent time analyzing open-source LinkedIn bot projects. Five of them:
| Project | Notable |
|---|---|
| AIHawk (29.4k stars) | Dynamic resume per job via LLM, multi-provider AI |
| GodsScion (1.7k) | Best form handling — form type hierarchy, fuzzy matching, loop detection |
| nicolomantini (1.1k) | Learn-as-you-go Q&A logging |
| JobHuntr (397) | Runs inside a real Chrome profile |
| srikar-kodakandla (122) | AI-first, every question through LLM |
The GodsScion implementation was the most battle-tested. Cloned it, read every file. Their form detection uses data-test-form-element XPath to find everything in the Easy Apply modal, then they have a 5-type hierarchy: selects → radios → text inputs → textareas → checkboxes. Uses bidirectional fuzzy matching ("Yes" matches "I agree" both directions), has loop detection, handles autocomplete with type → sleep → ArrowDown → Enter.
Ported all of that to Playwright async API, added support for number inputs (they missed that), added clean discard-on-error path.
The Honesty Problem
Built a per-job resume tailoring system on top. For each job, Claude generates a tailored version: reorders skills to match the job description, rewrites bullet points to use the right terminology, adds keywords, reorders work experience by relevance.
But early on the prompt was too aggressive. It was fabricating job titles. "Senior DevOps Engineer with 5+ years" when the person had never held that title. User caught it immediately.
Rewrote the entire prompt with HONESTY as the highest priority:
- NEVER change job titles
- NEVER claim experience with technologies not in the resume
- NEVER invent numbers or metrics
- Summary should describe who they actually are
Keep the ATS optimization (right keywords where they genuinely apply) but don't fabricate experience. That's not optimization, that's fraud.
What Got Committed
10 files created in the autoapply module. Build passes. 21 API routes registered. Pattern matching tests pass (12/12). Dashboard renders. All the pieces work independently.
The Day in Summary
One morning debugging infrastructure APIs. One afternoon/evening building a job automation system from first principles.
The homelab dashboard is waiting for a redeploy. The job automation system is waiting for real-world testing—need to run it against an actual CSV and see what breaks.
Both feel solid. Both are the kind of work that's obvious in retrospect but required a lot of setup to get right. The infrastructure work was cleaner—existed in a bounded space, had clear reference implementations. The automation work was messier—had to research five competing approaches, choose patterns, adapt them to async Playwright, handle edge cases no one writes about.
But that's what makes it interesting. The homelab dashboard was about connecting dots that already existed. The job automation system was about building something that didn't exist yet.
Both shipped today.
Status: Homelab dashboard ready for mm-argobox redeploy. Job automation core system built, integration with ArgoBox complete, waiting for live testing and refinement.