gate

name	gate
description	**MANDATORY before every commit and push.** All gates must pass — Gates 1–3 always run; Gates 4 (Docker) and 5 (Cloud) run only when applicable. Do NOT proceed if any gate fails — fix the issue first.

Gate — Pre-Commit Quality Gate

MANDATORY before every commit and push. Gates 1–3 always run; Gates 4 (Docker) and 5 (Cloud) only when applicable. Do NOT ask for permission, skip gates, or continue past a failure — if any gate fails: STOP, fix, re-run the gate.

How to run the gates (fan out the independent ones)

Gate 1 (the coverage loop) is the long pole — start it first and let it finish. Gates 2–5 (security, build, docker, cloud-security) are mutually independent, so run them in parallel using the fan-out ladder from the subagents skill: prefer the Workflow tool (one stage per gate, schema-validated return), else parallel Agent/Task subagents, else serial. Each gate subagent returns a structured verdict:

{ "gate": "security", "status": "passed|failed|skipped", "severity": "critical|high|none", "findings": ["..."] }

The parent reduces the verdicts into the summary below: any failed with critical/high severity ⇒ overall FAILED. Cache each verdict keyed on the tree hash (git write-tree + clean-tree check) — the same key the gate-pass.py token uses (see Record the pass) — so a re-run on an unchanged tree reuses the verdict. Never reuse a verdict across a changed tree.

Gate 1 — Test Coverage (≥ 95%)

Run the test workflow, ALL test layers (unit, integration, E2E if configured).

• Lines ≥ 95% | Functions ≥ 95% | Statements ≥ 95% | Branches ≥ 90%
• Zero failing tests

Gate 2 — Security (no critical, no high)

Run the security workflow across every package manager found in the project.

• Zero critical, zero high vulnerabilities; no real secrets in tracked files
• Known exceptions count only if explicitly documented in the project's /security override (e.g. install-time-only transitive deps); when in doubt, treat as blocking

Gate 3 — Local Build

Detect and run all applicable builds:

PROJECT_ROOT=$(git rev-parse --show-toplevel)
cd "$PROJECT_ROOT"

npm frontend (if package.json + vite/webpack/next detected):

npm run build

npm backend (if api/package.json detected):

cd api && npm run build

Python (if pyproject.toml detected):

./venv/bin/python -m build 2>/dev/null || ./venv/bin/python -c "import py_compile, glob; [py_compile.compile(f, doraise=True) for f in glob.glob('**/*.py', recursive=True) if 'venv' not in f]"

• Zero compiler errors; zero TypeScript type errors (for TS projects)

Gate 4 — Docker Build (if Dockerfile present)

if [ -f "$PROJECT_ROOT/Dockerfile" ]; then
  docker build -t $(basename "$PROJECT_ROOT"):gate-check . --quiet
  echo "Docker build: ✅"
else
  echo "Docker build: skipped (no Dockerfile)"
fi

If the project has a docker-compose.yml, also verify it starts cleanly:

if [ -f "$PROJECT_ROOT/deploy/docker-compose.yml" ] || [ -f "$PROJECT_ROOT/docker-compose.yml" ]; then
  COMPOSE_FILE=${PROJECT_ROOT}/deploy/docker-compose.yml
  [ -f "$COMPOSE_FILE" ] || COMPOSE_FILE=${PROJECT_ROOT}/docker-compose.yml
  docker compose -f "$COMPOSE_FILE" config --quiet && echo "Compose config: ✅"
fi

Gate 5 — Cloud Security & Data Privacy (if cloud project)

Detect whether this project deploys to a cloud provider:

PROJECT_ROOT=$(git rev-parse --show-toplevel)
IS_CLOUD_PROJECT=false

# Detect project instruction file
INSTRUCTION_FILE=$(for f in CLAUDE.md AGENTS.md .cursorrules .windsurfrules .github/copilot-instructions.md GEMINI.md; do [ -f "$PROJECT_ROOT/$f" ] && echo "$PROJECT_ROOT/$f" && break; done)

# GCP: check for gcloud config, Terraform, or project instruction file references
if [ -n "$INSTRUCTION_FILE" ] && grep -qE "gcloud|GCP_PROJECT|GOOGLE_CLOUD_PROJECT|Cloud Run|Cloud SQL|Firebase" \
  "$INSTRUCTION_FILE" "$PROJECT_ROOT/.env.example" 2>/dev/null; then
  IS_CLOUD_PROJECT=true
fi

# AWS: check for aws-cli config or CDK/Terraform
if ls "$PROJECT_ROOT/terraform/" "$PROJECT_ROOT/infra/" "$PROJECT_ROOT/cdk.json" 2>/dev/null | grep -qE "aws|cdk"; then
  IS_CLOUD_PROJECT=true
fi

echo "Cloud project: $IS_CLOUD_PROJECT"

If IS_CLOUD_PROJECT=true, run the cloud-security workflow (full cloud security and data privacy scan):

• Zero CRITICAL findings (public data exposure, open credentials, public storage, SQL injection)
• Zero HIGH findings (missing SSL, overprivileged IAM, PII in logs, missing auth headers, eval() usage)
• MEDIUM/LOW findings: reported and tracked, non-blocking

If IS_CLOUD_PROJECT=false, Gate 5 is skipped.

Gate summary output

This is the reduce step: aggregate the verdicts (Gate 1 plus the parallel Gates 2–5). STATUS is PASSED only when every applicable gate reports passed with no critical/high severity:

QUALITY GATE RESULTS
Gate 1 Tests:          ✅ PASSED (FE 97% | BE 96%)   | ❌ FAILED (BE 88%)
Gate 2 Security:       ✅ PASSED (0 critical, 0 high) | ❌ FAILED
Gate 3 Build:          ✅ PASSED                      | ❌ FAILED
Gate 4 Docker:         ✅ PASSED | skipped            | ❌ FAILED
Gate 5 Cloud/Privacy:  ✅ PASSED | skipped            | ❌ FAILED (1 CRITICAL)
STATUS: ✅ ALL GATES PASSED — safe to commit | ❌ GATE FAILED — fix issues before commit

Do NOT commit or push until STATUS shows ALL GATES PASSED.

Record the pass (enables the gate-on-commit hook)

Only when the summary shows ALL GATES PASSED, record the pass so the optional gate-on-commit hook will allow the next commit/push:

python3 ~/100xprism/hooks/gate-pass.py 2>/dev/null || true

This writes a token for the current tree state (HEAD + tracked diff + untracked files) to ~/.100xprism/gate-cache; any later edit invalidates it and re-arms the gate. If a gate failed, do NOT run this — leave the cache stale so the commit stays blocked.