mcp-memory/agent-rules/workflow-constraints.md

name, description, trigger

name	description	trigger
workflow-constraints	Strict behavioral constraints for Jenkins, staging deployments, git investigations, and background tasks.	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.