Task Graph (DAG) Construction

## The three lifecycle phases Every Gradle build moves through three phases in strict order: 1. **Initialization** — Gradle decides which projects participate (reads `settings.gradle(.kts)`) and creates the `Project` objects. 2. **Configuration** — Gradle evaluates every build script, *creating and configuring* tasks and registering their relationships. No task *actions* run yet. 3. **Execution** — Gradle runs the selected tasks' actions in dependency order. ## Where the graph fits The **task execution graph** is computed *between* configuration and execution. It is a **DAG (directed acyclic graph)**: nodes are tasks, edges are dependency relationships, and it must contain no cycles. During configuration, relationships are declared but not yet resolved into an ordering. Once configuration completes, Gradle: 1. Takes the **requested tasks** (what you typed, e.g. `gradle build`). 2. Walks their dependencies **transitively** — `dependsOn`, implicit dependencies inferred from declared inputs/outputs, and `mustRunAfter`/`shouldRunAfter` ordering hints. 3. Produces a single, deduplicated, topologically-sortable graph of every task that must run, plus any `finalizedBy` finalizers. ## Why acyclic matters If task A depends on B and B (transitively) depends on A, there is no valid execution order, so Gradle fails with a *circular dependency* error before any action runs. This guarantees a deterministic order. ## Plan-then-run Because the **whole** graph is built first, Gradle knows up front exactly what will run. This enables features like up-to-date checking, the build cache, and parallel execution to reason about the entire plan instead of discovering work as it goes. ```kotlin tasks.register("compile") { doLast { println("compiling") } } tasks.register("test") { dependsOn("compile") // edge: test -> compile doLast { println("testing") } } // `gradle test` builds a graph [compile, test] and runs compile, then test. ```