Press enter or click to view image in full size

20 min readJust now

–

This is Part 5 of the series. In the previous parts, we built a complete Event-Component-System framework for Flutter, including features, systems, reactive programming, and widget integration. Now it’s time to address a crucial aspect of any framework: developer experience through debugging and inspection tools.

In this part, we’ll explore how custom DevTools extensions transform the debugging experience for ECS applications, making complex architectures visible and understandable at a glance.

Why DevTools Integration Matters

As your ECS application grows, understanding what’s happening under the hood becomes increasingly important. Questions like “Which system is reacting to this component?” or “Why isn’t my reactive system firing?” become common. Without proper tooling, debugging these issues means adding print statements and rebuilding repeatedly; a frustrating and time consuming process.

Traditional debugging approaches fall short with ECS architectures because:

• Runtime behavior: Reactive systems only show their behavior when things change
• Scale problems: Large applications can have dozens of features, each with multiple systems and entities
• Temporal issues: Understanding the sequence of events and reactions requires careful logging
• Distributed logic: A single feature’s behavior might involve multiple systems and entities spread across different files

Consider a typical debugging scenario without proper tooling. You’re building an app where the user’s profile data should update the UI, trigger a notification, and save to persistent storage. When you test it, none of these things happen. You start adding print statements to different components, then to each system that should react to it, then to the storage layer. After five rebuilds, you discover the reactive system was never added to the feature. This simple oversight cost you 20 minutes of frustration.

A custom DevTools extension solves all of these problems by providing real-time visibility into your ECS architecture. It’s not just about making debugging faster, it’s about making entire classes of bugs impossible to overlook.

The Philosophy of Visual Debugging

Before diving into the specific features, it’s worth understanding the philosophy behind visual debugging tools. Code is inherently linear and textual. You read it line by line, file by file. But ECS architectures are fundamentally about relationships and data flow. They’re networks of interconnected components, systems, and reactions.

Trying to understand a network through linear code is like trying to understand a city’s layout by reading turn-by-turn directions. You can do it, but it’s inefficient and error-prone. A map , a visual representation, makes the structure immediately clear.

This is why tools like Redux DevTools revolutionized debugging for state management. They didn’t add new functionality; they made existing functionality visible. The same principle applies to our ECS framework. The architecture already exists in our code, but making it visual transforms how we interact with it.

The goal isn’t to replace code or traditional debugging. It’s to complement them. Sometimes you need to step through code line by line. Other times, you need to see the big picture. Great development tools provide both perspectives.

Understanding the Technical Architecture

Before we explore the features, let’s briefly understand how DevTools extensions work. This context will help you appreciate why certain features work the way they do.

Flutter DevTools uses a service extension protocol built on top of the Dart VM service. Your running application can register custom service extensions, essentially RPC endpoints that DevTools can call. When DevTools needs data, it sends a request to your app, your app serializes the response, and DevTools displays it.

This architecture has important implications:

It’s live: DevTools is always talking to your running app, not analyzing static code or looking at logs. The data you see is the actual current state.

It’s lightweight: The service extension only runs when DevTools requests data. Your production app pays zero performance cost for debugging capabilities.

It’s separate: The DevTools UI is a completely separate Flutter application. It can use any widgets, packages, or visualization libraries without affecting your main app.

It’s discoverable: DevTools automatically finds all registered service extensions. No configuration file, no manual registration in DevTools itself.

Our ECS framework takes advantage of this by automatically registering a service extension when the first ECSManager is created. This extension exposes all features, systems, entities, and logs. The DevTools extension then queries this data and visualizes it.

The beauty of this approach is its transparency. As a developer using the framework, you don’t do anything special to enable DevTools support. You write your features and systems normally, and they automatically appear in DevTools. This “zero configuration” approach is crucial for adoption, debugging tools that require setup often go unused.

The Power of Visual Debugging

The DevTools extension for our ECS framework provides three main views, each addressing different debugging needs. Let’s explore each in depth, understanding not just what they do, but why they matter and how they change your development workflow.

Entity Browser: Your ECS Database Explorer

The entity browser gives you a live view of all components and events in your application. Think of it as a database browser for your ECS architecture, but with the immediacy of a debugger and the comprehensiveness of a schema viewer.

When you open the entity browser, you see a list of every entity in your application. Each entry shows:

• The entity’s name and type (Component or Event)
• Which feature it belongs to
• For components: the current value and previous value
• For events: the last triggered timestamp

This might sound simple, but the implications are profound. You’re looking at the complete state of your ECS architecture. Every piece of data your application is tracking is visible in one place.

The real magic happens with the filtering capabilities. In an app with hundreds of entities, you can instantly filter by feature, by type, or search by name. This makes it trivial to find exactly what you’re looking for, even in complex applications.

Let me give you a concrete example. Imagine you’re building a trading system for your app. You have components for user gold, inventory slots, merchant inventory, transaction status, and more. During testing, a trade completes but the gold doesn’t transfer.

Without the entity browser, you’d have to:

1. Add print statements to the gold component
2. Add print statements to the trade system
3. Rebuild and run the scenario again
4. Sift through console output to find your prints among framework messages
5. Maybe add more print statements and repeat

With the entity browser:

1. Open the browser and search for “gold”
2. Watch the component’s value in real-time as you perform the trade
3. See immediately whether the component value changes at all
4. If it does change, check the previous value to verify the calculation
5. If it doesn’t change, you know the problem is in the system logic, not the component

This transforms a multi-step debugging process into immediate observation. You’re not instrumenting your code and waiting for results, you’re watching your application’s state directly.

The browser updates automatically every second, so you can perform actions in your app and see the results immediately. This real-time feedback creates a tight loop between action and observation, making it easy to test hypotheses quickly.

For components, seeing both current and previous values is particularly valuable. It helps you understand not just the state, but the transitions.

The feature grouping is also more useful than it might initially appear. Features in our ECS framework represent logical domains. When debugging, you often know which domain has the problem. Filtering by feature lets you ignore everything else and focus on the relevant entities.

Dependency Graph: Visualizing the Invisible

The dependency graph is where the DevTools extension truly shines. It visualizes your entire ECS architecture as a connected graph, transforming abstract code relationships into concrete visual connections.

When you open the graph view, you see nodes of different colors:

• Lifecycle nodes (OnInitialize, OnExecute, OnCleanup, OnTeardown) in purple
• Components in green
• Events in orange
• Systems in blue

The colors aren’t just aesthetic, they encode information. At a glance, you can distinguish between data (components/events) and behavior (systems), and between different types of data.

But the real power is in the edges, the lines connecting nodes. These edges represent relationships:

• An edge from OnInitialize to a system means that system runs during initialization
• An edge from a component to a system means the system reacts to that component’s changes
• An edge from a system to a component means the system interacts with (reads or modifies) that component

These relationships exist in your code, of course. A reactive system declares which entities it reacts to in its reactsTo getter. But in code, you might need to open multiple files to understand these relationships. The graph shows them all at once.

Let’s consider what this means for architectural understanding. Suppose you’re joining a project with an existing ECS codebase. The project has 15 features, each with multiple systems and entities. How do you learn how it works?

The traditional approach: read the code. Start with the main feature, follow the system implementations, see which components they use, find those component definitions, see which other systems use them, and so on. After several hours, you have a mental model, hopefully an accurate one.

With the dependency graph: open DevTools, look at the graph. In seconds, you see the entire architecture. You can immediately identify:

• Which features are central (lots of connections) vs peripheral
• Which components trigger the most reactions (many systems react to them)
• Which systems are most complex (interact with many entities)
• How different features interact with each other

The graph supports zooming and panning, so you can get both a bird’s-eye view and a detailed view. The layout algorithm automatically arranges nodes to minimize edge crossings, making the structure as clear as possible.

The interactive features take this further. Click on any node to highlight its entire cascade of dependencies. This reveals the ripple effects through your architecture.

For example, click on a component. The graph highlights:

• All systems that react to changes
• All components those systems interact with
• Any systems that react to those components (creating a chain reaction of dependencies)

This cascade visualization answers a crucial question: “If I change this, what else is affected?” This is invaluable for refactoring, for understanding side effects, and for impact analysis.

The graph also includes search and filter functionality. Looking for all systems related to player health? Just type something and the relevant nodes light up while others fade to gray. This makes navigating large architectures effortless.

You can also filter by feature, which effectively creates a subgraph showing only the systems and entities within that feature and their external connections. This is useful for focusing on a specific domain without the noise of the entire application.

One particularly interesting use case is detecting architectural problems. If a system has edges to entities from many different features, it might be doing too much, a code smell in ECS architecture. If a component has no incoming edges (no systems react to it), it might be dead code. These patterns are hard to spot in code but obvious in the graph.

The dependency graph fundamentally changes how you think about your architecture. Instead of code as files and functions, you start seeing it as a network of data flows and reactions. This shift in perspective often leads to better architectural decisions.

Log Viewer: The Audit Trail

The log viewer shows a live stream of everything happening in your ECS framework. Every component update, every system reaction, every event trigger gets logged with a timestamp and detailed message.

This might sound like standard logging, but the ECS framework’s logging is specifically designed for architectural visibility. The framework automatically generates descriptive log messages:

• When a component updates: “UserFeature.AuthStateComponent updated from required to completed”
• When a system reacts: “UIFeature.UserAuthStateIcon reacted to changes in UserFeature.AuthStateComponent”
• When an event triggers: “UserFeature.LoginEvent triggered”

These messages are structured and consistent. You always know which feature owns the entity, what changed, and why. This consistency makes logs scannable, you can quickly skim through hundreds of entries to find what you’re looking for.

The log viewer displays entries in reverse chronological order (newest first), which matches the typical debugging workflow. You just triggered a bug, you immediately look at the logs to see what happened. The most recent events are right at the top.

Each log entry is expandable to show the full call stack. This bridges the gap between the high-level architectural view and the low-level code. The log tells you “GoldBarSystem reacted,” the stack trace tells you exactly where in the system’s code that happened.

Like the other views, the log viewer includes powerful filtering. You can filter by log level (info, warning, error), search through messages, or clear old logs to focus on current behavior.

The log level filtering is particularly useful during performance debugging. Set the level to “warning” or “error” and you see only problems. Your application might be logging hundreds of normal operations, but you only care about the three errors buried in there.

The search functionality works across all fields, feature names, entity names, log messages. Searching for “gold” shows all logs related to any entity with “gold” in its name, from any feature. This cross-cutting search is powerful for tracing how a single concept (like gold) flows through your application.

The clear logs feature deserves special mention. During iterative debugging, you often want to reset your observation window. Perform an action, see what logs, clear the logs, try a variation, compare the new logs. The ability to clear logs without restarting your app maintains the fast iteration cycle.

The logs are particularly useful for debugging timing issues. You can see the exact sequence of component updates and system reactions, helping you understand race conditions or unexpected ordering problems.

For example, suppose you’re debugging a situation where the UI updates before data loads, causing a flash of incorrect content. The logs show:

12:34:56.100 - UIFeature.DisplaySystem reacted to changes in DataFeature.StateComponent12:34:56.150 - NetworkFeature.FetchSystem completed fetch12:34:56.151 - DataFeature.DataComponent updated from null to [data]12:34:56.152 - DataFeature.StateComponent updated from Loading to Loaded12:34:56.153 - UIFeature.DisplaySystem reacted to changes in DataFeature.StateComponent

The timestamps reveal the problem: DisplaySystem reacted to a state change at 12:34:56.100, but the data wasn’t loaded until 12:34:56.151. The first reaction must have been triggered by a different state change (probably changing to Loading). This immediate visibility into timing makes debugging race conditions much more tractable.

Real-World Use Cases

Let me share some detailed practical scenarios where the DevTools extension proves invaluable. These aren’t hypothetical examples, they’re based on real debugging patterns you’ll encounter in ECS applications.

Debugging Reactive Systems

You’ve created a reactive system that should update the UI when inventory changes, but nothing happens when you add items.

Without DevTools, your debugging process might look like:

1. Add print statements to the inventory component’s update method
2. Add print statements to the reactive system’s react method
3. Rebuild and run the app
4. Add an item to inventory
5. Check the console, you see the component update but not the system reaction
6. Wonder if the system is registered
7. Check the feature definition, it is registered
8. Wonder if the system is listening to the right entity type
9. Check the reactsTo getter, looks right
10. Add more print statements
11. Eventually discover the reactsIf condition returns false due to a different bug

This process takes 15–20 minutes and involves multiple rebuilds.

With DevTools:

1. Open the entity browser and watch the inventory component
2. Add an item, see the component’s value change from [item1] to [item1, item2]
3. Switch to the dependency graph and click the inventory component
4. See the InventoryUISystem is connected, confirming it should react
5. Open the log viewer, no log of the system reacting
6. Check your system’s reactsIf condition in the code
7. Fix the bug

This process takes 2–3 minutes and requires no rebuilds. More importantly, the visual feedback guides you to the problem. You can see the component changing, see the system should react, and therefore deduce that the system is choosing not to react.

Onboarding New Developers

A new team member joins your project. They’re experienced with Flutter but new to your ECS architecture. You need them productive quickly.

Traditional onboarding: “Here’s the codebase. The main features are in src/features/. Each feature has systems and entities. Start by reading the player feature, then look at how it interacts with the inventory feature. The reactive systems are the tricky part, make sure you understand those. Good luck!”

The developer spends days reading code, building mental models, and asking questions. They make their first commit a week later.

With DevTools onboarding: “Here’s the codebase. Open DevTools and look at the dependency graph. This is our entire architecture. Green nodes are data, blue nodes are behavior. Purple nodes are when things run. Click around to explore the connections.”

The developer can explore interactively. They click on features, systems and see what data they work with. They click on components and see all the systems that react to it. They follow chains of dependencies to understand feature interactions.

After an hour with the graph, they understand the architecture. After a day reading specific code they’re interested in, they’re making productive contributions. The visual tool accelerated understanding by an order of magnitude.

This isn’t just about speed, it’s about accuracy. When learning from code alone, developers build mental models that might be incomplete or wrong. They might not notice a subtle reactive dependency or misunderstand the execution order. The visual representation is authoritative, it shows exactly what exists and how it connects.

Refactoring with Confidence

You want to split a feature into two separate features. The current feature is too large, and separating concerns will make the code more maintainable.

Before making changes, you open the dependency graph and click on the systems and entities in the feature.

This gives you a checklist of external dependencies. You know exactly which other features will need updates when you split PlayerFeature. You can plan the refactoring.

After making the changes, you refresh the graph and verify the new structure.

You run the app, open the log viewer, and watch the systems react normally. The refactoring succeeded without incident because you had complete visibility into dependencies before, during, and after the change.

Debugging Data Flow

You’re implementing a feature where completing a quest should update multiple systems: grant rewards, unlock new areas, update the UI, and trigger an achievement check. Sometimes all of these happen, sometimes only some of them, seemingly at random.

The log viewer reveals what’s happening:

14:23:15.234 - QuestFeature.QuestCompleteEvent triggered14:23:15.235 - RewardFeature.RewardGrantSystem reacted to trigger of QuestCompleteEvent14:23:15.240 - ProgressFeature.UnlockSystem reacted to trigger of QuestCompleteEvent14:23:15.242 - UIFeature.NotificationSystem reacted to trigger of QuestCompleteEvent

Three systems reacted, but you expected four. AchievementSystem didn’t react. You check the dependency graph, AchievementSystem is connected to QuestCompleteEvent. So why didn’t it react?

You check the code and find that AchievementSystem has a reactsIf condition checking if achievements are enabled. In this playthrough, the user hasn’t unlocked achievements yet. The system is working correctly; your expectations were wrong.

But wait, sometimes it works? You test again, this time on a playthrough with achievements enabled:

14:25:42.123 - QuestFeature.QuestCompleteEvent triggered14:25:42.124 - RewardFeature.RewardGrantSystem reacted to trigger of QuestCompleteEvent14:25:42.125 - AchievementFeature.AchievementSystem reacted to trigger of QuestCompleteEvent14:25:42.129 - ProgressFeature.UnlockSystem reacted to trigger of QuestCompleteEvent14:25:42.130 - UIFeature.NotificationSystem reacted to trigger of QuestCompleteEvent

All four systems reacted. The “random” behavior was actually conditional behavior. The logs and graph together revealed both the expected flow and the condition affecting it.

The Developer Experience Advantage

What makes this DevTools integration special isn’t just the features, it’s how effortless they are to use. Let’s talk about the developer experience principles that make these tools actually get used in practice.

Zero Configuration

The extension automatically discovers your ECS architecture through the service extension protocol. There’s no configuration file, no manual registration, no setup process. Add a new feature with systems and entities, and it immediately appears in DevTools. Remove a feature, and it disappears.

This “zero configuration” approach is crucial for adoption. Developers won’t use debugging tools that require setup. They’ll use print statements instead because print statements work right now, with zero friction. By making DevTools support automatic, we remove that friction.

The framework achieves this through reflection and service extensions. When you create an ECSManager, it automatically registers a service extension. When DevTools queries that extension, the manager discovers all features, systems, and entities, serializes them, and sends them back. From the developer’s perspective, it just works.

Real-Time Updates

The extension polls your application every second, giving you a live window into your architecture. You don’t manually refresh, you don’t restart anything, you don’t clear caches. The data you see is always current.

This real-time nature fundamentally changes how you debug. Traditional debugging is a batch process: instrument code, run the app, examine results, repeat. With real-time DevTools, debugging becomes continuous observation. You perform actions in your app and immediately see the effects in DevTools.

This tight feedback loop accelerates learning. You can test hypotheses rapidly. “Does clicking this button update that component?” Just click and watch, you have your answer in a second. “Which systems react when I do this?” Perform the action and watch the logs stream in.

The one-second polling interval is a careful balance. More frequent updates would consume more resources and make the UI feel jittery. Less frequent updates would feel laggy. One second is fast enough to feel real-time while being efficient enough to always be on.

Beyond Debugging: Design and Communication

While the DevTools extension excels at debugging, its value extends far beyond finding bugs. Let’s explore some less obvious but equally important use cases.

Living Documentation

Traditional documentation goes stale. You write detailed architecture docs explaining how features interact, then the code changes and the docs become lies. Keeping documentation synchronized with code requires discipline and effort that often doesn’t happen.

The DevTools dependency graph is living documentation. It can never go stale because it’s generated from the actual code. If you add a new system, it appears in the graph. If you remove a dependency, the edge disappears. The documentation is always perfectly accurate because it’s not documentation, it’s a visualization of reality.

This has profound implications for team communication. Instead of writing how things work, you show the graph. Instead of describing the initialization sequence, you show the OnInitialize node and its connections.

The graph becomes a shared reference. In code reviews, you can say “look at the graph” instead of explaining architectural decisions in comments. In architecture discussions, you can pull up the graph and point at specific nodes and edges. In sprint planning, you can estimate complexity by looking at the number of connections.

Design Tool

The DevTools extension isn’t just for finished code. it’s useful during development too. When planning a new feature, you can sketch out the architecture quickly and immediately see it visualized.

Here’s a workflow: You’re designing a crafting system. You create:

• CraftingFeature
• RecipeListComponent with an empty list
• InventoryCheckComponent with placeholder logic
• CraftingExecuteSystem that does nothing yet
• CraftingCompleteEvent

You open DevTools and see your architecture in the graph. Even though nothing works yet, you can see the structure. You can verify that CraftingExecuteSystem is in the OnExecute lifecycle (since crafting happens over time). You can see that you’ll need to connect it to InventoryFeature.

You realize you forgot to handle crafting failures. You add CraftingFailedEvent and see it appear on the graph. You add FailureNotificationSystem and see it connect. You’re designing by seeing, not just by thinking.

This visual design process helps you spot architectural issues early. If your new system has edges to components in six different features, maybe it’s doing too much. If your new component has no incoming edges, maybe nothing will use it. These patterns are obvious in the graph but easy to miss in code.

Code Review Enhancement

The DevTools extension provides objective evidence during code reviews. Instead of trusting that a PR correctly implements reactive dependencies, you can verify them visually.

A reviewer can:

1. Pull the branch
2. Run the app
3. Open DevTools
4. Check that the new systems appear in the graph
5. Verify their connections match the PR description
6. Watch the logs to confirm the systems react as claimed

This visual verification is faster and more reliable than reading code. You can see at a glance what changed. New nodes in the graph correspond to new systems or entities. New edges correspond to new dependencies.

The logs provide evidence of runtime behavior.

This objective verification improves code review quality while reducing reviewer burden. Less time reading code trying to understand changes, more time evaluating whether those changes are right.

Performance Profiling

While DevTools isn’t a dedicated performance profiler, it provides useful performance insights. The OnExecute node in the graph shows every system running each frame. A system with many outgoing edges is likely doing a lot of work. The combination reveals performance hotspots.

You can also use the logs for rough performance analysis. If certain systems appear in the logs constantly, they’re reacting frequently. If certain components update dozens of times per second, they might be updating too often.

This isn’t a replacement for proper profiling tools, but it’s often enough to identify obvious problems. You don’t need microsecond precision to spot that a system is running unnecessarily or that a component is updating in a tight loop.

Educational Tool

For teams adopting ECS architecture, the DevTools extension serves as an educational tool. New developers can explore example projects visually, seeing how ECS architecture works in practice.

They can experiment freely. “What happens if I remove this system?” Remove it and watch the graph change. “Which systems does this component affect?” Click it and see the cascade. “How do lifecycle systems work?” Look at the purple nodes and their connections.

This hands-on exploration builds intuition. Developers learn by doing and seeing, not just by reading. The immediate visual feedback makes the learning process engaging rather than tedious.

The extension also helps with teaching ECS principles. You can demonstrate reactive programming by showing how a component update cascades through systems. You can explain separation of concerns by showing how systems in different features interact only through entities. Abstract principles become concrete and visible.

Integration with Development Workflow

The DevTools extension isn’t a separate tool you occasionally open, it integrates seamlessly into your daily development workflow. Let’s talk about how it fits into common development activities.

Feature Development

When developing a new feature, DevTools is your companion:

1. Design phase: Sketch out entities and systems, see the structure in the graph
2. Implementation phase: Watch the entity browser as you implement component logic
3. Testing phase: Use logs to verify systems react correctly
4. Debugging phase: Use the graph to understand unexpected behavior
5. Refining phase: Check the graph to ensure your architecture is clean

You keep DevTools open in a second window, glancing at it as you work. It provides constant feedback about your code’s behavior and structure.

Bug Investigation

When a bug report comes in, DevTools helps you triage:

1. Read the bug report
2. Identify which domain it affects (UI, gameplay, persistence, etc.)
3. Open the entity browser and filter to that domain’s feature
4. Reproduce the bug while watching components
5. Identify which component behaves incorrectly
6. Switch to the graph and click that component
7. See which systems interact with it
8. Check the logs to see the actual reaction sequence
9. Form a hypothesis about the bug’s cause
10. Fix the code and verify in DevTools

This structured approach makes bug investigation systematic rather than random. You start broad (which domain?), narrow down (which component?), then investigate deeply (which systems?).

Architecture Reviews

During architecture reviews, DevTools provides visual aids:

1. Present the proposed architecture as code
2. Run it and show the graph
3. Discuss the structure visually
4. Identify potential issues (too many connections, unclear separation, etc.)
5. Refactor and show the improved graph
6. Make decisions based on visual evidence

These reviews are more productive than abstract discussions because everyone is looking at the same concrete representation. Arguments about architecture become discussions about specific nodes and edges you can all see.

Maintenance and Refactoring

When maintaining old code, DevTools helps you understand it:

1. Open the project
2. Look at the dependency graph
3. Identify the central features (most connections)
4. Identify the peripheral features (few connections)
5. Understand the overall structure before diving into code
6. When refactoring, verify you haven’t broken connections

The graph serves as a map of the codebase. You can explore it to understand where things are and how they relate before making changes.

Best Practices for Using DevTools

To get the most value from the DevTools extension, follow these practices:

Keep DevTools Open

Don’t treat DevTools as a tool you open when problems occur. Keep it open in a second monitor or window while developing. Glance at it regularly. Watch components change as you interact with your app. Monitor logs as systems react. This continuous visibility helps you catch issues early.

Use the Right View for the Task

Each view serves different purposes:

• Entity browser: Inspecting specific component values, watching state changes
• Dependency graph: Understanding architecture, identifying dependencies, impact analysis
• Log viewer: Understanding sequences, timing issues, verifying reactions

Switch between views based on what you’re investigating. Don’t try to use the entity browser for architectural questions or the graph for timing issues.

Filter Aggressively

Don’t try to process all information at once. Use filters to focus on what matters:

• In the entity browser: Filter by feature when debugging a specific domain
• In the graph: Search for specific entity or system names
• In the log viewer: Filter by log level to reduce noise

Effective filtering transforms overwhelming information into actionable insights.

Use the Cascade Feature

When analyzing impact, always use the cascade feature in the graph. Click a node to see everything it affects. This reveals non-obvious dependencies and helps you understand ripple effects.

Verify After Refactoring

After any architectural changes, check all three DevTools views:

1. Graph: Verify the structure matches your intentions
2. Entity browser: Verify all entities exist as expected
3. Logs: Perform key actions and verify systems react correctly

This three-step verification catches issues before they reach production.