safe-deploy-workflowlisted

# Safe Deployment Workflow Patterns for deploying code to servers without accidentally leaking secrets, overwriting fixes, or breaking CORS. ## When to Use - Deploying any code to a remote server (rsync, scp, git pull) - Modifying server config files (proxy, PM2, env vars) - Fixing bugs on the server and syncing back to source repo - Any workflow where code lives in both a local git repo AND on a server - Auditing or rotating API keys across local configs and agent config files (see `references/api-key-audit.md`) ## The Golden Rule **GitHub = source of truth. Server = deployment target. Never the reverse.** Fixes go: local repo → commit → push → deploy to server. If you fix something directly on the server, it WILL be overwritten next deploy. ## Git Hygiene ### Before Every Commit ```bash git status # Check what's staged git diff --staged # Review all changes ``` ### NEVER `git add -A` in an unguarded directory `git add -A` catches everything including `.env` (with API keys), `.ds_key`, `.secret`, and any other hidden files, plus `node_modules/` (thousands of files). Always set up `.gitignore` FIRST: ``` node_modules/ .env .env.* .ds_key *.log *.bak ``` **CRITICAL: Scan ALL dotfiles before any commit.** Files like `.ds_key` and `.secret` are the most dangerous because they're invisible in directory listings and often contain raw API keys. Before any `git add`, run: ```bash find . -maxdepth 1 -name ".*" -not -name ".git" -not -name ".gitignore" -exec f