ironclaw-reborn-architecture-review

Demand a second production implementation or a verifiable dependency boundary before accepting any new trait. A trait with one real impl is ceremony; extracting it later from a concrete type is mechanical, so reject swap-later rationalizations.

Use a dedicated architecture test crate such as ironclaw_architecture_tests with explicit boundary rules per crate. Blocklist-based rules leave new crates unruled by default, so add the new crate's boundary rule in the same PR that introduces it.

A cross-crate re-export is justified only when a boundary test closes the direct import path and the re-export names its consumer and enforcing test. Glob re-exports at a crate root are treated as laundering and rejected.

Only service-graph wiring such as build_* and with_* functions belongs in the composition crate. Behavior like delivery logic, auth flows, or domain services belongs in an owning crate, following the ironclaw_webui host-side product crate model.

Boundary tests police dependency edges, not interior mass or abstraction quality. The two real decay modes are mass pooling inside a crate and speculative abstraction, which require manual checklist review beyond the automated tests.