repository-manager-gate-execution

Repository Manager — Gate Execution

rm_gates_* is the one tool that drives both tiers of the pre-commit gate: stage="fast" runs a repo's pre-commit-stage hooks (formatters/linters, no network/tests, target ≤5s warm); stage="heavy" runs its pre-push-stage hooks (pytest, cargo, uv lock --check, ...) via pre-commit run --hook-stage <stage>. The measured reason this skill exists: on 2026-08-21 a single epistemic-graph push cost roughly six hours because every one of six failing pre-commit hooks was re-proven, on every fix, by re-running the repo's entire 90-minute heavy wave — there was no way to ask "just the hooks that were failing." The same push's integration suite was independently reporting ~500 timeout errors that turned out to be one cold cargo build blowing a 60-second per-test fixture timeout, hiding 17 real failures underneath the noise. retest and the gate ledger close the first gap; profile is how you find the second kind before it hides anything.

When to use

• Submit a fast or heavy gate wave across one, several, or all repos (run).
• Re-validate a fix without re-running everything that already passed (retest) — narrows to whatever the ledger last recorded failing for that repo/stage, escalating to a full wave automatically once every retested hook passes.
• Poll a running wave, or get the roll-up of what's failing right now (status).
• Get condensed failure detail for one job/repo (explain).
• Find the slowest hooks or repos, fleet-wide or for one job (profile).

When NOT to use

• The merge queue's own differential gate-vs-base-ref comparison at land time → repository-manager-merge-and-reconcile.
• Python pyproject.toml install/build (not gate execution) → repository-manager-workspace-validation.
• Content-addressed build/cache dedup → repository-manager-build-coordination.
• Deciding how many heavy gate waves may run concurrently across the fleet → repository-manager-fleet-scale-operations.