2026-10-01 finding: /opt/unlikely-api/docker-compose.yml bind-mounts the compose project directory at /app on every service (.:/app), so the image’s /app is shadowed and the directory docker compose up ran from IS the live code until the next deploy. A build from /opt/unlikely-api puts the shared, often dirty, tree into production; a clean-worktree deploy (git worktree add —detach ~/.tmp/deploy-, copy .env, docker-compose.deploy-override.yml keeping data/ + monitor-latest.json on the main checkout, docker compose -p unlikely-api --project-directory $WT -f $WT/docker-compose.yml -f $WT/docker-compose.deploy-override.yml up -d --build unlikely-api worker scheduler) must leave its worktree in place; check docker inspect unlikely-api Mounts before removing any worktree. On 2026-10-01 four parallel sessions re-pointed /app four times in ten minutes and a cert drafted in between rendered on the wrong code. Production since 08:55 ET: /home/claude/.tmp/deploy-08f040f (master HEAD). Memory: feedback_deploy_from_clean_worktree.
2026-10-01 09:01 ET update: production now mounts /opt/unlikely-api itself (the shared main tree, clean at master HEAD 8a65c7b when deployed by one of the chip sessions); the morning’s two deploy worktrees (deploy-4cf7c2d, deploy-08f040f) were removed after they stopped being mounted. Standing rule unchanged: whatever directory docker compose up ran from is production, so keep the main tree clean or deploy a persistent clean worktree with docker-compose.deploy-override.yml, and check the /app mounts before removing any worktree.