Part 3 of 3 — Engineering Intent Series -- Inside the Machine: The ISL Build Pipeline
In Part 1 we identified the problem. In Part 2 we dissected the spec format. Now we go inside the engine that transforms intent into production code — automatically, verifiably, and repeatably. Thi...
Source: DEV Community
In Part 1 we identified the problem. In Part 2 we dissected the spec format. Now we go inside the engine that transforms intent into production code — automatically, verifiably, and repeatably. This is the ISL Tooling Engine. It has two distinct phases: Build and Generate. Phase 1: The Builder Real software is never a single file. A LoginForm depends on UserAuthService, which depends on User domain model, which depends on AuthStatus enum. Each of those has its own .isl.md spec file. The ISL Builder scans your entire specification folder, identifies all @Reference tags, and builds a Directed Acyclic Graph (DAG) of your system: AuthStatus (enum) └── User (domain model) └── UserAuthService (business logic) └── LoginForm (presentation) This graph is not documentation. It's the build order. Topological Sort The Builder performs a topological sort on this graph — the same technique used by real compilers, package managers (npm, cargo, gradle), and build systems like Make. The rule is simple:
