Merge pull request #153 from syncable-dev/develop

Develop

Author: Alex793x

.gitignore

@@ -5,6 +5,7 @@ target/
 
 # These are backup files generated by rustfmt
 **/*.rs.bk
+.qoder
 
 # MSVC Windows builds of rustc generate these, which store debugging information
 *.pdb

.qoder/quests/analyze-folder.md

@@ -0,0 +1,116 @@
+# Analyze Folder Command Telemetry Design
+
+## Overview
+
+This document outlines the design for improving the telemetry events for the `analyze` command in the syncable-cli application. Currently, the command generates two separate telemetry events when executed, which is incorrect. The goal is to generate only one event per command execution while still capturing the different modes of operation (detailed view, JSON output, etc.).
+
+## Current Issues
+
+1. **Duplicate Events**: When running `sync-ctl analyze .`, two events are generated:
+   - A generic "analyze" event
+   - A specific "Analyze Folder" event
+
+2. **Lack of Differentiation**: The current implementation doesn't capture how the analysis was performed (JSON output, detailed view, matrix view, etc.)
+
+## Proposed Solution
+
+Replace the two separate events with a single "Analyze Folder" event that includes properties to differentiate the analysis mode.
+
+## Architecture
+
+### Event Structure
+
+The new telemetry event will have the following structure:
+
+Event Name: "Analyze Folder"
+Properties:
+- analysis_mode: string (one of: "json", "detailed", "matrix", "summary")
+- color_scheme: string (one of: "auto", "dark", "light")
+- only_filter: string[] (list of filtered analysis aspects)
+
+### Implementation Plan
+
+1. **Remove duplicate event calls**: Eliminate the separate `track_analyze()` call
+2. **Enhance the `track_analyze_folder()` method**: Add parameters to capture analysis mode
+3. **Modify the main function**: Pass analysis parameters to the telemetry event
+4. **Update the telemetry client**: Modify the `track_analyze_folder()` method to accept and process these parameters
+
+## Detailed Design
+
+### 1. Telemetry Client Modifications
+
+The `TelemetryClient` struct will be updated to accept properties in the `track_analyze_folder` method:
+
+Method signature:
+- Current: `track_analyze_folder(&self)`
+- New: `track_analyze_folder(&self, properties: HashMap<String, serde_json::Value>)`
+
+Implementation:
+- The method will pass the properties to the track_event function
+- Properties will be merged with common properties before sending
+
+### 2. Main Function Updates
+
+In the main function, the analyze command handling will be modified:
+
+Process for determining analysis mode:
+- If json flag is true → "json"
+- Else if detailed flag is true → "detailed"
+- Else based on display option:
+  - Matrix or None → "matrix"
+  - Detailed → "detailed"
+  - Summary → "summary"
+
+Properties to capture:
+- Analysis mode (determined by command flags)
+- Color scheme (if specified)
+- Only filter (if specified)
+
+### 3. Remove Duplicate Event
+
+The separate `telemetry_client.track_analyze()` call will be removed from the analyze command handling.
+
+## Data Flow
+
+``mermaid
+graph TD
+    A[User runs analyze command] --> B[CLI Parser]
+    B --> C[Main Function]
+    C --> D[Create telemetry properties]
+    D --> E[Track single Analyze Folder event]
+    E --> F[Send to PostHog]
+```
+
+## Benefits
+
+1. **Single Event Per Command**: Only one telemetry event will be generated per analyze command execution
+2. **Mode Differentiation**: The analysis mode (JSON, detailed, matrix, summary) will be captured in event properties
+3. **Enhanced Analytics**: Better data for understanding how users interact with the analyze command
+4. **Consistency**: Aligns with the pattern used for other commands like security scans
+
+## Implementation Steps
+
+1. Modify the `track_analyze_folder` method in the telemetry client to accept properties
+2. Update the analyze command handling in main.rs to:
+   - Remove the duplicate `track_analyze()` call
+   - Create properties map with analysis mode and other relevant information
+   - Call `track_analyze_folder` with the properties
+3. Test the implementation to ensure only one event is generated with correct properties
+4. Update any related tests
+
+## Testing Plan
+
+1. **Unit Tests**: Update telemetry tests to reflect the new method signature
+2. **Integration Tests**: Verify that only one event is generated when running the analyze command
+3. **Property Validation**: Confirm that the correct analysis mode is captured in event properties
+4. **Edge Cases**: Test with various combinations of command-line options
+
+## Backward Compatibility
+
+This change is backward compatible with existing telemetry infrastructure. The event name remains "Analyze Folder", and the core telemetry collection mechanism is unchanged. The only difference is in the data captured with the event.
+
+## Future Enhancements
+
+1. **Performance Metrics**: Add analysis duration and file count to the telemetry properties
+2. **Project Type Detection**: Include detected project types in the event properties
+3. **Error Tracking**: Add success/failure status to the events

.qoder/quests/command-event-normalization.md

@@ -0,0 +1,117 @@
+# Command Event Normalization Design
+
+## Summary
+
+This document outlines the changes needed to fix the duplicate telemetry events issue in the syncable-cli application. Currently, the `security` and `vulnerabilities` commands each generate two telemetry events, causing data duplication. The solution involves modifying the telemetry client to use descriptive event names directly and removing the duplicate event calls in the command handlers.
+
+## Problem Statement
+
+When running commands like `sync-ctl security .`, two events are generated:
+- "security" event with properties
+
+
+- "Security Scan" event
+
+Similarly for `sync-ctl vulnerabilities .`:
+- "vulnerabilities" event with properties
+
+
+- "Vulnerability Scan" event
+
+This duplication creates unnecessary noise in telemetry data and can skew analytics.
+
+## Solution
+
+The solution involves two key changes:
+
+1. Modify the telemetry client methods to directly use the descriptive event names:
+   - `track_security()` will track "Security Scan" events
+
+
+   - `track_vulnerabilities()` will track "Vulnerability Scan" events
+
+2. Remove the duplicate event calls in the command handlers:
+   - Remove `track_security_scan()` call from the security command handler
+
+
+   - Remove `track_vulnerability_scan()` call from the vulnerabilities command handler
+
+## Implementation Details
+
+### File: src/telemetry/client.rs
+
+Update the `track_security` method to use the descriptive event name:
+```rust
+
+pub fn track_security(&self, properties: HashMap<String, serde_json::Value>) {
+    self.track_event("Security Scan", properties);
+}
+```
+
+Update the `track_vulnerabilities` method to use the descriptive event name:
+```rust
+
+pub fn track_vulnerabilities(&self, properties: HashMap<String, serde_json::Value>) {
+    self.track_event("Vulnerability Scan", properties);
+}
+```
+
+Update the deprecated methods to be no-ops with deprecation comments:
+```rust
+
+
+pub fn track_security_scan(&self) {
+    // Deprecated: Use track_security with properties instead
+
+
+}
+
+pub fn track_vulnerability_scan(&self) {
+    // Deprecated: Use track_vulnerabilities with properties instead
+
+
+}
+```
+
+### File: src/main.rs
+
+In the Security command handler, remove the duplicate event call:
+```rust
+
+
+// Remove this duplicate call
+
+
+// if let Some(telemetry_client) = telemetry::get_telemetry_client() {
+//     telemetry_client.track_security_scan();
+// }
+```
+
+In the Vulnerabilities command handler, remove the duplicate event call:
+```rust
+
+
+// Remove this duplicate call
+
+
+// if let Some(telemetry_client) = telemetry::get_telemetry_client() {
+//     telemetry_client.track_vulnerability_scan();
+// }
+```
+
+## Benefits
+
+1. **Eliminates Duplicate Events**: Each command will generate exactly one telemetry event
+
+
+2. **Maintains Event Properties**: All existing properties will still be captured
+
+
+3. **Consistent Naming**: Event names will clearly indicate the type of scan performed
+
+
+4. **Backward Compatibility**: Existing telemetry infrastructure remains unchanged
+
+
+5. **Cleaner Analytics**: Reduces noise in telemetry data, making analysis more accurate
+

src/analyzer/runtime/detection.rs

@@ -14,14 +14,11 @@ impl RuntimeDetectionEngine {
     }
 
     /// Get all available package managers in a project
-    pub fn get_all_package_managers(project_path: &Path) -> Vec<String> {
+    pub fn get_all_package_managers(project_path: &Path) -> Vec<super::javascript::PackageManager> {
         use super::javascript::RuntimeDetector;
 
         let js_detector = RuntimeDetector::new(project_path.to_path_buf());
         js_detector.detect_all_package_managers()
-            .into_iter()
-            .map(|pm| pm.as_str().to_string())
-            .collect()
     }
 
     /// Check if a project uses a specific runtime

src/analyzer/security_analyzer.rs

@@ -1551,7 +1551,7 @@ impl SecurityAnalyzer {
     }
 
     // Additional helper methods...
-    fn collect_source_files(&self, project_root: &Path, language: &str) -> Result<Vec<PathBuf>, SecurityError> {
+    fn collect_source_files(&self, _project_root: &Path, _language: &str) -> Result<Vec<PathBuf>, SecurityError> {
         // TODO: Implement source file collection based on language
         Ok(vec![])
     }
@@ -1874,7 +1874,7 @@ mod tests {
         config.skip_gitignored_files = false;
         config.downgrade_gitignored_severity = true;
 
-        let analyzer = SecurityAnalyzer::with_config(config).unwrap();
+        let _analyzer = SecurityAnalyzer::with_config(config).unwrap();
         // Additional test logic could be added here for downgrade behavior
     }
 
@@ -2027,7 +2027,7 @@ mod tests {
 
         for pattern in &legitimate_patterns {
             // These should either not match any secret pattern, or be filtered out by context detection
-            let matches_old_generic_pattern = pattern.to_lowercase().contains("secret") || 
+            let _matches_old_generic_pattern = pattern.to_lowercase().contains("secret") || 
                                             pattern.to_lowercase().contains("key");
 
             // Our new patterns should be more specific and not match env var access