Blast Radius Analysis

ctxo get_blast_radius
vs Manual Analysis

Modify a base class constructor. How many files break?
One call vs five greps to find the answer.

What Was the Task
Add IMetricsService to BaseSyncJob Constructor
A base class with 17 subclasses across sync services, background jobs, and message processing. Adding a constructor parameter ripples through every subclass, every instantiation site, and every caller up the chain. The question: what exactly will break?

The Change

Multi-language 35 impacted symbols Claude Opus 4.6

BaseSyncJob is the abstract base for all synchronization jobs. It has 2 constructor overloads, 17 direct subclasses, and is instantiated in scheduling and job tracking services. Adding IMetricsService means every base(...) call and every new XxxSync(...) must change.

Two Approaches

With ctxo: search_symbols to find BaseSyncJob, then get_blast_radius for the full impact graph with confidence tiers and risk scores.

Without ctxo: Multiple Grep passes for class inheritance patterns, base(...) calls, and new Xxx(...) instantiation sites.

Performance Metrics
Head-to-Head Comparison
Both approaches used the same Claude Opus 4.6 model on the same codebase. The only difference: ctxo's dependency graph vs raw regex scanning.
Metric With ctxo Without ctxo Delta
Iterations (rounds)32Similar
Tool calls4633% fewer
Estimated tokens~14K~17K18% less
Execution time~15 seconds~15 secondsSame
Impact depth4 layers (depth 1-4)2 layers only2x deeper
Confidence classification3-tier (confirmed / likely / potential)Binary (breaks / doesn't)Risk-scored
Subclasses found17 (all)14 (missed 3)3 missed = silent compile errors
Impacted symbols35 (risk-scored, 4 layers deep)46 call sites (flat list, no scoring)Risk-scored + prioritized
RecommendationAlternative approach suggestedRaw list onlyIncluded
Result Quality
What Each Approach Revealed
Speed was similar. The real difference is depth, completeness, and actionability. Manual analysis gives a shallow snapshot; ctxo gives the full picture.

ctxo get_blast_radius

  • 17 of 17 subclasses found - zero missed, including Message module jobs
  • 35 impacted symbols with per-symbol risk scores (0.0 - 1.0)
  • 3-tier confidence: 21 confirmed, 8 likely, 6 potential
  • 4-depth traversal: subclasses - instantiation - scheduling - API/host
  • Edge kinds revealed (extends, imports, uses, calls)
  • Suggested alternative: resolve via ServiceContainer to touch only 1 file instead of 17

Manual Analysis

  • 14 of 17 subclasses found - missed 3 (AttachmentDownloadJob, ImageDownloadJob, MessageSyncJob)
  • 30 instantiation sites with line numbers (but incomplete without the 3 missing classes)
  • Only 2 layers deep - no visibility into scheduling or API callers
  • No risk scoring - flat list with no priority guidance
  • No transitive callers found (AppHostService, SyncEndpoints invisible)
  • No alternative approach suggested - just "here's what breaks"

Verdict: Manual Analysis Is Dangerously Shallow

The manual approach missed 3 subclasses entirely. In a real refactor, those 3 files would have compile errors that the developer didn't plan for. Grep-based analysis can only match text patterns it's told to look for - if the inheritance is in a different directory or module, it's invisible.

ctxo found every single subclass because it traverses the actual dependency graph, not regex patterns. It went 4 layers deep to reveal that this change ripples all the way to API endpoints and the host service lifecycle. And it suggested an alternative (ServiceContainer resolution) that could eliminate the entire ripple effect - reducing the change from 17 files to 1.

Manual analysis gives you a partial answer you think is complete. ctxo gives you the full answer with risk-scored priorities, confidence tiers, and actionable alternatives. The difference isn't speed - it's correctness.

Live Comparison
Side-by-Side: Claude Code Sessions
Two real conversations analyzing the same constructor change. Left uses ctxo's dependency graph. Right does it manually.
With ctxo ~15 seconds
U
I need to modify the constructor of BaseSyncJob to add a new IMetricsService parameter. What will break?
C
Let me analyze the blast radius using ctxo.
search_symbols (ctxo)
query: "BaseSyncJob"
get_blast_radius (ctxo)
symbolId: "...BaseSyncJob::class"
Result
impactScore: 35 | risk: 1.0 | confirmed: 21 | likely: 8 | potential: 6
Read
BaseSyncJob.cs (constructor signature)
C
Full blast radius analysis:
Depth 1 - 17 Subclasses (confirmed)
  • UserSync, UserArchiveSync, OrgSync
  • ThreadSync, ThreadEventSync
  • CalendarCollector, CalendarEnable, OnlineCalendarCollector, CallCollector
  • GroupSync, FeedSync, FeedMessages, FeedRetainedMessages, GroupAttachmentDownloader
  • AttachmentDownloadJob, ImageDownloadJob, MessageSyncJob
Depth 2 - Instantiation Sites (likely)
  • ScheduleManager - HandleUserSync, HandleGroupSync, HandleCalendar, HandleDownloads, RunManualSync
  • JobTracker - ExecuteSyncJob, RunPendingJobs
  • MessagesServiceRegistration
Depth 3-4 - Transitive Callers (potential)
  • AppHostService.MainLoopAsync - host lifecycle
  • AppHostService.ExecuteAsync - entry point
  • SyncEndpoints.MapSyncEndpoints - API layer
Recommendation
  • Resolve IMetricsService via ServiceContainer inside BaseSyncJob - touch only 1 file
Iterations: 3
Tools: 4
Tokens: ~14K
Without ctxo (Manual) ~15 seconds
U
I need to modify the constructor of BaseSyncJob to add a new IMetricsService parameter. What will break? DO NOT USE CTXO
C
Let me find all subclasses and usages with Grep.
Grep x3 (parallel)
class\s+\w+.*BaseSyncJob | class BaseSyncJob | all refs
Round 1 Result
14 subclasses found, 48 total references
Round 2 of 2
Read x1, Grep x2
constructor + new Xxx() + base() patterns
C
Complete blast radius:
Layer 1 - 14 Subclasses (missed 3!)
  • UserSync, UserArchiveSync, OrgSync
  • ThreadSync, ThreadEventSync
  • GroupSync, FeedSync, FeedMessages
  • FeedRetainedMessages, GroupAttachmentDownloader
  • CalendarCollector, CalendarEnable
  • OnlineCalendarCollector, CallCollector
  • AttachmentDownloadJob, ImageDownloadJob, MessageSyncJob - NOT FOUND
Layer 2 - 30 Instantiation Sites
  • ScheduleManager.cs - 16 calls
  • JobTracker.cs - 14 calls
Layers 3-4 - Not Reached
  • AppHostService, SyncEndpoints - invisible to grep
  • No risk scoring, no alternative suggested
Summary
  • 14 of 17 subclasses found (3 missed)
  • 30 instantiation sites (incomplete)
  • Thinks 46 call sites - actual number is higher
Iterations: 2
Tools: 6
Tokens: ~17K