Gates
Gates are automated quality checks that must pass before a WU can be completed. They replace manual code review with consistent, automated enforcement.
Why Gates?
Section titled “Why Gates?”Traditional review:
- Human bottleneck (waiting for reviewers)
- Inconsistent (different reviewers, different standards)
- Slow feedback (review happens after code is written)
Gates:
- Instant (run automatically)
- Consistent (same checks every time)
- Fast feedback (run locally before pushing)
Config-Driven Gates
Section titled “Config-Driven Gates”Define your gate commands in workspace.yaml:
This approach works with any language and toolchain.
Using Presets
Section titled “Using Presets”For common languages, use a preset to get sensible defaults:
Available presets: node, python, go, rust, dotnet, java, ruby, php
Preset Defaults
Section titled “Preset Defaults”| Preset | Format | Lint | Typecheck | Test |
|---|---|---|---|---|
node | prettier --check . | eslint . | tsc --noEmit | npm test |
python | ruff format --check . | ruff check . | mypy . | pytest |
go | gofmt -l . | golangci-lint | go vet ./... | go test |
rust | cargo fmt --check | cargo clippy | cargo check | cargo test |
dotnet | dotnet format --verify | dotnet build | - | dotnet test |
java | spotless:check | checkstyle | mvn compile | mvn test |
ruby | rubocop | rubocop | - | rspec |
php | php-cs-fixer | phpstan | - | phpunit |
Running Gates
Section titled “Running Gates”If any gate fails, wu:prep fails and you fix issues in the worktree before completion.
Gate Flags
Section titled “Gate Flags”| Flag | Description |
|---|---|
--docs-only | Run only docs-related gates (skip format/lint/typecheck/test) |
--full-tests | Run full test suites instead of scoped tests |
--full-lint | Run full lint pass instead of scoped lint |
Command Options
Section titled “Command Options”Commands can be strings or objects with options:
Language Examples
Section titled “Language Examples”Node.js / TypeScript
Section titled “Node.js / TypeScript”Python
Section titled “Python”Java / JVM
Section titled “Java / JVM”How Gates Work Under the Hood
Section titled “How Gates Work Under the Hood”Each gate maps to a policy rule in the Software Delivery Pack:
| Gate | Policy ID | Trigger |
|---|---|---|
| Format check | software-delivery.gate.format | on_completion |
| Lint | software-delivery.gate.lint | on_completion |
| Type check | software-delivery.gate.typecheck | on_completion |
| Test | software-delivery.gate.test | on_completion |
When wu:prep or wu:done runs, the kernel evaluates these policies. A deny from any gate makes the completion decision final — the deny-wins invariant applies. The result is recorded in the evidence store for audit.
Gate Behavior
Section titled “Gate Behavior”On Claim
Section titled “On Claim”When you wu:claim:
- Worktree is created
- Gates status is “pending”
During Work
Section titled “During Work”Run pnpm gates frequently:
On Prep and Done
Section titled “On Prep and Done”When you wu:prep:
- Gates run automatically in the worktree
- If any fail, the WU stays
in_progressuntil you fix and rerunwu:prep
When you wu:done:
- The WU merges to main
- The stamp is created
- The worktree is cleaned up
Gate Failures
Section titled “Gate Failures”Fix and retry:
Skip Flags
Section titled “Skip Flags”Skip specific gates when needed:
Or in configuration:
CI Integration
Section titled “CI Integration”Use the LumenFlow Gates GitHub Action:
The action reads your gates.execution config automatically. See GitHub Action docs for details.
Backwards Compatibility
Section titled “Backwards Compatibility”If no gates.execution config is present, LumenFlow falls back to auto-detecting your project type based on files present and uses preset defaults.
Next Steps
Section titled “Next Steps”- Policy Engine — How gates are evaluated as deny-wins policies
- Evidence Store — How gate results are recorded for audit
- Configuration Reference — Full gates schema
- CLI Reference — All gate commands