Architecture Boundary Linting in AILK

How AILK enforces import boundaries between apps and packages using a declarative YAML rule set and a CI-enforced lint step.

Showing Rendered view

Architecture Boundary Linting in AILK

AILK enforces import boundaries at the CI level. The rule set lives in architecture.yaml; the enforcer runs as part of pnpm preflight.

The boundary model

The monorepo has three apps (web, api, mcp) and a shared packages/ layer. The rules are simple:

  • Apps import from packages/* — allowed.
  • Apps import from other apps — blocked.
  • Packages import from packages/* — allowed (subject to tier ordering).
  • Packages import from apps/* — blocked.

architecture.yaml

Each rule entry declares a from glob, a to glob, and whether the import is allowed or blocked. The linter reads the file at runtime and checks every import statement in the codebase against the rule set.

Why YAML, not ESLint

The boundary rules are structural, not stylistic. A YAML source of truth makes them readable by humans, parseable by scripts, and viewable in PRs as a diff — no plugin config required.

CI enforcement

pnpm architecture runs the linter. It exits non-zero on any violation, which fails the preflight step and blocks the PR from merging. The linter output names the file, the import, and the rule it violates.

Was this helpful?
Edit this page on GitHub