chore: migrate global agent rules into repository and update deployment scripts

agent-rules/workflow-constraints.md

@@ -0,0 +1,34 @@
+---
+name: workflow-constraints
+description: Strict behavioral constraints for Jenkins, staging deployments, git investigations, and background tasks.
+trigger: always_on
+---
+
+# 1. Strict Background Task Control
+- **Rule:** Do not run continuous background polling, background loops, or test suites unless explicitly requested.
+- **Rule:** If the user says 'stop' or 'don't run anything', kill all tasks immediately and stop launching new ones.
+
+# 2. No Unauthorized Jenkins Deployments
+- **Rule:** Never trigger Jenkins CI/CD pipelines (`jn run`) automatically. Always wait for explicit user approval before deploying via Jenkins.
+
+# 3. Hot Deploy & Visual Verification
+- **Rule:** In `ai-pr-review`, never `git push` without first hot-deploying to staging using `just deploy-code aipoc` and running the relevant sandbox E2E test to allow visual confirmation, and wait for human visual verification to complete before git push.
+- **WARNING (Jenkins Conflict):** Hot-deploying creates manual containers on `aipoc`. If you subsequently trigger a Jenkins deployment to `aipoc` (`ai-pr-review-ansible-deploy`), the Ansible playbook will fail with a Docker naming conflict (`Error when allocating new name: Conflict`). You MUST SSH into `aipoc` and manually remove the conflicting containers (`sudo docker rm -f <container_id>`) before running the Jenkins deployment.
+
+# 4. Git Investigation Constraints
+- **Rule:** Confine code investigations and debugging to actual code diffs. Never rely lazily on git commit messages to determine what changed.
+
+# 5. Git Push and Gatekeeper Constraints
+- **Rule:** Before running `git push`, you MUST ensure the git working tree is completely clean (`git status`). Untracked scratch scripts or uncommitted formatting changes will cause the pre-push gatekeeper to hang indefinitely.
+- **Rule:** If a `git push` task hangs, kill it, investigate and clean the working tree (using `git clean -fd` or `git restore`), and retry. NEVER poll a hanging push task in a loop.
+- **Rule:** NEVER use `git push --no-verify` to bypass a hanging pre-push hook. The hook is hanging due to environment state, not failing tests.
+# 6. Strict Process Termination (Zombie Cleanups)
+- **Rule (CRITICAL):** NEVER kill processes using broad wildcard name matches (e.g., Get-Process | Where-Object Name -match "cargo|rustc"). This causes collateral damage to globally deployed binaries (e.g., in ~/.local/bin/).
+- **Rule:** When cleaning up zombie files or locked compiler processes, you MUST strictly target the process by its Path to ensure it originates from the current workspace's 	arget/ directory (e.g., Get-Process | Where-Object { $_.Path -match "\\target\\" } | Stop-Process -Force).
+
+# 7. GCP / GCR Troubleshooting Constraints
+- **Rule (GCR 403 Forbidden):** Google Container Registry obscures `404 Not Found` errors as `403 Forbidden` for security reasons. If a `docker pull` or `podman pull` from GCR fails with `403 Forbidden`, you MUST explicitly verify that the image path and tag are 100% correct (checking prefixes, project IDs, and typos) before assuming it is an IAM or Service Account permission issue.
+
+# 8. GCP Infrastructure Provisioning (gcloud & Cloud Armor)
+- **Rule (Cloud Armor IP Limits):** GCP Cloud Armor security policies strictly enforce a limit of **10 IP ranges per rule** (`--src-ip-ranges`). When allowlisting large services (like Atlassian Bitbucket which has 11+ IP CIDR blocks), you MUST split the ranges across multiple rules (e.g., priority 1000 and 1001) to prevent the `Only a maximum of 10 IP ranges allowed per rule` API error.
+- **Rule (gcloud Idempotency):** When writing bash scripts to provision GCP infrastructure, NEVER use bare `gcloud ... create` commands. You MUST wrap all creation commands in existence checks (e.g., `if ! gcloud ... describe ... >/dev/null 2>&1; then ... fi`) to ensure the script is fully idempotent and can be safely retried upon failure.