f0bd7959b1
Authored by: Structural Analysis Agent (Euler) Updated all dependency analysis artifacts with fresh extraction: - graph.json: Canonical dependency graph with 10 crates, 139 files, 16 crate edges, 72 file edges - graph.summary.md: Overview with fan-in/fan-out rankings and crate inventory - sccs.md: SCC analysis confirming no cycles at crate or file level (clean DAG) - layers.observed.md: 5-layer architecture diagram derived from dependencies - hotspots.md: Coupling hotspots (g3-config highest fan-in, g3-cli highest fan-out) - limitations.md: Documented extraction limitations (conditional compilation, macros, etc.) Key findings: - All 10 workspace crates form a directed acyclic graph - g3-core/src/ui_writer.rs has highest file-level fan-in (10 dependents) - g3-console is standalone with no workspace dependencies - Clean layered architecture with no violations detected
122 lines
3.7 KiB
Markdown
122 lines
3.7 KiB
Markdown
# Analysis Limitations
|
|
|
|
## Extraction Method
|
|
|
|
This analysis used static parsing of:
|
|
1. `Cargo.toml` files for crate-level dependencies
|
|
2. `use` statements in `.rs` files for file-level imports
|
|
3. `mod` declarations for module structure
|
|
|
|
## What Could Not Be Observed
|
|
|
|
### 1. Conditional Compilation
|
|
|
|
Dependencies gated by `#[cfg(...)]` attributes may be:
|
|
- Platform-specific (e.g., `#[cfg(target_os = "macos")]`)
|
|
- Feature-gated (e.g., `#[cfg(feature = "..." )]`)
|
|
- Test-only (e.g., `#[cfg(test)]`)
|
|
|
|
**Impact**: Some edges may only exist on specific platforms or with specific features enabled.
|
|
|
|
**Affected crates**:
|
|
- `g3-computer-control`: Has platform-specific modules (macos.rs, linux.rs, windows.rs)
|
|
- `g3-providers`: May have feature-gated provider implementations
|
|
|
|
### 2. Macro-Generated Code
|
|
|
|
Imports generated by procedural macros are not captured:
|
|
- `#[derive(...)]` macros
|
|
- `async_trait` macro expansions
|
|
- Custom derive macros
|
|
|
|
**Impact**: Some implicit dependencies on trait implementations may be missed.
|
|
|
|
### 3. Re-exports
|
|
|
|
Transitive re-exports via `pub use` are partially traced:
|
|
- Direct re-exports in `lib.rs` are captured
|
|
- Nested re-exports may not be fully resolved
|
|
|
|
**Example**: `g3-providers/src/lib.rs` likely re-exports types from submodules.
|
|
|
|
### 4. Dynamic Dispatch
|
|
|
|
Trait object usage (`dyn Trait`) creates runtime dependencies not visible in imports:
|
|
- `Box<dyn LLMProvider>`
|
|
- `Arc<dyn UiWriter>`
|
|
|
|
**Impact**: Actual runtime coupling may be higher than static analysis shows.
|
|
|
|
### 5. Build Script Dependencies
|
|
|
|
`build.rs` files were identified but not analyzed for:
|
|
- Generated code dependencies
|
|
- Native library linkage
|
|
- Environment-based configuration
|
|
|
|
**Affected**: `g3-computer-control/build.rs`
|
|
|
|
### 6. External Crate Dependencies
|
|
|
|
Only workspace-internal dependencies were analyzed. External crates from crates.io are listed in Cargo.toml but not traced at file level:
|
|
- `tokio`, `reqwest`, `serde`, etc.
|
|
- `tree-sitter-*` language grammars
|
|
- Platform-specific crates (`core-graphics`, `x11`, `windows`)
|
|
|
|
### 7. Test File Dependencies
|
|
|
|
Test files in `tests/` directories were included but:
|
|
- May have different dependency patterns than production code
|
|
- Use `dev-dependencies` not distinguished from regular dependencies
|
|
- Integration tests may have broader access than unit tests
|
|
|
|
### 8. Example File Dependencies
|
|
|
|
Files in `examples/` directories:
|
|
- Included in file counts
|
|
- May demonstrate usage patterns not representative of core dependencies
|
|
- Often have simplified or demonstration-only imports
|
|
|
|
## What Was Inferred
|
|
|
|
### 1. Module-to-File Mapping
|
|
|
|
`mod foo;` declarations were mapped to `foo.rs` or `foo/mod.rs` by convention.
|
|
|
|
**Confidence**: High (Rust standard convention)
|
|
|
|
### 2. Crate Root Identification
|
|
|
|
`lib.rs` was assumed to be the crate root for libraries.
|
|
`main.rs` was assumed to be the binary entry point.
|
|
|
|
**Confidence**: High (Cargo convention)
|
|
|
|
### 3. Import Target Resolution
|
|
|
|
`use crate::foo::Bar` was resolved to the file containing module `foo`.
|
|
|
|
**Confidence**: Medium (may miss re-exports)
|
|
|
|
### 4. Cross-Crate Import Resolution
|
|
|
|
`use g3_core::Agent` was mapped to `g3-core/src/lib.rs`.
|
|
|
|
**Confidence**: Medium (actual definition may be in submodule)
|
|
|
|
## What May Invalidate Conclusions
|
|
|
|
1. **Significant refactoring** since analysis date
|
|
2. **Feature flags** enabling/disabling major functionality
|
|
3. **Platform-specific builds** with different dependency graphs
|
|
4. **Workspace configuration changes** in Cargo.toml
|
|
5. **New crates added** to workspace
|
|
|
|
## Recommendations for Improved Analysis
|
|
|
|
1. Use `cargo metadata` for authoritative crate dependency graph
|
|
2. Use `cargo tree` for transitive dependency analysis
|
|
3. Use `rust-analyzer` for precise import resolution
|
|
4. Run analysis on each target platform separately
|
|
5. Analyze with all feature combinations
|