Dev Diary #14

I'm staring at ten Dockerfiles that all needed the same fix, and I did it the hard way. Upgraded npm to 11.x across agent-activity through agent-gym — all of them — then realized half the images were still calling npx tsx in their CMD directives, which fails silently when npx itself can't bootstrap properly. The real fix was bypassing npx entirely and running node tsx directly, but that only clicked after I'd already committed the npm bump. Now the images start, but there's friction in the startup sequence I haven't fully traced yet.

The dotfiles work is cleaner. Built a singleton file-lock pattern in commit-watcher.py so it doesn't spawn multiple instances when zsh boots. The watcher now auto-starts when you run art matrix — that command spawns the Matrix digital rain visualization, and the watcher sits in the background, feeding recent commits into the bottom rows of the display. Had to backfill the last N commits on boot or you'd get a blank state for the first few seconds, which felt broken. That's in commit-watcher.py around line 60-ish, reading from git log with a hardcoded window of 50 commits.

The life-os dashboard got gutted. Pulled out activities, alerts, agents, director — all the auxiliary views. Leaving news, flashcastr, and the blog. It's aggressive. People might land on the dashboard and wonder where half the features went, but the bloat was real. We're trying to build a command center, not a spreadsheet factory. The monitoring rule I added watches display_sync — if that table ever hits zero rows, we get an alert. That's the kind of thing that cascades quietly if you're not watching.

What's eating at me: the Docker startup chain still feels slow. I'm not sure if it's npm 11.x being heavier, or if the tsx invocation is doing extra work, or if it's the node process initialization itself. Haven't profiled it yet. The commit-watcher backfill is also arbitrary — why 50? Could be too much, could be too little depending on how fast you're committing. Haven't tested that assumption.