QualityGateCore: Automating Zero-Warnings Swift Discipline at Scale

A modular CLI engine that enforces production-quality Swift standards across local workflows, CI/CD pipelines, and AI-assisted development — built plugin by plugin, proposal by proposal.

Problem

Swift’s compiler is strict by design, but strictness alone doesn’t enforce discipline across a growing codebase. Teams accumulate warnings, skip doc coverage, let concurrency hazards slip through, and ship with untested edge cases — not because they don’t care, but because there’s no automated gate stopping them at commit time.

Existing tools address fragments of this problem. DocC lints documentation. Swiftlint flags style issues. Build logs surface warnings. But nothing unified these signals into a single, structured, CI/CD-ready verdict. The gap was especially acute for AI-assisted development workflows, where agents need machine-readable output and well-described tool interfaces to reason about code health.

QualityGateCore was built to close that gap: a single Swift CLI that runs every meaningful quality check, emits structured output, and integrates cleanly into both human and automated workflows.

Approach

The project’s MASTER_PLAN.md establishes a clear mission — “Zero Warnings/Errors quality gates for Swift projects, with structured output for CI/CD integration and SPM plugin support” — and the architecture follows that mission with unusual fidelity.

Rather than building a monolith, the developer structured QualityGateCore as a constellation of independently testable auditor plugins. The target list tells the story: SafetyAuditor, ConcurrencyAuditor, UnreachableCodeAuditor, RecursionAuditor, PointerEscapeAuditor, FloatingPointSafetyAuditor, MemoryLifecycleGuard, AccessibilityAuditor, LoggingAuditor, TestQualityAuditor, DependencyAuditor, ReleaseReadinessAuditor, MCPReadinessAuditor, and StochasticDeterminismAuditor — each a discrete target with its own test suite. This is plugin-based architecture as a first principle, not a refactor.

The toolchain reflects the problem domain precisely. swift-syntax powers static analysis of Swift ASTs. indexstore-db enables symbol-level querying across the project graph. Yams drives YAML configuration parsing for .quality-gate.yml project settings. swift-argument-parser handles the CLI surface. The dependency list reads like a deliberate inventory, not accumulation.

Design artifacts are the most revealing signal of working style. With 28 design proposals and a confirmed design-first workflow, the developer was clearly writing proposals before writing code — treating architecture decisions as documents worth preserving and revisiting. This kind of structured thinking before implementation is especially valuable in a tool with this many moving parts.

Claude Code sessions were used sparingly and purposefully: 3 sessions, 32 messages, 8 commits, all three fully achieving their stated goal. Two friction signals — one buggy code incident, one wrong approach — were resolved within sessions rather than abandoned, which reflects a debugging posture rather than a restart posture.

Results

QualityGateCore reached its v1.0.0 release on May 12, 2026, approximately nine weeks after the first commit on March 13. In that window, 64 commits landed across the project’s single working branch, reflecting steady, focused progress rather than burst-and-pause development.

The shipped package includes:

• 22 distinct auditor modules, each with a corresponding test target
• Three output formats: terminal-readable, JSON, and SARIF for GitHub Code Scanning integration
• Both SPM plugin types: CommandPlugin for local use and BuildToolPlugin for pipeline enforcement
• MCP-ready tool descriptions via MCPReadinessAuditor, positioning the tool for AI agent workflows
• Built-in doc tooling absorbing docc-lint and swift-doc-gaps capabilities rather than depending on them externally

The QualityGateTestKit target deserves specific mention — it signals that the developer built a reusable testing harness for the auditors themselves, treating testability of the framework as a first-class concern rather than an afterthought.

Judgment Calls

Several decisions reveal craft worth noting.

Absorbing rather than depending. The MASTER_PLAN.md explicitly calls out absorbing docc-lint and swift-doc-gaps capabilities as built-in functionality. This is a deliberate inversion of the usual impulse to reach for existing packages. By internalizing those capabilities, the tool gains a unified configuration surface, consistent output format, and no fragile external version pinning.

StochasticDeterminismAuditor is the most interesting target name in the list. Including an auditor specifically for stochastic determinism — likely targeting randomness, shuffled outputs, or non-reproducible test behavior — suggests the developer was thinking about a category of bugs that most quality tools ignore entirely. That’s domain-specific judgment, not framework-following.

MCPReadinessAuditor as a first-class concern. Most tool authors would treat AI-agent compatibility as documentation work. Including it as an auditor module means the tool can evaluate itself and other projects for MCP readiness — a recursive, forward-looking design choice that reflects awareness of where developer tooling is heading.

28 proposals before v1.0.0. In a nine-week project, writing 28 design documents is not overhead — it’s the mechanism by which a 22-module system stays coherent. Each proposal likely corresponds to a module boundary, an API decision, or a behavior contract. The discipline to write before building is what makes the plugin architecture feel designed rather than grown.