# Integration Notes: Opus Review Feedback

## Integrating

### 1. Lambda targets in signal connections (Critical)
**Why**: Real issue. Lambda Callables would silently fail. Will add filter in `_build_signal_listeners` to skip targets starting with `func` and document as known limitation.

### 2. Qualified target names in connections (Critical)
**Why**: Real edge case. Will skip targets containing `.` in `_build_signal_listeners`. Consistent with existing code tools.

### 3. Tool registration pattern (Critical)
**Why**: Correct — must follow the existing `@mcp.tool()` in module pattern, not register in server.py. Will fix.

### 4. Property vs method call in autoload refs (Critical)
**Why**: Important to avoid false flow branches. Will check raw source line for `(` after the access pattern.

### 5. Non-"direct" autoload ref patterns (Critical)
**Why**: `has_node`/`get_node` refs have empty or path-based access fields. Will filter to `ref.pattern == "direct"` only.

### 6. Remove end_line 99999 fallback
**Why**: Parser already sets end_line properly. Sentinel value would cause misattribution. Will use `func.end_line < func.line` check instead.

### 7. Cache raw source files
**Why**: Simple optimization that prevents re-reading same file multiple times during deep traces. Will build a `file_path -> lines` cache.

### 8. Shared visited set across entry points
**Why**: Prevents duplicate downstream paths in output. Better default behavior.

### 9. Conftest location
**Why**: Consistent with existing test patterns. Will add fixture to `tests/test_tools/conftest.py`.

### 10. Integration test for server registration
**Why**: Good safety net. Will add a test verifying `godotiq_trace_flow` is registered.

### 11. Filter autoload ref by checking for `(` on source line
**Why**: Reliable way to distinguish method calls from property accesses.

## NOT Integrating

### Signal name collisions (Issue #11)
**Why not**: This is a known pre-existing architectural choice shared with `_find_signal_listeners`. The event bus pattern (which dominates Godot projects) uses unique signal names. Fixing this properly requires qualifying by signal source, which is a v2 concern. Will document as known limitation.

### Signal emission outside functions (Issue #8)
**Why not**: Top-level signal emissions in GDScript are extremely rare (signals are emitted in response to events, which happen in functions). The graceful skip via `_find_containing_function` returning None is already sufficient — it just won't trace that emission. Not worth a dedicated test case.

### `detail` parameter validation (Issue #14)
**Why not**: Consistent with existing tools that don't validate enum-like params. Unknown values defaulting to "normal" is harmless behavior.

### Drop `project_path` from spec (Issue #10)
**Why not**: Already handled — the plan's tool signature doesn't include it, and the spec is a separate document that won't affect implementation.
