Reviewing files that changed from the base of the PR and between 07929d9 and 435027d.

• internal/core/dag.go (2 hunks)
• internal/core/execution/runstatus.go (4 hunks)
• internal/core/spec/builder.go (2 hunks)
• internal/core/spec/definition.go (1 hunks)
• internal/integration/handler_on_test.go (1 hunks)
• internal/runtime/agent/agent.go (2 hunks)
• internal/runtime/runner.go (6 hunks)
• internal/runtime/transform/status.go (1 hunks)
• schemas/dag.schema.json (1 hunks)

• GitHub Check: Test on ubuntu-latest

internal/core/dag.go (1)

475-482: Init handler field and handler type constant are consistent with existing lifecycle hooks

HandlerOn.Init with json:"init,omitempty" plus the HandlerOnInit constant mirrors the existing success/failure/cancel/exit pattern and lines up with the builder, runtime, and schema usage. No issues from a core-model perspective.

Also applies to: 519-525

internal/core/spec/definition.go (1)

93-101: HandlerOn Init/Abort/Cancel definition cleanly matches intended YAML shape

The added Init and Abort fields plus the deprecation comment on Cancel accurately model the new lifecycle hooks and backward compatibility without impacting other spec fields.

internal/runtime/transform/status.go (1)

73-80: WithOnInitNode correctly mirrors existing status options

The new option cleanly follows the existing pattern (OnExit/OnSuccess/OnFailure/OnCancel), safely handles nil, and ensures OnInit in DAGRunStatus is populated from the runtime node when present.

internal/core/execution/runstatus.go (1)

15-31: OnInit support in run status is wired consistently

Initializing OnInit in InitialStatus, adding the OnInit field to DAGRunStatus, and extending both Errors() and NodeByName() to include it keeps init handlers first‑class alongside exit/success/failure/cancel. The behavior is internally consistent and should integrate cleanly with the new status transformer option.

Also applies to: 35-57, 65-88, 91-113

internal/runtime/agent/agent.go (1)

610-633: Agent wiring for Init handler into runner config and status looks correct

Passing a.dag.HandlerOn.Init into cfg.OnInit and adding transform.WithOnInitNode(a.runner.HandlerNode(core.HandlerOnInit)) alongside the existing handler options keeps Agent → Runner → Status behavior consistent with other lifecycle hooks. The ordering in Status (nodes + log + init/exit/success/failure/cancel) is sensible.

Also applies to: 744-780

internal/runtime/runner.go (1)

35-45: Init handler orchestration and handler precondition evaluation look correct; double‑check intended semantics

The runtime changes hang together well:

• Runner/Config now carry onInit/OnInit, and setup() registers an HandlerOnInit node just like the other handlers.
• In Run, the init handler executes only after DAG-level preconditions pass and before any workflow nodes. If runEventHandler returns a non‑nil error (i.e., the init step’s Execute fails), setLastError and setCanceled are called, so the event loop exits with core.Aborted and no steps are run, matching the schema’s “if this fails, the DAG fails and no steps execute” intent.
• WithOnInitNode(r.HandlerNode(core.HandlerOnInit)) ensures status objects carry the init handler node state, in line with OnExit/OnSuccess/OnFailure/OnCancel.

Two subtle points you may want to confirm against your expectations/tests:

• In runEventHandler, failures in Prepare or in evaluating handler preconditions now set the handler status (failed or skipped) but return nil, so for the init handler only an actual Execute error will cancel the DAG. If you ever need preparatory/logging failures on init to abort the DAG too, you might want to propagate those as errors specifically for HandlerOnInit.
• setupEnvironEventHandler seeds Env[EnvKeyDAGRunStatus] from r.Status(ctx, plan). For onInit this will typically be NotStarted at the time the handler runs, whereas for exit/success/failure/cancel it reflects the final DAG status. If you expect init scripts to branch on DAG status, it’s worth confirming that this asymmetry is acceptable.

Overall, the init lifecycle hook is integrated consistently; just ensure these edge semantics line up with what you want long‑term (your new integration tests likely already cover most of this).

Also applies to: 66-76, 83-95, 128-143, 680-705, 724-743

internal/integration/handler_on_test.go (6)

1-9: LGTM: Clean test setup.

Package naming and imports follow Go conventions and coding guidelines, properly using stretchr/testify/require as specified.

---

11-12: LGTM: Proper parallel test setup.

Using t.Parallel() for the integration test suite is appropriate and improves test execution time.

---

14-36: LGTM: Comprehensive happy path test.

The test properly verifies both parsing (Init field and name) and runtime execution (OnInit status), with clear assertions.

---

38-67: LGTM: Thorough failure path test.

Excellent coverage of the init failure scenario, verifying the abort status, exit handler execution, and that subsequent steps don't run. The failure path testing aligns with coding guidelines.

---

69-125: LGTM: Good edge case coverage for preconditions.

Both tests properly handle precondition scenarios with appropriate assertions. The conditional checks (lines 114-116, 121-124) correctly handle timing-dependent behavior and are well-documented.

---

166-224: LGTM: Clear and consistent handler tests.

The Failure, Success, and Exit handler tests follow a consistent pattern and properly verify each handler's execution and status.

Reviewing files that changed from the base of the PR and between c178b89 and 58e29a6.

• internal/integration/handler_on_test.go (1 hunks)

• GitHub Check: Test on ubuntu-latest

internal/integration/handler_on_test.go (5)

1-11: LGTM!

The package declaration and imports are clean and follow Go best practices. The use of an external test package (integration_test) is appropriate for integration tests.

---

13-196: Excellent test coverage for HandlerOn feature.

The table-driven test structure is well-organized and covers the key scenarios: Init (success, failure, precondition skip, DAG precondition), Failure, Success, and Exit handlers. The use of optional setup/run/validate functions provides good flexibility.

---

48-77: Well-structured test for Init failure behavior.

The test correctly verifies that Init handler failure causes DAG abortion, triggers the exit handler, and prevents step execution. The validation logic properly checks all expected states.

---

103-135: Good defensive handling of timing-dependent states.

The test properly handles cases where OnInit may be nil or NotStarted when DAG preconditions fail, and accounts for timing-dependent node status (NotStarted or Aborted). This makes the test more robust.

---

216-257: Well-designed async abort test.

The test properly handles the asynchronous nature of abort handling using a goroutine and synchronization channel. The pattern of waiting for the DAG to reach Running status before aborting ensures deterministic test behavior. The comment on line 231 helpfully clarifies the mapping between the YAML abort field and internal Cancel handler.