DevToolsBC — Vision Document

One-liner

Turn the entire Business Central codebase into a simulatable, queryable, explainable system — so developers never program blind again.

The World Today

Every BC customization follows the same painful loop:

Write AL → Deploy to sandbox → Click through UI → Hope it works → Debug when it doesn't → Repeat

This cycle costs 30-60 minutes per iteration. Multiply by dozens of iterations per feature, and you're losing days to feedback latency. Worse — the developer never sees the full picture. They're modifying a system of 9,000+ objects through a keyhole.

The tribal knowledge problem is even more damaging:

A senior dev knows that posting a sales invoice triggers 47 event subscribers across 12 extensions
A junior dev deploys their subscriber and has no idea it fires after a third-party extension already zeroed out the field they need
A consultant scoping a customization has no way to estimate blast radius without asking the senior dev

No tool solves this. Microsoft's AL Language extension gives IntelliSense. It doesn't show you what happens when your code runs. The debugger shows you one step at a time. Nobody shows you the whole pipeline.

The Vision

DevToolsBC gives every BC developer — senior, junior, consultant — x-ray vision into the system. Five capabilities, building on each other:

1. Structural Analysis — "What exists?"

Browse, search, and explore the full BC object model. See every table, codeunit, page, event, and how they connect. Answer: "What objects exist in the Sales domain?"

Status: Built. Object Browser, Event Flow, Dependencies, Domain Explorer.

2. Impact Analysis — "What does my code touch?"

Select any procedure, see its complete forward blast radius. Every procedure it calls, every event it fires, every subscriber that activates, every table it reads/writes/deletes.

Status: Built. Impact view with graph + table breakdown.

3. Execution Simulation — "What happens when it runs?"

Walk the entire execution path of a procedure — in order. See the call stack build up, events dispatch, branches taken, loops walked. The ordered execution trace that the debugger gives you, but without deploying.

Status: Built. Simulation view with timeline, graph, and table panels. Data-aware execution with AL expression evaluation. Scenario engine with expectations and AL test code generation.

4. Data Flow Tracing — "What happens to my record?"

Start from a record instead of a procedure. Pick a Sales Header, set Document Type = Invoice, select "Post" — see the entire posting pipeline with:

Field-level mutations — which fields change, from what to what, by whom
Validation inventory — every TestField/Validate/FieldError, what it checks, would it pass
Extension attribution — [Base] green / [Ext: AppName] amber / [Local] blue on every step
Pipeline hierarchy — expandable stages showing the posting flow as a tree

This is the record-centric lens — same engine, fundamentally different entry point and presentation. Where simulation answers "what does this code do?", data flow answers "what happens to this data?"

Status: Phase 1 built. Trace engine, mutation tracking, pipeline view, 3-step seed selector, attribution badges.

5. AI-Powered Understanding — "Explain it to me"

Natural language entry: "What happens when I post a sales invoice with foreign currency?" → auto-fills the structured form → trace runs. Click any step for a plain-language explanation tailored to your audience level (Developer / Consultant / Junior). Ask follow-up questions. Generate event subscribers and validation overrides.

Status: Not started. This is the pinnacle — where the structural analysis becomes accessible to non-developers.

The Architecture

.al files + .app symbols
        │
        ▼
   ┌─────────┐
   │ bc-parse │  Rust CLI — parses everything into SQLite
   │  (Rust)  │  9,236 objects, 53K procs, 23K events in ~3s
   └────┬─────┘
        │
        ▼
   ┌──────────┐
   │  SQLite   │  17-table schema — the single source of truth
   │  bc-toolkit.db  │
   └────┬─────┘
        │
        ▼
   ┌──────────────┐
   │Express Server │  REST + WebSocket API
   │  (Node.js)    │  Analysis engines live here:
   │               │  - simulation-engine.ts (code-centric DFS)
   │               │  - execution-engine.ts (data-aware simulation)
   │               │  - trace-engine.ts (record-centric + mutations)
   │               │  - impact-builder.ts (static forward BFS)
   │               │  - domain-builder.ts (multi-hop BFS)
   └────┬─────┘
        │
        ▼
   ┌──────────────┐
   │React Frontend │  10 views, terminal-aesthetic UI
   │ (Vite + TS)   │  Zustand state, dark theme, monospace
   └──────────────┘

Key principle: Rust parses, Node analyzes, React visualizes. The Rust parser is fast and done once. The Node engines can iterate quickly. The React views match the mental models of each analysis type.

Build Phases — Completed

Phase	What	Status
P0	Rust parser → SQLite, Express wired to DB	Done
P8	SQLite migration, domain BFS, object browser	Done
P9	Domain builder with events + extensions + calls + relations	Done
P10	Procedure body AST parsing (13 stmt types, 24 record ops)	Done
P11	Static Impact Analysis — forward BFS from seed	Done
P13	Simulation engine — ordered DFS execution trace	Done
P13+	Data-aware execution — AL expression parser/evaluator, virtual record store	Done
P14	Scenarios — expectations, comparison, AL test generation	Done
P15	Data Flow Tracer Phase 1 — trace engine, mutation tracking, pipeline view	Done

Build Phases — Ahead

Phase	What	Key Deliverable
P16	Data Flow Phase 2 — Mutation Timeline + Table View	Chronological mutation list, per-table summary cards
P17	Data Flow Phase 3 — Extension Analysis + Validation Enrichment	Would-fail predictions, extension breakdown charts, static explanations
P18	Data Flow Phase 4 — AI Explanations	Claude-powered step explanations, audience-level selector
P19	Data Flow Phase 5 — NL Input + Dialogue + Code Generation	Natural language queries, conversational follow-ups, AL code gen
P20	Claude Integration — write/simulate/iterate loop	API for Claude to submit code, run simulation, get structured results
P21	VS Code Convergence	Live impact analysis on save, inline annotations, Monaco editor option

Who Is This For?

Today — Jonathan's unfair advantage

At work: "I already simulated this, here's the full impact" — instant credibility
Client discovery: Scan their codebase, simulate key processes, present findings in the first meeting
Learning: Build the tool that exposes BC internals → learn BC internals deeply

Tomorrow — BC developer tool

No tool like this exists in the BC ecosystem
Microsoft's tooling provides IntelliSense, not simulation
Every BC partner (there are ~5,000 globally) has developers who could use this
Natural distribution: open-source the structural analysis, monetize the AI layer

Long-term — Company doctor diagnostic platform

Walk into any company → scan → simulate → diagnose
"Here's where your system is fragile"
"Here's the blast radius of what you're asking for"
"Here's the generated test suite that proves it works"
Reduces diagnostic time from weeks to hours

Design Principles

Record-centric AND code-centric. Two entry points to the same underlying engine. Developers think in code, consultants think in data. Serve both.
AI as enhancement, not dependency. Phases 1-3 of every feature work without AI. Static heuristics first. Claude enriches later. The tool must be useful offline.
Separate views for separate mental models. Impact (graph), Simulation (timeline), Data Flow (pipeline), Scenarios (test matrix). Don't force everything into one view.
Fork, don't modify. New engines fork from existing ones rather than adding flags. trace-engine.ts forked from simulation-engine.ts. Each view owns its engine. This prevents feature coupling.
Parse once, analyze many. The Rust parser runs in 3 seconds. Every analysis reads from SQLite. Adding a new analysis type means adding a new Node engine + React view — zero Rust changes.
Terminal aesthetic. Dark theme, monospace, compact. This is a power tool for developers, not a dashboard for executives. Information density over visual polish.

The 10 Views

#	View	Purpose	Status
1	Home	Quick stats, recent activity, jump points	Built
2	Objects	Browse/search all AL objects with full detail	Built
3	Event Flow	Publisher → subscriber chain visualization	Built
4	Dependencies	Extension/subscription relationship graph	Built
5	Trace	Debug session trace replay (from VS Code DAP)	Built
6	Processes	Domain explorer — BFS from seed objects	Built
7	Impact	Static forward blast radius from any procedure	Built
8	Simulation	Ordered execution trace with call stack	Built
9	Scenarios	Data-aware execution with expectations + test gen	Built
10	Data Flow	Record-centric pipeline with mutations + attribution	Built (Phase 1)

What Makes This Different

Not a linter. Linters check syntax. We simulate execution.
Not a debugger. Debuggers step one line at a time on a live system. We show the entire pipeline statically.
Not documentation. Documentation goes stale. We analyze the actual code.
Not AI chat about code. Chat gives you guesses. We give you the traced execution path, then let AI explain it.

The closest analogy: what Chrome DevTools did for web development, DevToolsBC does for Business Central.

Last updated: 2026-02-26 — Phase 15 (Data Flow Tracer Phase 1) complete