41 lines
1.8 KiB
Markdown
41 lines
1.8 KiB
Markdown
# The Analysis Contract: Decoupling Metadata from Implementation
|
|
|
|
## 1. Unified Model
|
|
Instead of each parser having its own internal model, we move to a "Context-Rich Model".
|
|
|
|
```java
|
|
public record CodebaseMetadata(
|
|
List<TriggerPoint> triggers,
|
|
List<EntryPoint> entryPoints,
|
|
Map<String, String> properties,
|
|
CallGraph callGraph
|
|
) {}
|
|
```
|
|
|
|
## 2. Intelligence Provider Lifecycle
|
|
1. **Initialize**: Provide root paths and configuration.
|
|
2. **Scan**: The provider builds its internal index (e.g., JDT AST, Regex indices).
|
|
3. **Extract**: The provider returns a `CodebaseMetadata` object.
|
|
4. **Dispose**: Cleanup resources.
|
|
|
|
## 3. Tool-Specific Strengths
|
|
|
|
### JDT Provider (Advanced)
|
|
- **Strengths**: True semantic understanding, inheritance resolution, precise constant lookups.
|
|
- **Usage**: Deep analysis where we need to know that `BaseService.notify()` is actually what is being called in `ChildService`.
|
|
|
|
### Regex / Tree-Sitter Provider (Light)
|
|
- **Strengths**: Extremely fast, works even on broken code (doesn't need full classpath), very low memory overhead.
|
|
- **Usage**: Large monorepos where full JDT analysis would take minutes.
|
|
|
|
## 4. Aggregation Logic
|
|
The `IntelligenceService` can actually combine results from multiple providers!
|
|
- Use JDT for the State Machine Config (where we need high precision).
|
|
- Use Regex for a quick scan of 1000+ controllers to find mapping patterns.
|
|
|
|
## 5. Refactoring Strategy
|
|
1. **Extract**: Move current JDT-based transition parsing into a `JdtStateMachineProvider`.
|
|
2. **Define**: Create the `CodebaseMetadata` model.
|
|
3. **Bridge**: Update the `ExportService` to accept both a `StateMachineModel` and a `CodebaseMetadata` object.
|
|
4. **Implement**: Create the `CodebaseIntelligenceProvider` interface and its first implementation (wrapping the existing JDT logic).
|