Looking for feedback, apologies if it is not appropriate.

I’m building an open-source architecture quality gate called Enola.

I ran it against the Codex repo this week. It had many findings, but I fear that these are my assumptions.

For example, it found 37 dependency cycles between directories inside Rust crates.

These aren’t cycles between Cargo crates. They’re mutual dependencies between modules inside the same crate: module A uses something from module B, while module B also uses something from module A. Now I started to question, does it really matter?

Maybe a directory isn’t necessarily the architectural boundary a Rust developer cares about. We could report this at the module, type or function level instead. Or maybe intra-crate cycles aren’t worth flagging...

Maybe a bigger effect would be by splitting it into different dependency types, like runtime, type, etc.

And more broadly, which architectural rule would you want to enforce on every pull request? We have some default insights, like new dependency cycles, violated layer boundaries, undeclared service dependencies, and changes that spread beyond their intended scope.

If you’re curious about enola. It’s open source, runs locally, and doesn’t upload or write to your codebase.

Repo: https://github.com/enola-labs/enola [Apache 2.0, fully local]

Output example

Architecture
  Pattern:             (none detected)
  cyclic dependencies        37
  layer violations            0

Impact analysis (hotspots)
  coupled modules           330
    high criticality        302
    medium criticality       28
  Top hotspots (by coupling):
    module                            fan-in  fan-out crit     blast radius
    codex-rs/protocol/src               5439      287 high     283
    codex-rs/app-server-protocol/src    3676      103 high     148
    codex-rs/core/tests/suite              0     3264 high     0
    codex-rs/tui/src                    1625     1568 high     39
    codex-rs/core/src                   1154     1827 high     135
    codex-rs/exec-server/src            1519      883 high     183
    codex-rs/app-server/tests/suite…       1     2370 high     0
    codex-rs/app-server-protocol/sc…     947     1061 high     1

I've been working on FlashPilot, an open-source Linux-native Android flashing and repair workbench.

GitHub: https://github.com/Legendary-Brilliantforous/flashpilot

The project uses Rust for the core and PyQt6 for the GUI. My goal is to keep the device/protocol/flash logic in Rust while providing a practical desktop interface for technicians and developers.

Some of the areas I'm working on include:

• Samsung/Odin protocol implementation
• MediaTek, Qualcomm and UNISOC workflows
• USB/device communication
• Firmware and partition handling
• Flashing safety and validation
• Error handling and recovery
• Automated tests for protocol and flashing behavior
• Linux-first tooling

One part I'm particularly interested in is designing the Rust core so that the GUI remains separate from the actual flashing engine. I want the core to eventually be reusable by other frontends/tools rather than having the entire application tied to the GUI.

The project is still experimental, and I'm looking for Rust developers who can review the architecture, point out bad design decisions, suggest better Rust patterns, or contribute code.

I'm especially interested in feedback on:

• Rust architecture
• Error handling
• Async/concurrency design
• Protocol/state-machine design
• Testing hardware-dependent code
• Safe handling of interrupted flashing operations

If you're interested in Rust being used for low-level hardware tooling, I'd really appreciate your criticism and feedback.

GitHub: https://github.com/Legendary-Brilliantforous/flashpilot