Architecture review welcome — tear the design apart

[beyondnetPeru]

Evolith is an architecture linter for CI: it evaluates a repository against a Rego/OPA rule corpus (layering, dependencies, security posture, CI/CD, ADRs) and fails the PR — and it reports a rule it could not evaluate as a failure, never as a silent pass. Exit codes: 0 pass · 1 the tool failed · 2 the gate blocked · 3 invalid invocation.

This thread is for tearing it apart. The design is documented in the open (ADRs, a gap board that lists what is not built, a dated "known limitations" page), so the most useful thing you can do is disagree with a decision, with a pointer to the ADR or the rule.

Things we would genuinely like an outside opinion on:

1. The default. A blocking rule that ends skipped fails the run. Right default, or too strict to live with day to day?
2. Rules as data outside the repo. The library (~413 rules / ~178 packs) governs many repositories from one place; --select narrows it. Would you want it this way, or per-repo config à la ArchUnit / dependency-cruiser?
3. Two engines, one corpus. --engine opa evaluates 133 of 159 rules on our own repo; the native evaluator far fewer. Is holding them to agreement over facts (not coverage) the right contract? See docs/known-limitations.md.
4. Node/TypeScript first. The dependency and linter rules assume it; structural, CI/CD and ADR rules are language-agnostic. Which ecosystem next?
5. MCP surface. The same deterministic engine exposed to a coding agent over stdio (no LLM inside). Useful, or the wrong shape for agents?

Try it in ten seconds on any repo (Node ≥ 18, nothing leaves your machine):

npx -y @beyondnet/evolith-cli init --name my-project --yes
npx -y @beyondnet/evolith-cli validate --engine opa
echo $?

Where things are: README · Known limitations · ADRs · Gap board · good first issue

Spanish is welcome too — the whole documentation is bilingual (EN/ES).