@@ -36,7 +36,7 @@ This ADR only answers: given that spec, what does the Java code a user writes lo
 
 ## Decision
 
-The annotation is `@Builder.StubTask(dagId, taskId)`, not `@Builder.Task(id)`. Python declares the
+The annotation is `@Builder.TaskHandler(dagId, taskId)`, not `@Builder.Task(id)`. Python declares the
 task with `@task.stub` and Java supplies only its body, so the two are different things and should
 not share a name: `@Builder.Dag`/`@Builder.Task` stay with the native surface, where Java owns the
 Dag ([ADR-0002](0002-native-dag-interface.md)). Python owns both ids too, so a handler names the pair
@@ -49,7 +49,7 @@ code reads it.
 ### 1. Annotation based with positional injection
 
 ```java
-@Builder.StubTask(dagId = "etl", taskId = "score")
+@Builder.TaskHandler(dagId = "etl", taskId = "score")
 public long score(Client client, long rows, double threshold, List<String> regions) { ... }
 ```
 
@@ -83,7 +83,7 @@ public static class ReportInput implements TaskInput {
   public long transformed;
 }
 
-@Builder.StubTask(dagId = "etl", taskId = "report")
+@Builder.TaskHandler(dagId = "etl", taskId = "report")
 public void report(ReportInput input) {
   log.log(INFO, "Report {0} for transformed value {1}", input.runLabel, input.transformed);
   if (!"nightly".equals(input.runLabel)) {
@@ -145,7 +145,7 @@ One verb, overloaded, and everything registers as a class: nothing is constructe
   in code the processor writes and type-checks — without asking a Dag author to track argument
   order by hand.
 - `@Builder.XCom` is retired; the Python call site is the only source of data-flow wiring.
-- Renaming the shipped `@Builder.Task` to `@Builder.StubTask(dagId, taskId)` for this surface
+- Renaming the shipped `@Builder.Task` to `@Builder.TaskHandler(dagId, taskId)` for this surface
   breaks existing mixed-language Dags, which change one annotation and name the Dag they belong to.
 - The public surface is not final until the open question above is resolved.
 
 
@@ -145,7 +145,7 @@ Nothing is constructed at registration. Task classes are instantiated per task-i
 run ([ADR-0001](0001-mixed-lang-dag-interface.md)), and the Dag definition itself is read once, at
 registration, without running a task body.
 
-One bundle carries native Dags and mixed-language stub tasks alike
+One bundle carries native Dags and mixed-language task handlers alike
 ([ADR-0001](0001-mixed-lang-dag-interface.md)), so one process serves both.
 
 ## Alternatives
@@ -170,7 +170,7 @@ One bundle carries native Dags and mixed-language stub tasks alike
 - A task method is plain Java with a real signature, so nothing about the authoring surface exists
   only to satisfy the compiler: no twin class, no `In<T>`, no `TaskRef<T>` wrapper.
 - Native tasks keep `@Builder.Task`, while the mixed-language surface moves to
-  `@Builder.StubTask` ([ADR-0001](0001-mixed-lang-dag-interface.md)), so an annotation names
+  `@Builder.TaskHandler` ([ADR-0001](0001-mixed-lang-dag-interface.md)), so an annotation names
   which of the two things a method is.
 - The interface-based surface wires edges through object references (`after(extract)`) rather than
   through compile-time-generated calls, so it needs no tree reading and works under any compiler.
@@ -202,6 +202,6 @@ One bundle carries native Dags and mixed-language stub tasks alike
   Today's shipped `Dag` has only `addTask(id, definition)`, which returns the Dag rather than a ref;
   `.config(...)` is keyed to the Dag serialization schema.
 - **`register` is one overloaded verb**: `register(Class<?>)` for an annotated class, `register(Dag)`
-  for a built one, and `register(dagId, taskId, Class<? extends Task>)` for a stub task
+  for a built one, and `register(dagId, taskId, Class<? extends Task>)` for a task handler
   ([ADR-0001](0001-mixed-lang-dag-interface.md)). It is proposed here; today a bundle is built from an
   `Iterable<Dag>` through `BundleBuilder.getDags()`.