Quality Gates & Skill Automation
Relevant source files
The following files were used as context for generating this wiki page:
Introduction
Quality Gates and Skill Automation represent the core enforcement mechanisms within the FLEXT ecosystem to ensure code reliability, security, and architectural consistency. These systems operate through a combination of mandatory "make" verbs, pre-commit hooks, and specialized automation "skills" that detect policy violations using static analysis tools.
The scope of these gates covers the entire development lifecycle, from local feature branch development to final CI validation. By utilizing script-first automations, the project ensures that quality requirements are reproducible and enforceable by CI-style commands, maintaining high standards across foundation libraries and web interfaces.
Sources: guides/skill-automation-pattern.md:1-12, guides/development.md:144-156, index.md:27-30
Skill Automation Pattern
The Skill Automation Pattern is designed to create reusable, script-first automations that are enforceable by CI commands. Each automation is encapsulated in a "skill" folder containing detection rules, baselines, and documentation.
Skill Structure
Each automation family must deliver a standardized folder structure located under .agents/skills/<automation-name>/.
| Component | Description |
|---|---|
SKILL.md | The canonical skill document defining scope, rules, and instructions. |
rules.yml | Detection rules using ast-grep, ripgrep, or custom logic. |
rules/ | A directory containing individual ast-grep rule files. |
baseline.json | An auto-generated violation baseline to track existing debt. |
report.json | The output report generated after a skill validation run. |
Sources: guides/skill-automation-pattern.md:14-23, guides/skill-automation-pattern.md:58-64
Skill Execution Flow
Skills are validated using a generic runner script (scripts/core/skill_validate.py). This runner handles discovery and execution of rules across the codebase.
The runner supports specific skill validation or repository-wide execution via the --all flag.
Sources: guides/skill-automation-pattern.md:25-33, guides/skill-automation-pattern.md:66-67
Quality Gates & Verification
Quality gates are the mandatory checkpoints integrated into the Makefile and pre-commit workflow. These gates enforce strict adherence to type safety, linting standards, and security policies.
Core Quality Verbs
FLEXT utilizes canonical make verbs to categorize and execute quality checks.
| Command | Action | Threshold/Scope |
|---|---|---|
make check | Quick validation | Runs linting and basic checks before commit. |
make lint | Linting (Ruff) | Enforces zero violations in production code. |
make type-check | Type safety (MyPy) | Enforces MyPy strict mode (Zero Tolerance). |
make security | Security scanning | Uses Bandit to identify vulnerabilities. |
make test | Functional testing | Requires 85%+ coverage for core, 75%+ for apps. |
make val | Full validation | Execution of all gates; mandatory before push. |
Sources: guides/development.md:158-166, guides/testing.md:18-24, index.md:27-30, README.md:46-49
The "Zero Tolerance" Type Safety Gate
The project enforces a zero-tolerance policy regarding type safety. All operations must use complete type annotations and follow the Railway-Oriented Programming (ROP) pattern using the r[T] result type.
# Correct implementation enforced by Quality Gates
from __future__ import annotations
def process_data(data: t.JsonMapping) -> p.Result[ProcessedData]:
"""Process data with type safety."""
if not data:
return r[ProcessedData].fail("Data required")
return r[ProcessedData].ok(ProcessedData(**data))
Sources: guides/development.md:104-113, pyproject.toml:135-155
Automated Testing Framework
Testing is a critical component of the quality gate system, structured into unit, integration, and end-to-end (E2E) categories.
Testing Hierarchy
The testing system is organized to ensure both isolation and full workflow validation.
The pyproject.toml file defines coverage goals, with a minimum fail_under = 25 for general packages, though documentation specifies higher standards (85%+) for foundation libraries like flext-core.
Sources: guides/testing.md:32-38, guides/testing.md:18-21, pyproject.toml:115-119
Verification Commands
Developers must verify their changes using targeted project commands.
# Project-specific quality verification
make check PROJECT=flext-web
make test PROJECT=flext-web
Sources: development.md:21-25, development.md:54-58
Conclusion
Quality Gates and Skill Automation in flext-web ensure that every contribution adheres to the "Engineering Law" of the project. By combining automated detection via specialized skills with mandatory validation through make verbs, the project maintains a zero-debt baseline and high architectural integrity. Developers are required to ship scripts, skills, and documentation together, preventing the introduction of manual-only procedures and ensuring long-term maintainability.
Sources: guides/skill-automation-pattern.md:76-78, index.md:32-36