Update dependency analysis artifacts

Refreshed static dependency analysis for the G3 codebase:

- graph.json: 143 nodes (9 crates, 134 files), 189 edges
- No cycles detected (DAG structure confirmed)
- Top fan-in: g3-core (43), g3-providers (27), g3-config (16)
- Top fan-out: g3-core/src/lib.rs (27), g3-cli/src/lib.rs (12)
- 4-layer architecture: Foundation → Core → Services → Application

Extraction method: Cargo.toml parsing + regex-based import analysis
Limitations documented: internal crate imports, re-exports, conditional compilation

Agent: euler

analysis/deps/limitations.md

@@ -1,121 +1,103 @@
 # Analysis Limitations
 
-## Extraction Method
+## What Was Observed
 
-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
+| Source | Method | Confidence |
+|--------|--------|------------|
+| Crate dependencies | Parsed from Cargo.toml `[dependencies]` sections | High |
+| External crate imports | Regex match on `use g3_*::` statements | High |
+| Module declarations | Regex match on `mod` and `pub mod` statements | High |
+| File classification | Path pattern matching (tests/, examples/, lib.rs, etc.) | High |
 
-## What Could Not Be Observed
+## What Was Not Observed
 
-### 1. Conditional Compilation
+### 1. Internal Module Imports
 
-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)]`)
+`use crate::` statements were detected but not resolved to specific target files.
 
-**Impact**: Some edges may only exist on specific platforms or with specific features enabled.
+**Impact**: File-to-file edges within a crate are incomplete. Only `mod` declaration edges are captured.
 
-**Affected crates**:
-- `g3-computer-control`: Has platform-specific modules (macos.rs, linux.rs, windows.rs)
-- `g3-providers`: May have feature-gated provider implementations
+**Example not captured**:
+```rust
+// In ./crates/g3-core/src/streaming.rs
+use crate::context_window::ContextWindow;  // Edge to context_window.rs not in graph
+```
 
-### 2. Macro-Generated Code
+### 2. Re-exports
 
-Imports generated by procedural macros are not captured:
-- `#[derive(...)]` macros
-- `async_trait` macro expansions
-- Custom derive macros
+`pub use` statements that re-export items from submodules are not tracked as separate edges.
 
-**Impact**: Some implicit dependencies on trait implementations may be missed.
+**Impact**: Transitive dependencies through re-exports are not visible.
 
-### 3. Re-exports
+**Example**:
+```rust
+// In ./crates/g3-core/src/lib.rs
+pub use context_window::{ContextWindow, ThinScope};  // Re-export not tracked
+```
 
-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
+### 3. Conditional Compilation
 
-**Example**: `g3-providers/src/lib.rs` likely re-exports types from submodules.
+`#[cfg(...)]` attributes on imports are not parsed. All imports are treated as unconditional.
 
-### 4. Dynamic Dispatch
+**Impact**: Platform-specific dependencies (e.g., macOS-only code in g3-computer-control) appear as universal.
 
-Trait object usage (`dyn Trait`) creates runtime dependencies not visible in imports:
-- `Box<dyn LLMProvider>`
-- `Arc<dyn UiWriter>`
+### 4. Macro-Generated Imports
 
-**Impact**: Actual runtime coupling may be higher than static analysis shows.
+Imports generated by macros (e.g., `derive` macros, `include!`) are not detected.
 
-### 5. Build Script Dependencies
+**Impact**: Some edges may be missing if macros generate `use` statements.
 
-`build.rs` files were identified but not analyzed for:
-- Generated code dependencies
-- Native library linkage
-- Environment-based configuration
+### 5. Dev-Dependencies
 
-**Affected**: `g3-computer-control/build.rs`
+Only `[dependencies]` sections were parsed. `[dev-dependencies]` were not included in crate-level edges.
 
-### 6. External Crate Dependencies
+**Impact**: Test-only dependencies (e.g., `tempfile`, `serial_test`) are not in the graph.
 
-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`)
+### 6. Build Dependencies
 
-### 7. Test File Dependencies
+`[build-dependencies]` were not parsed.
 
-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
+**Impact**: Build script dependencies are not represented.
 
-### 8. Example File Dependencies
+### 7. Feature-Gated 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
+Cargo features that enable optional dependencies are not tracked.
+
+**Impact**: Optional dependencies appear the same as required ones.
+
+### 8. Workspace Dependencies
+
+`[workspace.dependencies]` are resolved but the inheritance relationship is not tracked.
+
+**Impact**: Cannot distinguish workspace-inherited vs crate-specific dependency versions.
 
 ## What Was Inferred
 
-### 1. Module-to-File Mapping
+| Inference | Basis | Confidence |
+|-----------|-------|------------|
+| File type classification | Filename and path patterns | Medium-High |
+| Module file resolution | Rust module naming conventions (mod.rs, name.rs) | High |
+| Crate membership | File path prefix matching | High |
 
-`mod foo;` declarations were mapped to `foo.rs` or `foo/mod.rs` by convention.
+## Potential Invalidation Conditions
 
-**Confidence**: High (Rust standard convention)
+1. **Non-standard module structure**: If any crate uses `#[path = "..."]` attributes to override module paths, those edges will be incorrect.
 
-### 2. Crate Root Identification
+2. **Generated code**: If any `.rs` files are generated at build time (not checked into git), they are not included.
 
-`lib.rs` was assumed to be the crate root for libraries.
-`main.rs` was assumed to be the binary entry point.
+3. **Symlinks**: Symbolic links in the source tree are not followed or detected.
 
-**Confidence**: High (Cargo convention)
+4. **External workspace members**: Only crates in `./crates/` and root `./src/` were analyzed. External workspace members would be missed.
 
-### 3. Import Target Resolution
+## Verification Commands
 
-`use crate::foo::Bar` was resolved to the file containing module `foo`.
+To verify crate-level dependencies match Cargo's resolution:
+```bash
+cargo tree --prefix none --no-dedupe | grep '^g3-'
+```
 
-**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
+To find imports not captured by this analysis:
+```bash
+rg 'use crate::' --type rust | wc -l  # Internal imports (not fully resolved)
+rg 'pub use' --type rust | wc -l     # Re-exports (not tracked)
+```