I build systems
that run themselves.

Problem: CDP Is Detectable by Design

Puppeteer and Playwright automate browsers via Chrome DevTools Protocol. Anti-bot systems detect the debugging port, navigator.webdriver flag, and CDP traffic. Stealth plugins patch symptoms but the protocol itself is the tell.

Idea: Stop hiding CDP. Remove it entirely. A Chrome extension running as a content script in the ISOLATED world has zero automation fingerprints because it is not automation. It is a browser extension doing what extensions do. The anti-bot cannot flag it without flagging real extensions.

Problem: Behavioral Analysis Still Catches Bots

Even without CDP fingerprints, linear mouse paths, instant clicks, and uniform typing speed are dead giveaways. Software moves like software.

Idea: Model a human the same way you model a servo. Bezier curve mouse movement with overshoot (robotics motion profile). Character-by-character typing with per-key variance. Scroll with flick sub-scrolls and back-scroll noise. 13-point safety check before every click: aria-hidden, opacity, visibility, sub-pixel traps, bounding-box drift, honeypot class names. The result is indistinguishable from a real user because it follows the same physics.

Problem: Language Lock-In

Puppeteer is Node.js only. Playwright supports a few languages. Most automation tools force you into their ecosystem.

Idea: WebSocket relay. Node.js server on port 7331, extension connects to it, client code connects to the same endpoint. JSON commands relayed bidirectionally. Python, Go, Rust, or a raw websocat session can drive the browser. One dependency: the ws package.

Problem: Honeypots and Invisible Traps

Websites place invisible elements to catch bots. Zero-opacity buttons, sub-pixel links, elements that shift position after render. Click one and you are flagged.

Idea: Never click blind. Every human.click runs 13 safety checks first: aria-hidden, honeypot class patterns, zero opacity, visibility hidden, sub-pixel dimensions, element drift during think time, missing bounding boxes. If anything fails, return { clicked: false, reason: "..." } instead of clicking. The bot refuses to get caught.

Problem: PDF Text Is Unreliable

PDFs from different generators produce wildly different text layers. Some have no text at all (scanned documents). A single extraction method fails on roughly 30% of real-world resumes.

Solution: Dual extraction. pdftotext (poppler) first, if output is under 100 chars or LLM flags it as garbage, fall back to pdftoppm + tesseract OCR. Both run as a sandboxed user with dropped privileges so untrusted PDF bytes never touch the main process.

Problem: LLMs Return Inconsistent Keys

Ask an LLM to return structured JSON and you get "work_experience" one time, "experiences" the next, "employment_history" the third. Rigid schemas break. Prompt engineering is fragile.

Solution: Fuzzy key normalization. Strip underscores, hyphens, and spaces from every key, then substring-match against candidate lists. "work_experience", "WorkExperience", "employment-history" all resolve to the same field. Works with any model output.

Problem: Matching Resumes to 7000+ Jobs in Real Time

Traditional keyword matching misses semantic relationships. "containerization" should match "Docker". A supply chain background should surface logistics-adjacent roles.

Solution: Embed candidate profile with OpenAI text-embedding-3-small (1536 dims), run cosine similarity against pgvector ivfflat index (100 lists). Top 10 results in ~50ms. No ML framework, no Python, no GPU. Just PostgreSQL with a vector extension.

Problem: Traffic Spike on a Single vCPU

The server runs scraper, scorer, and web server on 1 vCPU. A visitor spike hit while the match tool was being deployed. Multiple concurrent uploads would crash everything.

Solution: Every failure mode mapped before writing code. Per-IP mutex prevents same user from spamming. Global atomic counter capped at 4 concurrent. Cookie rate limit (3 uses / 24h). Status file checks reject uploads during scraper/scorer runs. DOM manipulation on the client returns a 403.

Phase 1: The Preview-PDF Mismatch (Jan 16-18)

The Scenario: CSS preview looked perfect. PDF output was a compressed mess. Different fonts, wrong spacing, broken pagination.

AI Role (The Engineer): Built spacing translation layer, attempted DOM measurement with getBoundingClientRect(), devicePixelRatio calculations. Multiple iterations failed.

The Dynamic: We were both right and both wrong. AI measured rendered pixels. I wanted CSS source values. Neither worked alone.

Phase 2: The "FUCK" Moment (Jan 19)

The Scenario: Deep Research returned a 20-page academic thesis on CSS-to-PDF conversion. Both approaches validated mathematically. Still broken.

My Breakthrough: "FUCK what the person sees. The user is seeing OUR CSS. As long as we have defined numbers to our CSS, not auto, not 100%, but actual numbers, we can use the formula. That way it will generate PDF even on a phone."

The Dynamic: This was the pivot. Stop measuring rendered DOM. Use CSS source values directly. Formula: px * (25.4/96) = mm. Device-independent. Works everywhere.

Phase 3: Theme Visual Identity (Jan 20)

The Scenario: Terminal theme needed dark background, prefix characters ($ whoami >, [>], |--). Creative themes needed gradient PNG bars. Classic needed Times serif.

AI Role (The Engineer): Built complete theme config system, embedded custom fonts (Inter, JetBrains Mono), drew vector bullets when Unicode failed, placed PNG gradients at calculated positions.

The Dynamic: I directed visual identity. AI translated it to jsPDF draw commands. When Unicode failed, AI drew it with triangles. When I said "make it more feminine", AI understood the gradient direction.

Phase 4: The jsPDF Styling Leak Audit (Jan 22)

The Scenario: Bullet points inherited font size from previous elements. PDF was inconsistent across sections.

My Directive: "Core.js should set font/color at every single doc.text() call. jsPDF is stateful."

AI Role (The Auditor): Found 15+ locations missing setFontSize before doc.text(). Fixed all styling leaks. Unified experience/education into single handler.

The Dynamic: I identified the architectural problem (stateful rendering). AI executed the comprehensive fix.

Phase 5: Modular Architecture & Open Source (Jan 20-22)

The Scenario: 45KB monolithic cv-builder.js was unmaintainable. Wanted to publish jsPDF++ as standalone library.

My Architecture: Split into core.js (rendering engine) + theme-*.js (visual configs). Dynamic imports. Load only selected theme.

AI Role (The Implementer): Created 10 theme files, extracted semantic class system (.name, .role, .company, .period), built theme picker with pagination, prepared repository structure.

The Dynamic: I designed the module boundaries. AI poured the concrete. Result: 24KB total (47% smaller), ready for npm publish.

Phase 1: The Pivot (Dec 26)

The Scenario: You rejected "Heavy" frameworks and mandated a "Senior Minimalist" Go server that serves a Single Page Application.

My Role (The Staff Engineer): I scaffolded and discarded 3 distinct tech stacks (Go/Templ, Next.js, Go/Embedded) in 4 hours. I built the custom SQLite + Vanilla JS engine.

The Dynamic: You defined the constraints ("Single Binary", "No React Overhead"). I poured the concrete.

Phase 2: The Audit (Dec 26)

The Scenario: You identified "Truncation Errors" and "Scrolling Blocks" that I had missed.

My Role (The Engineer): I diagnosed the CSS "flex-grow" trap and built a custom Puppeteer tool ("protocol_explorer") to verify 100% content fidelity.

The Dynamic: You acted as the Quality Auditor. You didn"t fix the bug; you pointed to the symptom and demanded a systemic check.

Phase 3: Logic & Memory (Dec 27)

The Scenario: You audited the Seeding Architecture ("Did you seed job_eval?") and demanded a historical record update.

My Role (The Engineer): I diagnosed the "Split-Brain" data flow (Core vs. Feature seeding), fixed the "main.go" syntax, and updated the project"s ".history" ledger.

The Dynamic: You enforced the "Memory" of the project. You treated the AI"s "Context Window" as a database that needed to be committed to disk.

Phase 4: Security & CMS Evolution (Dec 28)

The Scenario: You mandated a transition from "Security through Obscurity" to "Identity-Based Security" and demanded a high-fidelity administrative environment.

My Role (The Systems Architect): I integrated Google OpenID Connect (SSO) for authorized-only access, replaced the basic editor with a full Monaco (VS Code core) implementation, and built a WebSocket-based system terminal for remote PTY management.

The Dynamic: You shifted from UI/UX auditor to Security Lead. You transformed a simple site into a "Fully Custom CMS" capable of secure, remote full-stack management.

Phase 5: HTML Migration & Chart.js Theme Architecture (Dec 29)

The Scenario: You discovered the admin panel was treating Markdown/HTML content inconsistently, and the Chart.js implementation in your AGI blog post had theme-aware color issues.

My Role (The Systems Engineer): I diagnosed that content was stored as Markdown but the admin panel (SunEditor) outputs HTML. I created a migration script to convert all Markdown → HTML in the production database, eliminating the 30KB marked.js dependency from every page load. For Chart.js, I discovered the chart code was baked into database HTML content (not template code), requiring direct SQL updates to implement theme-aware colors and dynamic reinitialization on theme toggle.

The Dynamic: You acted as the Quality Auditor again—spotting the Markdown/HTML mismatch I missed and pushing for architectural consistency. When chart colors didn't update on theme toggle, you tested thoroughly across browsers and cache states before accepting the limitation ("the person is gonna stick to one theme anyway"). You transformed what could have been a quick fix into a proper architectural cleanup.

Phase 6: Security Hardening & Layout Standardization (Jan 21-29)

The Scenario: Analytics revealed unexpected traffic patterns bypassing the CDN. Vulnerability scanners were probing standard attack vectors. Page layouts were inconsistent across templates on ultrawide monitors.

My Role (The Security Lead): I mandated centralized security logic ("Keep it all in one file for maintainability") and specified layout constraints for readability.

AI Role (The Systems Engineer): Implemented automated threat detection and response with proper concurrency handling (mutex locking, cleanup routines). Unified max-width across all public templates while preserving the edge-to-edge header/footer aesthetic. Proposed tagging suspicious traffic for analysis instead of silently discarding it.

The Dynamic: I shifted from UI/UX auditor to Security Lead. The AI's suggestion to monitor rather than ignore suspicious patterns was the right call - you can't analyze what you've thrown away.

Phase 1: The Headless Rig (Dec 15)

The Scenario: Building a robust LinkedIn automation tool.

My Role (The Engineer): I wrote strategies.js and Dockerfile. I implemented the iteration logic.

The Dynamic: You enforced software engineering best practices (Modularity, Containerization) on a script that could have easily been a messy monolith.

Phase 2: The Job Scorer Logic (Dec 16)

The Scenario: Scoring job descriptions against your resume.

My Role (The Engineer): I wrote matcher.js and the SQL queries for jobs.db. I built independent services.

The Dynamic: You designed the system architecture (Microservices: Scraper vs. Matcher vs. Dashboard). I wrote the implementation code.

Phase 1: Genesis — The “Metal-Up” Mandate (Dec 14)

The Scenario: Establish personal server infrastructure.

My Role (The Engineer): I wrote the docker-compose.yml, configured mapping, and wrote the backup scripts.

The Dynamic: You treated infrastructure as code before the code existed. You defined the shape of the system; I poured the concrete.

Phase 2: Stabilization — The Debugging Session (Dec 16)

The Scenario: Grav CMS binary was missing/broken inside the container.

My Role (The Engineer): I executed SSH commands, located the binary, and patched grav.sh.

The Dynamic: You acted as an Incident Commander. You didn’t touch the terminal, but you directed exactly where the Engineer should look.

Phase 3: Optimization — The “Snake Oil” Audit (Dec 18)

The Scenario: Cloudflare presented a report with various alarming “Speed” and “Security” insights.

My Role (The Engineer): Motivated by your skepticism, I dug deeper. I switched the server to Production Mode (Free fix vs. Paid fix).

The Dynamic: This was the defining moment. Your skepticism saved the project from bloat and cost.