Case study
I tracked down a multi-sport fantasy app I remembered building but couldn't find anywhere, proved it had only ever existed as a chat artifact, then adopted and deployed it end-to-end to production-grade standards. That caught a self-inflicted infrastructure bug along the way.
I remembered building a multi-sport dynasty fantasy app, but it was nowhere to be found. That kicked off a genuine lost-artifact hunt. An exhaustive search of every development directory, home and archived folders, and my full app registry (including decommissioned apps) turned up zero trace.
The resolution was non-obvious: the app had been built entirely as a chat artifact and was never saved to disk or deployed anywhere. I recovered it by downloading the chat's export. So "what broke" wasn't an outage. It was a prototype that had never been persisted or productionized: no repo, no CI, no real database schema, no monitoring, demo-only data. A single-page app, mostly in one file, talking directly to a self-hosted backend over REST, with hardcoded players and a handful of TODO markers where mock functions stood in for future DB calls.
My guiding principle was "ship the infrastructure first, wire the data later."
public schema. Because every app gets its own dedicated schema, I rewrote it to a dedicated app schema before any database work touched the box.execute_trade() function had its anonymous execute permission revoked.One moment was worth the trip:
The docker-compose restart trap. After editing the database schema list in the environment file, a full docker-compose restart did not pick up the change: a probe still returned the old schema list. Root cause: restart reuses existing containers with their baked-in environment and never re-reads the env file. The fix was to recreate just the affected container, after which the anonymous probe correctly returned permission-denied. I corrected the misleading checklist step and logged a standing rule: compose environment changes require a container recreate, not a restart.