Finding
zeph-config uses pub use <submodule>::*; glob re-exports in two module aggregator files, obscuring which submodule a given type comes from and creating an inconsistent API surface (some submodules are re-exported explicitly by name, others via glob, within the same mod.rs).
Location
crates/zeph-config/src/memory/mod.rs:34-43 (10 wildcard re-exports):
pub use consolidation::*;
pub use fidelity::*;
pub use graph::*;
pub use hebbian::*;
pub use persona::*;
pub use reasoning::*;
pub use retrieval::*;
pub use root::*;
pub use session::*;
pub use store::*;
crates/zeph-config/src/migrate/mod.rs:35,39-41,44-45 (6 wildcard re-exports, mixed with explicit named re-exports in the same block at lines 25-33, 36, 42-43):
pub use infra::*;
pub use llm::*;
pub use mcp::*;
pub use memory::*;
pub use session::*;
pub use tools::*;
Why
Per the project's modularity guidelines: wildcard re-exports hide where items come from, make API boundaries opaque to readers and IDE "go to definition" navigation, and risk unexpected additions to the public surface whenever a submodule gains a new pub item — since there's no explicit allow-list to update. zeph-config is already a large crate (131 config structs across 30 files per its own lib.rs module doc), which makes explicit provenance more valuable here, not less: a reader trying to locate TrajectoryConfig or migrate_egress_config has to grep all ten (or six) submodules rather than reading one re-export list.
No functional bug was found — a scan across the memory/ submodules turned up no colliding public names today — but the risk grows with crate size, and the mix of explicit vs. glob re-exports in migrate/mod.rs is itself an inconsistency (compare lines 25-33 with line 35).
Suggested fix
Replace each pub use X::*; with an explicit named re-export list (pub use x::{TypeA, TypeB, ...};), matching the style already used for features, integrity, plugins, and serve in the same migrate/mod.rs file.
Scope
Read-only architecture finding from CI cycle 1424 (arch pass over zeph-gateway/zeph-tui/zeph-common/zeph-config — the crates without a dedicated architecture pass in this loop). No code changes made; P3 since it is a maintainability/readability concern rather than a functional or type-safety defect.
Finding
zeph-configusespub use <submodule>::*;glob re-exports in two module aggregator files, obscuring which submodule a given type comes from and creating an inconsistent API surface (some submodules are re-exported explicitly by name, others via glob, within the samemod.rs).Location
crates/zeph-config/src/memory/mod.rs:34-43(10 wildcard re-exports):crates/zeph-config/src/migrate/mod.rs:35,39-41,44-45(6 wildcard re-exports, mixed with explicit named re-exports in the same block at lines 25-33, 36, 42-43):Why
Per the project's modularity guidelines: wildcard re-exports hide where items come from, make API boundaries opaque to readers and IDE "go to definition" navigation, and risk unexpected additions to the public surface whenever a submodule gains a new
pubitem — since there's no explicit allow-list to update.zeph-configis already a large crate (131 config structs across 30 files per its ownlib.rsmodule doc), which makes explicit provenance more valuable here, not less: a reader trying to locateTrajectoryConfigormigrate_egress_confighas to grep all ten (or six) submodules rather than reading one re-export list.No functional bug was found — a scan across the
memory/submodules turned up no colliding public names today — but the risk grows with crate size, and the mix of explicit vs. glob re-exports inmigrate/mod.rsis itself an inconsistency (compare lines 25-33 with line 35).Suggested fix
Replace each
pub use X::*;with an explicit named re-export list (pub use x::{TypeA, TypeB, ...};), matching the style already used forfeatures,integrity,plugins, andservein the samemigrate/mod.rsfile.Scope
Read-only architecture finding from CI cycle 1424 (arch pass over zeph-gateway/zeph-tui/zeph-common/zeph-config — the crates without a dedicated architecture pass in this loop). No code changes made; P3 since it is a maintainability/readability concern rather than a functional or type-safety defect.