Quality Gates

Quality gates are checkpoints in the pipeline where work must meet specific criteria before advancing. Gates can be automated (CI, linting, type checking) or require specific agent or human approval. A PR that fails a gate stays at that stage until the issue is resolved or the circuit breaker trips.

Gate Types

Gate	Type	When	What It Checks
CI Gate	Automated	Every push	Build, lint, typecheck, unit tests
Code Review	Agent (automated)	After build	Code quality, patterns, potential issues
Architecture Review	Agent (specific)	On request or for complex PRs	Design decisions, scalability, patterns
Security Gate	Agent (specific)	PRs touching auth/security surfaces	Auth patterns, token handling, permissions
QA Gate	Agent (functional)	After code review	Functional testing, regression, edge cases
E2E Gate	Agent (browser)	After QA	Browser-based end-to-end testing
Human Gate	Human	Before merge	Final approval and merge decision

Automated Code Review

Code review runs as a GitHub Action, triggered by a label. This keeps review infrastructure outside the agent fleet — no tmux session, no compute cost, just CI.

Flow

PM agent adds the review-trigger label to the PR
GitHub Action runs automatically
Action analyzes the diff and posts findings as inline PR comments
Action adds review-complete label
Pipeline advances to the fix stage if there are actionable comments

Comment classification

When fix agents process review comments, they categorize each one:

Category	Action
`must-fix`	Implement the fix
`should-fix`	Implement unless impractical
`nitpick`	Fix if trivial, skip if not
`overengineering`	Skip — the reviewer is suggesting unnecessary complexity

Security Gate

PRs that touch security-sensitive surfaces require architecture review before merge. This gate is mandatory and cannot be bypassed by agents.

Trigger conditions

The security gate applies when the PR is labeled security or touches any of:

Authentication paths (src/lib/auth*)
Middleware
Token handling or machine auth
IAM or service account permissions

Requirements before merge

Architecture agent review comment posted in-thread
CI green
If emergency: explicit human override, then post-merge architecture review within 1 hour

Auto-Merge Conditions

For low-risk repositories, PRs can be auto-merged when all conditions are met:

Architecture agent approved
QA agent approved or tests passing
CI green
No unresolved review comments
Repository is configured for auto-merge (opt-in per repo)

High-value repositories always require human approval. Auto-merge is a convenience for infrastructure repos, documentation, and internal tooling — not production application code.

Circuit Breaker

The circuit breaker prevents infinite fix cycles. After N failed attempts (default: 3), the pipeline halts and requires human intervention.

Attempt 1: Fix agent addresses comments → new review → still failing
Attempt 2: Fix agent tries again → review → still failing
Attempt 3: Fix agent tries once more → review → still failing
           ↓
         agent-stuck label applied
         Pipeline halts
         Human triages

Why 3 attempts?

Empirically, if an agent can't fix review comments in 3 attempts, the issue is either:

A fundamental design problem (agent needs architectural guidance)
A misunderstanding of the review comment (agent is fixing the wrong thing)
A limitation of the agent's capabilities (task needs human implementation)

In all three cases, more automated attempts waste compute without progress.

Delivery Flow

The delivery flow ensures that changes reach users through a verified path:

Builder agent → QA agent → Human inbox
                  ↓
        Steven never hears about failures.
        All agents enforce this.

Failed QA loops back to the builder. Only clean, tested work reaches the human merge queue. This means the human reviewer sees only PRs that have already passed automated code review, addressed review comments, and passed E2E testing.