architecture-review

Check the change against five questions: does it respect dependency direction, does it add a justified dependency to the core crate, does it mix concerns across layers, can it be tested offline, and is the trust impact explicit. Any reversed dependency arrow is a violation.

Enforce a one-way dependency rule such as aixlarity-cli depending on aixlarity-core but never the reverse. During review, reject any change that makes the core crate import from the CLI crate or reverses internal module arrows.

Run it before any PR that adds a new module, significantly changes module boundaries, moves code between crates during refactoring, or adds a tool that might need special permissions. Routine small changes within one module usually do not need it.

A checklist catches declared violations like reversed imports or mixed layers, but it cannot detect subtle coupling introduced through shared state or implicit contracts. It also depends on reviewers honestly answering whether new dependencies are justified.

Offline testability keeps the core crate independent of external providers, so unit tests run deterministically in CI without secrets. A change that requires live API keys for core logic signals a layering problem where provider concerns leak into core.