feat: vibecheck integration with attribution panel#21
feat: vibecheck integration with attribution panel#21o-k-a-y wants to merge 3 commits intojoshLong145:mainfrom
Conversation
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #21 +/- ##
==========================================
- Coverage 75.53% 74.50% -1.03%
==========================================
Files 19 19
Lines 4737 4825 +88
Branches 4737 4825 +88
==========================================
+ Hits 3578 3595 +17
- Misses 1078 1144 +66
- Partials 81 86 +5 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
src/app.rs
Outdated
| Some(agent_id) => ledger.depth_of_for_agent(&sym.id, agent_id), | ||
| None => ledger.depth_of(&sym.id), | ||
| }; | ||
| let read_depth = ledger.depth_of(&sym.id); |
There was a problem hiding this comment.
why remove the sub agent support?
There was a problem hiding this comment.
You're right. This was unintentional.
flatten_symbol was always using the aggregate depth_of(), ignoring the active agent filter. This caused symbol-level depth indicators in the tree view to show aggregate coverage even when filtering by a specific agent. Now passes agent_filter through and uses depth_of_for_agent() to match the behavior already present in count_symbols().
| for (family, score) in scores { | ||
| let pct = (score * 100.0).round() as u32; | ||
| let bar_len = (score * 12.0).round() as usize; | ||
| let bar = "█".repeat(bar_len); | ||
| let color = family_color(family); | ||
| lines.push(Line::from(vec![ | ||
| Span::styled( | ||
| format!(" {:<8}", format!("{family}")), | ||
| Style::default().fg(Color::DarkGray), | ||
| ), | ||
| Span::styled(format!("{bar:<12}"), Style::default().fg(color)), | ||
| Span::styled(format!("{pct:>3}%"), Style::default().fg(color)), | ||
| ])); | ||
| } |
There was a problem hiding this comment.
From my testing I noticed that larger projects now open much slower in ambits. With this type of implementation we only take the hit on application start, and new files from the file watcher. Im wondering if we can this operation occur in parallel. it's tricky since we are relying on the App instance which is constructed on app start.
We do have an event loop like pattern already implemented. wondering if we can extend the current Event type to add a new event type for vibe check file loads.
3 participants
No description provided.