Quality Gates
Automated checkpoints that code must pass before deployment. Lint, test, build - the essential gates that maintain code quality.
Definition
Quality Gates are automated checkpoints that code must pass before it can be pushed to the repository. They consist of three primary checks: linting (code style), testing (functionality), and building (compilation).
In Farmwork, quality gates are enforced through the /push command, which runs all gates in sequence. If any gate fails, the push is aborted, and you're given the opportunity to fix the issues.
Philosophy
Core Principle
Never push broken code. Quality gates are non-negotiable checkpoints. They're not suggestions - they're requirements. Code that doesn't pass doesn't ship.
In farming, you don't send diseased crops to market. Quality control happens before distribution, not after. Quality gates apply the same principle to code - catch problems before they spread to your repository and your users.
Why Gates Matter
- Prevents broken code from reaching production
- Maintains consistent code style across the team
- Catches regressions before they're deployed
- Builds confidence in the codebase
- Reduces debugging time by catching issues early
The Gates
| Gate | Purpose | Common Tools |
|---|---|---|
| Lint | Code style, formatting, static analysis | ESLint, Prettier, Biome |
| Test | Unit tests, integration tests, coverage | Jest, Vitest, Playwright |
| Build | Compilation, bundling, type checking | TypeScript, Vite, Webpack |
Gates Are Optional
Each gate is automatically skipped if the corresponding script doesn't exist in your package.json. This means Farmwork works great with static HTML sites and projects without build steps. When a gate is skipped, you'll see a message like (skipped - no lint script).
Gates run in order. If lint fails, tests don't run. If tests fail, build doesn't run. This fail-fast approach saves time by stopping at the first problem.
The /push Command
/push is an 11-step process that handles the complete deployment workflow:
1. Clean system files (.DS_Store, etc.)
2. Sync package dependencies
3. Run code-cleaner agent
4. Run linter (with auto-fix)
5. Run test suite
6. Run build
7. Generate commit message
8. Stage changes
9. Create commit
10. Push to remote
11. Update FARMHOUSE.md metricsCode Cleaning
Before gates run, the code-cleaner agent removes console.logs, commented code, and dead code. This ensures you're not pushing development artifacts to production.
Handling Failures
When a gate fails, /push stops and reports the issue. You have options:
Lint Failures
- Auto-fix runs automatically for most issues
- Remaining issues need manual attention
- Fix, then run /push again
Test Failures
- Review failing test output
- Fix code or update test expectations
- Don't skip tests - they're protecting you
Build Failures
- Usually TypeScript or bundler errors
- Check error messages for file/line numbers
- Fix type errors before retrying
Don't Skip Gates
It's tempting to skip failing gates to "just push this quick fix." Don't. That's how technical debt accumulates. Fix the issue properly or don't push.
Configuration
Quality gates use your project's existing tooling. Farmwork doesn't impose specific tools - it runs whatever lint, test, and build commands your package.json defines.
{
"scripts": {
"lint": "eslint . --fix",
"test": "vitest run",
"build": "tsc && vite build"
}
}
If your project uses different script names (e.g., check instead of lint), update the /push command configuration to match your setup.
No package.json? No Problem
For static HTML sites or projects without Node.js, Farmwork gracefully skips all package-related steps. The /push command will still clean files, stage changes, generate commits, and push to remote - it just won't run lint, test, or build since they don't apply.