Moved the server to Heroku — and a container that died in silence

Migration week. The server moved from Render to Heroku (student credits, plus Render’s cold starts were the slowest thing in the whole app). It should have been “change the remote, copy the config vars” — instead the dyno crashed on boot in under a second, exit 0, without printing a single byte. Not one log line. I swapped in a trivial entrypoint (worked), added boot breadcrumbs (never printed), pinned –platform=linux/amd64 (not it), and finally reduced the entrypoint to a bare exec printenv — which also produced zero output. That was the tell: nothing that went through sh -c survived. Root cause: my Dockerfile ended with ENTRYPOINT [“/bin/sh”, “-c”, “ASPNETCORE_HTTP_PORTS=${PORT:-8080} exec dotnet …”], and Heroku re-wraps your dyno command in its own sh -c. The inner string loses its quoting, so the outer shell parsed my entire command as just a variable assignment — a perfectly valid shell program that does nothing and exits 0. The fix is almost insulting: make the ENTRYPOINT a single token (/app/start.sh) — one argument can’t be re-split by anyone else’s shell. Cutover is done: config migrated, JWT secret rotated on purpose (all old sessions invalidated), auto-deploy on push wired up, the Heroku support ticket closed with the real root cause, and Render is now suspended. Verified working on a real phone.

A pet died in production and it was my fault. The anti-decay “absence shield” (long absence → your pet sleeps instead of dying) keyed off the last-activity date — which only got set when you logged a task. So: install the app, look around, never log anything, come back a week later → last activity is null, you fall through to the normal decay rule, and your pet starves without ever being protected. Found it with my own account: pet “Mario”, 50 XP, crystallized. Now birth itself stamps the activity anchor — creating an account counts as activity — plus a streak guard so your first-ever task counts as day 1 instead of day 0. The dev-only pet-state diagnostic endpoint I added to investigate is staying; it’s what exposed the whole case.

Furniture now drags like you’d expect. Press a piece and carry it around the room, with a magnet snapping it to the cell under your finger (grab-offset aware, silently refusing invalid cells). Tap-to-move and the D-pad still work. While in there I deleted the entire per-item “scale mod” system — eyeballed multipliers per furniture keyword — because the drawn width now simply is the isometric width of the item’s footprint. The double bed had 36% excess width and was climbing up the wall; now it sits exactly in its cells. Also measured real footprints for 19 more items against their actual sprites (tables, kitchens, piano, fireplace, aquarium…).

Rugs are floors now. They got their own slot: they don’t block furniture, furniture doesn’t block them, and they render in a separate pass so they’re always underneath — you can finally put the sofa on the rug. Also swapped the pretty-but-unreadable glass modal cards for opaque ones (text over a busy animated room was a lottery), fixed the birth ceremony’s name panel overlapping the creature, and the group-creation archetype picker is now a swipeable carousel.