| name | lev-align |
| description | Project alignment validator. Loads .lev/validation-gates.yaml and checks current work against all applicable gates. Reports pass/fail/aspirational per gate. Integrates with /work ALIGN phase.
|
| version | 1.0.0 |
| related_skills | ["work","autodev-loop","lev-sdlc"] |
| skill_type | validation |
| category | process-lifecycle |
| triggers | ["align","check gates","validation gates","alignment check"] |
lev-align — Project Alignment Validator
Loads .lev/validation-gates.yaml from project root, checks current work
against all applicable gates, and reports structured pass/fail/warn per gate.
On Load
- Find
.lev/validation-gates.yaml via project root discovery (walk up from cwd)
- Parse gates into sections:
checks, architecture_compliance, sdk_first_compliance, spec_invariants
- Classify which gates apply to current work context based on:
- Module being touched (path → spec → invariants)
- Work type (feature, bugfix, refactor, sdk_pass_through_refactor)
- Tier classification (T1-T4 based on path patterns)
Alignment Check Protocol
For each applicable gate, classify and report:
| Status | Behavior | Action on Fail |
|---|
enforced | MUST pass | Block execution |
declared | SHOULD pass | Warn, log to handoff |
aspirational | COULD pass | Note only |
Gate Resolution Order
- Spec invariants — Check
spec_invariants.* for modules being touched
- Architecture compliance — Check
architecture_compliance.*
- SDK-first compliance — Check
sdk_first_compliance.*
- Mandatory checks — Check
checks.*
- Quality gates — Check
quality_gates.* based on task type template
Invariant Checking
For spec_invariants gates (poly_binder_only, daemon_ownership, index_architecture, etc.):
- Read the gate's
invariants list
- For each invariant, verify against current code state:
- Grep for violations (e.g., "daemon implementation logic" in core/poly/src/)
- Check file existence (e.g., "core/cli/ does not exist")
- Verify import chains
- Run any
gates commands if they have associated test commands
Output Format
## Alignment Report
**Project:** {project_name}
**Module:** {module_path}
**Work Type:** {work_type}
**Date:** {date}
### Enforced Gates
| Gate | Status | Evidence |
|------|--------|----------|
| poly_binder_only | PASS | 0 daemon logic lines in core/poly/src/ |
| daemon_ownership | PASS | 0 impl files under poly |
### Declared Gates
| Gate | Status | Evidence |
|------|--------|----------|
| poly_compliance | WARN | orchestrator/ still exists (cleanup pending) |
### Aspirational Gates
| Gate | Status | Note |
|------|--------|------|
| yaml_file_routing | NOTE | 3 hardcoded routes remain |
### Verdict
{PASS | WARN | BLOCK}
- Enforced: {n}/{total} pass
- Declared: {n}/{total} pass
- Blocking issues: {list or "none"}
Integration with /work
The /work ALIGN phase calls lev-align automatically when .lev/validation-gates.yaml exists:
- Load and parse the gates file
- Filter gates applicable to current workstream/module
- Check current state against enforced gates
- Include gate status in alignment verdict
- Block PROPOSE if any enforced gate fails
Invocation
/lev-align # Full alignment check for current module
/lev-align --module core/poly # Check specific module
/lev-align --gate poly_binder_only # Check specific gate
/lev-align --type refactor # Check gates for task type
/lev-align --report # Save report to .lev/pm/reports/
Anti-Patterns
- Skipping enforced gates — enforced means enforced, no exceptions without explicit user override
- Checking aspirational gates as blocking — aspirational is informational only
- Running without reading specs — gate checking requires reading the actual spec invariants
- Hardcoding gate lists — always read from validation-gates.yaml, never maintain a separate list
Composite Drift Score (from OOO)
When reporting alignment, compute a single composite drift number:
drift = 0.5 × goal_drift + 0.3 × constraint_drift + 0.2 × ontology_drift
| Component | Weight | What It Measures |
|---|
| Goal drift | 50% | How far current state is from stated objective |
| Constraint drift | 30% | How many gates are failing vs passing |
| Ontology drift | 20% | How much naming/structure has diverged from DNA canon |
One number to watch. If drift > 0.3, flag as WARNING. If drift > 0.5, flag as CRITICAL.
Source: .lev/pm/parity/ouroboros.yaml (ooo-10), tribunal item 13 (UNANIMOUS AGREE)
